HOVEDPROSJEKT I DATA VÅR 2011

Transkript

1

2 PROSJEKT NR. 18 TILGJENGELIGHET åpen Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: Telefaks: HOVEDPROSJEKT I DATA VÅR 2011 HOVEDPROSJEKTETS TITTEL Ruteplanleggingssystem DATO ANTALL SIDER / BILAG PROSJEKTDELTAKERE Jørgen Mobekk Sørensen Tor Andreas Baakind Morten Evje Anders Gabrielsen 160 / 6 INTERN VEILEDER Alexander Yngling OPPDRAGSGIVER Kraft Foods KONTAKTPERSON Bjart Pedersen SAMMENDRAG Prosjektet er et hovedprosjekt i informasjonsteknologi ved Høgskolen i Oslo, ved ingeniøravdelingen, og er et samarbeid mellom gruppe 18 og Kraft Foods. Regionssjefene benytter i dag en rekke egeutviklede regneark for å organisere selgere, ruter, butikker, hvor mye som distribueres osv. Systemet holder i hovedsak oversikt over hvilke selgere og fremmere som har ansvar for hvilke butikker og organiserer disse i dagsruter. I tillegg brukes systemet for å lage rapporter som viser salgsvolum, tidsbruk og annen nyttig informasjon. En kundedatabase med ca 4000 kunder er også lagret i en databaseløsning som kommuniserer med excel-arkene.

3 SAMMENDRAG Prosjektgruppen har inngått et samarbeid med Kraft Foods AS, og laget et ruteplanleggingssystem. Systemet skal holde styr på forholdet mellom bedriftens mange selgere, salgsfremmere og kunder. Tidligere har Kraft Foods styrt salgsrutene sine i en komplisert løsning basert på Excel-ark. Løsningen har ingen versjonskontroll, og heller ingen styring av brukertilgang utover filplassering. Alle oppgaver i dette systemet er manuelle, og kundenummere må huskes eller kopieres for å legge inn ruteoppføringer. Systemet har mange gode løsninger, men er veldig tungvindt i bruk. Vi ble enige med oppdragsgiver at dette var et godt utgangspunkt, men at vi kunne bruke egne løsninger der vi mente det var hensiktsmessig. Valget falt på å utvikle applikasjonen i ASP.NET, som er et kraftig rammeverk for webutvikling. For å utvikle et system i ASP.NET benyttes fortrinnsvis Visual Studio. Programmet har innebygde funksjoner for samarbeid mellom gruppemedlemmer, og dette har uten tvil lettet vårt arbeid gjennom tvungen versjonskontroll. Prosjektgruppa består av fire medlemmer. I datainnsamlingsfasen var samarbeid i fokus, men etterhvert som vi kom i gang med utviklingsfasen ble arbeidet mer og mer individuelt. Oppgavefordelingen har vært fordelt slik at en har hatt hovedansvar for C# koding, en har hatt hovedansvar for brukergrensesnitt, en har hatt hovedansvar for dokumentasjon og en har hatt hovedansvar for testing og kvalitetssikring av sluttproduktet. Utover dette har alle bistått hverandre der det trengs, og i avslutningsfasen av utviklingen sløyfet vi oppgavefordelingen og fokuserte på å sette inn ressurser der det var nødvendig. Selv om gruppemedlemmene har hatt forskjellige hovedansvar, har alle bidratt på alle områder og hjulpet hverandre der det har vært nødvendig. Vi fikk tidlig et godt innblikk av hva slags omfang oppgaven hadde, men selve oppbygningen av datastrukturer og hovedfunksjonalitet i programmet var noe uklart. Kommunikasjonen med arbeidsgiveren gikk noe tregt i starten, og dette førte til en rekke misforståelser rundt funksjonalitet og oppbygning av programmet. Misforståelsene kostet oss masse tid, og vi følte i flere situasjoner at vi hadde kastet bort flere ukers arbeid. Konsekvensene av dette ble at vi fikk dårlig tid på selve utviklingsfasen, og vi var nødt til å utelate noe tilleggsfunksjonalitet som hadde lettet arbeidsoppgavene til Kraft Foods arbeidere ytterligere. Men allikevel er både prosjektgruppa og oppdragsgiveren fornøyd med sluttproduktet. Systemet har blitt utviklet for Kraft Foods med hensikt å skulle bli tatt i bruk i daglig drift. I skrivende stund er ikke systemet implementert, men etter møte med oppdragsgiver 25. mai har vi blitt enige om å forsøke å implementere systemet etter at prosjektrapporten er levert. Vi håper at dette går etter planen, og at vi kan melde om ett system som er i drift da vi holder presentasjonen 15. juni. Oppdragsgiver har vist stor interesse for å sette systemet i drift, og vi er sikre på at sluttproduktet vårt vil være til stor nytte for bedriftens ansatte.

4 FORORD Denne prosjektrapporten er resultatet av et hovedprosjekt i data på Høgskolen i Oslo våren Hovedprosjektet er avsluttende del av et treåring bachelorprogram i Informasjonsteknologi. Prosjektrapporten består av sluttdokumentasjonen til prosjektet, som er fem dokumenter skrevet hver for seg. Dokumentene har individuell innholdsfortegnelse og inndeling med sidetall. De fem dokumentene er som følger: Kravspesifikasjon som er utgangspunktet eller problemstillingen for hele prosjektet. Prosessdokumentasjon som beskriver hele prosjektets arbeidsflyt. Her beskriver vi kommunikasjon med arbeidsgiver, arbeidsmetoder, samarbeid i gruppa, resultatoppnåelse, fremgangsmetoder og andre ting relevant til selve prosessen. Produktdokumentasjon som tar for seg hele applikasjonens oppbygning, løsninger, teknologier, funksjoner samt en omfattende gjennomgang av skjermbilder, kildekode og flyt i programmet. Testdokumentasjon som omhandler testing av systemet, hvlike problemer som har oppstått under testing, og hva vi har gjort for å løse det. Brukermanual som er ment til arbeidsgiveren for å få en innsikt i systemet. Kildehenvisninger og vedlegger ligger bakerst i hver del. Kildekoden til systemet ligger på prosjektsiden vår. Rapporten er optimalisert for papir.

5 HOVEDINNHOLD PROSJEKTRAPPORT Prosessdokumentasjon... Del 1 Kravspesifikasjon... Del 2 Produktdokumentasjon... Del 3 Testdokumentasjon... Del 4 Brukerveiledning... Del 5

6 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem RUTEPLANLEGGINGSSYSTEM PROSESSDOKUMENTASJON Prosjekt 18 Jørgen Mobekk Sørensen Morten Evje Tor Andreas Baakind Anders Gabrielsen Side 1

7 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem 1 FORORD Denne dokumentasjonen skal beskrive de forskjellige prosessene som inngår i arbeidet med hovedprosjektet ved Høgskolen i Oslo, avdeling for ingeniørutdanning, våren Dette dokumentet er optimalisert for papir. Vi kom i kontakt med Kraft Foods gjennom Per-Arne Baakind, som er faren til Andreas. Han er prosjektleder for et av konsernets systemer, og jobber sammen med regionsjefen for region Øst. Regionssjefene i Kraft Foods bruker excelark for å planlegge hvilke butikker selgere og fremmere skal besøke. Dette var en løsning som skulle fungere midlertidig i et par måneder, men er blitt brukt i over 4 og et halv år. Derfor håpet de at vi kunne lage en bedre løsning som de kunne bruke istede for den tungvindte løsningen i excel. Etter vårt første møte med Jarle Birkeli, ble vi enige om at dette er et ypperlig hovedprosjekt. Hensikten med prosjektet er å lage en bedre løsning enn dagens excel løsning. Vi valgte å bygge opp en løsning i nettleseren, slik at det ikke var behov for installasjon, implementasjon og stadig oppdatering av alle maskinene som inngår i systemet. Dette gjør det også enklere for alle både internt og eksternt å nå applikasjonen for å planlegge ruter, samt for selgere og fremmere å få tilgang til sine ruter. Disse er per idag manuelt printet ut hos Kraft Foods og gitt til hver enkelt selger / fremmer. Dette stiller høye krav til sikkerhet, noe som nevnes i et senere kapittel. Side 2

8 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem 2 INNHOLDSFORTEGNELSE 1 Forord Innholdsfortegnelse Innledning Om bedriften Bakgrunn for problemet Mål med oppgaven Rammebetingelser og begrensinger Planlegging og metode Genrell planlegging Arbeidsplan og fremdriftsplan Planlegging av databasetruktur Planleggingen i praksis Verktøy Skype og Windows fjernhjelp Dropbox Visual Studio, Team Foundation og Microsoft SQL Google Docs Facebook MySQL Workbench Kommunikasjon med oppdragsgiver Metode Utviklingsprosessen Prosjektets faser Gruppedannelse og valg av oppgave Startfase innledende arbeid Side 3

9 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem Forprosjektfase Planleggingsfasen Utviklingsfasen Testfasen Dokumentasjonsfasen AvslutNingsfasen Valg om oppbygning og funksjoner Lagdelingsprinsipp Problemer og løsninger Samarbeid med oppdragsgiver Programmeringsspråk Lagdeling Nettilgang Datamodellen Ajax-popup Kravspesifikasjonen og dens rolle i prosjektet Endringer i kravspesifikasjonen Kravspesifikasjon i forhold til design og implementering Samsvar mellom kravspesifikasjon og det ferdige produktet Om resultatet Tilbakeblikk Kildereferanser Nettsider Vedlegg Datamodell første utkast Side 4

10 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem 3 INNLEDNING 3.1 OM BEDRIFTEN Kraft Foods er en av Nordens ledende næringsmiddelbedrifter med ca ansatte i fire fabrikker. Deres sterke varemerker gjør dem til markedsleder innen kategoriene sjokolade, kaffe, kjeks og andre matvarer som sjokoladedrikker, kremost, bakeprodukter og desserter. Kraft Foods produserer blant annet varemerkene Freia, Philadelphia og Oboy. 3.2 BAKGRUNN FOR PROBLEMET I dag bruker regionssjefene hos Kraft Foods et excelark for å planlegge ruter for sine selgere og fremmere. Det er også lagt inn diverse rapportfunksjoner som for eksempel oversikt over tonnasje for hver butikk. Samtidig er hele kundedatabasen på over 4000 butikker lagt inn i samme excelark. Dette er et veldig tungt og innviklet system å jobbe med, hvor det er lett å gjøre feil. Kraft Foods vil derfor ha en enklere løsning bygget opp på en database, for å enklere kunne oppdatere og vedlikeholde informasjonen, samt forenkle arbeidsprosessen betraktelig. 3.3 MÅL MED OPPGAVEN Målet med oppgaven vil være å utvikle et webbasert ruteplanleggingssystem for Kraft Foods. Dette systemet skal gjøre det enklere å administrere og vedlikeholde data for ruter, selgere, fremmere og kunder. I tillegg å gjøre det enklere for selgere og fremmere å hente ut sine egne ruteopplysninger, samt informasjon om sine kunder. I og med at dagens løsning med excelark på mer enn 15MB er innviklet og tungt, vil noen av målene være å utvikle en løsning som er mer oversiktlig og enklere å vedlikeholde. Dagens løsning er også utsatt for utdatert kundeinformasjon, mye dobbeltlagring, samt store marginer for feil og oversrkriving av data. Per dags dato legger alle fire regionssjefene hver sin version av excelarket inn på et felles område på Kraft Foods sine servere. Dette settes da sammen til ett, og det er i denne fasen det er enkelt å overskrive hverandre data. Regionssjefene har også problemer med å huske om de lastet sist oppdaterte informasjon opp til fellesområdet, og kan iblandt glemme å gjøre dette. Andre mål med oppgaven vår blir dermed at systemet vårt skal være mindre tidkrevende enn dagens system. 3.4 RAMMEBETINGELSER OG BEGRENSINGER Etter flere møter og mail med oppdragsgiver har vi kommet frem til at vi systemet skal utvikles i Microsofts ASP.NET. All utvikling vil dermed foregå i Microsofts eget IDE (Integrated development environment), Visual Studio. Databasen vil være Microsoft SQL server. Sluttproduktet skal helst ligge på en server hos Kraft Foods, men de er usikre på om ITavdelingen vil tillate oss å legge applikasjonen på deres servere, med tanke på sikkerheten og komplekisteten i systemet. En svakhet i vårt system kan få katastrofale følger for andre applikasjoner som er tilknyttet deres servere. Dersom Kraft Foods ikke kan hoste websiden selv, vil Bjart Pedersen ordre med et eksternt webhotell. Side 5

11 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem 4 PLANLEGGING OG METODE 4.1 GENRELL PLANLEGGING Gruppemedlemmene i hovedprosjektet var klart lenge før vi i det hele tatt startet med å finne en oppgave. Medlemmene på gruppen har jobbet mye med hverandre i de foregående semesterne ved Høgskolen i Oslo. Selve valg av prosjekt og oppdragsgiver ble gjort høsten 2010, da vi møtte Jarle Birkeli, regionssjef i Kraft Foods. Dermed hadde vi i utgangspunktet god tid til å planlegge prosjektet sammen med oppdraggiver. På det første møtet med oppdragsgiver fikk vi innsikt i hva som skulle utvikles, og vi hadde kun en muntlig avtale på at vi skulle gjennomføre prosjektet. Vi fikk raskt opp en prosjekthjemmeside der alle dokumentene til prosjektet publiseres fortløpende. Da vi signerte kontrakten med Kraft Foods helt i starten av 2011, kom vi i gang med den virkelige planleggingen av prosjektet. Vi fikk nå tilgang til excelarkene de brukte for å planlegge ruter og det var først nå vi forsto hvor mye det var som skulle gjøres. Det var derfor viktig for oss å få den informasjonen vi trengte om rammeverk, servertilgang, svar på spørsmål om excel-arkene og datamodellen. Dette viste seg å være vanskelig. Kraft Foods brukte lang tid på å svare, og ofte fikk vi kun svar på deler av spørsmålene. Det viste seg også at IT-avdelingen i Kraft Foods heller ikke vær særlig samarbeidsvillige og fortalte oss at de ikke hadde noen webserver hvor vi kunne implementere systemet. Dette fordi de ikke viste noe om sikkerheten i vårt system, og ikke ville ødelegge andre essensielle systemer på deres servere. Det ble dermed vanskelig for oss planlegge noe om selve utviklingen av prosjektet, siden vi ikke fikk noe informasjon om type server og lignende. Dette førte til at vi ikke kunne starte utviklingen på grunnlag av at vi da ikke visste hvilket programmeringsspråk vi kom til å bruke. 4.2 ARBEIDSPLAN OG FREMDRIFTSPLAN Arbeidsplanen og fremdriftsplanen ble laget i slutten av januar. Vi hadde dermed sett for oss hvilke deler av prosjektet som skulle være påbegynt til hvilke tider og når de skulle være ferdige. Disse planene var realistiske anslag på hvor lang tid hver fase i prosjektet ville ta. Det var derfor viktig å følge fristene slik at vi ikke kom til å havne på etterskudd, og dermed få hastverk med utviklingen av løsningen. Desverre tok datainnsamlingen svært lang tid, både fordi excelarkene var kompliserte og fordi det var til dels dårlig kommunikasjon fra Kraft Foods sin side. Disse dokumentene vil derfor avvike noe i forhold til hvilke tidsfrister vi hadde planlagt. 4.3 PLANLEGGING AV DATABASETRUKTUR Det skulle over 4000 kunder inn i databasen med forskjellige ruter og statistikk linket opp til hver av dem. Det var derfor viktig å lage en god plan over hvordan vi kunne løse dette. Vi fikk utskrifter fra en av databasene til Kraft Foods, og planla utifra disse hvordan vi skulle løse blant annet importering og oppdateringer av databasen. Utskriftene kom i form av excelark og vi ble dermed enige om at disse kunne brukes til importering og oppdatering av databasen. Allikevel var strukturen komplisert, og vi endret hele oppbygningen av databasen på ett tidspunkt da vi klarte å utarbeide en løsning vi syntes var bedre. Dette tok mye ekstra tid, men i forhold til resultatet var det verdt det ekstra bryet. 4.4 PLANLEGGINGEN I PRAKSIS Da vi hadde satt opp fremdriftsplanen og arbeidsplanen følte vi at vi hadde god tid på oss til å gjennomføre prosjektet. Vi hadde tatt hensyns til andre fag vi tok samtidig, og ferier vi skulle ha. Det tok dessverre kort tid før vi allerede hadde brutt flere av tidsfristene. I forhold til arbeidsplanen var vi i rute helt frem til vi startet med datainnsamlingen, som leder videre til kravspesifikasjon og deretter selve utviklingen av løsningen. Datainnsamlingen stoppet hele prosessen i Side 6

12 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem prosjektet, og vi fikk dermed ikke kommet skikkelig i gang med utviklingen av løsningen. Det var også en del misforståelser angående databasemodellen. En god del av arbeidet som ble gjort her ble dermed ubrukelig og vi måtte gjøre dette på nytt. 4.5 VERKTØY Vi benyttet en rekke verktøy gjennom hele hovedprosjektet. De fleste av dem har vi kjennskap til fra før. Vi slapp dermed å bruke tid på å lære oss nye verktøy og kunne heller fokusere på å utvikle løsningen og jobbe med dokumentene til prosjektet. Verktøyene vi benyttet oss av under arbeidet med hovedprosjektet er: Skype. For møter over nett, da medlemmene av gruppa bor på forskjellige plasser, slapp vi å bruke unødvendig mye tid på reising. Dropbox. Til backup og deling av dokumenter innad i gruppa. Visual Studio. Til utvikling av løsningen. Team Foundation Server. For versjonskontroll av utviklingen. Microsoft SQL. For databaseløsningen. Google Docs. Ble brukt dersom flere arbeidet på det samme dokumentet samtidig. Facebooks hemmelige grupper. Ble brukt for å legge ut oppdateringer om prosjektet, og for å avtale møter internt i gruppa. MySQL Workbench. Ble brukt til design av databasemodellen SKYPE OG WINDOWS FJERNHJELP Vi valgte å bruke Skype når vi jobbet hver for oss. Dette er et utmerket verktøy for å snakke og skrive til hverandre. Verktøyet er gratis og det eneste man trenger er nettilgang. Det er også en funksjon for å se hverandres skjermer, men denne fungerte dårlig, og ga dårlig bildekvalitet. Vi valgte derfor å benytte oss av fjernhjelpen som er innebygd i Windows 7. I fjernhjelpen som følger med Windows 7 er det mulig å ta kontrollen over pcen til den man hjelper, og det er meget enkelt å bruke DROPBOX Dropbox ble brukt for lagring av alt som har med prosjektet å gjøre. Her lagret vi alle dokumenter, notater, bilder og lignende som ble brukt. Alt annet enn selve kildekoden ble lagret her. Dropbox fungerer også som versjonskontroll, da man kan gå tilbake til tidligere versjoner av et dokument. Det er ikke mulig at flere jobber på samme dokument, da blir det laget to versjoner av samme dokument og man må velge hvilket dokument man vil ta vare på. Dropbox er gratis om man kun vil ha 5gb lagring, dette holder i massevis for å lagre dokumenter så vi har ikke hatt noe behov for mer lagringsplass her VISUAL STUDIO, TEAM FOUNDATION OG MICROSOFT SQL Da vi til slutt valgte å utvikle systemet i ASP.net endte vi også opp med å bruke Visual Studio. Dette er et IDE som er til stor hjelp i programmeringen. ASP kan til tider være vanskelig da det veldig omfattende, men med Visual Studio får man god hjelp i og det gjør programmeringsbiten litt enklere. Team Foundation ble brukt for versjonskontroll for kildekoden, samtidig fungerer dette som backup da filene blir lagret på forskjellige steder. Versjonskontrollen fungerer slik at man må sjekke ut filer for å kunne bruke dem, da er det kun personen som har sjekket ut filene som som kan bruke dem.andre brukere kan se filene men ikke skrive til dem. Når man er ferdig med filene sjekker man de inn og da er filene tilgjengelig for andre brukere. For databasen brukte vi Microsoft SQL. Alle disse komponentene er laget for Side 7

13 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem hverandre, og fungerer meget godt sammen. Valgene ble derfor enkle da vi først hadde bestemt oss for å utvikle i ASP.net GOOGLE DOCS Vi brukte Google Docs dersom flere hadde behov for å skrive til de samme dokumentene samtidig. Google Docs fungerer relativt greit, men mangler selvfølgelig mange av funksjonene man finner i Microsoft Office. De dokumentene som ble skrevet av flere personer samtidig, ble først skrevet i Google Docs, før vi kopierte innholdet inn i et Word dokument og la til dokumentstilene FACEBOOK Alle avtaler innad i gruppen ble laget her. Vi benyttet oss av Facebooks hemmelige grupper, slik at kun gruppemedlemmene hadde tilgang til informasjonen publisert her. Dersom vi skulle bruke Skype til å arbeide sammen, avtalte vi dette på Facebook. Dette gjorde også skriving av dagbok enklere, dersom vi glemte å skrive ned hva vi gjode i dagboken kunne vi bare se igjennom hva som sto på veggen til Facebookgruppen vår. Denne løsningen fungerte meget godt, og det var enkelt for alle å følge med på hvilke planer gruppen hadde MYSQL WORKBENCH For å designe databasemodellen brukte vi MySQL Workbench. Dette er et program vi har brukt i tidligere prosjekter på skolen. Vi valgte å bruke dette programmet fordi vi har kjennskap til det, og fordi vi mener at vi får et bra resultat ut av det. Databasemodellen har hjulpet oss mye i underveis. Om vi har lurt på hva som henger sammen i databasen har vi bare tatt frem bildet av databasemodellen. 4.6 KOMMUNIKASJON MED OPPDRAGSGIVER I begynnelsen av prosjektet var kommunikasjonen med oppdragsgiver veldig god. Vi snakket med Kraft Foods om hva de ønsket seg av løsningen, og hva vi var i stand til å utvikle for dem. Vi utvekslet ideer og forslag om hvordan ting kunne løses. Det tok ikke lang tid før begge parter var enige om at en webløsning ville være det beste alternativet. Tilbakemeldinger på kravspesifikasjon var også god og vi fikk planlagt hva løsningen skulle inneholde. I startfasen av prosjektet var det som sagt god kommunikasjon. Etter hvert, og som skrevet tidligere i dette dokumentet, har ikke kommunikasjonen med oppdragsgiver vært av topp kvalitet. Vi ser i etterkant at vi kanskje burde ha tatt initiativ til flere møter med oppdragsgiver, slik at vi kunne ha lagt mer press på datainnsamlingsbiten. I prosjektdagboken går det klart frem at vi sendte mange purringer per mail angående forskjellige spørsmål som vi ikke hadde fått skikkelig svar på. Men på tross av dette fikk vi ikke noe svar. Konsekvensene av dette ble misforståelser og mye ekstra arbeid. Neste gang vi jobber med et prosjekt, kommer vi til å bruke lenger tid på planlegging av datainnsamling, slik at vi har et klart bilde av hvilke data vi trenger for å få oversikt over systemet. Men den eksisterende løsningen til Kraft Foods var komplisert, og vi forstod ikke helt i starten hva dette egentlig gikk ut på. Derfor gikk innsamlingen av data litt i rykk og napp, og ble kanskje ikke planlagt så godt som den burde. Dette er ting vi har tatt til ettertanke og som vi har fått mye lærdom fra. Det er viktig med bra kommunikasjon for å få en god flyt i prosjektprosessen. Vi føler at denne flyten helt klart ville blitt bedre dersom kommunikasjonen med opdragsgiver hadde vært bedre. 4.7 METODE I begynnelsen av prosjektet planla vi å jobbe etter Scrum-modellen. Denne er spesielt godt egnet for å utvikle komplekse systemer, akkurat som vårt Ruteplanleggingssystem. Modellen baserer seg på faser på alt ifra en uke, og helt opp til en måned - kalt en Sprint. I forkant av en Sprint plukkes noen av funksjonene som skal implementeres ut fra en Side 8

