Prosessdokumentasjon Prosjekt nr PayEx Logistics

Transkript

1 Page 1 of 106

2 1 Forord Denne prosessdokumentasjonen handler om utvikling av et datasystem som håndterer betalingsterminalenes sitt livsløp hos PayEx. Den tar for seg alt fra idé og planleggingsfasen til utvikling av applikasjonen. Rapporten stiller ikke spesielle krav til forkunnskaper og er leselig av personer uten teknisk bakgrunn. Page 2 of 106

3 2 Innholdsfortegnelse 1 Forord Innholdsfortegnelse Innledning Bedriftens situasjon Mål Planlegging og styring Rammebetingelser Ressurser Prosjektstyringsverktøy Utviklingsmetode Fremdriftsplan Risikoplanlegging Arbeidsplan Kravspesifikasjon Endringer i kravspesifikasjon Sammendrag av kravspesifikasjonen Analyse Strukturkart Papirprototype Use-Case Design Grensesnittet Programmet Database Trelagsarkitektur Testing Konklusjon Oppsummering Ønsker for fremtiden Hva kunne vært gjort bedre? Ikke implementert funksjonalitet Ordliste Systemet Programvare Kilde henvisning Bøker Vedlegg Vedlegg 1: Fremdriftsplan Vedlegg 2: Risikoplan og risikostyring Vedlegg 3: Arbeidsplan Vedlegg 4: Kravspesifikasjon Page 3 of 106

4 13.5 Vedlegg 5: Strukturkart Vedlegg 6: Balsamiq Mockups prototype Vedlegg 7: Use-case diagram Vedlegg 8: Beskrivelse av use-case Vedlegg 9: Skjermbilder av applikasjonen Vedlegg 10: Sekvensdiagram Vedlegg 11: Klassediagram Vedlegg 12: ER diagram Vedlegg 13: Test resultater Vedlegg 1: Fremdriftsplan Vedlegg 2: Risikoplan og Risikostyring Vedlegg 3: Arbeidsplan Vedlegg 4: Kravspesifikasjon Vedlegg 5: Strukturkart Vedlegg 6 Balsamiq Mockups prototyper Innlogingsside Country selection Infoside Production storage / Produksjonslager (terminaler hos kunder) Test lager In production storage (terminaler på lageret) Defect (Terminaler som må sendes til reparasjon) Vedlegg 7 Use case diagram Vedlegg 8 Beskrivelse av Use case Vedlegg 9 Skjermbilder av applikasjonen Innlogging: Lagervalg / Country selection Kortfattet info side etter lagervalg Production lager (Terminaler hos kunder) Resultat etter kunde søk ved navn Resultat etter unikt søk Registrering av defekte terminaler hos kunde Registrering av terminal som er uavhengig av kundetilhørighet Mottagelse av reparerte terminaler Utsendelse av defekte terminaler til reparasjon Pakkseddel til en RMA liste som skal sendes Internt lager Legge til nye terminaler på lager Legge til nye brukere (Admin funksjonalitet) Liste over alle brukere og deres rettigheter: Import av kundelister (Admin funksjonalitet) Import av postnummer liste (Admin funksjonalitet) Page 4 of 106

5 Import av terminal liste (Admin Funksjonalitet) Vedlegg 10 Sekvensdiagram System Production: In production Defect Admin Vedlegg 11: Klassediagram Vedlegg 12: ER diagram Vedlegg 13 Testresultat Page 5 of 106

6 3 Innledning Dette prosjektet handler om å designe og utvikle et logistikksystem for PayEx. Bedriften er en av Nordens fremste eksperter på betalinger, og har omlag seks hundre ansatte. Hovedkontoret til bedriften befinner seg i Stockholm, men de har i tillegg en avdeling i Oslo. Siden starten i 1972 har de utviklet en solid kompetanse på områder som betalingsløsninger for internett, mobil og fysisk handel, rating/fakturering, faktura og reskontro håndtering, inkasso og kredittadministrasjon Bedriften har en god del forskjellig betalingsterminaler i omløp, og disse terminalene er det ikke så lett å holde oversikten over. Deres system i dag er rett og slett ikke godt nok. Det er uoversiktlig og det tar lang tid å finne ut hvor terminalene befinner seg til enhver tid. De trenger et system som følger hver terminal sitt livsløp. Det er også nevneverdig at PayEx tilbyr forskjellige betalingsløsninger til sine kunder, blant annet frittstående og PC-koblet terminalløsning For frittstående terminalløsning blir det brukt en mobil betalingsterminal (930G), se figur Terminalen kommuniserer via GPRS, og bruker oppladbare batterier. Figur Terminal 930G For PC-tilkoplet terminalløsning blir det brukt en terminal som er avhengig av å være tilkoblet en datamaskin, figur viser en slik betalingsterminal. Løsningen krever at PC-en har TCP/IP-kommunikasjon. Figur GPA Terminal 1 Page 6 of 106

7 3.1 Bedriftens situasjon Bedriften benytter i dag regneark for å holde oversikt over betalingsterminalene sine, om disse er på lager, sendt til kunde eller er til reparasjon. Deres system er i dag rett og slett ikke godt nok. Det er uoversiktlig og det tar lang tid å finne ut hvor terminalene befinner seg til enhver tid. Metoden inneholder en rekke feilkilder og manuelle operasjoner. Systemet kommuniserer heller ikke med andre programmer, som skaper store problemer for bedriften og er en dårlig løsning for håndtering av logistikk. 3.2 Mål Målet med prosjektet er å lage et logistikksystem som holder oversikt over hvor terminalene befinner seg til enhver tid. Brukerne av systemet vil være datakyndige, men det er ønskelig at systemet skal være mest mulig brukervennlig. Bedriften vil eie dette produktet og vil ha alle rettigheter på videreutvikling. Page 7 of 106

8 4 Planlegging og styring Vi startet med et gruppemøte, hvor alle medlemmer i gruppa kom med forslag om hvordan vi skulle gå videre med prosjektet. Vi leste nøye gjennom kravspesifikasjonen fra PayEx da denne var klar, for å få klarhet i hva de var ute etter, hvilke funksjoner de ville at systemet skulle utføre og forestille oss et helhetsbilde av systemet generelt. Deretter prøvde vi å finne ut hvilke programmeringsspråk og verktøy vi skulle bruke. PHP/javascript og HTML ble foreslått men til slutt falt valget for C# og bruk av Visual Studio. For å lage designutkast brukte vi Balsamiq Mockups, som er et prototypingsverktøy. ArgoUML og Visual Paradigm ble brukt for å lage use-case og sekvensdiagrammer. Microsoft Word brukte vi for å lage strukturdiagram og generell tekstbehandling. Vi benyttet oss av Dropbox for å dele filer mellom gruppens medlemmer. I tillegg tok vi også i bruk Teamviewer for å kunne dele hverandres skjermbilder med direkteoverføring. Helt til slutt kan vi også nevne at vi hadde en felles e-post for å kommunisere med oppdragsgiver. Av e-posttilbydere valgte vi Gmail, som også muliggjør dokumentdeling på en grei måte. Det var nødvendig å lære programmeringsspråket C# for gruppen, og dette måtte skje hurtig. For å gjøre dette brukte vi en del bøker og diverse nettsider. En fullstendig liste over bøker og nettsider som ble brukt under prosessen finnes i slutten av dette dokumentet. Før vi startet med programmeringen ble det på forhånd planlagt hvordan grensesnittet, databasestruktur og egenskaper skulle være. Vi startet med å lage en prototype på papir for så å overføre disse til et velegnet program ut fra de krav som måtte oppfylles i kravspesifikasjonen. Disse ble så presentert for oppdragsgiver for godkjenning før vi startet med utviklingen. Page 8 of 106

9 4.1 Rammebetingelser Ut i fra kontrakten vi skrev med PayEx, skal ikke prosjektet påføre bedriften noen ekstra kostnader i form av betaling for tjenesten eller ekstra programvarer som trenger lisensiering. PayEx skal ha mulighet til å videreutvikle systemet på egenhånd, dermed må all form for koding som blir brukt for systemutviklingen og dokumentasjoner være tilgjengelig for bedriften. Tiden vi hadde tilgjengelig utstrakte seg fra starten av 2. semesteret til nær slutten av skoleåret. 4.2 Ressurser Vår kontaktperson i PayEx var Rolf Berthelsen som sto til rådighet ved spørsmål angående systemkrav og spesifikasjoner. Mats Andre Bækkelund og Jan Ljungkvist gav oss de nødvendige listene som vi trengte for å importere informasjon til vår database. Siavash, et medlem i gruppen, er deltidsansatt i bedriften. Dette var en stor fordel da han hadde innsikt i problemstillingen og var i kontakt med oppdragsgiveren kontinuerlig. Page 9 of 106

