FôrIt CDS. Hovedprosjekt Høgskolen i Oslo og Akershus. Prosjektnummer: Mikkel Sannes Nylend. Shahariar Kabir Bhuiyan

Transkript

1 Hovedprosjekt 2014 Høgskolen i Oslo og Akershus Prosjektnummer: Mikkel Sannes Nylend Shahariar Kabir Bhuiyan Stian Strøm Anderssen

2 PROSJEKT NR Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL FôrIt CDS DATO ANTALL SIDER / BILAG PROSJEKTDELTAKERE Stian Strøm Anderssen Shahariar Kabir Bhuiyan Mikkel Sannes Nylend (s177437) (s181104) (s181115) INTERN VEILEDER Eva Hadler Vihovde OPPDRAGSGIVER Goodtech ASA SAMMENDRAG KONTAKTPERSON Harald Pedersen Øystein Myhre FôrIt CDS er en mobil webapplikasjon som skal hjelpe fiskeoppdrettere med å spore leveranser av sitt fiskefôr. I applikasjonen vil en finne informasjon om ordre som: lastes, er på vei og som er ferdig. I tillegg kan en trykke på hver ordre og få listet ordrelinjer, som inneholder informasjon om hvilke varer som er bestilt. Det er også laget en kartløsning som skal vise hvor skipet med ordren er lokalisert. 3 STIKKORD Fiskefôr Goodtech Webapplikasjon

3 Innholdet i rapporten Rapporten inneholder følgende dokumenter i denne rekkefølgen. Presentasjon Produktdokumentasjon Testrapport Valg og utfordringer Prosessdokumentasjon Vedlegg

4 HØGSKOLEN I OSLO OG AKERSHUS FôrIt CDS Presentasjon Stian Strøm Anderssen, Mikkel Sannes Nylend og Shahariar Kabir Bhuiyan Gruppe

5 Presentasjon Forord Denne rapporten er en presentasjon av vårt hovedprosjekt avlagt på Høgskolen i Oslo og Akershus sommeren våren I denne rapporten presenterer vi produktet, gruppen, oppdragsgiver og skriver litt om mål for oppgaven. Presentasjonen kan leses uten noen spesiell forkompetanse. I siste avsnitt som omhandler produktet, går vi litt inn i teknisk detalj, men det skal være forståelig uansett leser. For mer informasjon og kildekode til prosjektet, se prosjektets hjemmeside: 1

6 Presentasjon Innholdsfortegnelse Forord...1 Innholdsfortegnelse Presentasjon Oppgaven Aktørene Gruppen Goodtech ASA Goodtech og industriell IT EWOS Fabrikker i Norge Høgskolen i Oslo og Akershus Bakgrunn FôrIt og FôrIt CDS Forskjell på storkunde og oppdretter Ordre Sporingssystemer Mål Produktet...8 2

7 Presentasjon 1 Presentasjon Vi er gruppe 10 som har hovedprosjekt på Høgskolen i Oslo og Akershus. Gruppen har fått i oppgave å lage en applikasjon for Goodtech ASA. 1.1 Oppgaven I henhold til oppgaven skal gruppen: - produksjonsprosessen fra mot hovedoppgave beskriver en løsning hvor EWOS via smarttelefon / nettbrett skal kunne følge opp sin bestilling av varer. S (ref: oppgavebeskrivelse hovedprosjekt Goodtech ASA) Gruppen skulle som nevnt over lage en applikasjon som skal brukes til sporing av bestilt mengde fiskefôr, en kunde skal kunne spore sine ordre, se hvor båten er, når den ankommer oppdrettsanlegget. Oppgaven sitt hovedmål er å forenkle prosessen med oppfølging av fôrleveranser for oppdretterne. Ved å lage en mobil applikasjon hvor oppdrettere kan logge inn og se sine kommende ordre, samt se hvor de er på vei, vil en slippe mange telefoner til storkunder om hvor fôret blir av og hvorfor de har fått det de har fått. Før gruppen påtok seg oppgaven var de fleste rammebetingelser allerede bestemt. Applikasjonen skulle utvikles i Java med Vaadin Touchkit og bygges med Maven byggeverktøy. Gruppen stod fritt til å prioritere hvilken funksjonalitet som skulle implementeres først, men Goodtech hadde en del krav for hva som måtte utvikles. For detaljer om dette, vennligst se kravspesifikasjon og utfyllende produktdokumentasjon. 3

8 Presentasjon 2 Aktørene I denne seksjonen skal vi se nærmere på de forskjellige aktørene i prosjektperioden. 2.1 Gruppen Gruppen består av tre medlemmer. Shahariar Kabir Bhuiyan, Mikkel Sannes Nylend og Stian Strøm Anderssen. Medlemmene har jobbet sammen i flere prosjekter tidligere og har vært motivert til å gjøre det bra siden dag en! 2.2 Goodtech ASA Goodtech er et industrifirma som ble startet opp i 1913, den gang under navnet Norsk Elektronisk Kabelfabrikk. I oppstarten var dette det eneste kabelselskapet i Norge, og de spesialiserte seg på produksjon av kabler til telefon og telegraf. I 1933 ble NRK dannet og dette medførte en sterk spredning av radioer rundt i de norske hjem. Norsk Elektronisk Kabelfabrikk var den største produsenten av kabler til disse. Frem til andre verdenskrig, gjorde bedriften det svært godt med en årlig ekspansjon, og opp gjennom årene har kabler vært produsert. I nyere tid har selskapet byttet fagfelt til utvikling rettet mot industri. Goodtech ASA er i dag et konsern som omfatter flere datterselskaper. De tilbyr tjenester i dag innenfor blant annet automatisering, industriteknikk, installasjon, kraftteknikk og miljøteknikk Goodtech og industriell IT Goodtech tilbyr i dag tjenester innenfor de fleste industrifelter som nevnt over. Gruppen skal skrive en oppgave for Goodtech Projects & Services, avdeling Industriell IT. Avdeling for industriell IT har de siste årene hatt flere store prosjekter som i dag blir videreutviklet på vegne av kunder. Det er her gruppens oppgave kommer inn. Hos Goodtech har vi hatt to veiledere: Harald Pedersen og Øystein Myhre. Harald Pedersen har vært prosjektansvarlig 4

9 Presentasjon for FôrIt CDS, mens Øystein Myhre har vært kodeveileder og har hjulpet gruppen under arbeidet med utviklingen av applikasjonen. 2.3 EWOS Ewos er Norges største produsent av fiskefôr. Ewos hadde i ansatte lokalisert over 5 land: Skottland, Norge, Sverige, Canada og Vietnam. 96 % av alt produsert fiskefôr er laksefôr Fabrikker i Norge EWOS har tre fabrikker i Norge som er lokalisert i Florø (Sogn og Fjordane), Halsa (Nordland) og Bergneset (Troms). Hver enkelt fabrikk leverer ut sitt ved bruk av befraktere til fiskeoppdrettere som har ventende ordreleveranser med. Hvert enkelt fabrikk har sine leveranseområder som totalt dekker store deler av norskekysten. Leveranseområdene er som følger: EWOS Florø - Dekker leveringsområdet fra Rogaland i sør til Hitra i nord EWOS Halsa - Dekker leveringsområdet fra Hitra og Frøya i sør til Namsos og Lofoten i nord EWOS Bergneset - Dekker leveringsområdet fra Lofoten og Vesterålen i sør til Hammerfest i nord EWOS er kunde i dette prosjektet og det er de som FôrIt CDS skal være utviklet til. I første omgang vil FôrIt CDS være rettet mot den norske delen til EWOS gruppen. 2.4 Høgskolen i Oslo og Akershus Høgskolen i Oslo er mottager av hovedprosjektoppgaven vår. På Høgskolen i Oslo har vi hatt Eva Hadler Vihovde som veileder gjennom prosjektarbeidet. Hun har hjulpet oss med å holde oss innenfor rammekravene som vårt hovedprosjekt omfatter. Hun har hele veien vært til stede under prosjektarbeidet, og har evaluert både produkt og dokumentasjon. 5

10 Presentasjon Figur Viser aktørene og hvilken rolle de har hatt i prosjektet. 3 Bakgrunn I dette kapittelet skal vi skrive om bakgrunnen til applikasjonen og hvorfor det var behov for FôrIt CDS 3.1 FôrIt og FôrIt CDS Goodtech har over flere år hatt et større prosjekt som går ut på å lage et MES system for bestilling, levering og produksjon av fiskefôr for firmaet Ewos. I den forbindelse ble det laget en stort dataprogram som gjør det mulig å administrere alt fra kjøp, bestillinger, produksjon, leveranser og sporing av fiskefôr. Dette programmet heter FôrIt og er i dag brukt på EWOS sine tre fabrikker i Norge. FôrIt er et omfattende program som kan følge fiskefôret fra fabrikken, over på skipet som frakter foret, og frem til det havner hos oppdretter. Det er svært mange aktører som skal bruke denne applikasjonen, og som tar del i den daglige driften. Vi skal forholde oss til kundesiden, de som mottar produktene. 6

11 Presentasjon Forskjell på storkunde og oppdretter Det er en viktig forskjell å påpeke angående brukerne av FôrIt. En storkunde er en person som er ansvarlig for å ha oversikt over bestillingene til ulike oppdrettere. En storkunde kan være ansvarlig for svært mange oppdrett, og dette er personen som også gjør bestillinger av fiskefôret på vegne av oppdretterne. Når en bestilling blir utført, blir den sendt til fabrikken og det blir bestemt hvilket skip som skal frakte foret til oppdretter Ordre Eksempelvis kan det være en bestilling på 100 tonn fiskefôr til en oppdretter i Geirangerfjorden. For å få levert 100 tonn fiskefôr er det mange aspekter en må ta hensyn til. Det viktigste hensynet er plassbehov og eventuelle mangler. Hvis det er for mange bestillinger og for få båter, kan det være at oppdretteren faktisk får være mindre enn det han faktisk bestilte. Dette vil igjen logges slik at oppdretteren kan få mer enn det vedkommende bestiller på sin neste ordre. Hver gang det blir gjort en bestilling opprettes det en ordre. Ordren igjen består av ordrelinjer som er spesifikke produkter med gitte mengder. Disse mengdene er enten oppgitt i bulk eller sekk. Bulk vil si en større bestilling hvor varen samles i en silo på befrakteren. Siloene leveres ofte som flere tonn, mens en sekk kan inneholde opp mot 500 liter fôr Sporingssystemer I FôrIt-systemet er det også planlagt å implementere en løsning for sporing av befrakterne som leverer fiskefôret til oppdretterne. I båtene er det en GPS sender som jevnlig skal oppdatere sine koordinater til FôrIt databasen. En bruker av FôrIt vil derfor kunne se hvor båten befinner seg i det øyeblikket. Hvis en oppdretter skal kunne spore sin bestilling av må han ringe til storkunden som kan få sjekket hvor båten er på vei, og hvor mye fiskefôr han har med seg til oppdretteren. Per dags dato har dette vært den eneste muligheten oppdretteren har hatt for å sjekke sine bestillinger. 7

12 Presentasjon 3.2 Mål For mer detaljer om krav, se i den vedlagte kravspesifikasjonen bakerst i sluttrapporten. Målet med prosjektet har vært og utvikle et produkt som tilfredsstiller krav og ønsker som er satt av EWOS og Goodtech. Applikasjonen skal være enklest mulig å sette i produksjon, og produktet skal være komplett. Alle moduler i applikasjonen skal testes, revideres og utbedres gjennom hele prosjektarbeidet. Før vi startet med prosjektarbeidet, satte vi oss ned og planla hvordan prosjektet skulle utformes i detalj. Vi planla hvilket tidsrom de ulike modulene skulle utvikles i, og når de skulle være ferdig. Ved å følge denne planen har vi klart og levere et produkt til avtalt til av god kvalitet som ivaretar kravene satt i kravspesifikasjonen. 3.3 Produktet Figur 3.1 Brukergrensesnittet til FôrIt CDS FôrIt CDS er en webapplikasjon optimalisert for mobile enheter som smarttelefoner og nettbrett. Webapplikasjonen vil bli brukt av kunder av den store fiskefôrprodusenten EWOS. FôrIt CDS er laget som en mobil applikasjon basert på en speiling av en allerede eksisterende desktopversjon av webapplikasjonen kalt FôrIt. Etter å ha logget inn i den nye applikasjonen 8

13 Presentasjon kan brukerne blant annet få rask tilgang til detaljer om ordren, se hvor lenge det er til ordren ankommer leveringsadressen og følge med på hvor befrakteren med fôret befinner seg på et kart. Applikasjonen viser bare kommende ordre som ikke har ankommet leveringsadressen enda. Det er også mulighet for å endre språk fra norsk til engelsk. Flere detaljer om applikasjonens funksjoner kommer under produktdokumentasjonens kapittel Applikasjonens funksjoner. Figur Figur som viser lagdelingen til FôrIt CDS 9

14 HØGSKOLEN I OSLO OG AKERSHUS FôrIt CDS Produktdokumentasjon Stian Strøm Anderssen, Mikkel Sannes Nylend og Shahariar Kabir Bhuiyan Gruppe

15 Produktdokumentasjon Forord Produktdokumentasjonen er en beskrivelse av webapplikasjonen FôrIt CDS. Den første delen av beskrivelsen gir leseren et innblikk i hva applikasjonen er og hvordan den fungerer for en bruker. Denne delen er ikke alt for teknisk, men er til for å få et innblikk i hvordan brukergrensesnittet fungerer med funksjonene. Videre går produktrapporten mer og mer i teknisk detalj om hvordan applikasjonen er bygget opp og kodet. Derfor er produktdokumentasjonen skrevet for lesere med erfaring innen systemutvikling og bør helst kunne grunnleggende Java. Det er også en stor fordel å ha kjennskap til andre kjente programmeringsspråk som CSS, XML og HTML. Beskrivelsen er laget for at leser skal få en oversikt over FôrIt CDS. Leser skal ved hjelp av dette dokumentet ha mulighet til å videreutvikle og vedlikeholde applikasjonen. Siden dokumentet inneholder svært tekniske begreper finnes det fotnoter på hver side og ordforklaringer som ligger helt til slutt av hele sluttrapporten. 1

16 Produktdokumentasjon Innholdsfortegnelse Forord...1 Innholdsfortegnelse Brukerdokumentasjon Bruk av applikasjonen Innloggingsskjerm Hjem Detaljer Se på kart Meny Profil Informasjon Logg ut Feilmeldinger Kodestandard og verktøy Applikasjonens funksjoner Innlogging Hurtigvisning av alle ordrene Detaljer for hver ordre Sporing av hver ordre på kart Bytte språk Informasjon om EWOS, Goodtech og applikasjonen Logge ut Programmets oppbygning Moduler Parent Server Common Client Standalone Hovedoppbygning

17 Produktdokumentasjon 5.1 Database Webservice Klient Servere Klasseforklaringer Hovedklasser Modellklasser Views og components Kobling til webservice Andre Teknisk beskrivelse av applikasjon Innloggingsfunksjon Sessions Views og komponenter Accordion Lyttere Visning av bilder og ikoner CSS Kommunikasjon med webservice Link fra ressursfil Konvertering til Java objekter Kart Språk Feilhåndtering og logging Feilhåndtering Tilbakemeldinger til bruker Logging Resterende arbeid

18 Produktdokumentasjon 1 Brukerdokumentasjon Dette kapittelet beskriver hvordan en kan bruke og teste applikasjonen. Det viser de forskjellige vinduene med en kort beskrivelse til hvert av de. Dette vil gi leser et kort innblikk i hva applikasjonen gjør og hvordan den fungerer. 1.1 Bruk av applikasjonen Anbefalte nettlesere for bruk av applikasjonen er Google Chrome (alle OS) og Safari for iphone. Windows Phone sin Internet Explorer fungerer også. Vi har opplevd at Firefox er noe mindre responsiv, men fortsatt fullt brukelig Innloggingsskjerm Det første skjermbildet en bruker møter er en innloggingsskjerm som vist på figur 1.1. Denne er veldig enkel, og tilbyr brukeren å taste inn et brukernavn og et passord. En bruker har muligheten til å endre språk til engelsk ved innloggingsskjermen. Ved førstegangsbruk vil applikasjonen lastes inn på norsk. I dette tilfelle kan man trykke på det britiske flagget øverst i høyre hjørne for å endre språk til engelsk. Omvendt kan man trykke på det norske flagget for å endre språket til norsk. Figur 1.2 viser innloggingsskjermen på engelsk og hvor man må trykke for å endre språk til norsk. 4

19 Produktdokumentasjon Figur Innloggingsskjermen Figur 1.2 Innloggingsskjerm engelsk Hjem Bruker blir sendt videre til hjemskjermen hvis korrekt brukernavn og passord er tastet inn. Her vil bruker kunne se en liste over innkommende ordre. Hver ordre er beskrevet med et ordrenummer, status på ordre og en leveringsadresse. Ved å trykke på Detaljer knappen kan bruker se en mer detaljert beskrivelse av sin ordre. Man kan også trykke på boksen som vist på figur 1.3. Hvis bruker ønsker å spore sin ordre gjøres det ved å trykke på Se på kart knappen. 5

20 Produktdokumentasjon Figur 1.3 Hjemskjermen. Hver B Detaljer Bildet under viser skjermbildet for Detaljer. Her vises en mer detaljert oversikt over en ordre med blant annet ordrelinjer. Ønsker bruker å gå tilbake til hjem-skjermen, kan man trykke på tilbakeknappen øverst til venstre som vist på figur 1.4, tilbakeknappen til en browser eller en fysisk tilbakeknapp på din mobiltelefon. 6

21 Produktdokumentasjon Figur 1.4 Detaljer. Rød pil viser tilbakeknappen Se på kart Bildet under viser skjermbildet for Se på kart. Kartet har to markører. Den rød, runde sirkelen med en oransje dott i sentrum illustrerer befrakteren, mens det røde flagget illustrerer leveringsposisjonen til ordren. Ved å klikke på disse markørene kan man få en liten detaljert oversikt over enten bortfrakter eller leveringsadresse, som vist på figur 1.6. Har en bruker gått seg vill i kartet kan man trykke på knappen øverst i høyre hjørne for å zoome tilbake til der man startet. Figur 1.5 illustrerer dette. For å gå tilbake til hjemskjermen trykker man på tilbakeknappen øverst til venstre, tilbakeknappen til en browser eller en fysisk tilbakeknapp på din mobiltelefon. 7

22 Produktdokumentasjon Figur 1.5 Kart. Rød pil viser knappen som tar deg med tilbake til start om du har gått deg vill. Figur 1.6 Popupvinduet som dukker opp hvis en markør trykkes på Meny Øverst i venstre hjørne i hjemskjermen er det en menyknapp. Klikker man på denne dukker det opp en meny med fire knapper. Hver av knappene vil navigere deg til det emnet som trykkes på. Legg merke til at man ikke kan klikke på det emnet man allerede er i. 8

23 Produktdokumentasjon Figur Den rød pil viser hvor menyknappen ligger. Figur 1.8 Et skjermbilde av menyen Profil Ved å trykke på Profil i menyen blir man sendt videre til profilskjermen, som vist på figur 1.9. Her kan bruker se flåtenummeret og kundenummeret til innlogget bruker. I profilen kan bruker endre språk om det er ønskelig. Legg merke til at knappen for det språket som brukes ikke kan klikkes på. 9

24 Produktdokumentasjon Figur 1.9 Profil. Det norske flagget ved språk illustrerer at språket norsk er valgt og kan ikke klikkes på Informasjon Ved å trykke på Om i menyen navigeres man til om-skjermen. Her kan bruker lese litt om applikasjonen, om EWOS, eller om Goodtech. Som standard åpnes Om EWOS fanen. 10