14 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem liste over gjeldende krav til prosjektet, kalt en Product backlog (Produktkø). Listen som plukkes ut, og som skal implementeres i løpet av en Sprint kalles Sprint blacklog (Sprintkø). Under gjennomføringen av prosjektet skal det holdes daglige møter med Scrum Master hvor alle som er med i teamet skal delta. Møtet skal være kort (rundt et kvarter), og i løpet av dette møtet skal alle medlemmene av teamet gi uttrykk for tre forhold: Hva er gjort siden forrige scrum møte? Hva skal gjøres før neste møte? Hva har (eventuelt) vært til hinder for at gruppemedlemmet var effektiv i implementeringen av funksjonalitet? Denne metoden var veldig godt egnet til vårt prosjekt, men vi var avhengige av regelmessige møter med oppdragsgiver. Kraft Foods hadde ikke ressurser nok til å kunne gi oss disse møtene, som burde blitt holdt en gang i uka. I perioder kunne det gå opptil flere uker før vi fikk svar på våre henvendelser. En løsning på dette problemet kunne vært å simulere kunden disse ukene, men på grunn av at det ble såpass få uker vi faktisk fikk avholdt et møte med de, så vi oss nødt til å forkaste denne metoden. Dette førte blandt annet til et tilbakesteg i utviklingen vår. Vi var nødt til å legge om strategien for prosjektet, og vi var blitt holdt igjen på grunnlag av mangelfull informasjon fra oppdragsgiver. Dermed så vi oss nødt til å benytte fossefallsmodellen. Denne modellen er absolutt ikke ideel for vårt prosjekt, som er et såpass stort og komplekst system. Men på grunn av omstendighetene med lite informasjon fra oppdragsgiver, og mye tid gått bort til å vente på svar, endte vi opp med denne modellen. Fossefallsmodellen gjennomføres i distinkte faser, hvor resultatet av hver fase danner grunnlag for arbeidet i kommende fase, samt grunnlag for beslutninger som omhandler prosjektets fremdrift. Hver fase er klart definert med både hensikt og arbeidsmessig fokus. De ulike fasene i fossefallsmetoden er forstudie, analyse, design og programmering, innføring og forvaltning. Forstudie går ut på å definere prosjektmålet, hva som skal gjøres i prosjektet. Hva bakgrunnen for at prosjektet ble satt igang er. Her definerer vi også rammebetingelsene for prosjektet, samt om prosjektet kommer til å møte spesielle utfordringer. Gruppemedlemmene får også tildelt ansvarsroller i denne perioden. En må ta det overordnede ansvaret og styre gruppen som en gruppeleder. En må stå ansvarlig for at brukergrensesnittet lever opp til forventningene, en må stå ansvarlig for at den funksjonaliteten som vi har lovet blir levert, og en må være ansvarlig for at all nædvendig dokumentasjon blir skrevet. Å ha en av rollene vil ikke si at det kun er det gruppemedlemmet som skal jobbe med den gitte oppgaven, men det er dette gruppemedlemmet som har ansvaret for at det blir gjort. I analysen skal det beskrives i detalj hva slags system som skal lages. Her skal det bestemmes hva systemet skal gjøre, hvordan det skal se ut, og hvordan det skal virke. Dette blir gjort igjennom kravspesifikasjonen vi skrev tidlig i prosjektet. Kravspesifikasjonen ble vist til oppdragsgiver i denne fasen, hvor vi opplyste dem om funksjonaliteten vi skulle legge til rette for på en slik måte at de forstod hva som skulle bli gjort. I design og programmeringsfasen definerte vi først mal på hvordan alle sidene skulle se ut. Her satte vi opp vanlige designelementer som går igjen på de fleste sidene som logo, hovedmeny, overskrifter, tabeller og lignende. Etter dette begynte vi å programmere grunnstrukturen i systemet. Dette innebar blandt annet Masterpagen (den ytre delen av applikasjonen som inneholder logo, hovedmeny, og avgrensningen til inneholdet). Funksjonalitet for å logge inn på siden, samt avgrensede områder for brukere som er logget inn, og de ulike brukergruppene. Og å sette elementene som ble definert under designutviklingen i live ved hjelp av HTML-attributter og Stilark (css). Innføringsfasen er fasen hvor vi overfører det vi har laget til oppdragsgiver. For vårt system kan vi si at målet for denne fasen er å sette systemet i daglig drift hos Kraft Foods på en slik måte at: Brukerne kan systemet Side 9

15 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem Brukerne stoler på systemet Brukerne har nytte av sytemet For at vi skal kunne infri disse målene må selvfølgelig riktig system utvikles, med riktig funksjonalitet uten feil og mangler. På grunn av at vi kom såpass sent igang med prosjektet, så vi oss nødt til å kutte ut noen av tilleggsønskene til Kraft Foods for å få systemet ferdig i tide. Her vil vi også gjennomføre en brukeropplæring på systemet, samt gjennomføre en fullstendig installasjon og import av nødvendig data / programvare på deres servere (Her inngår da programvaren for å kunne lese fra excel-filer, samt importere post-tabellen fra posten.no inn i deres database). Forvaltningsfasen går ut på at vi i tillegg til å levere det ferdige systemet til Kraft Foods, også legger ved tilstrekkelig dokumentasjon til at systemet kan holdes igang lenge etter at vi er ferdige. Denne dokumentasjonen skal blant annet bidra til at systemet vi har implementert brukes på riktig måte, og oppfører seg korrekt, uten feil og mangler. Derfor inneholder denne dokumentasjonen informasjon som er nødvendig for å kunne bruke systemet, vedlikeholde systemet og for å kunne holde det i daglig drift. Dokumentasjonen er skrevet på en slik måte at målgruppen forstår det som er skrevet. Det vi leverer til Kraft Foods av dokumentasjon er en brukermanual som inneholder brukerdokumentasjonen ment for brukerne av systemet. Her blir all funksjonaliteten beskrevet, som hvordan man setter opp ruter, hvordan man viser ruter, hvordan man legger til nye brukere, hvordan man endrer frekvensene på butikker og lignende. Vi leverer også en produktdokumentasjon som inneholder både informasjon for daglig drift av systemet, og systemdokumentasjon for å vedlikeholde og eventuelt videreutvikle systemet i senere tid. Side 10

16 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem 5 UTVIKLINGSPROSESSEN 5.1 PROSJEKTETS FASER Vi har vært igjennom flere faser under utviklingen av løsningen. Vi vil her gå igjennom de forskjellige fasene i prosjektet GRUPPEDANNELSE OG VALG AV OPPGAVE Alle gruppemedlemmene har arbeidet mye sammen i prosjekter og forskjellige fag fra før. Alle studerer også informasjonsteknologi og går i samme klasse. Dette vil si at vi kjenner hverandres styrker og svakheter godt, og vi visste dermed at samarbeidet i gruppa ville fungere bra. Da vi skulle velge oppgave så vi først igjennom forslagene fra skolen, men ingen av disse falt helt i smak. Vi var også ivrige etter å finne noe på egenhånd, slik at vi kanskje kunne skaffe oss noen referanser til senere bruk. Vi var veldig tidlig klar over at Kraft Foods hadde en mulig oppgave for oss, men vi var usikre på omfanget og trodde kanskje at oppgaven var litt liten. Etter første møte med Kraft Foods forsto vi raskt at oppgaven var veldig omfattende og et bra utgangspunkt for en hovedprosjektoppgave. Dermed valgte vi å arbeide med Kraft Foods om Ruteplanleggingssystemet som i hovedsak skulle brukes av regionssjefene. Vi ble også tildelt en intern veileder fra Høgskolen I Oslo, Alexander Yngling. Vi hadde første møte med han i midten av januar Vår kontaktperson i Kraft Foods var først Jarle Birkeli, men ble senere erstattet av Bjart Pedersen. Dette passet oss veldig bra, da det var Bjart som for over 4 år siden hadde utviklet løsningen med excel-arkene STARTFASE INNLEDENDE ARBEID Det første vi gjorde rent praktisk, etter at vi hadde dannet gruppe og funnet en oppgave, var å sette sammen en prosjekthjemmeside. Denne ble lagt på en av gruppemedlemmenes private domener. Deretter laget vi statusrapporten og en prosjektskisse som ble lagt ut på prosjekthjemmesiden i god tid før fristene gikk ut. Det ble også opprettet en dagbok som vi delte via dropbox. I denne skrev vi ned alt arbeid vi gjorde dag for dag, med dato, klokkeslett og personer som deltok. Statusrapporten og prosjektskissen ble også utarbeidet og levert. Dette ble gjort i startfasen: Prosjektdagbok Tildelt veileder Prosjekthjemmeside Statusrapport Prosjektskisse FORPROSJEKTFASE Under forprosjektet fikk vi innblikk i hvem som skulle bruke løsningen. Det viste seg at mange av brukerne ikke var spesielt datakyndige. Vi forsto derfor med en gang at brukervennlighet kom til å bli viktig. Brukerne av løsningen vil, i tillegg til regionssjefene i Krafts Foods, være ca 50 selgere og ca 120 salgsfremmere, alle med ulike datakunnskaper. Dermed kunne vi dra nytte av faget Menneske Maskin og Interaksjon som alle på gruppa har gjennomført. Vi diskuterte frem og tilbake om løsningen skulle være webbasert eller om den skulle være i form av en lokalt kjørende applikasjon. I diskusjon med oppdragsgiver kom vi frem til at en webapplikasjon uten tvil ville være det enkleste. Med tanke på at det vil være i underkant 200 brukere spredd rundt i hele Norge, vil det være tungvindt å installere et program for hver bruker. Med løsningen vi har kommet frem til trenger brukerne kun en nettleser på en datamaskin, og Side 11

17 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem et brukernavn med tilhørende passord. Dermed kan løsningen bli brukt omtrent overalt, avhengig av om dette kjører på Kraft Foods intranett eller om det blir lagt på en ekstern webserver tilgjengelig via internett. Oppdragsgiver hadde på dette tidspunktet ikke funnet ut hvilket programmeringsspråk vi kunne benytte. Derfor antok vi i forprosjektet at vi kom til å måtte skrive løsningen i PHP (PHP: Hypertext Preprocessor) og MySQL. Vi hadde fortalt oppdragsgiver at vi gjerne ville bruke ASP (Active Server Pages) eller JSP (Java Server Pages), da disse løsningene ofte blir mer oversiktelige. Vi kom frem til at vi kunne bruke ASP etter at forprosjektet var ferdig. Vi kom frem til i samarbeid med oppdragsgiver at systemet bør inneholde følgende: Mulighet for selgere og fremmere å hente rute- og kundeinformasjon. Mulighet for regionssjefene å administrere ruter, og organisere selgere og fremmere. Et grensesnitt for regionssjefene til å hente ut ulike rapporter. Mulighet for administrator å endre, slette, og legge til nye kunder. Det ble også nevnt fra oppdragsgiver at det kunne være ønskelig med ett eget GUI for mobile løsninger i fremtiden. Vi ble enige om at dette kunne implementeres hvis vi hadde tid, og at dette derfor ikke ville være i fokus. Møtene med oppdrasgiver i forprosjektfasen første til at vi fikk signert standaravtalen fra skolen. Dette er en avtale som formelt sett er mellom Høgskolen I Oslo og oppdragsgiver. Vi lagde en arbeidsplan med de forskjellige fasene i prosjektet. I dette dokumentet ble det utarbeidet grove tidsfrister for når de forskjellige fasene i prosjektet skulle være ferdig. Utifra arbeidsplanen lagde vi en fremdriftsplan med realistiske mål for når de forskjellige oppgavene i prosjektet skulle være ferdig. Alt arbeidet i forprosjektfasen førte til forprosjektrapporten. Dette dokumentet inneholder bland annet mål for prosjektet, rammebetingelser, forskjellige løsninger på oppgaven og en kort analyse av dette. Dette ble gjort i forprosjektfasen: Arbeidsplan Framdriftsplan Standaravtale Forprosjektrapport PLANLEGGINGSFASEN Det ble gjort en del planlegging i forhold til gruppemedlemmer og oppgavevalg helt i starten av prosjektet. Dette gikk i hovedsak ut på hvordan prosjektet i grove trekk skulle gjennomføres. I denne fasen hadde vi noen møter med oppdragsgiver, i tillegg ble det kommunisert mye via mail. Vi fant ut hvilke brukergrupper løsningen hadde behov for, og hvilke rettigheter disse skulle ha. Det ble i tillegg planlagt en rekke krav til systemet som la grunnlaget for kravspesifikasjonen. De viktigste kravene handlet om brukere, importering av database, funksjonalitet for regionssjefene, serverkrav, serverkapasitet og brukervennlighet. Side 12

18 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem Vi planla så godt det lot seg gjøre hvordan databaseoppbyggingen skulle se ut. Arbeidet med databasen tok lang tid, og datamodellen ble bygget opp flere ganger. Dette var på grunn av at det hele tiden dukket opp nye elementer fra oppdragsgiver som førte til at datamodellen ikke ville fungere. Det ble etterhvert laget et utkast til brukergrensesnittet som ble presentert for oppdragsgiver. Dette utkastet ble tatt godt imot, og kun noen små endringer ble gjort. Brukergrensesnittet ble laget relativt raskt i Photoshop, det vil si at vi kun viste frem bilder av hvordan løsningen ville se ut. Dette ble gjort i planleggingsfasen: Kravspesifikasjon Brukergrensesnitt Database UTVIKLINGSFASEN Som tidligere nevnt hadde vi en del kommunikasjonsproblemer i starten av prosjektet. Dette førte til at vi kom litt sent i gang med utviklingen. Men vi løste det ved at vi arbeidet hver for oss, mens vi pratet med hverandre over skype. Dersom noen trengte hjelp av de andre på gruppa bruke vi fjernhjelp som er innebygget i Windows til dette. Vi løste dette slik fordi gruppemedlemmene bor ett stykke fra hverandre, og vi slipper dermed å bruke tid på å reise. Selv om mesteparten av arbeidet ble gjort over skype, hadde vi også flere møter der alle på gruppa var samlet. Under disse møtene diskuterte vi forskjellige ting som design, brukergrensesnitt, og hvordan vi kunne løse vanskelige problemer. Under denne fasen arbeidet vi med kodingen av ruteplanleggingsverktøyet, og vi følte at i kunne konsentrere oss bedre dersom vi fikk sitte for oss selv i fred og ro TESTFASEN I testfasen fokuserte vi på å teste metoder og funksjonalitet i systemet ved hjelp av forskjellige forskjellige testmetoder. Vi begynte testingen tidlig i utviklingsprosessen, med testing av data access laget som inneholdt metoder som hentet/endret data fra databasen ved hjelp av LINQ-to-SQL. Denne testmetoden kalles white-box testing, hvor man bruker kjennskap til koden for å kjøre testene. Vi testet også brukergrensesnittet i en viss grad hos oppdragsgiver tidlig i utviklingsprosessen. Oppdragsgiver fikk se forskjellige skjermbilder av det planlagte brukergrensesnittet, og ga stort sett bare positive tilbakemeldinger, men allikevel var det noen småting som de ønsket å endre på, for eksempel hvilke menyvalg hver brukergruppe skulle ha tilgang til. Senere i utviklingsprosessen, da de fleste metodene i data access laget var ferdig laget og testet, tok vi for oss testing av presentasjonslaget. Her brukte vi såkalt black-box testing, hvor vi matet systemet med testdata for å sjekke hvilken tilbakemelding vi fikk. Validering av inputfelter, for eksempel at man prøver å sende inn en bokstav i et felt hvor bare tall er tillatt er et eksempel på denne testingen. Da får man skrevet ut en beskrivende feilmelding DOKUMENTASJONSFASEN Side 13

19 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem Denne fasen foregikk under hele prosjektet og handler om alle dokumenter som ble skrevet. I dokumentene finner man informasjon om alt fra valg av oppgave til ferdig utviklet produkt STYRINGSDOKUMENTER Med unntak av prosjektdagboken ble alle styringsdokumentene skrevet tidlig i prosjektet, denne ble skrevet fra start til slutt. I styringsdokumentasjonen inngår følgende dokumenter: Use case Use case hendelser Arbeidsplan Dagbok Forprosjekt Fremdriftsplan Gantt diagram Kravspesifikasjon Prosjektavtale Prosjektskisse Statusrapport SLUTTDOKUMENTASJON Vi startet med å skrive prosessdokumentasjonen. Denne tar for seg alle prosessene i prosjektet, fra idé til ferdig produkt. I og med at man går igjennom hele prosjektet når man skal skrive dette dokumentet, fikk vi en repetisjon og et godt overblikk over alt vi hadde gjort. Dette hjalp oss når vi skulle skrive produktdokumentasjonen fordi vi da viste i detalj hvilke prosesser vi hadde vært igjennom, og hvordan vi hadde jobbet med disse. Produktdokumentasjonen er beregnet på den teknisk ansvarlige som skal installere, vedelikeholde og modifisere systemet. Dette er en person som ikke har vært med under utviklingen av produktet og det vil dermed være meget viktig at det er beskrevet i detalj alt fra hvordan systemet er laget, til hvordan det kan videreutvikles. Det er også beskrevet hvordan systemet skal installeres, og hvilke krav som stilles til server. Dokumentet kan også være nyttig for de som eventuelt skal drive brukersupport. Brukerdokumentasjonen er beregnet på de som skal bruke systemet. Dette skal fungere som en bruksanvising, og skal beskrive hvordan man benytter seg av systemets funksjonalitet. I brukerdokumentasjonen har vi skrevet om hvilke funksjoner de ulike brukergruppene har, og hvordan de skal bruke disse funksjonene. I sluttdokumentasjon ingår følgende dokumenter: Prosessdokumentasjon Produktdokumentasjon Brukerdokumentasjon Side 14

20 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem AVSLUTNINGSFASEN Dokumentasjonen ble nedprioritert mot slutten av prosjkektet til fordel for utviklingsfasen, da vi fikk dårlig tid mot slutten. Derfor ble ca 40% av all dokumentasjon skrevet de siste 4 dagene før deadline for trykking 25. mai. Dokumentasjonen kan bære preg av dette, men alle gruppemedlemmene har jobbet på spreng for at dokumentasjonen skal holde en høy standard allikevel. Dokumentene er gjennomgått for skrivefeil, og disposisjon i rapporten er endret flere ganger for å få satt opp dokumentene i riktig rekkefølge. Dokumentene måtte også endres stilmessig, overskrifter, fonter og skriftstørrelser ble samordnet slik at dokumentene skulle se like ut. Deretter ble alle dokumentene gjort klare for levering. Vi har dessverre ikke fått implementert systemet hos oppdragsgiveren i skrivende stund. Dette er fordi utviklingsfasen kom for tett opptil deadline for prosjektrapporten. Vi må også nevne at vi var på møte hos Kraft Foods i midten av april, og da avtalte vi hva slags server oppdragsgiver måtte skaffe. På møtet vi hadde med de 23. mai hadde de enda ikke ordnet server, så det er ikke klart for implementering. Vi håper de får ordnet dette innen presentasjonen skal holdes 15. juni, slik at vi kan melde at systemet er implementert og tatt i bruk. 5.2 VALG OM OPPBYGNING OG FUNKSJONER LAGDELINGSPRINSIPP Som sagt kom vi frem til at vi skulle bruke ASP og Visual Stuido. For å få en mest mulig ryddig kode som kan vidreutvikles er det viktig å bruke ett lagdelingsprinspp. Vi hadde i begynnelsen tenkt til å bruke Model Veiw Controller (MVC). Dette er et lagdelingsprinsipp som er innebygd i Visual Studio, men siden ingen av oss hadde brukt dette før tok det for lang tid å lære dette. Vi endte dermed opp å bruke en litt mer manuell løsning, som inneholder Model, Data Access Layer (DAL) og et presentasjonslag. Dette er en metode vi har brukt før i tidligere prosjekter, som vi lærte i.net kurset, og derfor slapp vi å bruke tid på å lære oss noe nytt. Dette er en litt mer tungvindt løsning i forhold til MVC, men vi kom frem til at vi ville spare tid på å bruke ett prinsipp som vi allerede kunne. Som nevnt tidligere var vi allerede godt på etterskudd da vi begynte kodingen. Dermed prioriterte vi å komme i gang så fort som mulig, fremfor å lære oss et nytt lagdelingsprinsipp. Grunnen til at vi ikke tenkte på lagdelingsprinsipp før vi begynte med kodingen, var at vi ikke visste hvilket programmeringsspråk vi skulle bruke. Og lagdelingen vil bli noe forskjellig i forskjellige programmeringsspråk. Uansett påvirker ikke lagdelignen sluttproduktet, kun måten vi arbeider på. 5.3 PROBLEMER OG LØSNINGER Under prosjektet støtte vi på noen problemer. Under har vi skrevet ned de største problemene som oppsto SAMARBEID MED OPPDRAGSGIVER Det var som sagt noen kommunikasjonsproblemer med oppdragsgiver i starten av prosjeketet. Dette gjorde at vi tapte en del tid som skulle blitt brukt på utvikling av løsningen. Etterhvert fikk vi ny kontaktperson hos oppdragsgiver og kommunikasjonsproblemene løste seg. Vi fikk uansett god nok tid til utviklingen, men vår avtale med oppdragsgiver om å levere prosjektet innen 1. mai ble ikke holdt. Dette var ikke et stort problem for hverken oppdragsgiver eller prosjektgruppen, men vi fikk ikke like god tid på dokumentasjon og testing som vi hadde ønsket PROGRAMMERINGSSPRÅK Side 15

21 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem Det var i starten uklart hvilket programmeringsspråk vi kom til å benytte. Vi hadde valgt oss tre alternativer: PHP, ASP eller JSP. Oppdragsgiver var ikke sikker på hva slags server løsningen kom til å kjøre på. Derfor måtte de finne ut av det før vi avgjorde hvilket programmeringsspråk som ville bli brukt LAGDELING Vi hadde i utgangspunktet tenkt til å bruke Model View Controller (MVC), men da vi prøvde å sette opp dette i Visual Studio støtte vi på en del problemer. Løsningen på dette ble å forkaste MVC og gå over til en lignende løsning, som vi hadde lært i.net kurset i fjor. Istedet for å inneholde Model, View og Controller som MVC gjør, inneholder vår løsning nesten det samme (vi vet ikke navnet på denne løsningen, men det var en løsning vi lærte i foregående kurs, og den er bygget på samme prinsippet som MVC). Model inneholder samme som Model i MVC, DAL inneholder samme som Controller i MVC, og presentasjonslaget vårt inneholder det samme som View i MVC. Som vist er det bygget på samme prinsippet, men det er allikevel noen små forskjeller fra standard MVC NETTILGANG Helt i slutten av utviklingsfasen fikk et gruppemedlem problemer med internettilgangen hjemme. Dette var i forbindelse med oppgradering fra ADSL til VDSL. Gruppearbeidet har i hovedsak foregått over Skype, og vi har koblet oss til skolen via VPN for å kunne bruke Team Foundation serveren. Vi prøvde å løse nettproblemet via 3G tilkobling, men dette fungerte dårlig sammen med skolens VPN. Derfor måtte vi en periode samles hos en av gruppemedlemmene for at alle skulle kunne jobbe på prosjektet samtidig. Dette førte til at det ble litt mindre fleksibilitet i arbeidet, men det løste seg heldigvis ganske fort DATAMODELLEN Det var en del problemer under designet av datamodellen. For det første tok det lang tid før vi fikk en god oversikt over det gamle systemets datamodell, samt datamodellen fra AraWin som er databasen vi skal importere data fra. Dette gjorde at flere utkast til databasemodellen ble forkastet og mye arbeid ble dermed bortkastet. Det kom også en del ny informasjon underveis fra oppdragsgiver som første til endringer av modellen. Vi endte opp med å ha møte med oppdragsgiver, der vi ble enige om en absolutt siste frist for endringer slik at vi slapp flere tidkrevende inngrep. For å vise hva som er gjort på nytt har vi lagt med første utkast av datamodellen (se vedlegg Datamodell første utkast ) AJAX-POPUP I starten av prosjektet ble vi enige med arbeidsgiver om å bruke så mye smarte løsninger som mulig. Arbeidsgiveren hadde vel ikke så stor innsikt i hva dette egentlig betød, men gruppemeldemmene så for seg mye Ajax og JavaScript. Den største smarte løsningen vi hadde planer om å bruke var en Ajax-popup som inneholdt all informasjon om en butikk. Tanken var at når man så på en ruteoversikt og klikket på en butikk, fikk man opp ett vindu uten at siden lastet på nytt. Vinduet skulle legge seg oppå ruteoversikten og vise informasjonen direkte. Ett av gruppemedlemmene har litt mer greie på Ajax enn de andre, derfor fikk han i oppgave å lage denne løsningen. Løsningen ble laget fungerende, og data ble hentet ut fra databasen, men vi fikk ikke til å lagre endringene som skulle gjøres med dataene. Grunnen til at Side 16

22 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem dette ikke fungerte som planlagt er at ASP bruker en såkalt HTML-form for å sende informasjon imellom sidene, og når det da dukket opp en ny form inne i en annen form i HTML-koden, overskrev de hverandre. Dette førte til at vi fikk en Javascript-feilmelding. Vi kunne heller ikke droppe denne formen i den nye siden som ble inkludert, da dette ville føre til at ASP og C# koden ikke ville bli utført. Derfor måtte vi etter mye prøving og feiling innse at denne løsningen måtte fjernes og erstattes med en standard ASP.NET side. All denne jobbingen med ajax-popupen tok utrolig mye tid og krefter hos gruppemeldlemmene, og det er veldig synd at vi ikke klarte å få til en fungerende løsning på dette. Side 17