10 4.3 Prosjektstyringsverktøy Alt av dokumentasjon som vi har utarbeidet for planlegging og styring av prosjektet har vi brukt som prosjektstyringsverktøy Utviklingsmetode Vi valgte å bruke UP-light (Unified Process) som utviklingsmetode i vårt prosjekt, dette er en agil (smidig) metode vi mente passet best for vårt prosjekt. Dette fordi vi da har mulighet for større valgfrihet og kan tilpasse ting etter behov. Vi har benyttet oss av fire forskjellige faser UP-light består av. Disse fasene er: Idéfasen Hvor vi gjorde oss kjent med krav og omfang dette prosjektet ville ha, for å se at dette vi kunne la seg gjennomføre innen tidsrammen. Dette skjedde under gruppemøter tidlig i startfasen av prosjektet. Utdypningsfasen Startet med planlegging etter detaljerte krav, lagde fremdriftsplan, risikoplan og arbeidsplan. Prototyping av utseende og funksjoner for applikasjonen på papir og egnet verktøy. Utfordringer vi hadde i denne fasen var å lage gode nok planer for en stabil og jevn progresjon. Slik at det var mulig å komme i mål i henhold til tidsskjema. Konstruksjonsfasen Fasen brukte vi til programmering med Visual Studio og testing av funksjoner etter hvert som disse ble ferdige. Vi besøkte også oppdragsgiver jevnlig for å få godkjenning av løsninger. Denne fasen viste seg å være meget utfordrende, da vi her måtte vi lære oss nytt programmeringsspråk og ta i bruk ny og ukjent programvare. Allerede ved installasjonen fikk vi en del problemer som måtte løses før vi kom i gang. En av disse var at vi ikke fikk kontakt med Team Foundation Serveren grunnet feil versjonsnummer av SQLExpress på lokale maskinr. Det varte ikke lenge før et nytt problem oppstod, Visual Studio låste seg da til en bruker så ingen andre fikk gjøre noe. Dette brukte vi mye tid og ressurser på å finne ut av ved å spørre faglærere på skolen, andre elever og søke etter svar på nettet. Det var ikke alltid like lett å finnes svar på alt, da heller ikke faglærerne hadde vært borti problemene før. Page 10 of 106

11 Kode måtte skrives på en pen og ryddig måte slik at det ble lettere å feilsøke. Klargjøre slik at det i fremtiden er mulig å implementere nye funksjoner for oppdragsgiver. Ekstra vanskelig var å få til enkelte funksjoner til slik som import av data fra Excel, og hvordan håndtere designet slik at det ble en god brukervennlighet. Overgangsfasen Prosjektgruppen var i et avtalt møte med oppdragsgiver, hvor vår kontaktperson Rolf Berthelsen, Mats Andre Bækkelund som er avdelingsleder for team produksjon og Anders Gran som er director business development retail var til stede. Under dette møtet som ble holdt i et konferanserom hos PayEx, presenterte vi produktet for å se om det holdt mål etter deres ønske. De var godt fornøyde, vi fikk blant annet gode tilbakemeldinger når det gjaldt designet på applikasjonen og måten vi hadde løst import av lister på Fremdriftsplan Fremtidsplanen er en oversikt som viser estimert tid for hver fase i prosjektet. Den tar utgangspunkt fra start av planlegging og frem til presentasjon av prosjektet. Fremdriftsplanen gir også en indikasjon på progresjon. Vår fremdriftsplan er lagt til som vedlegg Risikoplanlegging Det er veldig nyttig å ha oversikt over hva som kan gå feil i det prosjekt arbeidet starter. Men enda viktigere er det å være godt forberedt og ha gode tiltak for å unngå det. Risikoplanlegging og risikostyring er lagt til som vedlegg 2 i dette dokumentet Arbeidsplan Arbeidsplanen er en detaljert beskrivelse av utført arbeid. Planen gir en oversikt over hvem i gruppen har gjort hva og under hvilke tidspunkt. Arbeidsplanen er lagt til som vedlegg 3. Page 11 of 106

12 5 Kravspesifikasjon Dokumentet som beskriver hvordan logistikksystemet skal fungere, og hvilke rammer prosjektet skal gjennomføres innenfor, kalles kravspesifikasjon. Først ble gruppen presentert med problemstilling og en kort kravspesifikasjon til systemet fra PayEx. Med utgangspunkt i dette laget prosjektgruppen et forslag til kravspesifikasjon som ble presentert for veileder og kontaktpersonen hos oppdragsgiver. Gruppen fikk tilbakemelding omgående og disse tilbakemeldingene ble brukt til å revidere dokumentet. Prosessen gjentok seg til alle parter var enige. Sluttdokumentet gjenspeilet arbeidsgivers ønsker og krav, og samtidig virket det gjennomførbart innen rammene som ble satt. 5.1 Endringer i kravspesifikasjon Den eneste endringen som ble utført i henhold til kravspesifikasjonen er at faktureringsdelen skulle implementeres ved et senere tidspunkt. PayEx ønsket å migrere vår applikasjon mot deres nåværende faktureringssystem, noe de kaller for PBA. Dette lot seg ikke gjøre ettersom oppdragsgiverens faktureringssystem i dag drives av en annen avdeling som holder til i Stockholm. Oppdragsgiver klarte ikke å tilrettelegge nødvendig informasjon til oss for utvikling av dette. 5.2 Sammendrag av kravspesifikasjonen Prosjektgruppen skal utvikle et webbasert logistikksystem som skal holde oversikt over betalingsterminalene til PayEx. Applikasjonen skal ligge lokalt hos bedriften hvor ansatte skal ha mulighet til å legge til, slette og endre informasjon om betalingsterminaler. De skal også kunne endre lagret informasjon om kunder. Applikasjonen skal bruke maskinvare og programvare som PayEx allerede har. Skal det brukes noen form for installasjon av annen programvare som bedriften ikke allerede har, må de få beskjed om det på forhånd, slik at dette kan overveies. Page 12 of 106

13 Vi har flere spesifikke krav til systemet, blant annet: Terminalene skal identifiseres på sin ped id (serienummer). Hvilken merchant id (kunde) terminalen ble sendt til Når terminalen har vært til reparasjon og hvilke feil den hadde Hvilke ped id er terminalen har hatt Det skal kunne tas ut rapporter på alt dette Det må være mulig å importere data i systemet. Spesielt i form av excelark med ped id er. Den endelige kravspesifikasjon som ble godkjent av oppdragsgiver er lagt til i dette dokumentet som vedlegg 4. Page 13 of 106

14 6 Analyse Analysefasen gikk ut på å gå gjennom hele oppgaven punkt for punkt, samle inn mer informasjon fra bedriften og bli kjent med hele arbeidsmengden. Det ville sikre oss om det var mulig å gjennomføre alt innen rammene. For å kunne legge inn data inn i vår applikasjon trengte vi diverse lister i form av excel ark, noe PayEx skaffet oss. Vi trengte en liste over alle betalingsterminalene som bedriften har hos sine kunder med nødvendige informasjon om kundene, samt en liste over feilmeldinger en betalingsterminal kan ha om den skulle bli registrert som defekt. For å kunne skanne inn serienummer til en betalingsterminal, noe som var ønskelig, fikk vi låne en skanner av PayEx for utvikling og testing. 6.1 Strukturkart For å illustrere en grafisk representasjon av hvilke sider som skal være med i webapplikasjonen bruker vi strukturkart. Kartet vil gi en oversikt over arbeidsmengen som kreves for å lage web-applikasjonen samt hjelpe oss å planlegge navigering av sidene. Til høyre er en forenklet versjon av strukturkartet vi laget, den viser hvilke områder av applikasjonen man har tilgang til med et klikk fra forsiden. Edit/Save Production Search Customer info Register defect Figur strukturkart, forenklet Send new Admin-fanen har man kun tilgang til om man logger inn som admin, ellers er den ikke synlig for vanlige brukere (ansatte). Kartet finnes i sin helhet som vedlegg 5 i dette dokumentet. Page 14 of 106