25 Produktdokumentasjon Figur 1.10 Om EWOS Figur 1.11 Om applikasjonen. En kan trykke på en av de to røde pilene for å lese om ønsket emne Logg ut Hvis bruker ønsker å logge ut kan bruker trykke på Logg ut i menyen. 1.2 Feilmeldinger Fire mulige feil kan oppstå ved bruk av applikasjonen. Den første er når bruker ikke får tilgang til applikasjonen. Dette kan skyldes at serveren hvor applikasjonen ligger nede. Ved en slik tilfelle må bruker vente til serveren er oppe og går igjen. Dersom bruker har glemt å fylle inn et felt, eller om en bruker har skrevet inn feil informasjon, vil det dukke opp en rød tekst hvor det står Feil brukernavn eller passord!, som vist på figur Sørg for å fylle inn nødvendige felter med korrekt informasjon. 11

26 Produktdokumentasjon Ved noen tilfeller kan informasjon du skriver inn være riktig, men likevel ikke få logget inn. Det skyldes at serveren applikasjonen kommuniserer med er ute av drift. Utviklerne får beskjed om dette fortløpende. Figur 1.12 Feilmelding ved ugyldig informasjon Figur 1.13 Feilmelding hvis server er nede Den fjerde feilmeldingen bruker kan få er illustrert i figur En slik feil skyldes logikk-feil i programkoden. Når feilen oppstår, rapporteres det til utviklerne øyeblikkelig, og bruker må vente tålmodig til feilen blir rettet på. 12

27 Produktdokumentasjon Figur 1.14 Errorview som vises når en uventet feil oppstår 2 Kodestandard og verktøy For at applikasjonen skal være enklest mulig å videreutvikle og drifte for Goodtech sine ansatte, ønsket de at vi fulgte deres standarder for Java-koding. Standarden Goodtech følger er hovedsakelig Geosoft sine standarder. Goodtech sin standard har implementert kun noen få avvik fra Geosoft sin standard. Dette gjelder blant annet for kommentarer som skal skrives på norsk. Det vil også si at all javadoc skal skrives på norsk. 13

28 Produktdokumentasjon Hovedspråket som ble brukt under utvikling av FôrIt CDS er Java 7. Som et rammeverk rundt Java har gruppen brukt Vaadin Touchkit som er et webrammeverk som gjør koding av webapplikasjoner for mobile enheter lettere. Når prosjektet skal kompileres blir det brukt byggeverktøyet Maven for å kompilere prosjektet. Maven er et rammeverk som kompilerer og bygger applikasjoner. Editeringsverktøy brukt for å skrive kode er Eclipse. Gruppen valgt Eclipse fordi det støtter de fleste filformater og det var det verktøyet gruppen var kjent med fra før. 3 Applikasjonens funksjoner Kapittelet utdyper nærmere om hva applikasjonen kan gjøre. Funksjonene blir beskrevet med få tekniske begreper slik at de fleste lesere uten IT-kunnskap kan henge med. Etter å ha lest dette kapittelet vil leseren ha fått en oversikt over hovedfunksjonene til FôrIt CDS. 3.1 Innlogging Når en bruker går inn på webapplikasjonen for første gang kommer kunden til innloggingsskjermen (figur 1.1). Her vil brukeren får se to tekstfelter, en for brukernavn og en for passord. Det vil også være en knapp for å kunne logge seg inn. Når en skriver inn brukernavn og passord kan en trykke enter eller trykke på knappen for å logge seg inn. Er brukernavnet og passordet godkjent vil en bli sendt videre til hjemskjermen, hvis ikke vil brukeren få en enkel tilbakemelding om at det var feil brukernavn eller passord (2.12). Ved ugyldig innsending av brukernavn og passord, vil passordfeltet bli blanket ut og brukernavnfeltet bli satt i fokus. Siden de fleste browsere støtter lagring av forms for vanlige HTML-sider vil også brukeren få valget om å kunne lagre brukernavnet og passordet i browseren. Dette gjør at en slipper å skrive inn brukernavn og passord hver gang en skal sjekke applikasjonen. Brukernavnet og passordet vil kunden få tilsendt av EWOS. Derfor er det heller ikke nødvendig å ha noen registreringsfunksjon innebygget i applikasjonen. 14

29 Produktdokumentasjon 3.2 Hurtigvisning av alle ordrene Etter at brukeren har fått logget inn vil brukeren som sagt bli videresendt til hjemskjermen. Her vil en kunne se alle de bestilte ordrene i et enkelt oppsett hvor hver ordre har en slags bolk med den viktigste informasjonen (figur 1.3). Dette vil typisk være en status for om den er registrert, om den laster eller om ordren er på vei. En vil også få vite estimert ankomsttid til leveringsadressen. Hver bolk har også to knapper. Den ene knappen sender det til en side med kart hvor en kan spore ordren på et kart. Den andre fører videre til en side med flere detaljer for den spesifike ordren. 3.3 Detaljer for hver ordre Denne siden viser hovedsakelig all nyttig informasjon om en ordre. Det vil si at når en trykker seg videre ved hjelp av detaljknappen på en av bolkene på hjemskjermen vil en komme hit (figur 1.4). Brukeren får vite hvilken befrakter som skal frakte ordren, hvor den skal leveres og hvilken status ordren har. Avhengig av om ordren har status registrert, lastet eller på vei, får en også et relevant tidspunkt. Dette kan enten være forventet avgang eller forventet ankomst. Under hovedinformasjonen for ordren kan en finne ordrelinjene. Dette er informasjon om hvilke varer som gjelder for den ordren, hvor mye som er bestilt av den varen. Hvis ordren ikke har blitt lastet enda vises det også hva som er planlagt å bli lastet for den varen. Hvis ordren har blitt lastet ombord på befrakteren vises hvor mye som ble faktisk ble lastet av den varen. Siden befrakterne ikke alltid har plass eller har for mye plass får ikke kunden alltid den mengden av fôr som er bestilt. Under alle ordrelinjene vil en også få en sum som gjelder for hele ordren. 3.4 Sporing av hver ordre på kart Når en har trykket på kartknappen for en av ordrene på hjemskjermen vil en videresendes til en side med kart (figur 1.5). På kartet vil en kunne se hvor befrakteren med ordren befinner seg akkurat nå. Det vises også et annet punkt for leveringsadressen til brukeren. I det en laster siden vil kartet vil automatisk fokusere inn slik at de to punktene blir godt synlig på skjermen. Brukeren har også ha en knapp øverst i høyre hjørne for å kunne manuelt fokusere inn til de to punktene hvis en har scrollet eller zoomet seg ut av fokus. Ved et klikk 15

30 Produktdokumentasjon på en av punktene vil en informasjonsboks poppe opp med informasjon om enten leveringsadressen eller om befrakteren. 3.5 Bytte språk Brukeren har også mulighet for å endre språket mellom norsk og engelsk i applikasjonen. Dette kan gjøres på innloggings- og profilvinduet. I innloggingsskjermen kan en trykke på flagget øverst i høyre hjørne. Språket vil endres til det flagget en trykket på. Det vil si at hvis det er et engelsk flagg som vises, bytter en fra norsk til engelsk ved å trykke på det. Under profilvinduet kan en se under innstillinger en mulighet for å velge det språket som ikke er valgt fra før (figur 1.9). Språkvalget vil bli husket til neste gang brukeren kommer til applikasjonen med den samme browseren. 3.6 Informasjon om EWOS, Goodtech og applikasjonen Webapplikasjonen har også et eget vindu for å vise statisk informasjon om bedriftene EWOS og Goodtech, samt litt generelt om applikasjonen. 3.7 Logge ut Brukeren har også mulighet til å logge ut ved å trykke logg ut i menyen. 4 Programmets oppbygning I denne seksjonen skal vi se nærmere på hvordan applikasjonen er bygd opp. 4.1 Moduler Siden FôrIt CDS er delt opp i flere moduler med forskjellige funksjoner. Hver modul inneholder en del av funksjonen til applikasjonen. For eksempel gir det oss muligheten å legge webservicen på et annet sted enn på klientlaget. Dette gir større sikkerhet og et mer fleksibelt sluttprodukt. 16

31 Produktdokumentasjon 4.2 Parent Figur 4.1 Viser modulene i programmet Modulen som er en samlet modul av alle de andre modulene for FôrIt CDS. 4.3 Server Modulen som inneholder programkode for webservicen. Bruker modellen fra modulen Common til å lage nyttige Java-objekter. 4.4 Common En modul som har tre klasser som definerer en modell på det som hentes fra databasen. 4.5 Client Modulen inneholder brukergrensesnittet, logikken for å hente data fra webservice og objektdefinisjoner for en bruker, ordre, ordrelinje og en befrakter. Alle ressurser som blir brukt av brukeren (alt fra bilder, ikoner og stilark) lagres også under denne modulen. Den inneholder også alle enhetstestene for klientdelen. 4.6 Standalone Det finnes to standalonemoduler. Den ene modulen som kalles kun Standalone lager en jarfil for klientdelen ved kompilering av parent-modulen. Jar-filen kan legges rett på serveren 17

32 Produktdokumentasjon og applikasjonen kan kjøres. Den andre standalonemodulen kalles Standalone-server og gjør det samme for webservicedelen av applikasjonen. 5 Hovedoppbygning Figur 5.1 Hovedoppbygning på hvordan applikasjonen er satt opp. 5.1 Database Databasen som FôrIt CDS baserer seg på er den samme som den ikke-mobile løsningen bruker. Siden denne databasen er svært stor og innviklet i forhold til hva som er nyttig 18

33 Produktdokumentasjon informasjon for mobilapplikasjonen blir bare små deler av denne databasen brukt. Databasen bruker standard SQL-spørringer for å hente data. Per dags dato er det ikke mulighet for mobilapplikasjonen å skrive til database, altså er kun lesing tillatt. 5.2 Webservice Webservicen er laget mellom klienten og databasen. Webservicen som blir brukt er av typen REST. REST står for Representational State Transfer og er en type standard for å kode webservicer. Webservicen henter data fra databasen med tre ferdiglagde sprørringer. De tre spørringene henter følgende: De siste ordrene for en kunde Alle salgsdetaljer for en bestemt ordre Alle befraktere Webservicen krever en innlogging før en kan hente data fra databasen. Dette gjøres når brukeren logger seg inn i applikasjonen. Dataen som returneres fra webservicen blir sendt som JSON-arrays og JSON-objekter. 5.3 Klient Klientdelen er den delen av applikasjonen som kjører lokalt i brukeren sin browser. Den viser views, tar imot brukerinput og bestemmer hva som skal skje med den inputen. Trykker brukeren på en knapp, registreres dette og koden til lytteren for knappen utføres. Når brukeren logger seg inn, kobler klientdelen seg på webservicen og henter JSON-objektene, konverterer JSON-objektene til definerte Java-objekter og sender nyttig informasjon ut til brukeren. Klientdelen av applikasjonen kontrollerer også session- og cookie-bruken ved pålogging, utlogging og valg av språk. Hovedoppgavene til klientdelen: Vise views Ta imot brukerinput Hente JSON-objekter fra webservice Konvertere JSON-objektene fra webservice til Java-objekter Vise relevant informasjon basert på Java-objektene 19

34 Produktdokumentasjon 5.4 Servere Prosjektet vil til slutt ligge på EWOS sine servere sammen med den eksisterende skrivebordsløsningen for FôrIt. Applikasjonen vil ta opp to porter, en for klientdelen og en for webservicen. Databasen eksisterer allerede på fungerende servere. Per dags dato har applikasjonen blitt testet i et testmiljø hos Goodtech sine interne servere som inneholder en liten kopi av EWOS sine databaser satt opp med webservicen og klientdelen. Mer om testing kommer under Testrapporten. 6 Klasseforklaringer Vi skal nå ta for oss klasseoppsettet for hovedmodulen, Client, som vi har jobbet med. Klasseoppsettet i modulen er bygget opp på MVC-prinsippet, Model View Controller. Dette prinsippet baserer seg på Views (skjermer) som er separert fra Model (modellen) med en Controller (kontroller). Pakkene er delt inn i følgende struktur: no.goodtech.foritcds.client no.goodtech.foritcds.client.model no.goodtech.foritcds.client.ui no.goodtech.foritcds.client.ui.language no.goodtech.foritcds.client.components no.goodtech.foritcds.client.util Navngivningen av pakkene følger standard navngivning for Java-program for bedrifter. Dette vil si: <domenenavn>.<bedrift>.<modul>.<pakkenavn> 20

35 Produktdokumentasjon Figur 6.1 Oversikt over hvordan pakkene er satt opp. 6.1 Hovedklasser Vi har en hovedklasse i Client-modulen. Den kalles ForitCDSUI og er en slags overklasse for applikasjonen. Den generer og bytter Views, holder kontroll på hvilken URL som blir vist i adressebaren og den setter hvilken CSS-style som gjelder. ForitCDSUI inneholder derfor et objekt av NavigationManager som bestemmer hvilket vindu som vises til enhver tid. Den holder også alle standarder for modulen. Som for eksempel bestemmer den standarder for datoformat, hvilket tekstformat som gjelder, applikasjonsnavn og sessionnavn. Vi følger det Språkrådets standard for visning av datoer: DD.MM.YYY. Klassen inneholder også et objekt av typen DefaultErrorHandler som finnes i Vaadin sine pakker. Dette objekter bestemmer hva som skal skje når en uventet RuntimeException oppstår. Mer om feilhåndtering kommer under kapittel 8 Feilhåndtering og logging. 21

36 Produktdokumentasjon 6.2 Modellklasser Figur 6.2 Sammensetningen av modellene og relasjonene mellom de. Modellklassene ligger under pakken model, og er et oppsett på hvordan applikasjonen deler opp dataen fra webservice og legger det ryddig i objekter. Klassene inneholder stort sett datasett som definerer objektet og get- og set-metoder. Modellklasser er følgende klasser: Fleet Freighter Order SalesDetails public class Freighter { private List<Order> orders; private int freighterid; private int factoryid; private String freightername; private String freighterno; private double longitude; private double latitude; public void setfreighterid(int freighterid) { this.freighterid = freighterid; 22

37 Produktdokumentasjon } } public int getfreighterid() { return freighterid; }... Figur 6.3 Eksempel på hvordan en modellklasse ser ut. Fleet er modellen på hva en flåte skal være. En flåte er det som definerer en bruker. Det viktigste for denne klassen er selvfølgelig en id og et passord, som blir brukt for å logge inn. Den inneholder også en liste med ordre, kundenummer og et leveringsnavn. Freighter er en modell for hva objektet befrakter inneholder. Objektet inneholder listen med ordre som befinner seg på skipet. Det har også to variable med datatyper som double som definerer latitude og longitude for hvor befrakteren befinner seg i verden. For å identifisere hver befrakter kalles det på hvilken fabrikkid den tilhører, samt hvilken id den selve befrakteren har. Klassen har også mindre viktige variabler som et nummer og navn. Order er datatypen for hver ordre. Den inneholder en liste av ordrelinjer (salesdetails). Hver ordre er koblet opp mot en flåte og en befrakter. Order har derfor en flåteid og befrakterid. Order bruker også latitud og longitude på samme måte som Freighter-klassen. For å identifisere hver ordre har den også en egen id. Andre data som definerer klassen er: Ordrenummer Flåtenummer En status som forteller hvilken tilstand ordren er i (registrert, laster eller på vei). Tre heltallsvariable for bestilt mengde, det som er planlagt å bli lastet ombord på befrakteren og hvor mye som faktisk ble lastet ombord. En dato for estimert ankomst Leveringsadresse En dato for planlagt avgang for ordren En dato for når ordren ble ferdig lastet ombord på befrakteren 23

38 Produktdokumentasjon Et leveranseadressenummer og et leveranseadressenavn SalesDetails er definisjonen på en ordrelinje. Hver ordre kan ha mange ordrelinjer. Hver ordrelinje består av en id, en varebeskrivelse, mengden som er bestilt, planlagt og faktisk lastet av varen. 6.3 Views og components Alle views som lages extender det som Vaadin kaller NavigationView. Det lager et vindu med en banner på toppen av skjermen og et område hvor du kan legge komponenter med forskjellige utforminger. En annen ting som er felles for alle views er en variabel som er av typen WSBusinessLogic. Dette gir muligheten for hvert view å koble seg til webservice og hente data fra databasen, for deretter å skrive dataen ut på skjermen. Hvis det oppstår en uventet feil er det kritisk at feilen logges slik at driftere vil kunne rette på feilen. Hver vindusklasse har derfor også en logge-variabel som skriver den uventede feilen til en loggfil. Mer om logging kommer under kapittel 8 Feilhåndtering og logging. Hvis feilen er så kritisk at applikasjonen ikke kan kjøre videre, blir brukeren omdirigert til et ErrorView (se figur 1.14) som er en statisk side som logger feilen og viser kunden at et problem har oppstått. Ressurser som bilder og ikoner hentes ved hjelp av ThemeResource. Flere av komponentene som legges til i vinduene er endret på i forhold til hva som er standardkomponenter fra Vaadin. Derfor har vi pakken som heter components. Den inneholder ForitMap som henter tiles til kartet fra MapBox. ForitMap bytter også kart mellom dagmodus og nattmodus for å gjøre kartet mer synlig for brukere som bruker applikasjonen utendørs. Pakken inneholder også to klasser som redefinerer menyknappen som viser og gjemmer menyen, og selve menypanelet som kommer opp ved trykk på menyknappen. Menyknappen inneholder en Animator som gir menypanelet en fin innrulling ved åpning av panelet. Siden Vaadin sin Touchkit-pakke ikke fullt ut støtter Windows Phone 8 sin standardbrowser, har knappen også en test som gjør at menyen også fungerer for de som bruker Windows Phone. 24

39 Produktdokumentasjon 6.4 Kobling til webservice Mellom alle views og webservicen har vi to klasser. Vi har en klasse som heter WSBusinessLogic som er en slags Controller hvis en ser på MVC-modellen. Den henter data fra den andre klassen, WebServiceConverter, som er koblepunktet til webservicen. Alle views kobles til WSBusinessLogic som videre kobles til WebSreviceConverter som kobler seg på webservice ved gyldig påloggingsinformasjon. WSBusinessLogic blir derfor et slags mellomledd mellom views og logikk, og kan tolkes som en controller i designmønsteret MVC. Tilkoblingsklassen WebserviceConverter tar ved innlogging imot brukernavnet og passordet og logger på webservice hvis informasjonen er gyldig. Etter en gyldig pålogging kan det hentes informasjon til views fra webservice sine tre URL-tilkoblinger. JSONobjektene som blir hentet fra webservice blir konvertert til objekter fra modellklassene, og videre blir dataen brukt til å bli skrevet ut til views. 6.5 Andre Av andre klasser har vi de tre språkklassene som ligger i pakken ui.language. Her er det en hovedklasse som inneholder navn på alle språklabels. Pakken har også to klasser som inneholder språkforskjellene i en lik array. Når et view har en komponent som krever en språkendring kalles den spesifike varibelen fra denne hovedklassen, og henter riktig tekst fra en av de to språkklassene. Disse tre klassene kalles ForitBundle (hovedklassen), ForitBundle_no (norsk språkklasse) og ForitBundle_en (engelsk språkklasse). Det ligger også en språklogikklasse under pakken util som kalles LanguageLogic. Denne holder kontroll på hvilket språk som er valgt til enhver tid. Dette gjøres ved sletting, lagring og oppdatering av cookies for en string som enten er NO eller US. Ved eventuelle nye språk vil det bare være å legge til en ny språkklasse med riktig tekst på variablene, og så legge til riktig språkidentitetsstring under LanguageLogic. 25