23 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem 6 KRAVSPESIFIKASJONEN OG DENS ROLLE I PROSJEKTET 6.1 ENDRINGER I KRAVSPESIFIKASJONEN Det er ikke blitt utført noen betydelige endringer i kravspesifikasjoner underveis i prosjektet. Rammebetingelsene ble såpass klart definert i startfasen, slik at vi ikke ble nødt til å endringer på kravspesifikasjonen. Det har allikevel kommet endel ønsker og innspill fra oppdragsgiver, som har ført til noe ekstra funksjonalitet, samt større endringer i datamodellen. 6.2 KRAVSPESIFIKASJON I FORHOLD TIL DESIGN OG IMPLEMENTERING Vi satt ingen klare retningslinjer for design i kravspesifikasjonen. Hovedpunktene rundt brukergrensesnitt sier at vi skal bruke ajax-løsninger og drop-down menyer og lignende. Og dette har vi gjort der det er hensiktsmessig. Kraft Foods hadde ingen store krav til brukergrensesnitt utover dette, derfor har vi fått arbeide slik vi selv ønsker på dette punktet. Vi synes allikevel at sluttproduktet holder en god standard når det gjelder brukergrensesnitt. Begrunnelsen for denne påstanden er at systemet er gjennomført med tydelige knapper, linker, kontraster og lite forstyrrende elementer for brukeren. 6.3 SAMSVAR MELLOM KRAVSPESIFIKASJON OG DET FERDIGE PRODUKTET Dette punktet er nøye gjennomgått i produktdokumentasjonen. Derfor henviser vi til hovedpunkt 8 i Produktdokumentasjonen for detaljert beskrivelse av samsvar mellom kravspesifikasjon og ferdit produkt. Kort oppsummert samsvarer sluttproduktet godt med kravspesifikasjonen. Noen punkter har fått en litt annen løsning enn forventet, men det betyr ikke nødvendigvis at det er noen dårligere løsning. Vi har på et par punkter valgt en enklere utvei grunnet dårlig tid, men i hovedsak er alle endringer fra kravspesifikasjonen gjort da vi mener alternativet er en bedre løsning på problemstillingen. Side 18

24 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem 7 OM RESULTATET Vi er veldig fornøyde med resultatet av vårt hovedprosjekt, da vi mener vi har klart å oppfylle kravene som oppdragsgiver hadde godkjent til systemet på en tilfredsstillende måte. Vi ser samtidig at det er store videreutviklingsog forbedringsmuligheter i systemet, slik at systemet kan bli enda bedre. Hadde vi hatt bedre tid i avslutningsfasen skulle vi helt klart ha gjort en del ting annerledes, men vi har klart å levere et komplett produkt og må se oss fornøyd med det. Noen punkter for funksjonalitet som oppdragsgiver kom med ønske om etter at siste kravspekk var ferdig, men som vi desverre ikke fikk tid til å gjennomføre er: Eget brukergrensesnitt for mobiltelefon, slik at man kan se sin egen rute via mobilen Mulighet til å vise ruta på et kart Utskrifter av forskjellige lister og rapporter i systemet Tilslutt mener vi at systemet har nådd målene som ble satt for en første versjon av dette produktet. Side 19

25 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem 8 TILBAKEBLIKK Vi føler at vi har fått veldig mye ut av dette prosjektet. Vi har lært mye om blant annet databaser, LINQ-to-SQL, asp.net og hvordan vi sammen kan jobbe effektivt på et større prosjekt uten at vi mister oversikten over de forskjellige delene ved hjelp av Visual Studio og Team Foundation Server. Prosjektet har også vært en spennende utfordring, hvor vi har fått muligheten til å vise at vi kan mestre å lage et meningsfylt produkt til en oppdragsgiver vi ikke var kjent med fra før. Vi har hatt en del kommunikasjonsproblemer med oppdragsgiver, noe som blir nevnt flere steder i prosjektrapporten. Dette førte til unødvendig lite tid i slutten av prosjektfasen, tid som vi kunne brukt til å forbedre det ferdige produktet og til å teste systemet eksternt hos oppdragsgiver. Vi har fått testet alt vi har kunnet fått teste internt, men skulle gjerne latt oppdragsgiver testet systemet noen uker, da det som regel dukker opp noe først når sluttbrukeren begynner å bruke systemet. Når det gjelder prosessen med utvikling av de ulike dokumentasjonsdelene, starter vi tidlig med produsering av dokumenter. Vi ønsket å fordele dette over en lengre periode, slik at ikke all dokumentasjonen måtte bli skrevet mot slutten av prosjektet. Dette klarte vi å følge ganske bra helt til programmeringsfasen begynte. Programmeringen tok overhånd på grunn av lite tid, derfor ble endel dokumentasjonsskriving i sluttfasen. Dette er ting vi føler at vi ikke fikk gjort så mye med, og vi har ikke hatt mer enn et par dager på å revidere og sluttstille prosjektrapporten før innlevering. Når vi ser tilbake på kommunikasjonsproblemene underveis i prosjektet, burde vi nok mast litt mer på oppdragsgiver for å få den informasjonen vi trengte, spesielt under datainnsamlingsfasen. Det er i hovedsak dette som førte til at vi fikk såpass lite tid på slutten da vi hele tiden underveis måtte gjøre store endringer i blant annet datamodellen på grunn av misforståelser. Dette har vi tatt stor lærdom av, og kommer til å ta med videre i prosjekter senere i arbeidslivet. Side 20

26 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem 10 KILDEREFERANSER 10.1 NETTSIDER Wikipedia - Scrum (12.mai.2011). Hentet fra Høgskolen i Sør-Trøndelag (u.å). Maler og standarder [Fossefallsmdellen]. Hentet fra Metode - Scrum: Metode - Fossefallsmetoden: Skype og Windows fjernhjelp - Skype: Windows fjernhjelp: Dropbox: Visual Studio, team Foundation og Microsoft SQL: MSDN via skoeln + skolens servere Google Docs: Facebook: MySQL Workbench: Side 21

27 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem 9 VEDLEGG 9.1 DATAMODELL FØRSTE UTKAST Den nåværende løsningen i excel inneholder 5 ark i selgertabellen ( Ansatt info, Oppsummering, Butikkinfo, Butikkinfo HZ og Snitt tid pr besøk ), og 5 ark i fremmeretabellen ( Initialer, Arawintall, Butikkinfo, Blank rute og Ansatt info). Selgertabell Ansatt info Fremmeretabell Ansatt info Side 22

28 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem Fremmeretabell Initialer Kraft foods bruker for tiden to uavhengige excel-ark for å føre ansattinformasjon om selgerne og fremmerne sine ( Fremmerne jobber for selgerne ). Vi har sett på denne løsningen, og funnet ut at det lagres mye av den samme informasjonen for både fremmere og selgere, og velger derfor å slå disse sammen til en Ansatt-tabell. Nåværende løsning er bygget på at fremmernummeret og selgernummeret starter med regionstilhørigheten, for deretter å inneholde et unikt nummer. Dette bryter med første normalform ved at verdien ikke er atomær. Vi har kommet frem til følgende tabell for å løse dette problemet. Ansattetabellen Beskrivelse av feltene: id dette er primærnøkkelen i tabellen. Vi har valgt denne løsningen istede for selger/fremmernummeret som brukt tidligere, fordi dette ville skapt problemer i tabellen da formatet på disse er forskjellig. Region_*id Dette er id en som indikerer hvilken region den ansatte tilhører. Denne variabelen blir hentet fra Regionstabellen. fornavn Fornavnet til den ansatte. etternavn Etternavnet til den ansatte. Brukergruppe_*id Dette er id en som indikerer hvilken brukergruppe den ansatte tilhører. Denne variabelen blir hentet fra Brukergruppetabellen. telefonnummer Den ansattes telefonnummer. epost Den ansattes epost (må ikke fylles ut). initialer Den ansattes initialer (hentes ut ifra fornavn og etternavn via egen funksjon). brukernavn Felt for brukernavn til systemet for den ansatte. passord Felt for passord til systemet for den ansatte. selgerhz Felt kun for selgere. Sier om det er en HZ-selger eller ikke (0 = nei, 1 = ja) HZ = Hot Zone. Fremmeretabellen Vi har laget en fremmertabell som inneholder informasjon kun for fremmere. Denne tabellen kobler samtidig fremmeren til selgeren. Side 23

29 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem Beskrivelse av feltene: Ansatt_*id Dette er id en hentet fra ansatt-tabellen til selgeren. Ansatt_*id1 Dette er id en hentet fra ansatt-tabellen til fremmeren. stillingprosent Dette er stillingsprosenten til fremmeren (sier om han har en 50% stilling, 80% stilling osv.). kommentar Evt. Kommentarer. Fremmeretabell / Selgeretabell Butikkinfo 1 av 2 Fremmeretabell / Selgertabell Butikkinfo 2 av 2 Kraft foods bruker denne løsningen i excel-arkene sine (både for fremmere og selgere), og dette forårsaker mye dobbeltlagring. For eksempel blir selgernavnet og kundenavnet repetert mange ganger, og det ligger samme informasjon i begge arkene. Siden informasjonen er lik, fant vi det best å slå disse sammen for en felles løsning. Utifra informasjonen over har vi kommet opp med følgende tabeller: Butikktabellen Følgende tabell viser informasjonen om de ulike butikkene Beskrivelse av feltene: *knr Kundenummeret til de ulike butikkene. Dette er primærnøkkelen i tabellen. kundenavn Kundenavnet. F.eks (Coop Obs Bjerke, Meny Oslo City, osv). Side 24

30 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem Region_*id Id en til regionen butikken tilhører. Adresse Adressen til kunden. Post_*postNr Postnummeret til kunden. Dette er fremmednøkkel, og er koblet til tabellen Post hvor vi henter ut poststed. Grossist:*grossistId id en til grossisten. Dette er en fremmednøkkel som er koblet til tabellen Grossist. Profil_*profilId id en til profilen. F.eks (Kiwi, Coop Mega,osv). Besøksfrekvens Dette er et tall som sier hvor ofte butikken besøkes i uka (1,0 = en gang i uka, 0,5 = annenhver uke, osv). tidibutikkperbesøk Antatt tid brukt i butikken (i minutter). Grossisttabellen Følgende tabell viser oversikt over alle grossistene. Beskrivelse av feltene: *grossistid Id en til de forskjellige grossistene. Navn Grossistnavnet. Kjede_*kjedeId Id en til kjeden grossisten er koblet til. Dette er en fremmednøkkel som er koblet til Kjedetabellen. Kjedetabellen Tabell som viser en oversikt over alle kjedene. Beskrivelse av feltene: *kjedeid Id en til kjeden. Navn Navnet til kjeden. Profiltabellen Tabell som viser en oversikt over alle profilene i systemet. Beskrivelse av feltene: *profilid Id en til profilen. Navn Navnet til profilen. Kjede_*kjedeId Fremmednøkkel som kobler profilen til kjeden. Denne er hentet fra Kjedetabellen. Posttabellen Posttabellen som er en oversikt over alle postnummer og poststeder i norge (hentes direkte og lastes ned fra posten.no). Side 25

31 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem Beskrivelse av feltene: *postnr Postnummeret. Fungerer som primærnøkkel og er unik for alle instansene i tabellen. Poststed Poststedet postnummeret tilhører. Fylke Fylket postnummeret tilhører. I tillegg så vi oss nødt til å opprette endel andre tabeller for å kunne følge alle normalformer, og for å lage en riktig databasemodell. Følgende tabeller er blitt opprettet i tillegg: SelgerButikk Dette er en tabell som kobler de ulike butikken til hver enkelt selger (hvilken butikk selgeren har ansvaret for), samt hvis selgeren eventuelt har en fremmer i denne butikken. Beskrivelse av feltene: Butikk_*kNr Kundenummeret til butikken. Dette er en del av primærnøkkelen. Ansatt_*id Id en til selgeren som har ansvaret for butikken. Dette er en del av primærnøkkelen. Ansatt_*id1 Hvis selgeren eventuelt har en fremmer på denne butikken, er dette id en til denne fremmeren. Regiontabellen Dette er en tabell som holder oversikt over de ulike regionene Kraft Foods opererer med, samt navnet på disse. Beskrivelse av feltene: *id Dette er regions iden. Denne blir brukt i blandt annet Ansattabellen og Butikktabellen for å si hvilken region disse tilhører. Navn Navnet på regionen. Brukergruppetabellen Dette er en tabell som lister opp de ulike brukergruppene med tilhørende tilgang til systemet (Eksempler på brukergrupper: Regionssjef, vareleveringsansvarlig, Selger, osv): Beskrivelse av feltene: *id Dette er den unike id en til brukergruppen. Tittel Tittelene på brukergruppen (Eksempel: Regionssjef). Tilgang_*id id en til tilgangen denne brukergruppen har (Hva denne brukergruppen skal ha tilgang til å gjøre i systemet). Hvis f.eks Regionssjef og Vareleveringsansvarlig skal ha samme tilgang i systemet, uten å ligge i samme brukergruppe (varleveringssjef er ikke en regionssjef). Side 26

32 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem Tilgangtabellen Tabell for å holde rede på de ulike tilgangsnivåene i systemet. Beskrivelse av feltene: *id Den unike id en for hvert enkelt tilgangsnivå. Navn Navnet på tilgangen (Ulike nivåene). Etter å ha defintert alle tabellene, og koblet disse sammen endte vi opp med følgende databasemodell: Side 27

33 Prosessdokumentasjon Prosjekt nr Ruteplanleggingssystem Side 28

34 Kravspesifikasjon Prosjekt nr Ruteplanleggingssystem RUTEPLANLEGGINGSSYSTEM KRAVSPESIFIKASJON Prosjekt 18 Jørgen Mobekk Sørensen Morten Evje Tor Andreas Baakind Anders Gabrielsen Side 1

35 Kravspesifikasjon Prosjekt nr Ruteplanleggingssystem CONTENTS 1 Innledning Presentasjon Om bedriften Bakgrunn for prosjektet Veiledning Forord Leserveiledning Beskrivelse av systemet Brukergrupper og funksjonalitet Systemet skal ha følgende brukergrupper: Administratoren skal ha følgende funksjoner tilgjengelig: Regionsjefen skal ha følgende funsksjoner tilgjengelig: Selgeren skal ha følgende funksjoner tilgjengelig: Fremmeren skal ha følgende funksjoner tilgjengelig: Oppdeling av systemet Systemet skal inndeles i følgende hoveddeler: Spesiell funksjonalitet... 7 Ruteplanleggingsdelen skal ha følgende funksjonalitet: Datalagring Rammebetingelser Sikring mot tap, ødeleggelse, tyveri og misbruk av data Risiko Tyveri og misbruk Serverkrav og kapasitet Plattform Nødvendige utvidelser Kapasitet Fremtidig utvidelse av systemet... 8 Side 2

36 Kravspesifikasjon Prosjekt nr Ruteplanleggingssystem 4.4 Bruk og brukervennlighet Brukergrensesnitt Begrensning av data som vises Datamodell Krav til datamodell Krav til systemkonstruksjon Programmeringsspråk Programstruktur og lagdeling Variabelnavn Krav til manuelle funksjoner Manuelle funksjoner for brukergruppen regionsjef Manuelle funksjoner for brukergruppen selger Manuelle funksjoner for brukergruppen fremmer Dataordbok Forklaring av brukergrupper Regionsjef Selger Fremmer Side 3

37 Kravspesifikasjon Prosjekt nr Ruteplanleggingssystem 1 INNLEDNING 1.1 PRESENTASJON Vår arbeidsgiver, Kraft Foods AS, styrer i dag salgsrutene sine i en tung og avansert løsning basert på Excel-ark. Vår hovedoppgave er derfor å lage en webbasert løsning, som skal erstatte det gamle systemet. 1.2 OM BEDRIFTEN Kraft Foods er en av Nordens ledende næringsmiddelbedrifter med ca ansatte i fire fabrikker. Deres sterke varemerker gjør dem til markedsleder innen kategoriene sjokolade, kaffe, kjeks og andre matvarer. Kraft Foods produserer blant annet varemerkene Freia, Philadelphia og Oboy. 1.3 BAKGRUNN FOR PROSJEKTET Regionssjefene i Kraft Foods benytter seg i dag av en løsning basert på regneark for å organisere selgere, ruter, butikker og kunder. Systemet holder i hovedsak oversikt over hvilke selgere og fremmere som har ansvar for hvilke butikker, og organiserer dagsruter for disse. Systemet brukes også til å lage rapporter av ulike slag. Dagens løsning åpner for mange feil, da de må utføre manuell versjonskontroll. De har også en kundedatabase med ca 4000 kunder som kommuniserer med excel-arkene. Side 4

38 Kravspesifikasjon Prosjekt nr Ruteplanleggingssystem 2 VEILEDNING 2.1 FORORD Kravspesifikasjonen definerer krav og betingelser for prosjektet Ruteplanleggingssystem. Mål og problemstillinger er tilpasset Kraft Foods behov, men konkrete løsninger og rammebetingelser er utarbeidet av prosjektgruppen. Dokumentet er en veiledning for utviklerne i prosjektgruppen, slik at systemet blir tilpasset arbeidsgiverens behov. 2.2 LESERVEILEDNING Dette dokumentet er delt opp i hoveddeler som beskriver hva slags egenskaper som skal bestemmes. Underpunkter med mye data er oppdelt i punktlister, og dette definerer krav for hovedfunksjonene i dokumentet. Punkt 3 Beskrivelse av systemet definerer systemets hovedfunksjoner. Side 5

39 Kravspesifikasjon Prosjekt nr Ruteplanleggingssystem 3 BESKRIVELSE AV SYSTEMET Ruteplanleggingssystemet skal være ett forenklet alternativ til dagens løsning med excel-ark. Systemet skal tilby samme funksjonalitet som utgangspunktet, men skal samtidig designes på en slik måte at det er enklere i bruk. Der det er mulig skal det brukes dropdown-menyer og auto-søk funksjoner, slik at brukeren ikke trenger å huske kundenummer og andre relevante data. Det skal være enkelt å søke opp informasjonen man trenger, slik at brukeren får en enklere navigering av systemet. Informasjonen som vises må også begrenses, slik at brukeren får færre forstyrrende elementer. 3.1 BRUKERGRUPPER OG FUNKSJONALITET SYSTEMET SKAL HA FØLGENDE BRUKERGRUPPER: Administrator Regionsjef Selger Fremmer ADMINISTRATOREN SKAL HA FØLGENDE FUNKSJONER TILGJENGELIG: Ett grensesnitt for import av data fra AraWin via Exceldokument REGIONSJEFEN SKAL HA FØLGENDE FUNSKSJONER TILGJENGELIG: Oversikt over butikker, selgere og fremmere avgrenset til sin region. Mulighet til å administrere hvilke fremmere som jobber under hvilke selgere. Mulighet til å administrere ruteoversikten for en gitt selger. Det vil si en oversikt over hvilke butikker en gitt selger skal besøke i løpet av en dag. Her vil det være en fordel med muligheten til å veksle mellom dags, ukes og månedsvisning. Etter administratoren har importert ny data, må systemet si ifra om butikker som ikke har tilegnet selgere og fremmere, slik at brukeren enkelt kan holde oversikt over hva som er oppdatert SELGEREN SKAL HA FØLGENDE FUNKSJONER TILGJENGELIG: Mulighet til å se hvilke fremmere som jobber under seg, og kontaktinformasjon for disse. Mulighet til å se hvilke butikker som inngår i selgerens ansvarsområde. Mulighet til å hente ut kontaktinformasjon og addresse for butikkene i sitt ansvarsområde. Mulighet til å se hvilke dagsruter regionsjefen har planlagt. Mulighet til å se en liste over butikker som er spesielle for denne måneden. Såkalte sesongbutikker FREMMEREN SKAL HA FØLGENDE FUNKSJONER TILGJENGELIG: Mulighet til å se oversikt over dagsrutene, og kontaktinformasjon for butikkene som skal besøkes. 3.2 OPPDELING AV SYSTEMET Side 6

40 Kravspesifikasjon Prosjekt nr Ruteplanleggingssystem SYSTEMET SKAL INNDELES I FØLGENDE HOVEDDELER: Butikker Selgere Fremmere Ruter Rapporter 3.3 SPESIELL FUNKSJONALITET RUTEPLANLEGGINGSDELEN SKAL HA FØLGENDE FUNKSJONALITET: Brukeren velger fra en meny hvilken selger han skal planlegge rute for. Etter at selger er valgt, får man opp en timeplan som dekker gjeldende måned. Brukeren kan velge å opprette en ny måned, som legger seg etter gjeldende måned. Måneden som opprettes skal være ferdig planlagt, basert på butikkenes informasjon om ukedager og besøksfrekvens. Hvis brukeren flytter på en oppføring som er autogenerert, skal det gis spørsmål om dette er en permanent endring, eller spesielt for denne måneden. Svarer brukeren at det er permanent, skal butikkinformasjonen oppdateres slik at den autogenereres på riktig sted neste gang. Hvis brukeren ønsker det, skal det kunne vises kun en eller to uker. På butikker som kun skal besøkes i sesong, skal disse komme opp i en egen to-do liste ved siden av de faste rutene. En ruteoppføring består av Butikknavn, Tid i butikk, Eventuell fremmer og fremmerens tid. Hvis det kun er fremmeren som skal besøke butikken denne dagen, vil Tid i butikk bli satt til null, og fremmerens tid til det antallet minutter fremmeren har til rådighet. En ruteoppføring knyttes til en gitt ukedag, og før eller etter lunch. Ingen tidspunkt skal benyttes. Men total tid før og etter lunch bør vises. 3.4 DATALAGRING Bedriften bruker ett datasystem som heter AraWin til å lagre informasjon om kunder, kjeder, grossister, selgere og områdene disse tilhører. Av sikkerhetsmessige årsaker kan ikke webløsningen kobles til denne databasen, og i utgangspunktet har vi kun tilgang på en dump fra AraWin til ett excel-ark. Dette betyr at løsningen som skal utvilkes må ha ett adminpanel hvor databasen kan oppdateres via import fra excel. Systemet vårt skal derfor ikke ha mulighet til å endre kundeinformasjon. Dette må oppdateres av bedriften i AraWin, og deretter importeres til systemet. Men systemet må også ha en egen database for lagring av den importerte dataen, samt all informasjon om rutesystemet. Side 7

41 Kravspesifikasjon Prosjekt nr Ruteplanleggingssystem 4 RAMMEBETINGELSER 4.1 SIKRING MOT TAP, ØDELEGGELSE, TYVERI OG MISBRUK AV DATA RISIKO Kraft Foods benytter seg som nevnt av en databaseløsning driftet av ett eksternt firma. Dermed må vi ta utgangspunkt i at disse allerede har gode rutiner for backup av kundedatabasen. Systemet vi lager vil lagre mye informasjon som genereres automatisk ut ifra kundedatabasen deres, derfor innebærer systemet relativt lav konsekvens for tap av data. Når en måned i ruteplanleggeren opprettes, lages rutene automatisk ut ifra data som allerede er lagret, og dette kan enkelt gjøres på nytt. Men allikevel tar dette tid, og det må utarbeides rutiner for backup av serveren som systemet skal kjøres på TYVERI OG MISBRUK Systemet må utvikles på en så sikker måte som mulig. Det må kontrolleres for sql-injection og all input må valideres. I tillegg må det sørges for at excel-dokumentet som importeres har en slags signatur, slik at det ikke er mulig å importere feil data. Brukertilgangen skal også tilpasses etter least-privilege prinsippet, altså at brukerene kun har tilgang til den informasjonen som er høyst nødvendig, og ikke kan endre informasjon som ikke er absolutt nødvendig å endres på. 4.2 SERVERKRAV OG KAPASITET PLATTFORM Serveren må støtte ASP.NET med Microsoft.NET Framework 4.0 og SQL Server Fortrinnsvis en Microsoft server, men det er også mulig å få dette til å fungere under Linux NØDVENDIGE UTVIDELSER For import av Exceldokumenter kreves det ett programtillegg som kan lastes ned fra Microsoft sine websider. Se produktdokumentasjon, punkt 10.3 Nødvendige utvidelser av server, side KAPASITET Systemet vil ikke stille store krav til serverkapasitet. All data som lagres er tekstbasert, og krever derfor ikke stor lagringsplass. Det vil heller aldri bli mange brukere som bruker systemet hardt på en gang, derfor stilles det heller ikke store krav til prosessorkraft og minne på serveren. 4.3 FREMTIDIG UTVIDELSE AV SYSTEMET Oppbygningen av systemet må følge en fornuftig struktur, og bygges med en ryddig lagdeling slik at videreutvikling er mulig. Kraft Foods selv overtar ansvar for videre utvikling og drift av systemet. 4.4 BRUK OG BRUKERVENNLIGHET BRUKERGRENSESNITT Side 8