15 6.2 Papirprototype Ut fra strukturkartet laget vi et utkast til de forskjellige sidene til web-applikasjonen på papir. Et lite utkast av dette er vist på bildet under. Figur Papirprototype I et senere møte med arbeidsgiver og veileder, kom det frem eventuelle endringer og misforståelser som var tilstede frem til det punktet. Fanen Customer storage ville oppdragsgiver kalle for Production, contact information var unødvendig å ha på hver side. Derfor ble en ny fane ble lagt til, info fanen, for å gi en kort beskrivelse av hva som befinner seg på hver enkelt fane. Page 15 of 106

16 Etter hvert ble papirtegningene overført til Balsamiq Mockups og vi fortsatte å designe ved hjelp av dette programmet. Dette for å spare tid og ha en bedre oversikt generelt. Et lite utkast av dette er vist i figuren under. Figur Balsamiq Mockup prototype En fullstendig illustrasjon av web-applikasjonen i Balsamiq Mockups finnes som vedlegg 6 i dette dokumentet. 6.3 Use-Case Use-case viser hvordan et system fungerer med forskjellige brukertyper, hvilke handlinger hver bruker kan utføre og forholdet mellom disse. En beskrivelse av hele systemet er illusterert i vårt use-case diagram: Page 16 of 106

17 Figur Use-Case diagram, liten Slik vist på diagrammet, består systemet av to typer brukere. Administrator og vanlig bruker (ansatt). Administrator har, i tillegg til vanlig brukers rettigheter, tilgang til: - Legge til bruker - Slette bruker - Redigere bruker - Importere kunder - Importere postnummer - Importere terminaler Større versjon av diagrammet er lagt til som vedlegg 7 i dette dokumentet. Beskrivelse av use-case diagrammet er lagt til som vedlegg 8 i dette dokumentet. 7 Design Den detaljerte planlegging for programmering av systemet kalles design av systemet. Vi måtte planlegge den grafiske delen, databasen, brukergrensesnittet og logikken i programmet i detaljer før vi kunne gå videre. Vi fikk ingen spesifikke krav fra oppdragsgiveren angående design av systemet, men vår design baserer seg på brukervennlighet og bruk av programvarer som PayEx allerede kjenner Page 17 of 106

18 til og innehar. Dette fordi videreutvikling av applikasjonen skulle bli lettere for oppdragsgiveren. Vi tok utgangspunkt i papirprototypen og Balsamiq Mockups-prototypen og designet et fullverdig grensesnitt. 7.1 Grensesnittet Det visuelle grensesnittet, altså det brukeren ser og oppfatter, er veldig enkelt og nøytral uten noen form for distraherende elementer. Det er vektlagt funksjonalitet da dette er et verktøy å ingen webside i den forstand. Som man ser på figuren under er bakgrunnen hvit og nøytral. PayEx sin egen logo er plassert øverst til venstre. Hurtigvalg for utvalgte land og informasjon om man er pålogget eller ikke og søke felt finner man på høyre side. For at brukeren skal slippe å bytte eller åpne nye sider når han arbeider på flere ting samtidig, har vi valgt å bruke faner som deler de forskjellige gruppene. Fargene som er valgt på fanene har vi hentet fra PayEx sin hjemmeside, på den måten kan førsteinntrykket på dette verktøyet virke litt kjent for brukeren. Vi har lagt ut skjermbildene av applikasjonen som vedlegg 9. Page 18 of 106

19 7.2 Programmet Programmet er hjernen i systemet og bestemmer hva som skjer når man trykker på en gitt knapp. Det blir ikke lagret noe informasjon i selve programmet, som henter all informasjonen fra tilhørende database. Vi tok utgangspunkt i use-case diagrammet fra analysefasen, og startet med utvikling av selve programmet. Vi laget sekvensdiagrammer, hvor vi tok for oss viktige handlinger i systemet og fremstilte dem grafisk. Når sekvensdiagrammene var ferdig laget hadde vi nok informajson til å lage et klassediagram for systemet. Klassediagram viser hvordan systemet er bygget opp og hvordan forskjellige deler av programmet er koblet sammen. Figur Klassediagram, eksempel Sekvensdiagrammene og klassediagrammene er vedlagt i dette dokumentet, se vedlegg 10 og 11. En av utfordringene med programmet har først og fremst vært design av siden. Det vil si arbeidet med å gjøre siden mest mulig brukervennlig for den ansatte hos PayEx. Fordi det ene Figur Sekvensdiagram, eksempel gruppemedlemmet jobber i bedriften, kunne vi på en enklere måte finne ut hvordan funksjonene bør være. Denne samhandlingsprosessen tok mye tid helt fra utkast på papir, gjennom design i Balsamiq Mockups og til endelig koding av designet i Visual Studio. Dette var nok den vanskeligste oppgaven. Videre fulgte det problematikk og utfordringer angående import av data fra Excel. PayEx har excel-ark med kundeinformasjon, bestående av rundt linjer. Denne informasjonen var det høyst nødvendig å kunne importere til vår database. Etter mye lesing i bøker og på Page 19 of 106

20 nett, fant vi for det meste bare løsninger for å kunne importere hvis excel-filen ligger lokalt på en PC, og det er en skrivebordsapplikasjon som skal importere. Altså, at selve programmet ligger på den samme PC som filen. Fordi systemet våres ligger i nettskyene skapte dette en utfordring. Løsningen vår ble til slutt å legge til en opplastingsmetode som lagrer filen på server, og sletter den etter bruk. Sistnevnte for å frigjøre plass og ressurser. For å importere dataene måtte vi legge til en Excel dataconnection i kodingen, som sørget for at systemet får informasjon om at filen den leser fra er laget av Excel. Dermed kunne vi bruke en normal SQL-spørring på radene i excel-arket, og en SQL-funksjon tok seg av lesing og innsetting til databasen. Page 20 of 106

21 7.3 Database En database er et elektronisk arkiv som brukes for å lagre informasjon. Databaser inneholder forskjellige tabeller og skjemaer hvor informasjon som er lagret kan lett hentes ut for brukere med rett tilgang. For å lagre de nødvendige informasjonene som er gjeldende vårt system har vi laget to databaser. Den ene var produksjonsdatabase som lagrer informasjon om kunder, produksjonsterminaler og brukere. Denne databasen innholder 17 tabeller. Den andre databasen er tilrettelagt for testterminaler og leverandører som låner disse. Denne består av 11 tabeller. Strukturen for disse er laget fra ER diagram som vi først tegnet på papir. Vist under er figurer av tabellene. Disse databasene legges opp på server internt hos Payex slik at Figur Produksjons base, tabeller de lett kan drifte og administrere disse selv. For å designe databasen, tok vi utgangspunkt i alle tidligere designdokumenter og laget et ER-diagram, som tok for seg relasjonene til de forksjellige tabellene. Figur Test base, tabeller Page 21 of 106

22 Figur under viser sammenslåtte tabeller fra produksjonsdatabasen. Figur Koblinger prod.database ER-diagrammet er lagt til som vedlegg 12. Page 22 of 106

23 8 Trelagsarkitektur Vi har lagdelt applikasjonen vår. Dette vil si at vi har 1 mappe som inneholder websiden og 3 mapper som inneholder klassefiler. En slik type lagdelingsarkitektur kalles for MVC (Model View Controller). Vi bruker denne lagdelingen for å gjøre applikasjonen sikrere, og mer oversiktlig. Model-mappen brukes for å lage en klassefil for hver tabell vi har i databasen. Hver av disse klassefilene har metoder som gjør at vi kan hente ut og lagre informasjon fra tilhørende tabell. I denne mappen kaller vi klassefilene for tabellnavnet. PayEx mappen inneholder alt av webfiler og code-behind filer som gjør det at siden er funksjonell og kan vises på nettet. BLL (Business Logic Layer) bruker vi som et mellomlag mellom websiden vår og DAL mappen. Her kan man om man vil, gjøre tester på innkommende verdier. Dette kan også gjøres i PayEx- laget (View- laget ). Det er en metode i BLL som oppretter en kobling til DAL, og vi kan da videreføre og tilbakesende informasjon. DAL (Data Access Layer) inneholder alle klassefilene som "snakker" direkte med databasen. I disse filene har vi blant annet metoder som setter inn, sletter, oppdaterer og henter ut informasjon fra databasen. Figur Trelagsarkitektur Page 23 of 106