40 Produktdokumentasjon 7 Teknisk beskrivelse av applikasjon Kapittelet går inn i applikasjonens funksjoner og beskriver hvordan disse er bygget opp ved hjelp av kodeeksempler og figurer. Leser burde ha kompetanse innen IT og systemutvikling, og ha god kjennskap til Java. 7.1 Innloggingsfunksjon Innloggingsfunksjonen på LoginView starter med et objekt av typen LoginForm. Denne klassen genererer en HTML-formtagg for å kunne logg inn på en sikker måte. Den lager to tekstfelter for brukernavn og passord og en submit-knapp for å klikke Logg inn. En kan enten logge inn ved å trykke enter på tastaturet eller ved å klikke på logg inn knappen. Klikkfunksjonaliteten er implementert ved å legge til en lytter til LoginForm-objektet. loginform.addlistener(new LoginListener() { public void onlogin(loginevent event) { String username = event.getloginparameter("username"); String password = event.getloginparameter("password"); boolean isvalid = false, error = false; if (!username.equals("") &&!password.equals("")) { try { isvalid = bll.login(username, password); } catch (Exception ex) { error = true; errorlabel.setcaption("får ikke koblet til server. Prøv på nytt senere."); LOGGER.error("Får ikke kontakt med webservice: ", ex); } } if (isvalid) { // Går til HomeView eller error bll.setview(new HomeView()); } else if (error == false) { 26

41 Produktdokumentasjon errorlabel.setcaption(bll.getbundle().getstring(foritbundle.loginerrorlabel )); } } }); Figur 7.1 Et eksempel på lytteren som er lagt til for å logge inn. I lytteren blir brukernavnet og passordet sendt videre til kontrolleren som sender dataen videre til WebserviceConverteren som spør webservice om dette er gyldig påloggingsinformasjon. Ved gyldig informasjon setter kontrolleren en session og videresender brukeren til HomeView Sessions En session Vaadin bruker VaadinService sin innebyggede metode for å kontrollere sessions. Dette brukes når brukeren logges inn eller ut. Her er et eksempel på hvordan session settes når brukeren henholdsvis logger inn og ut: VaadinService.getCurrentRequest().getWrappedSession().setAttribute(ForItCDS UI._SESSIONNAME, user); VaadinService.getCurrentRequest().getWrappedSession().setAttribute(ForItCDS UI._SESSIONNAME, null); 7.2 Views og komponenter Alle views i FôrIt CDS blir satt opp på samme måte. De bygger på Vaadins objekt kalt NavigationView. Denne klassen oppretter en banner og et tomt område under for alt innhold. Hvert NavigationView har mulighet for å legge til en overskrift i banneren ved å sette en caption. Alle komponenter som vi legger til i skjermene, som for eksempel Labels og Buttons, blir lagt til i forskjellige typer Layouts. Hver skjerm har en hovedlayout av typen 27

42 Produktdokumentasjon VerticalComponentGroup for alt innhold. Det er denne layouten som skaper den fine margen for innholdet i hvert view. Andre typer layouts som blir brukt er: VerticalLayout legger komponenter nedover i rekkefølgen en legger de til HorizontalLayout legger komponenter bortover i rekkefølgen en legger de til GridLayout en slags tabell hvor en bestemmer komponentenes posisjon med koordinater Her er et eksempel på hvordan komponenter blir lagt til i layoutene: VerticalLayout eachorderlayout = new VerticalLayout(); Label ordernolabel = new Label(bll.getBundle().getString(ForitBundle.homeOrderId) + printorder.getorderno()); eachorderlayout.addcomponent(ordernolabel); Figur 7.2 Eksempel på VerticalLayout. HorizontalLayout og VerticalComponentGroup fungerer på helt lik måte. int size = 0; if (orderlines!= null) size = orderlines.size(); // Lager GridLayout med størrelse 3, size+2 final GridLayout grid = new GridLayout(3, size + 2); //Legger til en Label i posisjon 0,0 i GridLayouten Label articleheader = new Label(bll.getBundle().getString(ForitBundle.orderdetailsTableArticle)); articleheader.setstylename(gridheader_style); grid.addcomponent(articleheader, 0, 0); grid.setcomponentalignment(articleheader, Alignment.MIDDLE_CENTER); Figur 7.3 Eksempel på GridLayout Accordion Applikasjonen har også et informasjonsview (AboutView) som inneholder en komponent som kalles Accordion. En Accordion viser sammenleggbare faner med informasjon, og de er svært effektive for å vise en større mengde data på en skjerm med små dimensjoner. En Accordion blir satt opp med flere Tabs som inneholder den informasjonen som skal vises for den fanen. Accordions fungerer som et trekkspill hvor en bare kan se informasjonen i en fane om gangen. Her er et eksempel på hvordan en tab blir lagt til: 28

43 Produktdokumentasjon // Accordion er området som inneholder de ulike Verticallayoutene. Accordion accordion = new Accordion(); final VerticalLayout aboutewoslayout = new VerticalLayout(); aboutewoslayout.setid("aboutewoslayout"); Image EWOSimage = new Image(null, EWOS_logo); aboutewoslayout.addcomponent(ewosimage); aboutewoslabel = new Label(bll.getBundle().getString(ForitBundle.aboutEWOSInformation)); aboutewoslayout.addcomponent(aboutewoslabel); // Legger til VerticalLayout til en Tab som legges til i Accordion. // arrow_up er et ikon på om den tabben er valgt eller ikke. Tab aboutewostab = accordion.addtab(aboutewoslayout,bll.getbundle().getstring(foritbundle.abou tewos), arrow_up); Lyttere Alle mulige aksjoner brukeren kan utføre krever lyttere. Noen av komponentene har allerede innebygget lyttere. Dette gjelder blant annet tekstfelter og større views med scrolling. For alle andre komponenter som skal være klikkbare kreves det lyttere. Her er et eksempel på hvordan en knapp fra HomeView får lagt til en Listener som lytter etter når brukeren klikker på den: mapbutton.addclicklistener(new ClickListener() public void buttonclick(clickevent event) { bll.setview(new MapView(printOrder)); } }); Visning av bilder og ikoner For å gjøre applikasjonen mer intuitiv, penere og få vist all informasjon vi ønsker kreves det en form for visning av bilder og ikoner. Alle bilder og ikoner blir hentet fra av en Resourcemappe som ligger under Client-modulen. De blir hentet ved hjelp av ThemeResource. Dette 29

44 Produktdokumentasjon er en Vaadin-komponent som henter riktig resurs fra Resource-mappen ved hjelp av filplasseringen til bildet. Her er et eksempel på hvordan filer hentes fra mappen images under ressursmappen: EWOS_logo = new ThemeResource("images/EWOS_logo.jpg"); goodtech_logo = new ThemeResource("images/goodtech_logo.png"); Bilder blir lagt til ved hjelp av Vaadins Image-objekt. Image-objektet tar imot ThemeResource-objektet og så er det bare å legge til bildet som hvilken som helst annen komponent. Ikoner blir bare lagt til med Vaadin-komponentenes innebyggede funksjon som støtter ikoner inne i hver komponent. // Legger til bilde final VerticalLayout aboutewoslayout = new VerticalLayout(); aboutewoslayout.setid("aboutewoslayout"); Image EWOSimage = new Image(null, EWOS_logo); aboutewoslayout.addcomponent(ewosimage); // Legger til ikon til en knapp private final ThemeResource homeresource = new ThemeResource("images/menu_home.png"); homenavbutton.seticon(homeresource); Figur 7.4 Viser hvordan et bilde blir lagt til i en VerticalLayout og hvordan et ikon blir lagt til i en knapp på menyen CSS Siden alle views blir generert til HTML-kode er de designet med et stilark av typen Cascading Style Sheet. Dette blir lagt til for applikasjonen i klassen ForitCDSUI public class ForItCDSUI extends UI {... } Hver komponent som bli lagt til i vinduene kan få en egen styling-id. Dette gjør det enklere å definere et eget design for alle komponenter som bli lagt til. Vaadin genererer også klassenavn på alt som befinner seg i vinduene. Dette gjør at det er bare å kalle på den riktige 30

45 Produktdokumentasjon delen av vinduet du vil endre på og style den slik det etter egen vilje. Her er et utdrag fra HTML-koden som blir generert fra HomeView. <div class="v-touchkit-componentgroup-row v-touchkit-componentgroup-rownocap"> <div class="v-caption"></div><div class="v-touchkit-componentgroupcell"> <div class="v-label v-widget v-has-width" id="homeinformationlabel" style="width: 100%;">Du har 2 innkommende ordre.</div> </div> </div> Figur 7.5 Koden viser øverste del av innholdet i HomeView som beskriver hvor mange innkommende ordre brukeren har. #homeinformationlabel { text-align: center; } Figur 7.6 Dette er den veldig simple CSS-koden som tilhører den tekstbiten. De kobles sammen med iden I L 7.3 Kommunikasjon med webservice Klassen WebserviceConverter har som hovedoppgave å snakke med webservice og hente data når det er behov for det. Webservicen er av typen REST og er laget på den måten at en må logge inn med gyldig påloggingsinformasjon for så å kunne hente den dataen en ønsker fra tre forskjellige URL. Når en åpner en av URLene i nettleseren etter en godkjent innloggning får en resultatet av den spørringen som URLen representerer. Dataen som kommer fra webservicen er av typen JSON-arrays. Dette er JSON-objekter satt sammen i en array. Dataen som blir hentet gjelder for den flåten som er logget inn. Selve koblingen til webservice skjer hjelp av en hjelpe-metode kalt readjsonarrayfromurl. Denne oppretter en BufferedReader, åpner URLen til webservice og henter JSON-teksten. Teksten blir så konvertert til en JSON-array og deretter returnert som objektet JSONArray. public JSONArray readjsonfromurl(string url) throws Exception { InputStream is = new URL(url).openStream(); try { BufferedReader rd = new BufferedReader(new InputStreamReader(is, Charset.forName(ForItCDSUI._CHARSET))); String jsontext = authenticate(url); JSONArray jsonarray = new JSONArray(jsonText); 31

46 Produktdokumentasjon return jsonarray; } } catch (Exception e) { throw new Exception(); } finally { is.close(); } Figur 7.7 Eksempel på hvordan en JSONArray blir opprettet ved lesing fra webservcice. Den tar i mot URLen og leser teksten for den URLen. Teksten blir så konvertert til JSONArray og returnerert. Klassen har også metoder for å kunne logge seg på webservice og applikasjonen. Denne metoden kalles login og tar imot et brukernavn og et passord som senere blir kryptert i metoden. Metoden returnerer et Fleet-objekt fra modellen vår. Er flåteobjektet lik null er ikke passordet eller brukernavnet godkjent. Godkjennelsen vurderes ut ifra responsen metoden får fra webservice. Ved hjelp av denne if-testen testes det på om responsen er 200, altså godkjent: HttpURLConnection urlconnection; urlconnection = (HttpURLConnection) url.openconnection(); urlconnection.setrequestproperty("authorization", "Basic " + encodeduserpassword); if (urlconnection.getresponsecode()!= 200) return null; Link fra ressursfil For å gjøre applikasjonen enkel å installere på EWOS sine systemer brukes det en ressursfil med filformatet xml. Xml-filen inneholder kun en statisk URL som er adressen til webservicen. Ved installering på nye servere må denne URLen endres for å få koblet på webservicen. <?xml version="1.0"?> <URL> Figur 7.8 Eksempel på hvordan XML-filen kan se ut. Metoden readwebserviceurl tar seg av lesingen av denne URLen. Dette gjøres slik: 32