42 Kravspesifikasjon Prosjekt nr Ruteplanleggingssystem Systemet bør følge retningslinjer for oppbygning av brukergrensesnitt. Herav plassering av knapper og dialoger, slik at brukeren skal få færrest mulig forstyrrende elementer, uten å miste funksjonalitet. Det skal også brukes hjelpefunksjoner som drop-down menyer, autofullfør, smarte søk og andre relevante hjelpemidler BEGRENSNING AV DATA SOM VISES Dagens løsning gir ekstremt mye data til brukeren på en gang. Dette ønsker Kraft Foods at vi klarer å begrense, slik at kun nødvendig informasjon vises til brukeren. I tillegg skal kun relevant data være mulig å endre på. Dagens løsning har åpne felter slik at det enkelt kan gjøres endringer som ikke skulle vært gjort. Side 9

43 Kravspesifikasjon Prosjekt nr Ruteplanleggingssystem 5 DATAMODELL 5.5 KRAV TIL DATAMODELL Datamodellen må oppfylle 3. normalform. Side 10

44 Kravspesifikasjon Prosjekt nr Ruteplanleggingssystem 6 KRAV TIL SYSTEMKONSTRUKSJON 6.1 PROGRAMMERINGSSPRÅK Systemet skal programmeres i ASP.NET og C# 6.2 PROGRAMSTRUKTUR OG LAGDELING Programmet skal struktureres på en ryddig og oversiktelig måte, og følge ett lagdelingsprinsipp som gjør videreutvikling og oversikt enklest mulig. 6.3 VARIABELNAVN Variabelnavn skal være beskrivende, og inneholde referanse til objektet det er en variabel av. Er det en label skal variabelen ha navn labelkundenummer eller lignende. Side 11

45 Kravspesifikasjon Prosjekt nr Ruteplanleggingssystem 7 KRAV TIL MANUELLE FUNKSJONER 7.1 MANUELLE FUNKSJONER FOR BRUKERGRUPPEN REGIONSJEF Mulighet til å ta utskrift av alle rapporter som er tilgjengelig gjennom systemets rapportgenerator. Mulighet til å ta utksrift av alle dagsruter. Mulighet til å ta utskrift av kontaktinformasjon for selgere og fremmere. 7.2 MANUELLE FUNKSJONER FOR BRUKERGRUPPEN SELGER Mulighet til å skrive ut sin aktuelle dagsrute. Mulighet til å skrive ut kontaktinformasjon om kunden som skal besøkes. Mulighet til å skrive ut kontaktinformasjon om fremmere som arbeider under seg. 7.3 MANUELLE FUNKSJONER FOR BRUKERGRUPPEN FREMMER Mulighet til å skrive ut sin aktuelle dagsrute. Mulighet til å skrive ut kontaktinformasjon om kunden skal besøkes. Mulighet til å skrive ut kontaktinformasjon om selgeren som er vedkommendes overordnede. Side 12

46 Kravspesifikasjon Prosjekt nr Ruteplanleggingssystem 8 DATAORDBOK 8.1 FORKLARING AV BRUKERGRUPPER REGIONSJEF Personen som i utgangspunktet styrer hele systemet. Regionsjefen er den eneste av de tre vanlige brukerne som skal ha mulighet til å endre data på ruteplanleggingsdelen SELGER Selgeren er regionsjefens produktpromotør i ett gitt geografisk område. I systemet har han kun mulighet til å se hvilke dagsruter regionsjefen har satt opp for selgeren og de fremmere som jobber under selgeren FREMMER Fremmerens oppgave er å fylle på varer i butikkene. I systemet skal han bare se sin egen dagsrute og kontaktinformasjon til selgeren han jobber for. Side 13

47 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem RUTEPLANLEGGINGSSYSTEM PRODUKTDOKUMENTASJON Prosjekt 18 Jørgen Mobekk Sørensen Morten Evje Tor Andreas Baakind Anders Gabrielsen Side 1

48 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem 1 FORORD Produktdokumentasjonen er ment for de som skal vedlikeholde, installere og videreutvikle systemet. Dokumentet tar for seg alle programmets hoveddeler og deres oppbygning og prinsipper, og er ment for å gi ITansvarlig ett innblikk i hvordan systemet er bygd opp. Dokumentet vil inneholde noen faguttrykk, og det forventes at den som leser dette har kunnskaper om objektorientert programmering, konfigurasjon av servere og over gjennomsnittelige kunnskaper om installasjon og drift av ett datasystem. Side 2

49 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem INNHOLDSFORTEGNELSE 1 Forord Innledning Bakgrunn for produktet Hensikt med prosjektet Kort beskrivelse av resultatet Teknologi Rammebetingelser Nødvendige verktøy Forhold til nettlesere Datastruktur Om datamodellen Beskrivelse av fremgangsmåte og bakgrunn Beskrivelse av normaliseringsformer Datamodell Tabellforklaringer Bruker Brukergruppe Region Fremmer Fremmerbutikk Selger Modul Butikk Butikkmodul Post Ekskludering Ukedag Side 3

50 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem 4.4 Kommunikasjon med databasen Programstruktur Retningslinjer Lagdelingsprinsipper Objektorientert programmering Bruk av ferdigkode AjaxLoad Nødvendige verktøy for eventuell videreutvikling Brukergrensesnitt Guidelines for GUI Tekst Farger Linker Tabeller Knapper Forsidene Presentasjon av programmets hoveddeler Innledning Regionsjefdelen Hovedmenyen til Regionsjef Hjem Selgere og fremmere Ruter Kunder Rapporter Selgerdelen Hjem Fremmere Ruter Side 4

51 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Kunder Fremmerdelen Ruter Kunder Administratordelen Hjem Oppdater system Brukeradministrasjon Samsvar mellom kravspesifikasjon og produkt Systemets oppbygning Funksjonalitet Administratorens funksjonalitet Regionsjefens funksjonalitet Selgerens funksjonalitet Brukervennlighet Oppsummering Programmets oppbygning og virkemåte Oppbygning Virkemåte Oppbygning i Visual Studio Mappestruktur for publisering Rotmappe Admin bin Design error Fremmer js Rapport Side 5

52 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Regionsjef scripts Selger Innstallasjon Forhold til maskiner, lagerplass, operativsystemer o.l Serverplattform Klientplattform Nødvendige utvidelser av server Hardwarekapasitet Tilpasning til nettlesere Internet Explorer Javascript Kildehenvisninger Nettsider Ajaxload Figurliste Vedlegg Vedlegg 1 - Sql-setning for opprettelse av database Side 6

53 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem 2 INNLEDNING 2.1 BAKGRUNN FOR PRODUKTET Kraft Foods AS har i flere år basert hele ruteplanleggingsoppgaven på en løsning laget i Excel. Løsningen har mange gode egenskaper, og jobben blir gjort, men den er lite effektiv og gjør at arbeidsoppgavene tar lenger tid enn nødvendig. Den gamle løsningen hadde heller ingen versjonskontroll, slik at Exceldokumentene ble sendt på rundgang uten at noen egentlig hadde helt oversikt over hvilken versjon som var oppdatert. Dette skaper fort problemer. 2.2 HENSIKT MED PROSJEKTET Vår oppgave ble da naturligvis å lage et system som løser disse problemene. I samarbeid med oppdragsgiver ønsket vi å lage et system som gjorde hverdagen enklere for Regionsjefene i Kraft Foods AS, samtidig som all funksjonalitet ble bevart. Dette løste vi ved å lage en nettbasert løsning, som tilbyr omtrent den samme funksjonaliteten på en enklere måte. Dette dokumentet beskriver løsningen og dens oppbygning i detalj. 2.3 KORT BESKRIVELSE AV RESULTATET Programmets tittel Ruteplanleggingssystem avslører hva programmet har som hovedoppgave. Systemet er skreddersydd til Kraft Foods Norges behov og ønsker, og holder oversikt over bedriftens selgere, fremmere, kunder og forholdet mellom disse. Systemets hovedfunksjonalitet brukes av bedriftens fire regionssjefer, men også selgere og fremmere skal ha mulighet til å hente ut data fra systemet. Kundene er bare en tredjepart i systemet og har ingen tilgang til informasjonen som lagres. Bedriftens selgere og fremmere reiser rundt i butikkene og håndterer varer. Systemets hovedoppgave er å gi regionssjefen en mulighet til å fortelle aktørene hvilken butikk som skal besøkes til en gitt tid. Denne problemstillingen er løst i form av en kalenderløsning, som gir oversikt over en selgers dagsruter. Denne kalenderen blir automatisk generert ut ifra data Regionsjefen taster inn. Henholdsvis besøksfrekvens, startuke, ukedager og ekskluderingsuker. Systemet bruker så disse dataene til å lage en ukesvisning av selgeren og fremmerens rute. Vi har diskutert flere mulige løsninger med arbeidsgiver, og vi mener til slutt at dette er den beste og enkleste løsningen. Ut over kalenderløsningen har systemet mulighet for utskrift av rapporter, oversikt over antall besøk til de forskjellige butikkene, vedlikehold av brukernavn, passord og andre relevante data. En viktig detalj å nevne ved systemet er at det baserer seg på input fra bedriftens nåværende databasesystem kalt AraWin. Informasjon om hvilke selgere som tilhører hvilke butikker og ansvarsområder hviler alene på input fra AraWin, og kan ikke endres i dette systemet. Mer om dette senere i dokumentet. Side 7

54 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem 3 TEKNOLOGI 3.1 RAMMEBETINGELSER Arbeidsgiver hadde ingen nøyaktige krav til bruk av teknologi. De ønsket seg et nytt datasystem, og vi ble til slutt enige om at en nettbasert løsning var enklest å bruke og vedlikeholde da alt ligger på en server. Vi endte opp med å velge en løsning i ASP.NET, da vi mener dette kvalifiserer best til videreutvikling, samtidig som det er ryddig og oversiktelig å jobbe med. IT-avdelingen gav oss også inntrykk av å ha best kunnskap rundt Microsoftprodukter, derfor falt ASP.NET som det mest naturlige valget. Ett annet argument for å velge ASP.NET, var muligheten for å importere Excel-ark. Systemet baserer seg som sagt på import av data fra AraWin, og dette kommer i Excel-dokumenter. Vi ønsket også å gjøre ting så enkelt som mulig, henholdsvis ved bruk av AJAX og dynamiske kontrollere. AJAX lar oss laste inn data uten at brukeren ser at siden lastes på nytt. Dette gjør at systemet virker kjappere og mer strømlinjeformet, og gjør det enklere å bruke. 3.2 NØDVENDIGE VERKTØY Til utvikling av systemet har vi brukt Microsoft Visual Studio 2010, og det anbefales at en eventuell videreutvikling av systemet foretas i samme utviklingsmiljø. Alternativt kan Microsoft Visual Web Developer benyttes, som er en gratisvariant av Visual Studio ment for webutvikling. Prosjektgruppa har ikke testet dette, så vi anbefaler ikke å benytte denne programvaren. Databasen er bygd i Microsoft SQL, og den innebygde SQLeditoren i Visual Studio har lite funksjonalitet, derfor har vi brukt EMS MsSQL Manager til å administrere databasen da dette har vært nødvendig. 3.4 FORHOLD TIL NETTLESERE Oppdragsgiveren sverger til Internet Explorer, derfor har dette blitt nettleseren i hovedfokus. Vi har testet systemet i IE7 og IE8, da Kraft Foods vil gå over til IE7 fra IE6 rett etter produktet vårt skal være ferdig. Vi har allikevel lagt vekt på at systemet skal fungere i både Firefox og Opera. Side 8

55 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem 4 DATASTRUKTUR 4.1 OM DATAMODELLEN BESKRIVELSE AV FREMGANGSMÅTE OG BAKGRUNN Nåværende løsning i Excel bruker data som er eksportert ut fra et annet system kalt AraWin. Denne eksporten blir lagt i et nytt Excelark som inneholder en lang liste med all nødvendig informasjon om både ansatte, regioner, kunder og hvilke ansatte som er koblet til hvilke kunder. Det er denne løsningen vi skal bygge opp. I deres Excelløsning er det mye dobbeltlagring av data som omhandler selgere og kunder, samt hvis en kunde for eksempel endrer kundenummer vil det være en svært tidskrevende operasjon og se til at dette også blir gjort overalt i systemet. Dette kan føre til feil ved at informasjonen ikke blir oppdatert på et eller flere steder, og dataene vil da ikke samsvare med hverandre. Vi har valgt å bygge opp en løsning, som vil sikre at dataene til enhver tid er oppdatert over hele systemet, samt gjøre oppdatering og vedlikehold mye enklere. Datamodellen vår vil tilpasses slik at eksporten fra AraWin vil kunne importeres direkte inn i vårt system på en enkel måte. Før vi begynner å se på datamodellen, må vi huske på at det finnes en teknikk for design av tabeller slik at man minimerer duplisering av informasjon. Dette kalles normalisering. Hvis man lagrer den samme informasjonen på flere ulike steder, risikerer man at en endring kan føre til en inkonsistent database. Et eksempel på dette kan være hvis en adresse er lagret på flere steder i tabellen og man endrer adressen på ett av stedene, kan man ikke vite hvilken adresse som er den riktige. Det finnes flere normaliseringsgrader, fra første normalform til Boyce-Codd normalform, og hvis man ønsker en høy normaliseringsgrad, fører dette ofte til flere tabeller i databasen BESKRIVELSE AV NORMALISERINGSFORMER FØRSTE NORMALFORM (1NF) En tabell oppfyller første normalform hvis den ikke inneholder ikke-atomære verdier. Ikke-atomære verdier vil si verdier som inneholder flere delverdier, for eksempel fornavn og etternavn i samme felt ANDRE NORMALFORM (2NF) En tabell oppfyller andre normalform hvis den oppfyller kravene til første normalform i tillegg til at alle verdier er fullt funksjonelt avhengig av primærnøkkelen. Dette vil si at en verdi må bare være avhengig av hele primærnøkkelen, ikke bare deler av den TREDJE NORMALFORM (3NF) En tabell oppfyller tredje normalform hvis den oppfyller kravene til andre normalform i tillegg til at man ikke har noen transitive avhengigheter. Dette betyr at en verdi ikke kan være avhengig av andre verdier enn primærnøkkelen. Side 9

56 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Et eksempel på dette kan være hvis man har en tabell med informasjon om en kunde, kundens kundenummer (som er primærnøkkel i dette eksempelet), postnummer og postadresse i samme tabell. Her blir poststedet avhengig av postnummeret som ikke er primærnøkkel, og dette bryter med tredje normalform BOYCE-CODD NORMALFORM (BCNF) En tabell oppfyller Boyce-Codd normalform hvis den oppfyller kravene til tredje normalform i tillegg til at alle determindanter må være kandidatnøkler. 4.2 DATAMODELL Databasen er en standard Microsoft SQL Server relasjonsdatabase, og består av 12 tabeller. Figuren under viser databasens oppbygning: Side 10

57 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 1 - Datamodell Side 11

58 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem 4.3 TABELLFORKLARINGER Under følger en beskrivelse av hensikten med alle tabellene, samt et utdrag av dokumentet datamodell med beskrivelse av alle feltene i tabellene BRUKER Tabellen lagrer all data om en Bruker i systemet. BrukerID - Primærnøkkelen til tabellen Bruker. Region_RegionID - Fremmednøkkel fra tabellen Region. AnsattNR - Deres ansatt-nr internt på kraft foods. Fornavn - Fornavnet til brukeren. Etternavn - Etternavnet til brukeren. Brukergruppe_BrukergruppeID - Fremmednøkkel fra tabellen Brukergruppe. Telefonnummer - Telefonnummeret til brukeren. Epost - Epostadressen til brukeren. Initialer - Initialene til brukeren. Brukernavn - Brukernavnet til brukeren på systemet. Passord - passordet til brukeren på systemet (kryptert). Figur 2 - Brukertabell BRUKERGRUPPE Brukergruppe betyr henholdsvis 1:Administrator, 2: Regionsjef, 3: Selger, 4: Fremmer. BrukergruppeID i tabellen Bruker, viser hvilken brukergruppe gitt bruker har. BrukergruppeID - Primærnøkkelen til tabellen Brukergruppe. Tittel - Tittelen til brukergruppen (f.eks: Regions sjef, Selger, Fremmer). Figur 3 - Brukergruppetabell Side 12

59 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem REGION Region angir hvilken region RegionID i tabellen Bruker, en bruker er koblet til. RegionID - Primærnøkkelen til tabellen Region. Navn - Navnet på regionen (f.eks: Øst, Vest, Nord, Sør). Figur 4 - Regiontabell FREMMER Hvis en gitt bruker har fått brukergruppe Fremmer, lages det en oppføring i Fremmertabellen med BrukerID fra Brukertabellen. FremmerID - Primærenøkkelen til tabellen Fremmer. Bruker_BrukerID - Fremmednøkkel fra tabellen Bruker som kobler en brukerprofil til fremmeren. Stillingprosent - Et tall som angir arbeidsmengden til fremmeren ( 25 = 25% stilling, 80 = 80% stilling). Kommentar - Eventuelle kommentarer om fremmeren. Figur 5 - Fremmertabell FREMMERBUTIKK Angir en fremmers kobling til en butikk. Butikk_KundeNr Primærnøkkelen hentet fra tabellen Butikk, som indikerer hvilken butikk fremmeren er satt opp på. Fremmer_FremmerID Primærnøkkelen hentet fra tabellen Fremmer, indikerer hvilken fremmer det gjelder. Figur 6 Fremmerbutikktabell Side 13

60 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem SELGER Hvis en gitt bruker har fått brukergruppe Selger, lages det en oppføring i Selgertabellen med BrukerID fra Brukertabellen. SelgerID - Primærnøkkelen til tabellen Selger. Bruker_BrukerID - Fremmednøkkel fra tabellen Bruker som kobler en brukerprofil til selgeren. SelgerHZ - Et tall (0 = ikke HZ, 1 = HZ), som indikerer om selgeren er en HZ selger eller ikke (dette for enkelt å finne alle HZ selgerne i systemet). Figur 7 - Selgertabell MODUL Modul er selgerens ansvarsområde. En selger er koblet til en modul, og flere butikker er koblet til selgeren via denne modulen. ModulNR - Primærnøkkelen til tabellen Modul. Selger_SelgerID: Fremmednøkkel fra tabellen Selger. Dette er id'en til selgeren som eier modulen. Figur 8 - Modultabell Side 14

61 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem BUTIKK Tabellen butikk lagrer all data om en butikk. Figur 9 - Butikktabell KundeNR - Primærnøkkelen til tabellen Butikk. Kundenavn - Navnet på butikken. Adresse - Adressen til butikken. Telefonnummer Telefonnummeret til butikken. Telefax telefaxnummeret til butikken. Post_PostNr - Fremmednøkkel fra tabellen Post, som inneholder postnummeret til butikken. ForEtterLunsj - Et tall (0 = før, 1 = etter), som indikerer om butikken skal besøkes før eller etter lunsj. Selgerfrekvens Et desimaltall som indikerer hvor ofte selgeren skal besøke butikken. SelgerFremmerfrekvens Et desimaltall som indikerer hvor ofte selgeren selv opererer som en fremmer. Fremmerfrekvens Et desimaltall som indikerer hvor ofte fremmeren skal besøk butikken SelgerHZfrekvens Et desimaltall som indikerer hvor ofte HZselgeren skal besøke butikken. Selger_SelgerID - Fremmednøkkel fra tabellen Selger. Denne id'en settes kun hvis butikken har en HZ selger. Sesong - 0 = ikke sesongbutikk, 1 = sesongbutikk. Hvis sesongbutikk, ikke vises på samme måte som de andre butikkene. TonnPeriode1 Tall hentet fra AraWin, og sier hvor mye tonn som ble distribuert til butikken i 1.periode. TonnPeriode2 Tall hentet fra AraWin, og sier hvor mye tonn som ble distribuert til butikken i 2.periode. Kommentar Eventuelle kommentarer til butikken. TidIButikkSelger Tid i minutter som selgeren bruker i butikken. TidIButikkSelgerFremmer Tid i minutter som selgeren bruker i butikken som fremmer. TidIButikkFremmer Tid i minutter som fremmeren bruker i butikken TidIButikkSelgerHZ tid i minutter som HZ-selgeren bruker i butikken. StartukeSelger Ukenummer som frekvensen for selgeren starter. StartukeSelgerFremmer Ukeummer som frekvensen for selgeren som fremmer starter. StartukeFremmer Ukenummer som frekvensen for fremmeren starter. StartukeSelgerHZ Ukenummer som frekvensen for hzselgeren starter. Side 15

62 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem BUTIKKMODUL Koblingen mellom en modul og en butikk. Modul_ModulNR - Dette er primærnøkkelen sammen med Butikk_KundeNR, og hentes fra tabellen Modul. Butikk_KundeNR - Dette er primærnøkkelen sammen med Modul_ModulNR, og hentes fra tabellen Butikk. Figur 10 - Butikkmodultabell POST Poststedtabell, importert fra posten.no. PostNR - Primærnøkkelen til tabellen Post. Poststed - Poststedet. Figur 11 - Posttabell EKSKLUDERING Systemet gir mulighet for unntak fra den faste oppføringen i rutetabellen. Hvis det ønskes at butikk med ID 12 ikke skal besøkes uke 33 for selger, vil lagres i denne tabellen. Butikk_KundeNr Del av primærnøkkelen, hentes fra Butikktabellen. Ukenummer Ukenummeret ekskluderingen gjelder. Type Angir om ekslkulderingsoppføringen tilhører selger(0), selgerfremmer(1) eller fremmer(2). Figur 12 - Ekskluderingstabell Side 16

63 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem UKEDAG Denne fungerer på samme måte som over, men denne angir hvilke dager en butikk skal besøkes. Hvis en butikk skal besøkes på mandager, lagres butikkid, 1(for mandag), og 1(for selger). Butikk_KundeNr Primærnøkkelen hentet fra tabellen Butikk, som sier hvilken kunde det gjelder. Ukedag Indikerer hvilken ukedag det gjelder, Mandag(0) til Søndag(7). Type - Angir om ekslkulderingsoppføringen tilhører selger(0), selgerfremmer(1) eller fremmer(2). Figur 13 - Ukedagtabell Side 17

64 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem 4.4 KOMMUNIKASJON MED DATABASEN ASP.NET har ett innebygd verktøy kalt LINQ to SQL. Dette verktøyet er et kraftig rammeverk som erstatter SQL spørringer med objekter, og gir programmereren bedre kontroll på håndtering av data. Systemet er også laget på en måte slik at det er mye vanskeligere å trenge gjennom enn for eksempel vanlig SQL. Det har altså mange innebygde sikkerhetsdetaljer. Valget vårt falt derfor på denne teknologien. Syntax er noe uvant og bakvendt i forhold til vanlig SQL, men en som har gjennomsnittelig kunnskap innenfor SQL vil også klare å bruke LINQ to SQL. Skulle dette bli et problem for en eventuell videreutvikling av systemet, finnes det god dokumentasjon for LINQ to SQL på Microsoft sine websider. Rammeværket opprettes ved at man kopierer over tabellstrukturen fra databasen, og systemet lager automatisk connection strings slik at databasen fungerer bare man lager ett objekt av rammeværket. Man slipper derfor lange tilkoblingskall til databasen mellom hver gang man skal bruke den. Databasens innhold er også lett tilgjengelig via objekter, og man slipper å skrive lange spørringer hver gang man vil hente ut data. Side 18

65 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem 5 PROGRAMSTRUKTUR 5.1 RETNINGSLINJER Vi har satt noen enkle retningslinjer for programmeringen, slik at systemet følger samme oppbygning og at vi bruker samme variabelnavn og filnavn i hele systemet. Et objekt i brukergrensesnittet skal alltid begynne variabelnavnet med objektnavnet, eksempel: labeloverskrift, panelhovedpanel, buttonklikk osv. Metodenavn skal alltid ha lange beskrivende navn, med stor bokstav for hvert mellomrom. Eksempel: visenbrukerfraid(), visallebrukere() osv. Filer i systemet skal alltid ha navn som beskriver hva filens oppgave er, eksempel: visruteselger.aspx, slettbruker.aspx osv. Alle filer skal ligge i egne undermapper i systemet som beskriver hvilken brukergruppe fila tilhører. Henholdsvis Admin, Regionsjef, Fremmer og Selger. 5.2 LAGDELINGSPRINSIPPER Systemet er bygd i tre lag. Et presentasjonslag som inneholder alle aspekter av brukergrensesnittet, et kontrollerlag vi har valgt å kalle DAL, kort for Data Access Layer, og et entitetslag kalt Model. Kontrollerlaget kommuniserer med databasen og håndterer alle inn og utdata samt beregninger på disse. Entitetslaget inneholder alle egendefinerte datatyper som brukes i systemet. Dette lagdelingsprinsippet ligner veldig på ett lagdelingsprinsipp kalt MVC Model View Controller. Vi har tatt utgangspunkt i dette, men brukt navn vi kjenner fra tidligere prosjekter og skoleoppgaver. View laget i MVC er også noe annerledes enn presentasjonslaget vårt, da vi lager alle klassene manuelt, mens i MVC vil View laget være dynamisk ut ifra controllerlaget. 5.3 OBJEKTORIENTERT PROGRAMMERING Vi har valgt å bruke ASP.NET i samarbeid med C#. Dette programmeringsspråket er objektorientert, og gir gode muligheter for egendefinerte datatyper i forhold til et programmeringsspråk som for eksempel C, som ikke tillater dette. En egendefinert datatype betyr at man kan opprette et objekt av i vårt tilfelle en brukergruppe, la oss si en selger. Deretter kan man gi denne selgeren datafelter og metoder som gjør beregninger på databasen. Dette selgerobjektet kan sendes rundt i systemet og uansett hvor det ender opp, vil alle deler av systemet klare å hente ut den samme dataen fra selgerobjektet. Dette gir stor fleksibilitet og lettlest kode. Objektorientert programmering tillater også noe som kalles arv. Et objekt av en fremmer og en selger har en ting til felles, og det er at de begge er en brukergruppe. Vi kan derfor lage en datatype kalt bruker, og deretter lage datatypene selger og fremmer og la disse arve alle egenskaper fra bruker. Så kan vi definere hva som er spesielt med en selger og en fremmer individuelt, men vi vet samtidig at de deler samme basisinformasjon fra datatypen bruker. Side 19