24 9 Testing Det er foretatt kontinuerlig testing av de forskjellige funksjonene etter hvert som disse var klare. Testingen gikk ut på å eliminere forskjellige typer feil som vi regnet med kunne oppstå. Ved å gjennomføre slike tester får man et sikrere og mer stabilt system samt trygghet for eventuelle brukere. Eksempler på ulike tester som er utført er sikkerhet ved innlogging, import av data fra excelark, søk etter kunder, redigering av data og sletting. Det var også vektlagt at systemet skulle si i fra ved hjelp av feilmeldinger når forskjellige feil fremstod. Det ble også utført test av knappene i applikasjonen, slik at en gitt knapp utførte riktig handling. I vedlegg 13 finnes en oversikt over disse ulike testene. Page 24 of 106

25 10 Konklusjon 10.1 Oppsummering Alt i alt er vi godt fornøyd med resultatet. Det har vært en lærerik prosess, både angående programmering og generell utvikling av en programvare med tanke på alle dets aspekter. Vi har fått med oss verdifull erfaring for en større systemutvikling, noe som vil komme oss godt i fremtiden. Oppdragsgiver sin størrelse og at systemet skal tas i bruk har vært motiverende for oss Ønsker for fremtiden Systemet skal settes i drift i løpet av sommeren Vi håper det blir en suksess, og at det de ansatte ved PayEx vil være fornøyde med det nye systemet vi har laget. Det er laget en liste over mulige utvidelser av funksjonaliteten. Denne håper vi kan implementeres i løpet av kort tid. Se punkt 10.1 i produktdokumentasjonen. Der finnes forslag fra vår part med forslag til nye og viktige funksjoner som vil komme systemet til gode Hva kunne vært gjort bedre? Antall funksjoner. Det har alltid vært i bakhodet at systemet skal settes i drift i sommer. Derfor har vi under utviklingen vært nødt til å prioritere de viktigste funksjonene i tillegg til å sørge for god brukerkvalitet, slik at systemet skulle fungere tilfredsstillende og bli ferdig i tide. Page 25 of 106

26 10.4 Ikke implementert funksjonalitet Oppdragsgiveren ønsket å kunne ta ut rapporter på alt som har med terminaler å gjøre. Vi klarte ikke å implementere denne funksjonen under tidsrammen, og valgte av den grunn å gi et oversiktsbilde over antall terminaler på hvert lager på Country selection-siden. Det var også ønskelig å ha en separat database som tar for seg testterminaler og deres livsløp. Vi har tilrettelagt tabellene for denne basen, men prioriterte ikke implementasjon av den i vårt applikasjon. Grunnen til det var for å kunne komme i mål i tide og vi prioriterte andre funksjoner slik at vi kunne levere et kjørbart produkt. Page 26 of 106

27 11 Ordliste 11.1 Systemet Production - Kundelager. In production Internt lager hos PayEx. Defect Oversikt og håndtering av defekte terminaler. Admin Bruker med administratorrettigheter i applikasjonen. Discarded Betalingsterminaler som ikke lenger er i bruk. Kasserte terminaler Programvare Balsamiq Mockups Prototypingsverktøy for å lage design til siden. Database Designer- Brukt for å lage ER diagram. Argo UML, Visual Paradigm Ble brukt for å lage Use Case og sekvensdiagrammer. Visual Studio Ble brukt for å utvikle systemet. Microsoft Word - For å skrive dokumentasjon. Gantt diagram - Ble brukt for å lage fremdriftsplan. Microsoft Excel For å importerer data i systemet. Team viewer For å hjelpe hverandre via direkteoverføring av hverandres skjermbilder. Drop box Felles område for å legge ut dokumenter og filer. Google Mail For fordeling av informasjon mellom gruppemedlemmer og oppdragsgiveren samt prosjektveilederen. Skype For å kunne hjelpe hverandre. MS SQL Server Microsofts sin egen SQL server og er implementert i Visual Studio. Brukt for å lage databasen. ASP.NET Siste utgave av.net plattformen (april, 2010). Page 27 of 106

28 12 Kilde henvisning 12.1 Bøker Troelsen, A. (2010). Pro C# 2010 and the.net 4 Platform, Fifth Edition. USA: Apress. Gunnerseon, E. (2000). A Programmer s Introduction to C#. USA: Apress. Mackey, A. (2010). Introducing.Net 4.0: With Visual Studio USA: Apress. Griffiths I., Adams M., Liberty J. (2010). Programming C# 4.0: Building Windows, Web, and RIA Applications for the.net USA: O'Reilly. Sempf B.,Sphar C., Randy Davis S., Sphar C. (2010). C# 2010 All-in-One For Dummies USA: Wiley Publishing, Inc. Mayo J. (2010). Microsoft Visual Studio 2010: A Beginner's Guide. USA: McGraw-Hill Osborne Media Novak I., Velvart A., Granicz A., Balassy G., Hajdrik A., Kanjilal J., Hillar G., Sellers M.,Molnar A. (2010). Visual Studio 2010 and.net 4 Six-in-One USA: Wrox Press Page 28 of 106

29 13 Vedlegg 13.1 Vedlegg 1: Fremdriftsplan 13.2 Vedlegg 2: Risikoplan og risikostyring 13.3 Vedlegg 3: Arbeidsplan 13.4 Vedlegg 4: Kravspesifikasjon 13.5 Vedlegg 5: Strukturkart 13.6 Vedlegg 6: Balsamiq Mockups prototype 13.7 Vedlegg 7: Use-case diagram 13.8 Vedlegg 8: Beskrivelse av use-case 13.9 Vedlegg 9: Skjermbilder av applikasjonen Vedlegg 10: Sekvensdiagram Vedlegg 11: Klassediagram Vedlegg 12: ER diagram Vedlegg 13: Test resultater Page 29 of 106

30 1.1 Vedlegg 1: Fremdriftsplan Page 30 of 106

31 1.2 Vedlegg 2: Risikoplan og Risikostyring Risikoplan Risikostyring Risiko Sannsynlighet Følger Kommunikasjonssvikt 25 % Alvorlig Sykdom 20 % Middels For lite tid 15 % Alvorlig Tap av data 10 % Middels Gruppemedlem slutter 5 % Alvorlig Mangel på motivasjon 5 % Alvorlig Ny prosjektleder med andre 5 % Middels prioriteringer Mangler kompetanse 25 % Alvorlig Tekniske problemer 25 % Alvorlig Risiko Kommunikasjonssvikt Sykdom Mangler kompetanse For lite tid Tap av data Gruppemedlem slutter Mangel på motivasjon Tekniske problemer Strategi Gruppekontakt Ekstra jobb på de andre medlemmene/jobbe hjemmefra Lese og tilegne kunnskapen for å bruke det i prosjektet Jobbe ekstra timer Backup av all data. Ny fordeling av arbeidsmengde En for alle og alle for en! Søke om informasjon på nettet, søke hjelp hos veilederen og kontakte aktuelle faglærere. Page 31 of 106

32 1.3 Vedlegg 3: Arbeidsplan Aktivitet Beskrivelse Ansvarlig Planlagt Utført Gruppe dannes Gruppe med fire studenter dannes, oppdragsgiveren valgt. Hjemmesiden Hjemmesiden til prosjektet lages. Alt av dokumentasjon legges ut der. Finnes på ss.com/ Viktorija 19 oktober 2010 Statusrapport Samarbeidsavtale Prosjektskisse Analyse Informasjonsinnhenting Dokument om gruppe medlemmer, oppdragsgiver og hva prosjektet vil gå ut på. Dokument signert mellom oppdragsgiveren og Høyskolen i Oslo Beskrivelse av prosjektet, navn og data Hyppig kontakt med PayEx for innsamling av nødvendig informasjon Page 32 of oktober 2010 u.5 u.5 25 november 2010 Siavash Uke 46, 2010 Forprosjekt Prosjektet defineres Glenn u.4 u.6 Fremdriftsplan Kravspesifikasjon Arbeidsplan Prototype Use Case Gantt diagram med fremdriftsplanen lages. Avtale mellom gruppen og oppdragsgiver om hva som skal gjøres Aktiviteter som skal utføres gjennom prosjektet Modellering av logistikksystem ved bruk av Balsamiq Mockups Beskrivelse av funksjonelle krav til systemet. 20 oktober, 2010 (fortsetter hele semester) 28 oktober desember 2010 Uke 18, 2011 Thomas 31 januar 31 januar Siavash u.6 u.10 Viktorija u.5 u.5 Thomas u.6 u.8 Viktorija u.6 u.9 Design ER - diagram Database struktur Glenn u.5 u.7 Grensesnitt Programmets utseende Siavash u.4 u.12 Ordbok Ordbok Siavash u.2 u.21 UML - diagrammer Klasse- og Viktorija u.5 u.14.

