Rabattsystem TEXTILGALLERIAN RABATTSYSTEM

Transkript

1 Rabattsystem Kund : Linus Ivelid, Textilgallerian Projektgrupp : Jonas Holte, Jesper Håkansson, Rasmus Eneman, Henrik Gabrielsson, David Grenmyr och Erik Magnusson Handledare : Tobias Ohlsson Kurs : WEBBPROJEKT 1, 1DV411 9 Mar of 8

2 INTRODUKTION Sammanfattning Textilgallerian.se är en etablerad webbplats som säljer hemtextil genom sin e handelssbutik. Vi fick i uppgift av Linus Ivelid, chef på Textilgallerian, att skapa ett system för att hantera kuponger med rabattkoder som kunderna kan använda när de handlar i e butiken. I nuläget finns det ingen sådan funktionalitet på Textilgallerian.se. Dels skapade vi ett gränssnitt där Textilgallerians personal kan skapa, redigera och ta bort kuponger. Här kan man också hantera användare och deras roller. Vi skapade också ett API som kan användas i e butiken för att kontrollera om kupongen är giltig för kunden och produkterna i varukorgen. Här räknar vi också ut den totala rabattsumman för använd kupong. I denna rapport beskriver vi arbetsprocessen och vilka tekniker som använts. Vi beskriver också vilka mål vi hade och hur slutprodukten till sist blev. Bakgrund, Riktlinjer och Mål Linus driver hemsidan Textilgallerian, och har sedan några år tillbaka velat ha ett rabattsystem. I systemet vill han kunna skapa olika typer av rabatter för olika typer av ändamål. Systemet ska behandla användare, anställda på Textilgallerian, som i olika utsträckning ska kunna hantera rabatter, genom att användarna tilldelas en roll med olika rättigheter. Olika varianter av rabatter kan t.ex. vara procentuella, köp X Betala För Y, Köp X Få Y. Samtidigt ska olika rabatt kuponger kunna kombineras, automatiskt genereras och anpassas efter specifika märken, produkter, kategorier eller kunder. Detta ska kunna användas genom ett API, där Textilgallerian på egen hand får ta kontakt och tillgodose den information som behövs för att kontrollera om en rabatt gäller. Hur frågan till API:et ska utformas har vi fått fria händer att bestämma. Ytterligare en efterfrågan var att ha en sida med statistik i rabattsystemet, vad denna sida skulle täcka för olika aspekter är dock inget som vi har gått in på. Slutprodukten av vårt projekt är tänkt att se ut enligt modellen: 2 of 8

3 Projektbeskrivning Efter önskemål av kund ska följande tekniker användas: ASP.NET MVC med RavenDB( <V2.5 ) som databas. Projektet består av två olika delar. Ett API som kunden kan prata med, och ett systemet för att generera rabattkuponger som API:et kan prata med. Summerad funktionalitet: Rabattsystem: Skapa, redigera och ta bort rabatter, användare och roller Procentuell rabatt på totalsumma Procentuell rabatt på helt köp, vid köp av minst X Kr Specifik summa rabatt vid köp av minst X kr Köp specifikt antal produkter, betala för X antal produkter Köp specifik vara, få specifik vara på köpet Rabatt för återkommande kunder Olika typer av rättigheter för användare(t.ex. ska kunna skapa andra användare, ska ta bort rabatt eller ska endast kunna visa) Överblick för rabatter, användare och användarroller Inloggning för användare Olika rättigheter för olika användare API: Ta emot ett kundvagnsobjekt i form av JSON Returnera ett kundvagnsobjekt som genomgått rabatthantering Ta emot en köpt kundvagn för att uppdatera status på rabatter 3 of 8

4 INNEHÅLLSFÖRTECKNING 1. FÖRSÄTTSBLAD 2. INTRODUKTION 2.1 SAMMANFATTNING BAKGRUND,RIKTIGTLINJER OCH MÅL PROJEKTBESKRIVNING 3 3. INNEHÅLLSFÖRTECKNING 3.1 INNEHÅLLSFÖRTECKNING 4 4. GENOMFÖRANDE 4.1 METODIK OCH TEKNIK 4.2 RESULTAT 4.3 EXTRA FUNKTIONALITET 4.4 AVVIKELSER TESTNING SLUTSATS ÖVERLÄMNING OCH VIDAREUTVECKLING of 8