66 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem 5.4 BRUK AV FERDIGKODE AJAXLOAD Vi har brukt en åpen løsning kalt Ajaxload, i vårt system. Dette er et javascript som kjører en ekstern side, og implementerer denne etter kjøring inn i eksisterende side. Ajaxload brukes i forbindelse med å legge til og slette fremmer fra butikker. For å slette en fremmer sendes fremmer identifikatoren med, samt kundenummeret til butikken, til en ekstern side. Denne siden prosesserer denne dataen, og fjerner koblingen mellom butikken og fremmeren. Etter at dette er gjort, fjernes så boksen som viser denne fremmeren, fra fremmerlisten. For å legge til en fremmer kjøres en ekstern side som tar imot fremmerinformasjon, legger dette til Fremmerbutikk tabellen, og senere skriver ut en liten boks på siden. Hele denne siden siden med boksen, og alt annet blir senere flyttet inn i en skjult boks på eksiterende side. Herifra hentes det videre ut kun boksen som ble produsert på forrige side, og denne skjøtes på listen over eksisterende fremmer tilkoblet denne butikken. Grunnen til at vi har valgt å bruke Ajaxload er for å kunne gi brukerne et mer dynamisk system, som fungerer med en gang en utfører en kommando, uten å laste alt innholdet på nytt. For å legge til en fremmer måtte Ajaxload modifiseres litt, for først å kjøre den eksterne siden, flytte innholdet inn i en skjult div, for så igjen å flytte den nylig produserte boksen inn i fremmerlista. VI forsøkte å sette et kall på flyttfremmer() direkte etter at ajaxload var kjørt ved hjelp av onclick-attributten til fremmeren. Men på grunn av at prosesseringen av siden for å legge til den nye fremmeren tok litt tid, forsøkte dette scriptet å flytte over den nye fremmeren før den var importert inn i den skjulte boksen. Dette førte til at ingen flytting ble gjort, og dette var grunnen til at vi måtte modifisere AjaxLoad for å kunne sette flyttfremmer() på vent, inntil den nye boksen var prosessert. 5.5 NØDVENDIGE VERKTØY FOR EVENTUELL VIDEREUTVIKLING Til utvikling av systemet har vi brukt Microsoft Visual Studio 2010, og det anbefales at en eventuell videreutvikling av systemet foretas i samme utviklingsmiljø. Alternativt kan Microsoft Visual Web Developer benyttes, som er en gratisvariant av Visual Studio ment for webutvikling. Prosjektgruppa har ikke testet dette, så vi anbefaler ikke å benytte denne programvaren. Databasen er bygd i Microsoft SQL, og den innebygde SQLeditoren i Visual Studio har lite funksjonalitet, derfor har vi brukt EMS MsSQL Manager til å administrere databasen da dette har vært nødvendig. En hvilken som helst SQL Manager som støtter Microsoft SQL vil gjøre jobben her. Dette er nødvendig for en eventuell backup av databasen. Side 20

67 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem 6 BRUKERGRENSESNITT 6.1 GUIDELINES FOR GUI Vi valgte å nedprioritere designet i prosjektet, på grunnlag av tidsmangel. Funksjonaliteten er i våre øyne mye viktigere enn designet i denne applikasjonen. Designet er veldig enkelt satt opp, men vi har ikke valgt å følge noen guidelines slavisk. Allikevel er det en rød tråd igjennom hele designet hvor blandt annet overskrifter, linker, knapper og lignende har samme design igjennom prosjektet TEKST Vi har valgt å bruke standard skrifttypen Arial / Helvetica igjennom hele systemet. Arial er en skrifttype som finnes på alle Windows maskiner, mens Helvetica finnes på alle Mac-maskiner. Dette er en av de sikreste skrifttypene å bruke på web, med tanke på et mest mulig likt utseende på flest mulig maskiner FARGER Tekstfargen vi bruker igjennom store deler av systemet er svart. Samtidig har vi valgt å beholde hvit som bakgrunnsfarge. Dette er kombinasjonen som gir mest kontraster, og med det mest lesbarhet. Videre i systemet har vi valgt å legge noen deler av systemet som skal bli lagt spesielt merke til, med en lys gråfarge som bakgrunn. Dette for å beholde lesbarheten som nevnt tidligere, men samtidig markere at dette skal skille seg fra resten av innholdet. Det er også lagt på en grønnfarge på linkene for selgerfremmer inne på rutene til en selger. Dette er ment for å enkelt kunne skille ut hvilke besøk som er satt opp for selger-tid, og hvilke besøk som er satt opp for en selger å gjøre fremmerarbeid LINKER Linkene igjennom systemet er laget med en lysere blåfarge enn standard blåfargen nettleseren selv setter. Dette for å gjøre overgangen fra bakgrunnen, og elementene rundt mykere. Vi har også valgt å fjerne understrekingen av linkene som standard, og heller sette dette på når en tar musepekeren over. Understrekingen mener vi ikke ser pent ut som standard, men fungerer allikevel veldig bra for å vise grafisk når en har musepekeren på en klikkbar link TABELLER Radene i oversiktstabellene, for eksempel oversikten over kunder, har fått enten en hvit, eller en lysegrå bakgrunn. Grunnen til at vi har valgt å sette annenhver bakgrunnsfarge grå og hvit, er for å øke lesbarheten. Ved en lang oppramsing i en tabell med mange kolonner horisontalt, er det lett å miste hvilken rad en leser informasjonen fra. Ved å endre bakgrunnsfargen slik vi har gjort, er det mye enklere å følge raden horisontalt. Dette fordi vi kjenner igjen bakgrunnsfargen når vi leser bortover, og kan da holde oss til riktig rad ved å se på denne KNAPPER Designet for knappene er en lysegrå bakgrunnsfarge, med en litt mørkere grå kant rundt. For å øke lesbarheten har vi valgt å legge litt mellomrom mellom kantene av knappen, og selve teksten som beskriver hva knappens Side 21

68 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem funksjonalitet gjør, etiketten på knappen. Knappene er veldig nøytrale i forhold til resten av designet, samtidig som de skiller seg ut, og viser at de er klikkbare knapper FORSIDENE Hver brukergruppe har ulike forsider. Forsidene innholder den viktigste informasjonen som gjelder for denne brukergruppen. Regionssjefene og administratoren har begge to tabeller for visning av informasjon. Disse tabellene har annet oppsett enn resten av tabellene i systemet, dette for å tilpasse de mer til bruk på forsiden, og for å vises alene på en side. Tabellene har mer luft mellom rutene, og større skrift enn normalt. Side 22

69 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem 7 PRESENTASJON AV PROGRAMMETS HOVEDDELER. 7.1 INNLEDNING Vi deler denne delen av dokumentasjonen inn i de fire brukergruppene som har tilgang til systemet. Under regionsjefdelen er vi hele veien logget inn som regionsjef, og under administratordelen er vi hele tiden logget inn som administrator, det samme gjelder selger- og fremmerdelen. 7.2 REGIONSJEFDELEN Regionsjefen er primærbrukeren i systemet, og er den brukergruppen med flest tilgjengelige funksjoner. Brukergruppen har tilgang til all informasjon, bortsett fra import av data til databasen som administrator tar seg av. Muligheten for import av data er tatt vekk fra denne brukeren, for å eliminere feilkilder i systemet. Regionsjefen er brukeren som i hovedsak planlegger rutene, og tilegner disse til fremmere og selgere HOVEDMENYEN TIL REGIONSJEF Hovedmenyen til regionsjefen består av følgende linker: Figur 14 - Regionsjefmeny Under følger skjermbilder av alle linkene, med forklaring HJEM Hvis vi går på linken Hjem, får vi følgende side opp: Figur 15 - Regionsjef forside Side 23

70 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Dette er førstesiden til en Regionsjef. Denne blir brukeren presentert for etter innlogging. Her ser Regionsjefen alle nye butikker og alle nye brukere som er lagt til av Administrator etter en import fra AraWin. Dette er entiteter som trenger behandling for å fungere i systemet, derfor viser vi disse på forsiden. Nye butikker trenger ukedager, frekvens og tid i butikk satt før de vil dukke opp i noen rute. Nye brukere trenger å få generert ett passord og få tilsendt dette på mail slik at de kan tas i bruk. Dette gjøres automatisk av systemet hvis Regionsjefen gjør dette fra menyen. Mer detaljer rundt dette kommer senere. Gjennomgang av eksempelkode for å vise funksjonaliteten i C# og Linq to Sql: RuteRep:finnNyeButikker() Figur 16 - Regionsjef kodeeksempel1 Side 24

71 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem var allebutikker vil bli en liste med butikker som er nye i systemet. Spørringen som følger bak ligner litt på en sql spørring, men syntax er noe annerledes i Linq to SQL. select new ButikkKlasse vil lage en klasse bestående av butikkdata, og feltene settes fra databasen slik som vist i klammene. C# er kresen på datatyper, derfor må alle felter av datatypen int konverteres ved hjelp av Convert.ToInt32. Deretter returneres allebutikker sin ToList() funksjon. Denne gjør listen fra databasen om til en generisk liste slik at beregninger kan utføres på listen i presentasjonslaget. Under følger utdrag fra presentasjonslaget, kodefilen til Default.aspx, som er siden som blir vist etter innlogging. Figur 17 - Regionsjef kodeeksempel2 Henter regionid fra session, kaller metoden fra RuteRep som er vist i eksempelet over. Får en liste tilbake, og kjører en løkke som skriver ut alle de nye butikkene til en tabell som blir vist på skjermen SELGERE OG FREMMERE Klikkes linken selgere og fremmere vil følgende skjermbilde vises: Figur 18 - Regionsjef selgere og fremmere skjerm1 Side 25

72 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem En enkel liste over selgere og fremmere som jobber under den innloggede regionsjefen vises. Klikkes vis mer på Kåre Kristoffersen vil følgende skjermbilde vises: Figur 19 - Regionsjef selgere og fremmere skjerm 2 Klikkes vis rute vil ruteoversikten til denne selgeren komme opp. Det skal vi se mer på senere, så vi hopper over dette nå. Klikkes vis butikker vil en liste over butikker knyttet til denne brukeren vises. Endre brukerdata gir mulighet til å endre feltene som ikke er satt av importen fra AraWin. Generer nytt passord vil sette ett nytt passord på denne brukeren og sende dette på mail til brukeren. Hvis mailaddresse ikke er satt, vil passordet skrives til skjerm. Dette må da noteres, da det IKKE blir lagret i klartekst i databasen. Denne kan brukes hvis brukeren har glemt passordet sitt. Av sikkerhetsmessige årsaker lar vi regionsjefen utføre denne oppgaven, og ikke brukeren selv. Da er det mindre sannsynlighet for at brukernavn og passord kommer på avveie. Klikkes vis butikker kommer følgende skjermbilde opp: Figur 20 - Regionsjef selgere og fremmere skjerm 3 Klikker vi på endre, vil siden visenbutikk.aspx vises. Her kan frekvens, startuke og ukedager for de forskjellige brukergruppene endres. Dette omtales i detalj under punktet om ruteplanlegging. Side 26

73 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Går vi tilbake og klikker Endre Brukerdata vil følgende side komme opp: Figur 21 - Regionsjef selgere og fremmere skjerm 4 Her kan fornavn, etternavn, telefonnummer, epost og om selgeren er en HotZone selger eller ikke endres. HotZone selgere har to ruter å forholde seg til, og er ment for spesielle butikker i oslo hvor det både fremmes sjokolade og tyggegummi. Disse butikkene har da to forskjellige selgere, og for å få dette oversiktelig har vi laget to forskjellige selgerroller, altså Selger og SelgerHZ. Feltene i grått er data som bare vises og ikke kan endres. Går vi tilbake og klikker Generer nytt passord får vi følgende side opp: Figur 22 - Regionsjef selgere og fremmere skjerm 5 Først en forklaring på hva å generere nytt passord innebærer. Deretter klikker vi på Generer nytt passord og får denne siden: Side 27

74 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 23 - Regionsjef selgere og fremmere skjerm 6 Her står brukernavn og nytt passord. Hadde epostadressen vært lagt inn på denne brukeren ville ikke passordet kommet opp her, men blitt sendt til brukerens mailadresse. Under følger metodene som genererer tilfeldige passord og krypterer passord. Figur 24 - Regionsjef kodeeksempel 3 Hvis vi går tilbake til brukerlisten og klikker legg til bruker øverst til høyre, vil vi få opp følgende side: Side 28

75 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 25 - Regionsjef selgere og fremmere skjerm 7 Her kan info om selger legges til. Velges fremmer fra dropdownen istedet, vil siden endres til dette: Figur 26 - Regionsjef selgere og fremmere skjerm 8 Fremmeren har litt andre datafelter derfor endres oppsettet. Lagres den inntastede dataen vil brukeren bli tatt tilbake til brukerlisten. Regionsjefbrukeren har kun tilgang til å legge til nye brukere av Fremmer eller Selger type. Side 29

76 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem RUTER Klikkes linken ruter når man er logget inn som regionsjef vil man få en oversikt over alle selgere og fremmere som er tilgjengelig i sin region: Figur 27 - Regionsjef ruter skjerm 1 Klikkes Vis Rute på en selger, får vi følgende skjermbilde opp: Side 30

77 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 28 - Regionsjef ruter skjerm 2 Her har vi skjermbildet som er grunnlaget for hele systemet. Ruteoversikten er systemets hovedfunksjon, derfor har denne fått mest oppmerksomhet. Denne ruteoversikten er generert ut ifra datafeltene som ligger i butikktabellen i databasen. Under følger gjennomgang av koden, men først skal vi se på hva som skjer om vi klikker på en butikk. Da får vi opp følgende skjermbilde: Side 31

78 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 29 - Regionsjef ruter skjerm 3 Dette skjermbildet lar brukeren endre data om butikken. Denne butikken har frekvens Hver uke eller oftere, og alle ukedager er valgt til høyre. Det betyr at denne butikken skal besøkes hver eneste dag. Startuke betyr hvilken uke i en 4-dagers syklus frekvensen skal løpe fra. Er frekvens satt til annenhver uke så bestemmer startuke hvilken uke første besøksuke blir. Ekskludering vil si at hvis man skriver 27,37,51 i boksen vil ikke butikken vises i ruteoversikten på disse ukenummerene, selv om frekvens, startuke og ukedag er satt slik at den skal dukke opp. Tid i butikk er tiden selgeren bruker på ett besøk. Denne brukes i ruteoversikten for å se hvor lang arbeidsdag selgeren får. Vi går tilbake til ruteoversikten, og ser på følgende skjermbilde: Side 32

79 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 30 - Regionsjef ruter skjerm 4 Grunnen til at man bare kan velge å vise uke nåværende uke og de neste tre ukene er at hele systemet er bygd rundt en fireukers syklus. Når disse fire ukene er gått, vil en ny syklus begynne automatisk. Samtidig gir ekskluderingen mulighet til avvik fra denne slik at den ikke blir helt statisk hele året. Butikkene som ligger i ruta nå er som sagt butikker som allerede har fått en frekvens, startuke og valgte ukedager. Butikkene i lista til høyre er alle butikkene som selgeren er knyttet til via moduler, ergo selgerens ansvarsområde. Hvis vi vil ha en av butikkene inn i ruteoversikten, klikker vi på butikken, velger ønsket startuke, frekvens og huker av ukedagene som er ønsket. Lagrer og går tilbake til ukeoversikten. Da skal butikken vises i ruten på ukedagen som er valgt. Dette er fremgangsmåten regionsjefen må bruke for å lage ruten til en gitt selger. Merk at butikker med sort skrift i ruteoversikten er butikker hvor selgeren er på selgerbesøk. Butikker med grønn skrift er da selgeren skal på fremmerbesøk. Det betyr i praksis at en selger utfører en fremmers oppgave. Dette er også illustrert i toppen av siden der det står Selger i sort og SelgerFremmer i grønt. Hvis regionsjefen ønsker å se butikker som ikke ligger i lista til høyre, er det en liten dropdown meny over boksen hvor det står Kun selgerens butikker. Her kan man velge alle butikker, og da kan man søke etter butikker i hele systemet. Merk at denne butikken vil ikke komme opp i selgerens ukeoversikt hvis man setter frekvens og nødvendige data, med mindre selgeren er koblet til modulen til butikken. Side 33

80 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Hvis man klikker på printer-ikonet over ruteoversikten vil man få opp et nytt vindu som ser slik ut: Figur 31 - Regionsjef ruter skjerm 5 Her kommer altså en utskriftsvennlig versjon med telefonnummer og addresse skrevet på butikkene. Denne er formatert for utskrift i stående A4 format. Vi skal nå se litt på koden bak ruteoversikten: I kontrollerlaget ligger filen RuteRep.cs. Denne inneholder all kode som kommuniserer med databasen. I presentasjonslaget ligger filene visruteselger.aspx og visruteselger.aspx.cs og disse bruker metoder i RuteRep for å hente ut dataene. Deretter behandles dataene og skrives til skjermen. Ruteoversikten består av 10 felter som kan inneholde data. Disse er mandag før lunsj, mandag etter lunsj, tirsdag før lunsj osv. RuteRep inneholder en metode som heter visrutedagselger. Denne gir ut en liste over alle butikker som skal vises i en av disse 10 feltene, avhengig av innparameterene metoden får. Metoden har innparametere selgerid, uke, dag, før/etter lunsj. Så henter metoden ut alle butikkene til denne selgerid en, og utfører en rekke tester butikken må oppfylle for å få være med i lista som returneres. Her kontrolleres det at butikken skal vises på gitt uke fra innparameter, gitt dag fra innparameter og om butikken skal vises før eller etter lunsj, også fra innparameter. Under følger utdrag av koden som sjekker om butikken oppfyller kravene. For fullstendig kode se RuteRep.cs linje Side 34

81 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 32 - Regionsjef ruter kodeeksempel 1 Etter metoden over har kjørt, må den behandles i filen visruteselger.aspx.cs. Her kalles metoden og dataen behandles og skrives ut til den rette av de 10 feltene vi nevnte over. Hvis i tillegg selgerens fremmertid skal vises i ruteoversikten, kalles metoden visrutedagselgerfremmer, og returverdien legges i den samme lista som vi får tilbake fra visrutedagselger. Da får vi alle butikker som skal besøkes av denne selgeren både som selger og som fremmertid. Under følger utdrag av denne koden. Fullstendig kode finnes i visrutedagselger.aspx.cs linje Side 35

82 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 33 - Regionsjef ruter kodeeksempel 2 Bildet er kuttet for å få plass, men koden som mangler til høyre er kun selve linken og er ikke viktig for å forstå hvordan koden er bygd opp. Beregningene på tallene er for å vise tiden for hver dag i ruteoversikten. Ifspørringene med session-brukergruppe bestemmer om butikken skal være klikkbar eller ikke, andre brukergrupper enn Regionsjefen skal nemlig bare få opp oversikten, men ikke ha mulighet til å gå inn på selve butikken KUNDER Hvis vi går på linken kunder vil følgende side vises: Figur 34 - Regionsjef kunder skjerm 1 Her har vi valgt å ikke vise alle kundene på en gang da dette vil gå tregt. Det vises derfor ingen kunder før brukeren har skrevet i søkeboksen og trykket søk. Ønsker brukeren derimot å få se alle de ca 1000 brukerene i regionen sin i en lang liste kan det klikkes vis alle. Søker vi på rema 1000 får vi dette: Side 36

83 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 35 - Regionsjef kunder skjerm 2 Klikker vi på Endre, vil vi få se samme skjermbilde som om vi klikker på en butikk i ruteoversikten. Spørringen i søkefunksjonen ser slik ut: Figur 36 - Regionsjef kunder kodeeksempel 1 Contains attributten i Linq to SQL gjør søking enkelt RAPPORTER Klikker brukeren på linken rapporter, vil han få en oversikt over alle de tilgjengelige rapportene i systemet. Denne oversikten ser slik ut: Side 37

84 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 37 - Regionsjef rapporter skjerm 1 Rapportene brukes av Kraft Foods for å få et inntrykk av hvor lønnsomme de forskjellige butikkene er, og hvor man eventuelt skal gjøre nedskjæringer. Derfor presenterer rapportene stort sett generert statistikk fra databasen. Oppsummering butikker ser slik ut: Figur 38 - Regionsjef rapporter skjerm 2 Tonn illustrerer omsetning i tonn pr butikk. Er differansen i pluss betyr det at tonnasjen har økt den siste 12 måneders perioden i forhold til forrige 12 måneders periode, og minus betyr at den har sunket. Går vi tilbake til rapportoversikten og trykker Oppsummering Selgere får vi denne oversikten: Side 38

85 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 39 - Regionsjef rapporter skjerm 3 Her har vi en oversikt over timeantallet, antall besøk og omsetning pr. Selger. Dette er data som blir generert ut ifra frekvens og besøksdager fra butikkdatabasen. Her finnes det noen innviklede beregninger, derfor viser vi litt eksempelkode under. Figur 40 - Regionsjef rapporter kodeeksempel 1 Metoden over finner alle butikkene til en selger, for deretter å gå inn på hver butikk og se om det finnes satte ukedager for selgeren. Finnes det ukedager beregnes minuttene pr måned ved å gange sammen antall dager, tid i butikk, frekvensen og til slutt gange med fire fordi vi skal ha ut data pr måned(dataen i databasen er pr uke). Deretter returneres antall minutter delt på 60 da vi skal ha timer i returverdi. Resten av metodene som henter ut data ligner veldig på denne, derfor henviser vi til kodefilen RapportRep.cs for å se resten av koden som brukes for å vise rapportdata. De to andre tilgjengelige rapportene oppsummering fremmer og oppsummering HotZone selger ser omtrent like ut som oppsummering selger, derfor legger vi ikke ved skjermbilder av disse. Side 39

86 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem 7.3 SELGERDELEN Logger vi inn som en selger får vi følgende hovedmeny: Figur 41 - Selger hovedmeny HJEM Hjem siden ser slik ut: Figur 42 - Selger hjemskjerm Selgeren har som vi ser ikke så mange muligheter. Han kan klikke Fremmere, Ruter eller Kunder, samt at han har en snarvei til å skrive ut ukas rute. Utskriften er en forenklet versjon av ruteoversikten FREMMERE Klikker vi på fremmere i menyen får vi følgende skjermbilde: Figur 43 - Selger fremmere 1 Her er en oversikt over fremmere som fremmer varer under selgerens ansvarsområde, altså butikkene som selgeren besøker. Her kan selgeren gå inn og se når fremmerene skal besøke disse butikkene på samme måte som han ser sin egen rute. Klikkes vis rute får vi opp den samme ruteoversikten som regionsjefen har tilgang til, men selgerbrukeren har ikke tilgang til å gå inn på selve butikken og endre frekvens og lignende, han har kun mulighet til å se rutene. Side 40

87 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem RUTER Klikker vi på ruter i menyen får vi opp selgerens rute: Figur 44 - Selger ruter skjerm 1 Denne er generert på samme måte som ruteoversikten i regionsjefens del av systemet, men her er det gjort noen begrensninger opp imot selgerbrukeren. Som nevnt kan ikke selgeren klikke på butikkene for å få opp siden for å endre butikkdata. Han kan heller ikke søke gjennom alle butikkene i boksen til høyre, kun de som er i sitt eget ansvarsområde. Utskriftssiden blir lik som hos regionsjefen KUNDER Klikker vi på Kunder i menyen får vi følgende skjermbilde: Side 41

88 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 45 - Selgere kunder skjerm 1 Her ser vi en kundeliste med Navn, Adresse, Telefonnummer og Telefaxnummer. Heller ikke her kan selgeren klikke på butikken, da all informasjon han har tilgang til allerede ligger i lista. 7.4 FREMMERDELEN Logger vi inn som en fremmer får vi følgende meny: Figur 46 - Fremmer hovedmeny Som vi ser er fremmerens system enda mer begrenset enn selgeren. Fremmeren skal kun ha tilgang til å se sine egne dagsruter og sine egne kunder, samt skrive ut disse RUTER Klikker vi på Ruter får vi opp denne ruten: Side 42