33 sekvensdiagrammer Implementering Grensesnitt utvikling Utvikles i Visual Studio Thomas u.7 u.21 Database SQL Glenn u.10 u.17 Programmering C#, LINQ og SQL Thomas u.8 u.21 Testing Programtest Utført hver gang ny funksjon ble lagt til Viktorija u.17 u.21 Dokumentasjon Resultat ført ut i tabell Glenn u.19 u.20 Dokumentasjon Styringsdokumentasjon Viktorija u.20 u.21 Arbeidsplan, fremdriftsplan og kravspesifikasjon Produktdokumentasjon Detaljert beskrivelse av Thomas u.20 u.21 produktet Brukerdokumentasjon Detaljert brukermanual Glenn u.20 u.21 Prosessdokumentasjon Siavash u.20 u.21 Presentasjon, forberedelse u.22 u.23 Presentasjon u kl. 10:50 Page 33 of 106

34 1.4 Vedlegg 4: Kravspesifikasjon Presentasjon Tittel Oppgave Logsitikksystem Utvikle et logistikksystem for betalingsterminalene til PayEx Periode 5. januar 2011 til 31. mai 2011 Prosjektgruppe 16 Prosjektmedlemmer Veileder Oppdragsgiver Siavash Delgosar, Thomas Kvernevik, Viktorija Nyberg, Glenn Halvorsen Eva Hadler PayEx Kontaktperson Rolf Berthelsen, tlf Page 34 of 106

35 Innledning Dette hovedprosjektet ved HiO ingenøravdelingen og som skal gjennomføres av gruppe studenter som består av Thomas Aleksander Kvernevik, Siavash Delgosar Maher, Glenn Halvorsen, Viktorija Nyberg i samarbeid med Payex. Payex ønsker seg et logistikksystem som holder oversikt over terminalene deres. Om bedriften PayEx er en av Nordens fremste eksperter på betalinger. Bedriften har omlag seks hundre ansatte. Siden starten i 1972 har de utviklet en solid kompetanse på områder som betalingsløsninger for internett, mobil og fysisk handel, rating/fakturering, faktura og reskontro håndtering, inkasso og kredittadministrasjon. Dagens situasjon PayEx har en god del forskjellig terminaler i omløp. Disse terminalene er det ikke så lett å holde oversikten over. Deres system i dag er rett og slett ikke god nok, det er uoversiktlig og det tar lang tid å finne ut hvor terminalene befinner seg til enhver tid. Det trenges et system som følger hver terminals livsløp. Brukerne av systemet vi skal lage er datakyndige, men det er ønskelig at systemet skal være mest mulig brukervennlig. Vi skal utvikle et logistikk system for bedriften, som holder oversikt over terminalene deres. Informasjonen skal lagres direkte i en database. Ved hjelp av denne basen skal PayEx kunne spore enhver terminal om hvor den befinner seg per dags dato. Page 35 of 106

36 Bakrunn for prosjektet Bedriften benytter i dag regneark for å holde oversikt over betalingsterminalene sine, om de er på lagret, sendt til kunden eller er på reparasjon. Denne metoden inneholder en rekke feilkilder og manuelle operasjoner. Systemet kommuniserer heller ikke med andre programmer. Dette skaper store problemer for bedriften og er en dårlig løsning for håndtering av logistikk. Forord Hensikten med kravspesifikasjon er å kunne holde oversikt over at begge partene har god forståelse og oversikt over hva selve prosjektet går ut på. Slik at begge partene blir fornøyde med sluttproduktet. Vi har fått en del av spesifikke krav som PayEx ønsker/må ha på systemet vi lager. Page 36 of 106

37 1.0 Systemkrav Oppdragsgiveren hadde flere klart formulerte krav helt fra starten av prosjektet. Altså funksjoner systemet skal kunne utføre. 1.1 Spesifikke krav fra PayEx Terminalene skal identifiseres på sin ped id (serienummer). Knyttet til serienummer skal være produksjonsnummer Første gang terminalen ble registrert i databasen Hvilken merchant id (kunde) terminalen ble sendt til og når den ble fakturert Når terminalen har vært på reparasjon og med hvilken feil den hadde og når reparasjonen ble fakturert Hvilke ped id er terminalen har hatt Det skal kunne tas ut rapporter på alt dette Det må være mulig å koble seg til databasen slik at vi kanskje kan knytte den sammen med andre 1.2 Systemet bør inneholde: Innloggingsfunksjon. Registrering/avregistrering av betalingsterminaler i rett lager. Registrering av innkommede/utsendte betalingsterminaler fra/til reparasjon. Oversikt/historikk over betalingsterminaler. Det må være mulig å importere data i systemet. Det skal være et likt oppsett for testterminaler som håndteres i en egen database eller separert fra produksjonsterminalene. Systemet må kunne nås fra hvilken som helst pc i Norge, Sverige og DK. Det må kunne knyttes en strekkodeleser til systemet. Må kunne brukes på vanlige PC er med vanlig Windows 7 eller Windows XP installert. Et enkelt brukergrensesnitt. Page 37 of 106

38 1.3 Funksjoner som kan implementeres senere: Kunne kople systemet til en faktureringssystem som PayEx allerede har. 1.4 Funksjoner som vi syns burde være med på systemet Sendes til kunde Sendes inn av kunde. KundeID som brukes. Den består av X antall siffer. Det er viktig å registrere dato når terminalen ble sendt inn, når den er videresendt til reparasjon, når den er kommet tilbake fra reparasjon, og når kunden får ny, reparert terminal. Samtidig skal man kunne spore utsendingene med et sporingsnummer. Når PayEx sender terminal til kunden må de opplyse kunden om sporingsnummeret for videre oppfølging. Testes for feil Det finnes mange forskjellige type feil som kan oppstå i terminalene. Hvis terminalen blir defekt innen 6 mnd er det garanti som gjelder, ellers blir kunden fakturert fullt beløp for reparasjon. Mottatt terminal blir testet av en ansatt lokalt hos PayEx, hvor feiltype registreres. Følgende feiltyper kan forekomme: Display defekt, terminalen er død, chipleseren er defekt, osv En eller flere av disse kan velges ved registrering av feil. Hver feil type får sin egen ID. Sendes til reparasjon Når PayEx har 10 eller flere defekte terminaler på lageret, må disse sendes ut for reparasjon. Hver utsendelse må registreres og lagres i systemet. Page 38 of 106

39 Det må kunne hentes ut en liste fra systemet hvor det står hvilke terminal som ble sendt (serienummer), hva slags feil de hadde (feil_id) og dato de ble sendt, for Hver pakke. Hver liste må få en egen ID i systemet. Ved utsendelse må PayEx først få et RMA-nummer fra reparatøren. RMA-nummeret består av bokstavene RMA + 5 siffer. Dette RMA-nummeret må kobles til riktig liste_id, og må skrives inn for hånd på systemet. Disse utsendelsene får hver sine sporingsnummer fra Posten i tillegg. Dette også må kobles til liste_id. Kommer tilbake fra reparasjon Hver terminal som kommer tilbake fra reparasjon får nytt serienummer. Da må de gamle overskrives med det nye serienummeret. Det er viktig å holde logg om de utførte reparasjoner, tidligere eiere og alle tidligere serienummer til terminalen. Det er viktig å registrere dato når terminalene har kommet tilbake og antall terminaler fra Danmark. Slik kan det holdes oversikt over hvor lenge de befant seg på reparasjon og om PayEx har fått tilbake alle terminaler de har sendt ut til reparasjon. Om noen av terminalene av et gitt RMA-nummer fortsatt befinner seg i Danmark, må det kunne lagres i en egen tabell i systemet for disse. Her må det stå hvilke terminaler (serienummer) det gjelder, hvilke RMA-nummer de tilhørte og hvilken dato de ble sendt ut til reparasjon. Når terminalene er reparert og registrert må de flyttes vekk fra defektlisten og flyttes til produksjonslisten. Page 39 of 106