5 GENOMFÖRANDE Metodik och teknik Teknikerna vi använt är på efterfrågan av kunden. De använder sig själv av ASP.NET MVC ramverket och vill helst se att det förblir så till kommande bidrag och uppdateringar till sidan. De använder sig av RavenDB som databas och hade även detta som önskemål till detta projekt. RavenDB var för vårt grupp ett helt nytt koncept vilket tog sin tid att komma igång med. Detta tog också upp en del tid från andra delar i projektet till en början då vi inte visste hur den kunde hantera arv och därmed inte riktigt visste hur vi kunde skriva vår backend. Vi valde att använda oss av HTML, CSS och JS ramverket Semantic UI, då Jesper tidigare jobbat med detta. Detta gjorde också det hela lättare att få en mobilvänlig sida, vilket kund tyckte skulle vara ett plus i kanten. Vår metodik har varit ganska fri och mycket upp till var och en för sig. Vi har försökt att genomgående ha möten med endast grupp och med kund för att känna att vi vet att vi ligger på rätt sida. I stort sett varje vecka har vi haft kontakt med kund via antingen möten eller mail. Möten med kursansvarig har även det skett veckovis. Man har fått disponera över sin egen tid och se till att man uppfyller sina och gruppens uppgifter och tidskrav. Gruppen har dock mestadels suttit tillsammans, vilket har fungerat bra. Vi har för många av de större uppgifterna samarbetat, och suttit två eller flera personer vid samma dator för att tillsammans lösa svårare idéer. Enligt vår planering som skett via scrum har det budgeterats med en arbetstid av 15 timmar per vecka. Varje sprint har också pågått en vecka. Dessa 15 timmar är endast tid vi lagt ner på konkreta tasks ifrån product backlog. Utöver dessa timmar har tid även mycket tid fått disponerats till andra omkringliggande ärenden som tar tid. Exempelvis resor, planering, hjälpa andra i gruppen osv. Uppskattningsvis så har tiden vi lagt ner utöver den konkreta tiden på tasks varit runt 20 timmar i veckan. Vi bestämde redan första veckan att dela upp ansvarsområden till personer i gruppen för att få en gruppstruktur. Dock var ingen av dess ansvar bindande. Man har frihet att gå utanför området om så önskas. Organisation av grupp och ansvarsområden: Rasmus Eneman, re222dv Tekniskt ansvarig Erik Magnusson, em222iv Kundkontakt, Projektansvarig 5 of 8

6 David Grenmyr, dg222cs Scrum master Jesper Håkansson, jh222xk Test ansvarig Henrik Gabrielson, hg222aa / Jonas Holte, jh222vp Något som har hjälpt vår grupp oerhört har vart att få lära sig jobba i Github med 6 personer i samma projekt. Versionshantering har stundvis medfört en del problem, då de flesta av oss var ovana att arbeta med Github tillsammans med flera personer. Tekniskt ansvarige, Rasmus, fick efter några veckor en uppgift att skriva ett dokument med instruktioner för gruppen att följa, vilket underlättade hela processen. Resultat Slutprodukten innehåller de delarna som vi planerat och vi känner oss nöjda med vad vi lyckats bygga fram. Vi har skapat ett gränssnitt åt Textilgallerian där de kan skapa nya kuponger. Vi har tänkt igenom många olika scenarier, vilket har gjort att man har väldigt mycket frihet att skapa olika typer av kuponger med många olika egenskaper, som till exempel start och slutdatum, användningsgräns, och minimal köpsumma för att få använda kupongen. Vi har fått fram ett fungerande system som innehåller det som kunden har efterfrågat. Det har även tillkommit extra funktionalitet under arbetets gång som blivit nödvändig för att systemet ska fungera som önskat. Extra funktionalitet Vi lade även till lite extra funktionalitet som Textilgallerian inte bad oss om från början, men som vi ändå ansåg var nödvändigt för att systemet skulle gå att använda på ett bra sätt. Vi lade till exempel till en detaljvy, där man kan klicka på varje enskild kupong för att få ut all information om kupongen som går att få. Det var inte möjligt att lägga in all denna information i en tabell på ett överskådligt sätt, och dessutom behövdes det en vy där man kunde få se en lista på alla engångskoder som skapades i samband med en kupong. Textilgallerian ville också att olika användare på systemet skulle kunna tilldelas olika roller, beroende på vilka rättigheter de skulle ha i systemet (T.ex skapa/ta bort rabatter, redigera användaruppgifter etc.). Eftersom det fanns många olika rättigheter att ta hänsyn till, och vi inte var helt säkra på vilka roller Textilgallerian skulle kunna tänkas behöva, så skapade vi även funktionalitet för att skapa nya roller. Då Textilgallerian har stora möjligheter för att själva skapa de roller som behövs, och de kan även skapa/redigera roller efter behov som kan uppkomma senare. 6 of 8

