Price Optimizer. Et prisreguleringsværktøj

Transkript

1 Price Optimizer Et prisreguleringsværktøj P3-Projekt Gruppe DS312E14 Software Institut for Datalogi Cassiopeia Aalborg Universitet Den 19. december 2014

2

3 Institut for Datalogi Cassiopeia Software Selma Lagerlöfsvej Aalborg Ø. Tema: Udvikling af applikationer fra brugere til data, algoritmer og test og tilbage igen. Titel: Price Optimizer - Et prisreguleringsværktøj Projektperiode: P3, Efterårssemesteret 2014 Projektgruppe: DS312E14 Deltagere: Alex Grøndahl Frie Morten Brodersen Jensen Bjarke Nedergaard Jepsen Jonathan Toftegaard Hansen Bjørn Espen Opstad Thomas Holm Thomsen Vejleder: Rikke Hagensby Jensen Synopsis: I projektet er der skabt et tæt samarbejde med en klient, som efterspurgte et effektivt prisreguleringsværktøj til anvendelse i en stor, international webshop. Der blev anvendt en iterativ udviklingsproces drevet af prototyping og løbende evaluering. Rapporten er indledt med en grundlæggende problemanalyse efterfulgt af et analyse- og designdokument i deres endelige form. Derefter følger implementering af systemet, beskrivelse af iterationerne samt en afrunding. Det udviklede system, Price Optimizer, blev implementeret som en platformsuafhængig webapplikation opbygget omkring ASP.NET MVC-frameworket. Systemet blev flere gange testet ved hjælp af usability-test. Oplagstal: 8 Sidetal: 150 Bilagsantal: 44 sider Afsluttet den Offentliggørelse af rapporten (med kildeangivelse) må kun ske efter aftale med forfatterne.

4 Jonathan Hansen Bjørn Opstad Bjarke Jepsen Alex Frie Thomas Thomsen Morten Jensen

5 Forord Denne rapport er udarbejdet af gruppe ds312e14 på 3. semester for Software-uddannelsen, i forbindelse med efterårssemesteret Rapporten blev afleveret d. 19/ Rapporten er skrevet på baggrund af semesterprojektet, som omhandler pristyring og datavisualisering. Formålet med rapporten er, at præsentere tanker, overvejelser, refleksioner, dokumentation samt resultater i forbindelse med semesterprojektet. Projektet på 3. semester tager udgangspunkt i et reelt problem, hvor brugerne af et ITsystem skal inddrages i udviklingsprocessen. Således er der fundet frem til en informant, der ejer og driver en webshop. Læsevejledning Rapporten er opdelt i 15 kapitler. Projektets arbejde baserer sig på og anvender metoder fra bogen Objektorienteret Analyse & Design (OOA&D) [1], med fokus på den iterative udviklingsmodel. Rapporten starter ud med en problemanalysedel, hvor problemet defineres og sættes i kontekst. Efterfølgende er der et analysedokument over den færdige løsning. Selvom der er arbejdet iterativt vil der her blive beskrevet den færdige analyse og struktur. Herefter vil designdokumentet udarbejdes. Dette er igen for den endelige løsning, hvor det beskrives hvordan arkitekturen og brugergrænsefladen er designet. Efter dette følger implementeringen af designet. De iterative faser af projektet bliver beskrevet i slutningen af rapporten. Under hver iteration beskrives valgte og fravalgte elementer fra implementeringen. Dette gøres for at afrapportere de valg, som projektgruppen har stået over for i hver iteration, samt at give læseren et overblik over, hvad der er blevet arbejdet på. Endvidere beskrives ændringer i problemanalysedelen, arkitektur og design. Til sidst i hver iteration vil softwareløsningen blive testet, og resultaterne af testen vil blive evalueret. Begreber skrives med kursiv, første gang de optræder i rapporten, da der flere gange optræder begreber, som muligvis er ukendte for læseren. Rapporten benytter Vancouver-reference-modellen til angivelse af kilder. Dette vil sige at en kilde angives, efter hvornår den optræder i rapporten og ikke i alfabetisk rækkefølge. Information om kilderne forefindes under litteraturlisten til sidst i rapporten. Information omfatter navn på forfatter, titel, udgivelsesår, dato, samt ISBN-nummer for bøger. Ved online indhold er der angivet udgiver, titel, dato samt en note over hvornår siden er tilgået. Der vil i implementeringsdelen indgå flere kodeeksempler. For at vise hvilken kontekst koden er taget ud fra, vil der i eksemplet blive vist hvilket namespace, klasse og metode der er tale om. Hvis der er kode som er undladt i eksemplet, vil dette blive angivet således [...]. Klassenavne, metoder, instansmedlemmer, lokale variabler, egenskaber og C#-keywords vil alle blive angivet således KlasseNavn, MetodeNavn(), instansmedlemsnavn, variabelnavn, EgenskabsNavn. C#-keywords kan for eksempel være if, true eller bool.

6 Indholdsfortegnelse Indholdsfortegnelse Kapitel 1 Indledning 1 I Problemanalyse 2 Kapitel 2 Motiverende afsnit Indledende interview Problemkontekst Kapitel 3 Problemdefinition Problemformulering Systemdefinition PACT-analyse Kapitel 4 Udviklingsmetode og strategi Strategi Opsummering II Analysedokument 16 Kapitel 5 Analyse af problemområdet Klasser og hændelser Struktur Adfærd Opsummering Kapitel 6 Analyse af anvendelsesområdet Brug Funktioner Opsummering III Designdokument 38 Kapitel 7 Arkitektur Kriterier

7 7.2 Komponentarkitektur Kapitel 8 Grænseflader Brugergrænseflade Systemgrænseflade Opsummering IV Implementering 63 Kapitel 9 Teknologier Anvendte teknologier Database Opsummering Kapitel 10 Udvalgte elementer af implementeringen Implementering af Database Hent data Visning og manipulation af data Gem data Opsummering V Iterationer 98 Kapitel iteration Dataindsamlingsmetoder Indledende interview Prototype 1 - Skitser Evaluering af prototypen Interview med klienten Evaluering af 1. iteration Kapitel iteration Valg & fravalg Problemområdet Test af Prototype 2 - Magentoforbindelse Evaluering af 2. iteration Kapitel iteration Valg & fravalg Problemområdet Test af prototype 3 - Price Optimizer (Alpha) Evaluering af 3. iteration Kapitel iteration Valg & fravalg Test af prototype 4 - Price Optimizer (Beta) Evaluering af 4. iteration

8 VI Rapportafslutning 143 Kapitel 15 Afrunding Diskussion Konklusion Perspektivering VIIAppendiks 151 Litteratur 152 Figurer 155 Tabeller 157 Kodeeksempler 158 Bilag A Interviews 159 A.1 Skype-interview med Tonny Andersen, Sinful - Referat A.2 Interviewspørgsmål til Tonny Andersen d A.3 Interview med Tonny Andersen, Sinful - d A.4 Afsluttende vurdering af Prototype 4 - Price Optimizer (Beta) Bilag B Test 171 B.1 Test af Prototype 2 - Magentoforbindelse B.2 Test af Prototype 3 - Price Optimizer (Alpha) B.3 Funktionel test af Prototype 4 - Price Optimizer (Beta) Bilag C Skitser 181 Bilag D Figurer 185 Bilag E Klassediagram 194 E.1 Problemområdet

9 Indledning 1 I de seneste år har der været en stigende interesse for køb af varer via webshops. I 2013 udgav Foreningen for Dansk Internet Handel (FDIH) en årsrapport, hvor det blev oplyst, at 17% af en dansk husstands forbrug gik til online handel [2]. Den største faktor der fik kunderne til at handle over internettet var, at 30% oplevede at webshoppen havde produktet til den billigste pris. Det stigende antal kunder hos webshops giver flere køb og derved mere data. Dette data kan for eksempel være data vedrørende salg, hvor det kan ses, hvilke produkter der sælges flest af, hvilket er vigtig information til prisoptimering. Den stigende datamængde kan gøre det uoverskueligt at udføre prisændringer, da der i nogle webshops findes flere tusinde produkter. Hvis webshop-ejeren mister overblikket over sine produkter kan det blive besværligt for vedkommende at holde sin webshop konkurrencedygtig. Med udgangspunkt i ovenstående problemstilling, undersøges det i denne rapport, hvordan der kan udvikles et softwaresystem til at gøre prisregulering af produkter i en webshop til en mere overskuelig opgave. Derfor er der, i denne rapport, arbejdet tæt sammen med en klient, som ønskede et værktøj til at prisregulere og -optimere sine produkter. Klienten driver en stor international webshop, hvorfra der sælges produkter. Prisreguleringsopgaven kompliceres dog af mangel af brugervenlig datavisulisering, hvor klienten føler at det både er tidskrævende og besværligt at holde styr på webshoppens produkter. Derfor ønskes det at have lettere adgang til at prisregulere produkter, samtidig med et ønske om, at der udvikles et værktøj, som kan optimere salget af produkter, og skabe et bedre visuelt overblik over webshoppen. 1

10 Del I Problemanalyse 2

11 Motiverende afsnit 2 I forbindelse med projektets opstart blev der afholdt et indledende, ustruktureret Skypeinterview med Tonny Andersen, se bilag A.1. Tonny Andersen er stifter og ejer af firmaet Sinful, der sælger erotiske produkter på internettet. Interviewets formål var, at få belyst problemets overordnede omfang og kontekst, samt at få en forståelse af situationen og klargøre hvorvidt Tonnys problemstilling var et muligt projektemne, for et tredje semesterprojekt på bacheloruddannelsen i Software. De vigtigste dele af interviewet med Tonny Andersen beskrives og uddybes i nedenstående afsnit. 2.1 Indledende interview En af Tonny Andersens opgaver som ejer af Sinful, omhandler prisstyring af produkterne i Sinfuls webshops. Da interviewet blev udført, havde Sinful webshops i fire forskellige lande, henholdsvis Danmark, Norge, Sverige og Finland. Hver af Sinfuls webshops indeholder over 2500 forskellige produkter. Tonny Andersen fortæller, at der i forbindelse med prisstyringen hentes data omkring brugeradfærd på de respektive webshops via Google Analytics. Google Analytics er et webanalyseværktøj, beregnet til at analysere brugeradfærd på hjemmesider. Dette gøres kvantitativt ved at måle trafik på hjemmesider, og ved at udnytte cookies hos de besøgende [3]. Analysen af brugeradfærd omhandler blandt andet hvilke produktsider, der er mest besøgt, samt hvor meget der bliver solgt af de forskellige produkter. Forholdet mellem antallet af besøgende på en produktside og antallet af de besøg der udmunder i et konkret salg, udtrykkes i form af en konverteringsfrekvens [4, p. 139]. Konverteringsfrekvens er et vigtigt redskab i Tonny Andersen arbejde. Konverteringsfrekvensen af et produkt kan give en indikation, om der er noget galt med produktets pris, beskrivelse eller selve webshoppen. Har et produkt en meget lav konverteringsfrekvens, betyder det at mange kunder har været interesseret og klikket ind på produktet uden at købe det. Dette vil derfor give anledning for Tonny til at undersøge produktet nærmere. Udover data fra Google Analytics, anvendes der hovedsageligt data fra Magento [5, p. 3]. Magento er et open-source Content Management System (CMS), som Tonny Andersen bruger til sine webshops. Data fra Magento består af information om produkter såsom navn, pris, tilbudspris og indkøbspris. Forholdet mellem indkøbsprisen og prisen er en faktor, der betegnes som dækningsbidrag [6]. Den simpleste formel for at udregne 3

12 dækningsbidraget er som følgende: P ris = daekningsbidrag (2.1) indkbspris hvilket der er givet et eskempel på i ligning , , 00 = 1.5 (2.2) Der findes en række af parametre, som ikke medtages til at udregne dækningsbidraget. Skulle der gives en helt korrekt faktor kunne der kigges på, hvor meget produktet koster at købe, hvor meget der betales for fragt og hvad der bruges af penge på emballage. Dette blev dog ikke nævnt af Tonny, som værende en afgørende faktor for udregningen af dækningsbidraget. Dækningsbidrag er endnu et vigtigt redskab for Tonny Andersen. 2.2 Problemkontekst I den nuværende arbejdssituation ændrer Tonny Andersen priser manuelt i et Excel-ark. Da Excel-arket er tungt at arbejde med, og prisstyring er en tidskrævende og besværlig proces, udfører Tonny Andersen kun prisændringer én gang i måneden. Hermed nedsættes Sinfuls konkurrenceevne, da hurtige prisændringer ikke er mulige. Dette har især effekt på prisfølsomme produkter, hvilket ifølge Tonny Andersen, er dyre mærkevareprodukter, hvor kunder aktivt søger efter den billigste pris. Her er det vigtigt at kunne ændre prisen på disse produkter efter parametre såsom dækningsbidrag, konverteringsfrekvens samt konkurrenternes priser på samme produkt. Figur 2.1. Adminpanelet i Magento På figur 2.1 og 2.2 ses screenshot af admin-panelet i Magento. Hvis prisen skal prisen på et, eller flere, produkter i Magento, skal produktet findes i listen over alle produkter, hvilket 4

13 ses på det 2.1. Når man har fundet det pågældende produkt, som skal ændres, fremkommer standardprisen i kolonnen ved navn Price - det er ikke muligt at ændre prisen direkte i tabellen. For at ændre prisen klikkes der ind på det enkelte produkt, hvorefter man kommer hen til figur 2.2. Her ses en menu til venstre, med forskellige parametre, hvor der kan ændres for det pågældende produkt. Øverst til venstre, ved 2-tallet, er det muligt at vælge hvilket land, man ønsker at arbejde med. Skal en pris ændres, er det derfor påkrævet først at vælge landet, hvorefter der skal klikkes på pris; 3-tallet. Det er nu muligt at ændre prisen for et enkelt produkt, i et enkelt land. Ønskes det efterfølgende at ændre prisen på et produkt i et andet land, skal det pågældende land vælges, og der kan igen klikkes på pris; ved 3-tallet. Hvis prisen på et andet produkt skal ændres, skal man tilbage til tabellen på 2.1, finde produktet, klikke ind på det enkelte produkt og igennem det hele igen. Der skal derfor rigtigt mange klik til, for at ændre priserne på flere produkter, hvilket bevirker, at overblikket forsvinder hurtigt. Figur 2.2. Adminpanelet i Magento På det første billede, se figur 2.3, ses en række forskellige sider, som Tonny Andersen benytter i sit Excel-ark. Den første er Overview og er en overordnet side i Excel for de forskellige lande i Tonny Andersens webshop. Her har Tonny data, som han ikke mener er relevant for dette projekt. Figur 2.3. Sider i Excel-arket. Den næste side, Indkøbsstyring, er interessant i forhold til dette projekt. Et udsnit af denne side kan ses på figur det skal dog nævnes, at de indtastede tal er fiktive, af 5

14 hensyn til beskyttelse af Tonny Andersens data. Siden her indeholder data som SKU, hvilket står for Stock Keeping Unit. SKU er et internt varenummer, som benyttes af lagerpersonalet til at finde frem til, hvor et produkt befinder sig på lageret. ID stammer fra Magento, og betegner hvilket id produktet har i Magento-shoppen. En række af parametrene er selvsigende, såsom navn, pris, solgte år, indtjening og producent. Synlig betegner, hvorvidt produktet skal være aktivt i webshoppen. QTY betegner antal på lager. Exclude betegner, om Tonny kan købe produktet hos sin forhandler. 0 betyder, at han ikke længere kan få produktet, hvor 1 betyder, at han har mulighed for stadig at indkøbe produktet. DB beskriver dækningsbidraget for det givne produkt. Der er blot givet en kort introduktion til nogle af kolonner, for at give en forståelse for, hvad de betyder. Det vigtigste på dette tidspunkt er at observere figur 2.4. Det ses at der findes en række kolonner, der kan arbejdes på. Der hvor arbejdet for Tonny Andersen bliver uoverskueligt, er de mange rækker, der findes på denne Excel-side. Denne side indeholder nemlig omkring 4500 rækker af produkter, som hver har unik data. Den næste side fra figur 2.3 er Prisstyring. Det er her Tonny ændrer priser på produkterne, for alle sine webshops. Siden indeholder nogle af de samme kolonner, som fra Indkøbsstyring - der er dog data for hvert produkt fra de forskellige webshops der findes. Dette betyder, at der er omkring 90 kolonner, der arbejdes på. Også på denne side er der op mod 4500 rækker. Der er ikke indsat et billede fra Prisstyring, da det ligner Indkøbsstyring -siden. Excel-arkets kompleksitet og tunge arbejdsprocess er et problem. Hvis dette forbedres, lettes arbejdsbyrden betydeligt for Sinful, og dermed frigøres der ressourcer til yderligere optimering af priser. Ifølge Tonny Andersen, findes der endnu ikke konkurrerende firmaer indenfor branchen af erotiske produkter, der udnytter mulighederne indenfor prisstyring. Dermed har Sinful mulighed for at være pioneer indenfor branchen, hvorfor en løsning til prisstyring- og regulering vil have stort potentiale og en positiv effekt på arbejdsgangen, samt omsætningen. 6

15 Figur 2.4. Indkøbsstyring -siden i Excel-arket. Billedet er drejet 90 7

16 Problemdefinition 3 I afsnit 2.1 blev det indledende interview med projektets klient Tonny Andersen beskrevet. Ud fra dette blev der opnået en forståelse af situationen, samt problemets omfang og kontekst. Der vil i dette kapitel fokuseres på at konkretisere og definere problemet, i form af en problemformulering, systemdefinition samt en PACT-analyse. 3.1 Problemformulering Der undersøges i dette projekt, om et system kan udvikles til styring af priser og visualisering af produktdata fra Sinfuls webshops, samt overvågning og visualisering af konkurrentpriser. Ifølge Tonny Andersen, ejer af Sinful, er markedet indenfor online markedsføring og salg konkurrencepræget, og maksimal udnyttelse af tilgængelige ressourcer er derfor en nødvendighed. Tonny Andersen ønsker et værktøj til at assistere med prisstyring på effektiv vis. Ud fra det indledende interview blev det klarlagt at effektiv prisstyring er et komplekst område. Med baggrund i dette kan Tonny Andersens problem formuleres således: Arbejdet med udnyttelse af data fra Magento og Google Analytics besværliggøres af manglen på eksisterende værktøjer, til at visualisere og administrere data. Indenfor prisstyring skal der tages højde for data, såsom dækningsbidrag, konverteringsfrekvens og prishistorik. Dette gøres for at øge indtjeningen samt optimere arbejdsgangen. Tonny Andersen mangler et brugervenligt værktøj der kan assistere ham i dette, der er tilpasset hans situation og behov. Hvordan udvikles et system, hvori der kan udføres prisændringer, som er effektivt at bruge, og vil være en forbedring i forhold til Tonny Andersens nuværende løsning? 3.2 Systemdefinition Med problemformuleringen var der fokus på at konkretisere problemets område og omfang, kort og præcist, i en beskrivende tekst. Som en videreudvikling af dette vil der udformes en systemdefinition, der udtrykker problemet fra et systemudviklingsperspektiv. Det fremtidige system defineres på følgende vis: Et IT-system, der bruges til at effektivisere og overskueliggøre administreringen, 8

17 reguleringen og optimeringen af priser på produkter i Sinfuls webshops i nordiske lande. Systemet skal primært fokusere på gennemskuelige og effektive metoder til prisændringer af produkter. Derudover skal systemet analysere aspekter indenfor prissætning og prishistorik med det formål at visualisere statistikker. Systemet skal udvikles som en webapplikation således, at der opnås platformsuafhængighed. Med systemet søges der at tilbyde et værktøj, der vil lette arbejdsbyrden ved prisoptimering betydeligt hos Sinfuls medarbejdere og dermed frigive ressourcer. Ydermere skal systemet give mulighed for en effektiv prisoptimeringsprocess, hvilket kan øge virksomhedens konkurrenceevne og derved fortjeneste. Systemdefinitionen er udfærdiget ud fra BATOFF-kriteriet, som består af seks elementer [1]. Elementerne af BATOFF-kriteriet, samt hvilke dele af systemdefinitionen der repræsenterer dem, er anvist nedenfor: Betingelser: Udvikles i tæt samarbejde med Sinful med fokus på brugbarhed og effektivitet. Anvendelsesområde: Sinfuls organisation. Teknologi: Webapplikation med platformsuafhængighed. Objekter: Produkter, produktdata og prishistorik. Funktioner: Værktøj til brugbar og effektiv prisregulering og -optimering. Filosofi: Værktøj til effektivisering af arbejdsprocessen omkring prisstyring. 3.3 PACT-analyse Efter at have formuleret problemet i en beskrivende tekst i afsnit 3.1, samt udfærdigelsen af en systemdefinition i afsnit 3.2, betragtes systemets omgivelser i form af en PACTanalyse. En PACT-analyse ser på mennesker der udfører aktiviteter i en kontekst ved hjælp af teknologi. Navnet PACT er et akronym for People, Activities, Context og Technology. PACT-analysen er baseret på elementer fra Designing Interactive Systems (DIS) [7]. PACT-analysen udføres for at forstå situationen omkring brugen af systemet, samt eventuelle elementer der skal tages hensyn til [7, p. 26]. People Personerne der kommer til at bruge systemet, er velintegreret i brugen af IT-systemer, og bruger i dagligdagen Magento, Google Analytics samt Excel til prisstyring på webshoppen. Personerne er sandsynligvis dansktalende, men da det er en international webshop kan der være brugere, som ikke har dansk som modersmål. Det antages at personerne, der kommer til at bruge systemet, har en travl arbejdsdag, hvorfor systemet skal udvikles med henblik på effektivitet. Dette vedrører både responstiden i systemet samt i brugergrænsefladen. 9

18 Activities Aktiviteten at optimere priserne i webshoppen udføres på nuværende tidspunkt kun én gang om måneden, se afsnit 2.1. Dette er grundet en kompliceret og tidskrævende arbejdsgang med det nuværende system. Der forelægger et ønske fra brugerne om at kunne gøre det til en af de daglige arbejdsopgaver, så priserne på produkterne kan optimeres i forhold til omsætning. Aktiviteter i forbindelse med prisstyring er: Få overblik over produkter. Finde produkter der skal have ændret prisen ved hjælp af filtre og sortering. Se konverteringsfrekvens og dækningsbidrag for de enkelte produkter. Ændre prisen på et produkt. Context Hovedsageligt sidder brugerne med systemet i et kontormiljø. Således er det muligt at systemet kan kræve brugerens fulde opmærksomhed. Det vil være en fordel hvis systemet, vil kunne bruges udenfor de faste rammer på kontoret, da Tonny Andersen gerne vil kunne anvende systemet ude hos forhandlere og producenter. Det er dog et krav at der er internetadgang for at systemet kan tilgå og ændre data, da systemet skal udvikles som en webapplikation, jævnfør systemdefinitionen 3.2. Da brugerne sidder i et kontormiljø vil det ikke være optimalt at systemet tilbyder audiel feedback til at signalere ændringer til brugeren. Technology Det er valgt at udvikle en webapplikation, da brugerne bruger forskellige operativsystemer. I det nuværende system benytter brugerne mus og tastatur til at prisregulere, hvorfor elementer som stemmestyring og kamerainteraktion ikke overvejes i dette projekt. Sinful benytter skærme større end 13 tommer i full-hd opløsning, hvilket systemet skal tilpasses efter. Da Sinful både bruger Google Analytics og Magento, skal systemet kunne udtrække data fra begge. 10

19 Udviklingsmetode og strategi 4 I denne del af rapporten, vil strukturen af rapporten blive afklaret. Ydermere beskrives det hvilken udviklingsmetode, der er anvendt til løsningen af problemstillingerne. Under projektet er der skabt et tæt samarbejde med firmaet Sinful. Der søges en forståelse af Sinfuls problemstillinger, en analyse af disse, samt udvikling af et fuldt funktionelt system til at afhjælpe problemstillingerne. Udviklingsproces - den iterative metode Gennem projektet har det været nødvendigt at planlægge og strukturere opgaver, for at fuldføre projektet. For at give et overblik over, hvor lang tid der er brugt på hver iteration, er figur 4.1 indsat. Tidsplanen er blevet revideret få gange i projektet, og figuren viser derfor det eksakte tidsrum for iterationerne. Figur 4.1. Kalender over tid benyttet til hver iteration. Inden projektets start blev der taget kontakt til en reel klient. Det er valgt at benytte den iterative udviklingsmetode. Klienten kan hermed evaluere systemet flere gange, og komme med forslag og feedback. Under udviklingsprocessen tages der løbende kontakt til klienten, og vedkommende får stor indflydelse på, hvordan det endelige system kommer til at se ud. I den iterative udviklingsmetode arbejdes der igennem hver iteration med at at skabe en bedre forståelse af problemstillinger. Ved hver iteration kommer man tættere på kerneproblemet, hvilket gør, at man flere gange kan ændre i systemet, for til sidst at få et optimalt system. Metoden bygger på et koncept kaldet prototyping, hvilket skal være med til at skabe en bedre forståelse for kerneproblemet. Prototyping går ud på, at 11

20 man ved hver iteration har lavet en grafisk brugergrænsefladen, som brugeren kan se. Dette kan enten være ved hjælp af skitser, eller ved at lave funktionsdygtige systemer. Desuden revideres alle dele af analysen gennem hver iteration. Nedenfor beskrives i tabel 4.1 hvad det var forventet at nå, samt hvad der reelt blev nået i de fire iterationer. Derudover bliver det beskrevet hvilke testpersoner og informanter, der har været med i iterationerne. Iteration Formål At definere et system, og opstille krav til, hvad systemet skal kunne. Implementere skitserne, således der opstilles en brugergrænseflade. Sikre, at overvejede funktioenr medtages i implementeringen. Modellere systemet, ved implementation af funktioner, og sikre at de opstillede kriterier blev opfyldt. Bruge 1 uge på at implementere nødvendige funktioner. Færdiggøre rapporten. Resultat At indsamle data vedrørende Tonnys problemstilling. Tilføjet: Problemområdet med klasser og hændelsestabel. Tilføjet: Skitser til brugergrænsefladen. Tilføjet: Anvendelsesområde. Brugergrænseflade opsat, således der kunne testes på systemet. Tilføjet: Prototype med fokus på at teste brugergrænsefladen. Revideret: Problemområdet, hvor struktur blev tilføjet. Tilføjet: Rapport struktur komplet opsat. Implementering skrevet. Arkitektur. Design. Revideret: Problemområdet. Anvendelsesområdet. Tilføjet: Funktioner tilføjet. Kvalitetssikring af systemet. Revideret: Problemområdet. Anvendelsesområdet. Implementering. Desi Indragelse af testperson(er) Kort skype-interview med Tonny, hvor problemstilling blev defineret. Interview på Tonnys kontor, med fuld gennemgang af nuværende system, samt evaluering på skitser. Tonny testede systemet og satte nye krav til næste iteration. Tonny testede systemet og satte nye krav til næste iteration. 6 testperoner testede systemet for at se, om de forstod brugergrænsefladen. Tonny konkluderede på systemet. Tabel 4.1. Tabel over formål, resultat samt indragelse af testperson(er) for hver iteration 12

21 Strukturen i rapporten er inspireret af metoderne i OOA&D [1]. Da der benyttes en iterativ udviklingsmodel, vil der være elementer af rapporten, som gennemgår en konstant udvikling gennem projektet. En visualisering af den iterative udviklingsmetode kan ses på figur 4.2. I hver iteration vil der blive opstillet krav for næste iterationen ud fra evalueringen af iterationen. Disse krav vil danne udgangspunkt for eventuelle nye designkrav, analyser og funktioner. I slutningen af hver iteration vil løsningen blive testet og derefter evalueret. Under de forskellige test og evaluering vil klienten blive inddraget for at få feedback. Endeligt vil der opstilles en diskussion, konklusion og perspektivering, som opsamling og afrundning på projektet. Figur 4.2. Iterativ udviklingsmodel. 4.1 Strategi Dette afsnits formål er at prioritere og fastlægge rækkefølgen af aktiviteterne i analyse- og designprocesserne. Det skal udmunde i en konkret strategi for den overordnede analyseog designopgave. Dette gøres ved at beskrive opgaven, finde vanskeligheder og derefter definere og anvende en situationsbestemt strategi [1, p. 279]. Teknisk platform Den tekniske platform der skal arbejdes med er en Magento-webshop som er udviklet i PHP, med en MySQL-database til at persistere data. Magento er for projektgruppen et ukendt system, men med den forudgående viden og erfaring omkring PHP og MySQL, 13

22 anses det som en mulig, men omfattende opgave, at tilegne den nødvendige viden omkring Magento for at udvikle et tilfredsstillende system. Udviklingen Projektgruppen har viden omkring C#, hvilket systemet vil blive udviklet i. Der skal udvikles en webapplikation, hvilket projektgruppen ikke har større erfaring med. Dette betyder at en del af udviklingstiden vil blive brugt til at læse dokumentation. Da projektgruppen har et godt læringsmiljø samt en bred vifte af færdigheder anses de ukendte teknologier ikke som en hindring i forhold at udvikle systemet. Specielle forhold Der skal i projektforløbet opstilles en udviklingsserver, hvor systemet skal implementeres på. Dette gøres, da der arbejdes for en reel klient, som allerede har en fungerende webshop. Det er derfor ikke en mulighed at udarbejde et system, som arbejder direkte på klientens fungerende system. Derudover får projektgruppen rig mulighed for at teste systemet for eventuelle fejl. Udviklingsserveren opstilles desuden, da det ikke vil være en god idé at afprøve systemet på klientens webshop, hvis der opstår uventede fejl, som får hans webshop til at gå ned. Når systemet skal tages i brug af Sinful kan der opstå problemer. Det er derfor vigtigt at systemet er testet grundigt på en installation af Magento der er virkelighedstro. I forbindelse med implementeringen hos Sinful vil det være fordelagtigt at have en backup, samt at have lagt en eller flere planer for hvad der skal ske hvis der skulle opstå problemer. Da Sinful har hovedkontor i Århus, og projektgruppen er bosiddende i Aalborg, er der en udfordring i forhold til afstand mellem projektgruppen og klienten. Dette kan løses ved planlægning af møder og aktiv kommunikation løbende gennem projektforløbet. Det er også værd at afstemme forventningerne fra begge parter, da projektet skal være afsluttet efter en periode på fire måneder. Det er derfor vigtigt at vurdere alle forslag, idéer og ønsker til funktionaliteten så de vigtigste krav, for både projektgruppen og Sinful bliver opfyldt ved projektets afslutning. Dette sætter også høje krav til projektgruppen, da der efter endt projekt skal afleveres et system, som klienten er tilfreds med. Dette er en ny tilgang til projektet, da systemerne på tidligere semestre ikke nødvendigvist skulle benyttes efter semestrets afslutning. Da projektgruppen havde de indledende samtaler med Tonny Andersen, var begge parter opsat på, at projektet skulle være produktivt for de involverede parter. Tonny Andersen var indforstået med at projektgruppen havde nogle bestemte krav i studieordningen, der skulle opfyldes. Ligeledes havde projektgruppen en forståelse for at Tonny Andersen driver en seriøs virksomhed, og som han gjorde opmærksom på, ville han gerne lægge nogle timer i projektet hvis resultatet i sidste ende blev et brugtbart system, som ville øge effektiviteten af Sinfuls prisoptimering. 14

23 Strategi Den overordnede strategi for projektet vil være at holde en aktiv dialog med Tonny Andersen - især i begyndelsen, men også løbende igennem projektforløbet. Således vil det være fordelagtigt at mødes fysisk med klienten Tonny Andersen i Aarhus i så vidt omfang som muligt for at skabe en god relation til klienten. På grund af den fysiske afstand mellem projektgruppen og klienten vil der også blive benyttet Skype-møder under projektforløbet, for oftere at kunne være i dialog med klienten uden betydelige omkostninger tids- og transportmæssigt. Det er væsentligt at teste hver iteration af systemet med Tonny Andersen, så projektet hele tiden har den rette kurs. For at kunne lave de forskellige test, vil det være en fordel at kunne se Tonnys skærm, og dermed følge med i hvordan han bruger systemet, og hvilke problemer han støder på. Det vurderes derfor at videosamtaler, hvor Tonny Andersen deler sin skærm, er en fordelagtig løsning. 4.2 Opsummering I problemformuleringen stilles et undrende spørgsmål, som skal løses igennem resten af rapporten. I systemdefinitionen gives en kort og præcis forklaring af, hvad systemet skal kunne, når det er færdigt udviklet. Til sidst blev de organisatoriske forhold beskrevet i PACT-analysen. Hele problemanalysen danner grundlag for, hvad der skal udvikles og overvejes igennem resten af projektperioden. Udviklingsmetoden blev derfor beskrevet i dette kapitel, med henblik på at give læseren et overblik over, hvad der skulle nås i projektet. Tidsplanen blev opstillet i slutningen af projektet, og er derfor en præcis tidsplan for projektperioden. Derudover blev der lagt en strategi for, hvad der blev overvejet i starten af projektet. Som det blev beskrevet i kapitlet gennemgås analysedelen af rapporten igennem hver iteration. På trods af dette vil de kommende kapitler vedrørende Analysedokumentet og Designdokumentet være beskrevet som det færdige resultat. 15

24 Del II Analysedokument 16

25 Analyse af problemområdet 5 I dette kapitel vil det analyserede problemområde blive beskrevet. Et problemområde, er den del af omgivelserne, der administreres, overvåges eller styres ved hjælp af et system. Analysen er lavet ud fra samtale med Tonny Andersen. Metoden der vil blive benyttet er taget fra Objekt-orienteret Analyse & Design (OOA&D) [1]. I metoden beskrives virkeligheden indenfor problemområdet som de kommende brugere ser den. Prisstyring og visualisering af produktinformation er det overordnede, systemet kommer til at administrere. Formålet med dette kapitel, er at beskrive situationen i problemområdet. Der lægges vægt på at prioritere overblik frem for detaljer. Dette gøres for at finde frem til kernen af problemstillingen og derved give bedre mulighed for i sidste ende at udvikle en løsning der afhjælper problemstillingen. I analysen klassificeres objekter og deres hændelser karakteriseres. Der findes endvidere frem til klassernes adfærd samt strukturen imellem klasserne. Det er kun de klasser og hændelser, der er relevante for de fremtidige brugeres forståelse af problemområdet, som defineres i analysen. Resultatet af analysen bliver således en fastlæggelse af systemets problemområde. Der vil blive udarbejdet en hændelsestabel over problemområdets klasser og hændelser. Derefter vil strukturen på klasserne fastlægges ved hjælp af et klassediagram. Når dette er gjort, opnås der en forståelse af systemets problemområde og et solidt grundlag for at modellere problemområdet til det nye system. Modellen benyttes, som grundlag for arkitekturen, så det nye system senere i rapporten kan designes og implementeres. Der vil indgå tre aktiviteter fra OOA&D [1]; Klasser, Struktur og Adfærd. De beskrevne aktiviteter i dette kapitel vil være det endelige resultat, på trods af den iterative udviklingsproces. Det vil senere i rapporten blive beskrevet, hvad der er fundet frem til, under hver iteration. Dette er forklaret yderligere i kapitel Klasser og hændelser I dette afsnit vil relevante klasser og hændelser, der er fundet frem til, blive beskrevet. Klasserne er beskrevet som det første, hvorefter de relevante hændelser vil blive præsenteret. Dette opsættes i en hændelsestabel. 17

26 5.1.1 Klasser For at skabe en forståelse for strukturen, samt klargøre hvad problemområdet indeholder, udføres klasseaktiviteten. En klasse er en beskrivelse af en samling objekter med samme struktur, adfærdsmønster og attributter. De endelige kandidater til klasseaktiviteten er fremkommet gennem flere iterationer, hvor der flere gange er foretaget interviews med klienten Tonny Andersen. Igennem projektet er der udført brainstorms over, hvilke klasser det var relevante. Nedenfor er de relevante klasser i problemområdet beskrevet. De beskrevne klasser opsættes i et klassediagram i afsnit 5.2, og kan ses på figur 5.1. Det afspejles i problemområdets struktur, at der arbejdes med en eksisterende webshop i form af en Magento-installation. Webshop Webshop-klassen repræsenterer Magento-løsningen. Tonny Andersens nuværende hjemmeside er bygget op med en Magento-løsning, hvorfra hele webshoppen kan styres og administreres. Sinful befinder sig ikke i ét, men fire lande. Disse lande har hver især deres egen valuta. Webshop-klassen skal derfor holde styr på, hvilke lande der indgår. Til at modellere dette oprettes en Land-klasse. Land Denne klasse beskriver hvilket land en netbutik tilhører. En kunde kan besøge en webshop i flere lande ved at gå ind på de forskellige landes domæne. Derfor vil denne klasse afspejle en netbutiks domæne. Hvis en kunde går til Sinful.se, vil de interagere med den svenske netbutik. Land-klassen skal desuden vide noget om, hvilke produkter der findes i hvert land. Produkt I Produkt-klassen oprettes produkterne. Produkter oprettes blot én gang, for derefter at blive tilkoblet til de lande, hvori de skal være. Tilkobningen til lande sker gennem Produktdata-klassen. Produkt-klassen sørger også for at tildele et produkt et SKU-nummer, hvilket står for Stock Keeping Unit og er et vareidentifikationsnummer. SKU bliver brugt af Sinfuls lagerfolk til at genkende produkter, da et produkt kan for eksempel variere med forskellige farver. Hvis et produkt findes i flere forskellige variationer, tildeles hver variation af produktet et unikt SKU. Indkøbsprisen og fabrikanten af et produkt bestemmes også i denne klasse. Der er dog elementer vedrørende et produkt, der ikke går igen i alle lande, men som er specifikt, for det enkelte land det befinder sig i. Dette håndteres i den næste klasse; ProduktData-klassen. Produktdata ProduktData-klassen indeholder information vedrørende et enkelt produkt. Der tages her stilling til, i hvilke lande, et produkt skal oprettes. Denne klasse oprettes både for at kunne håndtere produkter i flere lande, men også for, at kunne benytte historik over bestemte data, jævnfør systemdefinitionen. Der findes mange produkter i hvert land, men der er unikke egenskaber, der knytter sig til hvert produkt. Information som navn og pris er unikt for hvert land, og oplagt at medtage i denne klasse. Desuden skal det være muligt, 18

27 at bestemme i hvilke lande et produkt skal være. Udover dette holdes der også her styr på konverteringsfrekvens og dækningsbidrag for et produkt. Hvis et produkt skal tildeles en tilbudspris, vil det også blive håndteret i denne klasse. Valutakurs Valutakurs-klassen oprettes for at indhente data vedrørende valutakurser. Det er ønskværdigt at kunne vise aktuelle valutakurser, i forhold til priser på produkterne. Klassen skal derfor indeholde de valutaer, som tilhører de respektive lande i probleområdet. Dette betyder, at når Sverige, Finland og Norge indgår, skal de respektive valutakurser baseres på den danske valutakurs Hændelser I dette afsnit er de relevante hændelser beskrevet. Hændelserne blev udvalgt ved brainstorming. De væsentligste hændelser beskrives kort, for at give en bedre forståelse for, hvad de dækker over. Senere vil de blive opstillet i en hændelsestabel, som ses i tabel 5.1. En hændelse beskriver en øjeblikkelig begivenhed, som involverer en eller flere klasser. Hændelserene navngives ved hjælp af udsagnsord [1]. De væsentligste hændelser i forhold til problemområdet var de, der omhandler produkter og produktdata. Dette er valgt på baggrund af systemdefinitionen, hvor det er beskrevet, at det systemet primært omhandler er prisændringer af produkter. Herunder beskrives de forskellige hændelser kort. Produkt ændret Denne hændelse opstår, når et produkt ændres i Magento. Hændelsen er medtaget, da det er vigtigt at håndtere, når et produkt ændres direkte i Magento, i stedet for igennem det nye system. Produkt tilføjet Hændelsen indtræffer, når et produkt tilføjes i Magento. Det vil ikke være muligt, at oprette produkter direkte igennem det nye system. Derfor skal denne hændelse medtages, så det i den nye løsning vil blive muligt, at håndtere tilføjelser af produkter. Produkt fjernet Når et produkt fjernes i Magento, sker hændelsen Produkt fjernet. Som de to ovenstående hændelser, skal denne medtages, da det er vigtigt for den nye løsning, at kunne håndtere fjernelse af produkter. Produktdata tilføjet Hændelsen Produktdata tilføjet opstår, når et produkt bliver tilføjet til et nyt land direkte i Magento. Den er medtaget da det, som med Produkt tilføjet, ikke er muligt at tilføje 19

28 eksisterende produkter til nye lande gennem det nye system. Dette skal derfor gøres i Magento, hvilket systemet skal kunne registrere og håndtere. Produktdata ændret Når et af parametrene på produktdata bliver ændret, for eksempel en pris, opstår denne hændelse. Produktdata fjernet Denne hændelse optræder, blandt andet, når et produkt fjernes fra et bestemt land. Denne hændelse kan kun udføres ved direkte at fjerne et produkt fra et land via Magentowebshoppen. Her er det igen vigtigt, at det håndteres i det nye system Hændelsestabel Den færdige hændelsestabel ses nedenfor. Tilhørsforholdene mellem hver klasse og hændelse er markeret med et + eller en *. Kan hændelsen forekomme nul eller én gang benyttes +. Hvis hændelsen kan forekomme nul eller flere gange benyttes *. Det er forsøgt at gruppere relevante hændelser for at give et bedre overblik. Tabellen benyttes blandt andet til at finde frem til hændelser, som er fælles for flere klasser. Klasserne benyttes senere til at danne strukturer i et klassediagram. Klasser Webshop Land Produkt Hændelser Produktdata Valutakurs Produkt ændret * * Produkt tilføjet + + Produkt fjernet + + Valutakurs ændret * * Land oprettet * + * Land fjernet * + * Produktdata ændret * Produktdata tilføjet * + Produktdata fjernet * + Tabel 5.1. Hændelsestabel over problemområdet. 20

29 5.2 Struktur Strukturen er den anden aktivitet der udføres i problemområdet. Strukturen udføres på baggrund af klasserne i problemområdet. De strukturelle relationer mellem klasserne beskrives nedenfor, og kan ses i klassediagrammet på figur Klassediagram For bedre at kunne danne sig et overblik over klasserne, er de opsat i et klassediagram. Formålet med et klassediagram er, at modellere relationerne mellem klasserne. Klasserne, som optræder i klassediagrammet, er de klasser der er beskrevet under klasseaktiviteten. Resultatet af klassediagrammet er fremkommet ved brainstorming, og har været en iterativ proces, se del 11, hvor relationerne mellem klasserne systematisk er vurderet. Figur 5.1. Klassediagram i problemområdet. Generaliseringsstruktur Generaliseringsstrukturen beskriver en relation, hvor der findes en generel klasse, samt en eller flere specialiseringsklasser. Den generelle klasse beskriver egenskaber, som er fælles for et antal specialiserede klasser. Generaliseringer kan sprogligt udtrykkes ved formuleringen er-en, hvor en specialiseringsklasse beskrives, som værende det samme som den generelle klasse, blot med justeringer. Der findes ingen generaliseringer i det endelige resultat, da der ikke findes et er-en -forhold i strukturen. Der argumenteres hvorfor der i stedet er valgt at benytte en aggregeringsstruktur, i følgende afsnit. 21

30 Hierakimønsteret Et hierakimønster beskriver objekter på forskellige niveauer, som er forbundet. Dette betyder at et objekt af den nederste klasse har forbindelse til objekter af alle ovenstående klasser. På figur 5.1 betyder det, at produktdata er grupperet i produkter, alle produkter er grupperede i lande, og alle lande er grupperet i én webshop. Et objekt af produktdata hører her til netop ét produkt, og et produkt hører til netop ét land. Landet kan dermed stadig godt indeholde mange produkter. Aggregeringer og associeringer Aggregering og associering er begge objektstrukturer, som modellerer relationer mellem objekter i problemområdet. Ses der på klassediagrammet, benyttes objektstrukturerne til at beskrive strukturelle relationer mellem klasser. Et objekt er en helhed med identitet, tilstand og adfærd [1, p. 47], og strukturerne beskrives på klasseniveau, på trods af, at de er objektstrukturer. Dette betyder, at nogle af klassernes objekter er forbundet. En aggregeringsstruktur benyttes, når et objekt skal være en fundamental og definerende del af den ovenstående klasse. I OOA&D [1] defineres en aggregeringsstruktur med følgende udsagn: Aggregering: Et overordnet objekt (helheden) består af et antal objekter (delene). Som ved generalisering, kan der også her benyttes en simplere formulering, for at beskrive forholdet mellem klasser i aggregeringsstrukturen. Den forkortede formulering af aggregering er: indgår-i. Associeringsstrukturen beskriver en relation mellem to eller flere objekter. Associering beskriver dog ikke en definerende egenskab mellem objekter. Udsagn fra OOA&D [1]: Associering: En sammenhæng mellem et antal objekter. Associering benyttes når en aggregering udtrykker en for tæt knyttet sammenhæng mellem objekter. Dette kan for eksempel benyttes til at beskrive et ejerskabsforhold til en bil. Bilen kan skifte ejer, så en associering mellem bilen og en ejer kunne benyttes. En associering kan beskrives med er-forbundet-med. Aggregering mellem Webshop og Land Overordnet er klassen Webshop valgt til at repræsentere Magento-webshoppen hos Sinful. Da der er en netbutik i hvert land er det valgt at klassen Land, repræsenterer hvert enkelt land. Det er valgt at benytte en aggregeringsstruktur, hvilket betyder, at et land skal indgå i klassen Webshop. Ved denne struktur, er det essentielt for det overordnede objekts beståelse, at delobjektet oprettes. I klassediagrammet har Webshop kardinaliteten 1, som betyder, at der oprettes én webshop, hvori der kan være lande. Antallet af lande der kan være, er illustreret ved klassen Land. Antallet af lande kan være fra 1 til mange, illustretet ved 1..*. Det betyder at der skal minimum være ét land i en webshop, dog kan der 22

31 optræde mange lande. Det er på baggrund af dette valgt at benytte aggregering fremfor generalisering eller associering. Aggregering mellem Land og Produkt Klassen Land beskriver det domæne, som netbutik-kunder besøger. I problemområdet skal der for hvert land, være én til mange produkter. Begrundelsen for at benytte aggregering er, at det ikke giver mening at have en netbutik, som ikke indeholder produkter. Aggregering mellem Land og Valutakurs Relationen mellem de to klasser beskrives ved en aggregeringsstruktur. Dette er valgt, da projektgruppen anså det, som værende et vigtigt aspekt, at se på, hvilken valuta, der kobler sig til hvert land. Ud fra klassediagrammet skal der kobles en valutakurs på hvert land. Der er to grunde til at benytte denne struktur fremfor associering. For det første, skal valutakursen knyttes sammen med et bestemt land. Det er ikke nødvendigt at indhente flere valutaer, end der er lande. For det andet, kan forbindelsen fra et objekt i Valutakursklassen ikke kobles på mere end ét objekt fra Land-klassen. Med dette menes der, at den svenske valuta kun skal forbindes med den svenske netbutik. Aggregering mellem Produkt og ProduktData Relationen der benyttes mellem Produkt og ProduktData er aggregering. Dette betyder, at de elementer der findes i ProduktData indgår i Produkt-klassen. I klassediagrammet ses det, at for hvert produkt kan der fremstå 1 til mange objekter af produktdata. Produktdata repræsentere de parametre som er specifikke de enkelte lande. Produktdata spiller således en definerende rolle for produktet Klynger Klasserne i et klassediagram kan grupperes i klynger, for at give et bedre overblik over problemområdet. I OOA&D beskrives klynger med følgende udsagn: Klynge: En samling af klasser, som er indbyrdes forbundne. I dette projekt anså projektgruppen klassediagrammet, som værende den eneste klynge. Dette blev valgt, da OOA&D-bogen foreskriver, at en klynge normalt består af klasser der er forbundet med generaliserings- og aggregeringsstrukturer. Endvidere beskrives det også, at forbindelsen mellem klasser fra forskellige klynger normalt forbindes ved at benytte associeringsstrukturer. Når en klynge identificeres tildeles den en overskrift, hvori klasserne indgår. Skulle en sådan struktur have været benyttet her, ville klassediagrammet kunne få overskriften Prisstyringsværktøj. Hvis brugere af værktøjet også skulle håndteres i problemområdet, kunne de have fået en klynge ved navn Ansatte. 23

32 5.3 Adfærd Adfærd er den sidste aktivitet der udføres i problemområdet. Klassernes objekter har visse rammer for rækkefølgen af hændelser, i form af et defineret hændelsesforløb. Rækkefølgen af hændelser beskrives ved hjælp af adfærdsdiagrammer, hvor de mulige hændelser for objekter af en klasse, illustreres som et tilstandsdiagram. Formålet med udførslen af adfærdsaktiviteten er, at skabe en forståelse for, hvordan hver enkelt objekt kan påvirkes. Forståelsen af objekters opførsel benyttes senere i projektet som inspiration til, hvilke funktioner systemet skal indeholde. På illustrationerne i dette afsnit ses først klassens navn i en boks for sig. Derefter ses pilen, som skal anses som en hændelse. Pilen betegner et tilstandsskift for objektet, og fører til en ny tilstand, objektet kan have. Hvis en pil går ud fra tilstanden og tilbage igen, betegnes den som iterativ. Iterativt betyder, at den samme hændelse kan ske flere gange, dog uden, at objektet skifter tilstand. En klasse har altid en hændelse, som opretter objektet. Der skal desuden også tilføjes en sluthændelse, som resulterer i at objektet bliver nedlagt. En starthændelse er illustreret med en udfyldt sort cirkel. Sluthændelsen er illustreret ved en udfyldt sort cirkel med en ring omkring. Det er valgt kun at beskrive de tre vigtigste klasser ved hjælp af adfærdsdiagrammer. Webshop Tilstandsdiagrammet for Webshop-klassen er vist på figur 5.2. Klassen Webshop bliver initialiseret, når webshop oprettes. Starttilstanden beskriver at en Magento-webshop oprettes og sluttilstanden beskriver at en Magento-webshop nedlægges. Ud over det, findes der fire hændelser, som kan påvirke klassen. De fire hændelser er lavet som løkker, da de kan optræde mange gange. To af hændelserne, har med Produkt at gøre og hedder Produkt tilføjet og Produkt fjernet. Når et produkt tilføjes eller fjernes påvirkes Webshop-klassen, da produktet enten skal tilføjes eller fjernes i Magento-databasen. De to resterende hændelser er Land oprettet og Land fjernet. De to hændelser sker, når der henholdsvis oprettes et nyt land i Magento og når et land i Magento nedlægges. Figur 5.2. Tilstandsdiagram over klassen Webshop Produkt Tilstandsdiagrammet for Produkt-klassen forefindes på figur 5.3. Klassen repræsenterer hvert enkelt produkt i netbutikken, og initialiseres ved starttilstanden Produkt tilføjet. Sluttilstanden Produkt fjernet definerer, at et produkt ikke længere findes i Magentowebshoppen. Der findes tre hændelser; Produkt ændret, Produktdata tilføjet og 24

33 Produktdata fjernet. Den første hændelse sker, hvis et produkt ændrer tilstand via Magento-webshoppen. Det kan for eksempel være, hvis et produkts kostpris ændrer sig. De to andre hændelser sker, hvis et produkt bliver tilføjet eller fjernet fra et land. Figur 5.3. Tilstandsdiagram over klassen Produkt Produktdata Tilstandsdiagrammet for Produktdata-klassen ses på figur 5.4. Det skal bestemmes i Produktddata, hvilket navn et produkt skal have i bestemte lande. Klassen håndtere derudover konverteringsfrekvens og dækningsbidrag for det produkt, klassen er koblet på. Da dækningsbidraget skifter fra land til land, er den tilføjet her, i stedet for på produktet. På den måde, kan værdien sættes på produktet i det pågældende land. Klassen ProduktData består af en række parametre, som tilknyttes ét produkt. Klassens starttilstand initialiseres ved ProduktData tilføjet. Der er fire måder, hvorpå ProduktData fjernes. Det kan fjernes manuelt ved ProduktData fjernet. Det kan ske, hvis et land fjernes fra Magento-webshoppen; Land fjernet. Derudover kan et produkt også fjernes, hvilket nedlægger ProduktData. Til sidst fjernes klassen også hvis hele webshoppen bliver nedlagt. Der findes fire hændelser, som kan påvirke klassen. Pris ændret sker, hvis et produkt tildeles en ny pris direkte i Magento-webshoppen. Konverteringsfrekvens ændret sker, når værdien ændres i Google Analytics. Der holdes her styr på, hvor mange besøg et produkt har haft i et givet land, og antallet af solgte produkter. Dækningsbidrag ændres, hvis kostprisen på et produkt ændres, eller hvis et produkt sættes til en ny udsalgspris. Den sidste hændelse, Tilbudspris ændret, forekommer, hvis en vare sættes på tilbud. Figur 5.4. Tilstandsdiagram over klassen Pris 25

34 5.4 Opsummering Formålet med analysen af problemområdet var, at beskrive den information og de objekter, som det kommende system skal administrere. De elementer, som blev analyseret i dette kapitel, vil senere komme til at danne grundlag for systemets design og implementering. Igennem kapitlet er de relevante klasser og hændelser blevet belyst. Vurderingen og udvælgelsen af klasser og hændelser er sket igennem flere iterationer, og dette kapitel havde til formål at beskrive det endelige resultat af problemområdet. Resultatet af analysen frembragte en hændelsestabel, som illustrerede forbindelsen mellem klasser og hændelser. Derudover blev der udarbejdet et klassediagram med klasser og strukturer samt et adfærdsmønster med attributter for hver klasse i et klassediagram. I det efterfølgende kapitel vil der påbegyndes en analyse af anvendelsesområdet, hvor der ses nærmere på systemet der skal udvikles ud fra aktørernes synspunkt. 26

35 Analyse af anvendelsesområdet 6 Der vil i dette kapitel udføres en analyse af anvendelsesområdet for systemet. Definitionen på et anvendelsesområde er ifølge bogen Objektorienteret Analyse & Design (OOA&D) [1]: Anvendelsesområde: En organisation, der administrerer, overvåger eller styrer et problemområde. En analyse af anvendelsesområdet udføres med det formål at fastlægge kravene til brugen af systemet. Dette gøres, blandt andet, ved at analysere de relevante aktører i forhold til systemet, samt aktørernes brugsmønstre. Derudover søges der at fastlægge hvorledes systemet skal bearbejde og behandle informationen i anvendelsesområdet. Dette defineres ved at udforme en komplet funktionsliste for systemet [1]. 6.1 Brug I analysen af anvendelsesområdet ses der på systemets brug. Her defineres den tiltænkte brug af systemet, for at afgøre hvordan de forskellige aktører interagerer med systemet. Definitionen udarbejdes ved hjælp af en beskrivelse af aktører, brugsmønstre og efterfølgende en fremstilling af tilstandsdiagrammer for de respektive brugsmønstre. Denne proces sikrer, at systemet udvikles i tråd med brugsområdet [1]. Der vil indledningsvis opstilles en aktørtabel over systemets aktører og brugsmønstre, samt relationen imellem disse, for at opnå det fornødne overblik. Aktørtabellen kan ses i tabel 6.1. Tabellen vil derefter anvendes som udgangspunkt til en grundig analyse af systemets aktører og deres brugsmønstrer Aktører Aktørerne er, i forhold til brug, en abstraktion af brugere eller andre systemer, som interagerer med systemet [1]. Aktørerne specificeres med tre faktorer: formål, karakteristik og eksempler. Aktørerne er blevet identificeret ud fra Sinfuls arbejdsdelegering, som blev undersøgt gennem flere interviews med Tonny Andersen. Systemets aktører kan ses i aktørtabellen i tabel

36 Aktører Administrator Prisregulator Magento Google Analytics Brugsmønstre Registrer administrationsbruger Tilføj ansat Slet ansat Søg på produkt Filtrer produkter Omregn pris Se produktkategori Se ændringer Fortryd ændringer Synkroniser med Magento Ændre pris Gem til Magento Registrer køb Registrer besøg Tabel 6.1. Aktørtabel for systemet Da formålet med systemet, henholdsvis effektiv prisstyring, befinder sig indenfor en stor branche som online handel, vil det være naturligt at tro, at der ville være adskillige yderligere aktører. Dette er dog ikke tilfældet, da retfærdiggørelsen af oprettelsen af en ny aktør er, at aktørens rolle skal være forskellig fra eksisterende aktører. Er dette ikke tilfældet bliver aktørerne slået sammen til én. Det kan sammenlignes med at retfærdiggørelsen af oprettelsen af en ny klasse forudsætter at objekterne i den nye klasse har forskellig adfærd fra eksisterende klasser [1]. På baggrund af dette, er de fire ovenstående aktører beskrevet i detaljer nedenfor. Administrator Formål: En person, som opretter og administrerer alle brugernes adgang til systemet blandt Sinfuls ansatte. Karakteristik: Systemet består af én administrator med øverste mandat. Administratoren er højt positioneret i Sinful. Eksempler: En direktør ønsker at tilbyde et værktøj til sine ansatte, der kan assistere i prisstyringsprocessen. Direktøren logger derfor ind på sin administrator-bruger, som direktøren kontrollerer. Ønsker direktøren at uddelegere prisstyringsarbejdet til andre ansatte tilføjer direktøren de nødvendige ansatte i systemet, og tildeler dem de rettigheder, som de skal have for at kunne håndtere prisstyringsarbejdet. 28

37 Prisregulator Formål: En person, der har en begrænset adgang til systemet. Prisregulatorens primære opgave er, at danne sig et overblik over den tilgængelige data, konkludere herpå og ændre priser på de tilkoblede produkter. Karakteristik: Systemet kan bestå af flere prisregulatorer, der har til opgave at tilpasse priserne på forskellige produkter, så de stemmer overens med markedet. Dette er en opgave, der skal udføres løbende, og optil flere gange på samme produkt. Eksempel: Prisregulator A ønsker at opdatere priserne på 10 produkter i den svenske butik. Prisregulator A vælger at systemet skal vise de data, der er relevante for Sverige og filtrerer produkterne. De nye priser indtastes og ændringerne gemmes i webshoppen. Prisregulator B vil sikre, at ingen produkter sælges med tab. Prisregulator B vælger at se produkternes priser i alle lande tilkoblet til webshoppen. Herefter sorterer prisregulatoren produkterne efter dækningsbidrag, med den laveste værdi rangeret øverst, hvorefter de nødvendige priser ændres og gemmes i webshoppen. Magento Formål: Et system, der fungerer som et værktøj til at oprette, administrere og styre produkterne og salg i en webshop, samt opsætter webshoppen på en hjemmeside. Karakteristik: Der kan være mange produkter i Magento. Disse produkter kan modificeres og indtilles på mange forskellige parametre. En af disse parametre er prisen, som kan variere fra land til land. Desuden gemmer Magento salgsdata, så det er muligt at se antal solgte produkter over en bestemt tidsperiode. Eksempler: Magento A er opsat til at styre en webshop i fire forskellige lande med omkring 2500 produkter. Produkterne er dynamiske, da parametre såsom navn, pris og lagerbeholdning kan ændre sig. Magento B er fuldt funktionel og tilkoblet to lande. Der ønskes fra firmaets side at gå ind i det Svenske marked, hvorfor der oprettes et nyt land i Magento. De relevante produkter sættes i relation til det nye land. Google Analytics Formål: En service, der er tilkoblet en webshop og indsamler og gemmer statistiske data om brugeradfærd. Google Analalytics primære opgave er at overvåge og rapportere brugeres adfærd på hjemmesider. Dataen kan bruges til at rapportere om salgsmæssige statistikker på produkterne styret af Magento. Karakteristik: Leverer statistik omkring webshoppens besøgendes adfærd på de forskellige lande tilkoblet Magento. Disse oplysninger bliver registreret og gemt af systemet, samt anvendt til at levere yderligere parametre til prisstyringsværktøjet. 29

38 Eksempler: Google Analytics er tilkoblet den danske netbutik, og indsamler data, hver gang en bruger tilgår hjemmesiden, ser på produkter eller køber produkter. Desuden indsamles der information om, hvordan en bruger kommer ind på hjemmesiden. Dette kan gøre det muligt at se hvilke online kampagner der har fået kunden ind på siden Brugsmønstre Med brugsmønstre, søges der, at opnå en abstraktion over interaktionen mellem aktørerne og systemet. Brugsmønstre kan ses som en beskrivelse af aktørernes arbejdsopgaver, samt deres udførelse deraf, indenfor systemets rammer. De identificerede brugsmønstre kan ses i tabel 6.1. Ud fra brugsmønstrene i tabellen udvælges en række brugsmønstre, som anses for at repræsentere de mulige måder hvorpå systemet kan anvendes. Overordnet set findes to hovedmønstre til at beskrive brugsmønstre, henholdsvis proceduremønstret og materialemønstret, som kan ses på figur 6.1. Hvilket mønster, der passer på aktørens arbejdsopgave, afhænger af brugsmønstrets natur. Brugsmønstrets natur afhænger hovedsageligt af hvorvidt der er strikse rammer og regler for, hvad aktøren må gøre i en given situation. Er det tilfældet, at der er strikse rammer, er det hensigtsmæssigt at benytte proceduremønstret, da dennes basale struktur består af en bestemt sekvens med få variationer, i form af selektioner og iterationer [1, p. 127]. Grundlæggende er proceduremønstret bygget på, at en handling medfører en tilstand, hvorefter en ny handling medfører en ny tilstand. Materialemønstret er derimod baseret på minimal anvendelse af sekvens. Aktøren er derfor ikke tynget af et regelsæt i forhold til rækkefølgen af handlinger. Dette giver aktøren mere frihed i anvendelsen af systemet. Brugsmønstre kan beskrives på flere måder, blandt andet i form af et tilstandsdiagram eller en brugsmønsterspecifikation. Et tilstandsdiagram giver et godt illustrativt overblik over brugsmønstrets dynamiske forløb, samt logikken involveret deri. Dette sker dog på bekostning af detaljer, hvilket en brugsmønsterspecifikation derimod tilbyder. En brugsmønsterspecifikation er en kort og præcis beskrivelse af brugsmønstret med fokus på aktørerne. Det er, modsat af tilstandsdiagrammer, svært at beskrive brugsmønstrets logik ved hjælp brugsmønsterspecifikationer. Baseret på dette er det valgt at anvende både tilstandsdiagrammer, samt brugsmønterspecifikationer for dermed at få belyst alle brugsmønstrernes facetter. De udvalgte brugsmønstre beskrives nedenfor. De objekter og funktioner, der er relaterede til brugsmønstrene nævnes, men bliver først beskrevet i kapitel 6.2. Registrer administratorbruger Brugsmønster: Registreringen af administrationsbrugeren udføres af Tonny Andersen under opsætningen af systemet. På loginsiden vælges muligheden for at registrere, hvorefter Tonny Andersen bliver præsenteret for en ny side. Her indtaster Tonny Andersen diverse brugeroplysninger, såsom navn, og kodeord. På samme side bedes Tonny Andersen indtaste oplysninger omkring adgang til Magento-systemet og databasen tilkoblet Magento. Afslutningsvis klikker Tonny Andersen på godkendelsesknappen, 30

39 Figur 6.1. Det generelle procedure- og materialemønster [1, p. 129] der aktiverer oprettelsen af administrationsbrugeren, hvorefter han dirigeres videre til systemets startside. Godkendes de indtastede oplysninger ikke, bliver Tonny Andersen bedt om at kontrollere de indtaste oplysninger og derefter indtaste dem korrekt. Objekter: Bruger, Webshop. Funktioner: Registrer bruger, Log bruger ind. Mønster anvendt: Proceduremønstret er anvendt, da det i en registreringsprocess er vigtigt at alt bliver udført og udfyldt korrekt, således brugeren bliver korrekt registreret. Ændre pris Brugsmønster: Sinfuls prisregulator ønsker at ændre prisen på et produkt. Søgefunktionen bruges til at finde det ønskede produkt. Den nye pris indtastes og prisregulatoren kan enten lave flere prisændringer eller gemme alle ændringer til Magento. Objekter: Produkt, ProduktData. Funktioner: Opdater priser, Vis antal ændringer. Mønster anvendt: Materialemønstret er anvendt, da der ved prisændringer er mange muligheder indenfor hvilke informationer, man vil have vist, samt hvor mange priser og produkter man ændrer. Brugeren har dermed meget magt og kontrol indenfor nogle løse rammer, hvorfor materialemønstret er mest hensigtsmæssig. Synkroniser med Magento 31

40 Figur 6.2. Tilstandsdiagram for Registrer administratorbruger Figur 6.3. Tilstandsdiagram for Ændre pris Brugsmønster: Der er tilføjet nye produkter manuelt i Magento, og administratoren ønsker derfor at synkronisere systemet med Magento. Derved sikres det, at systemet repræsenterer den korrekte model af virkeligheden. Administratoren starter synkroniseringsprocessen og venter på at systemet er klar til brug igen. Objekter: Produkter, Produktdata, Webshop. 32

41 Funktioner: Indlæs produkter. Mønster anvendt: Her er der igen valgt at bruge proceduremønstret, da synkroniseringsprocessen er en automatiseret process, som skal forløbe efter faste regler, uden indblanding fra brugerens side. Figur 6.4. Tilstandsdiagram for Synkroniser med Magento Gem til Magento Brugsmønster: Når prisregulatoren er færdig med at lave prisændringer gemmes ændringerne til systemets og Magentos database. Det er ikke muligt at anvende systemet igen før processen er afsluttet. Objekter: Produkt, ProduktData, Webshop. Funktioner: Opdater priser. Mønster anvendt: Her er proceduremønstret anvendt, da det igen er vigtigt at processen med at gemme prisændringer til Magento sker efter faste rammer uden indgriben fra brugeren. Efter at systemets aktører, samt deres brugsmønstre, er blevet identificeret, gennemgået og analyseret vil der ses på hvilke funktioner der kræves for at systemet kan tilbyde disse brugsmønstre for aktørerne. 6.2 Funktioner I dette afsnit vil systemets funktioner fastlægges. Funktionerne i et system lader en aktør anvende systemets model af problemområdet. Dette kan være igennem en brugergrænseflade eller en systemgrænseflade hvis aktøren er et andet system. Ifølge OOA&D vægtes overblik fremfor detaljer, så dette afsnit vil resultere i en komplet funktionsliste, men kun de væsentligste funktioner vil blive specificeret [1]. 33

42 Figur 6.5. Tilstandsdiagram for Gem til Magento Initiativet og effekten på udførelsen af en funktion bestemmes af dens type. Den del af systemet som igangsætter en funktions udførelse, har initiativet til udførelsen og effekten af udførelsen ligger i den del som bliver påvirket af udførelsen. Initiativ til udførelsen af en funktion kan kun ligge ét sted: i anvendelsesområdet, problemområdet eller modellen af et IT-system. Effekten af udførelsen kan, imodsætning til initiativet, have indflydelse på både problemområdet og anvendelsesområdet. Funktioner kan være en eller flere af typerne aflæsning, signalering, opdatering og beregning. Typerne vil blive beskrevet og der vil blive vist en figur over hvor initiativet samt effekten af udførelsen for de enkelte funktioner, ligger. Disse figurer er baseret på figurene i [1, p. 138]. Initiatiet vil blive angivet med en *, effekten på udførselsen ligger der hvor pilen peger hen. På figurene ses et diagram over anvendelsesområdet, probemområdet, grænsefladelaget, funktionslaget og modellaget. Grænsefladelaget er det lag som aktørene i anvendelsesområdet interagere med. Funktionslaget indeholder systemets funktioner og modellaget har systemets model. Aflæsningsfunktioner henter data fra systemets model, som afspejler tilstanden i problemområdet. Som det ses på figur 6.6 ligger initiativet samt effekt af udførelsen i anvendelsesområdet. Figur 6.6. Diagram over initiativ samt effekt på en aflæsningsfunktion 34

43 Signaleringsfunktioner informerer om ændringer af data i modellen, hvilket repræsenterer en tilstandsændring i problemområdet. Da det er ændringer i modellen der signaleres, er det også i dette lag initiativet til udførelsen ligger. Det ses på figur 6.7 at signaleringen kan have effekt på anvendelsesområdet og problemområdet. Figur 6.7. Diagram over initiativ samt effekt på en signaleringsfunktion Opdateringsfunktioner opdaterer modellen, så den afspejler problemområdet. Initiativet til udførelsen kan ligge i anvendelsesområdet, hvis en aktør vil opdatere modellen. Initiativet kan alternativt ligge i problemområdet, hvis systemet modtager opdateringer direkte derfra. Det ses ud fra figur 6.8 at effekten i begge tilfælde ligger i modellaget. Figur 6.8. Diagram over initiativ samt effekt på en opdateringsfunktion Beregningsfunktioner udregner et output ud fra på et input. Det ses på figur 6.9 at denne type funktioner udføres på initiativ af aktører i anvendelsesområdet, hvor effekten også ligger Systemets funktioner I dette afsnit vil systemets funktioner blive gennemgået. Funktioner tildeles en kompleksitet som kan være simpel, middel, kompleks eller særdeles kompleks. Kompleksiteten bliver vurderet ud fra det estimerede tidsforbrug af funktionen. Indlæs produkter har til ansvar at indhente alle produkter og relevant produktdata fra en Magento-webshop og gemme dem i modellen. 35

44 Figur 6.9. Diagram over initiativ samt effekt på en beregningsfunktion Funktion Kompleksitet Type Indlæs produkter Kompleks Aflæsning, Opdatering Opdater priser Middel Opdatering Vis ændrede produkter Simpel Aflæsning Vis eller skjul produktdata Simpel Aflæsning Filtrer produktdata Simpel Aflæsning Sorter produktdata Simpel Aflæsning Vis antal ændringer Simpel Signalering Registrer bruger Middel Opdatering Log bruger ind Middel Aflæsning Hent valutakurs Middel Aflæsning, Opdatering Opdater priser er funktionen der fører ændringer i modellen over i Magento-webshoppen. Den administrerer således en del af problemområdet. Vis ændrede produkter er en funktion der kan vise hvilke produkter der er ændret pris på, men ikke er opdateret i Magento-webshoppen endnu. Vis eller skjul produktdata, Filtrer produktdata og Sorter produktdata er alle funktioner der skal gøre det nemt og overskueligt at finde bestemte produkter som skal opdateres. Vis antal ændringer er en funktion der kan vise hvor mange ændringer der er foretaget. Registrer bruger har til formål at registrere nye brugere. I systemet er der to brugerroller. Den ene er en administratorbruger som er ejeren af webshoppen. Denne bruger kan oprette prisregulator-brugere som er tilknyttet webshoppen. Prisregulatoren har kun adgang til at opdatere produktpriser. Log bruger ind har til ansvar at verificere en brugers identitet og give adgang til systemet, enten som administrator eller prisregulator afhængig af brugertype. Funktionen skal derefter tillade brugeren at anvende de dele af systemet brugeren har adgang til. Hent valutakurs Har til ansvar at hente opdaterede valutakurser. 36

45 6.3 Opsummering Der blev i dette kapitel fundet frem til aktørerne, som kan have indflydelse på, hvordan systemet skal udvikles. Aktørerne beskriver også, hvem der senere kommer til at arbejde med systemet. Derudover blev der fundet frem til funktioner, som skal implementeres for at få et optimalt system. Da aktører og funktioner nu er kendte elementer i forhold til udviklingen af systemet, skal der analyseres på, hvordan relevante arkitekturmønstre kan benyttes. 37

46 Del III Designdokument 38

47 Arkitektur 7 Efter analyse af problem- og anvendelsesområdet ses der på, hvordan systemet skal designes. Her vil der fokuseres på at designe arkitekturen af systemet, da dette har til formål at opnå en strukturering af systemet og dets komponenter. Under designet af arkitekturen vil der bruges elementer fra bogen Objektorienteret Analyse & Design [1]. Med udgangspunkt i kravene til systemet i form af brugsmønstre og funktioner, udledt i den foregående analyse, overvejes hvilke designkriterier, der ønskes til systemet. Designkriterierne udformes omkring kravene identificeret i analysen. Derudover udarbejdes en prioritering af designkriterierne således, at kriterierne balanceres i designet på bedst mulig vis. Dette skal resultere i, at der opnås et design uden væsentlige svagheder. I forbindelse med designet af arkitekturen, vil systemets komponenter og struktur defineres. Dette indebærer overvejelser omkring arkitekturmønstre, hvilket vil hjælpe med at strukturere systemet i veldefinerede, indbyrdes komponenter. Resultatet vil være et klassediagram med specifikationer af de komplekse komponenter [1, p. 185], hvilket derefter anvendes i implementeringen. 7.1 Kriterier Inden systemet udvikles opstilles der en række kriterier, som vurderes ud fra de specifikke krav til systemet, se afsnit 3.2. På den måde skabes der et bedre overblik over hvad, der er essentielt i systemet, og dermed skal lægges mest fokus på. Herunder beskrives og vurderes nogle af de generelle kriterier samt de mere specifikke kriterier Generelle Kriterier Ud fra OOA&D [1, p. 174] er der i tabel 7.1 opstillet en række generelle kriterier. Kriterierne er vægtet efter hvor vigtige de er for det konkrete projekt. 39

48 Kriterium Meget Vigtigt Mindre Irrelevant Trivielt vigtigt vigtigt opfyldt Brugbart Effektivt Sikkert Korrekt Pålideligt Vedligeholdbart Fleksibelt Forståeligt Genbrugbart Flytbart Integrerbart Tabel 7.1. Generelle kriterier Brugbart Ved brugbart menes hvor godt systemet er tilpasset i forhold til de omgivelser, systemet skal implementeres i. Således skal man både tage højde for de organisatoriske, arbejdsmæssige samt tekniske omgivelser. Da formålet med systemet er, at lette prisoptimeringen på produkter i forhold til det nuværende Excel-ark, se afsnit 2.2, vurderes det, at brugbart er af meget vigtig karakter. Systemet skal således være enkelt i brug, uden at gå på kompromis med funktionaliteten til prisstyring. Ligeledes er det af meget vigtig karakter, at systemet tilpasses den tekniske platform for at udnytte dens ressourcer optimalt og derigennem gøre systemet mere brugbart. Effektivt Systemets effektivitet er sat til vigtigt, da hovedformålet med systemet er, at formindske arbejdstiden ved prisstyring. Systemet skal erstatte det tidligere Excel-ark, som havde problemer med hastigheden og overskueligheden, se afsnit 2.2. Da systemet skal løse disse problemer er effektiviteten vigtig. Det kan dog være nødvendigt at gå på kompromis med systemets effektivitet for at holde det så brugbart som muligt. Effektivitet er derfor sat til vigtig og ikke meget vigtig. Sikkert Selvom meget af systemets data såsom pris, id og producent ikke er hemmeligt, er der også informationer som indkøbspris, tilbudspris og antal solgte produkter, hvilket er vigtigt at uvedkommende ikke har adgang til. Hvis sikkerheden ikke er i orden, vil det for eksempel være muligt for folk at ændre priserne direkte i webshoppen, eller se butikkens omsætning og populære produkter. Sikkerhed er derfor sat til vigtig. Korrekt Ved korrekt menes om systemet opfylder de formulerede krav fundet i analysen. Kriteriet vurderes til at være vigtig for at kunne levere et brugbart produkt til klienten. Kriteriet vurderes ikke til meget vigtig, da der udvikles iterativt, og således kan der ved hver iteration opstå nye krav eller ske en nedprioritering af tidligere krav til systemet. 40

49 Pålideligt Systemets pålidelighed er sat til vigtig. Dette er gjort, da der ikke må ske fejl i forbindelse med prisopdateringerne. Sker dette, risikerer Sinful at miste penge, hvis for eksempel en pris bliver sat for lavt på et produkt. Med cirka 2500 produkter er det ikke altid, at en fejl i prisændringen vil blive opdaget med det samme. Det er derfor vigtigt, at den del af systemet der ændrer prisen i webshoppen er pålidelig. Systemets andre funktioner som valutakurser og udregning af dækningsbidrag er ikke helt så kritiske og pålidelighed er derfor sat til vigtig. Vedligeholdbart Ved vedligeholdbart menes, hvor store omkostninger, der er ved at finde og rette fejl i et kørende system. Det er vigtigt at eventuelle fejl kan blive rettet hurtigt, da forkert prisregulering kan betyde mindre fortjeneste til Sinful. Således vurderes vedligeholdbart til at være af vigtig karakter. For at gøre systemet vedligeholdbart er det vigtigt, at kildekoden er forståelig, hvorfor de to kriterier vedligeholdbart og forståeligt ses som to vigtige egenskaber ved det endelige system. Fleksibelt Ved fleksibelt menes hvor store omkostninger, der er ved at tilføje, fjerne eller ændre funktionalitet i et kørende system. Ofte bliver man nødt til at vælge mellem hvor effektivt, eller fleksibelt, et system skal være, da der er en fundamental konflikt i designet af de to kriterier. Ud fra interviews med klienten er der skabt en god forståelse for problemstillingen, hvorfor der prioriteres at designe en mere specialiseret løsning, der til gengæld er effektiv. Derfor vurderes kriteriet fleksibelt til at være af mindre vigtig karakter. Forståeligt Forståeligt handler om udviklernes interne strukturering af koden. Det vil sige, hvor nemt det er for udviklere at skabe sig et overblik over koden og forstå systemet. Da systemet udarbejdes af seks udviklere med hvert deres ansvarsområde, er det vigtigt at koden bliver struktureret forståeligt, hvorfor kriteriet sættes til vigtigt. Genbrugbart Genbrugbart handler om muligheden for at genbruge dele af systemet i andre beslægtede systemer. Da effektivt er blevet vurderet som et vigtig kriterie, og der derfor vælges at udarbejde en specialiseret løsning, sættes genbrugbart til irrelevant i design af systemet. Ligeledes stiller systemdefinitionen ikke krav til at systemets dele skal bruges af andre systemer. Flytbart Ved flytbart menes hvor store omkostninger der er ved at flytte systemet til en anden teknisk platform. Eftersom der ikke er opstillet krav til at systemet skal være flytbart, se afsnit 3.2, vurderes kriteriet flytbart til at være mindre vigtigt. 41

50 Integrerbart Integrerbart handler om omkostningerne ved at koble systemet til andre systemer. Eftersom systemet skal kobles sammen med Magento og Google Analytis samt det ikke kan udelukkes at der skal kobles andre eksterne systemer til systemet i fremtiden vurderes kriteriet til at være vigtigt. Således ses integrerbart som systemets sammenkobling med eksterne systemer for at tilgå ekstern data Specifikke kriterier Nedenfor opstilles der tre specifikke kriterier, som systemet skal overholde. Kriterierne er nogle, som projektgruppen finder relevante at tænke over igennem alle iterationer, da de i sidste ende gerne skulle være med til at overholde kriteriet om, at systemet skal være brugbart. Samtidig er det ønskværdigt at undersøge, hvorvidt der stadigt kan opretholdes en høj effektivitet. Kriterium Meget Vigtigt Mindre Irrelevant Trivielt vigtigt vigtigt opfyldt Skal være opbygget på én side Der skal ikke ændres i Magentoinstallationen Overskuelighed Tabel 7.2. Specifikke kriterier. Et af kriterierne er, at systemet skal opbygges på én side. Dette er et ønsket kriterie, da der kan opretholdes en høj effektivitet ved at have alle produkter samlet ét sted, fremfor at tildele dem hver sin side. Dette muliggør at det er hurtigt at ændre priser på flere forskellige produkter. Hvis man skal ind på undersider til hvert produkt for at ændre prisen, vil denne proces blive meget langsommere, se afsnit 2.2. Desuden skal alt produktinformation også kunne vises på en side, således der ikke skal navigeres alt for meget rundt i systemet. Et meget vigtigt krav er, at systemet skal kunne fungere uden, at der skal ændres i Magento installationen. Dette er vigtigt, da mange webshopejere ikke selv har ekspertisen til at ændre i Magento installationen. Det vil være med til at fremtidssikre systemet i forhold til Magento-opdateringer. Det vil også mindske tidsforbruget ved implementeringen af systemet. Da systemet skal bruges til at håndtere store mængder af produkter, fremkommer der sandsyndtligvis megen information i systemet. Det er derfor vigtigt, at systemet bliver stillet op på en overskuelig måde. Med overskuelig menes der, at data skal grupperes. Hvis der for eksempel er et produkt i en tabel, skal informationen om det specifikke produkt prænsenteres sammen med produktet. Derudover skal funktioner af samme kaliber grupperes sammen. Hvis der er flere funktioner, som gør næsten det samme, skal de ikke ligge forksellige steder. Ydermere er det vigtigt, at overveje hvilke funktioner der ofte benyttes, og hvilke der ikke gør. De funktioner, som sjældent benyttes, må godt gemmes i en navigationsbar i brugergrænsefladen. Dette medfører, at brugeren ikke skal præsenteres for unødigt information. 42

51 Systemet der skal udvikles er et ekspert system, og projektgruppen ved, at Tonny Andersen har stor erfaring med IT. Derfor vurderes overskuelighed til at være vigtigt, da det stadigt er vigtigere at vise meget information på et sted. Der arbejdes her, ud fra et begreb fra DIS kaldet Omniscience [7, p. 328]. Her arbejdes der med brugere som har perfekt viden omkring det, de laver, og ikke laver fejl, når de benytter systemet. Hvis dette er tilfældet er det acceptabelt i systemet er udvikle korte, effektive stier til at navigere rundt i systemet ved. 7.2 Komponentarkitektur I det følgende afsnit vil der blive udarbejdet et klassediagram, der beskriver struktureringen af systemet inddelt i forbundne komponenter. Det gøres for at skabe forståelse af systemets opbygning, samt lette organiseringen af designarbejdet. Ligeledes bevirker opdelingen af systemet i komponenter, at kompleksiteten af designopgaven reduceres. Det samlede design bliver opdelt i mindre komplekse opgaver. Afsnittet vil benytte OOA&D som gennemgående kilde [1]. Til at udarbejde en fleksibel og let forståelig strukturering af et system benyttes komponenter. Komponent: En samling af programdele, som udgør en helhed og har et veldefineret ansvar. [1, p. 185] Således er en komponent, ud fra en objekt-orienteret tilgang, en afgrænset del af systemet, men ofte mere end en klasse. Komponenterne beskrives i Unified Modeling Language (UML) som pakker, og de indbyrdes afhængigheder repræsenteres med forbindelser mellem to komponenter [1, p. 185]. Ud fra de fundne komponenter i et system, kan komponentarkitekturen udarbejdes. Komponentarkitekturen defineres som: Komponentarkitektur: En strukturering af et system i indbyrdes forbundne komponenter [1, p. 186] Klassediagrammet med komponentarkitekturen, der præsenteres i dette kapitel, afspejler det endelige resultat. Udarbejdelsen af komponentarkitekturen foregik dog iterativt og de forskellige til- og fravalg vil blive beskrevet samt argumenteret for i del V Iterationer. Til udarbejdelse af komponentarkitekturen kan det være en hjælp at undersøge forskellige arkitekturmønstre. Fordelen ved arkitekturmønstre er, at de bygger på erfaring fra tidligere projekter og kan være en hjælp til at udarbejde et konsistent design [1, p. 189]. I de følgende afsnit repræsenterer en stiplet linje på figurerne en forespørgsel fra komponenten, som den stiplede linje går ud fra, til den komponent, som pilen peger på. Det skal implicit forstås, at komponenten der modtager en forespørgsel, sender data tilbage til komponenten, der foretager forespørgelsen. Der er derfor ikke angivet en pil med data der bliver sendt tilbage; se eventuelt figur

52 7.2.1 Lagdelt arkitekturmønster Et ofte benyttet mønster til opdeling af systemer i komponenter er en lagdelt arkitektur. En lagdelt arkitektur består af et antal vertikale lag hvor der i hvert lag kan være en eller flere komponenter horisontalt. I hvert lag kan der være én eller flere komponenter liggende horisontalt. Hver komponent har en grænseflade opadtil, nedadtil eller begge dele. Grænsefladen opadtil beskriver de operationer komponenten stiller til rådighed for det ovenliggende lag. Grænsefladen nedadtil beskriver hvilke operationer komponenten har til rådighed fra det underliggende lag. Mønstret kan ses på figur 7.1. Der findes forskellige variationer af lagdelt arkitektur, hvor man skelner mellem en åben eller lukket arkitektur, samt en streng eller løs arkitektur. En lukket arkitektur betyder at et lag kun kan tilgå operationer fra tilstødende lag, hvorimod det ved en åben arkitektur er muligt for hvert lag at tilgå operationer fra et hvert over- eller underliggende lag. En streng arkitektur betyder, at det pågældende lags operationer kun kan tilgå operationer i underliggende lag, hvor der i en løs arkitektur kan tilgås operationer i både underliggende og overliggende lag. På figur 7.1 vises et eksempel på en lukket-streng, eksempel (a), arkitektur samt en åben-løs arkitektur, eksempel (b). Fordelen ved en lukket-streng arkitektur er, at det giver en enkel struktur af afhængighed mellem lagene. Hvis der ændres i et specifikt lag, vides det, at det kun er det overliggende lag, der muligvis bliver berørt. Til gengæld er ulempen at for at kunne tilgå lag længere ned i strukturen end i-1, se figur 7.1, bliver man nødt til at sende kald gennem hvert nedestående lag for at kunne tilgå den ønskede information. Dette gøres ved at oprette operationer i de underliggende komponenter, der blot sørger for at sende forespørgslen videre. Det vil sige at kompleksiteten i komponenterne øges. I en åben-løs arkitektur er kompleksiteten i komponenterne lavere, da ethvert komponent kan tilgå operationer, der stilles til rådighed fra andre komponenter i systemet. Til gengæld øges afhængigheden betydeligt, da det ikke kan udelukkes, at hvis der ændres i en specifik komponents tilgængelige operationer, så kan det påvirke alle komponenter i systemet. I det endelige design af komponetarktekturen, se figur 7.5, er det lagdelte arkitekturmønster anvendt i forbindelse med Tre-lags-arkitekturmønstret, som beskrives i afsnit Der bliver anvendt en lukket-streng arkitektur således at, hvis ændringer foretages i et specifikt lags operationer, er det kun det ovenliggende lag, der bliver påvirket. Dette skaber en lav afhængighed mellem de forskellige lag. Systemet bliver heraf nemmere at vedligeholde, hvilket er et kriterie fra afsnit 7.1, der er blevet vurderet til at være vigtig for det endelige system Model-View-Controller arkitekturmønster På figur 7.3 kan mønstret for Model-View-Controller (MVC) [8] ses. MVC består af tre komponenter; Model, view og controller som hver kan have delkomponenter tilknyttet. Modelkomponentens primære ansvarsområde er, at holde styr på objekterne, der repræsenterer problemområdet. Sker der en ændring i problemområdet, skal det afspejles i modelkomponentens objekter ved et tilstandsskift. Controllerkomponenten er bindeled mellem view- og modelkomponenten. Controlleren sørger for at sende forespørgsler fra viewet til modellen, og omvendt. Controlleren opdaterer viewet, hvis modellen 44

53 Figur 7.1. Det lagdelte arkitekturmønster. Eksempel (a) med en lukket-streng arkitektur. Eksempel (b) med en åben-løs arkitektur skifter tilstand. Controlleren ændrer endvidere modellen, hvis brugeren manipulerer med viewet. Viewkomponenten præsenterer visuelt data fra modellen for brugeren. Viewet repræsenterer således den grafiske brugergrænseflade og interaktionen med brugeren. Brugeren kan ændre i dataen visuelt repræsenteret i viewet, og hvis ændringerne overholder den opstillede logik, ændrer controlleren tilstanden af modellen. Passiv Model-View-Controller-mønster. Da den endelige komponentarkitektur benytter sig af klient-server-mønstret, som beskrives i afsnit er det valgt at benytte det passive MVC-mønster [9]. I det passive MVC-mønster er det controlleren, der modificerer og opdaterer modellen. Således er viewet ikke forbundet med modellen og modtager ikke notifikationer fra modellen ved tilstandsændringer. Alle forespørgsler eller opdateringer går gennem controlleren, og modellen er uafhængig af både controlleren og viewet; deraf navnet passiv MVC. Det passive MVC-mønster benyttes ofte ved implementering af klient-server-arkitekturen, hvor det er klienten der udelukkende er den aktive part. Således er det klienten, der ved for eksempel at benytte en browser, aktivt tilgår viewet, hvorved controlleren sender en forespørgsel til modellen om at sende data til viewet. Hvis modellen ændrer tilstand, er det først når klienten fortager en aktiv handling i browseren, at viewet igen bliver opdateret. Således notificerer modellen ikke viewet ved tilstandsændringer. Aktiv Model-View-Controller-mønster Det aktive MVC-mønster adskiller sig fra det passive MVC-mønster ved, at modellen kan ændre tilstand uden controlleren er indblandet i denne tilstandsændring. Det kan for eksempel ske, hvis systemet er implementeret således at eksterne systemgrænseflader kan opdatere data i modellen udenom controlleren. Ligeledes hvis det er vigtigt at viewet afspejler tilstandsændringen så snart den optræder i modellen benyttes det aktive MVCmønster. Da ideen med at implementere MVC-mønstret er, at gøre modellen og viewet uafhængig, benytter man observatør-mønstret [8], se figur 7.2, til at notificere viewet om tilstandsændringer i modellen, for at undgå at gøre viewet og modellen direkte afhængige 45

54 af hinanden. Formålet med observatør-mønstret er, at definere et et-til-mange-afhængighedsforhold mellem objekter [8]. Når et subjekt ændrer tilstand, notificeres og ændrer alle observatører til det givende subjekt ligeledes tilstand, se figur 7.2. Som eksempel kunne man have to brugergrænseflader, hvor den første repræsenterer data fra modellen som et søjlediagram, og det andet repræsenterer modeldataen ved hjælp af et kurvediagram. Ved at benytte observatør-mønstret kan modellen gøres til et subjekt og de to brugergrænseflader til observatører til det pågældende subjekt. Når modellen ændrer tilstand, notificeres de to brugergrænseflader og de benytter hver deres implementering af opdateringsfunktion til at repræsentere den nye data, henholdsvis som søjlediagram eller kurvediagram. På denne måde kan man undgå en tæt kobling mellem objekterne. Modellen behøver ikke vide hvilken slags objekter brugergrænsefladerne er; den skal blot notificere sine observatører ved tilstandsændringer. Figur 7.2. Observatør-mønstret [1, p. 272] Systemdefinitionen i afsnit 3.2 opstiller krav til, at systemet skal udvikles som en webapplikation med platformsuafhængighed. Derudover skal kildekoden ifølge studieordningen skrives i C#, hvorfor det er valgt at benytte ASP.NET MVC-frameworket, som beskrives i kapitel 9. I det endelige design af komponentarkitekturen benyttes det passive MVCmønstret i forbindelse med opdelingen af brugergrænseflade, funktioner og model i komponenten PriceOpti server, se figur 7.5. Ved at benytte MVC er der mulighed for at have forskellige controllere og views af den samme model. Det muliggør at en administrator kan have et specifikt view med en controller, som giver adgang til at kunne modificere data i viewet, hvorimod en indkøber kan have et andet view og controller af modellen, hvor der kun gives adgang til at kunne se viewet, men ikke modificere i dataen. Således bevirker brugen af ASP.NET MVC-frameworket at systemet er tilpasset den tekniske platform, uden at den tekniske platform sætter begrænsninger for brugernes krav til systemet. Dette er i god tråd med at kriteriet brugbart blev sat til meget vigtig i forbindelse med udarbejdelsen af arkitekturen. Ved at benytte ASP.NET MVC-frameworket er man tvunget til at implementere MVCarkitekturen, da frameworket er bygget op omkring designprincipperne i MVC. Dette er et eksempel på konvention over konfiguration [10], som er et softwareparadigme hvis mål er, 46

55 at fjerne nogle af de valg en softwareudvikler skal tage i forbindelse med udarbejdelse af softwarearkitekturen. Samtidig søger paradigmet at øge overskueligheden i arkitekturen, uden at det sker på bekostning af fleksibiliteten. Konvention over konfiguration - paradigmet passer således godt sammen med udarbejdelsen af komponentarkitekturen der benytter arkitekturmønstre, der bygger på erfaring fra tidligere projekter til udarbejdelse af et konsistent design jævnfør afsnit 7.2. Figur 7.3. Passiv Model-View-Controller-mønstret Klient-server arkitekturmønster Udover det passive MVC-mønster, benyttes også klient-server-arkitekturmønstret. På figur 7.4 ses strukturen af mønstret. I klient-server mønstret deler man systemet op i én til flere klientkomponenter og en serverkomponent. Klientkomponenten har til ansvar at præsentere grafik, tekst og information til brugeren. Ligeledes står klientkomponenten for interaktion med brugeren samt kommunikation af information til og fra serveren. Det er således klienten der er den aktive ved enten at sende en forespørgsel eller at ændre i dataen præsenteret i browseren. Serverkomponenten har ansvar for at opbevare og redigere data som deles af klienterne. Serverkomponenten foretager ligeledes simple beregninger og bearbejdninger af data samt sender og modtager data til og fra klienterne [11]. Serveren tager således ikke selv initiativ til noget, men reagerer udelukkende når den modtager forespørgsler fra klienterne. Klienterne er brugerne der tilgår systemet ved hjælp af deres webbrowser. Fordelen ved kombinationen af klient-server-arkitekturmønstret og MVC-mønstret er at serveren stiller et view til rådighed som klientens browser kan rendere. Der opnås platformsuafhængighed da viewet kan tilgås af forskellige browsere på forskellige platforme. Tre-lags-arkitekturmønster I den endelige version af komponentarkitekturen er der benyttet tre-lags-arkitekturmønstret til en yderligere opdeling således at der benyttes et præsentationslag, et applikationslag samt et databaselag. Tre-lags-arkitekturmønstret er en specialisering af klient-servermønstret ved at serveren bliver delt op i et yderligere lag. Således opretter man et databaselag der har til ansvar at opbevare og redigere data fra modellen samt sende og modtage data fra applikationslaget. Applikationslaget står for kommunikationen mellem klienten og databaselaget samt for at foretage større beregninger på den tilgængelige data fra mo- 47

56 Figur 7.4. Klient-server-arkitekturmønstret dellen. Præsentationslaget har ligesom klienten i klient-server-arkitekturmønstret ansvar for den grafiske præsentation til brugeren samt for at stå for kommunikationen til og fra applikationslaget. Valget af tre-lags-arkitekturmønstret blev taget på baggrund af at der til det endelige system skal benyttes flere servere og databaser, se figur 7.5. I applikationslaget ligger Magento-serveren samt selve systemet. I databaselaget er der en database til at gemme modelkomponenten fra systemet samt en database til at gemme og hente data fra Magento. Endelig skal der tilgås forskellige eksterne databaser heriblandt Google Analytics for data om brugeradfærd samt en ekstern database for valutakurs til for eksempel beregning af dækningsbidrag i de forskellige lande Klassediagram af komponentarkitekturen På figur 7.5 ses den endelige komponentarkitektur. På det overordnede plan er der blevet benyttet tre-lags-arkitekturmønstret til at dele systemet op i præsentationslaget, applikationslaget samt databaselaget. Tre-lags-arkitekturen benytter det lagdelte arkitekturmønster med en lukket-streng arkitektur. Ligeledes er tre-lags-arkitekturen en specialisering af klient-server-arkitekturen hvorfor dette også er i brug. Endelige benyttes det passive MVCmønster mellem komponenterne model, view og controller i PriceOptimizer-komponenten. Klient-server-arkitekturen bevirker at der kan være n klienter koblet på applikationsog databaselaget og ved brug af MVC-mønstret kan man gøre brug af muligheden for at sende et unikt view til hver klient der sender en forespørgsel til Price Optimizer-serveren. 48

57 Figur 7.5. Klassediagram af komponentarkitekturen 49

58 Grænseflader 8 I dette kapitel vil systemets grænseflader blive beskrevet. Dette inkluderer både systemgrænseflader og brugergrænseflader. En grænseflade stiller systemets model af problemområdet og funktioner til rådighed for aktørerne i anvendelsesområdet. Det er derfor vigtig at grænsefladerne designes og implementeres så de passer til anvendelsesområdet. 8.1 Brugergrænseflade Brugergrænsefladen blev designet iterativt ud fra klienten Tonny Andersens indledende ønsker beskrevet i første interview A.1, prototyper som Tonny Andersen blev præsenteret for i det andet interviewet A.3 samt de to usability-test foretaget i 2. og 3. iteration, se afsnit 12.3 og I dette afsnit vil det endelige design af brugergrænsefladen blive beskrevet. Argumentationen for de forskellige valg og fravalg, som følge af den iterative udviklingsproces, vil blive beskrevet i del V Iterationer. Dette kapitel vil bruge OOA&D [1] og DIS [7] som primære kilder. Først præsenteres brugergrænsefladen i det endelige system hvorefter der beskrives hvilke designprincipper der er blevet benyttet samt argumentationen for de forskellige valg Opbygning af brugergrænsefladen I det følgende afsnit vil designet af det endelige system blive præsenteret. Afsnittet benytter sig af figurer i formindsket udgave. Større udgaver af figurerne kan findes i bilag D. Login-side Det første der møder brugeren når han tilgår systemet Price Optimizer skal være en loginside. Her bliver brugeren bedt om at logge ind eller registrere sig som ny bruger. Brugeren kan vælge om systemet skal huske login-oplysningerne til næste gang brugeren tilgår systemet. Når brugeren logger ind med en registreret Price Optimizer bruger, fremkommer der en Google login-form. Ved at brugeren logger ind med sin Google konto, giver personen systemet tilladelse til at hente brugerens Google Analytics-data hvis sådan en konto er tilgængelig. 50

59 Figur 8.1. Opbygningen af brugergrænsefladen til Price Optimizers login-side Venstre-menu Når brugeren er logget ind på Price Optimizer og Price Optimizer har hentet relevant data fra eksterne kilder som Magento og Google Analytics bliver brugeren præsenteret for brugergrænsefladen som på figur 8.2. I venstre side skal der være en menu, hvor brugeren kan vælge hvilken information der skal vises for produkterne i tabellen for hvert land. På figur 8.2 kan det ses at General Columns og Default Columns er foldet ud. Der bruges det engelske term Columns for ikke at skabe forvirring ved reference til figur 8.2. Det skal være muligt at folde de forskellige Columns ud og ind ved at trykke på dem. Ligeledes skal der ved menu-headeren være en checkbox, som når der trykkes på, enten krydser eller afkrydser alle produktinformationer i den pågældende Columns. Tabel Til højre for venstre-menuen skal tabellen med de indhentede produkter fra Magentowebshoppen være. Tabellen skal vise de kolonner som brugeren har valgt i venstre-menuen. Felter der kan ændres i tabellen skal have en lille blyant ved siden af sig, se figur 8.2. Ligeledes skal rækken hvor et felt er blevet ændret skifte farve til orange samt det specifikke felt skal gøres fed og stå i kursiv for at tydeliggøre for brugeren hvad der er blevet ændret. Brugeren skal have mulighed for at kunne søge i hver kolonne samt der skal være et overordnet søgefelt som søger i alt data i tabellen. Derudover skal hver række have et plustegn der symboliserer at rækken kan foldes ud. Dette forklares nærmere i afsnittet Fold ud-række

60 Figur 8.2. Opbygningen af brugergrænsefladen til Price Optimizers forside. Venstre-menuen bliver vist og man kan se der er blevet ændret i fire rækker. Se stort billede i bilag D.2 Figur 8.3. Tabellen fylder hele skærmbilledet da venstre-menuen er skjult. De tre knapper Show changes, Undo changes og Save to Magento er deaktiveret da der ikke er foretaget nogen ændringer. Se stort billede i bilag D.4 Knapper På figur 8.2 og figur 8.3 ses fem blå knapper. Knappen længst til venstre, Menu, skal henholdvis skjule og vise venstre-menuen for at give brugeren mulighed for udelukkende at arbejde med tabellen som kan ses på figur 8.3. Dette skal være med til at opfyldet kravet omkring brugbarhed fra afsnit 7.1. De tre knapper til højre for, henholdsvis Show 52

61 changes, Undo changes og Save to Magento skal være deaktiveret så længe brugeren ikke har foretaget sig en ændring i tabellen som på figur 8.3. Når brugeren har ændret et felt skal knapperne aktiveres og de skal vise antallet af ændringer brugeren har foretaget i tabellen. Ved tryk på knappen Show changes skal tabellen udelukkende indeholde de produkter som brugeren har ændret som vist på figur 8.4. Knappen skal da ændre tekst til Show all som når den bliver trykket på skal vise alle produkterne i tabellen igen. Figur 8.4. Efter tryk på knappen Show changes viser tabellen udelukkende de produkter der er blevet ændret. Se stort billede i bilag D.6 Når brugeren trykker på knappen Undo changes skal der poppe et vindue op, illusteret på figur 8.5, som forklarer at effekten vil være at alle ændringer bliver fjernet fra tabellen. Således skal systemet være sikker på at det er det brugeren reelt ønsker at gøre. Figur 8.5. Ved tryk på knappen Undo changes popper et advarselsvindue op som sikrer at brugeren ønsker at fjerne alle ændringer i tabellen Ved tryk på knappen Save to Magento skal der være et overlay, der dækker hele browserens skærmbilledede. På den måde deaktiveres brugerens interaktion med Price Optimizer imens systemet gemmer ændringerne til Magento. Overlayet skal have en animeret loadingbar, samtidig med at der skal være en beskrivende tekst, der forklarer de forskellige stadier Save-to-Magento-processen gennemgår, se figur 8.6. På den måde skal det undgås at brugeren bliver nervøs for, om systemet er frosset, hvis nogle systemprocesser tager lang tid. Knappen Help skal, når brugeren trykker på den, aktivere et overlay som gør brugen af Price Optimizer inaktiv. Samtidig skal den frembringe infobokse, der forklarer hvad 53

62 Figur 8.6. Ved tryk på knappen Save to Magento kommer ovenstående overlay frem. Det er en animeret loadingbar der angiver at systemet ikke er frosset og der beskrives med tekst på hvilket stadie i processen systemet er meningen er med de forskellige interaktive funktioner Price Optimizer stiller til rådighed. De funktioner der bliver beskrevet skal være fremhævet så der ikke er tvivl om hvor infoboksen hører til. Figur 8.7 viser overlayet samt infoboksene Price Optimizer skal stille til rådighed. Figur 8.7. Når brugeren trykker på Help-knappen bliver der lagt et overlay over Price Optimizer og der kommer infobokse frem der beskriver de forskellige interaktive funktioner der er til rådighed. Se stort billede i bilag D.3 Fold ud-række Som tidligere beskrevet skal tabellen indeholde en plusknap. Meningen er, at når brugeren trykker på plusknappen på et produkt, skal der foldes en underrække ud til det specifikke produkt, hvor brugeren kan få mere information om produktet. Se figur 8.8 for illustration. I underrækken skal brugeren kunne se en graf for både prishistorik samt konverteringsfrekvens. Derudover skal Price Optimizer tilbyde en valutaomregner, som ud fra en indtastet standardpris skal kunne udregne den tilsvarende pris i DKK, SEK, EUR og NOK. Der skal kunne ganges en faktor på hver valutakurs, som beskrives i afsnittet

63 Valutakurs & faktor. En illustration af udregningen skal kunne ses ved at holde musen over de forskellige resultater af det indtastede beløb, for de respektive lande, se figur 8.8. Figur 8.8. Ved tryk på plusknappen på et produkt i tabellen foldes rækken ud. Her kan brugeren tilgå mere information om det specifikke produkt samt foretage forskellige udregninger ved hjælp af valutaomregneren. Se stort billede i bilag D.5 Valutakurs & faktor Til højre for knapperne i Price Optimizer skal brugeren kunne se den aktuelle valutakurs for DKK, SEK, EUR, NOK, se figur 8.4. Kurserne skal beregnes udfra 100 DKK, og skal være med til at give brugeren et overblik over, om der har været kursændringer i forhold til den danske krone. Under hver valutakurs skal brugeren have mulighed for at angive en faktor, der skal ganges på den pågældende kurs. For eksempel kunne brugeren vælge at sætte faktoren på den norske kurs til 1,4, hvis brugeren mente, at de norske forbrugere var villige til at betale 40% mere for en vare, end de danske forbrugere. Navigationsbar Designmæssigt er formålet med Price Optimizer at gøre information om produkterne i Magento-webshoppen tilgængelige og mulige at ændre, udelukkende ved hjælp af ét view i Price Optimizer, se afsnit Således er det kun logoet samt en dropdownmenu der optræder i navigationsbaren. Dropdownmenuen tilbyder: Et link til Magento-webshoppen, at synkronisere tabellens data med Magento-webshoppen, en indstillingsside samt at logge brugeren ud af Price Optimizer. 55

64 8.1.2 Dialogmønstre Der findes fire dialogmønstre, jævnfør OOA&D [1, p. 150], omkring hvordan brugere interagerer med et systems brugergrænseflade, henholdsvis skemaudfyldelse, direkte manipulation, menuvalg og kommandosprog. Skemaudfyldnings-mønstret giver brugeren mulighed for at indtaste data i felter, der er klar til redigering eller udfyldning når brugeren ser dem. Skemaudfyldning optager mere plads samt kræver begrænset træning af brugeren, men forenkler indtastningen i forhold til for eksempel kommandosprog-mønstret. Ved kommandosprog skal data og operationer manuelt findes frem og ændres, uden nogen grafisk oversigt, undtaget teksten brugeren selv har skrevet og det systemet eventuelt returnerer. Ved brug af direkte manipulations-mønstret, får brugeren, i lighed med skemaudfyldelse, en grafisk grænseflade. Her kan brugeren interagere direkte med den grafiske brugergrænseflade. Direkte manipulation adskiller sig fra skemaudfyldning, ved at interaktionen kan være et tryk på et ikon eller trække og slippe virtuelle elementer. Det fjerde dialogmønster er menuvalgs-mønstret, hvor brugeren får menuer med valg og alternativer stillet til rådighed. Det gør at brugeren kan foretage ændringer, med systemets forudbestemte funktioner og alternativer. Valg af dialogmønstre En stor del af anvendelsesområdet er at vælge en pris der ønskes ændret, for så at indtaste ændringen. Dialogmønstret ligner som udgangspunkt skemaudfyldelse, fordi prisændringen er en tekstændring indenfor bestemte rammer, men også direkte manipulation fordi priserne skal manipuleres direkte i brugergrænsefladen, med umiddelbart synligt resultat. Fordi klienten ønsker at se mange produkter på én gang, og samtidig opnå en overskuelig brugergrænseflade, vil der bruges en kombination af skemaudfyldelse og direkte manipulation. En konsekvens af dette er, at brugergrænsefladen kan kræve et stort arbejdsområde i form af en høj skærmopløsning. Da det er et ekspertsystem der udvikles anses dette som acceptabelt. Menuvalgsmønstret benyttes også, da enkelte indstillinger og funktioner ikke er nødvendige at have tilgængelige direkte i viewet. Disse elementerne gemmes derfor i en menu Designovervejelser Under udviklingen af designet for brugergrænsefladen er designprincipperne beskrevet i DIS [7, p. 86] blevet benyttet. Det er gjort for at sikre kvaliteten og brugbarheden af brugergrænsefladen. Anvendelsen af principperne hjælper til at udvikle et godt design ved at tage højde for kendte problemstillinger i forbindelse med design af brugergrænseflader. Designprincipperne er inddelt i tre hovedkatagorier: Learnability, Effectiveness samt Accomodation som hver har et antal underkatagorier tilknyttet. I det følgende afsnit vil de engelske termer blive benyttet da en dansk oversættelse af termerne vil være utilstrækkelig i flere tilfælde. 56

65 Learnability Principperne i learnability-kategorien benyttes for at brugere nemmere skal kunne tilgå, lære og huske systemet. Brugeren skal ligeledes ikke bruge for meget tid på at finde ud af hvordan systemet fungerer. Principperne er de følgende: Visibility handler om, at brugerne skal kunne se hvilke funktioner der er tilgængelige, samt hvilke operationer systemet foretager sig. Dette princip bliver benyttet i Price Optimizer, ved at alt interaktion for at ændre, eller tilgå, information om et produkt i Magento webshoppen, kan gøres ved hjælp af ét skærmbillede, som vist på figur 8.2. Næsten alt funktionalitet er derfor samlet på ét skærmbillede. På figur 8.6 er visibility princippet blevet benyttet til at vise en animeret loadingbar, samt beskrive, for brugeren, de forskellige stadier i at gemme data til Magento, således brugerne ikke tror, systemet er frosset. Price Optimizer forklarer på denne måde brugeren hvilke operationer systemet foretager sig. Consistency betyder at brugergrænsefladen skal benytte ensartede farver og ikoner, og systemet skal være konsistent i måden der interageres med brugeren på. I Price Optimizer er det valgt at benytte Bootstrap-frameworket, som beskrives i afsnit 9.1. Ved at benytte Bootstrap til komponenterne i brugergrænsefladen sikres et ensartet design, hvilket er illustreret på figur 8.2. Price Optimizer benytter samme type inputfelt til tabelfelterne, søgefelterne, faktorfelterne samt valutaomregnerfeltet for at være konsistent i måden der vises til brugeren, at et felt kan ændres. Valget af farver til brugergrænsefladen vil blive beskrevet i afsnit Familiarity er at brugeren forstår det sprog og symboler, som systemet benytter sig af. Termerne, Price Optimizer benytter, er fundet ud fra interviews med klienten, se bilag A.3. Således er mange af termerne fagspecifikke, men noget som brugerne forventes at forstå. Derudover benyttes der et blyantsikon til at vise brugeren, at et felt kan ændres, pile på venstre-menuen for at angive at menuen kan foldes ud, samt dynamiske tal-indikatorer på de tre knapper Show changes, Undo changes og Save to Magento, for at angive hvor mange ændringer brugeren har foretaget i tabellen. Affordance handler om at brugergrænsefladen skal designes således at brugeren ikke er i tvivl om hvad de forskellige komponenters egenskab er. For eksempel skal der ikke herske tvivl hos brugeren om, hvad der er en knap, og hvad der er et tekstfelt. På figur 8.2 kan det ses, at i Price Optimizer er alle knapperne placeret horisontalt på linje. Teksten i knapperne indbyder til en handling fra brugeren, og musemarkøren ændrer tilstand, når brugerne bevæger den over knapperne. Tabellen er opbygget omkring kolonner med tekstfelter. I forbindelse med usability-test af prototype 3, se afsnit 13.3, havde en del testbrugere problemer med at finde ud af hvordan de skulle ændre en pris da tabellens indhold så statisk ud. Dette problem blev løst ved at sætte et ikon af en blyant ved siden af priser der kan ændres i tabellen. At det er et ekspertsystem der designes, påvirker ikke learnability-kravene i større grad. Det er vigtigt at brugeren får et konsekvent design og kan forstå interaktionen med systemet. 57

66 Effectiveness Effectiveness handler om at give brugeren en følelse af kontrol, ved at brugergrænsefladen er nem og sikker at bruge. Det gør at en bruger for eksempel kan annullere eller fortryde ændringer, sådan at handlinger ikke er destruktive, medmindre brugeren selv ønsker det. Navigation er hvor nemt brugeren kan danne sig et overblik, samt navigere i systemet. Ved Price Optimizer er der valgt, ved sparring med klienten, at samle alt information om de forskellige produkter på én side. For at bevare overskueligheden blev det valgt, at benytte en kollapse menu, for at brugeren selv kan bestemme hvor meget information, brugeren ønsker at have i tabellen, om hvert enkelt land, se figur 8.2. Ligeledes kan brugeren få mere information om et produkt ved at benytte plusknappen, der er tilknyttet hvert produkt i tabellen. Ved at få vist mere information om et produkt er der plads til færre produkter på skærmen, men brugeren forbliver på samme side og kan vælge at kollapse underrækken, når brugeren er færdig med at benytte det for det pågældende produkt. Endelig har brugeren mulighed for at skjule kollapse menuen når interaktionen med denne er færdig. Således har brugeren mulighed for udelukkende at arbejde med tabellen. Control handler om at vise hvem eller hvad der er i kontrol i systemet. Således benyttes overlayet i Price Optimizer hver gang systemet er i kontrol. Det bliver på den måde vist brugerne, at de skal afvente at systemet igen giver dem kontrol over brugergrænsefladen. Derudover er der benyttet ikoner, til at illustrerer de forskellige knappers adfærd. For eksempel er der vertikale pile på på venstre-menuen, for at vise at menuen kan foldes ud, samt plusknapper på hver række i tabellen til at illustrerer at rækken kan foldes ud. Feedback er at systemet skal give brugeren feedback ved interaktion, så brugeren ikke er i tvivl om at systemet reagerer på brugerens forespørgelse. Det bliver i Price Optimizer håndteret ved at enhver brugerinteraktion med systemet har en effekt. For eksempel highlightes alle input felter ved brugerinteraktion, faktorer input felterne returnerer en succes meddelelse ved ændring samt valutaomregnerens udregninger for de enkelte kurser, kan ses ved at holde musen over den specifikke pris. Recovery betyder at systemet skal give brugeren mulighed for at fortryde udførte handlinger.undo Changes-knappen tilbyder brugeren at fjerne de ændringer, som brugeren har foretaget i tabellen. Denne knap blev efterlyst af testpersonen i assessment-testen i 2. iteration Ved at brugeren har mulighed for hurtig at kunne fjerne foretagede ændringer, effektiviteres anvendelses af systemet, hvilket var et kriterier der var sat til vigtig i kapitel Constraints handler om at sætte begrænsninger for brugeren, så der ikke opstår fejl ved brugerens interaktion med systemet. I Price Optimizer bliver brugeren, ved Undo Changes samt ved lukning af browseren, spurgt om han er helt sikker på at foretage denne handling. Bekræftelse af handlingen skal sikre at der ikke foretages utilsigtet ændringer, der har alvorlige konsekvenser. På figur 8.7 ses Price Optimizers bekræftelses boks, ved Undo Changes, som brugeren skal give sin tilkendegivelse til, før effekten udføres. 58

67 Accomodation Accomodation handler om at applikationen er tilpasset, sådan forskellige typer af brugere med forskellig erfaring kan benytte systemet. Flexibility er at tilbyde brugerne forskellige tilgange til at benytte systemet. Det gøres for at give brugere med forskellig erfaringsniveau mulighed at kunne interagere med systemet. Da det i PACT-analysen i afsnit 3.3 blev belyst, at brugerne af systemet er velintegreret i brugen af IT-systemer, har Flexibility ikke været et højere prioteret princip, i designet af Price Optimizer brugergrænseflade. Style handler om at systemets brugergrænseflade skal designes stilfuldt og attraktivt. Et stilfuldt design er med til at fremme en positiv opfattelse af systemet. Som nævnt i Consistency benyttes Bootstrap for at skabe et konsistent design, hvilket er med til at skabe en attraktivt brugergrænseflade. Argumentation for farvevalg bliver beskrevet i nedestående afsnit Farvevalg Conviviality er at systemet ved beskeder til brugeren, skal være høfligt og venligt i sprogbrugen. Der er ikke noget der ødelægger brugeroplevelsen mere, end et system der benytter sig af aggressive beskeder til brugeren, ifølge DIS [7]. Eftersom systemet der udarbejdes er et arbejdesredskab, der skal bruges af en virksomhed, er det valg at gøre systemets sprogbrug neutralt. Således vil der ikke blive benyttet ladet ord i kommunikationen med brugeren. Accomodation-principperne følges i middel grad, da der ikke er mange forskellige brugere af systemet og det forventes at brugerne har en forståelse for prisstyring og lignende systemer. Brugergrænsefladens stil forsøges at være attraktiv, men fordi det er et ekspertsystem, der skal vise meget information, er dette kun delvist opfyldt, da et rent og minimalistisk design vil være på bekostning af effektivitet, og dermed modstride systemets formål. Andre designovervejelser I tillæg til de nævnte designvalg, benyttes også andre designelementer. For at gøre det lettere at se forskel på rækkerne i tabellen, ændres farvene på hveranden række med en mørkere baggrundsfarve. Sålænge markøren holdes over en række, skal rækken have en tredje baggrundsfarve, sådan at det tydeliggøres hvilken produktrække, der kigges på. Yderligere benyttes pop-up-meldinger for at gøre brugeren opmærksom på vigtige ændringer. Når brugeren gemmer eller fortryder alle ændringer, bliver brugerne spurgt om de er sikre på at de ønsker handlingen udført. Dette sørge for deres handling er intentionelle og de derved ikke kommer til at slette alle ændringer ved en fejl. Rækker der kan foldes ud er en vigtig del af designet, fordi det holder brugergrænsefladen så ryddelig som muligt indtil ekstra information behøves. Når brugeren ekspanderer rækken, udvides den vertikalt, og indeholder yderligere information om produktet og produktdata, som grafer og valutaomregner. Ekspandering og minimering styres ved et plus- og minusikon yderst til venstre i rækken. 59

68 8.1.4 Farvevalg I forhold til valg af farver i Price Optimizer er der blevet benyttet Graphic Design for Electronic Documents and User Interfaces s 5 retningslinjen for farvevalg [12] udover designprincipperne for et godt design. Det er valgt at benytte farven blå som gennemgående farve da blå i mange vestlige kulturer associeres med kulde, vand og himmel, se figur 8.9, men også rolighed, information og af økonomibranchen tillid [7, p. 277]. De sidstnævnte punkter stemmer godt overens med systemets brug. Varme farver, som orange, viser handling og nærhed, og bruges derfor i systemet til at signalere ændringer brugeren har foretaget i tabellen. Rødt er synonymt med fare, og fortryd-knappen er derfor markeret med rød. I modsætning til rød, er grøn forbundet med okay og tryghed i følge figur 8.9. Farven grøn bruges til at markere antal af ændringer på knapperne Show Changes og Save to Magento samt på knappen Menu, når venstre menuen er skjult, se figur 8.3 i kapitel Der er valgt ikke at benytte mere end de fire beskrevende farver, for at følge retningslinje om højst at benytte 5 ± 2 forskellige farver, for at opnå et konsistent design. Inden anden usability test, beskrevet i kapitel 13.3, blev en række i tabellen, markeret med rød, når en bruger havde foretaget en prisændring i den specifikke række, se figur Formålet med dette var at vise brugeren, at der i den pågældende række var blevet ændret en pris. Farvevalget viste sig at være uheldig, da enkelte testbrugere forbandt farven rød med fare, samtidig med at farven rød ofte i regnskabssammenhæng betyder negativ værdi. Testbrugernes opfattelse af farven rød som fare stemmer godt overens med figur 8.9 s beskrivelse af rød. Farven blev herefter ændret til orange. Orange er en varm farve som kræver brugerens opmærksomhed uden at signalerer fare. Figur 8.9. Farveskema over vestlige farvekonventioner. Billedet er taget fra DIS [7, p. 277] 8.2 Systemgrænseflade I dette afsnit beskrives systemgrænsefladerne. Systemgrænsefladerne er grænseflader der stiller systemets funktioner og modeller til rådighed for aktørerne. Systemgrænseflader er i denne sammenhæng defineret som grænseflader mellem Price Optimizer og eksterne systemer. Inden systemet kan udvikles skal de relevante systemgrænseflader belyses og designes. 60

69 Systemet anvender en database til datalagring, så det er oplagt at have en systemgrænseflade, der har ansvaret for kommunikation til og fra databasen-serveren. Hvis der ses på problemområdet, interagerer systemet med en Magento-webshop. Denne Magentowebshop er en stor del af problemområdet, så der skal udvikles en systemgrænseflade der giver systemet adgang til at overvåge og administrere Magento-databasen. Derudover er der brug for at hente valutakurser, for de lande webshoppen opererer i. Dette lægger op til at der udvikles en systemgrænseflade med dette ene formål. Måden hvorpå systemet skal fungere efter login, er illustreret på figur Brugeren vil ændre priser, og gør dette gennem systemet. Når ønskede ændringer er udført, kan brugeren gemme det til Magento-serveren. Derefter, for at de nye priserne skal vises for kunder i webhoppen, indexeres den nye information til webshoppen. Det ses på figuren at, når en datastrøm krydser grænsen mellem anvendelsesområdet og problemområdet er det en indikator for, at der er brug for en systemgrænseflade. Der er også brug for en systemgrænseflade, der stiller data fra Google Analytics til rådighed, da en del af den ønskede data omkring produkterne findes her. Figur Flowchart af komponenter der kommunikerer De systemgrænseflader der er identificeret og som skal implementeres er således: Kommunikation med Magento samt reindexering Indhentning af valutakurser Kommunikation med Google Analytics 61

70 Det bemærkes at processerne vedrørende behandling af data mellem Magento-serveren og Price Optimizer adskiller sig væsentligt fra processen Reindexering. Det må derfor vurderes under implementeringen om det er fordelagtigt at dele denne systemgrænseflade i to, med hver deres ansvarsområde. 8.3 Opsummering Formålet med designdokumentet var at udforme systemets arkitektur samt at give en klar ansvarsfordeling imellem systemets komponenter. Der blev ligeledes vurderet på kriterier til systemet udfra krav fra klienten. Derudover blev forskellige designprincipper gennemgået og analyseret med det formål at designe en brugbar brugergrænsefladen. Tilsidst blev systemetgrænseflader analyseret og designet. 62

71 Del IV Implementering 63

72 Teknologier 9 Formålet med dette kapitel er, at beskrive anvendte teknologier, der er benyttet til udvikling af systemet, samt at argumentere for de vigtigste teknologiske valg, der er taget med henhold til implementering. I afsnit 7.1 vedrørende kriterier, blev det vedtaget, at systemet, skulle være brugbart. Dette blev valgt på baggrund af flere møder med Tonny Andersen.Udover at skulle være brugbart for Tonny, skulle det også være brugbart for eventuelt ansatte prisregulatorer hos Sinful. Der ønskes ligeledes platformsuafhængighed da der kan være brugere med flere forskellige operativsystemer, og det blev derfor vedtaget, at udvikle systemet som en webapplikation. Dette kræver en række af teknologier, der skal benyttes, for at implementere systemet. I henhold til Studieordningen for Bacheloruddannelsen i Software, skal kildekoden til systemet skrives i C#. Den valgte platform til at udvikle i, er Microsofts Visual Studio, hvilket er Microsofts eget udviklingsmiljø til C#. For at udvikle og implementere systemet, behøves teknisk udstyr af forskellig slags. Der behøves en server for at implementere Magentoinstallationen, jævnfør afsnit 4.1. Dermed gøres webshoppen tilgængelig for aktørerne. Systemet der udvikles behøver også en server, hvorpå webapplikationen kan køres. For at gøre projektet så virkelighedstro som muligt, blev der oprettet et udviklingsmiljø med to servere. Den måde det er opsat på, er virkelighedstro, fordi serveren med Magentoinstallationen svarer til klientens Magentoinstallation, og det bliver således let at skifte installation, når systemet er færdigudviklet. Yderligere medfører dette at der ikke bliver ændret i klientens nuværende webshop, sådan at produkter får forkert pris på grund af testing udført i udviklingsøjemed. Magentoinstallationens kode skal ikke ændres i, i henhold til de specielle kriterier i afsnit For at øge sikkerheden omkring adgang til udviklingsmiljøets sensitive data, er serveren med systemet opsat med en begrænsning på hvilke IP-adresser, der kan tilgå det. Magentoinstallationen og det udviklede system kan begge installeres på samme server, hvis det er ønskværdigt. 64

73 9.1 Anvendte teknologier De forskellige fravalgte teknologier beskrives ikke så dybdegående, som de valgte teknologier, men de er taget med i afsnittet for at argumentere for, hvorfor de ikke blev implementeret i det færdige system. I løbet af kapitlet nævnes klient og server flere gange. Når klient nævnes, menes der kode som eksekveres hos klienten. Det vil sige, at koden udføres lokalt hos klienten. Dette kan medføre, at kode udføres hurtigere, da der ikke skal tilgås data som ligger udenfor klienten. På klient-siden kan webapplikationen gøres interaktiv. Der kan sendes anmodninger til serveren og modtages data herfra eller der kan tilgås data som er gemt i browseren, også kendt som LocalStorage; lokalt gemt data [13]. Ved server-side håndteres ofte brugerinput og der kan tilgås data, som ligger gemt i databaser. Data bliver genereret ved serveren og overføres til klienten. På figur 9.1 ses de valgte teknologier, kategoriseret efter om de udføres hos klienten eller på serveren: Figur 9.1. Anvendte teknologier HTML & CSS HTML står for HyperText Markup Language, og benyttes til at beskrive og strukturere indhold på en hjemmeside [14]. HTML bruges i dette projekt til at strukturere indholet i brugergrænsefladen for Price Optimizer. Ved brug af HTML kan softwareudviklere blandt andet indsætte links til andre sider, billeder eller overskrifter på sider. Brugen af HTML er dog tæt sammenkoblet med CSS, hvilket bruges til at style brugergrænsefladen. CSS er et akronym for Cascading Style Sheets, og benyttes til at lave et brugerdefineret udseende af et dokument skrevet ved hjælp af et Markup Language [15]. I dette projekt benyttes CSS til at style HTML-elementer således at der fås en webapplikation hvor brugeroplevelsen er god. Der er i projektet brugt mange timer på at gøre webapplikationen overskuelig og æstetisk tiltalende, således at kravet om brugbarhed blev opfyldt på bedst mulig vis. HTML-elementer bliver stylet ved hjælp af CSS-regler. I disse regler bliver bestemte attributter indstillet og et HTML-element kan have mange CSS-regler, også nogen som indstiller de samme attributter til forskellige værdier. Det vil i dette tilfælde være den sidste indstilling der gør sig gældende. En CSS-regel for at indstille tekstfarven til rød kunne være: 65

74 .red-text { color: #ff0000; } Denne regel vil kunne tilføjes et HTML-element ved at tilføje HTML-attributten class= red-text. Flere regler kan angives i samme attribut ved at adskille dem med mellemrum. Det blev tidligt i projektet valgt, at CSS-frameworket Bootstrap skulle benyttes. Bootstrap tilbyder en række foruddefinerede CSS-regler så man sparer tid ved styling af HTMLelementer. Inden uddybningen af Bootstrap, introduceres først nogle andre grundlæggende elementer i opbygningen af en webapplikation. JavaScript, jquery, AJAX & JSON JavaScript er et scriptsprog, som benyttes til at gøre hjemmesider interaktive. Når JavaScript benyttes på en hjemmeside, kan helheden af hjemmesiden betegnes som en Webapplikation. JavaScript-kode køres på klientens computer via browseren [16]. Dette betyder, at der ikke nødvendigvis hentes data fra serveren, hver gang en JavaScriptfunktion udføres. Det betyder også, at de personer der bruger webapplikationen, skal have en browser, som understøtter JavaScript. JavaScript er dog understøttet af de fleste browsere, herunder Google Chrome, Safari, Internet Explorer og Mozilla Firefox. Udover at gøre hjemmesider interaktive, gør JavaScript det også muligt for udviklere at bygge bro mellem browseren og den platform, som scriptet udføres på. Det vil sige, at man ved at benytte JavaScript kan udføre opgaver, som kræver mere end blot at vise statisk information. Det kan for eksempel være, at indhente information om hvor brugeren befinder sig, eller opfange hvordan brugeren interagerer med webapplikationen. I implementeringen er jquery også benyttet. jquery er et framework, som bygger oven på JavaScript [17]. Det er det meste anvendte JavaScript-bibliotek der findes [18]. Det indeholder en række JavaScript-funktioner, som kan benyttes i projektet. Det er også med til at reducere antallet af linjer kode der skal skrives, da de indbyggede metoder findes i én jquery-fil, som kan kaldes fra forskellige steder i koden. Ved at benytte JavaScript kan der hentes og sendes indhold ind til og fra webapplikationen via en server, uden at skulle opdatere og genindlæse hele siden [19]. Disse kald betegnes som AJAX-kald, og udføres i baggrunden. AJAX er et akronym for Asynchronous JavaScript XML. AJAX kan bruges til at overføre data til og fra klienten; i dette tilfælde en webbrowser. Asynchronous, eller asynkront, betyder, at når en bruger interagerer med systemet, kan opdateringer foregå samtidig med, at bruger laver andre ting. AJAX kan også anvendes til at overføre små opdateringer til viewet eller modellen da hele websiden ikke overføres, kun den relevante data. AJAX er brugt flere steder i projektet, hvor brugeren interagerer med systemet. For eksempel når de ændrede priser gemmes til Magento. For at gøre brugeren bevidst om, at der sker noget i baggrunden, er det valgt at lægge et overlay på webapplikationen, mens AJAX-kald udføres. I stedet for at benytte XML til dataudveksling, er der i dette projekt benyttet JSON. JSON er et simpelt dataudvekslingsformat, der simplificerer udvekslingen af datastrukturer [20]. Syntaksen bygger på de samme principper som JavaScript, og understøtter de 66

75 simple JavaScript-typer, såsom heltal, tekststrenge, arrays og objekter [20]. Denne simple datastruktur er ideel til at sende et objekt, eller et array af objekter, fra server til klient. Der er blandt andet benyttet et JSON-objekt til at indhente aktuelle valutakurser. Bootstrap Bootstrap er et framework, der benyttes til at opbygge en brugergrænseflade til hjemmesider eller webapplikationer. For at benytte Bootstrap i projektet, skal man implementere en CSS- og JavaScript-fil, som er frit tilgængelig fra Bootstraps hjemmeside. Ved at implementere Bootstrap i projektet stilles der en række funktioner til rådighed, som kan benyttes via JavaScript-filen. Når der skal ændres i brugergrænsefladen kan man enten gøre det ved selv at skrive sin CSS-kode, eller man kan benytte Bootstraps implementering af CSS-regler. Med Bootstrap deles browseren op i en række felter, eller et såkaldt Grid. Grid-systemet består af 12 horisontale felter, og giver udvikleren mulighed for at kunne bestemme, hvor meget et enkelt element skal fylde, på trods af skærmstørrelsen. Ved at benytte Bootstrap er det trivielt at implementere et konsistent design af komponenter. Konsistens i designet er vigtig i forhold til brugeroplevelsen, som det blev beskrevet i afsnit 8.1. ASP.NET MVC & C# For at kunne udvikle en webapplikation, benyttes ASP.NET MVC, som er et gratis webframework udgivet af Microsoft. Med ASP.NET MVC kan der udvikles en webapplikation, udviklet i ASP.NET med et stort udvalg af Microsofts.NET-sprog. C# er det mest udbredte af disse sprog, hvilket der også er benyttet i dette projekt. ASP.NET MVC kan endvidere arbejde sammen med databaser, hvilket også har en stor indflydelse på projektet. Når der henvises til ASP.NET MVC tales der om arkitekturen, og det mønster, som webapplikationen er udviklet ud fra. Kildekoden er delt op i tre lag, for at skabe mindre afhængighed, hvorved dele af koden lettere kan udskiftes, se afsnit MVC står for Model-View-Controller [21], som blev beskrevet i forbindelse med arkitekturen tidligere i rapporten under afsnit I dette projekt benyttes der blandt andet en AccountController, som sørger for, at den data der indtastes af brugeren i forbindelse med login, bliver holdt op mod den data der findes i model-laget. Ud fra dette kan det håndteres, hvorvidt en person kan logge ind eller ej, og hvilke data der vises for brugeren. En af grundene til at ASP.NET MVC blev valgt var, at der via Visual Studio nemt kan opsættes en arkitektur ved at benytte en standard ASP.NET MVC-projektskabelon. Desuden stiller Microsoft kode til bruger-login til rådighed, således der ikke skal udvikles et helt nyt brugersystem til projektet. Dette gjorde, at der på sikker vis kan kontrolleres, om en bruger har adgang til systemet eller ej, hvilket også var et vigtigt krav fra afsnit 7.1 vedrørende kriterier. 67

76 Razortemplates (CSHTML) Razortemplates benyttes til at omdanne den kode, der befinder sig i.cshtml -filer til kode, som kan læses af browseren. Herved kan browseren vise koden fra præsentationslaget til brugeren, se afsnit Razortemplates betegnes som en view engine, hvor der både kan skrives med HTML, JavaScript og C#. Denne type af filer er standard view engine, når der udvikles i ASP.NET MVC. En af fordelene ved at benytte denne filtype til at fremstille brugergrænsefladen er, at det er tilladt at skrive i ren HTML-kode, og samtidig må der laves C#-kode ved at angive Desuden behøves C#-kode i denne filtype ikke eksplicit at afsluttes. I kodeeksempel 9.1 opstilles der en tabel med ID et CurrencyTable på linje 17. På linje 18 startes C#-kode ved og der kan derefter oprettes en ny liste i variablen currencieslisted. Dette mefører, at der dynamisk kan opstilles en tabel, i stedet for ved brug af HTML-elementer. Det ses også i eksemplet, at Razortemplates får explicit angivet, hvornår C#-kode ikke benyttes længere. Ved kontrol strukturer kan man starte for Inde i kontrolstrukturen er det muligt at blande HTML og C# ved at præfikse C# variabler På denne måde beregner Razortemplates hvornår HTML-koden starter igen efter en C# variable er blevet skrevet ud. Kodeeksempel 9.1. Eksempel på C# kode i.cshtml-fil 17 <table id=" CurrencyTable "> 19 var currencieslisted = new List<s t r i n g >() ; 20 } Datatables & Datatables Editor Datatables er et plugin til jquery-frameworket [22]. Visning af meget data i brugergrænsefladen er en stor del af dette projekt, og derfor skal der udarbejdes en måde at vise store datamængder på. Valget for at opstille data i en tabel frem for andre alternativer blev truffet ud fra samtale med Tonny Andersen, hvilket der kan læses mere om under 1. Iteration i kapitel 11. Opstillingen af en tabel i en webapplikation kunne have været lavet i HTML, men det blev i gruppen vedtaget at benytte Datatables til generering af tabellen, da det muliggør at indhente kompleks data til tabellen med få jquery-kald. Det er dog ikke tilstrækkeligt kun at kunne indhente data i dette projekt; der skal også kunne ændres på dataen. Til dette benyttes Datatables Editor. Ved at benytte Datatables Editor kan der ændres på specifik data hentet ind Datatabels. Med Datatables kunne der hurtigt arbejdes med at få vist data i projektet, dog kostede Datatables Editor EUR102.00, men det blev valgt at købe denne udvidelse. En fordel ved at benytte Datatables er, at der kan indhentes data ved hjælp af AJAX-kald. På figur 9.2 ses et eksempel på en tabel genereret af Datatables. Ved at benytte Datatables kan der hurtigt implementeres funktioner med jquery. For eksempel ønskede Tonny Andersen, at han let kunne finde produkter i tabellen. Den orange boks på figur 9.2 viser et søgefelt, hvor der i real-tid søges i tabellen, når der skrives noget specifikt i søgefeltet. I den røde firkant vises, at brugeren har mulighed for selv at bestemme, hvor mange produkter der skal være i tabellen, se figur 9.2. Firkanten markeret med lilla, figur 9.2, er overskrifter for hver kolonne. 68

77 Ved at benytte Datatables kan der ved blot én linje kode implementeres en sorteringsfunktion. Som det ses er der under Name sorteret efter alfabetisk rækkefølge, således at navne med a står først. Den gule firkant på figur 9.2 viser et felt, hvor der kan ændres på den indtastede værdi, ved at benytte Datatables Editor udvidelsen. Den blå firkant indikerer, at der findes flere sider med data i tabellen, og ved at klikke på Next eller på tallene kan andre sider vises. Figur 9.2. Introduktion til Datatables - modiciferet. Originalen findes her [22] Web API Web API er et framework udviklet af Microsoft [23]. Det deler mange konventioner med ASP.NET MVC og implementeres på en lignende måde. Web API kan anvendes til at udvikle systemgrænseflader, og bliver anvendt i systemet til at stille produkter til rådighed for webapplikationen. Det bliver ligeledes brugt til at sende opdatering af produkter fra klienten til serveren. Web API er struktureret ligesom ASP.NET MVC, og har således også en model, controllere og views. Den deler modellen med webapplikationen. Web API har sin egen implementation af controllere, som kan sammenlignes med de controllere der bliver brugt i ASP.NET MVC. Viewet er i forbindelse med Web API det data der returneres til aktørerne der tilgår systemet. Denne data kan være i JSON-, XML- eller tekst-format. Google Analytics API Google Analytics indeholder data vedrørende brugeraktivitet på Tonny Andersens webshop i forskellige lande. For at have mulighed for at tilgå data fra Google Analytics, er der i projektforløbet blevet oprettet en konto, der overvåger Magento-webshoppen, som blev sat op i udviklingsmiljøet. Her kan der ses på historikken over personer, der har besøgt siden. I webapplikationen vil der ud fra denne historik blive lavet en statistisk graf, som 69

78 visualiserer besøg på hjemmesiden i en bestemt periode. Det blev vedtaget at medtage data fra Google Analytics, da det i fremtiden vil kunne give Tonny Andersen mulighed for at se statistikker over salg af produkter, via webapplikationen Price Optimizer. 9.2 Database Valget af database vil i dette afsnit blive gennemgået. De forskellige teknologier og deres fordele og ulemper vil blive klargjort og baggrunden for valget af teknologi vil blive belyst. Der kan i systemer være et behov for at kunne gemme data. Denne data vil typisk være systemets model. Hvis der opstår fejl, eller strømafbrydelse kan det være katastrofalt for et system hvis modellen går tabt. Derfor skal det overvejes hvilken teknologi der skal benyttes til persistent datalagring. Det vurderes i dette projekt, at det ikke er aktuelt at se på filer som en mulig løsning, da der udvikles en webapplikation. Det er på grund af dette,at der kun vil blive overvejet hvilken database-teknologi der skal benyttes, og ikke om en løsning med et fil-system ville være mere fordelagtigt. Valget stod mellem MS SQL og MongoDB, som er henholdsvis RDMS- og NoSQL-løsninger. Forskellene mellem disse vil blive forklaret senere i afsnittet. Overvejelserne stod mellem disse to da der findes bibliotekter til dem begge så de kan benyttes med ASP.NET MVC. Man kan således sige at valget i realiteten stod mellem den relationelle model og den objekt-orienterede model til datalagring RDMS RDMS står for Relational Database Management System. Databaser af denne type er baseret på den relationelle model [24]. Den oprindelige definition af en relationel database består af Codds 12 regler [25]. Reglerne blev ikke altid overholdt i de tidlige implementationer. Derfor er en relationel database i dag løst defineret som en database der som minimum: 1. Præsenterer data som relationer i tabelformat. 2. Gør det muligt at manipulere data i tabelformat. Da data bliver gemt i tabeller med relationer imellem rækkerne, skal man på forhånd fastlægge en struktur for databasen. Man skal således designe en tabelstruktur med hvilke kolonner der skal bruges og hvilken data der kan gemmes. Relationerne skal også fastlægges. Hvis der eksisterer en en-til-mange relation er det nok med en tabel til hver entitet. En entitet er en abstrakt betegnelse for eksempel en klasse i et system. Hvis relationen derimod er mange-til-mange er der brug for en tabel yderligere, med formålet at vise hvilke rækker der har en relation. Et eksempel på ovenstående principper angives ved en database med tre tabeller, navnligt tabel 9.1 som indeholder produkter, tabel 9.2 som indeholder produktdata samt tabel 9.3 der indeholder lande. Hver række i tabellerne har et unikt identifikationsnummer ved navn 70

79 Id. Relationerne rækkerne imellem er angivet ved at referere til rækkens Id. I tabellen med produktdata kan det ses at produktdataen med Id 1 og 2 hører til produktet med Id 1. Det ses også at de to produktdata-rækker hører til hvert deres land, Danmark og Sverige. Id Sku IndkøbsPris 1 PRDKT PRDKT PRDKT Tabel 9.1. Tabel med produkter Id ProduktId LandeId Pris Tabel 9.2. Tabel med produktdata Id Land 1 Danmark 2 Sverige Tabel 9.3. Tabel med lande Der er stor sandsynglighed for at man i et system har brug for at hente data der ligger i forskellige tabeller i databasen. Derfor vil man i de fleste relationelle databaser kunne lave forespørgsler i SQL (Structered Query Language). SQL muliggør forespørgsler der henter, sammensætter og returnerer data fra flere tabeller i en enkelt forespørgsel NoSQL NoSQL eller Not Only SQL er en nyere tilgang til databaser, som stemmer overens med tankegangen bag objekt-orienteret programmering. I stedet for at gemme data som relationer kan en NoSQL-løsning benytte forskellige datastrukturer som for eksempel keyvalue pair, graf eller dokumenter alt efter implementeringen. Dokumenter i denne database kan sammenlignes med objekterne i objekt-orienteret programmering. Da det er denne datastruktur der er mest relevant for systemet, vil den blive beskrevet i dybden fremfor de andre datastrukturer. Hvis det første produkt i eksemplet i afsnit skulle gemmes i en NoSQL database som et dokument kunne det se således ud i JSON-format: 71

80 1 { 2 " Id " : 1, 3 "Sku" : "PRDKT01", 4 " I n k o b s P r i s " : , 5 " ProduktData " : [ 6 { 7 "Land" : 1, 8 " P r i s " : }, 10 { 11 "Land" : 2, 12 " P r i s " : } 14 ] 15 } Kodeeksempel 9.2. Eksempel på et dokument i MongoDB Hvad der før var delt op i flere tabeller med indbyrdes relationer er nu samlet i et enkelt dokument, som kan sidestilles med et objekt i objekt-orienteret programmering. Man kunne for eksempel have en klasse Produkt med egenskaberne Id, Sku, IndkøbsPris og ProduktData. ProduktData-egenskaben kunne være en liste af ProduktData-objekter med egenskaberne Land og Pris. ProduktData-objekterne bliver gemt som et indlejret dokument i det overordnede Produkt-dokument Valg af database Valget af database stod mellem MS SQL og MongoDB. Først vil de to teknologier blive beskrevet kort, derefter vil argumentationen af valget blive belyst. MS SQL Microsoft SQL Server er Microsofts implementation af en relationel database. Det er denne database der følger med som standard i et ASP.NET MVC-projekt. MS SQL databaser skal have en fastlagt struktur for tabellerne så det vides hvordan og hvilke data der bliver gemt. Dette stemmer godt overens med vandfaldsmodellen, som tilgang til udvikling af et system. Ved vandfaldsmodellen er strukturen for systemet analyseret og fastlagt inden implementering. MongoDB MongoDB er udviklet af 10Gen som nu hedder MongoDB Inc. Navnet kommer af ordet humongous og databasen er udviklet i C++. MongoDB er en dokument-orienteret database der gemmer dokumenter i et udvidet JSON-format kaldet BSON. Dette format gør det muligt at gemme binær data som for eksempel filer i dokumenterne. [26] Det er ikke alle NoSQL-databaser der har behov for et fastlagt skema, altså en forudbestemt struktur for dataen. MongoDB er en af disse. Dokumenter i MongoDB bliver gemt i collections som kan sammenlignes med tabellerne i en relationel database. Strukturen for de enkelte dokumenter i en collection behøver ikke være den samme. Dette er især en fordel hvis man har et nedarvningshieraki og man vil gemme objekter af superklassen såvel som objekter af subklasserne. 72

81 Det vurderes at MongoDBs tilgang til NoSQL stemmer godt overens med den valgte iterative udviklingsmetode. Klasser vil derfor uden de store vanskeligheder kunne udvikle sig i takt med projektet, og uden alt for store anstrengelser i forbindelse med opdatering af koden, da objekter af den opdaterede klasse ville kunne gemmes direkte. Hvis vandfaldsmodellen var valgt som udviklingsmetode ville MS SQL-databasens begrænsning, i forbindelse med en forudbestemt struktur, ikke spille en lige så stor rolle. MongoDB ville stadig være et lige så oplagt bud hvis vandfaldsmodellen var valgt, og der måtte derfor afvejes andre kriterier for valg af database. 9.3 Opsummering De anvendte teknologier blev i dette kapitel belyst. Med forståelse for teknologierne, vil det i næste kapitel beskrives, hvordan teknologierne er benyttet. Der ses i det næste kapitel kode, som projektgruppen finder interessant at belyse. 73

82 Udvalgte elementer af implementeringen 10 I dette kapitel beskrives udvalgte dele af kildekoden. Kapitlet deles ind i tre overordnede emner for at øge overskueligheden af både koden og kapitlet. De tre emner relaterer sig til, hvordan der arbejdes med data i det implementerede system. Først beskrives det, hvordan der i systemet hentes data fra forskellige kilder. Derefter beskrives det, hvordan den indhentede data vises. Dette er et essentielt punkt for projektet, da formålet fra starten har været, at effektivisere prisstyring og tilbyde bedre visualisering af data, se afsnit 3.2. Under det sidste emne beskrives det, hvordan data der er blevet arbejdet med gemmes igen og opdateres i webshoppen. De benyttede kodeeksempler i kapitlet er det endelige slutresultat, og kapitlet er ikke blevet itererert over igennem alle iterationer. Det blev valgt at skrive kapitlet sent i projektet, for at undgå at ændre de beskrevne eksempler. Kommentarer i koden er fjernet, af hensyn til at skabe plads til at inkludere namespaces i kodeeksemplerne, således eksemplerne ses i kontekst Implementering af Database Der er mange måder at implementere persistent datalagring i et system. Afhængig af kravene kan man vælge mønstre som dependency injection eller abstrahere adgangen til databasen med et data access layer. Formålet med mønstre og abstraktioner er at skabe overskuelighed i koden samt mindske afhængigheder i systemet. Dette vil gøre det lettere at vedligeholde systemet, især for andre udviklere, der ikke har deltaget i udviklingsprocessen. Der er i dette projekt blevet lavet et data access layer (DAL), der fungerer som en systemgrænseflade til databasen. Der kan gøres brug af dependency injection når adgangen til databasen foregår igennem en enkelt klasse. Dependency injection ville frigøre de enkelte komponenter fra det ansvar at instantiere Dal-klassen samt den samme instans vil kunne benyttes i hele systemet, hvilket ville spare ressourcer. Denne frigørelse giver en fleksibel arkitektur, hvor man ville kunne skifte databaseteknologi uden at skulle ændre i alle kompontenter som har adgang til databasen. Dette er dog ikke blevet implementeret i nogen af iterationerne da det anses som usandsynligt at en anden databaseteknologi ønskes i fremtiden. Dette understøttes af at kriteriet flytbart i afsnit er vurderet som 74

83 irrelevant. I kodeeksempel 10.1 ses ICrud-interfacet. Dette interface sikrer at den konkrete Crud-klasse indeholder metoder til at gemme, slette, hente og opdatere objekter i databasen. Som det ses på linje 8, er interfacet generisk, med den begrænsning at den skal lukkes med en klasse der implementerer IMongoObject-interfacet. Den generiske tilgang er valgt da man således undgår at lave tilsvarende interfaces, samt konkrete klasser til hver modelklasse, der ønskes gemt i databasen. Kodeeksempel ICrud-interfacet 7 namespace SW3. Web. DAL { 8 p u b l i c i n t e r f a c e ICrud<T> where T : IMongoObject { 9 void Save ( T entity ) ; 10 void Delete ( T entity ) ; 11 T GetById ( s t r i n g id ) ; 12 void Update ( T entity ) ; 13 } 14 } IMongoObject-interfacet som ses i kodeeksempel 10.2 har til ansvar at sikre et objekt, som skal gemmes i databasen, har en Id-egenskab. Denne egenskab er af typen ObjectId som er en del af MongoDBs officielle C#-driver, som er et komponent der bruges til alt kontakt mellem systemet og MongoDB-serveren. ObjectId er en unik identifikation af det enkelte objekt i databasen. Det er et object på 12-bytes som består af [27]: 1. 4-byte værdi der repræsenterer sekunder siden Unix epoch (1. Januar 1970) bytes der repræsenterer den maskine der genererer id et bytes der repræsenterer id et på den proces der genererer id et. 4. En 3-bytes tæller som starter på en tilfældig værdi. Det 12-byte id kan repræsenteres som en streng som for eksempel 507f1f77bcf86cd Da de første 4-bytes af id et bliver brugt til at gemme antallet af sekunder siden Unix epoch, er det muligt at udlede fra id et hvornår objektet blev oprettet i databasen, og egenskaber på objekter som CreatedAt og CreationDate er derfor overflødige, medmindre et bestemt format eller datatype er påkrævet. 7 namespace SW3. Shared. Models { 8 p u b l i c i n t e r f a c e IMongoObject { 9 ObjectId Id { get ; set ; } 10 } 11 } Kodeeksempel IMongoObject-interfacet Implementationen af IMongoObject-interfacet ses i kodeeksempel Det er tiltænkt at alle klasser der gemmes objekter af i databasen skal nedarve fra MongoObject-klassen. Indtil videre er det kun det påkrævede ObjectId der nedarves, men ved at lægge fællestræk 75

84 for de klasser der persisteres i en superklasse, er det trivielt at tilføje flere fælles egenskaber for disse klasser. Det er valgt at implementere ObjectId et gennem IMongoObjectinterfacet da det muliggør brugen af type-restriktioner, der sikrer at det udlukkende er objekter af klasser, som har implementeret IMongoObject-interfacet der kan gemmes i databasen. Dette uddybes under gennemgangen af ICrud-interfacet. Restriktionen ville også kunne sættes på MongoObject-klassen og ImongoObject-interfacet ville således være overflødigt, medmindre der var brug for flere interfaces som sikrede at klasser, der nedarver fra MongoObject-klassen implementerer egenskaber man ønsker at sætte restriktioner op for. Kodeeksempel MongoObject-implementationen 7 namespace SW3. Shared. Models { 8 p u b l i c c l a s s MongoObject : IMongoObject { 9 [ BsonId ] 10 p u b l i c ObjectId Id { get ; set ; } 11 } 12 } ICrud-interfacet bliver implementeret som en konkret klasse i kodeeksempel Denne implementation benytter MongoDBs C#-driver i form af den private instansvariabel col. Denne variabel er af typen MongoCollection<T>. Denne generiske type bliver lukket med samme type som Crud<T>-klassen bliver lukket med. Grunden til denne struktur, er at dokumenter i MongoDB bliver gemt som collections, og i systemet er det bestemt at objekter af samme type bliver gemt i samme collection. Det bemærkes at Update()-metoden kaster en NotImplementedException. Dette er fordi den er tiltænkt en operation der kun opdaterer de dele af dokumentet, der er ændret. Save()-metoden overskriver derimod hele dokumentet med både nye og gamle værdier i databasen. En implementation af Update()-metoden er værd at overveje til en senere iteration. 76

85 Kodeeksempel Crud-implementationen 10 namespace SW3. Web. DAL { 11 p u b l i c c l a s s Crud<T> : ICrud<T> where T : IMongoObject { 12 p r i v a t e MongoCollection<T> col ; p u b l i c Crud ( MongoCollection<T> col ) { 15 t h i s. col = col ; 16 } p u b l i c v i r t u a l void Save ( T entity ) { 19 var result = col. Save ( 20 entity, 21 new MongoInsertOptions { 22 WriteConcern = WriteConcern. Acknowledged 23 }) ; i f (! result. Ok ) { 26 // throw e x c e p t i o n 27 } 28 } p u b l i c v i r t u a l void Delete ( T entity ) { 31 var result = col. Remove ( 32 Query<T>.EQ ( e => e. Id, 33 entity. Id ), 34 RemoveFlags. None, 35 WriteConcern. Acknowledged ) ; i f (! result. Ok ) { 38 // throw e x c e p t i o n 39 } 40 } p u b l i c v i r t u a l T GetById ( s t r i n g id ) { 43 var entityquery = Query<T>.EQ ( e => e. Id, new ObjectId ( id ) ) ; 44 r e t u r n col. FindOne ( entityquery ) ; 45 } p u b l i c v i r t u a l void Update ( T entity ) { 48 throw new NotImplementedException ( ) ; 49 } p u b l i c v i r t u a l IEnumerable<T> GetAll ( ) { 52 r e t u r n col. FindAll ( ). AsEnumerable ( ) ; 53 } 54 } 55 } Selve systemgrænsefladen der tillader at gemme, hente, opdatere og slette data bliver implementeret i Dal-klassen i kodeeksempel Denne klasse stiller Crud-klassen til rådighed for hvert objekt der skal gemmes i databasen. Derudover gør den det muligt at få adgang til de enkelte collections hvor objekterne bliver gemt. Denne adgang er tilgængelig for at muliggøre at sende bulk-operationer til databasen. Bulk-operationer bruges for at optimere ydelsen, når der skal udføres operationer på mange dokumenter af gangen, se afsnit På linje 29 bliver en metode defineret, som gør det muligt at få adgang til den collection som indeholder dokumenter af typen Product. Denne collection bliver brugt til at gemme data omkring produkthistorik. Det er nødvendigt med sådan en metode da de historiske Product-dokumenter ellers ville blive gemt i Products-collectionen. 77

86 Kodeeksempel Dal-klassen 8 namespace SW3. Web. DAL { 9 p u b l i c c l a s s Dal { 10 p r i v a t e s t r i n g dbname = "SW3" ; 11 p r i v a t e s t r i n g connectionstring = " S e r v e r=alex f r i e. dk : " ; 12 p r i v a t e MongoDatabase db ; p u b l i c Dal ( ) { 15 var mongoclient = new MongoClient ( connectionstring ) ; 16 var mongoserver = mongoclient. GetServer ( ) ; db = mongoserver. GetDatabase ( dbname ) ; 19 } p u b l i c Crud<T> Crud<T >() where T : IMongoObject { 22 r e t u r n new Crud<T>(Collection<T >() ) ; 23 } p u b l i c MongoCollection<T> Collection<T >() where T : IMongoObject { 26 r e t u r n db. GetCollection<T>( t y p e o f ( T ). Name + " s " ) ; 27 } p u b l i c MongoCollection<Product> HistoryCollection ( ) { 30 r e t u r n db. GetCollection<Product >(" ProductHistory " ) ; 31 } 32 } 33 } 10.2 Hent data Et af de vigtige aspekter i forbindelse med implementering af systemet er, at sikre at data, der er tilgængelig i systemet, stemmer overens med informationerne i Tonny Andersens webshop og dens tilkoblede lande. Dette understreges af at pålidelighed er sat som et vigtigt kriterium i afsnit 7.1. Da det ikke skal være muligt at slette eller tilføje produkter i systemet, gøres dette manuelt i Magentos eget system. Laves der eksterne ændringer i Magentos system, vil data tilgængelig i webshoppen og Price Optimizer ikke stemme overens, hvorfor kriteriet vedrørende pålidelighed ikke vil være opfyldt. For at afhjælpe dette implementeres en sykroniseringsfunktion der synkroniserer data fra Magento-webshoppen og dertilhørende lande Magentos opbygning For at kunne implementere en synkroniseringsfunktion er det nødvendigt at have en forståelse for Magentos opbygning og struktur. I Magento er størstedelen af data, indstillinger samt opsætninger gemt i en database der er opsat sammen med Magentoinstallationen. Dette betyder at alt tilgængeligt data i Magento vedrørende for eksempel webshoppen, lande, produkter og produktdata ligger i denne database, som Magento selv opsætter i forbindelse med installation. Databasen skal være en MySQL-database for at være kompatibel med Magento [28]. MySQL-databaser er relationelle og minder derfor om en MS SQL-database, se afsnit Price Optimizer anvender, i forbindelse med udviklingen, MySQL-databasen it_struer_dk_db2, hvilken er lokaliseret på projektgruppens Magento-server. Udviklingsserveren er et Unoeuro webhotel [29] hvor testudgaven af Magento-webshoppen også er installeret. Denne kan 78

87 findes på domænet it-struer.dk/magento/. Magento-databasen it_struer_dk_db2 indeholder 331 forskellige tabeller oprettet af Magento. Databasens opbygning er kompleks og omfattende, hvilket kan ses hvis man betragter diagrammet over databasen på figur Da diagrammet indeholder mange elementer, er det ikke muligt at se indholdet i hver enkelt tabel, men det giver en god forståelse for databasens kompleksitet. Der kan ses en større udgave af diagrammet i bilag D.7. Figur Digram over Magentos database. Se stort billed i bilag D.7. Problemstillingen vedrørerende hentning af data fra Magento er vigtigt for Price Optimizer, af flere årsager. En af klientens problemstillinger er at det er besværligt og tidskrævende at ændre priser i Magento. Derfor er det nødvendigt at trække den relevante data ud fra Magento og tilbyde et mere overskueligt og brugerbart pristyringsværktøj, i henhold til problemformuleringen i afsnit 3.1. Derudover er kriteriet intergrerbart i afsnit 7.1 vurderet som vigtigt, hvorfor Price Optimizer skal kunne intergreres med andre systemer, som i dette tilfælde er Magento. Magento har et API, som er blevet fravalgt. Begrundelsen for fravalget af API et kan læses under del V Iterationer i afsnit Da det blev valgt ikke at anvende Magentos API til at hente data med, blev det i stedet nødvendigt at hente alt data direkte fra Magentos bagvedliggende MySQL-database. Den ønskede data fra Magentos database blev i stedet hentet direkte fra de relevante tabeller i databasen ved hjælp af MySQL-queries. For at kunne hente data direkte fra tabellerne, er det derfor nødvendigt at vide hvor i databasen den ønskede data er placeret. Lokaliseringen af disse tabeller krævede en del research og vidensdeling med klienten Tonny Andersen. Alt relevant data blev dog lokaliseret og en 79

88 oversigt over anvendte tabeller, samt hvilke data de indeholder, kan ses på tabel Hvordan disse data bliver hentet og anvendt vil blive beskrevet i følgende afsnit. Tabelnavn catalog_product_entity catalog_product_entity_ decimal catalog_product_entity_ int catalog_product_entity_ varchar eav_attribute_option_ value cataloginventory_stock_ item core_store core_config_data Produktid SKU Produkttype Produktid Tilbudspris Produkttype Produktid Produkttype Produktid Producent-id Producentnavn Produktid Land-id Landenavn Scope Indstillingssti Data Produkttype Exclude indstilling Land-id Pris Indkøbspris Land-id Producent-id Land-id Produktnavn Land-id Lagerantal Hjemmeside-id Scope-id Valuta Tabel Anvendte tabeller fra Magentos database og hvilke data de indeholder 80

89 Synkronisering med webshoppen De vigtigste elementer af processen vedrørende synkronisering af data fra en webshop til Price Optimizer, vil blive beskrevet i dette afsnit. Synkroniseringsprocessen er blevet implementeret med respekt for designet af arkitekturen og dens komponenter, hvilket er uddybet nærmere i afsnit 7.2. I afsnit 7.2 blev der analyseret på forskellige arkitekturmønstre, hvilket resulterede i et endeligt klassediagram for komponentarkitekturen, hvilken kan ses på figur 7.5. Der bliver benyttet en lagdelt arkitektur med en lukket-streng arkitektur, se afsnit 7.2.1, og anvendt et passivt MVC-mønster, se afsnit Dette resulterede i en implementation af synkroniseringsprocessen på en måde hvilken er illustreret på flowchartet på figur Som det kan ses på figuren er den lagdelte lukkede-strengarkitektur overholdt.index.cshtml repræsenterer view-delen, og er adskilt fra modellaget, angivet som nr. 5 på figuren, af en controller. Controlleren ProductsController, som har nr. 2 på figuren, adskiller dermed lagene og har en grænseflade op til viewet og en ned til modellaget. Der er ikke nogle grænseflader mellem viewet og modellen af respekt for den lagdelte lukkede-streng-arkitektur. Derudover er det passive MVCmønster også implementeret, da det er controlleren der opdaterer modellen. Klientserver-mønstret, se afsnit 7.4, er også anvendt, da det er klienten der er den aktive og sender en forespørgsel til serveren ved aktiveringen af synkroniseringsprocessen i brugergrænsefladen. Endelig er tre-lags-arkitekturen, se afsnit 7.2.3, også implementeret, da der forefindes et præsentationslag, nr. 1, applikationslag, nr. 2, 3, 4 og 6 og et databaselag, som kan ses ved nr. 5. De mere specifikke dele af synkroniseringsprocessen og dens implementering, med udelukkende fokus på de vigtigste elementer, vil herunder gennemgås. Det første der sker er, at synkroniseringsprocessen bliver aktiveret af brugeren ved at brugeren klikker på knappen Sync from Magento, hvilken kan ses på figur Dette svarer til nr. 1 på flowchartet på figur Der anvendes et AJAX-kald til et API-endpoint i controlleren ProductsController, hvilket er nr. 2 på flowchartet, som vil beskrives i følgende afsnit. MagentoDal-klassen API-endpointet Api/Products/Sync, der bliver kaldt i controlleren, kalder som det første metoden GetProducts() i MagentoDal-klassen, hvilket svarer til overgangen fra nr. 2 til 3 på flowchartet. MagentoDal-klassen fungerer som et data access layer mellem Price Optimizer og Magentos database. Det er dermed i denne klasse at alt data omkring produkter, produktdata og lande hentes direkte fra Magento-databasen. Dette foregår ved hjælp af MySQL-queries, som angiver hvad der skal hentes fra de forskellige tabeller, som kan ses på tabel Metoden der anvendes til at hente data ændrede sig flere gange igennem projektforløbet, og viste sig at have en omfattende effekt på effektiviteten af datahentningen. Dette forklares yderligere i afsnit I den endelige implementering anvendes der en MySQL-datareader, som følger en foruddefineret query-streng, der angiver hvilke data der skal læses fra databasen, se tabel Betragtes kodeeksempel 10.6, ses det hvorledes datareaderen er indsat som betingelse for while-løkkens udførelse på linje 67, hvilket betyder at løkken udføres så længe der er data at læse. 81

90 Figur Flowchart over synkroniseringsprocessen Figur Sync from Magento Det første der sker i while-løkken er, at der på linje 68 anvendes et lambda-udtryk til at kontrollere, hvorvidt der allerede findes et produkt i den lokale liste af produkter kaldet products med et produktid der svarer til det id, der bliver læst fra Magento-databasen. Hvis det ikke er tilfældet, opfyldes betingelsen for if-sætningen på linje 70, hvorefter 82

91 der instantieres et nyt produkt. Herefter gemmes data omkring produktet på linje 72 til 78. Data for indkøbsprisen er et specialtilfælde, da denne kan være sat til værdien null i Magento-databasen. En MySQL-datareader kan ikke læse værdien null, og der implementeres derfor en if-sætning på linje 80, kodeeksempel 10.6, der medfører at data omkring indkøbsprisen kun bliver læst hvis dataet ikke er null. Som det sidste i ifsætningen, der starter på linje 70, tilføjes det nyligt instantierede produkt til listen af lokale produkter på linje 83. While-løkken sørger dermed for at data der er unikt for et produkt bliver hentet fra databasen og gemt i produkt-objektet. Kodeeksempel Oprettelse af produkter med data fra Magentodatabasen 62 namespace SW3. Web. DAL { 63 p u b l i c c l a s s MagentoDal : IDisposable { 64 [... ] 65 p u b l i c List<Product> GetProducts ( ) { 66 [... ] 67 w h i l e ( datareader. Read ( ) ) { 68 var product = products. Where ( p => p. MagentoProductId == datareader. GetInt32 ( " e n t i t y _ i d " ) ). FirstOrDefault ( ) ; i f ( product == n u l l ) { 71 product = new Product ( ) { 72 MagentoProductId = datareader. GetInt32 ( " e n t i t y _ i d " ), 73 Sku = datareader. GetInt32 ( " sku " ), 74 Exclude = datareader. GetBoolean ( " exclude_from_supply_needs " ), 75 PriceComparisonProduct = datareader. GetBoolean ( " exclude_from_supply_needs " ), 76 FollowSupplier = datareader. GetBoolean ( " exclude_from_supply_needs " ), 77 Manufacturer = datareader. GetString ( " manufacturername " ), 78 Stock = datareader. GetInt32 ( " qty " ) 79 } ; 80 i f (! datareader. IsDBNull ( datareader. GetOrdinal ( " value " ) ) ) { 81 product. CostPrice = datareader. GetDecimal ( " value " ) ; 82 } 83 products. Add ( product ) ; 84 } 85 } 86 [... ] 87 } 88 [... ] 89 } 90 } Efter betingelsen for while-løkkens udførelse ikke længere er opfyldt, kaldes en privat metode fra GetProducts()-metoden i MagentoDal-klassen, der anvender de samme implementeringsprincipper som ovenstående eksempel. Den private metode returnerer en liste med data der er unikke for produkterne i de forskellige lande, altså de forskellige produktdata. Disse bliver derefter sammenflettet med produkterne baseret på et match mellem produkternes og produktdataenes produktid, som begge er navngivet MagentoProductId, hvilket kan ses på linje 103 i kodeeksempel Findes der et match gemmes produktdata-objektet i et dictionary på produkt-objektet med lande-id et som key. Dette sker på linje 106. Alt data omkring produkterne og webshoppens lande er dermed hentet fra Magentos database og disse returneres til ProductsController-klassen, hvilket svarer til pilen fra nr. 3 til 2 på figur

92 Kodeeksempel Sammenfletning af produkter og produktdata 97 namespace SW3. Web. DAL { 98 p u b l i c c l a s s MagentoDal : IDisposable { 99 [... ] 100 p u b l i c List<Product> GetProducts ( ) { 101 [... ] 102 f o r e a c h ( ProductData pd i n productdatas ) { 103 var product = products. Where ( p => p. MagentoProductId == pd. MagentoProductId ). FirstOrDefault ( ) ; i f ( product!= n u l l ) { 106 product. ProductData [ pd. MagentoStoreId ] = pd ; 107 } 108 } 109 [... ] 110 } 111 [... ] 112 } 113 } ProductsController-klassen Efter at have fået alt data omkring produkter og lande fra Magentos database, er udgangspunktet igen nr. 2 på flowchartet på figur Der sker herefter flere ting i ProductsController-klassen, hvoraf den første er at der hentes information omkring brugeren der er logget ind på Price Optimizer, ved hjælp af Microsofts ASP.NET MVCframeworket. Brugerens identitet anvendes til at hente webshoppen tilkoblet brugeren fra den lokale MongoDB-database. Dette sker gennem et data acces layer, hvilket fungerer som bindeled mellem applikationslaget og databaselaget i forhold til en Trelags komponentarkitektur, se afsnit Brugerens webshop og den hentede data fra Magentos database skal kobles sammen, hvor udførelsen af dette kan ses i kodeeksempel Det ses ud fra attributten på linje 91 i kodeeksemplet at API-endpointet der benytter Sync()-metoden er Api/Products/Sync. 84

93 Kodeeksempel Produkter og produktdata knyttes til webshoppen 86 namespace SW3. Controllers. Api { 87 p u b l i c c l a s s ProductsController : ApiController { 88 [... ] 89 [ Authorize ] 90 [ ResponseType ( t y p e o f ( IEnumerable<Product >)) ] 91 [ Route ( "Api/ Products /Sync" ) ] 92 [ HttpGet ] 93 p u b l i c IHttpActionResult Sync ( ) { 94 [... ] 95 var userid = User. Identity. GetUserId ( ) ; 96 var webshop = dal. Collection<Webshop >(). FindOne ( Query. EQ ( " OwnerId", new ObjectId ( userid ) ) ) ; 97 [... ] 98 f o r e a c h ( var p i n magentoproducts ) { 99 f o r e a c h ( var pd i n p. ProductData ) { 100 i f (! webshop. Stores. ContainsKey ( pd. Value. MagentoStoreId ) ) { 101 webshop. Stores. Add ( pd. Key, pd. Value. StoreName ) ; 102 } 103 i f (! webshop. Currencies. ContainsKey ( pd. Value. MagentoStoreId ) ) { 104 webshop. Currencies. Add ( pd. Key, new Currency ( ) { Symbol = pd. Value. CurrencySymbol, Factor = 1. 0 }) ; 105 currencylist. Add ( webshop. Currencies [ 0 ]. Symbol + "_" + pd. Value. CurrencySymbol ) ; 106 } e l s e { 107 i f (! currencylist. Contains ( webshop. Currencies [ 0 ]. Symbol + "_" + webshop. Currencies [ pd. Value. MagentoStoreId ]. Symbol ) ) { 108 currencylist. Add ( webshop. Currencies [ 0 ]. Symbol + "_" + webshop. Currencies [ pd. Value. MagentoStoreId ]. Symbol ) ; 109 } 110 } 111 } 112 p. WebshopId = webshop. Id ; 113 } 114 [... ] 115 } 116 [... ] 117 } 118 } Sammenkoblingen sker ved hjælp af to foreach-løkker, henholdsvis linje 98 og 99. Her itereres der over alle produkter og for hvert produkt itereres der over produktets produktdata. Hensigten med dette er at tilknytte produkterne samt produktdata til webshoppen. Første del i forbindelse med tilknytningen er if-sætningen på linje 100, som kontrollerer hvorvidt et dictionary af lande i Webshop-objektet, kaldet Stores, indeholder en key svarende til lande-id et på det produktdata der bliver itereret over. Er dette ikke tilfældet gemmes landets id og navn fra produktdata i Stores på Webshopobjektet, hvilket sker på linje 101. Herefter bruges samme princip i forbindelse med et dictionary af valutaer på Webshop-objektet kaldet Currencies. Forskellen er her, at Currencies værdi er et objekt af typen Currency, hvorfor der på linje 104 instantieres et nyt Currency-objekt der tilskrives værdien i Currencies. I Currency-objektet gemmes en valuta samt en faktor for denne valuta. Som det sidste i den yderste foreach-løkke, linje 112, gemmes webshoppens id på produktobjektet gennem egenskaben WebshopId hvormed produkt og webshop er knyttet sammen. 85

94 Sideløbende med sammenfletningen af data mellem produkterne og webshoppen kontrolleres der hvorvidt den lokale liste currencylist indeholder data omkring valutaer og lande, som er tilgængelige i de forskellige produktdata. Gør den ikke dette bliver det tilføjet til listen som strenge med formen DefaultCurrency_StoreCurrency, hvilket sker på linje 105 og 108 i kodeeksempel Grunden til dette er, at strengene i listen currencylist senere bliver anvendt til at omregne de forskellige landes valutaer til webshoppens standardvaluta. DefaultCurrency svarer altså til webshoppens standardvaluta, mens StoreCurrency svarer til valutaen anvendt i et specifikt land. Strengens form er defineret således som følge af, at der anvendes The Free Currency Converter API [30] til at omregne valutaer. Selve omregningen sker i klassen CurrencyDal. CurrencyDal-klassen Omregningen af valutaerne sker i forbindelse med udregningen af dækningsbidraget for produkterne i alle deres tilknyttede lande. Metoden til udregningen af dækningsbidraget, kaldet GetContributionMargin(), ligger i CurrencyDal-klassen, men kaldes fra ProductsController. Det er illustreret ved overgangen fra nr. 2 til nr. 4 på flowchartet på figur Metoden GetContributionMargin() kan ses i kodeeksempel Før metoden kaldes er det nødvendigt at instantiere et nyt CurrencyDal-objekt i ProductsControllerklassen. Det er her den lokale liste currencylist bliver aktuel, da den anvendes som inputparameter ved instantieringen af CurrencyDal-objektet hvis contructor netop tager en liste af strings som inputparameter. CurrencyDal s contructor kan ses fra linje 87 til 90 i kodeeksempel

95 Kodeeksempel Udregning af dækningsbidraget 83 namespace SW3. Shared. Models { 84 p u b l i c c l a s s CurrencyDal { 85 p u b l i c Dictionary<s t r i n g, decimal> CurrencyValues { get ; set ; } p u b l i c CurrencyDal ( List<s t r i n g > inputlist ) { 88 CurrencyValues = new Dictionary<s t r i n g, decimal >() ; 89 GetCurrency ( inputlist ) ; 90 } [... ] p u b l i c decimal GetContributionMargin ( s t r i n g currencysymbol, s t r i n g defaultcurrency, decimal price, decimal specialprice, decimal costprice ) { 95 decimal contributionmargin = 0 ; 96 decimal convertedprice ; i f ( price <= specialprice specialprice == 0 specialprice == n u l l ) { 99 convertedprice = price / CurrencyValues [ defaultcurrency + "_" + currencysymbol ] ; 100 } e l s e { 101 convertedprice = specialprice / CurrencyValues [ defaultcurrency + "_" + currencysymbol ] ; 102 } 103 i f ( costprice!= n u l l && costprice!= 0 && convertedprice!= n u l l && convertedprice!= 0) { 104 contributionmargin = convertedprice / costprice ; 105 } contributionmargin = Math. Truncate ( contributionmargin 10000) / ; r e t u r n contributionmargin ; 110 } 111 } 112 } Denne liste bliver anvendt til at omregne valutaer ved hjælp af The Free Currency Converter API [30]. De omregnede valutaer bliver gemt i et dictionary ved navn CurrencyValues, som kan ses på linje 85. Metoden GetContributionMargin(), der udføres på linje 94 til 110, tager fem inputparametre og returnerer en decimal i form af det udregnede dækningsbidrag. De fem inputparametre er henholdsvis landets anvendte valuta, standardvalutaen, produktets pris i det givne land, produktet tilbudspris i det givne land og produktets indkøbspris. I forbindelse med udregningen kontrolleres der indledningsvis for, om det er prisen eller tilbudsprisen der er mindst i form af if-sætningen på linje 98. Derudover sikrer den at tilbudsprisen ikke er 0 eller null, da dette ofte er tilfældet hvis produktet ikke er på tilbud. Er prisen lavest opfyldes if-sætningens betingelse og prisen konverteres til standardvalutaen på linje 99. Her anvendes de omregnede valutaer i CurrencyValues, da dækningsbidraget altid udregnes med en pris angivet i webshoppens standardvaluta. Dette skyldes at produktets indkøbspris altid er angivet i standardvalutaen, da Sinful kun har ét lager og dermed kun indkøbspriser i én valuta. Er tilbudsprisen lavest, men ikke 0 eller null, konverteres denne i stedet på linje

96 På linje 103 er der implementeret en ny if-sætning, som sikrer at hverken indkøbsprisen eller den omregnede pris er 0 eller null da det i den efterfølgende udregning ville resultere i en DivideByZeroException [31]. Er det ikke tilfældet udregnes dækningsbidraget på linje 107 og trunkerer til fire tal efter kommaet for at sikre mod overflow. Til sidst returneres det udregnede dækningsbidrag på linje 109, hvilet svarer til en overgang fra nr. 4 til 2 på flowchartet på figur Metoden afsluttes De fleste dele af synkroniseringsprocessen er nu udført. Inden synkroniseringsprocessen afsluttes sker der dog yderligere to ting. Det første er at der bliver udført en simpel sortering på det dictionary, kaldet Stores, som indeholder de forskellige lande tilkoblet webshoppen. Dette gøres da rækkefølgen af menuboxene for landende i Price Optimizers brugergrænseflade bliver defineret ud fra i hvilken rækkefølge de optræder i Stores. I henhold til efterspørgsel fra klienten Tonny Andersen sorteres landende derfor efter hvilken rækkefølge de er tilføjet til webshoppen. Det andet der sker er, at de gamle produkter der var i den lokale MongoDB-database før synkroniseringen bliver flyttet til historikken og de nye opdaterede produkter gemmes i den selvsamme database. Dette er markeret ved overgange fra nr. 2 til 5 på figur Derefter sendes en status tilbage til præsentationslaget om hvorvidt synkroniseringen var en succes eller ej, hvorefter synkroniseringen er afsluttet. Dette er overgangen fra nr. 5 til 6 på figur Synkroniseringsprocessen er dermed afsluttet og produkterne tilkoblet brugerens Magentoinstallation er dermed repræsenteret i Price Optimizers brugergrænseflade Visning og manipulation af data Price Optimizers hovedformål er at tilbyde effektivt og brugbart visning og manipulation af data, hvilket er understøttet af de opstillede kriterier i afsnit 7.1. Dermed er håndteringen og formidlingen af data vedrørende produkter og lande i webshoppen en omfattende del af systemet. Ud fra et implementerings- og kodemæssigt perspektiv er visning og manipulation af data fra webshoppen forholdsvis triviel. Det er i stedet mere relevant i forhold til et designmæssigt perspektiv, hvor dette er beskrevet yderligere i afsnit 8.1. I dette afsnit vil der gennemgås et enkelt element af datavisualiserings-implementationen. Dette element omhandler hvorledes DataTables, se afsnit 9.1, visualiserer systemets tilgængelige data Datavisualisering ved hjælp af DataTables For at DataTables kan vise data skal den først have konkret data, der kan visualiseres. Data fra webshoppen tilkoblet til Price Optimizer hentes fra Magento-databasen, hvilket beskrives i afsnit 10.2, og gemmes i systemets lokale database. DataTables anvender derfor data fra systemet lokale database, hvilket hentes gennem APIendpointet Api/Products/GetAll i Price Optimizers controller. Dette sker ved hjælp af et AJAX-kald, som kan ses på linje 420 i kodeeksempel API-endpointet Api/Products/GetAll anvender det implementerede data acces layer i, form af Dal- 88

97 klassen, og henter samt returnerer en collection indeholdende alle produkterne fra systemets database. Efter at dataen er hentet påbegyndes opsætningen af DataTables på linje 423, hvilket kan ses i kodeeksempel Her er det defineret hvor mange rækker der skal vises som standard, hvilket er sat til 100 rækker. Linje 424 definerer standarden for hvorledes dataen skal sorteres. Dataen sorteres efter kolonne 2, hvilket er produktets id og defineret på linje 433, i stigende rækkefølge. Kolonne 2 er produktets id, da kolonnerne er 0-indexeret og der findes to kolonner før produktid et, henholdsvis på linje 426 og 427. Kolonnen på linje 426 er en skjult kolonne, som derfor ikke bliver vist i brugergrænsefladen, hvilket anvendes til at registrere hvorvidt en række er blevet ændret. Den anden kolonne, på linje 427, er ligeledes en skjult kolonne, der anvendes til at styre hvorvidt en Fold ud række, se afsnit 8.1.1, er aktiveret. Fra linje 433 til 447 i kodeeksempel defineres data, som skal vises i tabellen i Price Optimizers brugergrænseflade. Her angiver data hvilken data fra produktobjektet, hentet via API-endpointet Api/Products/GetAll, der skal vises. Efterfølgende angives hvilket navn kolonnen tildeles ved hjælp af title. Sidst i kolonnes opsætning angives type, hvilken er defineret som natural. Dette implementerer en JavaScriptfunktion, som definerer hvilke kriterier kolonnen skal sorteres efter. Der er i den forbindelse implementeret en redigeret udgave af funktionen således tal bliver vægtet højere end bogstaver og tegn. Da for eksempel produktnavne kan indeholde tal var en sådan vægtning mest hensigtsmæssig. Udover de ovenstående indstillinger for kolonnerne indeholder kolonnerne også en definition på den en render-funktion. Disse render-funktioner er implementeret i forskellige udgaver og bestemmer hvorledes kolonnens data skal renderes, eller vises. I forbindelse med kolonnen Exclude på linje 437 i kodeeksempel bliver render-funktionen booleanrender anvendt. Funktionen sørger for at Exclude-indstillingen, som er angivet om 1 eller 0 i produktobjektet, bliver vist som henholdsvis Yes eller No i tabellen i brugergrænsefladen. På linje 442, se kodeeksempel 10.10, udnyttes view engine Razortemplates, se afsnit 9.1, således at der ved hjælp kan anvendes C#-kode til at iterere over produktdata tilkoblet produktobjektet. Dermed er alle kolonner der bliver vist i brugergrænsefladens tabel opsat. Efter at DataTables har hentet alt data gennem API-endpointet Api/Products/GetAll og opsat dette bliver der afslutningsvis aktiveret koden på linje 451 i kodeeksempel På denne linje kaldes funktionen generatecolmenu(), hvilken genererer venstre-menuen, se afsnit 8.1.1, i brugergrænsefladen. 89

98 Kodeeksempel Datavisualisering ved hjælp af DataTables 414 <script> 415 $ ( document ). ready ( function ( ) { 416 [... ] 417 var count = 0 ; 418 var table = $ ( '#producttable ' ). DataTable ({ 419 " ajax " : { 420 url : "/ api / Products / GetAll ", 421 datasrc : "" 422 }, 423 " idisplaylength " : 100, 424 " o r d e r " : [ [ 2, " asc " ] ], 425 " columns " : [ 426 { " data " : " HiddenChanges ", " o r d e r a b l e " : f a l s e }, 427 { 428 " c l a s s " : ' d e t a i l s c o n t r o l ', 429 " o r d e r a b l e " : f a l s e, 430 " data " : n u l l, 431 " d e f a u l t C o n t e n t " : ' ' 432 }, 433 { " data " : " MagentoProductId ", " t i t l e " : " Product Id ", " type " : " n a t u r a l " }, 434 { " data " : "Sku", " t i t l e " : "SKU", render : render, " type " : " n a t u r a l " }, 435 { " data " : " CostPrice ", " t i t l e " : " Cost P r i c e ", render : pricerender ( 0, f a l s e ), " type " : " n a t u r a l " }, 436 { " data " : " Manufacturer ", " t i t l e " : " Manufacturer ", render : render, " type " : " n a t u r a l " }, 437 { " data " : " Exclude ", " t i t l e " : " Exclude ", render : booleanrender, " type " : " n a t u r a l " }, 438 { " data " : " PriceComparisonProduct ", " t i t l e " : " P r i c e Comparison ", render : booleanrender, " type " : " n a t u r a l " }, 439 { " data " : " F o l l o w S u p p l i e r ", " t i t l e " : " Follow S u p p l i e r ", render : booleanrender, " type " : " n a t u r a l " }, 440 { " data " : " Stock ", " t i t l e " : " Stock ", render : render, " type " : " n a t u r a l " } 441 //, placement i s important due to l o o p s. ( var s i n Model. StoreNames ) { 443 <text >, { " data " : " ProductData.@( s. Key ). Name", " t i t l e " : "@( s. Value ) Name", render : render }</text> 444 <text >, { " data " : " ProductData.@( s. Key ). P r i c e ", " t i t l e " : "@( s. Value ) P r i c e ", render : pricerender ( s. Key ), t r u e ), " type " : " n a t u r a l " }</text> 445 <text >, { " data " : " ProductData.@( s. Key ). S p e c i a l P r i c e ", " t i t l e " : s. Value ) S p e c i a l P r i c e ", render : pricerender ( s. Key ), t r u e ), " type " : " n a t u r a l " }</text> 446 <text >, { " data " : " ProductData.@( s. Key ). ConversionRate ", " t i t l e " : "@( s. Value ) Conversion Rate", render : render, " type " : " n a t u r a l " }</text> 447 <text >, { " data " : " ProductData.@( s. Key ). ContributionMargin ", " t i t l e " : "@( s. Value ) C o n t r i b u t i o n Margin", render : cmrender, " type " : " n a t u r a l " }</text> 448 } 449 ], 450 [... ] 451 " i n i t C o m p l e t e " : function ( ) { 452 generatecolmenu ( ) ; 453 } 454 }) ; 455 [... ] 456 }) ; 457 </script> 90

99 10.4 Gem data I afsnit 10.2 blev det beskrevet hvorledes synkronisering med en Magento-webshop til Price Optimizer følger MVC-mønstret. Synkroniseringsprocessen aktiveres af brugeren i viewdelen, laver et AJAX-kald til controlleren og henter og skriver data omkring produkterne og webshoppen i modellen. Der er dermed fastlagt hvorledes der hentes data og der ses i dette afsnit på processen vedrørende at gemme data. Denne proces følger ligeledes MVCmønstret. Når brugeren gemmer foretagede ændringer sker der fire forskellige delprocesser i gemtil-magento-processen; Produkthistorikken bliver opdateret, ændringerne bliver gemt i systemets database, ændringerne gemmes direkte i Magentos database og priserne bliver reindexeret i Magento. På figur 10.4 ses et flowchart af denne process. På kodeeksempel ses et udsnit af SaveToMagento()-metoden, som aktiveres af et AJAX-kald fra brugergrænsefladen. I kodeeksemplet er det af hensyn til overskueligeheden at der er udeladt kode. Både figuren samt kodeeksemplet vil blive forklaret nærmere i de næste afsnit. 91

100 Figur Gem-til-Magento-processen 92

101 Kodeeksempel Udsnit af SaveToMagento()-metoden 222 namespace SW3. Controllers. Api { 223 p u b l i c c l a s s ProductsController : ApiController { 224 [... ] 225 [ Authorize ] 226 [ Route ( "Api/ Products /SaveToMagento" ) ] 227 [ HttpPost ] 228 p u b l i c IHttpActionResult SaveToMagento ( JArray changedproducts ) { 229 var magentodal = new MagentoDal ( ) ; [... ] var historybulk = dal. HistoryCollection ( ). InitializeUnorderedBulkOperation ( ) ; f o r e a c h ( var cp i n changedproducts ) { 236 dynamic json = cp ; 237 var localproduct = dal. Collection<Product >(). FindOne ( Query. EQ ( " MagentoProductId ", ( i n t?) json. MagentoProductId ) ) ; historybulk. Insert ( localproduct. Clone ( ) ) ; var changedproductdata = json. ProductData as JObject ; 242 f o r e a c h ( var cpd i n changedproductdata ) { 243 i n t key = i n t. Parse ( cpd. Key ) ; 244 s t r i n g price = ( cpd. Value as dynamic ). Price. ToString ( ). Replace ( ', ', '. ' ) ; 245 [... ] 246 t r y { 247 decimal changedprice = decimal. Parse ( price, NumberStyles. AllowDecimalPoint NumberStyles. AllowThousands, CultureInfo. InvariantCulture ) ; 248 [... ] 249 i f ( changedprice!= localproduct. ProductData [ key ]. Price ) { 250 localproduct. ProductData [ key ]. Price = changedprice ; 251 magentodal. UpdatePrice ( localproduct. ProductData [ key ]. Price, key, localproduct. ProductData [ key ]. MagentoProductId ) ; 252 } 253 [... ] 254 } catch ( FormatException ) { // No product data f o r given key } 255 } 256 dal. Crud<Product >(). Save ( localproduct ) ; 257 } t r y { 260 historybulk. Execute ( ) ; 261 } catch ( InvalidOperationException ) { 262 // no products to move 263 } r e t u r n Ok ( ) ; 266 } 267 [... ] 268 } Save to Magento Når brugeren af systemet ønsker at gemme de ænderinger der er foretaget, trykkes der på Save to Magento -knappen i brugergrænsefladen. Denne handling starter processen der ses på figur Størstedelen af denne proces foregår server-side. Efter brugeren har startet processen, bliver de produkter der er ændret sendt fra LocalStorage til 93

102 serveren i nr. 2 og 3 på figuren. LocalStorage tilhører HTML5-standarden og tillader webapplikationer at gemme data lokalt i browsere der understøtter HTML5 [32] Punkterne til og med nr. 3 foregår klient-siden mens de resterende punkter foregår server-side. Overgangen fra klient-siden til server-siden sker ved et kald til metoden SaveToMagento() i ProductsController, hvilken kan ses på kodeeksempel Gem til systemets og Magentos database Når de ændrede produkter er sendt til serveren, bliver der itereret over dem samt de tilhørende produktdata. Dette starter på linje 235 i kodeeksempel Produkterne bliver sendt til serveren som et JSON-array, og det er arrayet, som bliver itereret over. Det enkelte JSON-objekt bliver castet til en dynamisk type, hvilket giver en fleksibilitet i forhold til at hente de enkelte egenskaber ud af JSON-objektet. Det skal bemærkes at det ikke er en typestærk måde at arbejde med et JSON-objekt på. Så typerne på egenskaberne i Product-klassen bliver ikke nødvendigvis respekteret. Dette gør det besværligt at arbejde med JSON-objektet som et Product-objekt, som skal opdateres og gemmes i databasen. På linje 237 bliver det enkelte produkt hentet fra systemets database på MagentoProductId-egenskaben. Dette gøres så der kan arbejdes med det typestærke Product-objekt. Derefter bliver der itereret over produktdata på JSON-objektet på linje 242. På linje 243 bliver lande-id et på produktdataet gemt i en lokal variabel. Derefter bliver den nye pris gemt i en streng. På linje 247 bliver den nye pris lavet om en til decimal, og der bliver kontrolleret om prisen i produktdataet for denne iteration er blevet ændret. Hvis den er blevet ændret sættes den nye pris på produktet fra databasen på linje 250 hvorefter ændringen skrives direkte til Magentos database gennem MagentoDal-objektet på linje 251. Dette svarer til nr. 6 på flowchartet på figur Efter alle produktdata er blevet gennemløbet, og ændringerne er gemt i Magentos database, gemmes det opdaterede produkt i systemets database på linje 256. Dette foregår gennem Dal-klassen, hvilken beskrives i afsnit Når både produkter og produktdata er gennemløbet, eksekveres bulk-operationen på linje 260. Dette gemmer kopierne af de gamle produkter, som er blevet opdateret, i historik-collectionen. Produkthistorik Inden de nye priser bliver gemt i systemets og Magentos database, kopieres de gamle data over i ProductHistory-collectionen. Dette foregår i nr. 4 på figur Det er hele Product-objektet der gemmes i denne collection, da man således kan få et indblik i hvordan et enkelt produkts tilstand var på et givent tidspunkt. I kodeeksempel bliver der initialiseret en Bulk-operation på linje 233. Denne operation vil indeholde de Product-objekter der skal gemmes i historikken. Hvert ændret produkt bliver således tilføjet denne operation på linje 241 i foreach-løkken. Det er en kopi af det gamle Product-objekt der tilføjes fordi det er de gamle værdier der ønskes gemt i historikken. 94

103 Reindexér priser i Magento Efter priserne er opdateret i Magento skal de reindexeres for at blive opdateret i selve netbutikken. Dette er ikke muligt at gøre igennem Magentos API. Systemet imiterer derfor en bruger og logger ind på Magentos administrationspanel ved hjælp af Magentos brugergrænseflade. Det er valgt at gøre det på denne måde for ikke at skulle ændre i Magentos filer eller udvikle en extension til Magento, da dette er et kriterie opsat i afsnit Metoden Reindex() bliver i MagentoReindexer-klassen kaldt fra ProductsController hvor url, brugernavn og password på nuværende tidspunkt er hardcoded. Reindex()-metoden kan ses på linje 17 kodeudsnit Da metoden imiterer en bruger, ved at logge ind gennem brugergrænsefladen til Magentos administratorpanel for at reindexere, starter metoden med at opsætte en HttpClient som imiterer en browser, på linje 19. Med HttpClientHandler- og CookieContainer-klasserne understøtter den imiterede browser cookies, som er nødvendige for at kunne logge ind og reindexere. På linje 23 henter metoden login-siden for at finde FormKey som er en unik genereret kode Magento har tilknyttet hver login-session. Derefter bruger metoden FormKey til at logge ind med, hvilket kan ses på linje 31. Da brugeren, metoden logger ind med, kun har adgang til at reindexere, vil den efter at være logget ind komme til reindexerings-siden. På linje 33, efter reindexerings-siden er hentet, findes og kaldes url en til at reindexere priserne. 95

104 Kodeeksempel MagentoReindexer-klassen 8 namespace SW3. Shared. Utils { 9 p u b l i c c l a s s MagentoReindexer { 10 [... ] 11 p u b l i c MagentoReindexer ( s t r i n g user, s t r i n g pass, s t r i n g url ) { 12 username = user ; 13 password = pass ; 14 adminurl = url ; 15 } p u b l i c bool Reindex ( ) { 18 u s i n g ( var handler = new HttpClientHandler ( ) ) 19 u s i n g ( var client = new HttpClient ( handler ) ) { 20 var cookiecontainer = new CookieContainer ( ) ; 21 handler. CookieContainer = cookiecontainer ; s t r i n g loginpage = client. GetAsync ( adminurl ). Result. Content. ReadAsStringAsync ( ). Result ; var content = new FormUrlEncodedContent ( new [ ] { 26 new KeyValuePair<s t r i n g, s t r i n g >(formkeyname, FormKey ( loginpage ) ), 27 new KeyValuePair<s t r i n g, s t r i n g >(usernamename, username ), 28 new KeyValuePair<s t r i n g, s t r i n g >(passwordname, password ) 29 }) ; s t r i n g reindexpage = client. PostAsync ( adminurl, content ). Result. Content. ReadAsStringAsync ( ). Result ; s t r i n g result = client. GetAsync ( ReindexPricesUrl ( reindexpage ) ). Result. Content. ReadAsStringAsync ( ). Result ; r e t u r n result. Contains ( " Product P r i c e s index was r e b u i l t " ) ; 36 } 37 } p r i v a t e s t r i n g FormKey ( s t r i n g loginpage ) { 40 var pattern = "<input name=\"" + formkeyname + "\" type=\" hidden \" value =\"(.?) \" />" ; 41 var match = Regex. Match ( loginpage, pattern ) ; 42 r e t u r n match!= n u l l? match. Groups [ 1 ]. Value : n u l l ; 43 } p r i v a t e s t r i n g ReindexPricesUrl ( s t r i n g reindexpage ) { 46 var pattern = "<a h r e f =\"(.?/ r e i n d e x P r o c e s s / p r o c e s s /2/ key /.? ) \"> Reindex Data</a>" ; 47 var match = Regex. Match ( reindexpage, pattern ) ; 48 r e t u r n match!= n u l l? match. Groups [ 1 ]. Value : n u l l ; 49 } 50 } 51 } 10.5 Opsummering I dette kapitel blev den endelige implementeringen af Prize Optimizer beskrevet. Der blev igennem kapitlet lagt mest vægt på, hvordan der indhentes, manipuleres med, og gemmes data, fremfor at beskrive hvordan brugergrænsefladen er opbygget. Dette blev gjort, da brugergrænsefladen bygger på meget jquery-kode og css-klasser, hvor meget ikke er lavet fra bunden, men blot blevet modificeret til at passe til dette projekt. Det blev valgt at lave implementeringskapitlet sent i projektet, da der blev ændret mange gange i koden. I 96

105 den næste del af rapporten beskrives iterationerne, hvori de valgte og fravalgte elementer fra de foregående kapitler bliver beskrevet. Dette er med til at give en forståelse for, hvad der blev lavet i hver iteration, og hvad formålet med iterationen var. 97

106 Del V Iterationer 98

107 1. iteration 11 Den første iteration dannede grundlag for problemanalysen. I dette kapitel vil der blive gennemgået det væsentligste arbejde udført i iterationen. Det omfatter beskrivelser af de gennemførte interviews, hvorfor de er udført, resultatet af disse, samt hvad disse resultater blev anvendt til. Derudover beskrives prototyperne der blev fremstillet under iterationen. Indledningsvis bliver de forskellige dataindsamlingsmetoder beskrevet, da de danner grundlaget for valg foretaget i forbindelse med udførelsen af interviews Dataindsamlingsmetoder I forbindelse med dataindsamling kan der anvendes flere forskellige metoder [33]. Blandt metoderne er spørgeskemaer og interviews. Interviews kan derudover deles op i tre forskellige metoder [7, p. 142]. Et overblik over metoderne kan ses nedenfor: Spørgeskema Struktureret interview Semi-struktureret interview Ustruktureret interview Et spørgeskema fungerer således, at flere personer får en række prædefinerede spørgsmål og svarmuligheder. Denne form for dataindsamling er bygget op med en fast struktur, der gør, at svarene fra de adspurgte ikke kan bevæge sig udenfor spørgeskemaet. Metoden benyttes som oftest til udspørgelse af en større gruppe af personer, og giver derfor kvantitativ data [34]. Spørgeskemaer er præget af lukkede spørgsmål, hvilket for eksempel kan være simple ja, nej spørgsmål eller valg af andre fastlagte svarmuligheder. Der kan derfor kun svares indenfor spørgeskemaet faste rammer og der tilbydes ikke rum for uddybende svar. Spørgeskemaets lukkede natur og dets resulterende kvantitative data gør, at spørgeskemaer er oplagt hvis der ønskes større mængder data hvorpå der kan anvendes statistik som for eksempel procentvis fordeling af svarene. Strukturerede interviews er på mange punkter lig med spørgeskemaer. Her er der også på forhånd opstillet faste rammer i form af prædefinerede spørgsmål, og der må ikke afviges 99

108 fra disse, hverken fra intervieweren eller den interviewedes side. Modsat spørgeskemaer kan strukturerede interviews indeholde åbne spørgsmål, men det resulterer stadig i kvantitativ data. Åbne spørgsmål kan typisk ses som hv-spørgsmål, hvilket vil sige spørgsmål der for eksempel begynder med hvad, hvem, hvorfor og hvordan [7, p. 142]. Dette tillader at den interviewede kan komme med længere og mere dybdegående svar. Strukturerede interviews benyttes ofte i vox pop-undersøgelser. Vox pop er en forkortelse for Vox Populi og betyder folkets stemme. Denne form for interview ses ofte i TV, hvor en journalist stiller sig op på gaden for at få tilfældige folks mening og holdninger inden for et givet emne [35]. Det semi-strukturede interview beror sig på, at indsamle kvalitativ data. Her er rammerne ikke så faste, men der er stadig en foruddefineret struktur og et fastlagt et tema for interviewet. I modsætning til spørgeskemaet og det strukturerede interview er det i det semi-strukturerede interview tilladt at bevæge sig uden for de forbedredte spørgsmål, både fra interviewerens og den interviewedes side [7, p. 143]. Et semi-struktureret interview er derfor et godt værktøj til at få klargjort den interviewedes problemstillinger, da denne har mulighed for at præge interviewet og dreje det i retning mod hvor den interviewede føler problemet foreligger. Interviewets løse natur stiller også store krav til intervieweren, da det er vigtigt at kunne tolke og reflektere over den interviewedes svar og derefter omgående omstille sig derefter. På denne måde kan der hurtigt opnås en afgrænsning af den interviewedes problemstilling. Endelig er der det ustrukturede interview, hvilket minder om det semi-strukturerede interview. Med den ustrukturede opbyning arbejdes der, ligesom med den semistrukturerede, med åbne svarmuligheder fra den interviewedes side. Den interviewede har derfor igen mulighed for at præge interviewet. Det ustrukturede interview arbejder dog ikke indenfor nogle rammer, men benytter derimod åbne spørgsmål uden struktur. Dette er ofte en fordel hvis der fra interwieverens side ikke er nogen forudgående viden indenfor interviewets område eller emne [7, p. 143]. Ulempen er derimod, at den interviewede kan styre interviewet i en retning, der senere viser sig at være irrelevant for problemstillingen. 100

109 11.2 Indledende interview I forbindelse med projektets opstart blev der etableret et samarbejde med klienten Tonny Andersen, administrerende direktør hos Sinful. Da projektgruppen ikke havde nogen forudgående viden omkring Sinful var det derfor ønsket at opnå en viden omkring Tonny Andersen som person, samt firmaet Sinful og dets virke. Derudover blev der undersøgt hvilke eventuelle problemstillinger klienten måtte have. Til dette formål blev det valgt at udføre et ustruktureret interview, grundet den manglende forforståelse. Sinfuls hovedkontor er lokaliseret i Aarhus mens projektgruppen befinder sig i Aalborg, hvorfor interviewet blev udført ved hjælp af Skype med Tonny Andersen og hele projektgruppens deltagelse. Det indledende interview med klienten Tonny Andersen kom til at danne grundlag for det motiverende afsnit i problemanalysen i kapitel 2. Derudover kan der læses et kort referat af interviewet i bilag A Prototype 1 - Skitser På baggrund af det indledende interview blev arbejdet på prototype 1 påbegyndt. Projektgruppen havde kun opnået en basal forståelse af klienten Tonny Andersens problemstilling, men der var mange idéer at arbejde videre på. Det blev fastslået at problemstillingen havde datavisualisering og -analysering som omdrejningspunkt. Det blev derfor valgt at udføre en fælles brainstorm i gruppen, som opfølgning på interviewet med klienten. Resultatet af brainstormen kan ses på figur Der var mange forskellige idéer i forbindelse med problemstillingen, deriblandt aspekter indenfor markedsføring, Facebookkampagner, økonomi, lagerstyring samt statistik, hvilket er repræsenteret ved Google Analytics, se figur Da der kunne arbejdes i flere forskellige retninger blev der internt i projektgruppen diskuteret hvorledes der på mest effektiv vis kunne opnås en afgrænsning samt fuld forståelse for klienten Tonny Andersens problemstilling. Figur Brainstorm baseret på det indledende interview med klienten. Det blev besluttet at der, baseret på den iterative udviklingsmodel, beskrevet i kapitel 4, skulle fremstilles flere simple prototyper som hurtigt kunne evalueres af klienten. Det blev vurderet at projektgruppens forskellige forståelser af problemstillingen kunne illustreres og forklares, med mindst mulig tidsspilde, ved hjælp af simple skitser af en mulig brugergrænseflade. Dette er en form for lo-fi-prototyping der udarbejdes efter princippet om at være designed to be produced quickly, and thrown away as quickly. [7, p. 177]. De fremstillede skitser vil blive præsenteret i en mindre form i dette afsnit, mens de kan ses 101

110 i større udgaver i bilag C. Hensigten med skitserne var at kunne fremvise de forskellige vinkler på problemstillingen overfor klienten. Ses der for eksempel på skitsen på figur 11.2 var der fokus på at vise mange produkter på en side med sparsom information koncentreret omkring valuta og pris. Brugergrænsefladen skulle være simpel og let overskuelig, hvorfor produkter er inddelt i et gittersystem hvilket giver et godt overblik. Figur Brugergrænseflade med gittervisning. Figur 11.3 viser en skitse hvor produkterne er vist mere koncentreret og der i stedet er fokus på at vise så mange produkter som muligt. Dette sker dog på bekostning af overskueligheden. Figur Brugergrænseflade med listevisning. Betragtes i stedet skitsen på figur 11.4 var der fokus på at gøre det nemt og intuitivt med et slideview der imiterer det intuitive fingerswipe fra smartphones og tablets. Med denne skitse sættes der fokus på det enkelte produkt. Dette understøttes af skitserne på figur 11.5 og figur 11.6 hvor der er mulighed for at se store mængder information omkring et enkelt produkt. Dette ville være hensigtsmæssigt for eksempel i forbindelse med markedsføring af specifikke produkter. Til skitserne omkring brugergrænsefladedesign var der også fremstillet prototyper af bagvedliggende sider med udvidet information. Dette drejer sig blandt andet om skitsen 102

111 Figur Slideview brugergrænseflade Figur Slideview brugergrænseflade med udvidet information i bunden Figur Slideview brugergrænseflade med udvidet information i siden på figur 11.7, der viser udvidede oplysninger omkring et produkt, men denne gang 103

112 med fokus på statistisk, hvilket for eksempel kunne være i forbindelse med prishistorik, Google Analytics eller konkurrentpriser. Den sidste skitse der blev fremstillet, figur 11.8, illustrerer muligheden for at sammenligne produkter. Ved hjælp af skitserne var det muligt at fremvise prototyper af kerneområder i den foretagede brainstorm, se figur 11.1, da økonomi, markedsføring, Google Analytics og forskellige datatyper var repræsenteret. Figur Statistik omkring et enkelt produkt. Figur Mulighed for at sammenligne produkter. 104

113 11.4 Evaluering af prototypen Evalueringen af de fremstillede prototyper, i form af skitser, blev udført ved hjælp af et interview med klienten Tonny Andersen og Sinfuls IT-ansvarlige Eirik Bakke. Dette blev valgt af flere grunde, blandt andet et ønske fra projektgruppen om at opnå en fuld forståelse af Tonny Andersens problemstilling. Projektgruppen vurderede at dette bedst kunne opnås ved hjælp af et semi-struktureret interview baseret på, og struktureret omkring, den grundlæggende forståelse opnået i forbindelse med det indledende interview. Derudover ville det ved udførelsen af et interview være muligt efterfølgende at få øjeblikkelig og uddybende kritik af de fremstillede prototyper. Endelig anså projektgruppen det som en oplagt mulighed for at besøge Sinfuls hovedkontor i Aarhus og dermed få et indblik i firmaet Sinful, dets opbygning og arbejdsgange. Vigtigst af alt, var at møde klienten Tonny Andersen personligt for at få lagt grundlaget for et produktivt og godt samarbejde. Eirik Bakkes deltagelse havde til hensigt at sikre at det tekniske aspekt af Sinful blev repræsenteret på mødet således der ikke blev udviklet et system der ville konflikte med Sinfuls eksisterende systemer. Formålet med interviewet var, som tidligere nævnt, at opnå en fuld forståelse af klientens problemstilling. Dette vil i de fleste tilfælde ikke kunne løses ved blot at spørge klienten omkring dennes problemstilling, da det kan være svært for klienten at beskrive en problemstilling verbalt [7, p. 157]. En god metode til at forstå klientens problemstilling, kan derfor være at forstå klientens hverdag. Dette vil give et indblik i hvordan klienten arbejder indenfor problemområdet, og derved give et indblik i problemområdet som klienten måske ikke umiddelbart ville kunne forklare. På baggrund af dette blev interviewet indledt med klientens forklaring af problemstillingen efterfulgt af en gennemgang af klientens hverdag. Opbygningen af interviewet kan ses ud fra følgende punkter: 1. Klientens forklaring af problemstillingen. 2. Gennemgang af klientens hverdag. 3. Klientens bud på en eventuel løsning. 4. Fremlæggelse af skitser. 5. Diskussion om funktioner i en endelig løsning. 6. Aftale om krav til 2. prototype. Efter gennemgangen af klienten Tonny Andersens hverdag blev denne bedt om at give et bud på en eventuel løsning. Først derefter blev prototyperne fremvist for klienten sammen med projektgruppens idéer vedrørende den endelige løsning. Dette punkt blev intentionelt placeret til sidst i interviewet for ikke at påvirke klienten i løbet af interviewet ved at lade denne se skitserne på forhånd. Skitserne samt projektgruppens og klientens idéer lagde derefter op til en diskussion omkring løsningens funktioner. Endelig blev der på baggrund af dette aftalt kravene til 2. prototype. Interviewet var struktureret omkring spørgsmålene i bilag A

114 11.5 Interview med klienten Der vil i dette afsnit gives et sammendrag af det semi-strukturerede interview med klienten Tonny Andersen og Sinfuls IT-ansvarlige Eirik Bakke. Der kan læses en direkte transkribering af interviewet i bilag A.3. Sammendraget er yderst kortfattet og vil kun koncentrere sig om de vigtigste aspekter af interviewet, da det ellers ville være en gentagelse af information allerede formidlet tidligere i rapporten. Tonny Andersen indledte interviewet med at fortælle omkring hans person og baggrund. Derefter talte han om sin arbejdsgang samt Sinfuls opbygning og organisation. Fokus var rettet mod problemstillingen omkring det faktum at de havde over 2500 produkter i fire forskellige lande og den nuværende prisstyringsprocess var ineffektiv, uoverskuelig og kompliceret. Dette er uddybet i afsnit 2.2. Denne gennemgang af arbejdsprocessen og det nuværende system gav projektgruppen en forståelse for i hvilken retning der skulle arbejdes, henholdsvis mod effektivitet og overskuelighed. Et af spørgsmålene fra interviewet bad Tonny Andersen om at nævne tre gode og tre dårlige egenskaber ved hans nuværende system. Her nævner Tonny, at det er godt de er begyndt at arbejde med produktpriser ud fra data tilgængeligt fra Magento og Google Analytics. Ligeledes at systemet benytter Excel hvormed han selv kan ændre forskellige paramatre uden Eirik Bakkes hjælp. Endelig er det en fordel at Eiriks nuværende Excelsystem giver SQL-inputs der af Tonny kan skrives direkte til databasen, hvilket fjerner meget manuelt arbejde. Af dårlige egenskaber nævnes den store mængde data i Excel-arket, samt at det kører langsomt. Det medfører at Tonny kun trækker data ned og opdaterer priser en gang i måneden, da data manuelt skal hentes ind i Excel-arket fra Magento og Google Analytics, hvilket er en tidskrævende proces. Den sidste negative egenskab var at det stadig er besværligt, tager lang tid og at Tonny skal holde tungen lige i munden, når han ændrer priser i Excel-arket. Svarene på spørgsmålet kan læses i sin helhed i bilag A.3 [36:37]. Afslutningsvis i interviewet blev der talt om forslag og idéer til den endelige løsning. Her var der fokus på at systemet automatisk skulle trække data ud fra Magento og Google Analytics, der er behov for, for at kunne optimere prisstyringen af produkterne. Her nævnte Tonny dækningsbidrag og konverteringsfrekvens, som de vigtigste parametre systemet skal forholde sig til for at styre priserne. Udover dette nævnte Eirik Bakke scraping af konkurrenternes produktpriser som et interessant område. Scraping, forkortelse af web scraping, er en automatisk proces, der indhenter ønsket data fra websider [36] Kritik af prototyper Til interviewet var der blevet udviklet seks forskellige prototyper i form af skitser til visualisering af brugergrænsefladen for produkthåndtering, se bilag C. Skitserne blev præsenteret for Tonny Andersen og Eirik Bakke efter interviewet for ikke at påvirke og indsnævre deres ideer til et nyt system. Interviewet med Tonny Andersen og Eirik Bakke gjorde det klart at designet der anvendte slideview, se figur 11.4, ikke var ideelt, da der er over 2500 produkter der skal håndteres, og 106

115 designet kun viser ét produkt ad gangen. Tonny Andersen foretrak i stedet listevisningen, hvor han vil have mulighed for at se og ændre de forskellige landes priser. Ifølge klienten Tonny Andersen var det vigtigt at man hurtigt skulle kunne ændre priserne på flere forskellige produkter. Det vil derfor være for langsomt og irriterende hvis der skulle klikkes ind på et produkt for at ændre prisen. Det blev derfor besluttet at det optimale ville være, at brugeren af systemet ikke skal skifte side, men blot arbejde på én side for at ændre de basale ting, hvilket blev sat til at være et specifikt kriterie i afsnit Ud fra dette ønskede Tonny Andersen og Eirik Bakke at der blev taget udganspunkt i listevisningen og skitsen på figur Her vises alle produkterne i en tabel, med mulighed for at søge på et bestemt produkt. Tabellen kan endvidere sorteres efter forskellige parametre. Figur Den valgte prototype med listevisning 11.6 Evaluering af 1. iteration I den første iteration var der fokus på at indsamle data vedrørende Tonny Andersens problemstilling. Dette blev gjort igennem interviews, hvilket gav projektgruppen en forståelse for, hvad projektet skulle indeholde. Der blev udviklet en række skitser, ved at benytte prototyping, som var en af de lærte metoder fra kurset System Udvikling, OOA&D. I sidste del af interviewet blev Tonny Andersens og Eirik Bakkes forventninger til samarbejdet mellem projektgruppen og Sinful opsummeret. Derudover blev der opnået enighed omkring en række indledende overordnede krav og ønsker for den endelige løsning. Disse kan ses nedenfor, som de blev formuleret af Tonny Andersen og Eirik Bakke. Systemet skal kunne: 107

116 Hente relevant data fra Magento og Google Analytics. Anvende data fra Magento og Google Analytics til beregning af dækningsbidrag samt konverteringsfrekvens. Vise produkter i en liste. Opdatere priser og ændre priser direkte i databasen. Have to kategorier af varer: En kategori af standardvarer hvor den foreslåede pris bliver styret ud fra parametrene dækningsbidrag og konverteringsfrekvens. En kategori af prisfølsomme produkter hvor konkurrenters pris på de pågældende produkter anvendes i udregningen af den foreslåede pris. Afslutningsvis blev der i interviewet indgået en aftale vedrørende kravene til den næste prototype; prototype 2. For at kunne nå flere iterationer, samt få styr på kernefunktionaliteten først, blev der opnået enighed om nogle få, men vigtige krav. Kravene angivet nedenfor er derfor krav der anses af klienten Tonny Andersen som en grundlæggende del af den endelige løsning. Kravene der blev aftalt til prototype 2 er som følger: Hente data fra Magento. Ændre priser og opdatere Magento. Benytte en liste til at præsentere data. 108

117 2. iteration 12 Under denne iteration medtages kun de vigtigste elementer, der blev fundet frem til eller ændret. Iterationen er opstillet på denne måde for at belyse de problemstillinger og valg, som projektgruppen har været igennem. I den første iteration blev det ved aftale med Tonny Andersen bestemt at benytte listevisning af produkterne. Dette blev valgt efter evaluering af prototyperne i form af skitser i 1. iteration, hvor skiten på figur 11.9 blev valgt. Der blev derefter i denne iteration udbygget på skitsen ud fra kritik modtaget i interviewet i afsnit Skitsen blev udbygget efter mail-korrespondance med klienten Resultatet af dette kan ses på figur Her blev det blandt andet tilføjet mulighed for at brugeren selv kan vælge hvilke kolonner vedkommende vil se, ved at klikke på checkboxene i venstre-menuen. Denne funktionalitet blev tilføjet ud fra et ønske fra Tonny Andersen. Derudover er det muligt at filtrere produkterne efter producent eller navn. En sorteringensfunktionen blev tilføjet over hver kolonne, i stedet for at ligge dem i venstremenuen. Den reviderede skitse blev herefter mailet til Tonny Andersen, som gerne så, at der i stedet for at stå Pris EUR blev angivet Pris LAND, da flere lande kan benytte den samme valuta. Da projektgruppen og Tonny Andersen havde en fælles forståelse for, hvordan brugergrænsefladen skulle se ud, fortsatte projektgruppen udviklingen af systemet med den nyerhvervede viden Valg & fravalg Der blev i denne iteration lagt stor vægt på, at alle medlemmer af projektgruppen skulle spille en aktiv rolle i implementeringen af koden, hvorfor der blev afsat 3 uger til at kode det første udkast af webapplikationen. Det vigtigste i denne periode af projektet var, at få påbegyndt et system, som Tonny Andersen ville have gavn af at benytte i sin hverdag. I løbet af iterationen blev følgende implementeret: Opsætning af MongoDB på egen server Opsætning af egen Magento webshop samt database hos 109

118 Figur skitse af systemet Opsætning af server til publicering af webapplikationen Implementering af brugergrænseflade ud fra den valgte skitse Mulighed for at gemme ændringer til Magento Datatables og Datatables Editor Mulighed for at søge på produkter Mulighed for at sortere produkter Implementerede funktioner Opsætning af MongoDB på egen server For at systemet skulle kunne gemme forskellige informationer skulle der opsættes en database. Til dette blev det valgt at bruge MongoDB, se kapitel Valg af database. Databasen blev sat op på en udviklingsserver og porte hertil blev åbnet så der kunne skabes forbindelse til databasen fra andre server. Opsætning af egen Magento webshop samt database hos For at kunne test med en rigtig Magento webshop blev der opsat en Magento-installation på et webhotel hos Unoeuro. Opsætning af server til publicering af webapplikationen Da der udvikles en webapplikation skal denne også ligge på en webserver. Der blev forsøgt at gøre dette på webhotellet one.com. Her kørte webhotellet på linux server. Det var ikke muligt at skifte server hvorfor systemet ikke kunne køre på one.com webhotel. Det blev derfor valgt at sætte det op på egen udviklingsserver. 110

119 Implementering af brugergrænseflade ud fra den valgte skitse Ud fra den valgte skitsen, se figur 12.1 skulle der implementeres en brugergrænseflade der lignede dette. En stor udgave af brugergrænsefladen kan ses i bilag D på figur D.1. Til implementering af brugergrænsefladen blev der anvendt Bootstrap for at opnå et konsistent design, se 9.1 Anvendte teknologier. Mulighed for at gemme ændringer til Magento Efter en bruger har ændret en pris skal prisen kunne opdateres og gemmes i Magentos database, se 10.4 Gem data. Datatables og Datatables Editor Der skulle vises meget information til brugeren hvorfor det blev valgt at benytte Datatables og Datatables Editor, se 9.1 Anvendte teknologier. Mulighed for at søge på produkter For at give brugeren mulighed for at finde et specifikt produkt blev der implementeret et søgefelt. Det blev valgt at bruge det søgefelt der var integreret i Datatables. Mulighed for at sortere produkter For at brugeren havde mulighed for at sortere produkterne efter de forskellige kolonner blev der implementeret en sorteringsfunktion. Denne funktion var en del af Datatables og fungerer ved at brugeren klikker på et kolonne navn hvorefter tabellen sorteres efter dette Fravalg Da dette var den første iteration hvor der blev udviklet kodet blev der ikke fortaget mange fravalg. Der blev i denne iteration brugt meget tid på opsætning af udviklingsmiljøet og få en forståelse af de forskellige teknologier det skulle bruges. Der blev derfor ikke foretaget fravalg Problemområdet Klassediagrammet, som ses på figur 12.2, er det første udkast af problemområdet i projektet. Klassediagrammet er blevet revideret i alle iterationerne, og strukturen har derfor ændret sig meget, i forhold til det endelige klassediagram i afsnit 5.2 på figur 5.1. På figur figur 12.2 er der en Butik-klasse. Dette svarer til klassen Land på det endelige klassediagram. Konverteringsfrekvens, Pris og Dækningsbidrag-klasserne, er på figur 5.1 det, der svarer til ProduktData. ProduktData-klassen blev senere oprettet for at kunne have historik samlet i én klasse. Projektgruppen fandt på senere tidspunkt ud af, at der skal angives en kardinalitet imellem klasserne. Ses der på associeringen mellem Valutakurs- og Webshop-klassen, defineres det ikke hvor mange valutakurser en webshop kan indeholde, og der mangler derfor relevant information Test af Prototype 2 - Magentoforbindelse Formålet med testen var at få brugerfeedback på de implementerede funktioner, brugergrænsefladen, samt eventuelt manglende funktionalitet. I løbet af afsnittet beskrives 111

120 Figur Klassediagram i 2. iteration Figur Systemet efter 2. iteration metoden samt udførelsen af usability-test af prototype 2 med klienten Tonny Andersen Metode til usability-test Til usability-testen af prototype 2, blev der valgt, at benytte assessment-test. Assessmenttest udføres ofte midtvejs i produktudviklingscyklussen, efter der er blevet udviklet en applikation med de grundlæggende tilgængelige funktioner, samt en brugergrænseflade af højere kvalitet [37, p. 34]. Formålet med assessment-testen er, at evaluere på de grundlæggende funktioner implementeret i prototypen, som blev fundet ud fra tidligere skitser. Hvor tidligere test i produktudvikling blev udført for at undersøge og få en bedre forståelse af problem- og anvendelsesområdet, er formålet med assessment-testens at se, hvordan en bruger interagerer med en funktionel prototype. Brugeren stilles overfor specifikke og realistiske opgaver, der skal udføres ved hjælp af systemet. Det undersøges og evalueres således hvor brugbart systemet er og eventuelle usability-mangler i systemet bliver tydeliggjort. 112

121 Du er logget ind via login-siden og er nu på forsiden af Sinful PriceOptimizer, hvor du blandt andet kan se en tabel af produkter. Opgave 1: Del 1) Du vil gerne have sorteret produkterne i alfabetisk rækkefølge. Hvad gør du? Del 2) Du ser på tabellen igen og vil gerne have svensk og norsk pris fjernet fra tabellen, da du ikke skal benytte kolonnerne lige nu. Hvad gør du? Opgave 2: Del 1) Du har opdaget at Sinful Rabbit Vibrator Original bliver solgt til 369,00 kr. hos en konkurrerende sexshop og du vil derfor ændre prisen på dette produkt til 359,00 kr. Hvad gør du? Del 2) Du vil gerne gemme den nuværende ændring, og sende det til Magento. Hvad gør du? Del 3) Du synes at 10 produkter per side er for få, og vil gerne ændre det til 50 produkter per side i stedet for. Hvad gør du? Opgave 3: Del 1) Du ønsker kun at se det specifikke produkt Sinful Magic Wand Kraftig Vibrator i tabellen. Hvad gør du? Del 2) Du ønsker at kunne se informationen under Web crawler-info og Statistics. Hvad gør du? Tabel Opgaver til assessment-test Opsætning af assessment-test Til assessment-testen, blev der udarbejdet tre opgaver med underpunkter som kan ses i tabel Testen var udformet således at sværhedsgraden var stigende igennem de tre opgaver, for at testpersonen skulle få en succesoplevelse og blive fortrolig med systemet før sværere opgaver blev stillet. Ved udførelse af brugerbaseret evaluering af en prototype anbefales det at benytte 4-5 testpersoner indenfor brugergruppen for at opnå pålidelige resultater [37, p. 73]. I forhold til prototype 2, var det ikke muligt at opnå det antal testpersoner, eftersom der på det pågældende tidspunkt kun var én bruger af det endelige system. Det blev valgt at gennemføre testen alligevel, ud fra argumentet at en test med én bruger var bedre end ingen test. 113

122 Udførelse af assessment-test Til udførelsen af assessment-test blev der uddelegeret fem forskellige roller til gruppemedlemmerne, samt en rolle til testpersonen. Testleder hvis formål var at læse de tre opgaver højt for testpersonen, samt støtte testpersonen hvis denne gik i stå i udførelsen af en opgave, uden at hjælpe for meget. Derudover stod testlederen for en kort introduktion til assessment-testen samt at debriefe testpersonen, ved hjælp af et semi-struktureret interview. Testpersonen som udfører en række opgaver i systemet. Personen skal under hele testen tænke højt, og hvis personen går i stå, skal testlederen træde til med ledende spørgsmål. Testpersoner kan have variende erfaring indenfor IT, og det er vigtigt at notere, hvilket niveau personen er på. Dataloggeren skrev samtalen mellem testpersonen og testlederen ned samt det, som testpersonen tænkte højt under udførsel af opgaverne. Videooperator der havde til opgave at optage video og lyd af Skype-samtalen mellem testledern og testpersonen. Teknisk supporter som var tilstede hos testlederen under udføreslen af assessmenttesten som passiv observator, men som kunne uddybe tekniske aspekter hvis nødvendigt under det semi-strukturede interview. Observatører der havde til opgave at observere testpersonens adfærd og interaktion med prototypen under assessment-testen. Derudover havde de til opgave at optage lyd og video som kunne benyttes som backup. Testmiljøet var af en anderledes karakter end det kontrollerede testmiljø tilgængelig på Cassiopeia, AAU. Testen blev udført ved hjælp af en Skype-samtale hvor testpersonen befandt sig i mødelokalet hos Sinful i Aarhus mens projektgruppens medlemmer befandt sig i to gruppelokaler på Cassiopeia, AAU. Testlederen, videooperatoren og den tekniske supporter befandt sig i det samme rum og var begrænset i intern samtale da testpersonen således ville høre det. Dataloggeren og observatørerne opholdte sig til gengæld i et andet lokale og havde mulighed for at diskutere og komme til en fælles forståelse af hvad de havde observeret. Til Skype-samtalen blev der benyttet fire computere. En computer hos testpersonen hvor lydindgang, lydudgang og video var tilgængelig. En computer som testlederen og den tekniske supporter benyttede med samme indstillinger som hos testpersonen. En computer til optagelse af Skype-samtalen som kun optog lydudgangen og video samt en computer hos dataloggeren og observatørerne hvor ligeledes kun lydudgang og video var tilgængelig. Selve assessment-testen foreløb således at testpersonen, efter etablering af Skype-samtalen, blev bedt om at tilgå prototypen i sin webbrowser. Testlederen læste herefter en kort introduktion op for testpersonen, bilag B.1. Derefter beskrev testlederen scenariet og de tre opgaver i tabel 12.1 blev læst højt i takt med at testpersonen udførte delopgaverne. 114

123 Som afslutning blev der udført et semi-struktureret interview hvor testpersonen havde mulighed for at uddybe sin oplevelse af interaktionen med prototypen Resultat af assessment-testen & debriefingen Som nævnt i afsnit var der kun en enkelt testpersonen til testen af prototype 2. Testpersonen havde stor erfaring med IT som bruger, i kraft af sin daglige benyttelse af flere forskellige IT-applikationer; heriblandt Excel. Testpersonen gik på intet tidspunkt i stå under udførelsen af testen, og de fleste opgaver blev løst på under 10 sekunder, samtidig med at testpersonen benyttede den korrekte forståelse af prototypen. Enkelte opgaver blev løst på alternative måder, og i løbet af testen var der steder, hvor testpersonens mentale model af prototypen ikke stemte overens med den faktiske. I tabel 12.2 er de fundne problemer blevet opstillet. Hvert problem er givet en vurdering ud fra om det er af kosmetisk, seriøs eller kritisk karakter. Denne vurdering bygger på Molich og Nielsens evaluering af brugergrænseflader, hvor man vurderer ud fra tre parametre [38], henholdsvis hvor forsinket brugeren bliver, hvor irriteret en bruger bliver eller hvor irrationel en funktion opfattes samt om brugerens mentale model af applikationen svarer overens med den faktiske applikation. Problem nr. Problemnavn Vurdering 1 Sortering ikke tydelig Kosmetisk 2 Pris kan ændres skal være tydeligere Kosmetisk 3 Prisændringer gemmes ikke ved Seriøs museklik 4 Mangler en knap til at rydde Kosmetisk søgefilteret 5 Forkert mentalmodel af Save to Seriøs Magento 6 Previous & next forsvinder ikke Kosmetisk Tabel De fundne problemer fra assessment-testen med en vurdering af hvilken karakter problemet er af I nedestående liste bliver hvert problem beskrevet og der gives en argumentation for vurderingen af problemets karakter. 1. Sortering ikke tydelig: Problemet opstod i forbindelse med Opgave 1, Del 1 hvor testpersonen skulle sortere produkterne i tabellen i alfabetisk rækkefølge. Selve opgaven blev udført korrekt på under fem sekunder, men testpersonen efterspurgte om det var muligt at fremhæve eller på anden måde tydeliggøre at man kan klikke på overskrifterne i tabellen for at højne brugbarheden. Problemet anses for at være af kosmetisk karakter da det ikke havde indflydelse på testpersonens udførsel af opgaven. 2. Pris kan ændres skal være tydeligere: Opgave 2, Del 1 var den opgave der tog længst tid for testpersonen og skabte lidt forvirring. testpersonen blev bedt om at ændre prisen på et specifikt produkt i tabellen. Et af problemerne var at testpersonen 115

124 ikke umiddelbart vidste hvordan prisen skulle ændres. Testpersonen begynder med at søge efter det specifikke produkt selv om det stod tydeligt i tabellen. Efter lidt tid klikker testpersonen på prisen, men det virker som om at det sker ved et tilfælde. Selvom det at ændre pris på et produkt er essentielt for applikationen der er under udvikling vurderes problemet til at være af kosmetisk karakter da brugeren blot skal have udført operationen én gang for at forstå funktionaliteten. 3. Prisændringer gemmes ikke ved museklik: Problemet opstod ligeledes i forbindelse med Opgave 2, Del 1. Efter at have ændret prisen på produktet trykker testpersonen udenfor prisfeltet med musen i den tro at ændringen bliver gemt. For at gemme en prisændring skal brugeren efter indtastning af en ny pris trykke på [Enter] for at gemme den nye pris. Det forvirrer testpersonen at prisændringen ikke bliver gemt når han trykker væk med musen og han prøver i stedet for at trykke på Save to Magento -knappen hvilket heller ikke gemmer ændringen. Det er først efter hjælp fra testlederen at opgaven bliver løst korrekt. Problemet er af seriøs karakter da det at ændre priser hurtigt ved hjælp af applikationen er essentielt for brugeren. Det skal således være muligt at ændre pris på produkter så hurtigt som muligt. Ligeledes medfører problemet, at prisændringer ikke gemmes når der trykkes væk med musen, at testpersonen får en forkert mentalmodel af applikationen. 4. Mangler en knap til at rydde søgefilteret: Ved Opgave 2, Del 3 bliver testpersonen bedt om at udvide tabellen til at vise 50 produkter i stedet for de nuværende 10. Eftersom at testpersonen ved udførelsen af en anden opgave har skrevet i søgefeltet skal han først slette denne tekst. I den forbindelse efterlyser testpersonen en rydde-knap til at rydde søgefeltet. Det vil spare brugeren af systemet at markere teksten i søgefeltet og slette den ved at have en rydde-knap, derfor anses problemet for at være af kosmetisk karakter. 5. Forkert mentalmodel af Save to Magento: Som beskrevet i problem 3 fik testpersonen en forkert mentalmodel af knappen Save to Magento hvis funktion er at opdatere prisændringer til Magento webshoppen. Problemet anses for at være af seriøs karakter da funktionen Save to Magento kun skal udføres når alle prisændringer er fortaget. Dette skyldes at funktionen er tidskrævende og vil gøre brugen af systemet langsommere hvis brugeren trykker på knappen hver gang der er foretaget en prisændring i tabellen. Samtidig bliver prisændringen ikke gemt i tabellen, hvilket testpersonen forsøgte at opnå. 6. Previous & next forsvinder ikke: Ved Opgave 3, Del 1 hvor testpersonen bliver bedt om kun at få vist et specifikt produkt i tabellen, undrer han sig over at der under tabellen stadigvæk står Previous og Next selvom der kun er et produkt. Problemet er af kosmetisk karakter, da det ikke ændrer på funktionaliteten af systemet, men virker forstyrrende for brugeren. Ved det efterfølgende debriefingsinterview af testpersonen blev de forskellige problematikker uddybet og ønsker til funktionalitet i det endelige system blev givet. 116

125 Tonny Andersen blev spurgt ind til, om der var funktionaliteter han fandt unødige eller besværlige at bruge. Han påpegede at det ikke fungerer optimalt, at man skal trykke [Enter] for at gemme en prisændring; specielt ikke når man skal ændre pris på mange produkter. Derudover efterlyste han, at i de rækker hvor der er foretaget en prisændring, at den ændrede farve eller på anden måde skiller sig ud så det er tydeligt at der er foretaget en ændring. Udover en rydde-funktion til søgefeltet, ønsker Tonny Andersen også at have en rydde-knap til tabellen således at, hvis han fortryder de ændringer han har foretaget i tabellen, kan han trykke på denne knap, hvorefter han kommer tilbage til udgangspunktet for tabellen. Tonny Andersen blev efterfølgende spurgt, om der er funktionalitet i tabellen som manglede. Til dette svarede han, at der manglede en række kolonner, henholdsvis antal solgte varer af de enkelte produkter, gerne indenfor forskellige tidshorisonter, antal på lager, tilbudsprisen og indkøbsprisen på de enkelte produkter. Tonny Andersen efterspurgte til sidst en Exclude-kolonne, der angiver om et produkt stadig kan fås hos leverandøren. Denne kolonne må gerne indeholde en ja- eller nej-tekst. Til sidst nævnte Tonny at han gerne vil have organiseret menuen og tabellen således at han kan se de forskellige kolonner for hvert land. Han vil gerne have mulighed for hurtigt at kunne skifte mellem produkter i for eksempel Danmark og Norge. Han vil helst ikke skulle bruge mere end tre klik på et skift mellem landene Evaluering af 2. iteration I denne iteration blev der fundet frem til en række problemer, som skulle implementeres i den 3. iteration. Kravene blev vurderet ud fra, om det var seriøse eller kosmetiske fejl. De seriøse fejl, er vigtige at få implementeret i næste iteration, da de kan forvirre personer, som bruger systemet. Ydermere blev der til sidst i iterationen fundet frem til, at ændringer af priser ikke skulle foregå ved at foreslå prisændringer, som det ellers var planlagt fra starten. Dette blev der fundet frem til i samarbejde med Tonny Andersen, da han ønskede at have kontrol over hvilke priser der skulle ændres på, og hvornår de skulle ændres. Ud fra debriefingsamtalen med Tonny Andersen blev der fundet frem til, at der var funktioner som skulle udbedres, og der var samtidig nye tilføjelser til systemet. Derudover blev problemområdet analyseret, med henblik på at skabe en forståelse for, hvilke klasser der skulle implementeres. Derudover skulle udviklingen af systemet påbegyndes. Det gik dog op for projektgruppen, at nogle af delopgaverne var meget store og komplekse at implementere i systemet. Her tænkes der på indhentning af data fra Google Analytics og implementering af web-crawleren. Derfor blev disse to delopgaver udsat til en senere iteration. 117

126 3. iteration 13 Den tredje iteration er baseret på resultaterne og erfaringer opnået i forrige iterations afsluttende test, se afsnit iteration var koncentreret om systemets grundlæggende funktionalitet og en implementering af skitsen valgt i afsnit Dette resulterede i Prototype 2 - Magentoforbindelse, hvor dennes brugergrænseflade kan ses på figur Der er dermed dannet et solidt grundlag for videre udvikling. Der vil i afsnittet beskrives og begrundes de foretagede valg og fravalg, efterfulgt af en liste af implementerede elementer, et klassediagram af problemområdet og test af prototypen udviklet i iterationen Valg & fravalg Baseret på evalueringen af prototype 2, se afsnit 12.4, opstilles der nedenfor de elementer der var relevante i en implementeringsmæssig sammenhæng i 3. iteration. Listen indeholder både elementer der blev implementeret samt elementer der blev fravalgt. En begrundelse for valgene i forbindelse med hvert enkelt punkt i listen følger derefter. Implementering af databasedump Håndtering af produktdata Venstre-menu Fold ud række Valutakurser & omregner Show changes Undo changes Filtrering af produkter Loading screen Brugerregistrering og -login LocalStorage 118

127 Big-Mac Index Magento API Implementerede funktionaliteter Implementering af databasedump I afsnit 9 er det beskrevet hvorledes der er opsat og anvendt et udviklingsmiljø i forbindelse med implementeringen af systemet. For at gøre udviklingsmiljøet realistisk, blev der implementeret et dump af Sinfuls Magento-database i udviklingsmiljøet. Dermed kunne der arbejdes på realistisk data som var repræsentativ for produkterne i Sinfuls webshop og problemområdet. Anvendelsen af realistisk data hjælper i forbindelsen med udviklingen, og gør det lettere, at kvalitetssikre. Håndtering af produktdata Efter database-dumpet fra Sinful var blevet implementeret i udviklingsdatabasen skulle alt det nye information håndteres. Der skulle tages højde for ændringer i databasestrukturen fra 2. iteration og der skulle tages højde for forskellige lande. Venstre-menu Efter at have fået indlæst alt data i tabellen skulle brugeren have mulighed for at fjerne kolonner. Hvis dette ikke var en mulighed ville de mange produktinformationer hurtigt blive uoverskuelige. For at give brugeren mulighed for dette blev der lavet en menu med en checkbox for hver kolonne, så brugeren selv kan bestemme hvilke data der skal vises. Tideligere i 2. iteration var denne menu hardcoded, da det ikke var muligt at få produkt data fra forskellige lande. Den gamle menu kan ses til højre på figur 13.1 For at gøre det overskueligt for brugeren, er de forskellige checkboxe inddelt i forskellige overkategorier. Overkategorierne er henholdsvis de forskellige lande og én der indeholder generel information som SKU og kostpris. Overkategorierne blev genereret dynamisk så der senere let vil kunne blive tilføjet eller fjernet lande fra webshoppen. Den nye menu kan ses til venstre på figur 13.1 Fold ud række Da der på dette tidspunkt var planlagt senere, at vise grafer over prishistorik, var der brug for en måde at vise flere informationer om et produkt uden at gå på kompromis med, at webapplikationen skulle vises på én side, se afsnit Det blev derfor besluttet at implementere en fold ud række for hvert produkt. Som det kan ses på figur 13.5, blev der implementeret en lille knap med et plus i hver produktrække. Ved at klikke på dette blev der foldet en ekstra række ud med flere oplysninger om produktet. Der blev i denne iteration dog ikke implementeret prishistorik, og der blev derfor sat et billede af en graf ind til visualisering. Valutakurser & omregner Et ønske fra klientens side var, at benytte en valutaomregner. Det blev vurderet på om visning af valutakurs og valutaomregneren skulle være samlet eller ej, og hvor i brugergrænsefladen det skulle placeres. Der blev besluttet at dele det op og placere valutakurserne i øverste højre hjørne, som kan ses på figur og senere under test af prototype Selve valutaomregneren blev placeret i fold-ud-rækken 119

128 Figur Til venstre ses venstre-menuen i 3. iteration og til højre ses venstre-menuen fra 2. iteration. under hvert produkt, som også kan ses på figur Dette blev valgt, da dette ikke var en funktion der kun skulle bruges, når der arbejdes med et specifikt produkt og ikke ved hver prisændring. Det blev desuden valgt for ikke at optage plads på siden og mindske overskueligheden. Show changes Det blev vurderet at en funktion til at filtrere produkterne i tabellen, så der kun blev vist produkter der var blevet ændret, ville være nødvendigt. Hvis der var ændret pris på flere produkter ville det være en fordel at få en oversigt over dem alle, så de kunne kontrolleres inden der blev gemt til Magento. Undo changes For at give brugeren af systemet mulighed for at fjerne alle ændringer blev der implementeret en knap med teksten Undo changes. Denne knap ændrer alle priser til værdien før brugeres ændringer. Dette giver en sikkerhed for bruger ved at de altid kan fortryde hvis de laver en fejl. Filtrering af produkter For at brugeren af systemet kan finde de produkter, som brugeren ønsker at ændre prisen på skal der være forskellige måder af filtrere produkterne på. Til dette blev der implementeret en søgefunktion i toppen af hver kolonne af tabellen. Søgefelter gør det muligt at søge efter specifikke værdier i hver kolonne. 120

129 Loading screen Forskellige metoder i applikationen kunne tage længere tid som for eksempel ved opstart af applikationen hvor alle produkters data skal indlæses. Dette betyder at brugeren bliver mødt at en tom tabel hvilket kan irritere og forvirre brugeren. Det blev derfor valgt at brugeren ikke skulle have mulighed for at bruge systemet før alt var indlæst og klart til brug. Der blev derfor implementeret en loading screen som blev brugt hver gang systemet hentede eller gemte data. Denne loading screen fungerede ved at der blev lagt mørk halvgennemsigtigt overlay over hele siden så brugeren ikke kunne klikke på noget. Desuden var der en lille loading bar på midten af siden for at vise brugeren at systemet arbejdede. Brugerregistrering og -login I afsnit 7.1 blev der opsat kriterier for systemet, hvor kriteriet sikkert blev sat til vigtigt. Dette var relevant i forhold til Price Optimizer, da det er vigtigt at data fra brugerens tilkoblede webshop ikke er tilgængelig for andre. Der blev derfor implementeret et login-system baseret på ASP.NET MVC-frameworkets Identity & Security pakker. Price Optimizer understøtter dog på nuværende tidspunkt ikke flere brugere. Det er muligt at registrere en ny bruger, men alle nye brugere bliver koblet på den samme Magento-webshop opsat på udviklingsserveren. LocalStorage I 2. iteration blev alle prisændringer gemt i systemets database, så snart brugeren havde skrevet ændrigen ind og trykket Enter. Dette gav en lille forsinkelse for brugeren og gav føelsen af at systemet "hakkede"ved brug. For at afhjælpe dette samt gøre dette lettere at vise ændringer blev det valgt at bruge LocalStorage, som blev beskrevet i afsnit 10.3 Visning og manipulation af data. Dette gjorde det muligt først at gemme alle ændringer, når brugeren ønskede det. Desuden blev LocalStorage brugt til at visualisere brugerens ændringer ved at ændre farve på produktrækken i tabellen Fravalg Big-Mac Index BigMac-index blev fravalgt da det ikke var ikke et ønske fra klientens side. Det blev heller ikke anset som relevant, da valutakurserne og -omregneren opfyldte klientes behov. Magento API I Magentos API eksisterer der mange indbyggede funktioner, der kunne være blevet brugt til at kommunikere med Magento-installationen. Alligevel fandtes der også flere grunde til ikke at benytte det. Først og fremmest var API et langsommeligt. Det var sandsynligvis på grund af, at kaldene blev besvaret med overflødig information, i forhold til systemets formål samt Magentos langsomme natur som Tonny Andersen nævnte allerede i det indledende interview. Den anden grund er at API et ikke kan reindexere priserne. Ydermere var det enkelte lands valutaenhed ikke tilgængeligt via API et, hvilket var vigtigt at have til rådighed for valutakurser, valutaomregneren og udregning af dækningsbidraget. 121

130 13.2 Problemområdet Fordi der blev lavet ændringer vedrørende hvilke elementer der skulle implementeres i systemet, vil der også forekomme ændringer i klassediagrammet, der beskriver problemområdet. Det ses blandt andet at bigmac-index er blevet fjernet. Derudover kan der argumenteres for at både valutakurs og konkurrentpris aggregeres af produktdata, fordi de ikke er sideordnede eller ligestillede og fordi valutakurs ikke kan skifte forbindelse fra produktdata til konkurrentpris [1]. Det opdaterede klassediagram ses i figur Klassediagrammet afspejler de klasser, som projektgruppen anså som relevante i forhold til systemets problemområde. Som det ses på figur 13.2, er den ikke identisk med det endelige klassediagram fra afsnit Da det i denne iteration var tænkt, at der skulle laves en webcrawler, var der også oprettet en klasse til denne i klassediagrammet. På figur 13.2 ses det, at produktdata og konkurrentpris har et 1 til mange -forhold, hvilket betyder, at hver gang der findes en pris på et produkt i Sinfuls webshop, kan der findes 0 eller flere priser på konkurrende virksomheders webshops. I klassediagrammet har Valutakurs en kardinalitet på 1, som indikerer, at der på et givet tidspunkt kun findes én værdi her. I denne iteration stod Produkt -klassen som en associering til Produktdata. Dette betød, at produktdata var forbundet med et produkt. Senere blev det dog fundet frem til, at produktdata var en definerende del for et produkt, og blev derfor ændret til en aggregering. På figuren ses der, at der for hvert Produkt kan være mange Produktdata. Figur Klassediagram i 3. iteration Optimering af synkroniseringsprocessen Et af systemets kriterier, fra afsnit 7.1, var at det skulle være mere effektivt end klientens nuværende system. Systemets hastighed har stor indflydelse på effektiviteten, 122

131 og det blev derfor forsøgt at optimere de mest tidskrævende processer i systemet. Dette drejede sig hovedsageligt om processen vedrørende synkroniseringen med Magentowebshoppen. Hentning af data vedrørende produkterne og landende tilknyttet webshoppen var ineffektivt, og det blev derfor prioriteret at optimere dette. I afsnit 13.1 blev det beskrevet hvorledes data fra dumpet af Sinfuls Magento-database blev implementeret. Dette medførte at systemet skulle håndtere over 2500 produkter med tilhørende produktdata. Dermed blev optimering af synkroniseringsprocessen særdeles aktuel, da systemet brugte 34 minutter og 44 sekunder på at synkronisere med webshoppen, hvilket er repræsenteret ved Test 1 i tabel Dette var uacceptabelt i forhold til de opsatte kriterier omkring effektivitet og brugbarhed i afsnit 7.1, hvorfor en optimering var en nødvendighed. Der vil nedenfor trinvist gennemgås optimeringen af synkroniseringsprocessen samt hvilke ændringer der blev implementeret og effekten af disse. Målinger Måling 1 Måling 2 Måling 3 Måling 4 Tid 34 minutter, 44 sekunder 3 minutter, 48 sekunder 2 minutter, 18 sekunder 43 sekunder Tabel Tider målt i forbindelse med optimering af synkroniseringsprocessen 1. optimering I første omgang blev der, i forbindelse med synkroniseringen mellem systemet og webshoppen, indledningsvis hentet unikt information om alle produkterne ved hjælp af en MySQL-forspørgsel til Magento-databasen. Produkterne blev gemt i en liste. Listen med produkterne blev derefter anvendt til at hente alle produktdata for de enkelte produkter. Dette blev implementeret ved, at iterere over listen af produkter og læse data omkring hvert produkts produktdata direkte fra Magento-databasen. For hver iteration over produkterne blev der derfor åbnet og lukket en ny MySQL-forbindelse til databasen. Da systemet indeholdte over 2500 produkter resulterede det i oprettelsen af mere end 2500 MySQL-forbindelser til Magento-databasen. Dette var ikke hensigtsmæssigt og var den direkte årsag til, at systemet var ineffektivt og brugte 34 minutter og 44 sekunder på synkroniseringsprocessen. Dette angives som Måling 1 i tabel For at udbedre dette blev metoden til at hente produkter revideret. I stedet for at oprette en ny forbindelse for hvert produkt, hvilket medførte oprettelsen af flere tusinde forbindelser, blev der kun anvendt fire MySQL-forbindelser til databasen. Det resulterede i en markant forbedring fra 34 minutter og 44 sekunder til 3 minutter og 48 sekunder, hvilket er overgangen fra Måling 1 til Måling 2 på tabel Dette er en forbedring på 914%. 2. optimering Yderligere optimering var ønsket og der blev derfor set på MySQL-kommandoerne der blev anvendt i forbindelse med hentningen af data. For at kunne hente data fra Magento- 123

132 databasen, er det nødvendigt at specificere en query-streng, der angiver hvilken data der skal hentes. I en query-streng angiver kommandoen SELECT hvilken data der skal hentes i databasen. Kommandoen FROM kan anvendes til at bestemme hvilke tabeller der skal hentes fra. Til sidst kan WHERE anvendes til filtrere dataen. Det blev valgt at implementere en implicit JOIN-forespørgsel, da det således var muligt at angive præcis hvilken data der var ønsket fra flere tabeller i en enkelt query-streng. Dermed kunne der sendes en forespørgsel, med præcis den data der skulle bruges. Overflødigt data blev undladt. Denne metode til at hente data var en væsentlig forbedring i forhold til den tidligere metode, som kun anvendte kommandoerne SELECT og FROM hvormed alt data fra de angivne tabeller blev hente. Dette medførte hentning af store mængder af unødig data. Anvendelsen af implicitte JOIN forespørgsler resulterede i en forbedring af synkroniseringsprocessen fra 3 minutter og 48 sekunder til 2 minutter og 18 sekunder, hvilket var en forbedring på 165%. Overgangen fra Måling 2 til Måling 3 kan ses i tabel optimering Efter optimering på processen, vedrørende hentning af data, blev der eftersøgt hvorvidt der var flere flaskehalse i synkroniseringsprocessen der kunne optimeres. Her blev der fundet en flaskehals i forbindelse med lagringen af produkterne i systemets MongoDBdatabase. Produkterne blev lagret i systemets database ét produkt af gangen, hvilket var særdeles ineffektivt. Der blev derfor implementeret anvendelsen af bulk-operationer, hvilket er en metode som er tilgængelig gennem MongoDBs C#-driver. Bulk-operationer betyder at instruktioner samles i pakker af 1000 instruktioner. Tilføjes der mere end 1000 intruktioner, bliver bulken automatisk delt op i pakker af 1000 [39]. I stedet for at gemme ét produkt af gangen til systemets database blev instruktionen om dette tilføjet til en bulk, hvilket blev gjort for alle produkter. Når alle produkter var tilføjet til bulken kunne denne skrives til databasen. Da der var over 2500 produkter i webshoppen blev der skrevet instruktioner til systemets database af tre omgange. Dette var igen en betydelig forbedring fra at skrive til databasen mere end 2500 gange. Dette er repræsenteret ved overgangen fra Måling 3 til Måling 4 i tabel Det var en optimering fra 2 minutter og 18 sekunder til 43 sekunder, altså yderligere 320%. 124

133 13.3 Test af prototype 3 - Price Optimizer (Alpha) I dette afsnit vil usability-testen af prototype 3 blive beskrevet. Der vil gøres rede for valg af testmetode, udførelse samt fremfundne resultater. De følgende afsnit benytter artiklen Instant data analysis: Conducting usability evaluations in a day som kilde til beskrivelsen af IDA-metoden [40] Metode til usability-test Til testen af prototype 3 blev det valgt at udføre en test bygget på IDA-metoden (Instant Data Analysis). IDA-metodens mål er at gøre det muligt at udføre en usabilityevaluering af en software applikation på én dag. Således skal både udførelsen, analysen samt dokumentationen af testen kunne udføres på omkring otte timer ved benyttelse af 4-6 testpersoner. IDA-metoden blev udviklet med det formål at kunne udføre, analysere og dokumentere en usability-test på en dag. Denne tilgang til usability-evaluering bygger på en erkendelse af at traditionel dataanalyse er en tidskrævende aktivitet som kan afholde softwareudviklere fra at foretage en usabilityevaluering. Det medfører mangel på vigtig information omkring usability-problemer i forbindelse med udviklingen af systemet. Information som kunne have ført til forbedret kvalitet gennem et redesign af applikationen. Således er IDA-metodens mål ikke at være den bedste teknik til at observere og identificere usability-problemer, men være en effektiv metode til hurtigt at identificere de centrale og kritiske usability-problemer i en software applikation, som kan forbedres gennem redesign. IDA-metoden blev således valgt som testmetode til evaluering af prototype 3 da den iterative udviklingsproces stemmer godt overens med IDA-metodens mål. Ligeledes var prototype 3 på et stadie i udviklingsprocessen hvor testpersoner kunne benytte systemet og udføre flere forskellige opgaver lig dem som det endelige system skulle kunne understøtte. Derfor var en større test med 4-6 testpersoner ideel til formålet Opsætning af Instant Data Analysis IDA-metoden er designet til at anvende brugerbaseret tænk højt -testing. Brugerbaseret tænk højt -testing udføres ved at man placerer testpersonen foran det udviklede system. I løbet af testen bedes testpersonen om at tænke højt, i forbindelse med løsningen af forskellige opgaver, der bliver stillet. Til usability-testen af prototype 3 blev fem opgaver med tilhørende underpunkter udarbejdet, hvilke kan ses i tabel Opgaverne afspejler en prisregulator daglige brug af systemet og er udarbejdet således at testpersonen udfører opgaver i centrale dele systemet. Ligeledes er opgavernes sværhedsgrad stigende for først at gøre testpersonen tryg ved situationen. Det kan føles ubehageligt at blive overvåget af både testlederen samt de forskellige kameraer der optager testen i usability-laboratoriet. For at gøre testen virkelighedstro blev der udarbejdet loginkort til hver testperson med specifikke login-oplysninger. Udover dette blev der opstillet et scenarie som opgaverne skulle løses ud fra, se

134 Du er ankommet til dit kontor hos Erotik A/S der ejer nordens største erotiske webshop med salg af produkter i Danmark, Sverige, Norge og Finland. Dit arbejde hos Erotik A/S består i at skulle prissætte samt prisoptimere de over 2500 produkter der bliver solgt via Erotik A/S s Magento webshop i de fire land. Til at lette dette arbejde har du fået udviklet en webapplikation der skal gøre den information der er til rådighed overskuelig. Din computer er netop startet op og du er klar til at påbegynde dit arbejde. Opgave 1: Del 1) Du er ankommet til Price Optimizers log-in side hvor du gerne vil logge ind. Hvad gør du? Del 2) Du er nu logget ind på Price Optimizer og vil gerne forhøje Price Default med 10 kr. på de tre øverste produkter i tabellen. Hvad gør du? Del 3) Du fortryder de ændringer du har foretaget og vil gerne fjerne dem. Hvad gør du? Opgave 2: Del 1) Du ønsker at gøre tabellen mere overskuelig i forhold til hvad du skal arbejde med i dag. Du vil gerne fjerne SKU, Exclude og Cost Price under General Columns samt Special Price og Conversion Rate under Default Columns. Del 2) Du har nu fået et bedre overblik over tabellen, men vil også gerne se prisen for produkterne i den svenske webshop. Hvad gør du? Del 3) Du har nu de kolonner du skal bruge og vil gerne have fjernet menuen i venstre side for at kunne benytte hele skærmen til at se tabellen. Hvad gør du? Opgave 3: Del 1) Du vil nu gerne sortere tabellen således at Contribution Margin er rangeret efter højeste værdi øverst. Del 2) Du vil gerne forhøje Price Default på de 3 øverste produkter med 20 kr. Hvad gør du? Del 3) Du kommer i tanke om at du også gerne vil kunne se den norske pris i tabellen. Hvad gør du? Del 4) Du ønsker nu kun at kunne se de produkter du har ændret i tabellen. Hvad gør du? 126

135 Opgave 4: Del 1) Du ønsker nu at få vist mere information om det øverste produkt i tabellen. Hvad gør du? Del 2) Du kan nu se en graf over solgte produkter indenfor det sidste år samt en valutaomregner. Du overvejer at øge prisen på produktet med 15,- kr. Du ønsker at se hvad denne nye pris svarer til i andre valutaer. Hvad gør du? Del 3) Du kan nu blandt andet se prisen i svenske kroner i valutaomregneren (OBS! Sig ikke en pris der ikke findes i forvejen!). Du ønsker nu at ændre den oprindelige svenske pris til den nye omregnede svenske pris. Afrund til nærmeste heltal. Opgave 5: Del 1) Du er tilfreds med dine ændringer og ønsker at gemme dem til din Magento webshop. Hvad gør du? Del 2) Som den sidste ting vil du gerne logge ud af Price Optimizer. Hvad gør du? Udførelse af Instant Data Analysis Til udførelsen af IDA-metoden blev rollerne datalogger og testleder, som beskrevet i afsnit , uddelegeret. Dataloggerens opgave i testen var et tage noter, som kunne benyttes under brainstormen. IDA-metoden introducere en rolle, IDA-facilitator, som har til ansvar at styre den efterfølgende brainstorm. IDA-facilitatoren er ikke med under selve testen da idéen er at få en udefrastående med når usability-problemerne skal diskuteres. Det blev fravalgt at have en IDA-facilitator da projektgruppen anså det som en god mulighed for at få praktisk erfaring med usability-testing, at spille en mere aktiv rolle i forbindelse med testen. IDA-metoden foreskriver at man ikke optager testpersonen, samt skærmen, som bliver benyttet til testen. Det blev alligevel gjort af to grunde. For det første stillede usability-laboratoriet det nødvendige udstyr til rådighed. Derfor krævede det ikke nogen større indsats for projektgruppen at opstille det elektronisk udstyr. For det andet kan optagelserne anvendes til at gå tilbage og se hvordan testpersonen interagerede med systemet ved tvivlssituationer. Der var således behov for en videooperatør. Testmiljøet til usability-testen var usability-laboratoriet på Cassaopia, Aalborg Universitet. Figur 13.3 viser hvorledes testrummet var opstillet. I dette rum befandt testpersonen samt testlederen sig. Det blev valgt at benytte usability-laboratoriet da testrummet ikke adskiller sig markant fra et kontormiljø og på den måde vil give et realistisk billede af miljøet det endelige system skal anvendes i. En testsession foregik på følgende måde: Testpersonen blev vist hen til testrummet hvor testlederen bød velkommen samt gav en introduktion til hvordan testen ville forløbe. Introduktionen kan ses i bilag B.2. Heref- 127

136 Figur Usability-laboratoriets testrum hvor testpersonen samt testlederen opholdte sig under udførelsen af testen ter udførte testpersonen de beskrevne opgaver i afsnit som testlederen læste højt. Under udførelsen af hver opgave tænkte testpersonen højt om hvordan personen mente opgaven skulle løses, hvad der overraskede samt hvad der ellers faldt testpersonen ind. Som det kan ses på figur 13.4 kunne observatørerne både følge med på videoskærmene samt gennem spionspejlet. Samtalen mellem testpersonen og testlederen, samt hvad testpersonen tænkte højt under udførelsen af opgaverne, kunne dataloggeren høre ved hjælp af mikrofoner der var opstillet i testrummet. Efter testen blev testpersonen ført til et andet lokale hvor debriefing-interviewet fandt sted. Det blev udført som et semi-struktureret interview hvor testpersonen var alene med en af observatørerne. Formålet var at testpersonen her fik mulighed for yderligere at kommentere på prototype 3, uden at føle sig observeret og overvåget, i mere afslappede omgivelser. Efter testpersonerne havde været igennem usability-testen udførte gruppemedlemmerne en brainstorm og dataanalyse-session. Her blev blev de observerede usability-problemer, samt feedback fra de semi-strukturerede interviews, skrevet op på et whiteboard. De opstillede punkter blev delt op i usability-problemer og features da en del af punkterne var funktioner som testpersonerne mente ville kunne gøre systemet bedre, men som ikke var usabilityproblemer. Usability-problemerne blev herefter inddelt i tre kategorier, kosmetisk, seriøs og kritisk ud fra kriterierne beskrevet i afsnit Resultatet af brainstormen og dataanalysen blev en liste med rangerede usability-problemer som kan ses i det kommende afsnit. 128

137 Figur Kontrolrummet hvor observatørerne kunne observere testen uden at forstyrre testpersonen Resultat af Instant Data Analysis-testen & debriefing Til usability-testen af prototype 3 var der blevet skabt kontakt til seks testpersoner der indvilligede i at deltage. I tabel 13.2 kan kan der ses køn, alder, job, IT-erfaring samt Magento-erfaring for hver enkelt testperson. Fem af testpersonerne var erfarne ITbrugere da de enten var IT-studerende eller benyttede IT-løsninger i deres daglige arbejde. Eftersom systemet er udarbejdet til brugere, der har erfaring med at benytte regneark i deres daglige arbejde, anses de fem testpersoner for at være repræsentative for målgruppen til det endelige system. Der blev derudover valgt at benytte en testperson med ringe ITkundskaber for at teste systemets brugbarhed overfor en person, der givetvis vil have en anden mentalmodel af systemet, end de andre testpersoner. I forbindelse med udførelsen af opgaverne var der ingen af testpersoner der gik helt i stå. Men som forventet havde testperson Kvinde B større vanskeligheder med at gennemføre opgaverne hvilket fremgår af tabel 13.3 hvor tiderne for udførsel af opgaverne er samlet. Således brugte Kvinde B omkring tre gange så lang tid på at løse alle opgaverne i forhold til de resterende fem testpersoner. Specielt opgave 1, hvor testpersonerne blev bedt om at ændre prisen på de tre øverste produkter i tabellen, var svær for Kvinde B. Hun brugte 10:22 minutter på opgave 1 alene. De resterende testpersoner var hurtigere til at gennemskue at priserne, på de enkelte produkter, kunne ændres i tabellen. Generelt var der forvirring første gang der skulle ændres en pris i prototype 3. Denne forvirring opstod af at prisen ser statisk ud i tabellen og der ikke er nogen indikation af at den kan ændres, se Sektion B, figur Således er fejl 1, 2, 3 og 12 under Fejl fundet i forbindelse 129

138 Køn Alder Job IT-erfaring Magentoerfaring Kvinde (A) 20 IT-studerende Studiemedarbejder Ingen hos Coolshop Kvinde (B) 25 Lærerstuderende Erfaring til Ingen brugsbehov Mand (A) 23 IT-studerende Har arbejdet Har lidt erfa- med at ring med Ma- se og ændre gento tabeldata Mand (B) 24 IT-studerende Programmør Ingen hos Intel Mand (C) 30 CEO hos Wexo Meget indenfor Opsætter IT og Magento og modificerer Magento løsninger Mand (D) 30 Direktør for Arbejder til Har erfaring Sinful daglig med med opsætning Excel af Magento webshop Tabel Information om testpersonerne til usability-testen af prototype 3 med tabellen, i nedenstående liste af usability-problemer, afkommet af forkert mentalmodel af prisændring på et produkt. Testpersonerne var ligeledes i tvivl om hvornår de skulle benytte Save to Magento - knappen. Formålet med denne knap er at gemme ændringerne til Magento-databasen og således opdatere priserne på webshoppen når brugeren af systemet er færdig med at foretage alle ændringer. Mange af testpersonerne benyttede Save to Magento -knappen hver gang de havde foretaget en prisændring på et produkt. Det medførte at systemet føltes langsomt for testpersonerne da opdateringen af Magento-databasen samt reindexering kan tage op til flere minutter, afhængig af internetforbindelsen. Ligeledes var enkelte testpersoner i tvivl om hvad der var sket efter Save to Magento var færdig med at opdatere og gav brugerne lov til at benytte systemet igen. Herunder er de observerede usability-problemer i forbindelse med testen listet. Problemerne er inddelt i fire sektioner alt efter om de er observeret i forbindelse med knapper, med tabellen, med menuen eller i forbindelse med navigationsbaren samt valutakursen. Ligeledes er de blevet vurderet ud fra samme kriterier som i afsnit med om problemet er af kosmetisk, seriøs eller kritisk karakter. De fire sektioner af prototype 3 kan ses på figur Fejl fundet i forbindelse med knapper (Sektion A, figur 13.5) 1. Save to Magento tager lang tid. (Seriøs) 2. Tvivl om hvad der er ændret efter tryk på Save to Magento. (Kosmetisk) 130

139 Opgave Testperson Samlet tid Kvinde A 02:02 01:56 01:22 01:51 00:51 08:02 Kvinde B 10:22 04:16 07:20 04:36 01:19 27:53 Mand A 03:11 03:00 02:53 02:42 00:30 12:16 Mand B 01:20 01:45 01:27 01:09 00:56 06:37 Mand C 02:27 02:29 02:22 01:39 01:18 10:15 Mand D 02:30 01:45 02:05 00:49 01:58 09:07 Gennemsnit 03:39 02:32 02:55 02:08 01:09 12:22 Tabel Tabellen angiver hvor lang tid hver testperson var om at udføre de enkelte opgaver. Derudover kan der ses et gennemsnit af tiden der blev brugt til hver opgave 3. Efter tryk på Save to Magento blev alle fravalgte kolonner også vist. (Kritisk) 4. Forkert mentalmodel af Save to Magento. Tror man skal trykke på knappen hver gang man har lavet en ændring. (Seriøs) 5. Føler at Clear Changes tager lang tid. (Kosmetisk) Fejl fundet i forbindelse med tabellen (Sektion B, figur 13.5) 1. Lidt forvirring om hvad man kan opnå ved at trykke på plus-knappen. (Kosmetisk) 2. Ikke åbenlyst hvordan man kan ændre en pris på et produkt. (Kritisk) 3. Priserne på et produkt ser statiske ud. (Kritisk) 4. Ved prisændring opstår der fejl. Kommer til at trykke på sortering eller en anden pris. (Seriøs) 5. Navngivningen Default skaber forvirring. (Kosmetisk) 6. Hover-effekten ved mus over produkterne i tabellen er ikke tydelig. (Kosmetisk) 7. Tror pilene ved kolonnenavnet i tabellen er sorteringsknapper (Kosmetisk) 8. Hvis man ved en prisændring kommer til at trykke på sortering ændres farven på rækken ikke til rød. (Kosmetisk) 9. Ved drag & drop af en kolonne ændrer checkboxenes funktion således at et check i en checkbox fjerner en kolonne og omvendt. (Kritisk) 10. Testperson tror man kan fjerne en kolonne ved drag & drop. (Kosmetisk) 11. Rød farvemarkering af en række ved prisændring giver indtryk af at man har lavet en fejl. (Seriøs) 12. Tror man kan ændre prisen på et produkt ved valutaomregneren. (Seriøs) 13. Tror pilene hører til kolonnen ved siden af. (Kritisk) 14. Forkert mentalmodel af valutaomregneren. Tror den kan ændre prisen på produktet. (Seriøs) 15. Ikke tydeligt hvilken pris man har ændret på et produkt når hele rækken bliver rød. (Kosmetisk) Fejl fundet i forbindelse med menuen (Sektion C, figur 13.5) 131

140 1. Ved tryk på Menu hide skaber hide animationen forvirring. (Kosmetisk) 2. Når menuen er gemt væk må der gerne være en pil eller anden indikation om at man kan få menuen frem. (Kosmetisk) 3. Ikke tydeligt at man kan folde menuen for landende ud ved tryk på de forskellige headers. (Kosmetisk) 4. Kolonnebredden er ikke dynamisk efter indholdet i kolonnen. (Kosmetisk) 5. Ved tryk på plus-knappen på et produkt ændrer rækken farve på det pågældende produkt. (Kosmetisk) 6. Margen på kolonnerne er ikke vertikalt på linje med kolonnenavnet. (Kosmetisk) Fejl fundet i forbindelse med navigationsbaren samt valutakurs (Sektion D, figur 13.5) 1. Vil gerne have et rigtigt logo i stedet for en tekstknap. (Kosmetisk) 2. Valutainfo i højre hjørne skaber forvirring. Er i tvivl om hvad det er. (Kosmetisk) 132

141 133 Figur Skærmbillede af prototype 3 delt ind i fire sektioner

142 13.4 Evaluering af 3. iteration Der blev i alt fundet 5 kritiske, 6 seriøse og 17 kosmetiske fejl i forbindelse med usabilitytesten af prototype 3. Tre af de kritiske fejl opstod i forbindelse med forkert mentalmodel af, hvordan man ændrer priser på produkter i tabellen, samt hvornår Save to Magento - knappen skal benyttes. Af de i alt 28 fundne usability-problemer var følgende fejl, som projektgruppen kendte til i forvejen. Fejl 3 i Fejl fundet i forbindelse med knapper samt fejl 9 i Fejl fundet i forbindelse med tabellen. Fejlene skyldtes at systemet var en prototype under udvikling. Begge fejl blev vurderet til at være kritiske. Således skyldtes tre af de kritiske fejl at testpersonerne havde forkert mentalmodel af systemet. De to resterende kritiske fejl, udsprang af fejl i systemet, som projektgruppen var klar over inden testen. Den 4. fejl i forbindelse med knapper, Forkert mentalmodel af Save to Magento. Tror man skal trykke på knappen hver gang man har lavet en ændring, blev vurderet til seriøs. Dette var en fejl, som optrådte flere gange, og har haft stor betydning for, hvorvidt testpersonerne mente at systemet var for langsomt. Fejlen kan ligge i, at projektgruppen her har taget et forkert designvalg, da knappen som standard er udtonet. Ved blot én prisændring fremhæves knappen, hvilket kan skabe en forventning om, at der skal trykkes på knappen. Trykkes der ofte på knappen, vil brugeren opleve meget ventetid, hvilket kan få systemet til at virke ineffektivt. Der vil i den kommende iteration blive lagt vægt på at udbedre de kritiske fejl. Fejltype Kritisk Seriøst Kosmetisk Antal fejl Tabel Antal fejl fundet i forbindelse med IDA-testen inddelt i de tre typer kritisk, seriøs eller kosmetisk 134

143 4. iteration 14 Fjerde iteration var den sidste i projektforløbet og der blev derfor lagt vægt på at afrunde og færdiggøre systemet. Det var derfor nødvendigt at prioritere forskellige funktioner og fejlrettelser da det ikke var muligt at implementere alt Valg & fravalg Efter usability-testen i 3. iteration blev der fundet frem til fem fejl af kritisk karakter, samt flere seriøse og kosmetiske fejl, se afsnit Ud fra disse fejl samt interviewet med Tonny Andersen blev der fundet frem til flere funktionaliteter der manglede i systemet. Nedenfor er der opstillet en liste over de forskellige funktionaliteter. Ideelt skulle funktionerne implementeres i systemet, men af tidsmæssige årsager var det ikke muligt, og det var derfor nødvendigt at prioritere funktionerne og fravælge de mindre vigtige. Mange af funktionerne er Could have -funktioner [7, p. 140], der ikke er vigtige for systemets hovedformål, effektiv prisregulering, og er derfor blevet fravalgt. Vis tidsestimat ved loading Alertboxe ved Save to Magento Antal varer på lager Dækningsbidrag efter laveste værdi af pris eller tilbudspris Faktor på valutakurser Følg leverandørpriser Graf over prishistorik Internetkontrol Specifikke ændringer i fed skrift Muligt at se og ændre tilbudsprisen for hvert land Håndtering af komma ved prisændringer 135

144 Ved lukning af browser skal brugeren spørges om vedkommende ønsker dette Graf med salg, konverteringsfrekvens og antal produktvisninger Hjælpeoverlay Sekundær og tertiær sortering Webcrawler Tilføj flere brugere Indstillingsprofiler Implementerede funktionaliteter Vis tidsestimat ved loading Under usability-testen, se afsnit 13.3, blev der fundet frem til, at det implementerede venteoverlay, der viser en loadingbar når systemet arbejder, gav testpersonerne en god forståelse for at de skulle vente. Testpersonerne blev dog hurtigt irriterede da der ikke var nogen indikation om hvor lang tid de skulle vente eller hvorfor de skulle vente. Det blev derfor diskuteret om der skulle implementeres et tidsestimat over hvor lang ventetid der var. Dette ville være svært da tiden det tager at gemme prisændringerne til Magento kan variere efter internethastighed, trafik på siden og serveren Magento-løsningen er installeret på. Det blev derfor besluttet at hjælpeoverlayet i stedet skulle give besked til brugeren om hvad der blev arbejdet på. Dette vil gøre at brugeren er informeret om hvorfor systemet arbejder og derved fjerne en stor del af irritationsmomentet. Alertboxe ved Save to Magento Systemet har en knap der synkroniserer de ændrede priser til Magento webshoppen. For at undgå at brugeren benytter knappen ved en fejl skal brugeren spørges om vedkommende er sikker på at denne vil gemme de foretagede ændringer. Antal varer på lager Det var et ønske at kunne se antal varer på lager i tabellen. Dette var for klienten Tonny Andersen et ønske da han brugte det til at prisbestemme produkterne. Dækningsbidrag efter laveste værdi af pris eller tilbudspris Dækningsbidraget blev indledningsvis beregnet ud fra et produkts indkøbspris og produktets normale pris. Dette skal beregnes efter den laveste værdi af pris eller tilbudspris. Faktor på valutakurser Ifølge klienten blev priserne i de forskellige lande ikke udelukkende sat ud fra valutakursen. For eksempel nævnte klienten Tonny Andersen at priserne i Norge gerne er højere end Danmark. Det blev derfor besluttet at det skulle være muligt at indtaste en brugerdefineret faktor for hvert land tilkoblet webshoppen, som vil blive ganget på i valutaomregneren. 136

145 Følg leverandørpriser Ifølge Tonny Andersen har Sinful produkter hvor der er sat en vejledende pris fra leverandørens side. Tonny har derfor en indstilling i Magento til hvert produkt der fortæller om prisen følger leverandørens vejledende pris. Dette ønskes at kunne ses i systemet. Graf over prishistorik Et ønske fra klienten Tonny Andersens side var muligheden for at kunne se en prishistorik på hvert enkelt produkt. For at kunne vise dette krævede det at hver enkel prisændring blev gemt i systemets database. Det blev derfor valgt at systemet skulle opdatere en prishistorik hver gang systemet gemte prisændringer til Magento. Dette er beskrevet i afsnit Internetkontrol Når der skal gemmes prisændringer til Magento skal det først kontrolleres om brugeren har internet. Hvis brugeren ikke har internetadgang risikerer brugeren at miste alle ændringer. Specifikke ændringer i fed skrift Det skal være muligt at se den specifikke pris man har ændret ved at den er skrevet med både kursiv og fed skrift. Muligt at se og ændre tilbudsprisen for hvert land Ud over de normale priser i forskellige lande, skal det være muligt at ændre tilbudsprisen. Håndtering af komma ved prisændringer Da Magento opfatter punktum som komma skal brugerens input laves om så det passer med at punktum er decimaladskiller. Ved lukning af browser skal brugeren spørges om vedkommende ønsker dette Hvis brugeren lukker systemet mister vedkommende alle ændringer. Der skal derfor være en sikkerhed, der gør at brugeren ikke mister sine ændringer ved en fejltagelse. Graf med salg, konverteringsfrekvens og antal produktvisninger Ud fra det indhentede data fra Google Analytics skal der vises en graf over konverteringsfrekvensen på produktet. Dette data er tilgængeligt igennem Google Analytics. Da det endeligt lykkedes at få data fra Google Analytics i slutningen af iterationen, var det ikke muligt at nå at lave en metode til at behandle det hentede data og vise det. Hjælpeoverlay Ud over de nævnte funktionaliteter ovenfor blev det også besluttet at implementere et hjælpeoverlay i systemet. Dette blev besluttet, da det vil kunne afhjælpe otte af de fejl, der blev fundet under usability-testen. Det stemte endvidere godt overens med kriteriet Brugbart fra afsnit 7.1, hvor dette blev sat til at være meget vigtigt. Ved hjælpeoverlayet får brugeren information omkring hvad, systemet foretager sig, hvilket er med til at skabe mindre forvirring i brugergrænsefladen. Samtidig kan der stadigt opholdes en høj effektivitet i systemet, hvilket var et krav, vurderet som vigtig. Endvidere er det med et hjælpeoverlay muligt for nye brugere at lære, hvordan systemet fungerer, samtidig med at øvede bruger kan ignorere den. 137

146 Fravalg Sekundær og tertiær sortering Sekundær og tertiær sortering skulle for eksempel gøre det muligt for brugeren først at sortere produkterne efter pris og derefter navn. Dette skulle så give alle produkter med højest pris først. Hvis to produkter havde samme pris skulle de sorteres efter navn. På daværende tidspunkt var det kun muligt at sortere efter en parameter af gangen. Denne funktion blev udelukkende nævnt af en enkelt testperson fra usability-testen under et af debriefing-interviewene. Funktionen var heller ikke interessant for Tonny Andersen, hvorfor det ikke blev anset som en nødvendighed for systemet og den blev derfor fravalgt. Webcrawler Webcrawleren blev fravalgt da det ikke var et stort ønske fra Tonny Andersens side. Derudover ville webcrawleren være en meget tidskrævende funktion at implementere. Tilføj flere brugere Med funktionen Tilføj flere brugere menes muligheden for at kunne oprette en ekstra konto til en salgsassistent som kun vil begrænset adgang til funktioner i systemet. Dette blev fravalgt da det ikke havde direkte indvirkning på systemets virke eller funktionalitet. Indstillingsprofiler Indstillingsprofiler skulle give brugeren mulighed for at gemme hvilke kolonner der skulle vises som standard så vedkommende hurtigt kunne få vist den produktdata der skal bruges. Denne funktion vil kunne optimere arbejdsprocessen for Tonny Andersen. Funktionen blev udelukkende nævnt af Tonny under interviewet som en Want to have but Won t have this time round -funktion [7, p. 140], men blev ikke fundet under usability-testen, se afsnit Grundet dette og omfanget af en eventuel implementering blev denne funktion også fravalgt. 138

147 14.2 Test af prototype 4 - Price Optimizer (Beta) Som afslutning på 4. iteration blev der foretaget en funktionel test af prototype 4 s funktionalitet for at verificere at prototypen opfyldte de funktionelle kriterier opstillet i afsnit 7.1. I kapitlet vil der benyttes Testing Overview and Black-Box Testing Techniques [41] som primær kilde Funktionel test I en funktionel test benyttes black-box-test til at verificere at et givet input resulterer i et forventet output. Black-box ignorerer de interne mekanismer i systemet eller komponenten der bliver testet og fokuserer udelukkende på om outputtet stemmer overens med det forventede resultat ud fra et givet input. Funktionelle test bliver benyttet til at sikre at de funktionelle krav til systemet er opfyldt. Normalt benyttes en kravspecifikation til at udarbejde forskellige testscenarier. Eftersom der i dette projekt er arbejdet ud fra den iterative udviklingsmodel benyttes de funktionelle kriterier i afsnit 7.1 til at opstille forskellige testscenarier. Således vil kriterierne pålideligt, korrekt og sikkert være de kriterier der bliver testet ved hjælp af den funktionelle test. Ideelt set skulle man teste ethvert tænkeligt scenarie ved hjælp af black-box-test. Da det vil være en tidskrævende process er strategien for den funktionelle test at udarbejde scenarier som en given bruger af systemet ofte vil benytte. Målet er at finde så mange fejl som muligt ved hjælp af få testscenarier. Til udformningen af testscenarierne vil der blive benyttet Four-item -testskabelonen [41] hvor hvert testscenarie får et ID, en beskrivelse af hvad og hvordan der testes, et forventet resultat samt det faktiske resultat. Resultatet af testscenarierne vil være at finde i bilag B Funktionel test af kriteriet Sikkert Til udarbejdelse af den funktionelle test af sikkerheden blev følgende scenarier testet. 1. At tilgå domænet samt subdomæner uden at være logget ind. 2. At tilgå API-endpoints uden at at være logget ind. 3. At teste login-formen for: a) Det ikke er muligt at indsætte null værdier. b) skal indeholde og et punktum. c) Skal kunne håndtere special tegn i passwordet ved registering af ny bruger. d) Ikke kunne registrere en ny bruger med samme . e) Der ved registrering af en ny bruger er kodeordet på mindst seks tegn. Testscenarierne vedrørende at prøve at tilgå domænet samt subdomænerne til systemet uden først at være logget ind viste at systemet håndterede forespørgslerne korrekt og afviste uautoriserede brugere, se Test ID 1-3 bilag B

148 Ved test af om det var muligt for uautoriserede brugere at sende forspørgsler til systemets API-endpoints viste testscenarierne at det ikke er muligt at tilgå data man ikke er autoriseret til. Der var dog det forbehold at ud af de otte testscenarier, se Test ID 4-11 bilag B.3, afveg fem af scenariernes faktiske resultat fra det forventede. I stedet for at afvise den uautoriserede bruger gav systemet i stedet en fejlmeddelelse om at det ikke var muligt at tilgå dataen. Sikkerhedsmæssigt gør det ikke nogen forskel, men for et konsistent brugergrænseflade-design vil det være optimalt hvis den uautoriserede bruger i stedet blev afvist. De resterende testscenarier for sikkerheden i systemet omhandlede brugen af login samt at oprette en ny bruger, se Test ID bilag B.3. Det endelige system benytter sig af ASP.NET MVC-frameworkets indbyggede sikkerheds- og indentitetspakker, hvorfor testens fokus var på om pakkerne var implementeret korrekt. Ud af de otte testscenarier returnerede alle test det forventede resultat Funktionel test af kriterierne pålideligt & korrekt Til den funktionelle test af kriterierne pålideligt og korrekt blev der til black-boxtesten anvendt grænseværdianalyse [41]. Grænseværdianalyse er hvor der testes med inputværdier under en given værdi, på den givende værdi og over den givende værdi. Grænseværdianalysen er velegnet til at opdage programmeringsfejl som for eksempel at der er benyttet >= hvor intentionen var at benytte >. Valget af grænseværdianalysen blev taget på baggrund af at systemdefinitionen specificerer at der skal udvikles et system med primært fokus på prisændringer af produkter, se afsnit 3.2. Det er vigtig at kontrollere at systemet håndterer prisændringer korrekt. Til testen blev værdier i tabel 14.1 benyttet. Værdierne blev valgt ud fra følgende kriterier: 1. Hvordan håndterer systemet prisændringer til negative værdier. 2. Hvordan håndterer systemet prisændringer lige under, på og lige over værdien Hvordan håndterer systemet prisændringer til et større, realistisk tal. Langt under Lige under På Lige over Langt over Tabel Grænseværdier til funktionel test af prisændringer Til de forskellige testscenarier blev følgende forudsætning angivet som ligeledes kan ses i tabel Brugeren er korrekt logget ind på systemet og der er hentet 2206 produkter ind i tabellen. For hver grænseværdi i tabel 14.1 blev der udarbejdet et testscenarie hvor prisen blev ændret på henholdsvis Default Price, Danish Price, Swedish Price, Finnish Price og Norwegian Price. Til hvert testscenarie blev det undersøgt om systemet Price Optimizer angav den korrekte indtastede værdi i brugergrænsefladen samt om databasen i henholdsvis MongoDB og Magento MySQL blev opdateret korrekt med den indtastede værdi. I testscenarierne 140

149 er systemet Price Optimizer, MongoDB og Magento MySQL angivet som henholdsvis PriceOpti, Mongo og Magento af hensyn til pladsen. Listen med testresultaterne af den funktionelle test af prisændringer kan ses i bilag B.3. Test ID 21 Beskrivelse Forudsætning: Brugeren er korrekt logget ind på systemet og der er hentet 2206 produkter ind i tabellen. Ændre Defalut Price på produktet "Aneros HELIX Prostata Stimulator"til -100 re- Forventet sultat PriceOpti: -100 Mongo: Intet Magento: Intet Tabel Udsnit af testscenarierne til funktionel test af prisændringer Faktiske resultat Testscenarierne til hvordan systemet håndterer negative tal gik alle sammen igennem, se Test ID bilag B.3. Således ændrede Price Optimizers brugergrænseflade det indtastede negative tal til produktets nye pris. Da det ikke er en lovlig handling at ændre en produktspris til et negativt tal blev denne pris ændret tilbage til den oprindelige pris ved tryk på Save to Magento. Tryk på Save to Magento betyder at brugeren har trykket på knappen Save to Magento i brugergrænsefladen i Price Optimizer og at systemet prøver på at opdatere henholdsvis MongoDB- og Magento databasen. Hverken MongoDB eller Magento gemte den negative værdi i databasen hvilket var korrekt håndteret. Det vil ikke give mening at brugeren skulle have lov til at indtaste et negativt tal i Price Optimizer, men det er et usability spørgsmål der ikke berøres i den funktionelle test. Ved testscenarierne hvor produktpriserne blev sat til 0, se Test ID bilag B.3, fejlede alle testene for brugergrænsefladen i Price Optimizer. Når en produktpris blev ændret til 0 angav systemet i stedet for prisen til - hvilket i tabellen betyder der ikke er sat en pris på det pågældende produkt. Denne fejl kan føre til at brugeren ikke tror det er muligt at ændre prisen på det pågældende produkt da systemet ikke kan håndtere priser der ikke allerede er angivet til en værdi. Til gengæld blev prisen korrekt gemt i både MongoDB- og Magento databasen, hvor den blev angivet til at være 0. Således er det en renderingsfejl af tabellen i brugergrænsefladen i Price Optimizer. Testscenarierne hvor produktpriserne bliver testet først med 1 og derefter , se Test ID bilag B.3, gav følgende resultat. Testscenarierne med Default Price, Swedish Price, Finnish Price og Norwegian Price gik alle sammen igennem både ved korrekt håndtering i brugergrænsefladen af Price Optimizer samt korrekt lagring i MongoDBog Magento databasen. Til gengæld fejlede lagringen af Danish Price prisændringerne til MongoDB- og Magento databasen. Prisændringen blev korrekt håndteret i brugergrænsefladen i Price Optimizer, men ved tryk på Save to Magento ændrede prisændringen tilbage til det oprindelige udgangspunkt. Grunden til dette var at Danish Price som den eneste pris på produktet ikke var angivet. Det vil sige den den ikke var blevet oprettet i Magento databasen. Før den funktionelle test havde projektgruppen en antagelse om at det ikke var muligt at prissætte et produkt der ikke allerede havde en pris i Magento. Denne antagelse blev bekræftet af den funktionelle test af prisændringer. 141

150 14.3 Evaluering af 4. iteration Den 4. iteration var den sidste. Der blev derfor ikke udført en usability-test med Tonny i denne del, da der ikke kunne opstilles nye krav til ekstra funktioner. Til sidst i 4. iteration aftestede projektgruppen systemet ved at benytte en funktioneltest. Der blev desuden taget kontakt til Tonny, således han kunne give sin mening vedrørende systemet. Nedenfor evalueres Tonnys konklusion på systemet. Indledningsvis i projektet var Tonny Andersens grundlag for at deltage, at han ønskede at få et færdigt system eller værktøj, for lettere at kunne prisregulere produkterne i sin webshop. Denne premis føler projektgruppen er opnået, da der er blevet udviklet et system, hvor Tonny igennem en webapplikation kan tilgå og administrere produkterne. Det vil med tiden komme til at erstatte hans nuværende system og blive et intergrereret værktøj i Sinful. For at konkludere på, hvorvidt Tonny føler, at opgaven er fuldført, blev der til sidst i projektet taget kontakt til ham via . Et omdrejningspunkt i rapporten har været brugbarhed. Derfor ønskede projektgruppen at Tonny skulle konkludere på, hvorvidt Price Optimizer var brugbart for ham. Til dette svarede Tonny Price Optimizer er meget brugbart og er på mange punkter meget bedre og mere effektiv end de to muligheder vi har haft for at ændre priser tidligere, som er;, se bilag A.4, - hvorefter han beskriver den besværlige prisændringsmetode i Magento, samt det langsomme Excelark. Et andet vigtigt punkt igennem rapporten har været effektivitet. Her vurderer Tonny på 3 parametre; Hastighed, arbejdstiden brugt på at udføre en opgave og overskuelighed, som han henholdsvis tildeler karaktererne 8, 7 og 9 på en skala fra 1 til 10, hvor 10 er den højeste værdi. Til sidst i iterationen blev der lavet et endeligt klassediagram over, hvordan systemet så ud. Det blev lavet ved brug af Visual Studio, og inkluderer alle attributer og metoder for modelklasserne. Klassediagrammet kan ses på figur E.1 i bilag E. 142

151 Del VI Rapportafslutning 143

152 Afrunding 15 Afslutningsvis skal rapporten, det udviklede system og projektarbejdet afrundes. Dette gøres i tre dele, henholdsvis diskussion, konklusion og perspektivering. I hvert afsnit vil det gennemgås hvilke elementer, der er opfyldt, hvilke der er opfyldt i mindre grad, hvad der er opnået, samt en beskrivelse af hvad eventuelt videre arbejde kan indebære Diskussion Dette semester stillede krav til, at der skulle findes en informant samt udvikles et system, som kan løse et virkelighedstro problem. Derfor blev der i dette projekt fundet en klient, som manglede et nyt system. I et systemmæssigt perspektiv har dette projekt været det hittil mest komplekse og omfattende på Software-uddannelsen. Derudover har projektgruppen haft et højt ambitionsniveau. Dette skyldes dels projektgruppens egne aspirationer og dels klientens ønske om et fuldt anvendeligt system efter projektets afslutning. Samarbejdet har medført ny viden og erfaring indenfor samarbejde med en aktiv klient Arbejdet med informanten Tonny Andersen Samarbejdet med klienten Tonny Andersen og Sinful blev opnået efter opsøgende adfærd fra projektgruppens side. Et af projektgruppens medlemmer havde kendskab til virksomheden og Sinful blev derfor kontaktet, med henblik på at undersøge mulighed for et samarbejde samt hvorvidt Sinful havde problemstillinger, relevante for semesterets krav. Overordnet har samarbejdet været særdeles vellykket.tonny Andersen har haft indflydelse på systemets udvikling ved at deltage som aktiv sparringspartner i den iterative udviklingsproces. Derudover har Tonny Andersen været yderst hjælpsom og har deltaget i flere usability-test og interviews. Samarbejde med en klient giver også besværligheder og udfordringer. Da der skulle udvikles med realistisk data fra Sinfuls webshop krævede det forskellige dumps af deres database. Grundet travlhed hos Sinful samt at det var en anden medarbejder end Tonny Andersen, der skulle lave dumpet, tog dette lang tid. Dette skyldes at der ikke var mulighed for aktiv kommunikation med den anden medarbejder, samt at denne ikke prioriterede opgaven i samme grad som projektgruppen, hvorfor forventningene ikke var afstemt. Datadumpet kunne med fordel være brugt tidligere, da det dannede grundlag for 144

153 den indledende udvikling af systemet og dermed sinkede udviklingsprocessen. Dette var i høj grad forsaget af, at datadumpet indeholdt oplysninger om opbygningen af Magentodatabasen ved flere lande tilkoblet den samme webshop. Dermed var det ikke muligt at implementere håndteringen af flere lande og produktdata for de respektive lande før dumpet blev modtaget. Da datadumpet blev modtaget fra Sinful anvendte systemet oplysninger omkring Sinfuls webshop, som for eksempel indkøbspris, hvilket Sinful ikke ønskede andre fik adgang til. Dette gjorde at der måtte sættes IP-restriktion på de anvendte udviklingsservere for at nægte uvedkommende adgang. Forløbet med aktiv sparring med klienten, forsinkelser grundet manglende data fra klientens side samt vigtigheden af anvendelsen af et udviklingsmiljø, gav projektgruppen et indgående indblik i at samarbejde med en virksomhed. Der blev opnået erfaring omkring vigtigheden af et tæt samarbejde med klienten under udviklingsforløbet og en iterativ opfølgning på forventningsafstemningen mellem udviklerne og klienten, således der ikke opstår misforståelser. Dette kunne med fordel have været anvendt mere aktivt i forbindelse med udvekslingen af data, hvormed forsinkelser kunne have været undgået Den iterative arbejdsproces På dette semester skulle der enten arbejdes iterativt eller efter vandfaldsmodellen. Ved vandfaldsmodellen udarbejdes analysen, alle funktioner til systemet fastlægges og designet af brugergrænsefladen bestemmes inden udviklingen af systemet påbegyndes. Ved den iterative arbejdsproces deles projektet ind i mindre faser, hvor alle elementer af både rapporten og systemet vurderes under hver iteration. Da der blev samarbejdet med en reel klient, blev det vedtaget at arbejde iterativt, hvilket var en ny erfaring for alle projektgruppens medlemmer. Den iterative udviklingsmetode medførte at Tonny Andersen havde mulighed for at komme med nye forslag eller ændringer til hvordan systemet skulle opbygges, undervejs i forløbet. Dette menes at have haft en positiv effekt på udviklingen af systemet, da samarbejdet med Tonny Andersen har affødt en del funktioner, som der ikke var tænkt over i begyndelsen af projektforløbet. Dette har betydet at der er udviklet et system bedre tilpasset klientens behov end hvis der var blevet anvendt vandfaldsmetoden. Modsat den anvendte iterative udviklingsproces understøtter vandfaldsmodellen ikke samme niveau af løbende evaluering og aktiv sparring med klienten. I forbindelse med det iterative arbejde er der aktivt benyttet prototyping, hvor der først blev lavet en skitse over brugergrænsefladen, og det blev overvejet hvilke funktioner der skulle implementeres. I hver iteration blev der udarbejdet prototyper, som igennem projektet blev forbedret. De første prototyper blev udarbejdet ved at lave skitser der repræsenterede projektgruppens forestilling af systemets brugergrænseflade. De blev fremstillet i programmet Balsamiq [42], som har en række elementer, man kan drag n droppe, således der kan laves en skitse. Fordelen ved dette var, at der hurtigt kunne laves flere skitser, og de skitser, der ikke skulle benyttes, var der ikke blevet brugt lang tid på at udarbejde. Denne fremgangsmåde var baseret på princippet omkring designed to be produced quickly, and thrown away as quickly. [7, p. 177]. Det medførte at der hurtigt blev udviklet en række ideer til designet, hvoraf der kunne testes, hvilket design af 145

154 brugergrænsefladen, Tonny Andersen ønskede. Det var en stor fordel, da der dermed ikke blev implementeret noget, som Tonny Andersen fandt nytteløst. Umiddelbart efter klientens ønskede design var fundet, kunne udviklingen af prototype 2 påbegyndes. Det blev bestemt at prototype 2 skulle være en fungerende webapplikation, hvorefter udviklingen kunne påbegyndes. Hvad der skulle implementeres i prototype 2 var godt planlagt, men der blev ikke nået så meget, som først antaget, hvilket hovedsageligt skyldes manglende dump af Sinfuls database. Her var det en fordel med den iterative udviklingsproces, da der kunne læres af og anvendes erfaringer fra iterationen i næste iteration. Den iterative arbejdsproces er ideel, ved udvikling af systemer, hvor brugerens krav hele tiden kan revideres. Dette betyder dog, at omfattende planlægning er nødvendigt. I starten af projektet blev det antaget, at det for hele semestret kunne planlægges, hvor meget der skulle implementeres og hvor meget der skulle nås i hver iteration. Dette var ikke tilfældet. Det var i løbet af projektet nødvendigt at omstrukturere tidsplanen flere gange. Derudover kom det bag på projektgruppen hvor meget JavaScript-kode, som egentligt skulle benyttes. Dette resulterede i en meget stor Index-fil, som kunne være svær at overskue. Dette kunne have været forudset, hvis der havde været en fastlagt og struktureret opbygning af koden ved hjælp af vandfaldsmodellen. En af de største udfordringer ved det iterative arbejde, var at strukturere rapporten. Da ingen i projektgruppen havde dokumenteret en sådan fremgangsmåde før, blev det diskuteret flere gange, hvordan rapporten skulle opbygges. Dette betød, at rapporten flere gange har ændret struktur. For eksempel har iterationerne ændret placering i rapporten flere gange da det var svært at dokumentere den iterative metode på en sådan måde at det gav mening for en udeforstående læser Udvikling af et system ved brug af OOA&D På dette semester blev der introduceret metoder, omhandlende hvordan der arbejdes korrekt i forhold til objektorienteret analyse og design, ved udvikling af softwaresystemer. Ved at benytte de lærte metoder fra undervisningen i OOA&D, kunne systemet defineres på en ny måde. Her menes der blandt andet med hensyn til systemdefinitionen, hvor essensen med systemet defineres, samt problem- og anvendelsesområdet. Disse metoder kan klart benyttes i kommende projekter. Eftersom det var første gang projektgruppen afprøvede metoderne fra kurset i systemudvikling, blev ikke alt udført fuldstændigt korrekt. Der blev udført nogle aktiviter fra OOA&D med mindre tilfredsstillende resultat i starten af projektet, hvilket resulterede i aktiviteter, som ikke var helt korrekte. Senere i projektet blev der dog opnået forståelse for, hvordan de aktiviteterne skulle udføres korrekt. På det tidspunkt var udviklingen af systemet allerede fremskredent, hvorfor aktiviteterne til implementeringen måtte tilpasses, og ikke den anden vej rundt, som det er tiltænkt i bogen. Dette kan også være en effekt af den iterative arbejdsproces, da der stadig blev gjort erfaringer omkring systemet ved hjælp af implementering i stedet for ved hjælp af analyse. 146

155 Da der blev arbejdet effektivt igennem projektet, var projektgruppen hæmmet af, at projektgruppen var foran kurset i OOA&D. Dermed var aktiviteterne der skulle udarbejdes i forbindelse med projektet ofte ikke blevet gennemgået i kurset. Dette var en stor ulempe, især under analysen af problemområdet, hvilken måtte udsættes til efter kurset havde dækket området. Havde kurset været mere fremskredent i løbet af den første del af semesteret, kunne der have været opnået en mere flydende arbejdsgang med henhold til analyse og design. Da der gennem projektet er arbejdet iterativt med prototyping, har det flere gange været nødvendigt at genoverveje systemet. Dette har medført, at der adskillige gange er blevet redigeret i aktiviteterne i problem- og anvendelsesområdet, hvilket har betydet, at diagrammer og figurer er blev lavet om flere gange. Derfor vurderes det i projektgruppen, at metoderne fra OOA&D henvender sig bedst til vandfaldsmodellen, da systemet ikke ændrer sig så markant, som ved iterativt arbejde Reflektering over kode I dette afsnit, bliver implementering af Price Optimizers kode overvejet og diskuteret. Abstraktion af webshop-databaselaget Det var vigtigt for projektet at Sinfuls Magento-webshop blev understøttet af systemet. Det blev i den forbindelse ikke overvejet om systemet skulle udvikles med henblik på at understøtte andre webshop-løsninger. Arkitekturen kunne have været designet med en abstraktion på den specifikke webshop således andre webshop-løsninger kan understøttes ved at tilføje en konkret implementation der overholder den opstillede abstraktion. Google Analytics Google Analytics blev implementeret i JavaScript på klient-siden i systemet. Den ideelle implementering havde været en server-side-implementation, hvor data fra Google Analytics kunne have været integreret korrekt i systemets model. Dette vil kunne være opfyldt med Googles C#-bibliotek til implementering af Google Analytics. Dette indebærer at systemet og brugeren skal verificere sig selv ved hjælp af OAuth2 [43]. AngularJS Da projektgruppen undervurderede mængden af JavaScript blev der ikke overvejet en struktureringen af JavaScript-koden. Det voksede sig således uoverskueligt i løbet af iterationerne. Index-filen har over 1000 linjer hvor JavaScript udgør en væsentlig del. Strukturen i koden ved andre aspekter i systemet blev overvejet, og der blev taget stilling til hvordan koden skulle struktureres i mønstre. Det samme skulle have været gjort med henblik på struktureringen af JavaScript-koden. Til dette kunne JavaScript-frameworket AngularJS havde været benyttet. AngularJS tilbyder en struktur af JavaScript-kode der kaldes Model-View-Whatever (MVW) [44]. Som navnet antyder, minder det om MVCmønstret. Det er dog ikke fastlagt præcist hvordan det skal implementeres. Idéen bag MVW-mønsteret er at adskille præsentation og logik. Hvordan dette opnås er op til udvikleren. 147

156 En anden ting AngularJS tilbyder er 2-vejs-binding af modellen. Dette tillader en aktiv MVC-implementation i systemets klient som det bliver beskrevet i afsnit

157 15.2 Konklusion Denne rapport er en dokumentation af processen for udviklingen af et system, under tredje semester på Software-uddannelsen på Aalborg Universitet. I rapporten blev der præsenteret overvejelser og resultater foretaget i løbet af projektperioden. Systemet Price Optimizer er udviklet ved brug af den iterative metode og i samarbejde med informant og klient Tonny Andersen. Udviklingen har været succesfuld for både klienten og projektgruppen, da der er udviklet et system som opfylder begge parters ønsker og krav. Projektgruppen har udviklet en ikke-triviel softwareløsning og klienten har fået et værktøj, der forbedrer arbejdsprocessen angående prisregulering i Sinfuls Magento-webshop. Da Tonny Andersen har haft mulighed for at påvirke systemets udviklingsretning, på grund af den iterative udviklingsmetode, endte Price Optimizer ud i et system, som Tonny Andersen var yderst tilfreds med. Projektgruppen har været positiv overfor den iterative arbejdsproces, da det har givet en fleksibel og dynamisk arbejdstilgang til udviklingen af softwareløsningen. På trods af udfordringerne vedrørende rapportstrukturen, mener projektgruppen at rapporten beskriver problemstillingerne på acceptabel vis. Price Optimizer opfylder kravene, som blev stillet i systemdefinitionen. Platformsuafhængighed er opnået, da systemet tilgås gennem en webapplikation, som ikke er platformsafhængig, men kun kræver en webbrowser. Effektivitet er et kriterie, der er blevet lagt vægt på, og er opfyldt ved anvendelse af elementer, såsom bulk-operationer samt en effektiv arbejdsgang i brugergrænsefladen, skræddersyet til Tonny Andersens arbejdesproces. Systemet er af høj kvalitet, da det opfylder de opstillede kriterier i høj grad, vurderet af projektgruppen, samt Tonny Andersen. Derudover benyttes der i systemet anderkendte mønstre for programmering. De generelle og specifikke kriterier er blevet opfyldt i henhold til de respektive prioritetsvurderinger. Der er ikke ændret i Magentoinstallationens filer, Price Optimizer er opbygget på én side og overskuelighed er tilpasset efter, at webapplikationen er et ekspertsystem. Derudover har brugbarhed været et meget vigtigt kriterie, og er opnået i høj grad i brugergrænsefladen. Det er overskueligt i brug, og varetager i stor grad funktionaliteten der behøves. Endeligt kan det konkluderes på, om der er udviklet et system som besvarer problemformuleringen. Problemformuleringen er opfyldt på en yderst tilfredsstillende måde ifølge Tonny Andersens endelige vurdering af den sidste iteration: Price Optimizer er meget brugbart og er på mange punkter meget bedre og mere effektiv end de to muligheder vi har haft for at ændre priser tidligere[...] Price Optimizer er derfor et mere effektivt værktøj end Tonny Andersens nuværende værktøjer til at ændre priser i Sinfuls webshop, og har således indfriet sit formål. 149

158 15.3 Perspektivering I dette afsnit vil der perspektiveres ud fra systemet Price Optimizer. Formålet er at gennemgå og vurdere eventuelle fremtidige udvidelser og implementeringer af systemet. Dette projekt strakte sig over en tidsbestemt periode, hvorfor der var begrænsninger på hvor stort et system der kunne udvikles. Der var flere funktioner, som var nævnt af klienten undervejs, der ikke blev implementeret. Nogle af funktionerne kan med fordel implementeres på et senere tidspunkt. En ønsket funktion der blev fravalgt i projektet, var webcrawler-funktionen til at finde konkurrenternes priser på prisfølsomme produkter. Webcrawleren var en funktionalitet, der blev foreslået til Tonny Andersen, som han fremstod positiv overfor. Ved et videre samarbejde med klienten, vil det være en oplagt mulighed at implementere en webcrawler. Dette vil kunne forstærke Sinfuls konkurrencedygtighed, da der under prisoptimeringen ville kunne refereres til konkurrenternes priser som retningslinjer. Til yderligere at hjælpe brugeren med prisoptimering, vil der med fordel kunne vises information om antal solgte varer og antal klik på et specifikt produkt. Til dette skal den hentede data fra Google Analytics behandles og vises til brugeren. Google Analytics-implementeringen var specifikt efterspurgt af Tonny Andersen, og kan give vigtig information om brugeradfærd på en produktside. Denne data kunne med fordel vises ved hjælp af grafer i fold-ud-rækkerne. Et andet element, som Tonny Andersen nævnte, var at have indstillingsprofiler for hvilke kolonner der bliver vist i tabellen. Dette vil give brugeren mulighed for selv at indstille hvilke kolonner brugeren har brug for at se og gemme denne visning til senere brug. At kunne gemme visningen vil optimere arbejdstiden ved efterfølgende prisoptimeringer. Lige nu understøtter systemet kun én version af Magento. I en eventuel videreudvikling kunne der med fordel implementeres et abstraktionslag der vil gøre det muligt at understøtte flere forskellige Magento-versioner samt andre webshop-løsninger. 150

159 Del VII Appendiks 151

160 Litteratur [1] Lars Mathiassen, Andreas Munk-Madsen, Peter Axel Nielsen, and Jan. Stage. Objektorienteret Analyse & Design. Forlaget Marko ApS, 3. edition, ISBN: [2] Henrik Theil. Internetbrug. [Online]. Available from: internetforbrug-17-kr-bruges-paa-nettet-hver-gang-vi-forbruger-100-kr/. [Accessed ]. [3] Google.com. Google analytics. [Online]. Available from : analytics/. [Accessed ]. [4] Ian Daniel. E-commerce Get It Right!: Essential Step-by-Step Guide for Selling and Marketing Products Online. Insider Secrets, Key Strategies and Practical Tips - Simplified for Start-Ups and Small Businesses. NeuroDigital, ISBN: [5] Adam McCombs and Robert Banh. The Definitive Guide to Magento. Apress, ISBN: [6] e conomic.dk. Dækningsbidrag - hvad er et dækningsbidrag? [Online]. Available from : [Accessed ]. [7] David Benyon. Designing Interactive Systems. Pearson Education Limited; 3rd Revised edition edition (September 13, 2013), 3. edition, ISBN: [8] John Vlissides Richard Helm Erich Gamma, Ralph Johnson. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, first edition edition, ISBN: [9] Steve Burbeck. Applications programming in smalltalk-80(tm): How to use modelview-controller (mvc). Avaiable from : smarch/st-docs/mvc.html. [Accessed ]. [10] Jeremy Miller. Patterns in practice: Convention over configuration. Avaiable from : [Accessed ]. [11] Henrik Bærbak Christensen. Klient-server og tre-lags-arkitekturen version 1.1. Avaiable from : pdf. [Accessed ]. 152

161 [12] Adam McCombs and Robert Banh. Graphic Design for Electronic Documents and User Interfaces. Apress, ISBN: [13] W3C. The localstorage attribute. [Online]. Available from : TR/webstorage/#the-localstorage-attribute. [Accessed ]. [14] W3C. Html. [Online]. Available from : [Accessed ]. [15] W3C. Html & css. [Online]. Available from : webdesign/htmlcss. [Accessed ]. [16] W3C. Javascript web apis. [Online]. Available from : standards/webdesign/script. [Accessed ]. [17] jquery.com. jquery. [Online]. Available from : [Accessed ]. [18] w3techs. Usage of javascript libraries for websites. [Online] Available from : http: //w3techs.com/technologies/overview/javascript_library/all. [Accessed ]. [19] jquery.com. jquery.ajax(). [Online] Available from : jquery.ajax/. [Accessed ]. [20] JSON. Introducing json. [Online]. Available from : [Accessed ]. [21] Microsoft. Asp.net overview. [Online]. Available from : com/en-us/library/dd381412(v=vs.108).aspx. [Accessed ]. [22] Datatables. Datatables table plug-in for jquery. Avaiable from : net/. [Accessed ]. [23] ASP.NET. Asp.net web api. [Online]. Available from : com/en-us/library/hh833994%28v=vs.108%29.aspx. [Accessed ]. [24] Edgar F. Codd. A relational model of data for large shared data banks. Avaiable from : [Accessed ]. [25] Pranab Kumar Das Gupta. Database Management System Oracle Sql And Pl/Sql. PHI Learning Pvt. Ltd., ISBN: [26] MongoDB Inc. Mongodb. Avaiable from : [Accessed ]. [27] MongoDB Inc. Objectid - mongodb manual. Avaiable from : org/manual/reference/object-id/. [Accessed ]. [28] Magento. System requirements for magento enterprise edition and community edition Avaiable from : system-requirements. [Accessed ]. 153

162 [29] Unoeuro. Unoeuro webhotel. Avaiable from : products-webhotel.php. [Accessed ]. [30] Manny Vergel. The free currency converter api. Avaiable from : freecurrencyconverterapi.com/. [Accessed ]. [31] Microsoft. Dividebyzeroexception class. Avaiable from : com/en-us/library/system.dividebyzeroexception(v=vs.110).aspx. [Accessed ]. [32] W3C. Web storage - world wide web consortium. Avaiable from : org/tr/webstorage/#dom-localstorage. [Accessed ]. [33] Videntilhandling.dk. Seks af de mest anvendte dataindsamlingsmetoder. Avaiable from : Dataindsamlingsmetoder_SR_01.pdf. [Accessed ]. [34] Denstoredanske.dk. Interview. Avaiable from : Samfund,_jura_og_politik/Massemedier/Journalistiske_genrer_og_stofomr% C3%A5der/interview. [Accessed ]. [35] Mogens Meilby. Journalistikkens grundtrin : fra ide til artikel. Avaiable from : [Accessed ]. [36] R. Mitchell. Instant Web Scraping with Java. Packt Publishing, ISBN: [37] Jared Spool Jeffrey Rubin, Dana Chisnell. Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests. Wiley, 2 edition edition, ISBN: [38] Jakob Nielsen & Rolf Molich. Heuristic evaluation of user interfaces. ACM, ISBN: [39] MongoDB. db.collection.initializeunorderedbulkop(). Avaiable from : initializeunorderedbulkop/#db.collection.initializeunorderedbulkop. [Accessed ]. [40] Mikael B. Skov Jesper Kjeldskov and Jan Stage. Instant data analysis: Conducting usability evaluations in a day. [Online]. Available from : 1/New%20folder/InstantDataAnalysis.pdf. [Accessed ]. [41] Laurie Williams. Testing overview and black-box testing techniques. Avaiable from : [Accessed ]. [42] LLC Balsamiq Studios. Balsamiq. Avaiable from : [Accessed ]. [43] Google Accounts Authentication and Authorization. Oauth2. Avaiable from : [Accessed ]. 154

163 [44] Igor Minar. Mvc vs mvvm vs mvp. what a controversial topic that many developers can spend.... Avaiable from : aznvhj355g2. [Accessed ]. Figurer 2.1 Adminpanelet i Magento Adminpanelet i Magento Sider i Excel-arket Indkøbsstyring -siden i Excel-arket. Billedet er drejet Kalender over tid benyttet til hver iteration Iterativ udviklingsmodel Klassediagram i problemområdet Tilstandsdiagram over klassen Webshop Tilstandsdiagram over klassen Produkt Tilstandsdiagram over klassen Pris Det generelle procedure- og materialemønster [1, p. 129] Tilstandsdiagram for Registrer administratorbruger Tilstandsdiagram for Ændre pris Tilstandsdiagram for Synkroniser med Magento Tilstandsdiagram for Gem til Magento Diagram over initiativ samt effekt på en aflæsningsfunktion Diagram over initiativ samt effekt på en signaleringsfunktion Diagram over initiativ samt effekt på en opdateringsfunktion Diagram over initiativ samt effekt på en beregningsfunktion Det lagdelte arkitekturmønster. Eksempel (a) med en lukket-streng arkitektur. Eksempel (b) med en åben-løs arkitektur Observatør-mønstret [1, p. 272] Passiv Model-View-Controller-mønstret Klient-server-arkitekturmønstret Klassediagram af komponentarkitekturen Opbygningen af brugergrænsefladen til Price Optimizers login-side Opbygningen af brugergrænsefladen til Price Optimizers forside. Venstremenuen bliver vist og man kan se der er blevet ændret i fire rækker. Se stort billede i bilag D

164 8.3 Tabellen fylder hele skærmbilledet da venstre-menuen er skjult. De tre knapper Show changes, Undo changes og Save to Magento er deaktiveret da der ikke er foretaget nogen ændringer. Se stort billede i bilag D Efter tryk på knappen Show changes viser tabellen udelukkende de produkter der er blevet ændret. Se stort billede i bilag D Ved tryk på knappen Undo changes popper et advarselsvindue op som sikrer at brugeren ønsker at fjerne alle ændringer i tabellen Ved tryk på knappen Save to Magento kommer ovenstående overlay frem. Det er en animeret loadingbar der angiver at systemet ikke er frosset og der beskrives med tekst på hvilket stadie i processen systemet er Når brugeren trykker på Help-knappen bliver der lagt et overlay over Price Optimizer og der kommer infobokse frem der beskriver de forskellige interaktive funktioner der er til rådighed. Se stort billede i bilag D Ved tryk på plusknappen på et produkt i tabellen foldes rækken ud. Her kan brugeren tilgå mere information om det specifikke produkt samt foretage forskellige udregninger ved hjælp af valutaomregneren. Se stort billede i bilag D Farveskema over vestlige farvekonventioner. Billedet er taget fra DIS [7, p. 277] Flowchart af komponenter der kommunikerer Anvendte teknologier Introduktion til Datatables - modiciferet. Originalen findes her [22] Digram over Magentos database. Se stort billed i bilag D Flowchart over synkroniseringsprocessen Sync from Magento Gem-til-Magento-processen Brainstorm baseret på det indledende interview med klienten Brugergrænseflade med gittervisning Brugergrænseflade med listevisning Slideview brugergrænseflade Slideview brugergrænseflade med udvidet information i bunden Slideview brugergrænseflade med udvidet information i siden Statistik omkring et enkelt produkt Mulighed for at sammenligne produkter Den valgte prototype med listevisning skitse af systemet Klassediagram i 2. iteration Systemet efter 2. iteration Til venstre ses venstre-menuen i 3. iteration og til højre ses venstre-menuen fra 2. iteration Klassediagram i 3. iteration Usability-laboratoriets testrum hvor testpersonen samt testlederen opholdte sig under udførelsen af testen

165 13.4 Kontrolrummet hvor observatørerne kunne observere testen uden at forstyrre testpersonen Skærmbillede af prototype 3 delt ind i fire sektioner C.1 Gridview C.2 Slideview C.3 Udvidet slideview C.4 Udvidet slideview med ekstra indstillinger C.5 Sammenligning af produkter C.6 Udvidet information omkring et produkt D.1 Systemet efter 2. iteration D.2 Opbygningen af brugergrænsefladen til PriceOptimizers index side. Kollapse menuen bliver vist og man kan se der er blevet ændret i fire rækker D.3 Når brugeren trykker på Help knappen bliver der lagt et overlay over PriceOptimizer og der komme infobokse frem der beskriver de forskellige interaktive funktioner der er tilrådighed D.4 Opbygningen af brugergrænsefladen til PriceOptimizers index side. Tabellen fylder hele skærmbilledet da kollapse menuen er skjult. De tre knapper Show changes, Undo changes og Save to Magento er deaktiveret da der ikke er foretaget nogen ændringer D.5 Ved tryk på plusknappen på et produkt i tabellen foldes ovenstående række ud. Her kan brugeren tilgå mere information om det specifikke produkt samt fortage forskellige udregninger ved hjælp af valutaomregneren D.6 Opbygningen af brugergrænsefladen til PriceOptimizers index side. Efter tryk på knappen Show changes viser tabellen udelukkende de produkter der er blevet ændret D.7 Digram over Magentos database D.8 Billede af brugergrænsefladen ved 2. iteration E.1 Klassediagram over modellaget Tabeller 4.1 Tabel over formål, resultat samt indragelse af testperson(er) for hver iteration Hændelsestabel over problemområdet Aktørtabel for systemet Generelle kriterier Specifikke kriterier

166 9.1 Tabel med produkter Tabel med produktdata Tabel med lande Anvendte tabeller fra Magentos database og hvilke data de indeholder Opgaver til assessment-test De fundne problemer fra assessment-testen med en vurdering af hvilken karakter problemet er af Tider målt i forbindelse med optimering af synkroniseringsprocessen Information om testpersonerne til usability-testen af prototype Tabellen angiver hvor lang tid hver testperson var om at udføre de enkelte opgaver. Derudover kan der ses et gennemsnit af tiden der blev brugt til hver opgave Antal fejl fundet i forbindelse med IDA-testen inddelt i de tre typer kritisk, seriøs eller kosmetisk Grænseværdier til funktionel test af prisændringer Udsnit af testscenarierne til funktionel test af prisændringer B.1 Funktionel test af kriteriet sikkert B.2 Funktionel test af kriterierne pålideligt & korrekt. Del 1/ B.3 Funktionel test af kriterierne pålideligt & korrekt. Del 2/ Kodeeksempler 9.1 Eksempel på C# kode i.cshtml-fil Eksempel på et dokument i MongoDB ICrud-interfacet IMongoObject-interfacet MongoObject-implementationen Crud-implementationen Dal-klassen Oprettelse af produkter med data fra Magentodatabasen Sammenfletning af produkter og produktdata Produkter og produktdata knyttes til webshoppen Udregning af dækningsbidraget Datavisualisering ved hjælp af DataTables Udsnit af SaveToMagento()-metoden MagentoReindexer-klassen

167 Interviews A I dette bilag findes transkriberinger af følgende interviews: A.1 Skype-interview med Tonny Andersen, Sinful. A.2 Interview spørgsmål til Tonny Andersen d A.3 Interview med Tonny Andersen, Sinful - d A.4 Afsluttende vurdering 159

168 A.1 Skype-interview med Tonny Andersen, Sinful - Referat Flere informanter. Excel-ark styrer både priser og indkøb for Tonny. Styrer det i Excel. Skal kunne hente alt data manuelt ned til Excel. Kunne analysere data mere end den gør nu. Excel vil gøre Tonny mere flexibel, kan bruge en Excel formel til at beregne forskellige tal. Excel: Det er for abstrakt, dataen skal gøres mere tilgængelig. Excel: Det vigtigste er at få nøgletallene og ændre prisen for de forskellige produkter i de forskellige lande. Det tager langtid at styre priserne på de enkelte produkter. Skal kunne styre de forskellige lande og få opdateret dem så de er nogenlunde ens. Vil gerne nemt selv kunne manipulere tallene. Styrer priser i fire forskellige lande manuelt -> optimeres To typer produkter: 1) Varer der stort set aldrig ændrer sig prismæssigt. 2) Varer hvor man skal se på priserne i forhold til de enkelte lande (Norge er et rigt land) Gå ind på konkurrenternes hjemmeside og få prisen på et specifikt produkt -> optimerer prisen i forhold til konkurrenterne. Se om der er et produkt der er udviklet til Magento. RJMetrics forskellige produkter. 160

169 A.2 Interviewspørgsmål til Tonny Andersen d Interview med Tonny Tiger tirsdag d. 16. september A.2.1 Rammerne Bjarke interviewer. De andre tager noter og skriver eventuelle spørgsmål ned som de kan stille efter interviewet. Tonny skal bruge scenarier og historier til at fortælle om hans arbejdsrutine med de nuværende systemer. En typisk dag i hans liv. Efter at Tonny har fortalt kan han i fællesskab med os diskutere et scenarie hvor man dykker ned i detaljerne og diskutere hvilke funktioner der skal med i forhold til f.eks MoSCoW Den der interviewer skal til sidst give et resume af interviewet for at få klarlagt eventuelle misforståelser. Morten tager Zoom3 med og Bjarke tager bluetooth-højtalere med for at optage interviewet. GoPro til evt. optagning af visning af nuværende system. A.2.2 Generelle spørgsmål Navn, alder og baggrund? Hvorfor valgte du at starte en webshop i stedet for en almindelig butik? Fortæl om en typisk arbejdsdag. A.2.3 Spørgsmål til systemet Hvordan benytter du dit nuværende system? Tonny demonstrerer systemet for os Har du en google analytics for alle landene eller blot en samlet? Hvor arbejder du med det her. Altid på kontoret eller også hjemme? Fortæl mig tre gode og tre dårlige ting om dit nuværende system. Hvis du havde tre ønsker til forbedringer hvad vil det være? Ekstra ting du ville ønske, at du kunne gøre i dit nuværnde system? Hvad skal der tages hensyn til landende imellem? Hvad skal der laves statistikker over? 161

170 A.2.4 Spørgsmål til forbedringer Vil det være en fordel at kunne sammenligne forskellige produkter? Hvis ja: Hvilke parameter? Pris, antal solgte, antal på lager. Vil det være en fordel at kunne filtrere produkter? Evt. hvilke filtre (Minimum pris, maksimum pris, hvad er der blevet solgt mest af) er interessante? Hvem vil være brugerne af systemet? Vil der i fremtiden kunne komme nye brugere? Vil det være en fordel at kunne sortere produkter? og hvilken sortering (Minimum pris, maksimum pris, hvad er der blevet solgt mest af) er interessante? Se en sammehæng mellem Youtube-hits og solgte produkter? Ændrer du nogle gange blot enkelte ting? Fx priser på enkelte produkter? Hvis nej, ville du gøre det hvis systemet var hurtigt og simpelt at tilgå? Vil det være en fordel hvis du kunne tilgå de produkter du opdaterer tit ved et enkelt tryk i systemet? Oplever I at I har en for stor lagerbeholdning af enkelte produkter? Er det interessant at se på et produkts popularitet fordelt på områder? (verdenskort visualisering af data) Ønsker du at kunne opdatere priser igennem vores program? Betyder responstid noget for dig? I forhold til at en webapplikation og at hente data ned. Hvor mange gange om måneden/ugen/dagen vil du benytte det færdige system? A.2.5 Spørgsmål til vores skitser Kan du se nogle problemer i en WebApplikation? Sikkerhed? Skal applikationen kunne ændre prisen på webshoppen? Vi skal have adgang til alt data ellers kan vi ikke lave applikationen. Er det et problem? Hvilken form for sikkerhed er der på webshoppen nu? NDA? 162

171 A.3 Interview med Tonny Andersen, Sinful - d [03:52] Er det ok at vi filmer når der bliver vist skitser og elementer på storskærm? (Tonny) "Øhhh hvis det kun er jer der har adgang til det og lærere, ja" [04:32] Hvis vi starter med det generelle. Navn, alder og hvad din baggrund er. (Tonny) "Jeg hedder Tonny Andersen. Jeg er 31 år og jeg har en baggrund efter gymnasiet hvor jeg har været elev hos Dansk Supermarked. Og så blev jeg leder derude lige efter jeg var elev og så har jeg siddet og købt ind fra Kina for et firma hvor jeg sad og købte ind til Jysk sengetøjslager. Så i 2008 gik jeg selvstændig, sagde mit job op og så lavede jeg nogle pakkeprojekter hvor jeg styrede at der skulle pakkes for eksempel 1000 kæmpe displays til Jysk sengetøjslager hvor jeg styrede en masse unge mennesker med det. Og så fik jeg den dumme ide til Sinful i sommeren 2008 og så er det egentlig bare kørt på siden der. Og vi fattede jo minus i starten, jeg tror vi havde en ordre den første måned. Men så bare ved at arbejde hårdt med det er det blevet til hvad det er i dag hvor vi er 20 forskellige folk herude og vi er i 4 lande. Og det kan da være at vi går til flere markeder på sigt også." [05:51] Hvorfor valgte du en webshop i stedet for en almindelig butik? (Tonny) "Fordi allerede der i 2008 kunne man se at tendensen, at det var online at folk begyndte at handle. Det interesserer mig også mere, altså med alt det data der driver. Du kan se data når du driver en webshop og du er ikke så afhængig. Hvis du har en fysisk butik skal du være der hele tiden men da vi startede webshoppen kunne vi bare have telefonen med alle steder og styre det. Nu kan man også se at online generisk vækst er 14 % om året og den almindelige detailhandel ligger og bakker i 2 % så det er meget fornuftigt" [06:38] Hvad med en typisk arbejdsdag hvordan ser den ud? (Tonny) "Jeg starter kl. 07 om morgenen med at svare de mail der ligger. Det er meget forskelligt hvad jeg sidder med. Det er sådan meget hvis vi skal have et eller andet sparket igang. Og det store for os nu er at få varer hjem fra Kina hvor vi får vores egne varer. Jeg har lige været i Kina for 14 dage siden. Dvs. jeg sidder og besvarer mails fra kinesere om morgenen. Og så kommer der mails fra de ansatte i løbet af dagen hvor jeg har noget sparring med dem. Og så et projekt som dette her bruger jeg tid på, og hvad der nu ellers er og finde nye medarbejdere. Det vil sige det er meget blandet. Jeg er sådan lidt inde i det hele. Jeg har det overordnet ansvar for at vi når budgetter og strategien det er egentlig min vigtigste opgave at vi følger vores koncept" [07:57] Lad os gå over til en gennemgang af systemet (Tonny) "Ja sådan overordnet der vil jeg sige at det vi skal munde ud med at systemet det kan løse, den vigtigste opgave for os, er at den kan styre priser intelligent. At systemet kan gør prisstyring let og gøre det intelligent. Der tror jeg det kunne være fedt at lave en analyse af for eksempel Zalando, hvordan er deres prisstyring. For eksempel i Tyskland 163

172 kører de alt i Euro men de er 5-10 % billigere i Tyskland end i Finland selv om de også kører Euro. Og så Danmark, Sverige Norge kører sådan meget efter noget valutakurs, men det runder altid op til en eller anden fast parametre. Vi har jo den problemstilling nu, at vi har fire lande vi skal styre priser i og har 2500 produkter. Og tidligere hvis vi skulle ændre en pris skulle vi ind i en administrator. Vi kører på Magento. Der styrer vi det hele fra administratoren og vi har så 2500 produkter i fire lande, og hvis man skal sidde og holde styr på det kan man bruge fra morgen til aften. Eirik har så udviklet et Excel-ark hvor du kan ligge id på produktet ind og så kan du skrive den pris den skal have og så laver den et SQL-input som man så kan ligge ind, som den skriver direkte til serveren. Men stadigvæk vil jeg sige at hvis man kan lave et system der kan trække det data ud det har brug for, og man kan lave ændringer, det vil være ti gange lettere. Jeg kan måske godt finde ud af at bruge Excel delen og uploade selvom det tager lidt langtid for mig men jeg får en indkøbsassistent der skal sidde og styre priserne. Der er det ikke sikkert at personen skal sidde og skrive direkte til databasen." [18:20] trækker du data fra Google Analytics og Magento manuelt ud til excel arket? (Tonny) "Magento overall data og så trækker jeg for hvert eneste land. Trækker de landespecifikke ting ud og så fra Google Analytics. Hvor mange der er solgt den måned, hvad gennemsnitsalgsprisen har været. Det trækker jeg ud fra alle fire land og putter det ind i kolonner." [19:10] (Tonny) "Hver måned så går jeg ind og kigger DB og så sorterer jeg med den største først. Så kan jeg se om der er en eller anden fejl. Hvis vi nu har et DB på 50 på en vare så har vi fået lagt en vare ind med forkert indkøbspris. Indkøbsprisen trækker jeg jo fra Magento." [19:31] Hvad står DB for? (Tonny) "Det er dækningsbidrag dvs vi tager den pris varen er solgt med og dividerer med indkøbsprisen og så kan jeg se en eller anden faktor. Og hvis den er alt for høj så er det nok fordi når de har godkendt en indkøbsordre, at de skrevet en forkert pris. Hvis den er alt for lav kan det også være at de har lavet en fejl da de godkendte ordren. Det kan også være leverandøren har øget prisen eller at vi er kommet til at sætte den til en forkert pris. Og især i de andre land hvor vi sad og manuelt ændre priser når vi oprettet et produkt fandt jeg nogen grimme ting hvor vi tabte penge når vi solgte det. Der er jeg begyndt at bruge det her med DB. Så det giver mig et billede af hvor meget vi tjener på de forskellige varer." [21:22] (Tonny) "Hvordan øhh, hvad konverteringsfrekvensen er på den vare når folk er inde på den. Det vil sige den der vare har jeg solgt en af og der har været 51 visninger, så har jeg en konverteringsfrekvens på 1,54%. Dvs det er en faktor der viser at hver gang der kommer 51 mennesker ind så bliver der købt en gang af det pågældende produkt. Og det giver mig et billede, når jeg sortere det, om der er nogle vare der får alt for meget fokus 164

173 og som vi ikke sælger. Så der er DB, der er vigtigt når man sidder og styrer priserne og sikre at der ikke er et eller andet galt der og så er der ligesom den her faktor med konverteringsfrekvensen af den enkelte vare. Det er de to vigtigste parametre jeg bruger." [23:30] Prisstyring nævnte du rimelig mange gange da vi snakkede på Skype så vi tænkte meget på hvordan vi kunne få en vinkel på det så vi får noget akademisk indover. Vi lever i et kapitalistisk samfund så der er selvfølgelig en masse forskning i det så vi skal nok kunne finde noget sjovt ved det (Tonny) "Og det fede ved det er at det er noget vi faktisk ved særlig meget om. Så hvis i har nogle ting i lære i process vil det være fedt at få nogle input til det for det er ikke noget vi har arbejdet med. Før sad jeg bare med en følelse ud fra da jeg var i Dansk Supermarked og det teori jeg havde lavet, den der skal koste det der, men hvis man begynder at bygge noget data ind i det så bliver det lige pludselig meget sjovere og det er et sted vi kan hente rigtig meget." [24:18] Det er det der med at vi vil være innovative fordi det skal ikke være teknisk trivielt (Eirik) "Hvis jeg kan komme med et bud der så er scraping af konkurrentens priser et vældig interessant tema som vi ikke har kigget så meget på. For det giver os en mere retningslinje på indtjening. Så få bedre styr på det." [25:02] (Tonny) "Nemlig! For den måde vores prisstruktur fungere på det er at vi har nogle vare hvor folk de aldrig vurdere en pris på det. For eksempel en glidecreme, de ved ikke hvad den skal koste og de går ikke ind på konkurrentens hjemmeside på ser på hvad koster glidecreamen. Så den sidder vi og styr ud fra hvad ser pænt ud, den her kan man tage 89,00 kr. for og det ser fint ud. Og alle vores egen Sinful varer er heller ikke så prisfølsomme da vi er de eneste vi har dem. Men vi har netop de der produkter som Eirik siger hvor det måske er produkter hvor folk simpelthen sidder og sammenligner på Pricerunner og på andre steder. Så hvis man kan lave i systemet at vi har vores standard vare som ikke er prisfølsomme. Det gør vi ud fra de her parameter. Men så har vi måske 20 varer hvor den kan scrape konkurrenter hvad er der pris eller tage de 4 vigtigste konkurrenter i hvert land og hvad er deres pris og så kan man styre dem individuelt. Det vil være super awesome for vi kan se så snart at vi er en af dem med de laveste priser så sælger vi 2-3 gange mere af de varer. Så det er egentlige sådan vores prisstruktur fungere. Vi prøver at holde en god margen på det som folk ikke søger og så der hvor folk de sidder og sammenligner der..." [29:13] (Eirik i forhold til scraper) "Et problem dog med at tage det på navn er faktisk lidt vanskeligere end i det fleste andre brancher fordi folk er ikke så konsekvente med brug af produktnavnene som de er på en computer for eksempel." [30:48] (Tonny) "Det der bare er vigtigt for os er især at når i laver opbygningen er at man kan ændre en del priser for eksempel i et land overview så man ikke skal ind på hver eneste i det. Før hen hvis vi skulle ændre antal i shoppen på varer så skulle vi ind på hver eneste varer men så i det her modul vi har fået bygget på kan vi gå ind og klikke af, dvs jeg kan søge på alle de her varer som jeg vil, navn, varernummer. Og så kan jeg klikke af hvad for nogen jeg vil ændre antal på og så skriver den til alle produkterne. Så hvis 165

174 man på en eller anden måde, det smarteste nok hvis man har et dashboard som det her og så har man priserne i det enkelte land og så kan man klikke af hvad for nogen man skal ændre." [33:46] (Tonny) "En parameter der også er i det er at i shoppen der har vi nogle forskellige tilbuds kategorier hvor man når man smider noget på tilbud så før der skulle vi ligge det manuelt i den kategori men der har Eirik så gjort sådan den skriver til shoppen at det skal ligges i den når det ryger på tilbud. Så der er et eller andet os som skal kodes så det automatisk ryger i den kategori så man ikke skal ind og tilføje produktet. Fordi vi har en tilbudskategori under kvinder, mænd, par, fetish og en general tilbuskatogori hvor alle tilbud skal være." [35:20] I Google Analytics har du en samlet konto eller har du ligesom en konto for hvert land? (Tonny) "Begge dele. Jeg har ID til hvert land så der sidder tracking kode forskellige til hvert land. Men man kan samle i rapporter derinde. Jeg har en masteracount så jeg kan samle datarapporter for alle lande. Men jeg ved ikke hvordan det fungere når det er noget med priser og valutakurser så umiddelbart tror jeg det skal køre op mod hvert enkelt land så der ikke er et eller andet men det er noget vi kan teste. Fordi man kan lave rapporter hvor den trækker data for alle lande men jeg tror så snart det er noget med salgs priser i hvert enkelt land så ved jeg ikke om man kan lave det i rapporter." [36:11] Arbejder du med systemet der hjemme eller er det kun på kontoret? (Tonny) "Det er egentlig fortrinsvis her men det er fedt hvis det kan fungere alle steder fra for jeg sidder også nogen gange i Kina" [36:37] Også hurtigt tre gode og tre dårlige ting ved det nuværende system (Tonny) "Det er ligesom en jobsamtale. De gode ting hvis vi tager udgangspunkt i en kombination af mit og Ereiks system er at 1) Vi er begyndt at arbejde med priser og bruger noget data til det. Det er en god ting det har vi ikke gjort før så vi kan se hvad der sælger og se hvad er DB et på tingene. Det gør simpelthen at vi tjerner flere pengene på de vare vi sælger nu. 2) Det gode ved at det er i excel er at jeg kan lave om på det selv. Får jeg en eller anden ide og vil trække noget nyt data ind så kan jeg gøre det fra analytics. Det er det gode ved det at det er i excel. 3) Det at Ereik har lavet den hvor vi kan skrive til databasen gør at det fjerne rigtig meget manuelt arbejde. Det dårlige er 1) at der er ved at være så meget data i mit excel ark at det kører rigtig langsomt. 2) Det er kun opdateret en gang i måneden fordi jeg skal sidde og trække dataen og det gør jeg hver gang vi er nået over den første. Dvs hvis der er nogen der har ændret priser i mellem tiden så kan jeg egentlig kommer til at overskrive dem fordi det er kun opdateret en gang i måneden. 3) Og så er det lidt bøvlet altså det tager squ langtid og jeg skal holde tungen lige i munden hvis jeg skal bruges Ereiks med det og for eksempel en indkøber vil jeg ikke lade side og skrive dirkete til databasen" [38:28] Er der nogen specielle hensyn der skal tages mellem landene? 166

175 (Tonny) "Det kunne være fedt at se på hvad gør dem der har succes i forskellige lande for eksempel Zalando. Og så analysere på hvordan er deres indbyrdes prisstruktur i de forskellige lande. [39:30] (Tonny) "I Danmark er det jo ikke lovligt at køre forskellige priser til forskellige folk men jeg ved at der nogle af mine venner der har test i Norge at vise forskellige priser til forskellige folk og der konverterede det bedre da det blev dyrere. Også i Danmark der køre vi meget.99 på priser og i Finland kører man for eksempel 39,9 fordi der er Euro." [42:06] Er der noget mere du vil tilføje i forhold til visualisering af statistik (Tonny) "Der er den simple med DB et som er vigtig. Så kunne det også være sjovt at trække statistik på DB på producent. Dvs. når jeg sidder og skal holde møde med eller anden leverandør, der kunne det være sjovt at se om vi tjener på Flesh light der tjener vi kun faktor 2, på det her tjener vi faktor 3 så ved vi hvilket brand vi skal fokusere på eller justere priserne på. Det vigtigste DB et på de enkelte vare og noget med hvor meget trafik er til den her vare og hvor meget sælger vi af den. 167

176 A.4 Afsluttende vurdering af Prototype 4 - Price Optimizer (Beta) Der blev efter den fjerde og sidste iteration sendt nedenstående mail til klienten Tonny Andersen med det formål at få en afsluttende vurdering på det udviklede system. Mailen og spørgsmålene deri indeholder svarene fra Tonny Andersen. Tonny Andersens svar er angivet i kursiv. A.4.1 Vurdering fra Tonny Andersen Hej Tonny. Vi vil gerne have dig til at vurdere systemet ud fra forskellige kriterier som vi skal bruge til dokumentation i vores rapport. Håber du er frisk på opgaven. Det vil være rigtig fint hvis du i din besvarelse både vil vurdere de forskellige spørgsmål på en skala fra 1-10 samt komme med en lille skriftlig begrundelse (Vi ved godt det er de værste spørgsmål at få :)). Hej drenge, jeg prøver at svare mit bedste og sig til hvis der er noget I skal have uddybet. Havde været fedt at vide denne opgave lidt før da vi ligger vandret herude. Vi kan evt gennemgå tingene mundtligt hvis der er noget som skal uddybes eller hvis der er nogle vurderinger I synes er mærkelige. Husk man skal passe på med det der IT ;) Det 1. kriterie systemet skal vurderes ud fra er hvor brugbart systemet er ud fra følgende parametre. Du må i din vurdering gerne sammenligne vores system i forhold til dit gamle Excel ark. 1) Hvor brugbart er systemet i forhold til din arbejdsmæssige situation? Her er nogle ideer du kan tænke over til din besvarelse. Du er skal være velkommen til at tilføje egne argumenter - Regulering af produktpriser. 9 - Optimering af produktpriser. 8 - Overvågning af produkter. 0 - Visualiserer data. 4 - Lette arbjdsbyrden. 9 Price Optimizer er meget brugbart og er på mange punkter meget bedre og mere effektiv end de to muligheder vi har haft for at ændre priser tidligere, som er; 1. via administationen i Magento. Denne vej er meget simpel, men man skal gemme hver gang man har ændret blot en pris, så bare der er 2-3 produkter der skal have ændret pris på alle 4 sprog bliver det tidskrævende. 2. via et Excel ark som er opbygget sådan at det laver kommandoer som man kan indæstte i Mysql. Denne løsning er fin ved mange pris ændringer, men det tager 168

177 en del tid at opdatere arket med de rette data hver gang man skal bruge det og chancen for fejl er meget stor. Fordelen ved løsningen i excel er at man selv kan ændre på tingene simpelt hvis man får en god idé til en faktor der skal med i vurderingen af priser. "Price optimizer"slår Excel arket på denne måde; - Regulering af priser er ikke noget man skal afsætte 2-3 timer til hver gang men nu en opgave man kan gøre løbende. Tidligere blev priser mest reguleret efter d. 1 da jeg skulle bruge noget data til excel arket, dette data henter PO "live- De indbyggede filtre gør det også meget let at finde de ting man vil optimere på. Fx kan det være et Brand man vil optimere sit DB på og så sørger man bare på dette. Denne funktion var også mulig i Excel arkert, men da der var rigtig meget data deri, kunne det tage lang tid om at loade når man aktiverede et filter. Vi kommer dermed til at optimere på vores priser oftere. Optimeringen bliver stadig meget ud fra nogle personlige købmandsmæssige vurderinger, hvor at det kunne give programmet endnu mere styrke hvis man i fremtiden kunne få det til; - Holde øje med konkurrenters priser - Vurderer om en varer sælger bedst til en given pris (fx 99 eller 119 kr) PO kommer klart til at lette vores arbejdsbyrde når det gælder priser. Og med produkter i 4 valutaer er dette noget som tager en del tid at holde styr på. 2) Hvor brugbart er systemet i forhold til dine organisatoriske omgivelser? - Her tænkes for eksempel i forhold til at du får en ny indkøber. 9 - Er der flere personer der skal tilgå systemet. 8 - Frigiver det ressourcer til andre opgaver i organisationen. 9 PO er meget simpelt opbygget så de fleste folk i organisationen ville kunne bruge det med en kort oplæring i det. Til en start vil det være vores indkøber og jeg der skal bruge det og for vores indkøber der ikke har avancerede IT kundskaber til at bruge Excel/MySql løsningen vil det være en stor fordel at vedkommende at ændre mange priser via dette program. PO er med til at prisoptimering bliver noget hurtigere, denne tid kunne bruges på andre opgaver eller at øge antallet af dage vi optimerer priser og dermed give os en konkurrencemæssig fordel. 3) Generelt opfylder systemet de behov som vi har talt om ved de forskellige interviews i løbet af efteråret? PO løser den vigtigste opgave som vi har snakket om, at vi lettere kan holde vores priser bedre opdateret i alle 4 lande. Og programmet fungerer rigtig fint til den funktion. Der er dog nogle enkelte ting som vi har snakket om som ikke er bygget i programmet endnu, fx konkurrent overvågning. Det 2. kriterie er hvor effektivt systemet er. Igen skal du være mere end velkommen til at sammenligne vores system med Excel arket Ideer til besvarelse: - Hastighed 8 (kun når den skal gemme eller cleare ting er den "sløv") - Arbejdstiden brugt på at udføre en 169

178 opgave 7 (noget med at man kan ændre flere priser med fx 10% eller 10 kr. kunne optimere hastigheden) og at man fx kan cleare alle filtre ville øge hastigheden. - Overskuelighed 9 3) Prøv at "smadre"systemet Jeg kan ikke smadre det :( Eneste ting er at det prøver at loade analytics data. 170

179 Test B I dette bilag dokumenter for test af prototyper. C.1 Test af Prototype 2 - Magentoforbindelse d C.2 Test af Prototype 3 - Price Optimizer (Alpha) d C.3 Funktionel test af Prototype 4 - Price Optimizer (Beta). 171

180 B.1 Test af Prototype 2 - Magentoforbindelse Test af Prototype 2 - Magentoforbindelse med Tonny Andersen tirsdag d. 14. oktober B.1.1 Introduktion Før testen skal jeg sige et par ting for at være sikker på, at jeg husker det hele, vil jeg læse det op. Det system, du skal hjælpe os med at teste, er en webapplikation til prisregulering af produkter på webshoppen Sinful. Det skal pointeres at applikationen er en prototype under udvikling og derfor ikke nødvendigvis afspejler det endelige produkt. Dette betyder også at der kun er 15 produkter tilgængelig i forbindelse med testen. Testen forløber på den måde, at du får stillet et antal opgaver, som du skal forsøge at løse ved hjælp af systemet. Opgaverne afspejler en webadministrators daglige brug af systemet. Du vil få udleveret opgaverne en efter en. Vi vil bede dig løse opgaverne på følgende måde. Først læser jeg hele teksten til opgaven højt. Derefter fortæller du mig, hvordan du forstår opgaven, og hvad du vil gøre for at løse den. Så går du i gang med selve løsningen. Mens du arbejder med opgaven vil vi gerne have, at du tænker højt. Det betyder, at du skal sige, hvad du har tænkt dig at gøre, hvad der overrasker dig og hvad du ellers tænker på under brugen. Jeg ved godt, at det ikke er naturligt at sidde og snakke højt, så hvis du glemmer det, vil jeg minde dig om det. Hvis du får problemer under løsningen af opgaven, kan du godt spørge mig. Men jeg vil nok ikke hjælpe dig direkte. Jeg vil i stedet forsøge at få dig til selv at komme videre. Når du mener, at du er færdig med at løse en opgave, vil jeg bede dig sige det, så vi ikke er i tvivl bagefter. B.1.2 Use cases Du er logget via log ind siden og er nu på forsiden af Sinful PriceOptimicer hvor du blandt andet kan se en tabel af produkter. Case 1: Del 1) Du vil gerne have sorteret produkterne i alfabetisk rækkefølge. Hvad gør du? Del 2) Du ser på tabellen igen og vil gerne have svensk og norsk pris fjernet fra tabellen, da du ikke skal benytte kolonnerne lige nu. Hvad gør du? Case 2: Del 1) Du har opdaget at Sinful Rabbit Vibrator original bliver solgt til 369 kr. hos en konkurrerende sexshop og du vil derfor ændre prisen på dette produkt til 359 kr. Hvad gør du? 172

181 Del 2) Du vil gerne gemme den nuværende ændring, og sende det til Magento. Hvad gør du? Del 3) Du synes at 10 produkter pr side er for få, og vil gerne ændre det til 50 produkter pr side i stedet for. Hvad gør du? Case 3: Del 1) Du ønsker kun at se det specifikke produkt Sinful Magic Wand Kraftig Vibrator i tabellen. Hvad gør du? Del 2) Du ønsker at kunne se informationen under Web crawler info og Statistics. Hvad gør du? B.1.3 Opfølgende spørgsmål Hvad er din umiddelbar reaktion på prototypen? Var der nogle funktioner du fandt unødige eller meget besværlig at benytte? Hvordan var din oplevelse af at navigere rundt i applikationen? I forhold til andre brugere af systemet, f.eks din nye indkøber, ser du der nogle udfordringer? Efter at have prøvet applikationen synes du der er funktionalitet der mangler? Har du nogle forslag til hvordan du gerne vil have tabellen organiseret? 173

182 B.2 Test af Prototype 3 - Price Optimizer (Alpha) Test af Prototype 3 - Price Optimizer (Alpha) ved hjælp af Instant Data Analysis-metoden tirsdag d. 14. oktober Testen blev udført på 6 testpersoner. B.2.1 Introduktion Testen kommer til at forløbe således. Først giver jeg dig en kort introduktion til testen. Herefter skal du udføre forskellige opgave. Når du er førdig med alle opgaverne eller tiden er gået går du ind i lokalet ved siden af hvor Thomas vi foretage et debrifing interview. Før testen skal jeg sige et par ting for at være sikker på, at jeg husker det hele, vil jeg læse det op. Det system, du skal hjælpe os med at teste, er en webapplikation til prisregulering af produkter på en erotik webshop. Det skal pointeres at applikationen er en prototype under udvikling og derfor ikke nødvendigvis afspejler det endelige produkt. Testen forløber på den måde, at du får stillet et antal opgaver, som du skal forsøge at løse ved hjælp af systemet. Opgaverne afspejler en webadministrators daglige brug af systemet. Du vil få udleveret opgaverne en efter en. Vi vil bede dig løse opgaverne på følgende måde. Først læser jeg teksten til opgaven højt. Derefter fortæller du mig, hvordan du forstår opgaven, og hvad du vil gøre for at løse den. Så går du i gang med selve løsningen. Mens du arbejder med opgaven vil vi gerne have, at du tænker højt. Det betyder, at du skal sige, hvad du har tænkt dig at gøre, hvad der overrasker dig og hvad du ellers tænker på under brugen. Hvis du får problemer under løsningen af opgaven, kan du godt spørge mig. Men jeg vil nok ikke hjælpe dig direkte. Jeg vil i stedet forsøge at få dig til selv at komme videre. Når du mener, at du er færdig med at løse en opgave, vil jeg bede dig sige det, så vi ikke er i tvivl bagefter. Til denne test benytter vi en Mac. Hvis du ikke er vant til at benytte en Mac hjælper jeg dig gerne med f.eks. at lave snabel a dat det ikke er operativ systemet vi test men vores applikation. Du er ankommet til dit kontor hos Erotik A/S der ejer nordens største erotiske webshop med salg af produkter i Danmark, Sverige, Norge og Finland. Dit arbejde hos Erotik A/S består i at skulle prissætte samt prisoptimere de over 2500 produkter der bliver solgt via Erotik A/S s Magento webshop i de fire land. Til at lette dette arbejde har du fået udviklet en webapplikation der skal gøre den information der er til rådighed overskuelig. Din computer er netop startet op og du er klar til at påbegynde dit arbejde. 174

183 Opgave 1: Del 1) Du er ankommet til Price Optimizer log in side hvor du gerne vil logge in. Hvad gør du? Del 2) Du er nu logget in på Price Optimizer og vil gerne forhøje Price Default med 10 kr. på de tre øverste produkter i tabellen. Hvad gør du? Del 3) Du fortryder de ændringer du har foretaget og vil gerne fjerne dem. Hvad gør du? Opgave 2: Del 1) Du ønsker at gøre tabellen mere overskuelig i forhold til hvad du skal arbejde med i dag. Du vil gerne fjerne SKU, Exclude og Cost Price under General Columns samt Special Price og Conversion Rate under Default Columns. Del 2) Du har nu fået et bedre overblik over tabellen men vil også gerne se prisen for produkterne i den svenske webshop. Hvad gør du? Del 3) Du har nu de kolonner du skal bruge og vil gerne have fjernet menuen i venstre side for at kunne benytte hele skærmen til at se tabellen. Hvad gør du? Opgave 3: Del 1) Du vil nu gerne sortere tabellen således at Contribution Margin er rangeret efter højeste værdi øverst. Del 2) Du vil gerne forhøje Default Price på de 3 øverste produkter med 20 kr. Hvad gør du? Del 3) Du kommer i tanke om at du også gerne vil kunne se den norske pris i tabellen. Hvad gør du? Del 4) Du ønsker nu kun at kunne se de produkter du har ændret i tabellen. Hvad gør du? Opgave 4: Del 1) Du ønsker nu at få vist mere information om det øverste produkt i tabellen. Hvad gør du? Del 2) Du kan nu se en graf over solgte produkter indenfor det sidste år samt en valutaomregner. Du overvejer at øge prisen på produktet med 15,- kr.. Du ønsker at se hvad denne nye pris svarer til i andre valutaer. Hvad gør du? 175

184 Del 3) Du kan nu bland andet se prisen i svenske kroner i valutaomregneren(obs! Sig ikke et pris der ikke findes i forvejen!). Du ønsker nu at ændre den oprindelige svenske pris til den nye omregnede svenske pris. Afrund til nærmeste heltal. Opgave 5: Del 1) Du er tilfreds med dine ændringer og ønsker at gemme dem til din Magento webshop. Hvad gør du? Del 2) Som den sidste ting vil du gerne logge ud af Price Optimizer. Hvad gør du? B.2.2 Opfølgende spørgsmål Hvad erfaring har du? It-systemer, webshops osv. It-bruger: Begynder, middel eller ekspert? Kendte du i forvejen til Magento? Hvad er din umiddelbare reaktion på prototypen? Var der nogle funktioner du fandt unødige eller meget besværlig at benytte? Hvordan var din oplevelse af at navigere rundt i applikationen? Efter at have prøvet applikationen synes du der er funktionalitet der mangler? Har du nogle forslag til hvordan du gerne vil have tabellen organiseret? 176

185 B.3 Funktionel test af Prototype 4 - Price Optimizer (Beta) 177

186 Test ID Beskrivelse Forventet resultat Faktiske resultat Tilgå følgende url: 1 uden at være logget Afvist Afvist ind Tilgå følgende url: 2 uden at være Afvist Afvist logget ind Tilgå følgende url: 3 uden at være Afvist Afvist logget ind Tilgå følgende API-endpoint: alexfrie.dk:8080/api/products/getall 4 uden Afvist Afvist at være logget ind Tilgå følgende API-endpoint: alexfrie.dk:8080/api/products/sync 5 uden at Afvist Afvist være logget ind Tilgå følgende API-endpoint: alexfrie.dk:8080/api/products/edit 6 uden at Afvist Fejlmeddelelse være logget ind Tilgå følgende API-endpoint: 7 Afvist Fejlmeddelelse uden at være logget ind Tilgå følgende API-endpoint: 8 Afvist Fejlmeddelelse uden at være logget ind Tilgå følgende API-endpoint: 9 Afvist Fejlmeddelelse uden at være logget ind Tilgå følgende API-endpoint:alexfrie.dk:8080/Api/Products/GetPriceHistory/id 10 Afvist Afvist uden at være logget ind Tilgå følgende API-endpoint: 11 Afvist Fejlmeddelelse uden at være logget ind 12 Logge ind uden at have udfyldt adresse. Fejlmeddelelse Fejlmeddelelse 13 Logge ind uden at have udfyldt password Fejlmeddelelse Fejlmeddelelse 14 Logge ind uden at have udfyldt og password Fejlmeddelelse Fejlmeddelelse 15 Logge ind med forkert eller password Fejlmeddelelse Fejlmeddelelse 16 Angive en eller. Fejlmeddelelse Fejlmeddelelse 17 Registrer en ny bruger med en der allerede er i systemet Fejlmeddelelse Fejlmeddelelse 18 Registrer en bruger med et password der er under 6 tegn langt Fejlmeddelelse Fejlmeddelelse 19 Registrer en ny bruger hvor passwordet indeholder special tegn Godkendt Godkendt 20 Angive en eller punktum Fejlmeddelelse Fejlmeddelelse Tabel B.1. Funktionel test af kriteriet sikkert 178

187 Test ID Beskrivelse Forudsætning: Brugeren er korrekt logget ind på systemet og der er hentet 2206 produkter ind i tablen. Ændre Defalut Price på produktet "Aneros HELIX Prostata Stimulator"til -100 Forudsætning: - - Ændre Danish Price på produktet "Aneros HELIX Prostata Stimulator"til -100 Forudsætning: - - Ændre Swedish Price på produktet "Aneros HELIX Prostata Stimulator"til -100 Forudsætning: - - Ændre Finnish Price på produktet "Aneros HELIX Prostata Stimulator"til -100 Forudsætning: - - Ændre Norwegian Price på produktet "Aneros HELIX Prostata Stimulator"til -100 Forudsætning: - - Ændre Defalut Price på produktet "Aneros HELIX Prostata Stimulator"til -1 Forudsætning: - - Ændre Danish Price på produktet "Aneros HELIX Prostata Stimulator"til -1 Forudsætning: - - Ændre Swedish Price på produktet "Aneros HELIX Prostata Stimulator"til -1 Forudsætning: - - Ændre Finnish Price på produktet "Aneros HELIX Prostata Stimulator"til -1 Forudsætning: - - Ændre Norwegian Price på produktet "Aneros HELIX Prostata Stimulator"til -1 Forudsætning: - - Ændre Defalut Price på produktet "Aneros HELIX Prostata Stimulator"til 0 Forudsætning: - - Ændre Danish Price på produktet "Aneros HELIX Prostata Stimulator"til 0 Forudsætning: - - Ændre Swedish Price på produktet "Aneros HELIX Prostata Stimulator"til 0 Forudsætning: - - Ændre Finnish Price på produktet "Aneros HELIX Prostata Stimulator"til 0 Forudsætning: - - Ændre Norwegian Price på produktet "Aneros HELIX Prostata Stimulator"til 0 re- Forventet sultat PriceOpti: -100 Mongo: Intet Magento: Intet PriceOpti: -100 Mongo: Intet Magento: Intet PriceOpti: -100 Mongo: Intet Magento: Intet PriceOpti: -100 Mongo: Intet Magento: Intet PriceOpti: -100 Mongo: Intet Magento: Intet PriceOpti: -1 Mongo: Intet Magento: Intet PriceOpti: -100 Mongo: Intet Magento: Intet PriceOpti: -1 Mongo: Intet Magento: Intet PriceOpti: -1 Mongo: Intet Magento: Intet PriceOpti: -1 Mongo: Intet Magento: Intet PriceOpti: 0 Mongo: 0 Magento: 0 PriceOpti: 0 Mongo: 0 Magento: 0 PriceOpti: 0 Mongo: 0 Magento: 0 PriceOpti: 0 Mongo: 0 Magento: 0 PriceOpti: 0 Mongo: 0 Magento: 0 Faktiske resultat Tabel B.2. Funktionel test af kriterierne pålideligt & korrekt. Del 1/2 179

188 Test ID Beskrivelse Forudsætning: Brugeren er korrekt logget ind på systemet og der er hentet 2206 produkter ind i tablen. Ændre Defalut Price på produktet "Aneros HELIX Prostata Stimulator"til 1 Forudsætning: - - Ændre Danish Price på produktet "Aneros HELIX Prostata Stimulator"til 1 Forudsætning: - - Ændre Swedish Price på produktet "Aneros HELIX Prostata Stimulator"til 1 Forudsætning: - - Ændre Finnish Price på produktet "Aneros HELIX Prostata Stimulator"til 1 Forudsætning: - - Ændre Norwegian Price på produktet "Aneros HELIX Prostata Stimulator"til 1 Forudsætning: - - Ændre Defalut Price på produktet "Aneros HELIX Prostata Stimulator"til Forudsætning: - - Ændre Danish Price på produktet "Aneros HELIX Prostata Stimulator"til Forudsætning: - - Ændre Swedish Price på produktet "Aneros HELIX Prostata Stimulator"til Forudsætning: - - Ændre Swedish Price på produktet "Aneros HELIX Prostata Stimulator"til Forudsætning: - - Ændre Swedish Price på produktet "Aneros HELIX Prostata Stimulator"til re- Forventet sultat PriceOpti: 1 Mongo: 1 Magento: 1 PriceOpti: 1 Mongo: 1 Magento: 1 PriceOpti: 1 Mongo: 1 Magento: 1 PriceOpti: 1 Mongo: 1 Magento: 1 PriceOpti: 1 Mongo: 1 Magento: 1 PriceOpti: Mongo: Magento: PriceOpti: Mongo: Magento: PriceOpti: Mongo: Magento: PriceOpti: Mongo: Magento: PriceOpti: Mongo: Magento: Faktiske resultat Tabel B.3. Funktionel test af kriterierne pålideligt & korrekt. Del 2/2 180

189 Skitser C Figur C.1. Gridview. 181

190 Figur C.2. Slideview. Figur C.3. Udvidet slideview. 182

191 Figur C.4. Udvidet slideview med ekstra indstillinger. Figur C.5. Sammenligning af produkter. 183

192 Figur C.6. Udvidet information omkring et produkt. 184

193 185 Figurer D

194 186 Figur D.1. Systemet efter 2. iteration

195 187 Figur D.2. Opbygningen af brugergrænsefladen til PriceOptimizers index side. Kollapse menuen bliver vist og man kan se der er blevet ændret i fire rækker

196 188 Figur D.3. Når brugeren trykker på Help knappen bliver der lagt et overlay over PriceOptimizer og der komme infobokse frem der beskriver de forskellige interaktive funktioner der

197 189 Figur D.4. Opbygningen af brugergrænsefladen til PriceOptimizers index side. Tabellen fylder hele skærmbilledet da kollapse menuen er skjult. De tre knapper Show changes, Undo

198 190 Figur D.5. Ved tryk på plusknappen på et produkt i tabellen foldes ovenstående række ud. Her kan brugeren tilgå mere information om det specifikke produkt samt fortage

199 191 Figur D.6. Opbygningen af brugergrænsefladen til PriceOptimizers index side. Efter tryk på knappen Show changes viser tabellen udelukkende de produkter der er blevet ændret

200 Figur D.7. Digram over Magentos database 192

201 193 Figur D.8. Billede af brugergrænsefladen ved 2. iteration

202 Klassediagram E E.1 Problemområdet Figur E.1. Klassediagram over modellaget 194