40 Kassering Ved kassering skal terminalene tas vekk fra nåværende liste og flyttes til en kasseringsliste. Nye terminaler Når PayEx bestiller nye terminaler må disse registreres i databasen. Her må det lagres hvilket serienummer de har, hva slags modell og hvilket år de ble produsert. Og videre oppfølging av hvor de blir sendt til, om de kommer tilbake og ellers hele livsløpet. Page 40 of 106

41 2.0 Funksjonalitet på web-applikasjonen Språk: Engelsk. Administrator innlogging. Administrator kan da lage brukere med passord og evt. tilbakestille/slette en bruker. Han kan slette kunder fra systemet. Passord blir generert automatisk av passordgenerator, mens brukernavn blir laget av administrator. Alle brukere skal ha mulighet til å endre passord ved innlogging. Dette er den viktigste funksjonen en administrator har per dags dato, men det er mulighet til å utvide/implementere flere funksjoner etter hvert (for eksempel endre modell på terminaler, lage, slette bestilling/terminaler osv, osv). Ellers får alle som bruker systemet utdelt en bruker/passord fra administrator. Og alle vanlige brukere kan henvende seg til administrator for diverse spørsmål. Etter innlogging får man velge hvilke lager man skal gå til (Norge, Sverige, Danmark). Etterpå får man velge hvilke type lager vil man gå til. Lagertyper å velge er produksjonslager, reparasjonslager, testlager og kundelager. Produksjonslager Det er alle terminaler som vi har tilgjengelig for å sende ut til kunder. Det skal være en søkefunksjon for å søke opp terminalen uansett hvor de befinner seg. Det skal være mulig å velge mellom serviceterminaler og nye terminaler. Hver av de må ha en registreringsfunksjon. Samt må det være mulig å ta opptelling og registrering. Page 41 of 106

42 Reparasjonslager Leveringsliste må kunne skrives ut med den tildelte RMA pluss diverse annet, som et vanlig dokument på A4 ark. Dette videresendes til Danmark for å få bekreftelse, sendes sammen med terminalene til reparasjon. Det er viktig å ha sporingsnummeret for å kunne spore opp pakken. Dette nummeret trenger ikke å forekomme på utsendelsesark (med RMA). Det burde være en funksjon som advarer om at det har gått over 25 dager og terminalene ikke er kommet tilbake. Og etter 35 dager kommer en ny advarsel som minner om at det har gått for lang tid. Mottatt terminal blir testet av en ansatt lokalt hos PayEx og feiltype registreres. Følgende feiltyper kan forekomme: display defekt, terminalen er død, chipleseren er defekt, osv, osv En eller flere av disse kan velges ved registrering av feil. Hver feil type får sin egen ID. Når terminalen kommer til bedriften fra kunde, blir den testet for feil og dersom den er defekt blir den lagt til på det fysiske reparasjonslageret. De reparerte terminalene som kommer fra Danmark må registreres på reparasjonslager. De må registreres med dato, nytt serienummer og hvilke RMA de har tilhørt. Testlager Oversikt over testterminaler. Nesten alt er likt som de andre lagerene (produksjonslager, reparasjonslager og kundelager). Forskjellen er at terminalene blir leid ut til leverandører, i stedet for enkelt kunder. Kundelager Det gjelder både for private kunder og bedrifter. Page 42 of 106

43 Oversikt over alle terminaler som er hos kunder per dags dato. Kunde_ID, merchant_id (unik for kunder), organisasjons_id, antall terminaler dem har hos seg, hvilken dato terminaler ble sendt til dem og/ eller når var den siste terminalen sendt til kunde (historikk), tlf nr, adresse osv. Samt viktig å holde oversikt over hver enkelt kundes handlehistorikk. Viktig å ha postens sporingsnummer på både utsendelses- og returlapp (valgfritt). Country selection Her vil de også ha en oversikt for hvert land med antall terminaler som er hos kunder, til reparasjon og som er kassert. 3.0 Krav til faner Production Man skal kunne søke etter navn, organisasjonsnummer eller merchant ID. Hvis flere kunder på samme navnesøk, vises en liste hvor bruker velger aktuell kunde. Søker man på organisasjonsnummer eller merchant-id, kommer man direkte til riktig kunde. Disse numrene må være komplette for å kunne søke. Ellers vises feilmelding. Navn kan altså være ukomplett. For eksempel hvis man søker på Expert, kommer alle Expert-butikkene PayEx har i sitt kunderegister. Man kan endre informasjonen til kunden, det være seg navn, adresse, diverse ID og telefonnummer. Dette kan hvilken som helst bruker gjøre uten admin-rettigheter. Videre vises en oversikt over antall terminaler og kabler/psu som kunde har fått tilsendt i sitt kundeforhold med PayEx. Her vises også sporingsnummer, dato produkt ble sendt kunde, dato produkt ble mottatt fra kunde (evt), og dato produktet ble registrert som defekt/kassert (evt). Man kan sende ny terminal eller tilhørende produkter ved hjelp av Send new -knappen. Man kan også registrere en terminal som defekt. Når man sender ny terminal eller tilhørende produkt, vil det også automatisk bli fakturert kunde. Dette gjøres ved å eksportere nødvendig kundedata til et excel-ark, som i sin tur leses Page 43 of 106

44 av et faktureringsprogram PayEx besitter. PayEx gir oss informasjon om hvordan dette excelarket må formateres slik at det leses korrekt av faktureringsprogrammet. Defect Her vises oversikt over alle terminaler som er registrert som defekt. Discarded Terminal sendes til Danmark, PayEx får penger for den, terminal kastes ut av logistikkdatabasen vår. PayEx vil ha oversikt over alle kasserte terminaler som er ute av systemet. Disse legger vi altså i en discarded-tabell i databasen vår. Page 44 of 106

45 1.5 Vedlegg 5: Strukturkart Login Country selection Index Production In Production Defect Info Admin Terminal search Production Search Customer info Edit/Save Register defect Send new Page 45 of 106

46 In Production New Terminal Service Terminal Add/Save Add/Save Defect Add terminal Send terminal Recieved Terminal Send RMA Reset Send Package Search Page 46 of 106

47 Admin Terminals Customers Import from excel Customers Postal Places Import Import Import Admin Users Show all Add user Edit user Generate pass Add Edit Delete Edit Usrname Edit Edit Privilege Page 47 of 106

48 1.6 Vedlegg 6 Balsamiq Mockups prototyper Innlogingsside Page 48 of 106

49 Country selection Page 49 of 106

50 Infoside Page 50 of 106

51 Production storage / Produksjonslager (terminaler hos kunder) Page 51 of 106

52 Page 52 of 106

53 Page 53 of 106

54 Page 54 of 106

55 Page 55 of 106

56 Test lager Page 56 of 106

57 Page 57 of 106

58 In production storage (terminaler på lageret) Page 58 of 106

59 Defect (Terminaler som må sendes til reparasjon) Page 59 of 106

60 Page 60 of 106

61 13.14 Vedlegg 7 Use case diagram Page 61 of 106

62 13.15 Vedlegg 8 Beskrivelse av Use case Innlogging Aktør: Bruker / admin Mål: Tilgangen til webapplikasjonen. Oppsummering: For å få tilgang til webapplikasjonen må korrekt passord og brukernavn skrives inn. Pre-betingelser: Brukeren/admin er ikke autentisert. Trigger: Brukeren/admin prøver å få tilgang til webapplikasjonen. Forløp: 1. Systemet krever at brukeren/admin logger seg inn. 2. Brukeren/admin skriver inn brukernavn og passord. 3. Systemet sjekker om brukernavn og passord stemmer. 4. Forsiden av programmet blir presentert for brukeren/admin. Variasjoner: Ved feil oppgitt brukernavn og eller passord. 5. Brukerinformasjon stemmer ikke. Start innlogging fra punkt 1. Ved å la felt(ene) være tomme og trykke på logg inn 6. Brukerinformasjon mangles. Start innlogging fra punkt 1. Post betingelser: Brukeren/admin er autentisert. Page 62 of 106