89 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 47 - Fremmer ruter skjerm 1 Ruteoversikten er lik som selgerens, her er det heller ikke mulig å klikke på en butikk KUNDER Klikker vi på kunder i menyen får vi følgende liste: Figur 48 - Fremmer kunder skjerm 1 Side 43

90 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem En enkel oversikt over fremmerens kunder med telefonnummer og adresse. 7.5 ADMINISTRATORDELEN Hvis vi logger inn som administrator får vi følgende meny: Figur 49 - Administrator hovedmeny Administratorens oppgave er å oppdatere databasen ved hjelp av import fra Kraft Foods system kalt AraWin. Dette systemet er godt beskrevet i kravspesifikasjonen, men i korte trekk er dette en databaseløsning som inneholder alle bedriftens data om selgere, kunder og koblingen mellom disse. Vi har ikke direkte tilgang til denne databasen, så oppdatering av systemet foregår via import av et excel-ark fra AraWin HJEM Hovedskjermen til administratoren ser slik ut: Figur 50 - Administrator hjemskjerm Her har administratoren oversikt over antall data som ligger i systemet. Etter import vil også brukere mangle passord, derfor må administratoren inn og generere et passord som blir sendt automatisk til brukeren på mail. Grunnen til at dette ikke skjer automatisk er at importen fra AraWin ikke inneholder brukerens e-post adresse, derfor må denne legges inn manuelt av administrator før brukeren kan få tilsendt passordet på e-post. Administratoren har også en tydelig boks som sier hvor lenge det er siden sist oppdatering av systemet ble kjørt. Dette er ment for at han ikke skal glemme å kjøre oppdatering. Som nevnt tidligere var dette en funksjon vi la til i ettertid, lenge etter datamodellen var ferdig. Derfor valgte vi å lage en løsning hvor datoen for siste Side 44

91 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem import blir lagret i en tekstfil. Dette skyldes at vi ikke hadde tid til å gjøre om på hele datamodellen for å få plass til en ny tabell. Metoden som skriver dato til tekstfilen ser slik ut: Figur 51 - Administrator kodeeksempel OPPDATER SYSTEM Klikker vi på oppdater system får vi opp følgende skjermbilde: Figur 52 - Administrator oppdater skjerm 1 Her har vi fokusert på funksjonalitet, og design av administrasjonsdelen har ikke blitt prioritert. Teksten på siden forteller administrator hva selve dokumentet må inneholde for at import skal bli vellykket. Inneholder ikke dokumentet som importeres disse feltene vil systemet gi en feilmelding, slik at ikke feil data importeres. Systemet gir også feilmelding om et dokument av feil format forsøkes å lastes opp. Excel-dokumentet som importeres må være av.xls format. Brukes nyere office som lagrer dokumentet i.xlsx må det åpnes og lagres i.xls format for at import skal fungere. Når et exceldokument lastes opp, kalles metoden ReadData i Admin/Oppdater.aspx.cs. på denne måten: Figur 53 - Administrator metodeeksempel 1 Side 45

92 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Denne metoden er omfattende, men et utdrag ser slik ut: Figur 54 - Administrator metodeeksempel 2 OleDbConnection er et innebygd grensesnitt i Microsoft Visual Studio som kan lese et exceldokument og bruke innholdet som om det skulle vært en database. Dette er en viktig del av systemet, og uten denne ville ikke importen vært mulig. Det som skjer her er at ved metodekallet definerer hvilke felter som skal være med i dokumentet, deretter lages det en reader, som er et iterator-objekt som jobber seg nedover exceldokumentet hver gang man kaller metoden Read(). Derfor kjører vi en løkke som kjører så lenge Read returnerer true. Nederst i koden ser vi at vi kaller en metode i importrep som behandler en linje av importen av gangen. Metoden i importrep er enda mer omfattende enn ReadData(), men vi skal forsøke å gjennomgå denne i detalj. Datainnsamlingsdelen av metoden ser slik ut: Side 46

93 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 55 - Administrator metodeeksempel 3 Her hentes felter fra reader-objektet som ble sendt ifra presentasjonslaget. Dette objektet er en nodeliste som inneholder de feltene vi bad om fra exceldokumentet. Vi henter ut de feltene vi trenger og setter de i passende variabler. Disse skal brukes senere for å behandle importdataene. Før vi forsetter må vi se litt på oppbygningen av exceldokumentet. Det er laget slik at det er en linje for her butikk som skal importeres. Hver av disse linjene inneholder informasjon om selgeren som skal knyttes til, og modulen som butikken tilhører. Dette betyr at dokumentet i utgangspunktet ser ut som en databasetabell som ikke engang oppfyller første normalform. Databasen vår skal oppfylle tredje normalform, og derfor må vi fordele dataene utover i flere tabeller for å unngå dobbeltlagring. Hver gang noe importeres må det kontrolleres om selger eller modulkoblingen finnes fra før, hvis ikke må den opprettes. Neste del behandler selgeren Side 47

94 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 56 - Administrator metodeeksempel 4 Finnes selgeren fra før gjøres ingenting, finnes den ikke opprettes selgeren i databasen. For å fortsette må vi få tak i selgerid en til den nye selgeren. Vi vet nå at det finnes en selger, så vi trenger ikke gjøre flere sjekker nå. Dette gjøres i denne koden: Figur 57 - Administrator metodeeksempel 5 Deretter må vi kontrollere om modulen som tilhører butikken finnes, finnes den ikke vil den opprettes: Side 48

95 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 58 - Administrator metodeeksempel 6 En modul har som sagt en selger koblet til seg. Hvis selgeren som er koblet til en gitt modul endres i AraWIn, må den også endres i systemet vårt. Derfor må vi kontrollere at modulen har riktig selgerid om den finnes fra før. Figur 59 - Administrator metodeeksempel 7 Deretter må vi kontrollere om butikken vi skal importere finnes fra før, finnes den ikke vil den bli opprettet. Data fra importen blir satt inn i feltene, resten av feltene blir satt til 0: Side 49

96 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 60 - Administrator metodeeksempel 8 Hvis derimot butikken finnes fra før, må vi oppdatere dataene som ligger på butikken. Side 50

97 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 61 - Administrator metodeeksempel 9 Da er butikkdata oppdatert, og vi kan gå videre til å opprette koblingen mellom en modul og en butikk. Dette må gjøres etter at butikken og modulen i seg selv er oppdatert, da en kobling mellom butikk og modul krever at både butikk og modul eksisterer. Her kan det oppstå et scenario hvor butikken er flyttet fra en modul til en annen i AraWin. Systemet vårt tillater kun én modulkobling pr Kundenummer, derfor må vi først slette alle koblinger som ikke skal være der: Figur 62 - Administrator metodeeksempel 10 Deretter henter vi ut en liste med den potensielt riktige modulen: Figur 63 - Administrator metodeeksempel 11 Hvis den ikke finnes: Side 51

98 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 64 - Administrator metodeeksempel 12 Da skal importen av en linje være fullført. Vi returnerer et array som inneholder tre felter. Den første er en eventuell ny selger som er lagt til i systemet, den andre er en eventuell ny butikk som er lagt til, den tredje er en eventuell feilmelding. Dette er data som brukes til å gi en utfyllende statusrapport etter at importen er fullført. Etter importen er fullført får vi følgende data tilbake: Figur 65 - Administrator oppdater skjerm 2 Side 52

99 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Her ser vi tall på feil og riktig, og en liste over nye elementer i systemet. De nye selgerne vil også komme opp på forsiden til administratoren. Og de nye butikkene vil komme opp på forsiden til Regionsjefen. Dette er som nevnt tidligere i dokumentet data som må behandles før det kan brukes som det skal i systemet BRUKERADMINISTRASJON Klikkes menyvalget Brukeradministrasjon, vil følgende side vises: Figur 66 - Administrator brukeradministrasjon skjerm 1 Her er en liste over alle brukere i systemet. Administratoren har kun mulighet til å legge til brukere av regionsjef type. Legg til ny regionsjef ser slik ut: Figur 67 - Administrator brukeradministrasjon skjerm 2 Her velger man hvilken region regionsjefen tilhører, og taster inn brukerdata. Går vi tilbake til listen og klikker vis mer på en bruker får vi opp følgende side: Side 53

100 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 68 - Administrator brukeradministrasjon skjerm 3 Denne ligner på siden regionsjefen får opp, men noe begrenset funksjonalitet. Begge menyvalgene er identiske med de hos regionsjefbrukeren, derfor tar vi ikke med skjermbilder på disse her. Side 54

101 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem 8 SAMSVAR MELLOM KRAVSPESIFIKASJON OG PRODUKT Kravspesifikasjonen ble laget på et tidlig tidspunkt, og sluttproduktet har en del mangler grunnet tidsklammeri. Vi kom tregt i gang med selve kodingen av systemet, og dette setter spor i samsvar mellom kravspesifikasjon og produkt. Årsakene til dette er beskrevet i prosessdokumentasjonen, og her skal vi kun ta for oss konsekvensene. 8.1 SYSTEMETS OPPBYGNING Oppbygning og programstruktur er gjort på en måte slik at det samsvarer med kravspesifikasjonen. Brukergruppene fra kravspesifikasjonen er fulgt, og systemet følger alle rammebetingelser satt av kravspesifikasjonen. 8.2 FUNKSJONALITET Å gjennomgå alle punker i kravspesifikasjonen og si hvordan vi har løst dette vil bli mye gjentakelse fra gjennomgangen av systemet i forrige hovedpunkt. Derfor kommenterer vi bare de punktene vi mener er viktige, og som trenger oppmerksomhet i forhold til kravspesifikasjonen ADMINISTRATORENS FUNKSJONALITET Et grensesnitt for import av data fra AraWin via Exceldokument. Dette er implementert og fungerer på en god måte. Brukeren får en utfyllende rapport etter import, og all data settes slik det skal REGIONSJEFENS FUNKSJONALITET Mulighet til å administrere hvilke fremmere som jobber under hvilke selgere. Dette punktet er bare delvis oppfylt, da vi har endret datamodellen slik at en fremmer ikke er koblet til en selger, men direkte på en butikk. Dette vil i praksis ikke ha noen betydning, men regionsjefen administrere altså hvilke fremmere som jobber under hvilke butikker. Mulighet til å administrere ruteoversikten for en gitt selger. Det vil si en oversikt over hvilke butikker en gitt selger skal besøke i løpet av en dag. Her vil det være en fordel med muligheten til å veksle mellom dags, ukes og månedsvisning. Her har vi valgt å bare gi en ukesvisning da dette gir enklest oversikt på skjermen. En mer variert løsning ville gitt for mye data på ett sted. Det er derimot enkelt å skifte mellom hvilke uker som vises. Etter administratoren har importert ny data, må systemet si ifra om butikker som ikke har tilegnet selgere og fremmere, slik at brukeren enkelt kan holde oversikt over hva som er oppdatert. Butikker og brukere som er nylig importert vil vises på regionsjefens hovedside etter han er logget inn. Dette er lett tilgjengelig og synlig plassert SELGERENS FUNKSJONALITET Mulighet til å hente ut kontaktinformasjon og addresse for butikkene i sitt ansvarsområde. I ruteoversikten vil dette kun vises ved en utskrift og ikke i ruta til vanlig. Men selgeren kan trykke på kundelisten sin, og der står telefonnummer og adresse. Side 55

102 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Mulighet til å se en liste over butikker som er spesielle for denne måneden. Såkalte sesongbutikker. Dette er funksjonalitet vi ikke har hatt tid til å implementere. En alternativ løsning er derimot tilgjengelig. Ekskluderingsuker er laget for dette, så hvis brukeren ekskluderer alle uker bortsett fra disse ukene denne butikken skal være med, vil butikken komme i ruteoversikten på riktig plass. 8.3 BRUKERVENNLIGHET Vi hadde store ambisjoner om mange ajax-løsninger i systemet. Dette viste seg å være noe mer komplisert enn forventet, og derfor har vi begrenset bruken av denne. Allikevel mener vi brukervennligheten er på topp, og at vi har brukt smarte løsninger. Det er brukt dropdown menyer der det er hensiktsmessig, og avkrysningsbokser der det passer seg. Brukeren trenger ikke taste inn mer data ved hjelp av tastaturet enn høyst nødvendig. Søkeboksene i systemet er ikke dynamiske slik vi ønsket det, man må trykke søk før man får presentert resultatet. Dette vil medføre noe mer klikking og lenger navigeringstid, men det er viktigere at det fungerer riktig hver gang, enn at det er enkelt å bruke en gang i mellom. Ajax-søkene vi forsøkte å implementere var så trege at man måtte vente flere sekunder før det kom noe resultat, og dette førte til en hakkete brukeropplevelse. Derfor valgte vi å gå bort fra dette. Ellers i systemet har vi brukt store tydelige knapper og linker, og brukeren bør ikke ha problemer med å navigere rundt i systemet. Hovedmenyen er tilgjengelig til enhver tid, og menyvalget som er gjeldende er markert i grått slik at det er tydelig for brukeren hvor han befinner seg. 8.4 OPPSUMMERING Kort oppsummert samsvarer sluttproduktet godt med kravspesifikasjonen. Noen punkter har fått en litt annen løsning enn forventet, men det betyr ikke nødvendigvis at det er noen dårligere løsning. Vi har på et par punkter valgt en enklere utvei grunnet dårlig tid, men i hovedsak er alle endringer fra kravspesifikasjonen gjort da vi mener alternativet er en bedre løsning på problemstillingen. Side 56

103 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem 9 PROGRAMMETS OPPBYGNING OG VIRKEMÅTE Skrive noe om hvilke filer systemet består av. Hvordan disse kommuniserer, mappestruktur. Kommunikasjon kode til gui 9.1 OPPBYGNING Programmet er som nevnt tidligere kodet i ASP.NET med C# (C-sharp) som grunnkode. Dette gir stor fleksibilitet, og gode muligheter for tunge beregninger. Programmet består derfor av en rekke.aspx filer som inneholder html og javascript kode, og bak ligger det programfiler som inneholder C# kode. All kode er generert fra Microsoft Visual Studio, og hvis koden skal endres på må kildefilene importeres i Visual Studio og nye filer genereres. Filene i programmet kan ikke endres direkte. For at mappestrukturen i programmet skal se mer ryddig ut, har vi valgt å legge alle funksjoner som tilhører en gitt brukergruppe i hver sin mappe. Alle selgerens kildefiler ligger i mappen Selger osv. Filer som er felles for alle brukere ligger i rotmappa. 9.2 VIRKEMÅTE ASP.NET fungerer slik at C# koden henter ut data fra databasen og utfører beregninger, deretter brukes ASP koden til å vise dataen på skjermen. ASP.NET er i utgangspunktet et eget kodespråk som ligner en del på HTML. Hovedforskjellen er at det har en del dynamiske løsninger, som gjør sidene litt mer levende enn standard HTML. Selv om ASP er et eget kodespråk, genererer det rett og slett bare en blanding av HTML og Javascript. Derfor vil det fungere helt fint i alle nettlesere og plattformer. 9.3 OPPBYGNING I VISUAL STUDIO Under koding av systemet vil hvert lag være et eget prosjekt i systemet. Alle disse lagene vil samles i en solution. Her er en komplett oversikt over hvordan solutionen ser ut i Visual Studio: Side 57

104 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 69 - Solution fra visual studio Alle filene som har endelse.cs er C# eller C-Sharp filer som blir kompilert ved en publisering av prosjektet. Da legges alle disse cs filene i.dll filer og mappestrukturen blir annerledes. 9.4 MAPPESTRUKTUR FOR PUBLISERING ROTMAPPE Side 58

105 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 70 - Mappeinnhold rotmappe ADMIN Inneholder alle filer som har noe med brukeren Administrator å gjøre. Figur 71 - Mappeinnhold Admin BIN Inneholder kompilerte kodefiler for all C# kode i de tre lagene. Dette er kompilert kode slik at koden ikke er lesbar. Figur 72 - Mappeinnhold bin DESIGN Inneholder designfiler. Alle bilder som brukes i systemet. Side 59

106 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 73 - Mappeinnhold Design ERROR Inneholder filer som viser feilmeldinger hvis noe går galt. Figur 74 - Mappeinnhold error FREMMER Inneholder alle filer som har noe med brukergruppen Fremmer å gjøre JS Inneholder javascriptfiler knyttet til det implementerte rammeverket AjaxLoad. Figur 75 - Mappeinnhold js RAPPORT Inneholder alle filer som skriver ut rapporter. Figur 76 - Mappeinnhold js REGIONSJEF Inneholder alle filer knyttet til brukergruppen Regionsjef. Side 60

107 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 77 - Mappeinnhold Regionsjef SCRIPTS Inneholder kodefiler knyttet til funksjonalitet i AjaxLoad. Figur 78 - Mappeinnhold scripts SELGER Inneholder alle filer knyttet til brukergruppen Selger. Figur 79 - Mappeinnhold Selger 9.5 INNSTALLASJON For å installere Ruteplanleggingssystem, må Microsoft Visual Studio 2010 og Microsoft SQL server 2008 benyttes. Det forventes at en med god kjennskap til disse programmene utfører installasjonen. Kildefilene i mappen Kildefiler i programmappen, må åpnes i Visual Studio ved å åpne filen Ruteplanleggingssystem.sln. Da åpnes hele prosjektet i programmet, og arbeidet kan begynne. Deretter må databasen importeres ved hjelp av punkt 14.1 Vedlegg 1 - Sql-setning for opprettelse av database. Dette er en sql-spørring som kjøres på serveren og oppretter alle entiteter i databasen automatisk. Så må databasen kobles i Server Explorer i Visual Studio, og deretter kobles med Linq to SQL klassen i kontrollerlaget DAL. Når dette er utført kan publisering av applikasjonen foretas ved at man klikker publish solution fra menyen. Her må adresse til server tastes inn, og filene vil da bli kompilert og lastet opp til server. Når dette er gjort må administratorbrukeren logges inn og regionsjefer opprettes. Deretter importeres data fra AraWin og systemet kan brukes som normalt. Side 61

108 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem 10 FORHOLD TIL MASKINER, LAGERPLASS, OPERATIVSYSTEMER O.L SERVERPLATTFORM Da systemet er laget i ASP.NET kreves fortrinnsvis en Microsoft server for best kompatibilitet. Det finnes alternativer for å kjøre.net servere under linux, men dette har prosjektgruppa liten innsikt i, og ønsker ikke å anbefale dette KLIENTPLATTFORM Da systemets grensesnitt er tilgjengelig via et webgrensesnitt, vil det ikke ha noen betydning hvilken klient brukeren kjører. Se punkt om tilpasning til nettlesere NØDVENDIGE UTVIDELSER AV SERVER For import av Exceldokumenter kreves det et programtillegg som kan lastes ned fra Microsoft sine websider. Denne utvidelsen må innstalleres på serveren for at import fra exceldokument skal fungere. Microsoft selv har laget utvidelsen, så vi må kunne ta utgangspunkt i at dette ikke er ondsinnet kode. Utvidelsen finnes på denne addressen: EF94E038C891&displaylang=en Installasjonsfilen er også lagt i mappa med kildekoden til programmet. Filnavn: AccessDatabaseEngine.exe Etter at filen er installert og serveren er startet på nytt er det ingen flere nødvendige steg for at dette skal fungere HARDWAREKAPASITET Systemet vil ikke stille store krav til serverkapasitet. All data som lagres er tekstbasert, og krever derfor ikke stor lagringsplass. Det vil heller aldri bli mange brukere som bruker systemet hardt på en gang, derfor stilles det heller ikke store krav til prosessorkraft. En helt allminnelig server vil holde mer enn nok til å kjøre dette systemet. Side 62

109 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem 11 TILPASNING TIL NETTLESERE 11.1 INTERNET EXPLORER Applikasjonen vår er tilpasset Internet Explorer 7, og oppover. Nettleserkompabilitet er et stort problem for dagens webutviklere, da ulike nettlesere viser nettsider ulikt. For eksempel har vi nettlesere som tar med en ramme rundt et bilde, en boks og lignende i bredden du setter, mens andre nettlesere legger rammen på i tillegg til bredden du setter. På grunn av at Kraft Foods bruker Internet Explorer, og samtidig får oppgradert alle sine maskiner til IE 7 iløpet av juni, valgte vi å gjøre siden kompatibel for denne. Internet Explorer er kjent for sine spesielle visninger av nettsider i forhold til de anerkjente standardene som Firefox, Opera, Chrome og de andre nettleseren følger. Dette førte til noen problemer underveis, men IE har allikevel kommet seg veldig godt, og nettsidene ser per dags dato veldig like ut uansett nettleser JAVASCRIPT Noen av tilpasningen i nettsiden er lagt til rette for å fungere ved hjelp av javascript, for eksempel ved bytte av de ulike fanene inne på butikkvisningen for en butikk. Her brukes javascript i stor grad til å bytte ut innholdet etter om du ønsker å se informasjon tilpasset selgeren, selgerens fremmertid, fremmeren eller hotzone selgeren for butikken. ASP.NET bygger også mye på javascript, så uten javascript aktivert i nettleseren vil ikke systemet fungere som det skal. Side 63