47 Produktdokumentasjon public void readwebserviceurl() throws Exception { if (ForItCDSUI._BASEPATH!= null && ForItCDSUI._BASEPATH.length() > 0) { // Lokaliserer filen String path = ForItCDSUI._BASEPATH + "/resources/webserviceconnection.xml"; File file = new File(path); DocumentBuilder dbuilder = DocumentBuilderFactory.newInstance().newDocumentBuilder(); Document doc = dbuilder.parse(file); webserviceurl = doc.getdocumentelement().gettextcontent(); } } Konvertering til Java objekter I WebserviceConverter finnes det tre hovedmetoder som henter arrays fra hjelpe-metoden readjsonfromurl. Metodene konverterer alle JSON-objektene over til relevante objekter fra modell-pakken og returnerer de som en liste eller et objekt. Disse metodene er: public List<Order> getorderslist(int locationid) Henter en liste med ordre basert på den flåten som er logget inn. Metoden får flåtens lokasjonsid inn som parameter og returnerer en liste med objektet Order fra modellen vår. public List<SalesDetails> getsalesdetailslist(order order) Henter en liste med ordrelinjer for den ordren som blir sendt som parameter. Den returnerer en liste med objektet SalesDetails fra modellen vår. public Freighter getfreighter(int freighterid, int factoryid) Siden denne metoden kun trenger et objekt leses det bare et JSON-objekt fra webservice her. Hver freighter er identifisert på en befrakterid og en fabrikkid. Disse variablene sendes inn som parametere. Metoden returnerer et Freighter-objekt fra modellen vår. public Freighter getfreighter(int freighterid, int factoryid) throws Exception { Freighter freighter; JSONObject jsonfreighterobject; 33

48 Produktdokumentasjon try { jsonfreighterobject = readjsonobjectfromurl(webserviceurl + "freighter/" + freighterid + "/v1?factoryid=" + factoryid); freighter = new Freighter(); freighter.setfactoryid(jsonfreighterobject.getint("factoryid")); freighter.setfreighterid(jsonfreighterobject.getint("id")); freighter.setfreighterno(jsonfreighterobject.getstring("freighterno")); freighter.setlatitude(jsonfreighterobject.getdouble("latitude")); freighter.setlongitude(jsonfreighterobject.getdouble("longitude")); freighter.setname(jsonfreighterobject.getstring("name")); } return freighter; } catch (Exception e) { throw new Exception(); } Figur 7.9 Metoden getfreighter() som henter et JSONObject og returnerer et Freighter-objekt fra modellpakken. 7.4 Kart Kartet som blir brukt i applikasjonen er av typen LMap. LMap er et objekt fra en dependency som finnes under Goodtech sin samling av Vaadin-framework. Objektet er hentet fra Vaadin sin leaflet-pakke som befinner seg under addon-mappen til Vaadin. Leaflet er et opensourceprosjekt som fokuserer på mobile kartløsninger. Objektet kommer med innebygde funksjoner for å behandle kart på mobile løsninger. // Fjerner alle kontroller til kartet som vi ikke ønsker å vise i kartet getlayerscontrol().remove(); // Oppdaterer punkter på kartet if (freighterpos!= null) map.removecomponent(freighterpos); if (deliverypos!= null) map.removecomponent(deliverypos); addlocations(); Figur 7.10 Eksempel på funksjoner som følger med LMap-objektet 34

49 Produktdokumentasjon FôrIt CDS har klassen ForItMap under components-pakken for å opprette kartet og de ønskede funksjonene. Denne klassen extender objektet LMap og får automatisk alle funksjoner som Leaflet tilbyr. LMap krever tiles for å få vist noe som helst. Dette er en sammensetning av utrolig mange bilder satt opp i en mappestruktur med koordinater og zomm-nivå. Siden lokale tile-sett kan bli utrolig store hentes de foreløpig fra MapBox. FôrIt CDS har også en funksjon som sjekker hva klokken er, og hvis den er mer enn klokken 20:00 vil kartet bytte tile-sett til et annet sett med mørkere farger. Klokken 06:00 igjen vil kartet bytte til normale lyse farger. Dette vil gjøre applikasjonen mer brukervennlig i og med at mange kommer til å bruke den ute i dårlig lys. if (mode.equals(_nightmode)) { tilelayer = new LTileLayer( " ); } else { tilelayer = new LTileLayer( " ); } addbaselayer(tilelayer, null); Figur 7.11 Eksempel på hvordan tiles bli hentet fra mapbox og lagt til i LMap-objektet. 7.5 Språk Applikasjonen har også en løsning for å kunne bytte språk fra norsk til engelsk. Dette ble implementert på grunn av mulige nye kunder i utlandet for EWOS og Goodtech. Språklogikken i applikasjonen bestemmes av en cookie. Hvis cookien ikke er satt blir det satt en nye en til standardspråket norsk. Cookien er av Vaadin sin egendefinerte måte for å behandle cookies på som er ved hjelp av VaadinService sine metoder. Dette behandles i LanguageLogic-klassen i util-pakken. private Cookie getcookie(string name) { Cookie[] cookies = VaadinService.getCurrentRequest().getCookies(); 35

50 Produktdokumentasjon } for (Cookie cookie : cookies) { if (name.equals(cookie.getname())) { return cookie; } } return null; public void destroycookie() { if (languagecookie!= null && country!= null) { languagecookie = new Cookie(cookieLanguageName, country); languagecookie.setmaxage(0); savecookie(); } } Figur 7.12 Eksempler på hvordan Cookies bli behandlet i applikasjonen. Etter at det bestemte språket har blitt satt henter den riktig data fra en klasse kalt ForitBundle. Denne ligger under ui.language og er en klasse som extender ListResourceBundle. Dette objektet er inneholder funksjoner for å behandle ressurser. Klassen inneholder flere statiske variabler som tilegnes en id. // HomeView public static final String homecaptiontext = generateid(); public static final String homeinformationstringnoorder = generateid(); Figur 7.13 Eksempel på hvordan hver tekstvariabel blir opprettet i ForitBundle Videre kobles det to andre klasser til denne hovedklassen som representerer hvert sitt språkvalg. Dette gjøres med at de extender ForitBundle. Hver av de to klassene inneholder samme type dobbel-array som inneholder hvilken variabel i bundle-klassen den tilhører og setningen i riktig språk som skal hentes. static final Object[][] contents_no = { // HomeView { homecaptiontext, "Velkommen " }, { homedeliveryaddress, "Leveringsadresse: " },... } 36

51 Produktdokumentasjon Figur 7.14 Eksempel på hvordan teksten lagres under ForitBundle_no. Fungerer helt likt for ForitBundle_en. 8 Feilhåndtering og logging Applikasjonen har hatt et stort fokus for å gjøre det så lett som mulig for andre aktører knyttet til prosjektet. Det betyr at med god feilhåndtering, logging og tilbakemeldinger vil det være mye enklere å installere, bruke, videreutvikle og drifte webapplikasjonen. 8.1 Feilhåndtering FôrIt CDS bruker Vaadins egendefinerte DefaultErrorHandler for å håndtere uventede RuntimeExceptions. Her har vi et eget objekt av denne klassen i vår hovedklasse, ForitCDSUI. Måten vi bestemmer hva som skal skje hvis det den uventede feilen oppstår er slik: { public void error(com.vaadin.server.errorevent event) { LOGGER.error("En feil oppstod: ", event.getthrowable()); setview(new ErrorView("")); } Denne egendefineringen skriver først feilen med en kort beskrivelse til en loggfil og så videresender den bruker til et ErrorView (se figur 1.14). Dette statiske skjermbildet er bare en side hvor bruker får informasjon om at det har oppstått en uventet feil. Hvis appen kan si noe om feilen får brukeren en kort ikke-teknisk setning om hva som kan være problemet. Applikasjonen har også flere steder hvor vi vet det kan oppstå en feil. Dette håndteres med try/catch-setninger i øverste lag. Det vil si at hvis det oppstår en feil når en prøver å koble seg til webservice (webservicelaget i figur 5.1) vil applikasjonen kaste denne feilen med en Throw helt til feilen kommer til et View hvor bruker kan få en informativ tilbakemelding og feilen kan bli logget. // Kode fra HomView try { 37

52 Produktdokumentasjon userorders = bll.getuserorders(username.getlocationid()); } catch (Exception e) { userorders = null; LOGGER.error("Får ikke hentet liste med ordre fra webservice.", e); bll.setview(new ErrorView(bll.getBundle().getString(ForitBundle.errorWebServiceOrder))); } // Kode fra WSBusinessLogic public List<Order> getuserorders(int username) throws Exception { if (username!= -1){ // Metoden getorderslist kaster en exception ved feil return wsc.getorderslist(username); // wsc --> WebserviceConverter } return null; } Figur 8.1 Eksempel på hvordan try-catch blir behandle på øverste lag for å kunne gi brukeren tilbakemeldinger og for å få logget feilen. Første utdrag er fra HomeView og det andre er metoden som kalles på som er hentet fra WSBusinessLogic. 8.2 Tilbakemeldinger til bruker Siden alle mulige feil som blir håndtert med try/catch blir utført på det øverste laget, altså views, er det lett å gi brukeren tilbakemeldinger. For eksempel vil bruker få tilbakemelding på Login-skjermen om det er feil påloggingsinformasjon eller om applikasjonen ikke får koblet seg til databasen (se figur 1.13). En annen type tilbakemelding til brukeren er hvis det er mangelfull data i databasen. Dette blir håndtert med testing på alle verdier som blir skrevet ut. Hvis det ikke finnes noen verdi for det feltet som skal bli skrevet ut, vil det bli skrevet ut en standard feilmelding avhengig av hvilket språk brukeren har valgt. Den norske standardmeldingen er: finner ikke data. Kartsiden vår krever også to koordinater. Ved mangelfull data fra databasen her vil punktet aldri vises og brukeren vil få en tilbakemelding på at enten koordinatene til bortfrakteren eller leveringsadressen ikke finnes. 38

53 Produktdokumentasjon 8.3 Logging For driftere og for utviklere som ønsker å legge til flere funksjoner til applikasjonen er det kritisk at feil som oppstår blir logget. Derfor bruker vi noe som kalles Log4j. Dette er et Javaverktøy laget for å logge hendelser for applikasjoner. I FôrIt CDS gjøres dette fra øverste nivå, altså fra views. Hver gang en bruker blir videresendt til ErrorView på grunn av en feil, blir hele StackTrace til Exception og en kort beskrivelse av feilen sendt via et Logger-objekt fra Log4j og videre til en loggfil. try { orderlines = bll.getsalesdetails(userorder); } catch (Exception e) { orderlines = null; LOGGER.error("Får ikke hentet ordrelinjer fra webservice.", e); bll.setview(new ErrorView(bll.getBundle().getString(ForitBundle.errorWebServiceSalesDetails ))); } Figur 8.2 LO R Loggfilen legges i en mappe kalt logs rett over src-mappen i Client-modulen. Her er et utdrag fra loggfilen: :56:20 LoginView [ERROR] Får ikke hentet liste med ordre fra webservice. java.lang.exception at no.goodtech.foritcds.client.util.webserviceconverter.getorderslist(webservi ceconverter.java:217) at no.goodtech.foritcds.client.util.wsbusinesslogic.getuserorders(wsbusinesslo gic.java:125) at no.goodtech.foritcds.client.ui.homeview.initgui(homeview.java:62) at no.goodtech.foritcds.client.ui.homeview.<init>(homeview.java:41)... 39

54 Produktdokumentasjon 9 Resterende arbeid FôrIt CDS er per dags dato et ganske ferdig produkt, men det har noen mangler for å få satt det helt ut i produksjon. Den første tingen som må gjøres er selve installasjonen på EWOS sine servere som vil bli gjort av Goodtech når alt annet er klart. Dette burde gå ganske lett, da det bare er å endre URLen til webservice i propertyfilen kalt WebserviceConnection.xml og starte opp servicene for klienten og webservicen. Utenom det finnes det to hovedproblemer som ikke kan bli løst i selve FôrIt CDS. Det første er at teknologien som skal sende koordinater for lokasjonene til befrakterne ikke er installert enda. Det andre problemet er beregningen av den estimerte ankomsttiden som heller ikke blir publisert til FôrIt-databasen. Når disse problemene vil bli implementert er ikke kjent enda. Applikasjonen er ikke avhengig av disse dataene, dog systemet vil være mer komplett når de er fikset. Ved en eventuell installasjon vil være lurt å laste ned en lokal filstruktur av kart-tiles. Dette vil gjøre applikasjonen mindre avhengig av andre servere som en ikke har kontroll over. 40

55 Produktdokumentasjon Blank side 41

56 HØGSKOLEN I OSLO OG AKERSHUS FôrIt CDS Testrapport Stian Strøm Anderssen, Mikkel Sannes Nylend og Shahariar Kabir Bhuiyan Gruppe

57 Testrapport Forord I dette dokumentet vil det bli beskrevet hvordan vi har testet applikasjonen, hvilke metoder vi har brukt og hva resultatene ble. Rapporten kan brukes i forbindelse med vedlikehold og eventuell videreutvikling. Det forutsettes at bruker har en teknisk bakgrunn innen IT og bør helst ha kompetanse innen systemutvikling. Det anbefales at leser er kjent med produktdokumentasjonen, men skal ikke være nødvendig. 1

58 Testrapport Innholdsfortegnelse Forord...1 Innholdsfortegnelse Mål Verktøy Testing Testing i utviklingsfasen Mål Ytelse og nettverksforbruk Mål Testing av funksjonalitet Mål Brukertesting Mål Resultater Feilsøking av kode Generell feilsøking Enhetstesting Funksjonalitet Innhenting av data Testing på forskjellige skjermstørrelser Nettverksforbruk Brukertesting Kommentarer Konklusjon

59 Testrapport 1 Mål Før et produkt settes ut i drift må man sørge for at produktet er sikkert og robust. Det er da nødvendig at applikasjonen er grundig testet. Hensikten med testene er å avdekke eventuelle feil som ikke ble oppdaget under utviklingsperioden. Tester som er utført omfatter generell feilsøking av kode, funksjonstesting, ytelse og nettverksforbruk, og brukertesting. 2 Verktøy Enhetstesting og feilsøking ble i stor grad gjennomført på medlemmenes bærbare datamaskiner. Testing av funksjonalitet og ytelse ble utført på følgende enheter. ENHET OPERATIVSYSTEM SKJERMSTØRRELSE SAMSUNG GALAXY S4 Android IPHONE 4 ios 7 4 SAMSUNG ATIV S Windows Phone ASUS NEXUS 7 (2013) Android IPAD 2 ios For måling av dataforbruk ble Wireshark brukt, et program som analyserer pakker ut og inn i et nettverk. I forbindelse med brukertesten ble det opprettet en spørreundersøkelse. Applikasjonen har blitt testet på følgende nettlesere. o Chrome o Safari o Firefox o Opera o Internett Explorer o Standard nettleser for Android 3

60 Testrapport 3 Testing I denne seksjonen ser vi nærmere på hva slags testing som ble utført i løpet av utviklingsperioden og målet med disse testene. 3.1 Testing i utviklingsfasen Underveis i hver iterasjon ble applikasjonen og dens funksjonalitet kontinuerlig testet på ulike enheter for å sikre like resultater. Testene ble utført i forbindelse med generell feilsøking, og ble stort sett utført av gruppemedlemmene. I forbindelse med denne metoden ble det blant annet utført enhetstesting, som går ut på å teste ut mindre enheter i programmet. Vi ønsker altså å teste om de ulike metodene i en klasse implementerer ønsket oppførsel. Vi har i denne sammenheng benyttet rammeverket JUnit, som går ut på å lage instanser av klassen som skal testes og prøve ulike sekvenser av metodekall og sjekker om verdiene som returneres stemmer med en såkalt fasit Mål Målet med denne metoden er å sørge for at all kode fungerer som det skal. 3.2 Ytelse og nettverksforbruk En viktig del av testingen var å sørge for at applikasjonen virker som den skal under ulike dekningssituasjoner da applikasjonen er ment til å brukes utenfor hjemmet. Denne metoden gir oss blant annet stor innsikt i hvilke problemer som kan oppstå, og eventuelle løsninger til problemene. En annen viktig del er dataforbruket ved bruk av applikasjonen. I denne sammenheng vil Wireshark benyttes for å måle datatrafikken, og estimere dataforbruket ved en økt Mål Målet med denne metoden er å sjekke oppførsel og forbruk på forskjellige nettverkstilkoblinger. 4

61 Testrapport 3.3 Testing av funksjonalitet For at applikasjonen i det hele tatt skal være brukbar må det sjekkes at generell funksjonalitet virket som det skal. Det er derfor viktig å teste alle knapper og navigasjonsmuligheter Mål Hensikten med denne metoden er å se om de ulike modulene i applikasjonen blant annet samsvarer med de funksjonelle kravene i henhold til kravspesifikasjonen. Sluttbruker skal bruke applikasjonen på mobile enheter, det er derfor viktig at denne er kompatibel på alle enheter. 3.4 Brukertesting For å oppnå målet om brukersentrert utvikling ble det nødvendige med brukertester. Underveis i utviklingsperioden ble veiledere ved Goodtech og HiOA bedt om å prøve applikasjonen og eventuell komme med noen tilbakemeldinger. Alle tilbakemeldinger ble tatt hensyn til og funksjonalitet ble eventuell revurdert og implementert på nytt. I sluttfasen ble det sendt ut en spørreundersøkelse til et par personer. Hensikten med spørreundersøkelsen var å lære om hvordan en eventuell sluttbruker så på applikasjonen vår Mål Målet med metoden er å få mest mulig tilbakemeldinger fra brukere slik at applikasjonens kan tilpasses til flest mulig brukergrupper. 5

62 Testrapport 4 Resultater Denne seksjonen oppsummerer alle tester som ble utført på applikasjonen. Testene har blitt delt opp i seks deler feilsøking av kode, testing av funksjonalitet, innhenting av data, testing på forskjellige skjermstørrelser, nettverksforbruk, og brukertesting. 4.1 Feilsøking av kode Testen har blitt delt opp i to deler, generell feilsøking og enhetstesting Generell feilsøking Nylig implementert kode ble kontinuerlig testet på utviklerverktøy. Resultat av slike tester ble oftest skrevet ut til fil, terminal eller skjermbildet. Når vi var sikre på at koden virket, tok vi testene videre til ulike mobile og desktop nettlesere, for å sikre at funksjonaliteten bak nylig implementert kode virket som vi ønsket. Dette er mer forklart under kapittelet Valg og utfordringer Enhetstesting Det ble opprettet fem test-klasser - FleetTest.java o Tester om modellen Fleet returnerer riktig verdier. Relasjonen mellom flåte og ordre blir testet. Totalt er det 3 tester i denne klassen. - ForitCDSUITest.java o Her blir det testet om man blir sendt videre til LoginView ved feil URL. o Datoformateringsmetoden i WebserviceConverter metoden blir testet. Tester hva som skjer ved riktig input, og galt input. o Totalt er det 2 tester i denne klassen. - FreighterTest.java o Tester om en de ulike metodene returnerer riktig verdier sammenlignet med fasiten. Relasjonen mellom befrakter og ordre blir testet. Det er totalt 8 tester i denne klassen. - OrderTest.java 6

63 Testrapport o Tester om en ordre returnerer riktig verdier. Relasjonen mellom ordre og flåte, ordre og befrakter, og ordre og ordrelinje blir testet. Totalt 17 tester. - SalesDetails.java o Tester om en ordrelinje returnerer riktige verdier. Relasjon mellom ordrelinje og ordre blir testet. 7 tester. Hver test-klasse oppretter en instans av modellen som skal testes og sjekker om returverdiene til en metodekall stemmer med en såkalt fasit. Vi ser nærmere på dataformaterings-metoden i ForitCDSUITest.java klassen. public String dateformatter(string date) { if (date == null date.length()!= 10) return null; String inputformat = "yyyy-mm-dd", outputformat = "dd.mm.yyyy"; Date inputdate; String outputdate; } try { inputdate = new SimpleDateFormat(inputFormat).parse(date); outputdate = new SimpleDateFormat(outputFormat).format(inputDate); } catch (ParseException e) { return null; // feil input } return outputdate; Figur 4.1 dateformatter-metoden fra WebServiceConverter.java. Tar imot en inputdato som parameter. Datoen som leses fra Web Servicen er på formen YYYY-MM-DD. Metoden ovenfor konverterer datoen til formen DD.MM.YYYY. Denne formen er mer forståelig og lesbar for en sluttbruker. Legg merke til at den kun tar imot dato på form YYYY-MM-DD! For å teste om denne metoden ved hjelp av JUnit oppretter vi en instans av klassen WebServiceConverter i test-klassen ForItCDSUITest.java. Deretter opprettes det en testmetode. 7

64 public void testdateformatter() { String date = " "; String formatteddate = " "; assertequals("tester om datoformaterings-metoden returnerer riktig verdi med riktig input.", formatteddate, wsc.dateformatter(date)); date = " "; assertnull("tester om datoformaterings-metoden returnerer null hvis input er feil.", wsc.dateformatter(date)); date = " "; assertnull("tester om datoformaterings-metoden returnerer null når lengden til date er mindre enn 10.", wsc.dateformatter(date)); date = null; assertnull("tester om datoformaterings-metoden returnerer null hvis date er null.", wsc.dateformatter(date)); } Figur 4.2 Test-metoden for dateformatter-metoden i WebServiceConverter.java String date er vår input dato, altså datoen vi mottar fra Web Servicen, mens formatteddate er det vi forventer å få som svar, altså fasiten. assertequals tester om resultatet av metodekallet blir lik formatert dato, altså fasiten. assertnull tester på hva som returneres ved feil input. Vi får følgende resultat når testen kjøres. Figur 4.3 Resultatet av JUnit-testen til ForItCDSUITest.java 8

65 Testrapport Totalt er det laget 37 enhetstester, og alle kjørte gjennom. 4.2 Funksjonalitet Applikasjonen ble kontinuerlig testet på ulike enheter etter implementering av ny funksjonalitet for å avdekke mangler, feil og eventuelle forbedringer. Funksjonaliteten virket stort sett på alle nettlesere utenom Opera. Resultatet «OK» betyr at testen ble godkjent. Eventuelle avvik er beskrevet med en kommentar, som kan brukes til fremtidig videreutvikling. VIEW FUNKSJONALITET RESULTAT/KOMMENTAR OPPSTART Starte opp app OK LOGIN Logge inn med brukernavn og OK passord Bytte språk til engelsk/norsk OK HOME Vise ordreoversikt OK Trykke på «Se på kart» OK Trykke på «Detaljer» OK Trykke på «Meny-knappen» OK, litt tregt i Windows Phone 8 telefoner. ORDERDETAILS Vise informasjon om valgt ordre OK Trykke på tilbakeknapp OK MAP Innlasting av kart OK, litt tregt i EDGE-nettet Innlasting av posisjoner OK Trykke på markørene OK Trykke på tilbakeknapp OK MENY Trykke på valgene «Meny», OK «Profil», «Om» eller «Logg ut» PROFILE Se på flåteid og kundenummer til OK innlogget bruker Bytte språk til engelsk/norsk OK Trykke på menyknapp OK. Logg-ut vises ikke i Internett Explorer ABOUT Trykke på accordion OK. En liten CSS feil i «Om EWOS», bildet går litt opp på accordion. Trykke på en lenke OK 9

66 Testrapport Trykke på menyknapp OK ANNET En refresh/oppdatering av siden OK, blir sendt videre til riktig view avhengig om du er logget inn eller ikke. Om applikasjonen husker språk neste gang applikasjonen brukes OK 4.3 Innhenting av data Testene under sjekker all datainnhenting ved hjelp av kall mot WEB servicen, og innhenting av tile for kart med kall mot MapBox. Testene ble foregått på Wi-Fi, 4G, 3G og Edge. Resultatet «OK» betyr at testen ble godkjent med en akseptabel responsnivå. Eventuelle avvik er beskrevet med en liten kommentar. VIEW FUNKSJONALITET RESULTAT/KOMMENTAR LOGIN Verifisering av innloggingsdetaljer OK, rask. Hvis server er nede er responsen litt tregere. HOME Hente informasjon om ordre. OK, rask ORDERDETAILS Hente informasjon om ordre og OK, rask ordrelinje MAP Innhenting av tile til kart OK, tregt på EDGE-nettet. 4.4 Testing på forskjellige skjermstørrelser Funksjonaliteten ble testet på følgende skjermstørrelser Applikasjonen skalerte ganske bra på alle skjermstørrelser, og all funksjonalitet virket som det skulle. 10

67 Testrapport 4.5 Nettverksforbruk Etter å ha lekt litt med appen mens Wireshark kjørte, kom vi fram til følgende resultater. FIREFOX (BYTE) IE (BYTE) CHROME GJENNOMSNITT KILOBYTE MEGABYTE (BYTE) REFRESH VANLIG ØKT LANGT FORBRUK En refresh beskriver en «oppdatering» av siden. En vanlig økt er en økt på ca. 1 min, hvor bruker sjekker ordreliste, ordredetaljer, sporer sin ordre, sjekker profilen og leser litt om applikasjonen. Med langt forbruk mener vi en økt på flere minutter hvor vi leker med kartløsningen, sjekker ordre og ordredetaljer flere ganger, bytter språk flere ganger også videre. Det er lite sannsynlig at sluttbruker vil bruke applikasjonen så mye. Resultatene forteller oss at dataforbruket er ganske minimalt. En sluttbruker vil sannsynlig ikke bruke applikasjonen i mer enn et minutt og da stort sett kun sjekke liste over kommende ordre, ordredetaljer og eventuelt spore order. Forbruket ble også testet på en datamaskins nettleser, så vi antar at forbruket vil være mindre på mobile enheter. 11

68 Testrapport 4.6 Brukertesting I sluttfasen ble det sendt ut en brukerundersøkelse til et par bekjente av den komplette applikasjonen. Det ble stilt syv spørsmål til brukerne om applikasjonens funksjonalitet og brukervennlighet. Totalt var det syv respondenter som deltok i spørreundersøkelsen. Ingen av testpersonene har testet applikasjonen før. Etter analysering av alle svar kom vi fram til følgende resultater. Hvor brukervennlig synes du appen var på en skala fra 1-10 (10 er best)? Figur 4.4 Analyse av tilbakemeldinger på applikasjonens brukervennlighet. 12

69 Testrapport Hva synes du om språket i applikasjonen (sjekk norsk og engelsk)? Legg gjerne ved en kommentar hvis du finner feil eller mulige forbedringer. Figur 4.5 Analyse av tilbakemeldinger på språket i applikasjonen Er applikasjonen responsiv? Prøv gjerne applikasjonen på mobilen din! Figur 4.6 Analyse av tilbakemeldinger på applikasjonens responsivitet. 13

70 Testrapport Hva synes du om fargevalget på en skala fra 1-10 (10 er best)? Legg gjerne ved en kommentar. Figur 4.7 Analyse av tilbakemeldinger om applikasjons fargevalg Figur 4.8 Kommentar om applikasjonens fargevalg 14

71 Testrapport Hva synes du om kartet? Figur 4.9 Tilbakemeldinger på kartfunksjonen i applikasjonen Hvor lett synes du det var å navigere i appen på en skala fra 1-10 (10 er lettest)? Figur Analyse av tilbakemeldinger på applikasjonens navigasjonsmuligheter 15

72 Testrapport Kommentarer Brukertesting endte opp med å bli et viktig verktøy for oss. Generelt har responsen vært ganske god. Funksjonaliteten fikk bra respons, og applikasjonen ble oppfattet som en rask applikasjon. Brukervennligheten og fargevalget ble ikke mottatt like bra som forventet, og disse områder er et forbedringssted ved videreutvikling. Applikasjonen ble mottatt bedre av folk med en annen mobilbakgrunn. Dette kan blant annet være på grunn av at man allerede kjenner til hvordan man navigerer gjennom en applikasjon generelt. 5 Konklusjon Testrapporten har gitt oss en god oversikt over applikasjonens funksjonalitet, responstider og dataforbruk. Testmetodene har vært med å øke produktets kvalitet ved sikre at funksjonaliteten samsvarer med de funksjonelle kravene. Rapporten viser at applikasjonen fungerer som den skal med den funksjonaliteten som var ønsket. 16

73 Testrapport Blank side 17

74 HØGSKOLEN I OSLO OG AKERSHUS FôrIt CDS Valg og utfordringer Stian Strøm Anderssen, Mikkel Sannes Nylend og Shahariar Kabir Bhuiyan Gruppe

75 Valg og utfordringer Forord I denne rapporten skal vi skrive litt om valgene som ble tatt i utviklingsprosessen. Vi kommer til å fokusere på større valg som hadde stor innvirkning på utforming av FôrIt CDS, og vi skal også skrive litt om utfordringene og hvordan vi har prøvd å løse disse. 1

76 Valg og utfordringer Innholdsfortegnelse Forord...1 Innholdsfortegnelse Valg og utfordringer GUI CSS Layout Oppsett av GUI Fargevalg og tekststørrelse Feilhåndtering Checked og unchecked exceptions JSON objekter Utfordringer og begrensinger i prosjektet Samsvar med kravspesifikasjon Funksjonelle krav Ikke-funksjonelle krav Produktkrav Prosesskrav Drøfting av resultatet Plattform Webservice HTML og Java Interaksjon og flyt Begrensninger Rammebetingelser Språk

77 Valg og utfordringer 1 Valg og utfordringer I dette kapittelet skal vi skrive litt om valg som ble tatt i forhånd til brukergrensesnittet. 1.1 GUI Som tidligere nevnt er FôrIt CDS utviklet ved hjelp av Vaadin Touchkit. Når en starter å lære seg Vaadin, er det veldig lett og sette seg inn i kodestandarder, oppsett og bruk av GUI elementer. I starten av prosjektfasen satte gruppen seg ned for å bli kjent med grensesnittet til Vaadin og hva det kunne tilby. Når en lager sin første applikasjon med Vaadin får en generert en ferdig applikasjon som inneholder noe grunnleggende brukergrensesnitt elementer. Denne genererte applikasjonen inneholder de fleste elementer som Vaadin har tilgjengelig for utviklere. Vi fant ut i en tidlig fase at dette ikke var verdt og bruke alt for mye tid på, da vi ville utvikle noe eget som det ikke hadde vært laget noe lignende av tidligere. 1.2 CSS Vaadin Touchkit kommer med mange, ferdige, genererte design oppsett. Hvis en ønsker og definere sitt eget design er dette mulig ved bruk av CSS. For at Vaadin skal bygges mot mobile enheter kommer den med et widgetset. Et Widgetset er en verktøykasse som forhåndsdefinerer GUI komponenter med et visst utseende og egenskaper. Vaadin Touchkit har som standard at de bruker Vaadin Touchkit Widgetset til dette. Når en utvikler applikasjoner i Vaadin blir det laget en XML fil kalt web.xml som inneholder informasjon om hvilket widgetset som skal brukes. Denne brukes for av webserveren Jetty sin skal kjøre programmet. Om en ønsker og redefinere design på komponenter må en da kalle på style navnet som wigdetsettet bruker på komponenten. Under følger et eksempel på et CSS kall som skal redefinere designet på en knapp..v-verticallayout.v-button {} En utfordring ved å redefinere utseende på komponenter er at Vaadin sitt widgetset har en tendens til å overskrive det utvikler har definert for komponenten i CSS. Hvis det skulle skje 3

78 Valg og utfordringer en feil ved lasting av CSS når applikasjonen kjører, vil applikasjonens utseende bli seende ut som widgetsettet har satt som standard. Vi har flere steder i vår kode ønsket og definere design på veldig spesifikke komponenter som Vaadin ikke har noe godt design på. Å gjøre kall på disse enkeltelementene kan være svært tidkrevende og utfordrende. Under følger en CSS kodesnutt som definerer designet på den venstre margen i gridlayouten som definerer designet på vår tabell i OrderDetailsView..v-vertical.v-margin-left,.v-horizontal.v-margin-left { } padding-left: 0!important; Kommentaren «!important» Blir brukt som en forsikring på at widgetsettet ikke skal overskrive vårt oppsett med sine design definisjoner. 1.3 Layout Vaadin bruker Layouts for å definere posisjonen til GUI komponenter i et view. Det finnes mange forskjellige layouts som kan brukes, og de er svært enkle i bruk med masse funksjonalitet implementert. I vår applikasjon har vi valgt og bygge opp alle views ved bruk av ulike Layouts. Den mest brukte layouten har vært vertikal layout som legger komponentene under hverandre. Fordelen med å bruke layouts er at en kan legge flere ulike layouts i hverandre. På hjemskjermen til applikasjonen har vi gjort nettopp dette. Under følger et eksempel hvor vi definerer en layout inne i en eksisterende layout. final VerticalComponentGroup mainbody = new VerticalComponentGroup(); final VerticalLayout orderlayout = new VerticalLayout(); <Oppsett av GUI elementer> VerticalLayout eachorderlayout = new VerticalLayout(); eachorderlayout.addcomponent(ordernolabel); 4

79 Valg og utfordringer HorizontalLayout buttonlayout = new HorizontalLayout(); <Oppretter knapper og egenskaper for disse> eachorderlayout.addcomponent(buttonlayout); orderlayout.addcomponent(eachorderlayout); mainbody.addcomponent(orderlayout); Ovenstående kodesnutt er hentet fra FôrIt CDS sitt HomeView og viser hvordan vi har definert layout inni flere layouts. Vi oppretter en mainbody layout som inneholder en orderlayout med en egen ordrelayout for hver ordre som skal vises. Denne layouten inneholder igjen en horisontal layout som skal legge til noen knapper ved siden av hverandre. Under følger en figur som viser en sammenheng mellom de forskjellige layoutene i hjemskjermen. Rødt - mainbody Gult - orderlayout og eachorderlayout Brunt - buttonlayout 5

80 Valg og utfordringer Figur Viser hjemskjermen til applikasjonen hvor layouts er merket ut. 1.4 Oppsett av GUI I en tidlig fase ble det bestemt at applikasjonen skulle være enklest mulig å bruke. Vårt mål var at en ikke skulle trenge mer enn fem minutter på å lære seg å navigere rundt i FôrIt CDS. For å oppnå dette fulgte vi to prinsipper: KISS-prinsippet (Keep It Simple Stupid ) o Prinsippet handler om å ikke overkomplisere applikasjonen og den funksjonalitet. Selv om koden kan være komplisert, er det viktig at dette ikke blir gjenspeilt i bruken. En god måte å løse dette problemet på, er å ha ryddig kode, og planlegge utforming av logikken før den blir laget 5 trykk regelen o En bruker skal ikke bruke mer enn 5 trykk for å navigere rundt i applikasjonen. 6

81 Valg og utfordringer Figur Sitemap FôrIt CDS som viser hvordan en kan navigere seg rundt i applikasjonen. Om en f.eks. står i kartvinduet, og ønsker å navigere seg til informasjonsvinduet, skal det ikke mer enn 4 trykk til før bruker har kommet til sitt ønskede vindu. 1.5 Fargevalg og tekststørrelse I applikasjonen har vi valgt å bruke fargekombinasjoner som skal tilfredsstille kravene om universell utfordring (For mer informasjon, vennligst lest kravspesifikasjon som finnes vedlagt i sluttrapport). FôrIt CDS er bygget opp av blått, grått og hvitt med rødt på feilmeldinger, og oransje på punkter på kartet. Etter å ha gjort litt research er dette farger som passer godt sammen. Hvis en fargeblind skulle brukt vår applikasjon, ville ikke han hatt problemer med å lese tekst som blir skrevet ut på skjerm. Kombinasjonen av rødt og grønt, kan for mange være en utfordring. Vi har valgt og ikke bruke dette i vår applikasjon. Fonten brukt i applikasjonen skal være så stor og enkel som mulig å lese. Målgruppen for brukere til applikasjonen er personer mellom 30 og 60 år som gjerne har litt dårlig syn. Både på farger og tekst er derfor viktig at vi bruker et design som er lett og lese. 7

82 Valg og utfordringer 1.6 Feilhåndtering Applikasjonen er laget slik at den skal logge all feil som oppstår. Når applikasjonen kjøres for første gang blir det opprettet en mappe som heter logs i kjøremappen til applikasjonen. Hvis et unntak blir kastet når applikasjonen blir kjørt, logges dette i loggfilen istedenfor å bli skrevet til konsollen. For at applikasjonen skal være enklere og drifte har vi valgt å løse feilhåndtering på denne måten. En sluttbruker får ikke noe ut av å lese feilmelding som oppstår ved feil når den kjøres. Det er det utviklere og drifter som har. Vi valgte derfor å lage en egen feilmelding-skjerm som forteller sluttbruker at noe er skjedd, og at vi jobber med å løse problemet. I en tidlig fase av prosjektet hadde vi veiledning med vår kodeveileder Øystein Myhre. Han viste oss en del standarder når det kommer til logging av feil. Etter dette satte vi en standard for applikasjonen at feilmeldinger skal logges på høyest mulig nivå for å få med alle potensielle feilmeldinger som kan oppstå. 1.7 Checked og unchecked exceptions I Java er det et skille mellom checked og unchecked exceptions. Unchecked exceptions er unntak/som blir kastet som følge av feil i koden. Dette var være unntak som NullPointerException eller IllegalStateExeption. Disse unntakene må ikke behandles in metoden hvor de blir kjørt da feilen som forårsaker disse kan være så mangt. De blir først oppdaget under kompilering av koden. Checked exceptions blir kastet når det er noe feil i miljøet rundt programmet. Dette kan være feil i input som bruker skriver inn, feil i kommunikasjon med webservice. Disse feilene må behandles, da programmet må vite hva det skal gjøre hvis de kastes. For mer detaljer om hvordan vi har løst feilhåndtering, vennligst se vår vedlagte Produktrapport. 8

83 Valg og utfordringer 1.8 JSON objekter Webservicen som skal hente data fra FôrIt databasen til vår klient kommuniserer via en URL som klienten vår mottar. Webservicen returnerer data som JSON arrayer og JSON objekter. Når vi skal konvertere disse dataene til våre klientobjekter, har vi parset URL-en, og fått returnert innholdet som en tekststreng. Vi har deretter konvertert tekststrengen til JSON objekter som igjen blir lagret som våre objekter. Siden applikasjonen som skal settes ut i produksjon ligger på Goodtech sitt lokale nettverk, har vi valgt å gjøre om applikasjonen ørlite grann for få kjørt den utenfor Goodtech sine lokaler. Istedenfor at klienten kommuniserer med webservicen via URL, har vi valgt og lage noen lokale JSON filer med samme innhold som webservicen ville returnert. I koden vår har vi derfor laget to metoder som leser fil-innholdet, og returnerer det på samme måte som webservicen ville gjort. For å få vist mest mulig av logikken vi har laget til produktet, har vi valgt å bruke lokale JSON filer i produktet vi leverer. I vår oppgavetekst fra Goodtech står det spesifisert at vi ikke skal lage noen databaseløsning til applikasjonen. Vi har derfor ikke gjort dette i vårt leveringsprodukt heller, for at forskjellene skal være minimale. Under følger et eksempel på en JSON fil vi har lagt ved i klienten. Om en ønsker å se alle JSON filene vi har brukt, ligger dette i /main/webapp/resources mappen. [ { "factoryid":1, "orderid":83013, "orderlineno":1, "itemsize":0, "articleno":"304829", "articlename":"salmon GROUP VI1000AQSG 50ABLK", "plannedweight": , "loadedweight": , "actualweight": } 9

84 Valg og utfordringer ] Koden over viser et JSON objekt for en ordrelinje. Dette er hentet fra filen CustomerOrderLines83012.json 2 Utfordringer og begrensinger i prosjektet Siden tidlig oppstart ble det bestemt at vi skulle bruke Vaadin Touchkit til å utvikle applikasjonen vår i. Programmer kodet med Vaadin Touchkit må kjøres som en webapplikasjon og ikke som en lokal mobilapplikasjon. Om gruppen hadde fått velge hadde vi valgt å lage en lokal app, da mulighetene er mye større i forhold til komponenter, design, interaktivitet mellom views, og kode. En native applikasjon har ikke behov for å kjøre i en nettleser. Det vil kjøre lokalt på enheten og applikasjonen kan da bruke diskplass direkte på telefonen istedenfor på en server. Når vi utvikler mot web er det en del faktorer en må ta stilling til. Den viktigste av de alle vil være databruk. Siden FôrIt CDS skal kjøres på mobile enheter vil sluttbrukerne sende og motta mye mobildatatrafikk. Dette koster igjen en del penger over tid, og vårt mål blir da og lage en applikasjon bruker minst mulig datatrafikk. En annen ulempe er hastighet på dynamikken i applikasjonen. På it-språket blir dette ofte kalt lagging. Dette motvirkes ved å kun vise komponenter som er helt nødvendig. Mye av våre views er derfor bygget opp ved hjelp av egendefinerte metoder som gjør denne jobben enklere for applikasjonen. Eksempelvis vil være vår ordrelinjetabell, som er et gridview med en svært enkel tabell i. I starten brukte vi Vaadin sin forhåndsdefinerte tabell, men det viste seg at denne var svært lite responsiv i bruk på mobile enheter. I tillegg var kompabiliteten begrenset på ulike nettlesere. Nettlesere og design var også et problem under utvikling. Når en utvikler mot web i dag er det svært mange nettlesere som brukes. Vi måtte derfor ta høyde for å lage en applikasjon som på best mulig måte ville fungere på tvers av flere nettlesere. 10

85 Valg og utfordringer 3 Samsvar med kravspesifikasjon Følgende kapittel henvender seg til kravspesifikasjonen som er ett vedlegg i sluttrapporten. Kapittelet tar for seg i hvor stor grad applikasjonen har oppfylt de spesifiserte kravene til det endelige produktet. 3.1 Funksjonelle krav Vi kan se at alle de prioriterte funksjonelle kravene som ble lagt frem i kravspesifikasjonen har blitt oppfylt. Applikasjonen har en innloggingsmulighet som videresender en bruker til et vindu hvor en kan se relevant data for hvem som er logget inn og hva som er blitt bestilt. En kan se aktive ordre og hvor de befinner seg på et kart. En kan også se alle ordrelinjer for hver ordre. Systemet har også en egen side hvor det er muligheter for å få litt informasjon om leverandøren EWOS, Goodtech og om applikasjonen FôrIt CDS. Systemet har også implementert funksjonalitet for å skrive ut driftsmeldinger, men siden dette enda ikke er implementert i databasen til EWOS og i vår webservice blir ikke dette skrevet ut. Vi kan også se at de aller fleste kravene for ønsket funksjonalitet er implementert i applikasjonen. Det blir loggført feil og det finnes en side hvor en kan endre språket. Det å vise forventet ankomst for befrakteren har også blitt implementert i klientdelen av systemet. Problemet er det samme da EWOS sine databaser ikke får inn noen data fra skipene om når de forventer å komme frem. Ikke noe av tilleggsfunksjonaliteten har blitt lagt til i applikasjonen grunnet tidsbegrensning og kun leserrettigheter til EWOS sine databaser. Det vil være fullt mulig å legge til dette ved et senere tidspunkt for Goodtech. 3.2 Ikke-funksjonelle krav Ikke funksjonelle krav er krav som beskriver kvalitetene til et system. I vår kravspesifikasjon skrev vi om to typer ikke funksjonelle krav. Produktkrav og prosesskrav. 11

86 Valg og utfordringer Produktkrav Vi skrev at bruker ikke skulle bruke mer enn 5 trykk for å navigere seg rundt i applikasjonen. Som nevnt i kapittel 1.4 er dette kravet utført. Vårt mål var å lage applikasjonen så enkel som mulig slik at terskelen for å lære bruk av applikasjonen skulle være lavest mulig. Etter tilbakemeldinger fra sluttbrukere har det kommet frem at disse kravene er oppfylt. Vi testet applikasjonen på personer i aldere år. Dette er personer som er innenfor applikasjonens målgruppe, som tilbakemelding fikk vi at applikasjonen var lett og navigere i, samt at funksjoner var selvforklarende. Krav som kommer til ytelse har vi testet i egne utviklingsmiljøer. Applikasjonen trenger svært lite ytelse for å kjøre fint Prosesskrav Dette er krav som omhandler arbeidsprosessen. På forhånd bestemte vi ar gruppen skulle arbeide etter KISS prinsippet, og ha sprinter etter SCRUM prinsippet på to uker. Den eneste endringen vi gjorde her, var å definere en sprint til ti dager. Totalt i hele prosjektet har vi hatt 5 sprinter. For mer informasjon om sprintene, les i den vedlagte produktdokumentasjonen. 4 Drøfting av resultatet Resultatet av vår applikasjon kan tolkes på mange måter. Oppgaven vi fikk var veldig spesifikk med hva som var ønsket av funksjonalitet, og vi har prøvd og følge denne oppgavebeskrivelsen som en mal gjennom hele prosjektet. I begynnelsen av prosjektfasen var det ikke bestemt hvem som skulle kode backend-logikken og hvordan denne skulle utføres. Vi bestemte derfor på daværende tidspunkt å putte dette på vent frem til prosjektansvarlig hadde fått diskutert med EWOS og sine kollegaer. På samme tid hadde vi flere ting og stri med, så vi anså ikke dette som et problem. Det ble bestemt at vi skulle bruke dummy-data i applikasjonen inntil backend-logikken ble bestemt. 12

87 Valg og utfordringer Applikasjonen vår er utviklet ved hjelp av Vaadin Touchkit sitt rammeverk. Vaadin er et verktøy som er en videreutvikling av Google Web Toolkit (også kalt GWT). GWT er Googles eget rammeverk og blir brukt til utvikling av webapplikasjoner mot pc. Vaadin arver egenskaper og funksjoner til GWT og skal tilby brukere en mer spesifiserte funksjoner rettet mot webben. I starten tilbød Vaadin er rammeverk mot utvikling av webapplikasjoner til pc. De siste to årene har det blitt utviklet et rammeverk mot mobiltelefoner som vi har brukt til utvikling av vår applikasjon. 4.1 Plattform Når vi startet opp med utvikling av FôrIt CDS var det fortsatt ikke implementert støtte for Windows Phone i Vaadin Touchkit. Android og ios var de mobile operativsystemene som var støttet og vi fokuserte derfor på å lage en applikasjon optimalisert for disse. Hvis en skal lage en såkalt native-applikasjon er det begrenset med støtte. Det er derfor viktig at en utvikler i et veldig spesifisert utviklingsmiljø som er rettet mot et spesielt mobilt operativsystem og versjon av dette operativsystemet. Hvis en oppdatering til for eksempel Android blir sluppet, kan det være nødvendig for utvikler og rekompilere prosjektet, endre i moduler og kode for å få prosjektet til å kjøre på den nye versjonen. I tillegg er det stor forskjell i logikk og oppsett av en ios applikasjon kontra en Android applikasjon. I praksis må en derfor lage to applikasjoner. I vårt tilfelle skulle vi lage en webapplikasjon som ikke tar i bruk verktøyet som native-applikasjoner bruker. Vi trengte derfor ikke tenke på begrensninger i forhold til hva som går på hvilken plattform. Allikevel har det vært flere begrensninger og utfordringer vi har støtt på i prosjektet. 4.2 Webservice Etter hvert i prosjektet ble det bestemt at Goodtech skulle utvikle en webservice som vår applikasjon skulle kommunisere med. Webservicen skulle totalt utføre tre spørringer mot FôrIt databasen og returnere disse i form av JSON objekter som vi skulle lese og presentere på en god måte i vår applikasjon. Siden denne webservicen ligger utenfor oppgavedefinisjon har gruppen valgt og se bort fra denne i arbeidet. Vi har vært med å definere krav og ønsker hvilke data som hentes, men vår hovedoppgave har vært utvikling av selve klienten. 13

88 Valg og utfordringer FôrIt databasen ligger på Goodtech sitt lokale nettverk, og man har kun tilgang til denne databasen om man kjører FôrIt CDS innenfor dette nettverket. For at vi skal få brukt det meste av vår produktlogikk i innlevering av hovedprosjekt, har vi valgt å opprette noen lokale JSON filer i prosjektet som bruker den samme logikken som webservicen bruker. Derfor vil den som evaluerer vårt produkt kunne se nøyaktig det samme som en sluttbruker vil se. Grunnen for at vi valgte å bruke lokale JSON filer har vært at vår oppgavedefinisjon omfattet klienten og arbeid ut til datalaget hvor webservicen ligger. De dataene som webservicen returnerer er helt like de lokale JSON filene vi har laget og det er derfor vi har valgt å bruke disse. 4.3 HTML og Java Vaadin applikasjoner kan kodes direkte i Java. Når prosjekter kjøres vil det kjøres på en lokal server under utvikling. Under bygging og kjøring av applikasjonen vil det genereres HTML kode ut ifra Java koden vi har skrevet. Designet i applikasjonen er satt ved hjelp av CSS. Hvis en kjører applikasjonen, åpner den i browseren og inspiserer siden vil en kun finne maskingenerert HTML kode med Vaadin og GWT navn. Det vil derfor være svært vanskelig å replikere vår side kun ved å se på HTML. 4.4 Interaksjon og flyt For informasjon om programoppbyggning, vennligst les i produktdokumentasjonen. Under følger et use-case diagream som skildrer flyten i FôrIt systemet 14

89 Valg og utfordringer Figur Use-case diagram som viser den logiske sammenhengen mellom handling og aktører i FôrIt systemet. 4.5 Begrensninger Selv om Vaadin Touchkit skal kunne kjøre på alle plattformer er det fortsatt en del begrensninger når det kommer til komponenter og valg av layout /design. Et aspekt hvor dette kommer til uttrykk er i forskjellige nettlesere. Selv om applikasjonen kjører pent i Google Chrome, betyr ikke det at den kjører like pent i Internet Explorer for Windows Phone. Vi har derfor måtte teste applikasjonen opp mot forskjellige browsere jevnlig under utvikling. Noen komponenter har derfor blitt egendefinert i ettertid for at de skal kunne kjøre slik vi vil på tvers av operativsystemer og nettlesere. Den ferdige applikasjonen vår skal kunne kjøres på både mobile og stasjonære klienter uansett operativsystem og nettleser. Oppgaven vår var veldig spesifikk og vi har hatt klare retningslinjer til hva sluttbruker skal kunne se. For å få til denne funksjonaliteten har det ligget mange timer med arbeid og mange linjer med kode som har vært skrevet mange ganger før vi har vært fornøyde. Takket være vår veileder Øystein Myhre har vi hele tiden fått kode revidert og applikasjonen har blitt jevnlig testet under utvikling. For mer informasjon om testing og produktet, vennligst se på Produkt og testrapport som finnes vedlagt i dokumentasjonen. 15

90 Valg og utfordringer 4.6 Rammebetingelser Ved start på utviklingsfasen ble det allerede satt veldig klare rammebetingelser på hva som skulle utvikles, og på hvilken måte dette skulle gjøres. Det var opp til gruppen og finne best mulig måte og få utviklet en applikasjon som tilfredsstilte kravene som var satt. For å få til dette var det mye planlegging og analyser som skulle til. Analysearbeidet og planlegging av applikasjonen tok flere uker og var essensielt for å være kapable til å produsere det som var ønsket av EWOS. For mer informasjon om analyseprosessen, vennligst se kapittel om dette i produktrapporten. Hvis vi skal vurdere applikasjonen som en helhet opp mot oppgavebeskrivelsen, kan vi med trygghet si at vi er svært fornøyd med produktets resultat. Applikasjonen er svært enkel i bruk, den kjører på alle plattformer uten problem, designet er laget på en slik måte at ingen skal ha problemer med å lese hva som står, og fargekombinasjonene er satt i henhold til prinsippene om universell utforming. (For mer informasjon, vennligst se på produktrapport). Hele veien har vi vært veldig nøye på å dokumentere alt vi gjør. Alle skisser er tatt bilder av, vi har skrevet dagbok for hver dag, gjøremålslister er laget for hver dag, og vi har prøvd og følge sprintene vi planla til punkt og prikke. Når vi har blitt tidlig ferdig med planlagte funksjoner har vi valgt å implementere ønsket funksjonalitet. I starten av prosjektarbeidet satte vi opp en språkfunksjon som en ønsket funksjonalitet, men utover i prosjektfasen bestemte vi at språk skulle implementeres. Siden det er sannsynlighet for at applikasjonen skal føres til utlandet er det ønskelig å få applikasjonen i engelsk format. Dette har vi fått til, og bruker kan velge om han vil kjøre applikasjonen på norsk eller engelsk. Når en bruker velger hvilket språk som blir satt, så lagres dette i en cookie og nettleseren husker språket bruker satt neste gang vedkommende logger på i FôrIt CDS. 4.7 Språk En utfordring med FôrIt CDS sin funksjon av språk er at all data som blir returnert fra webservicen kommer på norsk. Dette er data som vi ikke har mulighet til å få oversatt da denne dataen sendes over nett og ikke er lokalt lagrede tekststrenger. Hvis applikasjonen 16

91 Valg og utfordringer skal brukes i utlandet må det utvikles en egen database for de engelske kundene hvor all informasjon blir lagret på engelsk, da vil applikasjonen kjøre alt på engelsk. Vi har lagt opp til funksjonalitet slik at dette skal være mulig, men dette har ikke vært klart fra Goodtech sin side. 17

92 HØGSKOLEN I OSLO OG AKERSHUS FôrIt CDS Prosessdokumentasjon Stian Strøm Anderssen, Mikkel Sannes Nylend og Shahariar Kabir Bhuiyan Gruppe

93 Prosessdokumentasjon Forord Formålet med denne rapporten skal være å gi leseren en innsikt i arbeidet under prosjektperioden. I rapporten skriver vi om prosess-verktøy som ble brukt under prosessen. Rapporten inneholder også en lengre beskrivelse av prosessen hvor vi går inn på hver sprint og drøfter hva som ble gjort. En drøfting om arbeidsmetoden er også med i rapporten, her skriver vi litt om KISS prinsippet og hva dette innebærer. Vi drøfter også kravspesifikasjonens rolle i prosessen. Denne rapporten kan leses av alle. En trenger ingen spesiell forkompetanse. 1

94 Prosessdokumentasjon Innholdsfortegnelse Forord...1 Innholdsfortegnelse Arbeidsforhold og samarbeid Gruppen Kunnskapsnivå og egen læring Dialog med Goodtech Dialog med EWOS Verktøy Trello SVN Google Hangout Tavle SCRUM Prosessen Planleggingsfasen Forprosjektfasen Sprint til Sprint til Sprint til Sprint til Sprint til Arbeidet etter siste sprinten Arbeidsmetode KISS prinsippet Kravspesifikasjonens rolle i utviklingsprosessen

95 Prosessdokumentasjon 1 Arbeidsforhold og samarbeid I dette kapittelet beskrives arbeidsforhold og samarbeid i gruppen under prosjektperioden. 1.1 Gruppen Gruppen har siden starten av prosjektet hatt et tett samarbeid. Vi har gjennom mange prosjekter på Høgskolen valgt å jobbe sammen. Derfor var det naturlig for oss å jobbe sammen på hovedprosjektet. Grunnet utviklingsmiljøet applikasjonen skulle utvikles i, har vi holdt til i Goodtech sine lokaler på Karihaugen siden starten av januar frem til mai. Gruppen har jobbet 3-4 ganger i uken med prosjektet med en gjennomsnittlig arbeidstid på 7 timer per dag. Samarbeidet i gruppen har gått svært bra! Vi har hatt dialoger og vært ærlige med hverandre. Hvis det har vært vi er uenig i, har ingen hatt noe problemer med å ta det opp med resten av gruppen. Dette har skapt et veldig godt samhold og god dialog medlemmene imellom. I tillegg til dette har vi også sørget for å gjøre litt sosiale ting sammen etter arbeidstid for å ivareta gruppedynamikken på et personlig plan. Under følger en tabell som viser ansvarsfordelingen i prosjektet. Ansvarsområde Gruppeleder Brukergrensesnitt Kartløsning Språk Risikoanalyase Testing Webservice Kodemiljø (Maven moduler, xml- config filer) Prosessdokumentasjon Produktdokumentasjon Brukerdokumentasjon Hvem Stian Mikkel Shahariar Stian Alle Mikkel/Shahariar Mikkel/Stian Shahariar Stian Mikkel Shahariar 3

96 Prosessdokumentasjon Testdokumentasjon Utviklingsprosessdokumentasjon Kvalitetsikring Shahariar Stian Alle 1.2 Kunnskapsnivå og egen læring I et gruppearbeid hender det ofte at kunnskapsnivået gruppemedlemmene vil variere. Både Shahariar og Mikkel har vist fra et svært tidlig stadium at programmering er en veldig sterk side hvor de kan mye. Det har derfor vært naturlig at de har tatt et visst ansvar i prosjektutviklingen. Alle på gruppen har hjulpet hverandre med å få til bra kode hvis det har oppstått noen problemer noen steder. Vi fordelte forskjellige ansvarsområder til ulike gruppemedlemmer. Shahariar var ansvarlig for å drifte hjemmesiden og oppdatere prosjektdagboken jevnlig. Mikkel har hatt ansvar for at koden vi skriver er av god kvalitet. Stian har hatt ansvar for at dokumentasjonen blir skrevet, og dette på en god måte. Ved hjelp av denne fordelingen har vi alle fått lov til å ha ansvar for felter vi er sterkest i. Vi har alle jobbet med forskjellige områder under hele prosjektet, men denne fordelingen har vært en forsikring på at det som blir levert skal være av kvalitet. 1.3 Dialog med Goodtech Harald Pedersen og Øystein Myhre har vært ansvarlige for oss under prosjektperioden. De har begge hjulpet til med å få oss til å forstå prosjektets omfang, og hva som skal utvikles. Harald Pedersen har vært ansvarlig for oss under prosjektperioden, og Øystein Myhre har fremgått som en kodeveileder, det var han som hadde ansvar for å få utviklet webservicen etter våre ønsker og krav. Øystein har også hjulpet oss med å få satt opp miljøet til utvikling. Siden Goodtech hadde litt forskjellige standarder til kodemiljø enn det gruppen var vant til fra før, var dette en veldig sterk fordel. Dialogen med Goodtech har i hele prosjektfasen vært særdeles bra. Vi har fått all den hjelpen vi har trengt og mer til. Både Harald og Øystein har hjulpet gruppen med å få renskrevet dokumenter etter en viss standard. Kravspesifikasjonen ble i tidlig revidert av Øystein hele fem ganger før den ble satt som endelig. 4

97 Prosessdokumentasjon Vi anser arbeidet med Goodtech som et svært vellykket samarbeid. Vi ble tatt imot på en svært positiv og åpen måte som ble gjenspeilt i hjelpen vi fikk under prosjektarbeidet. 1.4 Dialog med EWOS Gruppen har siden starten av prosjektfasen forholdt seg til Goodtech, og deres ønsker og krav. Harald Pedersen har vært den som har stått for videre dialog med EWOS. På slutten av prosjektet sendte vi en lengre mail til EWOS hvor vi viste litt hva vi hadde gjort og skrevet om de. EWOS har samtykket til å bli omtalt som kunden i prosjektet. 2 Verktøy Nedenfor følger en liste med verktøy som ble brukt under prosjektarbeidet. 2.1 Trello Trello er en webapplikasjon som lar brukere lage «post it» notater med korte kommentarer om en oppgave som skal utføres. Trello tillater muligheten for å lage en status på notatet som blir laget. Status kan være «To do». «Doing», «Testing» eller «Done». Gruppen brukte Trello i startfasen på prosjektet for å fordele oppgaver, men gikk i sluttfasen over til å bruke tavle. 2.2 SVN SVN er et versjonskontrollverktøy for kode, også kalt Subversion. SVN er et online versjonskontrollverktøy som gjør det mulig å laste opp forskjellig versjoner av en fil. Ved bruk av versjonskontroll ivaretar en at prosjektet hele tiden er oppdatert med en kjørende versjon. Hver gang en fil blir endret må den sjekkes inn på SVN. Hvis de andre gruppemedlemmene skal ha tilgang til filen, kan de trykke på filen, og oppdatere den mot riktig versjon som har blitt lastet opp på SVN. 5

98 Prosessdokumentasjon 2.3 Google Hangout Google sin chatfunksjon som fungerer på stasjonære og mobile enheter. Gruppen har brukt Hangout flittig i hele utviklingsprosessen for å avtale møtetider, og gi nyttig informasjon. Hangout tillater også videokonferanser, noe gruppen har benyttet seg av. 2.4 Tavle I slutten av prosjektarbeidet begynte gruppen og bruke mer tavle. Det var hele tiden ting som måtte gjøres, og beskjeder ble oppdatert jevnlig. Istedenfor å bruke Trello, valgte gruppen da og gå over til bruk av tavle til å skrive ned viktige gjøremål og beskjeder. 2.5 SCRUM SCRUM er en smidig utviklingsmetode som blir brukt under prosjektutvikling. Ved bruk av SCRUM får utviklere mer å si under prosjektutviklingen. I SCRUM deler en opp prosjektet i flere iterasjoner som er små prosjektfaser. Disse iterasjonene blir kalt sprinter, hver sprint har en fast lengde. I vårt prosjektarbeid har dette vært ti dager. Etter hver sprint setter en seg ned og evaluerer sprinten som en helhet. En ser på hva som har blitt utført, hva som skal utføres i neste sprint og hva som har vært utfordrende. For mer informasjon om våre sprinter, vennligst les kapittelet om prosessen, eller se på vårt vedlagte Gant-Diagram. 3 Prosessen I dette kapittelet skal vi skrive om prosessen og belyse ulike prosjektfaser med hva vi gjorde i detalj. På hjemmesiden vår har vi laget en prosjektdagbok hvor leser kan følge utviklingen fra dag til dag gjennom hele prosjektet. Kapittelet består av flere underkapitler som beskriver de ulike sprintene i kronologisk rekkefølge. Vedlagt i sluttrapporten finnes et Gant diagram som viser fremdriftsplanen for prosjektet oppdelt i iterasjoner. 6

99 Prosessdokumentasjon 3.1 Planleggingsfasen Dette var den første starten på prosjektarbeidet. I denne perioden var hovedmålet og finne det mest relevante prosjektet som kunne gi oss mest utbytte. I vårt tilfelle ble dette FôrIt CDS applikasjonen hos Goodtech ASA. Etter noen møter med veilederne i Goodtech ble det laget en prosjektskisse og en statusrapport om prosjektets fremgang. 3.2 Forprosjektfasen Dette var oppstartfasen for det virkelige prosjektarbeidet. Arbeidet startet en tidlig morgen fredag 6 januar. I begynnelsen av prosjektet handlet det om å bli kjent med ulike utviklingsmiljøer og rammeverket som skulle benyttes i produktutviklingen. Denne perioden handlet mye om å gjøre seg komfortabel med miljøet vi skulle tilbringe de neste 5 månedene i. En betingelse oppdragsgiver satt, var at prosjektet skulle legges ut på bedriftens intranett. Dette ble gjort for å ivareta sikkerheten under utvikling, samt det var enklere for veilederne og følge utviklingen, og se til at oppsett ble utført i henhold til gitte standarder. For gruppen medførte dette at vi var avhengig av å sitte hos Goodtech når vi skulle utvikle produktet. Grunnet sikkerhetsbegrensninger ble det vanskelig å kunne sitte på skolen å jobbe med prosjektet. Det ble derfor laget en intern avtale i gruppen at vi skulle jobbe med prosjektet hver mandag, tirsdag og fredag fra klokken 08:30 til 16:00 hos Goodtech. Parallelt med planleggingen begynte vi å se på mulighetene som fantes i rammeverket vi skulle bruke til utvikling. Siden produktet er utviklet ved hjelp av rammeverket Vaadin måtte vi sette oss inn i dette for å lære oss hvilke muligheter og begrensninger som fantes. I en tidlig oppstartfase ble det utviklet en svært enkel demo som siden ble vist frem på forprosjektpresentasjonen på Høyskolen i Oslo og Akershus. Gruppen satte opp en plan for de fremtidige sprintene. Ved hjelp av estimeringsteknikken Planning Poker satte gruppen opp et estimat på hvor lang tid det skulle ta å utvikle de ulike modulene. Dette ble grunnlaget for de senere sprintene som er nevnt i senere avsnitt. Det ble også bestemt av hver sprint skulle være på 10 dager (mandag- fredag uken etter) 7

100 Prosessdokumentasjon 3.3 Sprint til Den første sprinten handlet mye om å bli kjent med prosjektet og skrive kravspesifikasjon. Vi hadde nå en god oversikt over prosjektets omfang, men det gjensto svært mye når det kom til prosjektets utforming, og hvilke standarder som prosjektoppsettet skulle følge. I en tidlig fase i prosjektet ble det bestemt at gruppen skulle kun lage klientsiden av applikasjonen. FôrIt CDS skulle være lagdelt hvor gruppens ansvar var applikasjonlaget. Applikasjonen skulle kommunisere med en webservice som igjen kommuniserte med selve FôrIt databasen. Det var veilederen vår Øystein Myhre som skulle være ansvarlig for å utvikle webservicen basert på våre analyser og tilbakemeldinger. Vår oppgave ble derfor å finne ut hva slags data som webservicen skulle hente ut. Siden vår applikasjon er en forenklet utgave av et større eksisterende system, var det en omfattende oppgave å finne ut hvilken data som var relevant for oss. Vi fikk tilgang på en databasemodell av det eksisterende systemet for å skjønne litt mer om logikken bak kulissene. Denne modellen var svært komplisert og det medførte i mange spørsmål som vi måtte finne ut av. Vi brukte over en uke på å lage en liste med hvilke data som webservicen skulle hente ut. Ved å lage listen over data vi trengte innså vi også en annen utfordring i prosjektfasen. Siden Goodtech skulle utvikle en modul til prosjektet vårt, ble gruppen avhengig at de leverte innen tid. Siden vi er studenter som skriver en oppgave på vegne av en oppdragsgiver er det naturlig å tro at dette prosjektet ikke er høyeste prioritet internt i bedriften. Forutsetningen for å få et ferdig virkende produkt var da at Goodtech leverte sin modul innen avtalt tid. Mye av tiden i sprint 1 gikk ut på å sette opp et prosjekt som var i henhold til Goodtech sine retningslinjer når det kom til kode, filhierarki, kommentarer m.m. Det ble i en tidlig fase bestemt at vi skulle bruke SVN til versjonskontroll av prosjektet. Gruppen skulle bruke Goodtech sitt interne savn oppsett for kode underveis i prosjektet. Siden det var mange regler vi måtte følge brukte vi ganske lang tid på å sette opp et prosjekt som var i henhold. 8

101 Prosessdokumentasjon Den fikk vi satt opp vårt første testprosjekt som stemte overens med standarden til Goodtech. Når prosjektet var satt opp i henhold var det mulig for oss å begynne på implementasjonsfasen satte vi opp klassehierarkiet til prosjektet som skulle være produktet vårt. Dette var første skritt på veien til et ferdig produkt. I starten av sprint 1 ble gruppen enige om en del funksjoner som skulle implementeres i løpet av sprinten. Ved hjelp av en gjøremålsliste som ble oppdatert fra dag til dag gikk dette arbeidet veldig i henhold til det vi planla. Siden Goodtech skulle lage webservicen var det opp til oss og lage testdata vi kunne bruke under utvikling av prosjektet. I sluttfasen av sprinten satte vi opp første utkast til det som skulle være vår dummydata. De viktigste funksjonene som ble implementert i sprint 1 Førsteutkast til modellen i prosjektet Noen views ble definert med et potensielt design Dummydata ble implementert for senere utvikling 3.4 Sprint til Vi var nå inne i kodefasen av prosjektet. Nå var det viktig at de største endringene skulle implementeres. For at ting skulle gå etter planen var det viktig at vi fulgte gjøremålslisten og jobbet systematisk. I starten av sprinten satte vi derfor opp den ønskede funksjonaliteten vi skulle implementere i løpet av denne sprinten. Ved hjelp av nettsiden Trello.com tildelte gruppen ulike oppgaver til medlemmene og satte opp frister for når de ulike modulene skulle være ferdig. Hovedfokuset for sprint 2 var å få implementert en kartløsning i prosjektet vårt. Siden sluttbrukerne av appen er avhengig av å kunne spore fiskefôret sitt, var det viktig at vi fant en kartløsning som funket godt til mobile enheter. 9

102 Prosessdokumentasjon Shahariar ble oppnevnt til kartansvarlig i begynnelsen av prosjektet. Han implementerte to kart fra Google og Leaflet i hvert sitt prosjekt og testet ut dette. Etter noe testing ble det bestemt at vi skulle bruke V-Leaflet til videre utvikling da dette var mer mobilvennlig. Vi jobbet også mye med å implementere de ulike sidene som skulle dukke opp i applikasjonen. Her lagde vi flere potensielle løsninger hvor alle hadde et felles mål, om å være enklest mulig å bruke for en sluttbruker. I slutten av sprinten satt vi igjen med utkast til en del layouts som applikasjonen kunne ha. De viktigste funksjonene implementert i sprint 2: Kartløsning fra V-Leaflet integrert i applikasjonen Layout og design ble implementert i flere sider Dummydataklassen ble oppdatert med flere data og logikk for å hente ut dataen. Innloggingsfunksjon til applikasjonen. 3.5 Sprint til I denne sprinten handlet det mye om å få implementert løsninger og fikse problemer som hadde oppstått så langt i prosjektet. Vi hadde også en demo med veilederne våre i Goodtech og fikk tilbakemeldinger på det vi hadde gjort så langt. Vi fikk mye innsikt i hva som kunne gjøres bedre og fikk en prioritert liste på prioritert funksjonalitet. For at prosjektet vårt også skulle bli relevant som en bacheloroppgave valgte vi å endre prioriteringen på kravene vi satte i kravspesifikasjonen. Tidligere hadde vi satt muligheten for å endre språk som en tilleggsfunksjonalitet. For at applikasjonen i fremtiden skal være enklere å distribuere i utlandet, valgte vi å sette språk som en prioritert funksjonalitet. Dette skulle vise seg å være en liten utfordring, men etter sprinten var over hadde vi klart å implementere et førsteutkast til en språkløsning. I denne perioden ble det mest fokus på koding, da det var viktig å få ting ferdig til avtalt tid og med en god kvalitet. Gjøremålslister ble laget hver dag og ble brukt som en pekepinn på hvordan vi lå an i prosjektet som en helhet. 10

103 Prosessdokumentasjon Språkfunksjon - bruker kan nå velge å få applikasjonen på norsk eller engelsk Endring i innloggingsfunksjon - Endret innloggingsfunksjonen til å bruke en innloggingsform som var sikrere enn det vi hadde fra før Design og layout på tekst, målet var å prøve å få en enklest mulig layout Dagmodus og nattmodus for kart lagt til, dette skal være en fin ekstrafunksjonalitet som tar liten plass, og som gjør at sluttbruker kan endre kontrast på kartet hvis vedkommende finner dette bedre 3.6 Sprint til Sprint 4 var en av de mest omfattende sprintene vi hadde. Nå hadde gruppen fått god oversikt over hva som måtte gjøres, og hvilke problemer vi sto ovenfor. Med to måneder til innlevering må en begynne å ta en del valg på hva som skal utvikles, og hva som må legges på is. I denne sprinten handlet det mye å om fullføre moduler som vi tidligere har begynt på, og samtidig begynne på de siste inkrementene av prosjektet som vi hadde planlagt å lage. Vår veileder Øystein Myhre kom flere ganger med forslag til hva vi kunne lage for å sørge for at vi ikke hadde noe dødtid. Parallelt med utvikling av applikasjonen, ble det i denne perioden utviklet en webservice som FôrIt CDS skulle kommunisere med for å hente data. For å få applikasjonen ut i produksjon er viktigheten av denne webservicen svært stor, da det er den som henter ut dataen som skal vises fra FôrIt sine databaser. Gruppen ble også klar over noen feil i moduler som var utvikle og vi måtte ta noen skritt tilbake for å få forbedret disse feilene da disse var kritiske for at applikasjonen skulle fungere på riktig måte. Moduler som ble laget i denne sprinten Bedret språkfunksjon ved å bruke Set og get-metoder på globale språkvariable. Prosjektet ble lagdelt i et Businesslayer som inneholder metoder for logikken. Goodtech har en del rutiner og regler når det kommer til å lage prosjekter som skal slippes ut til produksjon. Denne perioden har gått mye med til å sørge for at vårt prosjekt er delt opp i moduler som kreves for at applikasjonen lett kan legges ut på nett, og samtidig enkelt kommunisere med en webservice. 11

104 Prosessdokumentasjon På slutten av sprinten hadde vi en evaluering av kodingen med veilederen vår. Øystein tok stikkprøver av koden og fikk oss til å fortelle om hvorfor vi hadde kodet den slik vi gjorde. Dette gjorde at vi ble mer obs på feil vi hadde gjort og muligheten for å utvikle det vi hadde gjort til noe bedre. Han virket veldig fornøyd med det vi hadde gjort så langt i prosessen, men hadde noen kommentarer til noe av logikken vår. Til sprint 5 ble det bestemt av vi skulle fokusere mer på feilhåndtering problemer som måtte oppstå når koden kjører, viktigheten av å logge feil som måtte oppstå er svært stor da applikasjonen skal driftes i fremtiden, og da er det svært mye enklere om en vet hva som er feil. 3.7 Sprint til Dette var den siste sprinten vi satte opp i planen vår. Denne sprinten gikk ut på å gjøre ferdig de siste funksjonene og ferdigstille applikasjonen mot levering. I denne sprinten ble det fokusert mye på å få fullført enhetstestingen av applikasjonen, da webservicen vi skulle bruke snart var ferdig, var det viktig at vi fikk implementert denne inn i vår applikasjon. Siden det skulle være en liten forskjell på applikasjonen vi skulle levere inn til Høyskolen og applikasjonen som skal settes i produksjon på Goodtech, var det viktig at vi la opp til at endringene skulle bli minimale for at funksjonaliteten ville fungere for begge. Enhetstestingen var et viktig mål for oss og få fullført. Vi har hele tiden hatt fokus på at det vi leverer skal være så komplett som mulig. Applikasjonen skal kunne settes direkte ut i produksjon når vi leverer, samt at den skal være enkel å videreutvikle. I slutten av sprinten hadde vi et møte hvor vi planla ukene mot innlevering. På planen hadde vi satt oss som mål og bli ferdig med et leverbart utkast av applikasjonen. Siden webservicen ble litt forsinket i utviklingen, måtte vi bruke noen av de siste ukene med å få implementert denne inn i vår applikasjon. Det ble også bestemt av fokus mer og mer skulle gå mot å ferdigstille sluttdokumentasjonen. 12

105 Prosessdokumentasjon 3.8 Arbeidet etter siste sprinten I starten av prosjektfasen ble det bestemt hvor lange sprinter gruppen skulle ha, og hvor lenge hver enkelt skulle vare. For gruppen betydde det nå at alle sprinter var over. Hovedarbeidet med funksjonaliteten var over. Det som nå gjensto var å få renskrevet dokumentasjon og ryddet i kode. De neste ukene gikk mye til avslutningsarbeider. Ved hjelp av Øystein Myhre fikk vi hjelp til å få sluttført et produkt som tilfredsstilte Goodtech sine ønsker og krav på en god måte. Samtidig som applikasjonen vår ble ferdig ble det også implementert en løsning i FôrIt databasen som knyttet alle lokasjonsid er med et passord. Nå kunne en logge inn med hvilken som helt lokasjonsid, så lenge det var lagt til i databasen. Gruppen hadde som mål og få vår applikasjon opp og gå mot denne nye databasen før prosjektet ble avsluttet. Tirsdag 14 mai ble arbeidet med klienten ferdig. Nå lå det en ferdig FôrIt CDS klient som kommuniserte via webservicen ute på Goodtech sine testservere. Vår arbeid med produkt var nå ferdig. 4 Arbeidsmetode Kravspesifikasjonen ligger vedlagt bakerst i sluttrapporten og kan brukes som et supplement til dette kapittelet. 4.1 KISS prinsippet I kravspesifikasjonen vår skrev vi at vi kom til å dele opp prosjektfasen i sprinter på 2 uker. Vi skulle arbeide etter KISS prinsippet. (Keep it simple stupid). Dette har vi gjort gjennom prosjektarbeidet. Målet med applikasjonen var at den skulle være så enkel å bruke at alle kunne bruke den med minimal opplæring. En av de vanligste fellene utviklere kan gå i er å utvikle et program som er så komplisert at utvikler knapt skjønner hva som er kodet. Ved å ha jevnlig revidering av kode og utfyllende 13

106 Prosessdokumentasjon kommentarer i klassene har det vært enkelt og gå tilbake og se hva vi tenkte når koden ble utviklet. Struktur og formatering har vært den viktigste regelen vi har satt under prosjektperioden. Ved hjelp av vår kodeveileder på Goodtech, Øystein Myhre har vi jevnlig hatt demonstrasjoner av koden og på funksjonaliteten. Vi har valgt å bruke en smidig utviklingsmetode til prosjektet. Prosjektet er delt inn i ulike moduler hvor vi har fokusert på spesielle deler av produktet. Parallelt med modulutviklingen har vi gått tilbake til tidligere moduler for å fikse feil og bugs som har blitt funnet i senere i utviklingen. Kvalitetssikring ved revidering av tidligere arbeid har vært en visjon vi har jobbet etter. Revidering av tidligere kode ved å hele tiden prøve og forbedre det vi har laget. Vi følger en metodikk som handler å finne feilen tidligst mulig og forbedre den fortløpende. 5 Kravspesifikasjonens rolle i utviklingsprosessen Ved oppstart av prosjektfasen bestemte vi oss for å følge en smidig utviklingsmetode. Vi bestemte oss for å bruke SCRUM metodikken og delte opp prosjektene våre i iterasjoner og faser. Ved bruk av denne metodikken kan en gjøre endringer i prosjektplaner underveis. Det er ikke avtalt et fullstendig fast oppsett på forhånd. Dette har gjort at vi underveis har endret litt på prioriteringene på hva som skal gjøres først. Vi satte blant annet opp at språkfunksjon i applikasjonen skulle være ønsket prioritet, men dette ble implementert allerede i sprint 3. Gruppen har hatt et ønske om å levere et fullstendig produkt med utfyllende funksjonalitet som skiller seg ut fra andre tilsvarende produkter på markedet. Når vi startet å utvikle FôrIt CDS var vi klar over at det fantes tilsvarende produkter levert av konkurrenter, så vår oppgave var å lage et produkt som på mange måter ville anses å være unikt med et bredt spekter av funksjonalitet. Vi bygde derfor opp en kravspesifikasjon i samråd med Goodtech og EWOS som inneholdt svært realiserbare krav. Kravspesifikasjonen har vært vår guide mens vi har jobbet med prosjektet vårt. Vi har under hele prosjektprosessen evaluert modulene vi har laget opp mot kravspesifikasjonen. 14

107 Prosessdokumentasjon Derfor kan vi med trygghet si at kravspesifikasjonen har en god relevans med det ferdige produkt som er utviklet. I starten av prosjektarbeidet fikk vi en mail fra Goodtech som EWOS hadde fått tilsendt, hvor det var kommet noen ønsker til krav for systemet. Vi fikk beskjed om å forholde oss til Goodtech og deres ønsker om funksjonalitet. De var de som kom til å ta dialogen med EWOS om hva som skulle utvikles. Fordelen med dette er at kravene da blir enklere å implementere. En person som ikke har kompetanse i IT utvikling har liten innsikt i hva som er mulig å utvikle. Personer uten kompetanse kan lett sette krav som vil være svært vanskelig å implementere. Ved å la Goodtech stå for kommunikasjon med kunde, så har de redusert arbeidet vårt med å komme frem til en løsning som alle vil være fornøyd med. 15

108 HØGSKOLEN I OSLO OG AKERSHUS FôrIt CDS Avslutning Stian Strøm Anderssen, Mikkel Sannes Nylend og Shahariar Kabir Bhuiyan Gruppe

109 Avslutning Forord Denne rapporten oppsummerer vårt arbeid med FôrIt CDS. Under skriver vi litt om nytteverdien til prosjektet for de ulike aktørene, og en konklusjon som oppsummerer vårt 6 måneders lange arbeid med prosjektet. Denne rapporten kan leses av alle. En behøver ingen spesiell forkompetanse. 1

110 Avslutning Innholdsfortegnelse Forord...1 Innholdsfortegnelse Produktets verdi For Goodtech For EWOS For sluttbruker Videreutvikling Læringsutbytte Konklusjon...4 2

111 Avslutning 1 Produktets verdi I dette delkapittelet vil vi se nærmere på hvilken nytteverdi prosjektet vil ha for oppdragsgiver, kunden og sluttbrukere. 1.1 For Goodtech For Goodtech vil applikasjonen ha stor nytteverdi. FôrIt CDS ble lansert som et hovedprosjekt fordi en ville se på mulighetene som fantes ved å utvikle webapplikasjoner i Vaadin. Når applikasjonen settes ut i produksjon er det Goodtech som skal stå for vedlikehold, drifting og videreutvikling av applikasjonen. FôrIt systemet har blitt en større helhet med tilskudd av FôrIt CDS. 1.2 For EWOS FôrIt CDS er en oppgave med et veldig spesifikt rammeverk. Siden applikasjonen skal brukes av fiskeoppdrettere som har ventende leveranser på fiskefôr, kan det være med å forenkle prosessen en hel del. Når en oppdretter tidligere måtte ringe til befrakteren for å høre når leveransen er ventet, kan oppdretteren nå sjekke dette opp mot applikasjonen. EWOS vil finne bruk av vår applikasjon som en sterk forbedring til hva som eksisterer i dag. Dette kommer til å spare EWOS for mange telefonsamtaler som omhandler sporing av leveranser i fremtiden. Siden EWOS har kontorer i fem forskjellige land, vil det i fremtiden være mulighet og videreutvikle applikasjonen til å komme i andre språk. Vi har allerede implementert en språkfunksjon i vår applikasjon, så implementasjon av et nytt språk bør være svært enkelt. 1.3 For sluttbruker Formålet med applikasjonen fra første arbeidsdag har vært å forenkle muligheten for å spore leveranser for sluttbrukere. Siden applikasjonen er utviklet mot mobile enheter vil den være mulig å bruke på steder som kun har mobildekning. Dette kan f.eks. være om bord på en båt, langt til havs. Sluttbrukeren kan nå spore sitt fiskefôr hvor som helst, og når som helst! 3

112 Avslutning 2 Videreutvikling I et program vil det alltid være forbedringspotensialer. Et område vi ser for oss, etter tilbakemeldinger fra brukertestingen, er å gjøre applikasjonen mer brukervennlig. FôrIt CDS er en veldig stor applikasjon, og vi er fornøyde med funksjonaliteten vi fikk implementert. I produktdokumentasjonen, kapittel 9 Resterende arbeid har vi oppsummert kort hvordan arbeid som gjenstår. 3 Læringsutbytte I løpet av dette semesteret har vi fått kunnskap og erfaring innen flere områder. Vi har lært hvordan utvikling av større løsninger fungerer i arbeidslivet, vi har lært om forskjellige utviklingsmetodikker, deriblant SCRUM, vi har lært bruk av en mengde verktøy som brukes til utvikling i arbeidslivet, og vi har lært om hvorfor dokumentering er viktig. Oppgaven har gitt oss erfaring i å jobbe i team og å jobbe med en arbeidsgiver. Denne prosessen vi har vært gjennom har utviklet oss med tanke på å være forberedt til arbeidslivet. Alt i alt er vi veldig stolte av det produktet vi utviklet, og den fagkunnskapen vi tilegnet oss gjennom hele perioden. 4 Konklusjon I 6 måneder har vi jobbet iherdig med å realisere vårt hovedprosjekt. Et stort antall timer har gått med til planlegging, koding, testing og dokumentering. Oppgaven har vært utfordrende og svært lærerik å jobbe med. Produktet er pr dags dato ikke satt ut i produksjon, men vi håper dette vil være mulig i snar fremtid. Et av gruppens sine hovedmål har vært å lage applikasjonen så komplett som mulig, slik at en overgang fra prototyp til produksjon applikasjon skal være så enkel som mulig. Vi vil rette en stor takk til Harald Pedersen Øystein Myhre og Dag Moltu for deres hjelp i prosjektutviklingen. De har vært utrolig gode veiledere for oss, og har hjulpet til med å definere produktet slik det er i dag. 4

113 Avslutning Vi vil takke Eva Hadler Vihovde som har vært vår veileder i prosjektperioden. På bakgrunn av prosjektets omfang, og tilbakemeldinger, vil vi anse prosjektet som svært vellykket! 5

114 HØGSKOLEN I OSLO OG AKERSHUS FôrIt CDS Vedlegg Stian Strøm Anderssen, Mikkel Sannes Nylend og Shahariar Kabir Bhuiyan Gruppe

115 Vedlegg Innholdet i vedlegg Vedlegget inneholder følgende dokumenter i denne rekkefølgen. Vedlegg A - Forprosjektrapport Vedlegg B - Kravspesifikasjon Vedlegg C - Tilbakemelding fra oppdragsgiver Vedlegg D - Fremdriftsplan med Gantt-diagram Vedlegg E - Risikoanalyse Vedlegg F - Ordliste og kilder 1

116 Vedlegg A - Forprosjektrapport Vedlegg A Forprosjektrapport Innholdsfortegnelse Innholdsfortegnelse Arbeidsdokument Sammendrag Dagens situasjon Mål og rammebetingelser Løsninger Må ha-funksjoner Kan ha-funksjoner Analyse av løsninger Konklusjon

117 Vedlegg A - Forprosjektrapport 1 Arbeidsdokument Sted: Høgskolen i Oslo og Akershus Deltakere: Stian Strøm Anderssen Shahariar Kabir Bhuiyan Mikkel Sannes Nylend Gruppeside: Prosjekteier: Goodtech ASA Kontaktperson: Harald Pedersen Department Manager - Goodtech Projects & Services AS E-post: harald.pedersen@goodtech.no Veileder: Eva Hadler Vihovde Høgskolelektor Høyskolen i Oslo og Akershus - fakultet for teknologi kunst og design E-post: EvaHadler.Vihovde@hioa.no Formål med prosjekt: I henhold til oppgaven skal gruppen: MES- produksjonsprosessen fra mottak av råvarer til levering av ferdigvare hos kunde. Ferdigvarene leveres i stor grad med båt langs norskekysten. Dette forslaget til hovedoppgave beskriver en løsning hvor EWOS via smarttelefon / nettbrett skal kunne følge opp sin bestilling av varer. Stikkord for løsningen vil være: 3

118 Vedlegg A - Forprosjektrapport hvor er båten, når forventes båt A A Gruppen skulle som nevnt over lage en applikasjon som skal brukes til sporing av bestilt mengde fiskefôr, en kunde skal kunne spore sine ordre, se hvor båten er, når den ankommer oppdrettet. Arbeidsspørsmål Hvem skal være ansvarlig for ulike moduler i prosjektet? Hvordan skal vi gå frem å løse oppgaven? Hvilke kodestandarder skal gruppen følge? Hva skal lages? Hvor lange skal sprintene være? Motivasjonspørsmål Hvordan kan vi gå frem for å lære om Vaadin? Hvor mye forkunnskap kreves det for å sette seg inn i prosjektet? Hvordan kan gruppen på best mulig måte bidra til å lage en best mulig løsning som Goodtech kan levere til EWOS? Metodespørsmål Hvordan kommer applikasjonen til å bli brukt? Hva slags utviklingsmodell skal følges? Hvordan kan arbeidet kvalitetsikres? Andre spørsmål Hvordan skal gruppen takle konflikter? Hvordan skal gruppen håndtere lengre tids sykdom hos et gruppemedlem? På hvilken måte kan vi ivareta at alle medlemmer på gruppen leverer sine arbeidsoppgaver til avtalt tid? 4

119 Vedlegg A - Forprosjektrapport Samtlige medlemmer på gruppen er innforstått med innholdet i dette dokumentet og hva dette omfatter. Gruppen vil utstede en stor takk til Harald Pedersen og Øystein Myhre i Goodtech Projects & Services AS for muligheten til å være med på utviklingen av FôrIt CDS. Oslo 01/ Stian Strøm Anderssen Mikkel Sannes Nylend Shahariar Kabir Bhuiyan 5

120 Vedlegg A - Forprosjektrapport 2 Sammendrag Norge er en av verdens største fiskerinasjoner og eksporterer årlig én million tonn laks og ørret ut av landet. Det blir produsert 200 kg laks pr nordmann årlig. For å få til dette trengs det lakseoppdrett. På Vestlandet er det svært mange som lever av å drive lakseoppdrett. Pr oppdrett går det mellom 100 og 200 tonn med laksefôr pr uke. Dette trengs for at laksen skal bli sunn, tykk og god. Gruppen har fått i oppgave å lage en sporingsapp for lakseoppdrettere i Norge. Oppgaven har gruppen fått av Goodtech. Programmet skal være formet som en webapplikasjon og skal kunne kjøres på alle mobile plattformer. Det finnes i dag en løsning som kjøres som et program på PC, men dette er tungvint for mange oppdrettere å bruke da de ofte er ute. Det blir mye enklere å ha programmet som en applikasjon på telefonen. Ved hjelp av FôrIT applikasjonen, skal bruker kunne se hvor mye fiskefôr som er bestilt, hvor mye de faktisk får, hva som er betalt og de skal kunne spore forsendelsen på et kart ved hjelp av nøyaktige koordinater. Ved tid til overs kan også tilleggsfunksjonalitet lages. Dette kommer gruppen tilbake med på et senere tidspunkt. 3 Dagens situasjon Goodtech er et industrifirma som ble dannet i 1913 under navnet Norsk Elektrisk Kabelfabrikk. I begynnelsen leverte firmaet kabler til radioproduksjon. De fleste radioer i Norge hadde kabler fra firmaet. Siden den gang har selskapet fusjonert flere ganger, og byttet navn til Goodtech i de senere år. I dag jobber ikke Goodtech lenger med kabelproduksjon, men har spesialisert seg innenfor flere industriområder. Konsernet Goodtech deles nå inn i følgende avdelinger: Projects & Services Solutions Infra Enviroment Products 6

121 Vedlegg A - Forprosjektrapport Automatikk, industriteknikk, installasjon, krafteknikk og miljøteknikk er noe av det som Goodtech kan tilby. Det er Projects & Services som jobber mot IT sektoren. Det er her gruppen har fått i oppgave å lage sporingsapplikasjonen. Som nevnt tidligere finnes det allerede en eksisterende løsning som brukes på PC. Gruppens oppgave er å gjøre denne jobben enklere for sluttbruker ved å lage en mobil webapplikasjon. Webapplikasjonen skal utvikles i Java ved hjelp av Vaadin rammeverket. Til versjonskontroll skal Subversion brukes. Produktet er estimert å være ferdig til 1 mai. 4 Mål og rammebetingelser Gruppen kommer til å sette seg inn i Vaadin rammeverket. Siden prosjektet skal kjøres på mobile enheter er det viktig at knappene er av typen «Touch». Vi skal derfor bruke TouchKit rammeverket Vaadin tilbyr, dette er bra rammeverk som kan brukes til å lage trygge, stabile og raske webapplikasjoner til mobile enheter. Programmene vi lager skal kompileres ved hjelp av byggeverktøyet Maven. Subversion (SVN) skal brukes til versjonskontroll. Til prosjektets avslutning har vi som oppgave og mål å lage en applikasjon som skal tilfredsstille kravene som er satt. Applikasjonen skal være lett å videreutvikle og vedlikeholde. Koden skal ikke være for avansert, og alt skal kommenteres og dokumenteres. Dagbok føres for hver dag gruppen jobber med prosjektet. Shahariar er satt til å være webansvarlig og legger ut jevnlige oppdateringer på hjemmesiden. Mikkel er utnevnt til utviklersjef og har ansvar for å koordinere arbeidet med hvem som jobber med hvilken del i prosjektet. Stian er kontaktperson og har ansvar for at dokumentasjonen kommer inn i tide og er skrevet på riktig måte. Ansvaret kommer til å være flytende og fleksibelt, men ved å tildele ansvar så har medlemmene ansvarsområder i tillegg til å sette seg inn i utviklingsarbeidet med produktet. Alle medlemmene skal til enhver tid vite hva de andre gjør, og som en gruppe står alle inne for beslutninger som kommer til å bli tatt gjennom prosjektet. 7

122 Vedlegg A - Forprosjektrapport Alle medlemmer på gruppen kjenner hverandre godt og har jobbet sammen i flere tidligere prosjekter. Dynamikken i gruppen er svært god, og en kan si fra hvis en ikke er fornøyd med noe. Dette gjør at arbeidet med å utvikle et godt produkt blir enklere. I tillegg er ekspertiseområder godt spredt. Alle medlemmer er ansvarlig for et område de selv er gode på. Ambisjonsnivået i gruppen er også på et høyt nivå. Alle medlemmer har samme målsetning om å prestere på toppen av karakterskalaen. Derfor skal dokumentasjon, produkt og presentasjon være av topp kvalitet. 5 Løsninger Følgende mobile pattformer skal støttes: Windows Phone 8, Android (4.0 og oppover) IOS (6 og oppover). Til utvikling skal følgende teknologier brukes: Editor: Utviklingspråk: Rammeverk: Versjonskontroll: Designspråk: Eclipse Kepler med Vaadin for Maven installert. Goodtech s infrastruktur for systemutvikling vil benyttes. Java Vaadin Touchkit Subversion CSS, Java, Javascript Andre verktøy som kan bli brukt i prosessen: Scrum, Photoshop og Subclipse. Under følger en kort funksjonsbeskrivelse av hvordan løsningen er tenkt utført. Funksjoner i parenteser er fortsatt litt usikkert. 5.1 Må ha-funksjoner Kart med sporing av mine ordre o Sjøkart o Alle stoppesteder for båtene o Forventet ankomst 8

123 Vedlegg A - Forprosjektrapport Min side/mine ordre o Skal vise alle innkommende ordre o Mulighet for å se detaljer for ordren o Velge å se kart for innkommende ordre o Skal vises: Ordrenummer Kunde skal se hva som blir levert i forhold til hva som er bestilt Planlagt/estimert ankomstdato Pris/kvantitet Hvilken båt lasten kommer med Kommentar til ordren Innlogging og utlogging o (Kan evt. vise driftsmeldinger på innloggingssiden) Om kunden o Om kunden o Om applikasjonen o Kontaktinfo Oppdateringsknapp på hver side Innstillinger o (Se/endre /bruker) o (Endre passord) o (Endre språk nor/eng) 9

124 Vedlegg A - Forprosjektrapport 5.2 Kan ha-funksjoner Tutorial i starten Ordrehistorikk o Viser eldre ordre som er blitt mottatt o Muligheter for å se detaljer for hver ordre Automatisk innlogging Innstillinger o Endre fargevalg o Endre skrift o Justere sensitivitet Passordkrav Kart o Kan vise alle båtene på vei for en bruker o Estimering av tid under kartet o Rute for båten(e) Statistikkside o Visuell fremstilling av data (grafer for eksempel) (statistikk) o Hvor mye penger en har brukt osv. 5.3 Analyse av løsninger Valg av tekniske løsninger er blitt gjort i samråd med Goodtech. Før gruppen fikk prosjektet var det allerede bestemt at Vaadin og Maven skulle brukes. Siden har gruppen kommet frem til at det både må brukes Javascript og CSS for å definere et bra design på applikasjonen. Vaadin er fortsatt under utvikling og det er mye som ikke er ferdig definert som rammeverk. Ved å bruke Javascript og CSS sammen med Vaadin sin touchkit-pakke kan en lage applikasjonen fleksibel for alle plattformer. 10

125 Vedlegg A - Forprosjektrapport Figur 1: Forslag til hvordan appen kan se ut 6 Konklusjon Applikasjonen gruppen lager, skal være mulig å bruke på alle mobile plattformer. Den skal kunne brukes overalt, da brukerne ofte er ute på sjøen. Eneste betingelse skal være at det er dekning i området. Formålet med applikasjonen er å gjøre det enklere for brukere av systemet til å få oversikt over ordrene sine hvor enn de måtte befinne seg i verden. 11

126 Vedlegg B - Kravspesifikasjon Vedlegg B - Kravspesifikasjon Presentasjon Prosjektgruppe: Gruppe 10 Deltakere: Tittel: Stian Strøm Anderssen, s Mikkel Sannes Nylend, s Shahariar Kabir Bhuiyan, s FôrIt CDS Oppgave: Vi skal lage en sporingsapp for fiskefôr som skal brukes av fiskeoppdrettere til å spore bestillinger av fiskefôr. Appen skal gjøre det mulig for brukere å se hvor forsendelsen er på kart, hvor mye de har bestilt, hvor mye de faktisk får og når de får det. Oppdragsgiver: Goodtech Projects & Services AS Per Kroghs vei Oslo 12

127 Vedlegg B - Kravspesifikasjon Forord Prosjektet utføres som hovedprosjekt for institutt for informasjonsteknologi på Høgskolen i Oslo og Akershus på vegne av Goodtech Projects & Services AS. I kravspesifikasjonen skal det settes opp krav til hvordan produktet skal lages. Kravene er delt inn i prioriterte og ønskede krav. Ved tid til overs kan de ønskede kravene implementeres. Kravene er satt i samråd med Goodtech. En ordliste som forklarer begreper finnes i siste kapittel. Dette dokumentet fungerer som et styringsdokument under hovedprosejktet. Dokumentet skal være en enighet mellom utviklerne, Goodtech og leverandøren av fiskefôr i prosjektperioden. Kravene spesifisert i dette dokumentet, er krav og retningslinjer for hvordan prosjektet skal utføres. Alle parter skal være inneforstått med de nevnte krav. 13

128 Vedlegg B - Kravspesifikasjon Innholdsfortegnelse Presentasjon...12 Forord...13 Innholdsfortegnelse Systembeskrivelse Rammekrav for systemet Funksjonelle krav Prioriterte krav Ønskede krav Tilleggsfunksjonalitet Ikke-funksjonelle krav Produktkrav Brukervennlighet Ytelse Sikkerhetskrav Testkrav og feilhåndtering Prosesskrav Dokumentasjonskrav Teknisk dokumentasjon Brukerdokumentasjon Prosjektdokumentasjon Diagrammer og modeller

129 Vedlegg B - Kravspesifikasjon 1 Systembeskrivelse Vi skal lage en sporingsapplikasjon for fiskefôr for Goodtech Projects & Services AS. Applikasjonen skal gjøre det enklere for brukere å spore bestilt mengde fiskefôr. Formålet med applikasjonen er å gjøre det enklere for kunden å få informasjon om bestillinger. Siden systemet skal brukes av fiskeoppdrettere er det et krav om at applikasjonen primært skal kjøres på mobile klienter. 2 Rammekrav for systemet Systemet skal programmeres ved bruk av Java. Appen skal programmeres med rammeverket Vaadin-Framework som støtter Vaadin- TouchKit. Løsningen skal kunne kjøre på mobile plattformer. o Det vil si mobiler og nettbrett med mobilnett. o Hittil støttes bare ios og Android. o Windows Phone 7/8 skal få støtte av Vaadin etterhvert (forventes i Q2 2014). Appen skal bygges ved bruk av Maven byggevertøy. Det skal også brukes Javascript og CSS for å gjøre applikasjonen pen, brukervennlig og responsiv. Data leveres av en webservice. Wireshark skal brukes for å sikre at datatrafikken til applikasjonen blir så liten som mulig. Applikasjonen skal bygges opp etter de 7 prinsippene om universell utforming: o Enkel og intuitiv i bruk o Forståelig informasjon o Toleranse for feil o Like muligheter for alle o Fleksibel i bruk o Lav fysisk anstrengelse o Størrelse og plass for tilgang og bruk (Sitat ref.: 15

130 Vedlegg B - Kravspesifikasjon 3 Funksjonelle krav Funksjonelle krav beskriver funksjoner eller tjenester som et system skal implementere. Vi skiller mellom prioriterte krav, ønskede krav og tilleggsfunksjonalitet. De prioriterte kravene er funksjonene som vi kommer til å ha hovedfokus på å få ferdig. Ønskede krav er funksjonalitet vi ønsker å implementere. Tilleggskrav er krav vi skal implementere hvis vi blir ferdig med prioriterte og ønskede krav tidligere enn forventet. Alle funksjonelle krav er satt i prioritert rekkefølge. 3.1 Prioriterte krav Systemet skal ha en innloggingsfunksjon. En bruker av applikasjonen skal kun se data relevant for sin lokasjon og sine ordre. Systemet skal vise informasjon om hver ordre via en informasjonsside kalt Min side. o Ordrenummer Unikt identifikasjonsnummer til ordren o Vareid Unikt identifikasjonsnummer til varen o Varenavn Hvilken type vare o Skipning Et oppdrag (båtens tur) o Tidspunkt ordren er lastet på leveransebåt o Planlagt losset Summen av de planlagte lastemengder på alle ordrelinjer knyttet til en ordre. o Faktisk losset Den totale lastemengde på alle ordrelinjer som faktisk er lastet om bord i båt. o Ordrelinje Hver ordrelinje har en vare, en ordre kan ha flere ordrelinjer. Planlagt losset- Planlagt lastemengde for den enkelte ordrelinje Faktisk losset Faktisk mengde lastet om bord i båt. Vare Hvilket produkt som er bestilt. Type (bulk/sekk) Type forpakning på bestilt mengde fiskefôr. Systemet skal kun vise aktive skipninger. Det vil si aktuelle ordrer som er på vei, eller som er på vei til å lastes. Systemet skal vise posisjonen til ordren. Systemet skal vise alle ordrelinjer for innkommende ordre. 16

131 Vedlegg B - Kravspesifikasjon Systemet skal ha en side hvor en kan finne informasjon om leverandøren, Goodtech og om FôrIt CDS. Systemet skal inneholde versjonsinformasjon og driftsmeldinger. Systemet skal vise kommentar til ordrene (info om bestilt vann og diesel). 3.2 Ønskede krav Systemet skal ha en mulighet for å rapportere feil. Systemet skal vise forventet ankomst for båten. Systemet skal ha en side for innstillinger hvor en kan endre fargevalg, skriftstørrelse og språk. 3.3 Tilleggsfunksjonalitet Systemet kan vise statistikk i form av grafer. Systemet kan bestille ordrer. Systemet kan kansellere ordrer. Systemet kan endre ordrer. Systemet skal vise historikk over hva en har kjøpt før. 4 Ikke-funksjonelle krav Ikke-funksjonelle krav beskriver kvalitetene til et system. Vi deler opp ikke-funksjonelle krav i to deler, produktkrav og prosesskrav. 4.1 Produktkrav Produktkrav beskriver krav til et ferdig produkt som ikke er en direkte funksjon. Dette omhandler krav til brukervennlighet, ytelse, sikkerhet og testing/feilhåndtering Brukervennlighet Ved bruk av applikasjonen skal det være maks 5 trykk på skjerm for å utføre ønsket oppgave. 17

132 Vedlegg B - Kravspesifikasjon Terskelen for å bruke applikasjonen skal være så lav som mulig. Data som presenteres skal kunne leses raskt og tydelig. Fargevalget skal være intuitivt og enkelt og ivareta prinsippet om universell utforming. Det skal ikke være nødvendig å lese en bruksanvisning før en starter å bruke applikasjonen Ytelse Når en skal lage webapplikasjoner er det viktig å tenke på datatrafikk. Siden applikasjonen kjører på nett, og ikke lokalt på den mobile enheten, er det mer data som må lastes inn for at applikasjonen skal kjøres. Det er derfor viktig at det blir tatt hensyn til dette når applikasjonen skal utvikles. Systemet skal kun hente den mest relevante informasjonen som brukeren trenger. o Dette er for å gi minst mulig datatrafikk for brukeren. Systemet skal være raskt og responsivt Sikkerhetskrav Bruker logger med inn med brukernavn og passord. Applikasjonen skal ligge på Internett. Ved innlogging er det satt et maks antall forsøk på å skrive inn passord. Ved maks antall forsøk vil kontoen til bruker bli låst, og en systemansvarlig må kontaktes. Når applikasjonen skal kommunisere med webservicen, kreves en autentifikasjon med brukernavn og passord, for å bekrefte identiteten til applikasjonen Testkrav og feilhåndtering Hvis det oppstår feil i systemet, skal feilen logges og bruker varsles på en intuitiv måte. Logikken i programmet skal enhetstestes ved hjelp av programmerte testmetoder. Applikasjonen skal integrasjonstestes. Alle komponenter testes før de settes sammen til et system. 18

133 Vedlegg B - Kravspesifikasjon 4.2 Prosesskrav Prosesskrav beskriver krav til prosessen rundt utvikling av produktet. Vi skal følge Scrum med sprinter på 2 uker. Vi skal også følge arbeidsprinsippet KISS. 5 Dokumentasjonskrav Dokumentasjonskrav beskriver krav om dokumentasjonen til produktet og prosjektet. Vi skiller mellom teknisk dokumentasjon, brukerdokumentasjon og prosjektdokumentasjon. 5.1 Teknisk dokumentasjon All kode skal kommenteres på en slik måte at en ekstern utvikler lett skal kunne sette seg inn i koden og videreutvikle produktet. Skjerminnhold, meldinger, rapporter og annen dokumentasjon skal skrives på norsk. Variabelnavn og entitetsnavn skal skrives på engelsk for å gjøre videre utvikling enklere i henhold til internasjonale standarder. Under utvikling av produktet følger gruppen Goodtech sine retningslinjer for utvikling. 5.2 Brukerdokumentasjon Det lages en brukermanual som beskriver funksjonaliteten til systemet. Manualen skal ligge på internett og skal kunne lastes ned ved behov. 5.3 Prosjektdokumentasjon Dagbok skal skrives for hver arbeidsdag. All dokumentasjon skal skrives på norsk. Innholdet i sluttdokumentasjonen skal være: o Kravspesifikasjon o Testdokumentasjon o Prosjektskisse 19

134 Vedlegg B - Kravspesifikasjon o Kontrakt o Brukerveiledning o Produktrapport o Prosessrapport o Ordbok o Kilder 6 Diagrammer og modeller Diagrammet og modellen under beskriver hvordan applikasjonen kommuniserer. Klienten snakker med webapplikasjonen som ligger i DMZ. Webapplikasjonen snakker med en webservice. Figur 1: Enkel modell av arkitekturen til systemet. 20