63 Velge lager Aktør: bruker/admin Mål: Målet er å komme til riktig lager i systemet. Oppsummering: For å få tilgang til riktig lager må det trykkes på det riktige flagget. Pre-betingelser: Brukeren er logget inn. Trigger: Brukeren prøver å få tilgang til lager. Forløp: 1. Systemet krever at brukeren trykker på et flagg for å gå videre. 2. Brukeren trykker på valgt flagg. 3. Systemet sjekker hvilket flagg er valgt. 4. Systemet går til riktig lager i henhold til flaggvalget. 5. Info fanen av programmet blir presentert for brukeren. Post betingelser: Bruker har valgt lager. Søk Aktør: bruker/admin Mål: Hurtigsøk etter PedID Oppsummering: Felt for å kunne søke etter PedID fra hvor som helst på siden ved behov. Pre-betingelser: PedID eksisterer. Trigger: Må få vite info om den bestemte terminalen. Forløp: 1. Systemet krever at brukeren skriver inn PedID. 2. Brukeren skriver inn PedID. 3. Systemet sjekker om PedID eksisterer. 4. Informasjon om terminalen blir presentert. Variasjoner: Ved feil oppgitt PedID. 4. Brukerinformasjon stemmer ikke. Start fra punkt 1. Post betingelser: Informasjon om terminalen presenteres. Page 63 of 106

64 Production Forandre info om kunden Aktør: Bruker/admin Mål: Korrigere kundeinformasjon på systemet. Oppsummering: Brukeren/admin trenger å forandre kundeinformasjon Pre-betingelser: Kunden er registrert fra før av. Trigger: Brukeren/admin trenger å forandre informasjon om eksisterende kunde. Forløp: 1. Systemet ber brukeren/admin å søke etter kunde ved å skrive inn navn, organisasjonsnummer eller merchant ID. 2. Brukeren/admin skriver inn det nødvendige av informasjon. 3. Systemet sjekker om gitt navn, organisasjons nummer eller merchant ID finnes i databasen. 4. Kundeinformasjon blir presentert for brukeren/admin. 5. Brukeren/admin trykker på knappen change customer information 6. Brukeren forandrer informasjon. 7. Brukeren/admin trykker på Save knappen. 8. Systemet lagrer forandringer. Variasjoner: Ved feil oppgitt kunde navn, organisasjons nummer eller merchant ID. 4. Kundeinformasjon finnes ikke. Start fra punkt 1 i Production fanen. Post betingelser: Kunde informasjon er forandret og lagret. Page 64 of 106

65 Søk etter kunde Aktør: bruker/admin Mål: Søk etter kunde Oppsummering: Felt for å kunne søke etter navn, organisasjonsnummer eller merchant ID. Pre-betingelser: Kunde eksisterer. Trigger: Må få vite info om den bestemte kunden. Forløp: 1. Systemet krever at brukeren skriver inn navn, organisasjonsnummer eller merchant ID. 2. Brukeren skriver inn navn, organisasjonsnummer eller merchant ID. 3. Systemet sjekker om navn, organisasjonsnummer eller merchant ID eksisterer. 4. Informasjon om kunde blir presentert. Variasjoner: Ved feil oppgitt navn, organisasjonsnummer eller merchant ID. 4. Gitt informasjon finnes ikke. Start fra punkt 1. Post betingelser: Informasjon om terminalen presenteres. Page 65 of 106

66 Legg til defekt terminal Aktør: Bruker/Admin Mål: Legg til defekt terminal. Oppsummering: For å registrere terminal som er sendt inn fra kunde som defekt. Pre-betingelser: Terminalen er sendt inn av kunde men ikke registrert som defekt i databasen. Trigger: Ved funnet feil prøver brukeren/admin å legge til terminal som defekt. Forløp: 1. Systemet ber om å lese inn PedID. 2. PedID leses inn. 3. Type feil velges ut i fra ErrorID listen. 4. Dato velges. 5. brukeren/admin trykker Register knapp 6. Defekt terminal blir registrert i databasen. Variasjoner: Ved feil meldingen 6.Serveren er nede. Start fra punkt 1. Post betingelser: Terminalen er lagt til som defekt i databasen. Page 66 of 106

67 Send ny Aktør: bruker/admin Mål: Sende ut ny terminal til bestemt kunde. Oppsummering: En ny terminal med tilbehør dersom det er nødvendig sendes til en bestemt kunde. Pre-betingelser: Kunde ønsker tilsendt terminal og eventuelle tilbehør. Trigger: Oppfylle kundens ønske. Forløp: 1. Systemet ber brukeren om å legge inn Ped ID og/eller velge tilbehør samt sporingsnummer. 2. Brukeren utfører systemets krav. 3. Brukeren trykker på Invoice og send knappen. 4. Systemet registrer bestillingen. 5. Systemet sender e-post til support for fakturering. 6. Systemet gir brukeren tilbakemelding om bestilling. 7. Systemet åpner nytt vindu med dokument klargjort for utskrift. Variasjoner: Ved feilmelding 6. Server er nede. Start fra punkt 1. Post betingelser: Bestillingen er registrert, fakturert og sendt. Page 67 of 106

68 Legg til ny terminal. Aktør: bruker/admin Mål: Registrere ny terminal i systemet. Oppsummering: En ny og ubrukt terminal legges inn i systemet. Pre-betingelser: Terminal er ikke tidligere registrert i systemet. Trigger: Ny terminal må registreres inn. Forløp: 1. Systemet ber brukeren om å legge inn Ped ID. 2. Brukeren leser inn dette. 3. Systemet ber bruker å velge modell type. 4. Bruker velger type. 5. Systemet ber om produksjonsdato. 6. Bruker velger dato. 7. Bruker trykker Add knapp for å fullføre registreringen. 8. Systemet utfører registrering. 9. Systemet gir brukeren tilbakemelding. Variasjoner: Ved feilmelding 8. Server er nede. Start fra punkt 1. Post betingelser: Registrering fullført av ny terminal. Page 68 of 106

69 Legg til service terminal. Aktør: bruker/admin Mål: Registrere service terminal i systemet. Oppsummering: En service terminal legges inn i systemet. Pre-betingelser: Service terminal er ikke tidligere registrert i systemet. Trigger: Service terminal må registreres inn. Forløp: 1. Systemet ber brukeren om å legge inn Ped ID. 2. Brukeren leser inn dette. 3. Systemet ber bruker å velge modell type. 4. Bruker velger type. 5. Systemet ber om produksjonsdato. 6. Bruker velger dato. 7. Bruker trykker Add knapp for å fullføre registreringen. 8. Systemet utfører registrering. 9. Systemet gir brukeren tilbakemelding. Variasjoner: Ved feilmelding 8. Server er nede. Start fra punkt 1. Post betingelser: Registrering fullført av service terminal. Page 69 of 106

70 Legg til defekt terminal Aktør: Bruker/Admin Mål: Legg til defekt terminal. Oppsummering: For å registrere terminal som er sendt inn å ligger på lager. Pre-betingelser: Terminalen er sendt inn men ikke registrert som defekt i databasen. Trigger: Ved funnet feil prøver brukeren/admin å legge til terminal som defekt. Forløp: 1. Systemet ber om å lese inn PedID. 2. PedID leses inn. 3. Type feil velges ut i fra ErrorID listen. 4. Dato velges. 5. brukeren/admin trykker Add knapp 6. Defekt terminal blir registrert i databasen. 7. Systemet bekrefter registrering. Variasjoner: Ved feil meldingen 6.Serveren er nede. Start fra punkt 1. Post betingelser: Terminalen er lagt til som defekt i databasen. Page 70 of 106

71 Søk for å få tildelt RMA Aktør: Bruker/Admin Mål: Søke om RMA. Oppsummering: For å få sendt inn defekte terminal til reparasjon i Danmark. Hver pakke må ha en unik RMA. Pre-betingelser: Ferdig liste med defekte terminaler er lest inn. Trigger: Defekte terminaler må repareres. Forløp: 1. Systemet ber om å lese inn PedID. 2. PedID blir lagt i liste. 3. Brukeren trykker på Send RMA request knappen. 4. Systemet lagrer liste med tildelt nummer. 5. Bruker noterer seg nummeret på listen. 6. Systemet sender epost til Danmark om å få tilsendt RMA nummer. 7. Systemet gir brukeren tilbakemelding. Variasjoner: Ved feil meldingen 2.Terminal er allerede lagt til. Legg til annen. 3.Server er nede. Start fra punkt 2. Post betingelser: Krav for å få tilsendt RMA er oppfylt. Page 71 of 106