110 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem 12 KILDEHENVISNINGER 12.1 NETTSIDER AJAXLOAD AjaxLoad - Dynamic Ajax Content ( Side 64

111 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem 13 FIGURLISTE Figur 1 - Datamodell Figur 2 - Brukertabell Figur 3 - Brukergruppetabell Figur 4 - Regiontabell Figur 5 - Fremmertabell Figur 6 - Fremmerbutikktabell Figur 7 - Selgertabell Figur 8 - Modultabell Figur 9 - Butikktabell Figur 10 - Butikkmodultabell Figur 11 - Posttabell Figur 12 - Ekskluderingstabell Figur 13 - Ukedagtabell Figur 14 - Regionsjefmeny Figur 15 - Regionsjef forside Figur 16 - Regionsjef kodeeksempel Figur 17 - Regionsjef kodeeksempel Figur 18 - Regionsjef selgere og fremmere skjerm Figur 19 - Regionsjef selgere og fremmere skjerm Figur 20 - Regionsjef selgere og fremmere skjerm Figur 21 - Regionsjef selgere og fremmere skjerm Figur 22 - Regionsjef selgere og fremmere skjerm Figur 23 - Regionsjef selgere og fremmere skjerm Figur 24 - Regionsjef kodeeksempel Figur 25 - Regionsjef selgere og fremmere skjerm Figur 26 - Regionsjef selgere og fremmere skjerm Figur 27 - Regionsjef ruter skjerm Side 65

112 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 28 - Regionsjef ruter skjerm Figur 29 - Regionsjef ruter skjerm Figur 30 - Regionsjef ruter skjerm Figur 31 - Regionsjef ruter skjerm Figur 32 - Regionsjef ruter kodeeksempel Figur 33 - Regionsjef ruter kodeeksempel Figur 34 - Regionsjef kunder skjerm Figur 35 - Regionsjef kunder skjerm Figur 36 - Regionsjef kunder kodeeksempel Figur 37 - Regionsjef rapporter skjerm Figur 38 - Regionsjef rapporter skjerm Figur 39 - Regionsjef rapporter skjerm Figur 40 - Regionsjef rapporter kodeeksempel Figur 41 - Selger hovedmeny Figur 42 - Selger hjemskjerm Figur 43 - Selger fremmere Figur 44 - Selger ruter skjerm Figur 45 - Selgere kunder skjerm Figur 46 - Fremmer hovedmeny Figur 47 - Fremmer ruter skjerm Figur 48 - Fremmer kunder skjerm Figur 49 - Administrator hovedmeny Figur 50 - Administrator hjemskjerm Figur 51 - Administrator kodeeksempel Figur 52 - Administrator oppdater skjerm Figur 53 - Administrator metodeeksempel Figur 54 - Administrator metodeeksempel Figur 55 - Administrator metodeeksempel Figur 56 - Administrator metodeeksempel Side 66

113 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem Figur 57 - Administrator metodeeksempel Figur 58 - Administrator metodeeksempel Figur 59 - Administrator metodeeksempel Figur 60 - Administrator metodeeksempel Figur 61 - Administrator metodeeksempel Figur 62 - Administrator metodeeksempel Figur 63 - Administrator metodeeksempel Figur 64 - Administrator metodeeksempel Figur 65 - Administrator oppdater skjerm Figur 66 - Administrator brukeradministrasjon skjerm Figur 67 - Administrator brukeradministrasjon skjerm Figur 68 - Administrator brukeradministrasjon skjerm Figur 69 - Solution fra visual studio Figur 70 - Mappeinnhold rotmappe Figur 71 - Mappeinnhold Admin Figur 72 - Mappeinnhold bin Figur 73 - Mappeinnhold Design Figur 74 - Mappeinnhold error Figur 75 - Mappeinnhold js Figur 76 - Mappeinnhold js Figur 77 - Mappeinnhold Regionsjef Figur 78 - Mappeinnhold scripts Figur 79 - Mappeinnhold Selger Side 67

114 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem 14 VEDLEGG 14.1 VEDLEGG 1 - SQL-SETNING FOR OPPRETTELSE AV DATABASE CREATE TABLE [dbo].[bruker] ( [BrukerID] int IDENTITY(1, 1) NOT NULL, [RegionID] int NULL, [Fornavn] varchar(50) COLLATE Danish_Norwegian_CI_AS NULL, [Etternavn] varchar(50) COLLATE Danish_Norwegian_CI_AS NULL, [BrukergruppeID] int NULL, [Telefonnummer] varchar(50) COLLATE Danish_Norwegian_CI_AS NULL, [Epost] varchar(50) COLLATE Danish_Norwegian_CI_AS NULL, [Initialer] varchar(10) COLLATE Danish_Norwegian_CI_AS NULL, [Brukernavn] varchar(50) COLLATE Danish_Norwegian_CI_AS NULL, [Passord] varchar(50) COLLATE Danish_Norwegian_CI_AS NULL, [AnsattNR] int NOT NULL, CONSTRAINT [PK_Bruker] PRIMARY KEY CLUSTERED ([BrukerID]), CONSTRAINT [FK_Bruker_Brukergruppe] FOREIGN KEY ([BrukergruppeID]) REFERENCES [dbo].[brukergruppe] ([BrukergruppeID]) ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT [FK_Bruker_Region] FOREIGN KEY ([RegionID]) REFERENCES [dbo].[region] ([RegionID]) ON UPDATE NO ACTION ON DELETE NO ACTION ) CREATE TABLE [dbo].[brukergruppe] ( [BrukergruppeID] int IDENTITY(1, 1) NOT NULL, [Tittel] varchar(50) COLLATE Danish_Norwegian_CI_AS NULL, CONSTRAINT [PK_Brukergruppe] PRIMARY KEY CLUSTERED ([BrukergruppeID]) ) CREATE TABLE [dbo].[butikk] ( [KundeNR] int NOT NULL, [Kundenavn] varchar(50) COLLATE Danish_Norwegian_CI_AS NULL, [Adresse] varchar(50) COLLATE Danish_Norwegian_CI_AS NULL, [Telefonnummer] varchar(20) COLLATE Danish_Norwegian_CI_AS NULL, [Telefaxnummer] varchar(20) COLLATE Danish_Norwegian_CI_AS NULL, [PostNR] varchar(4) COLLATE Danish_Norwegian_CI_AS NULL, [ForEtterLunsj] int NULL, [Selgerfrekvens] decimal(18, 3) NULL, [SelgerFremmerfrekvens] decimal(18, 3) NULL, [Fremmerfrekvens] decimal(18, 3) NULL, [SelgerHZfrekvens] decimal(18, 3) NULL, [SelgerID] int NULL, [Sesong] int NULL, [TonnPeriode1] decimal(18, 3) NULL, [TonnPeriode2] decimal(18, 3) NULL, [Kommentar] text COLLATE Danish_Norwegian_CI_AS NULL, [TidIButikkSelger] int NULL, [TidIButikkSelgerFremmer] int NULL, [TidIButikkFremmer] int NULL, [TidIButikkSelgerHZ] int NULL, [StartukeSelger] int NULL, [StartukeSelgerFremmer] int NULL, Side 68

115 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem [StartukeFremmer] int NULL, [StartukeSelgerHZ] int NULL, CONSTRAINT [PK_Butikk] PRIMARY KEY CLUSTERED ([KundeNR]), CONSTRAINT [FK_Butikk_Post] FOREIGN KEY ([PostNR]) REFERENCES [dbo].[post] ([PostNR]) ON UPDATE NO ACTION ON DELETE NO ACTION ) CREATE TABLE [dbo].[butikkmodul] ( [ModulNR] int NOT NULL, [KundeNR] int NOT NULL, CONSTRAINT [PK_Butikkmodul] PRIMARY KEY CLUSTERED ([ModulNR], [KundeNR]), CONSTRAINT [FK_Butikkmodul_Butikk] FOREIGN KEY ([KundeNR]) REFERENCES [dbo].[butikk] ([KundeNR]) ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT [FK_Butikkmodul_Modul] FOREIGN KEY ([ModulNR]) REFERENCES [dbo].[modul] ([ModulNR]) ON UPDATE NO ACTION ON DELETE NO ACTION ) CREATE TABLE [dbo].[ekskludering] ( [KundeNR] int NOT NULL, [Ukenummer] int NOT NULL, [Type] int NOT NULL, CONSTRAINT [PK_Ekskludering] PRIMARY KEY CLUSTERED ([KundeNR], [Ukenummer], [Type]), CONSTRAINT [FK_Ekskludering_Butikk] FOREIGN KEY ([KundeNR]) REFERENCES [dbo].[butikk] ([KundeNR]) ON UPDATE NO ACTION ON DELETE NO ACTION ) CREATE TABLE [dbo].[fremmer] ( [FremmerID] int IDENTITY(1, 1) NOT NULL, [BrukerID] int NULL, [Stillingsprosent] int NULL, [Kommentar] text COLLATE Danish_Norwegian_CI_AS NULL, CONSTRAINT [PK_Fremmer] PRIMARY KEY CLUSTERED ([FremmerID]), CONSTRAINT [FK_Fremmer_Bruker] FOREIGN KEY ([BrukerID]) REFERENCES [dbo].[bruker] ([BrukerID]) ON UPDATE NO ACTION ON DELETE NO ACTION ) CREATE TABLE [dbo].[fremmerbutikk] ( [KundeNR] int NOT NULL, [FremmerID] int NOT NULL, CONSTRAINT [PK_Fremmerbutikk] PRIMARY KEY CLUSTERED ([KundeNR], [FremmerID]), CONSTRAINT [FK_Fremmerbutikk_Butikk] FOREIGN KEY ([KundeNR]) REFERENCES [dbo].[butikk] ([KundeNR]) ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT [FK_Fremmerbutikk_Fremmer] FOREIGN KEY ([FremmerID]) REFERENCES [dbo].[fremmer] ([FremmerID]) Side 69

116 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem ON UPDATE NO ACTION ON DELETE NO ACTION ) CREATE TABLE [dbo].[modul] ( [ModulNR] int NOT NULL, [SelgerID] int NULL, CONSTRAINT [PK_Modul] PRIMARY KEY CLUSTERED ([ModulNR]), CONSTRAINT [FK_Modul_Selger] FOREIGN KEY ([SelgerID]) REFERENCES [dbo].[selger] ([SelgerID]) ON UPDATE NO ACTION ON DELETE NO ACTION ) CREATE TABLE [dbo].[post] ( [PostNR] varchar(4) COLLATE Danish_Norwegian_CI_AS NOT NULL, [Poststed] varchar(50) COLLATE Danish_Norwegian_CI_AS NULL, CONSTRAINT [PK_Post] PRIMARY KEY CLUSTERED ([PostNR]) ) CREATE TABLE [dbo].[region] ( [RegionID] int IDENTITY(1, 1) NOT NULL, [Navn] varchar(20) COLLATE Danish_Norwegian_CI_AS NULL, CONSTRAINT [PK_Region] PRIMARY KEY CLUSTERED ([RegionID]) ) CREATE TABLE [dbo].[selger] ( [SelgerID] int IDENTITY(1, 1) NOT NULL, [BrukerID] int NULL, [SelgerHZ] int NULL, CONSTRAINT [PK_Selger] PRIMARY KEY CLUSTERED ([SelgerID]), CONSTRAINT [FK_Selger_Bruker] FOREIGN KEY ([BrukerID]) REFERENCES [dbo].[bruker] ([BrukerID]) ON UPDATE NO ACTION ON DELETE NO ACTION ) CREATE TABLE [dbo].[ukedag] ( [KundeNR] int NOT NULL, [Ukedag] int NOT NULL, [Type] int NOT NULL, CONSTRAINT [PK_Ukedag] PRIMARY KEY CLUSTERED ([KundeNR], [Ukedag], [Type]), CONSTRAINT [FK_Ukedag_Butikk] FOREIGN KEY ([KundeNR]) REFERENCES [dbo].[butikk] ([KundeNR]) ON UPDATE NO ACTION ON DELETE NO ACTION ) INSERT INTO [dbo].[region] ([RegionID], [Navn]) VALUES (1, N'Øst') INSERT INTO [dbo].[region] ([RegionID], [Navn]) VALUES (2, N'Sør') INSERT INTO [dbo].[region] ([RegionID], [Navn]) VALUES (3, N'Vest') Side 70

117 Produktdokumentasjon Prosjekt nr Ruteplanleggingssystem INSERT INTO [dbo].[region] ([RegionID], [Navn]) VALUES (4, N'Nord') INSERT INTO [dbo].[brukergruppe] ([BrukergruppeID], [Tittel]) VALUES (1, N'Administrator') INSERT INTO [dbo].[brukergruppe] ([BrukergruppeID], [Tittel]) VALUES (2, N'Regionsjef') INSERT INTO [dbo].[brukergruppe] ([BrukergruppeID], [Tittel]) VALUES (3, N'Selger') INSERT INTO [dbo].[brukergruppe] ([BrukergruppeID], [Tittel]) VALUES (4, N'Fremmer') INSERT INTO dbo.bruker ( BrukerID, RegionID, Fornavn, Etternavn, BrukergruppeID, Telefonnummer, Epost, Initialer, Brukernavn, Passord, AnsattNR ) VALUES ( '1', '1', 'Administrator', '', '1', '', '', '', 'Admin', 'C5AA351EC1400A6272C071DBF796372CD45A50B5', '0' ); Side 71

118 Testdokumentasjon Prosjekt nr Ruteplanleggingssystem RUTEPLANLEGGINGSSYSTEM TESTDOKUMENTASJON Prosjekt 18 Jørgen Mobekk Sørensen Morten Evje Tor Andreas Baakind Anders Gabrielsen Side 1

119 Testdokumentasjon Prosjekt nr Ruteplanleggingssystem 1 FORORD Testdokumentasjonen har som formål å beskrive all testing som er utført på systemet, både underveis og etter utviklingsprosessen. Testing av systemet har blitt utført kontinuerlig underveis i utviklingen og alle feil som har dukket opp under testing har blitt fikset. Feil som er forårsaket av brukeren av systemet blir sjekket, og det blir gitt beskrivende feilmeldinger om hva som er galt. Side 2

120 Testdokumentasjon Prosjekt nr Ruteplanleggingssystem TABLE OF CONTENTS 1 Forord Innledning Testing av systemet Administrator Oppdatering av system Brukeradministrasjon Regionssjefer Butikkadministrasjon Selger-og fremmeradministrasjon Ruteadministrasjon Rapportadministrasjon Selgere Fremmere Felles (funksjoner som gjelder alle brukergrupper) Innlogging Linker og menyvalg Endre passord Logge ut Kildehenvisninger Nettsider Side 3

121 Testdokumentasjon Prosjekt nr Ruteplanleggingssystem 2 INNLEDNING Det er nesten umulig å levere et system til oppdragsgiver som er helt feilfritt. For å gjøre jobben lettere for de som skal vedlikeholde systemet og finne eventuelle feil, er det derfor viktig å dokumentere hva som er testet og hvordan testingen har blitt utført. Vi har fokusert på funksjonell testing, og begynte med white-box testing, hvor man bruker kjennskap til koden for å kjøre testene. Senere i prosjektet, brukte vi black-box testing, det vil si at vi matet systemet med testdata for å sjekke hvilken tilbakemelding vi fikk. I black-box metoden trengs det ingen kjennskap til koden. Vi testet også brukergrensesnittet i en viss grad hos oppdragsgiver tidlig i implementeringsfasen. Oppdragsgiver fikk se forskjellige skjermbilder av det planlagte brukergrensesnittet, og ga stort sett bare positive tilbakemeldinger, men allikevel var det noen småting som de ønsket å endre på. Side 4

122 Testdokumentasjon Prosjekt nr Ruteplanleggingssystem 3 TESTING AV SYSTEMET Systemet er delt inn i fire hoveddeler, en del for hver av brukergruppene som kan logge inn i systemet. Det vil si administrator, regionssjefer, selgere og fremmere. Noen funksjoner er felles for alle brukergruppene. Disse kommer i en egen del til slutt. Nedenfor følger beskrivelser av den funksjonelle testingen utført ved hjelp av black-box -metoden. 3.1 ADMINISTRATOR OPPDATERING AV SYSTEM Funksjon Testet Kommentar Importere kundeliste fra AraWin At riktig data blir lagt inn i OK via opplastet Excel-ark databasen Importere kundeliste hvor Excelark inneholder feil felter At riktig feilmelding kommer opp OK Importere kundeliste hvor opplastet fil er av feil format Importere kundeliste hvor fanen/arket i Excel-arket har ikke heter Eksport At riktig feilmelding kommer opp At riktig feilmelding kommer opp OK OK BRUKERADMINISTRASJON Funksjon Testet Kommentar Endre brukerdata til en bruker i At riktig data blir endret i OK systemet databasen Endre brukerdata hvor telefonnummeret inneholder andre tegn enn tall At riktig feilmelding blir skrevet ut OK Endre brukerdata hvor epostadressen ikke Endre brukerdata hvor fornavn og/eller etternavn-feltene ikke er fylt ut Generere nytt passord til en bruker i systemet Generere passord når brukeren ikke har oppgitt epostadresse Generere passord når brukeren har oppgitt epostadresse Legge til ny regionssjef Legge til ny regionssjef hvor telefonnummeret inneholder andre tegn enn tall Legge til ny regionssjef hvor epostadressen ikke At riktig feilmelding blir skrevet ut At riktig feilmelding blir skrevet ut At passordet blir endret i databasen At passordet blir skrevet ut til skjerm med en beskrivende tekst til administrator At passordet blir sendt til den oppgitte epostadressen At riktig data blir lagt inn i databasen At riktig feilmelding blir skrevet ut At riktig feilmelding blir skrevet ut Legge til ny regionssjef hvor At riktig feilmelding blir skrevet ut OK Side 5 OK OK OK OK OK OK OK OK

123 Testdokumentasjon Prosjekt nr Ruteplanleggingssystem fornavn og/eller etternavn-feltene ikke er fylt ut Vise liste over alle brukere i systemet Vise en bruker fra brukerlista At riktig data blir hentet ut fra databasen At riktig data blir hentet ut fra databasen OK OK 3.2 REGIONSSJEFER BUTIKKADMINISTRASJON Funksjon Testet Kommentar Vise alle butikker innenfor sin At riktig data blir hentet ut fra OK region databasen Søke på butikker innenfor sin region At riktig data blir hentet ut fra databasen OK Søke på butikker innenfor sin region og ingen butikker matcher søkenavnet Tilbakestille søk av butikker Vise informasjon om en butikk Endre informasjon om en butikk Endre informasjon om en butikk hvor felt for Tid i butikk inneholder et annet tegn enn tall Endre informasjon om en butikk hvor felt for Tonn salg inneholder et annet tegn enn desimaltall Vise butikker tilkoblet en bestemt selger eller fremmer At riktig feilmelding blir skrevet ut At riktig data blir hentet ut fra databasen At riktig data blir hentet ut fra databasen At riktig data blir endret i databasen At riktig feilmelding blir skrevet ut At riktig feilmelding blir skrevet ut At riktig data blir hentet ut fra databasen OK OK OK OK OK OK OK SELGER-OG FREMMERADMINISTRASJON Funksjon Testet Kommentar Vis alle selgere og fremmere At riktig data blir hentet ut fra OK innenfor sin region databasen Vis kun selgere innenfor sin region At riktig data blir hentet ut fra databasen OK Vis kun fremmere innenfor sin region Vise informasjon om en selger/fremmer Endre informasjon en selger/fremmer Endre informasjon om en selger/fremmer hvor telefonnummeret inneholder andre tegn enn tall At riktig data blir hentet ut fra databasen At riktig data blir hentet ut fra databasen At riktig data blir endret i databasen At riktig feilmelding blir skrevet ut OK OK OK OK Side 6

124 Testdokumentasjon Prosjekt nr Ruteplanleggingssystem Endre informasjon om selger/ fremmer hvor epostadressen ikke Endre informasjon om en selger/fremmer hvor fornavn/og eller etternavn ikke er fylt ut Endre informasjon om en fremmer hvor stillingsprosent inneholder andre tegn enn tall Endre informasjon om en fremmer hvor stillingsprosent er et tall større enn 100 Legge til ny selger/fremmer Legge til ny selger/fremmer hvor telefonnummeret inneholder andre tegn enn tall Legge til ny selger/fremmer hvor epostadressen ikke Legge til ny selger/fremmer hvor fornavn og/eller etternavn ikke er fylt ut Legge til ny selger/fremmer hvor ansattnummer ikke er fylt ut Legge til ny selger/fremmer hvor ansattnummeret inneholder andre tegn enn tall Legge til ny fremmer hvor stillingsprosent inneholder andre tegn enn tall Legge til ny fremmer hvor stillingsprosent inneholder et større tall enn 100 Generere nytt passord til en selger/fremmer Generere nytt passord til en selger/fremmer som ikke har oppgitt epostadresse Generere nytt passord til en selger/fremmer som har oppgitt epostadresse At riktig feilmelding blir skrevet ut At riktig feilmelding blir skrevet ut At riktig feilmelding blir skrevet ut At riktig feilmelding blir skrevet ut At riktig data blir lagt inn i databasen At riktig feilmelding blir skrevet ut At riktig feilmelding blir skrevet ut At riktig feilmelding blir skrevet ut At riktig feilmelding blir skrevet ut At riktig feilmelding blir skrevet ut At riktig feilmelding blir skrevet ut At riktig feilmelding blir skrevet ut At riktig data blir endret i databasen At passordet blir skrevet ut til skjerm med en beskrivende tekst til administrator At passordet blir sendt til den oppgitte epostadressen OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK RUTEADMINISTRASJON Funksjon Testet Kommentar Vise rute for en bestemt uke til en bestemt selger, fremmer eller HotZone-selger At riktig data blir hentet ut fra databasen OK Skrive ut rute for en bestemt uke til en bestemt selger, fremmer eller HotZone-selger At riktig data blir hentet ut fra databasen Søke etter bestemte butikker At riktig data blir hentet ut fra OK OK Side 7

125 Testdokumentasjon Prosjekt nr Ruteplanleggingssystem tilhørende selger/fremmer i butikkboks i rutevisning Søke etter bestemte butikker tilhørende sin region i butikkboks i rutevisning databasen At riktig data blir hentet ut fra databasen OK RAPPORTADMINISTRASJON Funksjon Testet Kommentar Vise oppsummeringsrapport for At riktig data blir hentet ut fra OK butikker databasen Vise oppsummeringsrapport for selgere, fremmer og HotZoneselgere At riktig data blir hentet ut fra databasen OK Søke på butikker innenfor regionen i oppsummeringsrapporten for butikker At riktig data blir hentet ut fra databasen OK 3.3 SELGERE Funksjon Testet Kommentar Vise liste over alle selgerens At riktig data blir hentet ut fra OK butikker databasen Vise selgerens rute for en bestemt At riktig data blir hentet ut fra OK uke databasen Skrive ut selgerens rute for en At riktig data blir hentet ut fra OK bestemt uke databasen Søke etter butikker tilhørende At riktig data blir hentet ut fra OK selgeren i butikkboks i rutevisning databasen Vise liste over alle fremmere som er tilknyttet samme butikker som selgeren At riktig data blir hentet ut fra databasen OK Side 8

126 Testdokumentasjon Prosjekt nr Ruteplanleggingssystem 3.4 FREMMERE Funksjon Testet Kommentar Vise liste over alle butikker som er At riktig data blir hentet ut fra OK tilknyttet fremmeren databasen Vise fremmerens rute for en At riktig data blir hentet ut fra OK bestemt uke databasen Skrive ut fremmerens rute for en At riktig data blir hentet ut fra OK bestemt uke databasen Søke etter butikker tilhørende selgeren i butikkboks i rutevisning At riktig data blir hentet ut fra databasen OK 3.5 FELLES (FUNKSJONER SOM GJELDER ALLE BRUKERGRUPPER) INNLOGGING Funksjon Testet Kommentar Logge inn At brukeren blir logget inn i OK systemet Logge inn med feil brukernavn og/eller passord At brukernavn og passord blir sjekket opp mot databasen og skriver ut riktig feilmelding OK Logget inn som Administrator, Regionssjef, Selger og Fremmer At brukergruppene får riktige rettigheter og tilgang til riktige sider og menyvalg. OK LINKER OG MENYVALG Funksjon Testet Kommentar Klikke på de forskjellige At brukeren blir sendt til riktig URL OK menyvalgene i hovedmenyen Klikke på forskjellige linker At brukeren blir sendt til riktig URL OK Prøve å skrive en adresse i adressefeltet som ikke finnes At brukeren kommer til en 404- feilmeldingsside med beskrivende tekst at siden ikke finnes OK Prøve å manuelt gå inn på en side man ikke har tilgang til At brukeren kommer til en 403- feilmeldingsside med beskrivende tekst at man ikke har tilgang OK Side 9

127 Testdokumentasjon Prosjekt nr Ruteplanleggingssystem ENDRE PASSORD Funksjon Testet Kommentar Endre sitt eget passord i systemet At riktig data blir endret i OK databasen Endre sitt eget passord i systemet og man ikke skriver riktig passord i Gammelt passord -feltet At systemet sjekker verdien i feltet for Gammelt passord og matcher dette med passordet i databasen. Riktig feilmelding blir skrevet ut OK Endre sitt eget passord i systemet og verdiene i feltene Nytt passord og Gjenta nytt passord ikke matcher hverandre Endre sitt eget passord i systemet og det nye passordet er mindre enn 4 tegn At systemet sjekker verdiene i begge feltete mot hverandre. Riktig feilmelding blir skrevet ut At riktig feilmelding blir skrevet ut OK OK LOGGE UT Funksjon Testet Kommentar Logg ut At brukeren blir logget helt ut av OK systemet Side 10

128 Testdokumentasjon Prosjekt nr Ruteplanleggingssystem 4 KILDEHENVISNINGER 4.1 NETTSIDER Innledning - Blackbox-testing: Innleding - Whitebox-testing: Side 11

129 Brukerveiledning Prosjekt nr Ruteplanleggingssystem RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING Prosjekt 18 Jørgen Mobekk Sørensen Morten Evje Tor Andreas Baakind Anders Gabrielsen Side 1

130 Brukerveiledning Prosjekt nr Ruteplanleggingssystem 1 FORORD Dette dokumentet er brukerveiledningen, og skal være en veiledning for brukerne av ruteplanleggingssystemet. Dokumentasjonen er beregnet for brukere med alt i fra liten erfaring med pc og oppover. Det er tatt som en selvfølge at brukerne er kjent med internett som medium. Side 2

131 Brukerveiledning Prosjekt nr Ruteplanleggingssystem 2 INNHOLDSFORTEGNELSE 1 Forord Ordforklaringer Forklaring av brukergrupper Regionsjef Selger Fremmer Ord og uttrykk Ruter besøksfrekvens Startuke Ekskludering Tid i butikk Innledning Programmets funksjoner Admin Regionssjef Selger Fremmer Dialog med skjerm Informasjon på skjerm og papir Meldinger i programmet Endringer i databasen Meldinger ved importering Feilmeldinger ved importering Validering av felter Brukerveiledning Administrator Side 3

132 Brukerveiledning Prosjekt nr Ruteplanleggingssystem Hjem Oppdater system Brukeradministrasjon Regionssjef Hjem Selgere og fremmere Ruter Kunder Rapporter Lage ruter Selger Hjem Fremmere Ruter Kunder Fremmer Hjem Ruter Kunder Figurliste Side 4

133 Brukerveiledning Prosjekt nr Ruteplanleggingssystem 3 ORDFORKLARINGER 3.1 FORKLARING AV BRUKERGRUPPER REGIONSJEF Personen som i utgangspunktet styrer hele systemet. Regionsjefen er den eneste av de tre vanlige brukerne som skal ha mulighet til å endre data på ruteplanleggingsdelen SELGER Selgeren er regionsjefens produktpromotør i ett gitt geografisk område. I systemet har han kun mulighet til å se hvilke dagsruter regionsjefen har satt opp for selgeren og de fremmere som jobber under selgeren FREMMER Fremmerens oppgave er å fylle på varer i butikkene. I systemet skal han bare se sin egen dagsrute og kontaktinformasjon til selgeren han jobber for. 3.2 ORD OG UTTRYKK RUTER En rute er en oversikt over en selgers eller fremmers besøksrute. Den inneholder alle butikkene de skal besøke i løpet av en uke. Det er spesifisert for hver butikk hvor lang besøkstid butikken har og om den skal besøkes før eller etter lunsj BESØKSFREKVENS Besøksfrekvens er hvor ofte en butikk skal besøkes, denne kan ha verdien aldri, hver fjerde uke, annenhver uke eller hver uke eller oftere. Det vil si at om man setter denne verdien til hver uke eller oftere skal butikken besøkes en eller fler ganger i uka STARTUKE Startuke betyr hvilken uke i en 4-dagers syklus frekvensen skal løpe fra. Er frekvens satt til annenhver uke så bestemmer startuke hvilken uke første besøksuke blir EKSKLUDERING Ekskludering vil si at hvis man skriver 27,37,51 i boksen vil ikke butikken vises i ruteoversikten på disse ukenummerene, selv om frekvens, startuke og ukedag er satt slik at den skal dukke opp TID I BUTIKK Tid i butikk er tiden selgeren bruker på ett besøk. Denne brukes i ruteoversikten for å se hvor lang arbeidsdag selgeren får. Side 5

134 Brukerveiledning Prosjekt nr Ruteplanleggingssystem 4 INNLEDNING Programmets tittel Ruteplanleggingssystem avslører hva programmet har som hovedoppgave. Systemet er skreddersydd til Kraft Foods Norges behov og ønsker, og holder oversikt over bedriftens selgere, fremmere, kunder og forholdet mellom disse. Systemets hovedfunksjonalitet brukes av bedriftens fire regionssjefer, men også selgere og fremmere skal ha mulighet til å hente ut data fra systemet. Kundene er bare en tredjepart i systemet og har ingen tilgang til informasjonen som lagres. Bedriftens selgere og fremmere reiser rundt i butikkene og håndterer varer. Systemets hovedoppgave er å gi regionssjefen en mulighet til å fortelle aktørene hvilken butikk som skal besøkes til en gitt tid. Denne problemstillingen er løst i form av en kalenderløsning, som gir oversikt over en selgers dagsruter. Denne kalenderen blir automatisk generert ut ifra data Regionsjefen taster inn. Henholdsvis besøksfrekvens, startuke, ukedager og ekskluderingsuker. Systemet bruker så disse dataene til å lage en ukesvisning av selgeren og fremmerens rute. Ut over kalenderløsningen har systemet mulighet for utskrift av rapporter, oversikt over antall besøk til de forskjellige butikkene, vedlikehold av brukernavn, passord og andre relevante data. En viktig detalj å nevne ved systemet er at det baserer seg på input fra bedriftens nåværende databasesystem kalt AraWin. Informasjon om hvilke selgere som tilhører hvilke butikker og ansvarsområder hviler alene på input fra AraWin, og kan ikke endres i dette systemet. 4.1 PROGRAMMETS FUNKSJONER Systemet kan brukes av alle de forskjellige brukergruppene samtidig. Brukergruppene har følgende funksjoner: ADMIN Endre sitt eget passord Oppdatere systemet via utskrift fra AraWin Brukeradministrasjon Se antall bruker og kunder Se antall dager siden oppdatering Se brukere som trenger passord REGIONSSJEF HJEM Endre sitt eget passord Se liste over nye butikker som trenger å legges inn i en rute Se liste over nye brukere SELGERE OG FREMMERE Se brukere og sortere på brukergruppe Vise informasjon om hver bruker o Vise rute o Vise butikker tilhørende en bruker o Endre brukerdata Side 6

135 Brukerveiledning Prosjekt nr Ruteplanleggingssystem o Legg til bruker Generer nytt passord for bruker RUTER Se oversikt over selgere og fremmere og hotzone selgere Vise ruter for brukerne Lage og endre ruter for selgere og fremmere KUNDER Søke etter butikker fra sin egen region Vise alle butikker i sin region RAPPORTER Oppsummering butikker, tonnasje Oppsummering selgere Oppsummering fremmere Oppsummering HotZone selgere SELGER HJEM Endre sitt eget passord Skriv ut nåværende selger rute FREMMERE Se sine egne fremmere Vise rutene til sine enge fremmere RUTER Se egne ruter KUNDER Se sine egne butikker FREMMER HJEM Endre sitt eget passord Skrive ut nåværende fremmer rute Side 7

136 Brukerveiledning Prosjekt nr Ruteplanleggingssystem RUTER Se egne ruter Se sine egne butikker 4.2 DIALOG MED SKJERM Ruteplanleggingssystemet er en løsning laget for web, og er laget så selvbeskrivenede som mulig. Det skal være mulig for en som har brukt den gamle løsningen på excel ark og kjenne seg igjen i systemet og bruke det. For å bruke systemet må brukerne logge seg inn med brukernavn og passord. Dette generes automatisk av regionssjefen og sendes deretter på mail til brukeren. Brukeren kan enkelt se hvor i systemet han befinner seg ved å se på fanene øverst til høyre. Den grå fanen indikerer hvilken fane som er åpen. For å gå tilbake til systemet må brukeren bruke tilbakeknappen i nettleseren. Endringer i rutene skjer ved at man trykker på en butikk og deretter endrer eller legger til informasjon om når butikken skal besøkes, av hvem, hvor lenge butikken skal besøkes og hvilke uker butikken ikke skal besøkes. Deretter trykker man på lagre knappen nederst til høyre for å lagre endringene. Feilmeldinger i systemet er lett forståelige og det er tatt hensyn til at noen av brukerne ikke har veldig gode it kunnskaper. 4.3 INFORMASJON PÅ SKJERM OG PAPIR Brukerveiledningen vil foreligge på papir og på prosjektets hjemmeside. Dette dokumentet er brukerveiledningen på papir. Brukerveiledningen Vil være delt opp slik at hver bruker kun trenger å lese om sin brukergruppe. Dokumentet vil dermed bestå av følgende deler: Administrator, Regionssjef, Selger og Fremmer. Dette er fordi systemet er ment å brukes av regionssjefene som tidligere har brukt excel løsningen. Det er derfor nødvendig at disse har en viss kunnskap av hvordan ruteplanleggingen har blitt gjort tidligere. For de resterende brukerne er systemet selvforklarende. I selve systemet vil det kun være utdypet brukerveiledning for importering av data fra AraWin. 4.4 MELDINGER I PROGRAMMET ENDRINGER I DATABASEN Når brukeren gjør endringer som skal lagres i databasen vil det komme opp en bekreftende melding på at dette er gjort MELDINGER VED IMPORTERING Når det importeres nye data fra AraWin vil det kommer opp meldinger om nye butikker og brukere slik at disse kan få nye ruter. Det vil også være en liste over brukere som mangler passord. Side 8

137 Brukerveiledning Prosjekt nr Ruteplanleggingssystem FEILMELDINGER VED IMPORTERING Når det importeres nye data fra AraWin vil det komme opp feilmeldinger dersom det mangler noen felter eller om noe er feil fra utskriften VALIDERING AV FELTER Dersom det er skrevet inn feil data i felter vil det komme en melding om dette. Dette er implementert for at for eksempel epostadresser har riktig format. Validering av felter er til stor hjelp for brukeren, da det blir enklere å skrive inn rett data. Side 9

138 Brukerveiledning Prosjekt nr Ruteplanleggingssystem 5 BRUKERVEILEDNING Brukerveiledningen vil bli delt opp i følgende fire deler: Administrator, Regionssjef, Selger og Fremmer. De fire delene er laget for at en bruker kun skal trenge å lese om den brukergruppen den tilhører, og alle delene er derfor skrevet uavhengig fra de andre. 5.1 ADMINISTRATOR Denne delen av brukerveiledningen er ment for administratoren av systemet. Hovedoppgavene til denne brukeren er å Importere data fra AraWin og å administrere brukere, i hovedsak regionssjefene HJEM Under fanen HJEM har du som administrator en oversikt over følgende: Brukere o o o o o Kunder o o o o o Antall fremmere Antall selgere Antall regionssjefer Antall administratorer Totalt antall brukere Antall kunder i region Øst Antall kunder i region Sør Antall kunder i region Vest Antall kunder i region Nord Totalt antall kunder Antall dager dager siden oppdatering Brukere som trenger passord OVERSIKT OVER BRUKERE OG KUNDER Oversikten over brukere og kunder er kun ment som informasjon. Det eneste nyttige man kan bruke dette til er å se om det er sneket seg inn en ny administrator eller regionssjef som ikke skal være der. Dette kan være greit å ha som en sikkerhetsfunksjon ANTALL DAGER SIDEN OPPDATERING Antall dager siden oppdatering er også fint å ha for å kunne se hvor lenge siden databasen er oppdatert. Det blir da enklere å holde styr på når man skal oppdatere databasen OPPDATER SYSTEM Fanen OPPDATER SYSTEM skal brukes til å importere data fra AraWin. Her skal man velge excel dokumentet som skal brukes for oppdatringen av databasen. Det er viktig at dokumentet er i filformatet.xls. Dersom filen er av et annet format får man en melding som sier følgende: Filen har feil format. Dette løses ved å velge riktig fil og sørge for at den har riktig format. Excel dokumentet som skal importeres må ha følgende felter: Kunde/butikk: Side 10

139 Brukerveiledning Prosjekt nr Ruteplanleggingssystem KUNDENR KUNDENAVN ADRESSE TELEFON TELEFAX POSTNR Distrikt: DISTRIKTNR DISTRIKTNAVN Disse feltene er absolutt minimum for at import skal fungere som det skal. Vennligst kontroller at utskrift fra AraWin matcher dette. Det har ingen betydning om utskrift fra AraWin inneholder flere felter. Arket eller fanen i excel-arket må hete "Eksport". Importering tar tid, la maskinen jobbe til den er ferdig. Det kan fort ta 3-10 minutter, avhengig av hastigheten på internettforbindelsen BRUKERADMINISTRASJON Fanen BRUKERADMINISTRASJON gir en oversikt over alle brukerne. Her er det mulig og sortere listen, legge til ny regionssjef og endre brukerdata. Under følger alle funksjoner tilgjengelig for denne fanen LISTE OVER BRUKERE Listen over brukere kan sorteres på brukergruppe og er deretter sortert på ansattnummer. For å sortere velger man en brukergruppe fra dropdownboksen som vist på figur 1: Side 11

140 Brukerveiledning Prosjekt nr Ruteplanleggingssystem Figur 1 Brukergruppe sortering LEGGE TIL NY REGIONSSJEF Det er kun mulig for administrator å legge til en regionssjef. For å legge til en regionssjef klikker man på knappen Legg til ny regionssjef oppe til høyre under fanen BRUKERADMINISTRASJON som vist på figur 2: Figur 2 Legg til regionssjef Side 12

141 Brukerveiledning Prosjekt nr Ruteplanleggingssystem Dette må gjøres manuelt ved å skrive inn informasjon om brukeren og velge region. Informasjonen som er nødvendig her er: Region Fornavn Etternavn Telefonnummer Epost ENDRE BRUKEDATA Det er mulig å endre fornavn, etternavn, telefonnummer og epost til en bruker. Dersom brukeren man har valgt er en selger, kan man også velge om dette er en hotzone selger. Endring av fornavn og etternavn er kun ment å bruke hvis fornavn eller etternavn har havnet på feil plass under importen fra AraWin. Denne endringen fører ikke til endringer av initialer eller brukernavn. Det er også mulig å endre passord til en bruker ved å klikke på knappen Generer nytt passord. Skriv ned dette passordet og gi det til brukeren som så kan logge inn og lage seg ett nytt passord. Dersom brukeren har en registrert epost vil passordet også bli sendt til denne. For å endre brukerdata trykk på Vis mer som vist på figur 3: Figur 3 Endre brukerdata 1 Side 13

142 Brukerveiledning Prosjekt nr Ruteplanleggingssystem Deretter får man opp to valg, Endre brukerdata og Generer nytt passord som vist på figur 4. Figur 4 Endre brukerdata 2 Deretter velger du hva du vil endre ved å trykke på de respektive knappene. Dersom du velger Endre brukerdata får du opp en ny side der du må fylle inn brukerdataen og trykke Lagre for å utføre endringene. 5.2 REGIONSSJEF Denne delen av brukermanualen er ment for regionssjefene i systemet. Hovedoppgavene er å lage ruter for selgerne og fremmerne. Men det er også mulighet for å se butikker i regionen du er sjef for og rapporter for butikker, selgere og fremmere HJEM Under fanen HJEM vil du få opp en liste over nye brukere og butikker. Dersom det ikke er noen nye brukere eller butikker vil du ikke få opp noe av interesse her. Under følger alle funksjoner tilgjengelig for denne fanen NYE BRUKERE Denne listen vises kun dersom det er nye brukere i systemet. Her er det meningen at du skal gi de nye brukerne et passord. Når du har gjort dette vil de forsvinne fra oversikten over nye brukere. For å endre passord trykker du først på Endre ved siden av brukeren i listen, som vist på figur 5: Side 14

143 Brukerveiledning Prosjekt nr Ruteplanleggingssystem Figur 5 Gi bruker passord 1 Deretter trykker du Generer nytt passord, som vist på figur 6 : Figur 6 Gi bruker Passord 2 Når du trykker her vil du få opp et nytt passord, dette må du skrive ned og gi til brukeren du har laget passord for. Dersom brukeren har en registrert epost vil passordet også bli sendt til denne NYE BUTIKKER Denne listen vises kun dersom det er nye butikker i systemet. Det vil være en enkel liste med ett navn og en knapp, Endre, til hver butikk. Her er det meningen at man skal legge butikken til en selgers og en fremmers rute. Når dette er gjort vil butikken forsvinne fra listen Nye butikker. For å se hvordan man skal legge en butikk til en selgers eller fremmers rute se punkt lage ruter SELGERE OG FREMMERE Under fanen SELGERE OG FREMMERE vil du få frem en liste over alle fremmerne og selgerene i din region. Disse er sortert på ansattnummer. Her vil du kunne se ansatt nummer, brukergruppe, etternavn, fornavn, initialer, epost og telefon. Under følger alle funksjoner tilgjengelig for denne fanen LEGG TIL NY FREMMER Side 15

144 Brukerveiledning Prosjekt nr Ruteplanleggingssystem For å legge til en ny fremmer i systemet må du trykke knappen Legg til ny fremmer under fanen SELGERE OG FREMMERE som vist på figur7 : Figur 7 Legg til ny fremmer Du vil nå få opp en ny side der du skal skrive inn fornavn, ettrnavn, telefonnummer, epost, ansattnummer, stillingsprosent og en kommentar. Det er kun nødvendig å skrive inn Fornavn, etternavn og ansattnummer, men dersom epost oppføres vil passordet som genereres til brukeren sendes til denne. Det kan også vært lurt føre opp de resterende feltene, denne informasjonen vises da dersom man klikker seg inn på brukeren senere INFORMASJON OM SELGER ELLER FREMMER Dersom du vil ha informasjon om en fremmer eller selger i din region finner du det vd å klikke på knappen Vis mer i listen Selgere og fremmere. Informasjon tilgjengelig er: Vis rute Vis butikker Endre brukerdata Generer nytt passord I tillegg er navn, ansattnummer, region, brukergruppe, brukernavn, telefonnummer og epost for brukeren listet opp en en rute til høyre for knappene. Dersom man vil se ruten for en selger eller fremmer gjør man følgende: Velg den selgeren eller fremmeren du vil se ruten for ved å klikke på Vis mer knappen, som vist på figur 8: Side 16

145 Brukerveiledning Prosjekt nr Ruteplanleggingssystem Figur 8 Informasjon om fremmer eller selger Du vil deretter få opp innformasjon om brukeren og noen valg, klikk på knappen Vis rute, som vist på figur 9: Figur 9 Vis rute for selger eller fremmer 1 Side 17

146 Brukerveiledning Prosjekt nr Ruteplanleggingssystem Du vil da få opp en ny side der du kan se ruten for den selgeren eller fremmeren du har valgt, dette vil se ut som vist på figur 10: Figur 10 Vis rute for selger eller fremmer 2 Her vil du også kunne endre og legge til butikker i ruten for selgeren eller fremmeren. Se punkt lage ruter for en veiledning til hvordan man skal lage ruter. Det vil også være mulig å skrive ut ruten ved å trykke på printer ikonet øverst til høyre. Dersom man vil se butikkene til en selger eller fremmer trykker man på knappen Vis Butikker som vist på figur 11: Side 18

147 Brukerveiledning Prosjekt nr Ruteplanleggingssystem Figur 11 Vis butikker for selger eller fremmer Dersom man vil endre brukerdata eller generere nytt passord gjør man dette ved å trykke på enten Endre brukerdata eller Generer nytt passord som vist på figur 12: Figur 12 Endre brukerdata, generer passord for fremmer eller selger Side 19

148 Brukerveiledning Prosjekt nr Ruteplanleggingssystem RUTER Under fanen RUTER vil det være en ruteoversikt. Her vil du finne alle selgerne, fremmerne og hotzone selgere som tilhører din region. De er listet opp under de brukergruppene de tilhører. For å se en rute klikker du på Vis Rute til brukeren du vil se ruten til som vist på figur 13: Figur 13 - Ruter Du vil da få opp en ny side der du kan se ruten for den selgeren eller fremmeren du har valgt, dette vil se ut som vist på figur 10. Det vil også være mulig å skrive ut ruten ved å trykke på printer ikonet øverst til høyre. Her vil du også kunne endre og legge til butikker i ruten for selgeren eller fremmeren. Se punkt lage ruter for en veiledning til hvordan man skal lage ruter KUNDER Under fanen KUNDER kan du søke i butikker eller vise alle butikker i din region. For å vise alle butikker trykk på knappen Vis alle som du finner til høyre for søkeboksen. For å søke etter butikker skriv inn det du søker etter i søkeboksen og klikk søk som vist på figur 14: Figur 14 - Butikker Du vil da få opp en liste over butikker som inneholder søkeordet. Du kan også velge å endre informasjon til butikkene du har søkt etter dersom dette er ønskelig. For å gjøre dette klikker du på Endre helt til høyre i listen over butikker ENDRE BUTIKKDATA Når du har klikket på Endre som vist i forrige avsnitt vil du få opp skjermbildet som vist på figur 15: Side 20

149 Brukerveiledning Prosjekt nr Ruteplanleggingssystem Figur 15 Endre butikkdata 1 Her får du opp informasjon om butikken til venstre, samt en enkel rapport basert på tonnasje siste 12 måneder og forrige 12 månedersperiode. Besøksfrekvenser til selger, selgerfremmer, fremmer og selger hotzone finnes under de respektive fanene. Her endrer man hvilke ukedager butikken skal besøkes, hvor ofte den skal besøkes basert på frekvens, startuke for når den skal besøkes og hvilke uker butikken ikke skal besøkes. Du må i tillegg velge om butikken skal besøkes før eller etter lunsj. Du kan også velge om butikken er en sesong butikk eller ikke. Det er ikke mulig å endre hvilken selger som hører til butikken da dette er basert på importeringen fra AraWin. Derimot så må man velge hvilke fremmere som skal besøke butikken og dette gjøres under fremmer fanen som vist på figur 16: Figur 16 - Endre butikkdata 2 Klikk på pilen og fremmerne som hører til butikken dukker opp i en liste, du må så velge en eller flere av fremmerne du vil skal besøke butikken. Besøksfrekvens, startuke, eksluderte uker, ukedager og tid i butikk må også fylles ut. Når du er ferdig trykker du på knappen Lagre nederst til høyre. Det er også mulig å legge til en kommentar til butikken dersom dette er ønskelig. For en detaljert gjennomgang av hvordan man skal lage ruter se punkt LAGE RUTER. Side 21

150 Brukerveiledning Prosjekt nr Ruteplanleggingssystem RAPPORTER Under fanen RAPPORTER får man opp diverse rapporter for selgere, fremmer og butikker. Rapportene som er tilgjengelig er: Kunderapporter o Oppsummering butikker o Besøksrapporter Brukerrapporter o Oppsummering selgere o Oppsummering fremmere o Oppsummering HotZone selgere Under de forskjellige rapportene finner man statistikk som tonnasje, besøkstid i butikk og antall butikker for hver selger eller fremmer. En typisk rapport kan du se på figur 17: Figur 17 - Rapport LAGE RUTER Dette avsnittet handler om hvordan man skal lage en rute for en selger eller en fremmer. For å starte å lage en rute for en selger eller fremmer går man inn på fanen RUTER som vist på figur 18: Figur 18 Lag ruter 1 Side 22

151 Brukerveiledning Prosjekt nr Ruteplanleggingssystem Deretter klikker du på Vis rute knappen til den selgeren eller fremmeren du vil lage rute for. Du vil da få opp siden som vist på figur 19: Figur 19 - Lag ruter 2 Butikken du skal legge til i ruten velger du fra listen til høyre, i denne listen kan du velge om du vil se alle butikkene i din region, kun selgerens eller fremmerens butikker eller så kan du søke etter en spesifikk butikk. Når du har funnet frem til riktig butikk klikker du på den som vist på figur 20: Side 23

152 Brukerveiledning Prosjekt nr Ruteplanleggingssystem Figur 20 - Lag ruter 3 Du vil da få opp all informasjon om butikken som vist på figur 21: Figur 21 - Lag ruter 4 Nå skal du velge hvor ofte butikken skal besøkes, dette gjør du ved å klikke på dropdownboksen Frekvens. Du kan velge mellom Hver uke eller oftere, Annenhver uke, Hver fjerde uke, eller Aldri. Deretter velger du hvilken startuke butikken skal besøkes fra. Startuke betyr hvilken uke i en 4-dagers syklus frekvensen skal løpe fra. Er frekvens satt til annenhver uke så bestemmer startuke hvilken uke første besøksuke blir. Ekskludering vil Side 24

153 Brukerveiledning Prosjekt nr Ruteplanleggingssystem si at hvis man skriver 27,37,51 i boksen vil ikke butikken vises i ruteoversikten på disse ukenummerene, selv om frekvens, startuke og ukedag er satt slik at den skal dukke opp. Tid i butikk er tiden selgeren bruker på ett besøk. Denne brukes i ruteoversikten for å se hvor lang arbeidsdag selgeren får.det er også viktig og velge om butikken skal besøkes før eller etter lunsj. Til slutt kan du velge hvilke(n) dag(er) butikken skal besøkes. Dersom vi har valgt en butikk og lagt inn følgende data, som vist på figur 22, vil vi i ruteoversikten etter at vi har trykket Lagre nederst til høyre også deretter Tilbake øverst til venstre, se at butikken er lagt til mandag og torsdag før lunsj med tid i butikk satt til 300 minutter som vist på figur 23. Figur 22 - Lag ruter 5 Side 25

154 Brukerveiledning Prosjekt nr Ruteplanleggingssystem Figur 23 - Lag ruter 6 Dersom man har valgt å endre ruten til en fremmer, er det viktig at man velger besøksdata under fanen Fremmer etter at man har valgt en butikk. Dette er vist på figur 24: Figur 24 - Lag ruter 7 Side 26

155 Brukerveiledning Prosjekt nr Ruteplanleggingssystem 5.3 SELGER Som selger har du relativt få funksjoner i forhold til regionssjefen. Hovedfunksjonene du har i systemet er å skrive ut din egen rute, samt se dine egne butikker og hvilke fremmere som jobber under deg HJEM Under fanen du kommer til ved innlogging vil du finne kun en knapp, Skriv ut nåværende Selger rute. Denne knappen tar deg rett til utskriftsvennlig side av ukesruten din. Vindu for valg av printer kommer automatisk opp. Dermed er det bare og klikke print og du vil få ut din egen rute fra valgt printer FREMMERE Under fanen FREMMERE vil du få en oversikt over hvilke fremmere som jobber under deg. Her har du også valget om du vil se rutene til disse fremmerne. For å se en fremmers rute klikker du på knappen Vis rute ved siden av den fremmeren du vil se ruten til, som vist på figur 25: Figur 25 Selger sine fremmere Du vil deretter kommer til ruteoversikten til valgt fremmer. Her kan du velge og skrive ut ruten for fremmeren ved å klikke på printer ikonet som vist på figur 26: Side 27

156 Brukerveiledning Prosjekt nr Ruteplanleggingssystem Figur 26 Selger sin fremmers rute RUTER Under fanen RUTER vil du se din egen rute og en oversikt over hvilke butikker du har ansvar for. Her kan du også se dine ruter 4 uker frem i tid ved å velge uke oppe til venstre som vist på figur 27: Side 28

157 Brukerveiledning Prosjekt nr Ruteplanleggingssystem Figur 27 Selgers ruter Det er også mulighet for å skrive ut de forskjellige rutene ved å klikke på printer ikonet som vist på figur KUNDER Under fanen KUNDER vil du få opp en helt enkel liste over hvilke butikker du har ansvar for. Den vil se ut som vist på figur 28, og inneholder følgende: Kundennr, Kundenavn, Adresse, Postnr, Poststed, Telefon og Telefax. Figur 28 Selgers butikker 5.4 FREMMER Fremmere har færrest tilgjengelige funksjoner i systemet. Det du har tilgang til som fremmer er å skrive ut din egen rute, se din egen rute og se hvilke butikker du har ansvar for. Side 29