7 Avvikelser Det enda vi kan se om avvikelse är den statistiska sidan som efterfrågades i början av projektet. Denna har vi inte haft tid att skapa. Vi har dock förberett systemet på ett sätt så att gamla/kasserade rabatter inte tas bort utan endast kommer att ligga som inaktiverade. Detta gör att det kommer att gå att lägga till eventuell statistisk funktionalitet senare. Vi fick en mockup på hur Linus ville att gränssnittet skulle se ut när man skapar rabatter. Denna bild var väldigt värdefull för oss, och vi kunde utgå från den under en lång tid. Dock fattades det många fält i skapa kupong vyn som vi insåg skulle behövas för att man skulle kunna skapa kuponger av de typer som systemet skulle kunna hantera. Därför lade vi också till mycket som inte fanns i den ursprungliga mockupen från Textilgallerian. Testning Vi har i stora drag försökt testa varje task innan den ses som avslutad, framförallt för logiken som hanterar rabatterna på grund att det är den logiken som systemet faktiskt grundar sig på och innebär stora risker om något går fel. Vi har ett testprojekt för varje del i vårt projekt, samt att vi försökt göra en del manuella tester. Innan koden som en person i fråga har skrivit och skickat upp till GitHub faktiskt kommer in i det riktiga systemet (master branchen) så kommer hela test suiten köras på Appveyor för att faktiskt se om hela systemet fungerar tillsammans på en ny nod. Vi ser detta som en väldig fördel just på grund av att många personer arbetar på projektet samtidigt och med olika delar vilket kan resultera i att en del av systemet slutar fungera. Slutsats Projektet har gått bra och har genomförts enligt planering. Till en början trodde vi inte att det skulle bli ett så komplext program som vi ser nu slutändan. Vi var dock noga med att inte låta tid gå till spillo. Redan från början satte vi högt tempo och försökte hitta saker alla kunde göra, ända tills några veckor in i projektet och uppgifterna började ställa sig på kö. Det var allas önskan att få kunna sitta och jobba med alla delarna och det tycker jag vi har uppnått. Alla har fått välja sina egna uppgifter till så stor utsträckning som möjligt. Dynamiken i gruppen har även den fungerat väldigt bra. Alla har försökt att dra sitt strå till stacken med det de har kunnat göra. Det fanns tidigt lite olika tankar om vilket betyg vi skulle satsa på. Men vi gick ihop och bestämde oss för att försöka lägga oss på en fyra. 7 of 8

8 Ofta satte vi två eller fler personer på en och samma uppgift, vilket också har fungerat bra. Det gjorde det enklare att diskutera hur ett problem kunde lösas och vi kunde komplettera varandras idéer med egna tankar, så att varje lösning blev så optimal och genomtänkt som möjligt. Linus har fungerat bra att ha som kund. Vi har hela tiden fått det som efterfrågats och han har vart visat intresse under projektets gång. Han har alltid vart kontaktbar och snabb med att svara, och har har gett oss mycket bra feedback under våra möten med honom. Om något måste påpekas angående möten med kund så det enda negativa att responsen inte varit så snabb som vi kanske önskat där Linus teknikanvsvarige Johan Uddh tagit mer tid på sig att gå igenom koden än vad vi skulle önskat. Projektet räknas nu som klart men hade ändå varit trevligt att hinna ändra det som Johan eventuellt inte tycker är bra. Överlämning och vidareutveckling Vi har kommit överens om att leverera systemet med ett enkelt installationsdokument. Då de är samma tekniker som de redan använder så hoppas vi att det blir en smärtfri process. Vi vet att systemet kommer att testas och implementeras av Johan Uddh hos SciencePark i Kalmar och ger de fria tyglar att utveckla det vidare. Själva idén att använda ett rabattsystem som ett API är något som faktiskt skulle kunna utvecklas och säljas vidare till olika typer att e handelssystem eller butiker som kan tänkas vilja använda det. 8 of 8