72 Send pakke Aktør: bruker/admin Mål: Sende ut pakken med terminaler og liste etter mottatt RMA. Oppsummering: Liste med de defekte terminaler som ble tildelt RMA nummeret pakkes ned sammen med terminalene og sendes. Pre-betingelser: Terminalene er registrert på listen og RMA nummeret er tildelt. Trigger: Pakken settes klar til henting av posten. Forløp: 1. Bruker trykker på Send package knappen. 2. Systemet viser lagrete lister av defekte terminaler. 3. Brukeren velger rett liste. 4. Brukeren skriver inn mottatt RMA nummer. 5. Brukeren trykker Send knappen for å fullføre registreringen. 6. Systemet setter sammen listen nummeret og RMA nummeret som lagres i databasen. 7. Systemet gir tilbakemelding til brukeren. 8. Brukeren trykker på Print knappen for å skrive ut et dokument som skal legges til i pakken med de tilordnede terminaler. Variasjoner: Ved feilmelding. 7. Feil med serveren. Start fra punkt 3. Post betingelser: Registrert som sendt i systemet. Page 72 of 106

73 Mottatt terminal Aktør: bruker/admin Mål: Registrer mottatte terminaler fra reparasjon. Oppsummering: Reparerte terminaler tilordenes nye PedID er. Pre-betingelser: Terminalene er reparerte. Trigger: Terminaler er returnert fra reparasjon. Forløp: 1. Systemet spør etter RMA nummeret. 2. Bruker fyller inn RMA nummer. 3. Bruker trykker Search knappen. 4. Systemet viser liste med PedID er. 5. Bruker velger gammelt PedID 6. Bruker skriver inn ny PedID 7. Bruker trykker Save knappen 8. Systemet utfører endringene 9. Systemet lagrer endringene 10. Systemet gir tilbakemelding Variasjoner: Ved feilmelding. 3. RMA nummer finnes ikke eller er tomt. Start fra punkt Server er nede. Start fra punkt 2. Post betingelser: Registrert som mottatt fra reparasjon. Page 73 of 106

74 Legge til bruker Aktør: admin Mål: Legge til brukere med brukernavn, passord og tilordnede rettigheter. Oppsummering: For å gi bruker tilgang til webapplikasjonen Pre-betingelser: Brukeren er ikke registrert Trigger: Mangel på brukere. Forløp: 1. Systemet ber om å skrive inn brukernavn. 2. Admin skriver inn brukernavn. 3. Systemet ber om å generere passord. 4. Admin trykker på Generate knappen. 5. Systemet genererer passord. 6. Systemet ber om epost adresse. 7. Admin oppgir epost adresse 8. Systemet ber om å velge privilegier. 9. Admin krysser av valg. 10. Admin trykker på Add knapp. 11. Systemet lagrer gitt informasjon. 12. Systemet sender epost til ny bruker. 13. Systemet gir tilbakemelding. Variasjoner: Ved feilmelding. 10.Alle felter er ikke fylt inn eller utfylt feil. Start innlogging fra punkt Server er nede. Start fra punkt 1. Post betingelser: Brukeren er registrert. Page 74 of 106

75 Slette bruker Aktør: admin Mål: Slette registrert bruker. Oppsummering: For å nekte bruker tilgang til webapplikasjonen Pre-betingelser: Brukeren er registrert Trigger: Ansatt sluttet. Forløp: 1. Systemet ber om å skrive inn brukernavn eller epost. 2. Admin skriver inn brukernavn eller epost. 3. Systemet ber om å trykke Delete knappen. 4. Admin trykker på Delete knappen. 5. Systemet sjekker om bruker finnes. 6. Systemet generer tilbakemelding om bruker skal slettes. 7. Admin trykker Yes knappen. 8. Systemet utfører sletting. 9. Systemet gir tilbakemelding. Variasjoner: Ved feilmelding. 6.Felt utfylt feil. Start innlogging fra punkt 2. 6.Server er nede. Start fra punkt 2. Post betingelser: Brukeren er slettet. Page 75 of 106

76 Redigere bruker Aktør: admin Mål: Redigere informasjon om brukeren. Oppsummering: For å forandre informasjon eller privileger. Pre-betingelser: Brukeren er registrert. Trigger: Feil informasjon på brukere. Forløp: 1. Systemet ber om å skrive inn brukernavn eller epost. 2. Admin skriver inn brukernavn eller epost. 3. Systemet ber om å trykke Edit knappen. 4. Admin trykker på Edit knappen. 5. Systemet sjekker om bruker finnes. 6. Systemet presenterer oppgitt informasjon. 7. Admin trykker Edit knappen på ønsket felt. 8. Admin redigerer valgt felt. 9. Admin trykker Save knappen. 10. Systemet sjekker at gitt info er korrekt. 11. Systemet utfører og lagrer endringen. 12. Systemet gir tilbakemelding. Variasjoner: Ved feilmelding. 10.Felt utfylt feil. Start fra punkt Server er nede. Start fra punkt 2. Post betingelser: Bruker data er endret. Page 76 of 106

77 Import av data fra Excel ark Aktør: admin Mål: Importere data fra Excel ark. Oppsummering: Importere kunde informasjon, terminal og postnummer. Pre-betingelser: Informasjon på ark må finnes. Trigger: Mangel på informasjon. Forløp: 1. Systemet ber om å endre navn på fil som skal importeres. 2. Admin endrer navn på filen som systemet krever. 3. Systemet ber om opplasting av fil. 4. Admin finner valgt fil. 5. Systemet ber om at ALLE felt fylles korrekt. 6. Admin fyller ALLE felt korrekt. 7. Admin trykker Import knappen. 8. Systemet sjekker felt er korrekt utfylt. 9. Systemet lagrer filen på databasen. 10. Systemet gir tilbakemelding. Variasjoner: Ved feilmelding. 7.Felt ikke utfylt. Start fra punkt 6. 6.Server er nede. Start fra punkt 3. Post betingelser: Databasen oppdatert med importert data. Page 77 of 106

78 13.16 Vedlegg 9 Skjermbilder av applikasjonen Innlogging: Lagervalg / Country selection Page 78 of 106

79 Kortfattet info side etter lagervalg Production lager (Terminaler hos kunder) Page 79 of 106

80 Resultat etter kunde søk ved navn Page 80 of 106

81 Resultat etter unikt søk Registrering av defekte terminaler hos kunde Page 81 of 106

82 Registrering av terminal som er uavhengig av kundetilhørighet Page 82 of 106

83 Mottagelse av reparerte terminaler Page 83 of 106

84 Utsendelse av defekte terminaler til reparasjon Pakkseddel til en RMA liste som skal sendes Page 84 of 106

85 Internt lager Legge til nye terminaler på lager Page 85 of 106

86 Legge til nye brukere (Admin funksjonalitet) Liste over alle brukere og deres rettigheter: Page 86 of 106

87 Import av kundelister (Admin funksjonalitet) Import av postnummer liste (Admin funksjonalitet) Page 87 of 106

88 Import av terminal liste (Admin Funksjonalitet) Page 88 of 106

89 13.17 Vedlegg 10 Sekvensdiagram System Login Country Selection Page 89 of 106

90 Terminal Search: Production: Search Customer Edit Customer Information Page 90 of 106

91 Send new terminal Page 91 of 106

92 Register defect Page 92 of 106

93 In production Add new terminal Add service terminal Page 93 of 106

94 Defect Register defect Page 94 of 106

95 Register recieved Page 95 of 106

96 Apply for RMA Send Package Page 96 of 106

97 Admin Add user Page 97 of 106

98 Delete user Edit user Page 98 of 106

99 Import av excel- filer Page 99 of 106

100 13.18 Vedlegg 11: Klassediagram DAL (Data Access Layer): Page 100 of 106

101 BLL (Business Logic Layer): Page 101 of 106

102 13.19 Vedlegg 12: ER diagram Page 102 of 106