INOM
EXAMENSARBETE TEKNIK, GRUNDNIVÅ, 15 HP
STOCKHOLM SVERIGE 2017,
Prototypbyggande av Offertsystem inom besöksnäringen
EMMA BRUNDELL MADELEINE BERNER
KTH
SKOLAN FÖR INFORMATIONS- OCH KOMMUNIKATIONSTEKNIK
Prototypbyggande av Offertsystem inom besöksnäringen
Emma Brundell Madeleine Berner
29 juni 2017
2
Abstract
In the restaurant industry recruitment was difficult, which was due to the lack of skills and resources being lower than the need and the personal network was insufficient. During the time of the study, recruitment took place via the restaurants’ own networks, alternatively via a service that gave applications that did not fit the purpose. A company then created a social network to allow those in the industry to create new contacts faster and easier. The platform filled the needs that were expressed, and the company wanted to expand. The expansion should include a service for helping creating a short-term contact between restaurant and temporary staff. The system would be a prototype that would then continue to evolve. The prototype was supposed to collect an application from a restaurant, communicate it to the staffing agencies and then collect a quote on the staff to show to the restaurant. This was to give the restaurant the choice to choose the quality and the price they considered most suitable. For this the authors collected system requirements from the company with the digital meetingplace, restaurants and staffing agencies, and created a requirement specification for, as well as a prototype of, a digital quotation system. The essay describes only two out of four requirements in detail, to show how the problem was solved in greater detail. The other requirments were handled i the process, only not described in detail in this essay. The prototype was then developed, ending up as a website. The work was completed with a requirement specification for what the system should contain when continuing developing the prototyp, as well as a digital prototype. The prototype made it possible to send an application, a quote about staff and view all quotes connected to a specific application.
2
Sammanfattning
Inom restaurangbranschen var rekryteringen svår, vilket berodde på antalet med kompetens var lägre än behovet samt att nätverket ofta inte räckte till. Vid arbetets tidpunkt skedde rekrytering- en via restaurangernas personliga eller sina anställdas nätverk, alternativt via en tjänst som gav ansökningar som inte passade över huvud taget. Ett företag skapade en digital mötesplats för att låta de inom branschen skapa nya kontakter snabbare och enklare. Mötesplatsen fyllde sitt behov, och de ville därmed expandera och skapa ett system för kortvarig kontakt, så kallad bemanning.
Systemet skulle vara en prototyp som sedan skulle fortsätta utvecklas. Prototypen skulle samla in en ansökan från en restaurang, kommunicera den till bemanningsföretag och sedan samla in en offert på bemanningen för att visa till restaurangen. Detta för att ge restaurangen valet att välja den kvalitén och det priset som de ansåg passande. Författarna samlade in krav för systemet, från företaget med mötesplatsen, restauranger samt bemanningsföretag. Efter de skapade de en krav- specifikation för att kunna utveckla en prototyp av ett digitalt offertsystem. Uppsatsen beskriver endast två av fyra krav i detalj, för att visa hur problemet löst i djupare detalj. De andra kraven hanterades också, men nämns inte på djupet i uppsatsen. Prototypen utvecklades under arbetets gång i kod i form av en webbapplikation. Arbetet resulterade i en kravspecifikation för vad systemet bör innehålla samt en digital prototyp. Prototypen klarade av att skicka ansökningar och offerter om bemanning, samt visa upp offert som berörde en viss ansökan.
2
Innehåll
1 Introduktion 5
1.1 Bakgrund . . . 5
1.2 Problem . . . 6
1.3 Syfte . . . 6
1.4 Mål . . . 6
1.5 Fördelar, etik och hållbarhet . . . 7
1.6 Metodik . . . 7
1.7 Avgränsningar. . . 7
1.8 Disposition . . . 8
2 Teori 9 2.1 Kravspecifikation . . . 9
2.2 En offert . . . 11
2.2.1 Ett offertsystem . . . 11
2.3 Modeller för systemutveckling . . . 12
2.3.1 Arbetsmodell . . . 12
2.3.2 Prototyputveckling . . . 12
2.4 Ramverk . . . 13
2.5 Modellering av en verksamhet . . . 13
2.5.1 Processmodell. . . 13
2.5.2 Klassmodell . . . 13
3 Metoder 15 3.1 Litteraturstudie . . . 15
3.2 Prototyp . . . 15
3.3 Arbetsmetod . . . 16
3.4 Kravframtagning . . . 16
3.5 Utvecklingsmiljö . . . 17
4 Arbetet 19 4.1 Kravframställning och verksamhetsmodellering . . . 19
4.1.1 Workshop med Cheffle . . . 19
4.1.2 Krav 3: Svara på en offertförfrågan . . . 21
4.1.3 Krav 4: Visa upp offerter för jämförelse . . . 22
4.1.4 Klassmodell . . . 22
4.2 Modellering och design av databas . . . 22
4.3 Utveckling av MVP version av applikationen . . . 23
5 Resultat 25 5.1 Sammanfattning . . . 25
5.2 Krav 3 : Svara på en offertförfrågan . . . 27
5.3 Krav 4 : Visa upp offerter för jämförelse . . . 27
3
4 INNEHÅLL
6 Diskussion 29
6.1 Grundkraven . . . 29
6.2 Insamling av krav. . . 29
6.3 Arbetsmetod . . . 30
6.4 Testning . . . 30
6.5 Hållbar utveckling och etik . . . 31
7 Sammanfattning och framtida arbete 33 7.1 Sammanfattning . . . 33
7.2 Framtida arbete. . . 33
7.2.1 Arbetstitlar . . . 33
7.2.2 Skydda arbetaren. . . 34
7.2.3 Skyldigheter och rättigheter vid offerter . . . 34
7.2.4 Fungera i flera webbläsare . . . 34
7.2.5 Säkra länkar i e-post . . . 34
Litteraturförteckning 36
Bilagor 39
Bilaga A Intervjuer 39
Kapitel 1
Introduktion
Inom många branscher var det vedertaget att rekryteringsprocessen inkluderar åtminstone en di- gital applikation för att effektivisera rekryteringen. Det gällde dessvärre inte inom alla branscher under 2017. En orsak till det kan ha varit att det saknades branschspecifika applikationer som hjälper till med rekryteringsprocessen. I denna uppsats ligger fokuset på att ta fram en lämp- lig rekryteringsapplikation för restaurangbranschen. Detta gjordes med hjälp av att ta fram en kravspecifikation och en digital prototyp för ett offertsystem.
1.1 Bakgrund
Den svenska besöksnäringen har ökat snabbt de senaste åren, inte minst inom hotell- och restau- rangbranschen [1]. Bara i Stockholm sägs det öppna en ny restaurang var tredje dag [2]. Det är dock en bransch som under en längre tid har haft stor personalbrist. Branschen har inte bara haft problem med att hitta rätt personal utan även att hitta personal överhuvudtaget, vilket har gjort att konkurrensen om arbetskraft är stenhård [3]. Man räknar bland annat med att det saknas 5000 kockar år 2023 [4]. Samtidigt har många av de som arbetat inom branschen slutat inom ett antal år på grund av arbetsskador eller dåliga avtal [5].
Den mest använda länken mellan arbetsgivare och anställd har varit det personliga nätverket.
I brist på arbetskraft har man ringt upp en familjemedlem eller en vän och bett sina anställda att göra detsamma. Inom restaurangbranschen har det undvikits att använda digitala tjänster som till exempel Arbetsförmedlingen. Detta på grund av att majoriteten av de ansökningar som kommit in via Arbetsförmedlingen har varit personer som saknat motivation samt kompetens. De har endast sökt för att uppfylla en daglig kvot på antal sökta arbeten. Det stora antalet ansökningar och deras kvalité har inneburit en längre och mer ansträngande process än vad arbetsgivarna har haft tid och lust med. Ett samtal inom nätverket har därför varit det effektivaste sättet att få tag på en passande person och veta dennes riktiga kompetens. Det har dock inneburit att arbetsgivarna har gått miste om personal med önskade egenskaper, för att de funnits i ett annat nätverk. Dessutom har proceduren tagit upp en stor del av restaurangernas tid, vilket i sin tur har skapat stress.
När det har kommit till temporär brist av personal, på grund av till exempel sjukdom eller event där det befintliga arbetslaget inte har räckt till, har det funnits två alternativ för att lösa personal- frågan. Antingen har det varit att återigen använda det personliga nätverket, eller att kontakta ett bemanningsföretag. I båda fallen har det varit telefonen som varit medlet för kommunikation. Det andra alternativet har dock betytt stora kostnader med olika resultat. Restaurangen har behövt betala bemanningsföretaget som blir en mellanhand för att komma åt bemanningen. Dessutom har bemanningsföretagen skickat arbetare med varierande kvalité. I vissa fall har det till och med skett att bemanningen har haft otillräcklig kompetens för att klara av uppgiften. Restaurangen har varit tvungen att betala ut lika mycket lön till en arbetare som saknar kompetens, som restaurangen hade betalat för en arbetare med rätt kompetens. Trots att kompetensen varierar hos bemanningen har restaurangerna inte haft något annat val. Antingen ta emot arbetskraft som brister i kompe- tensen eller att inte ta emot någon arbetskraft över huvud taget.
Utifrån besöksnäringens behov har ett företag, vid namn Cheffle, skapat en digital mötesplats
5
6 KAPITEL 1. INTRODUKTION
för arbetsgivare och personal. Tanken var att arbetsgivaren ska skapa en ansökan med kompe- tenskrav och sedan ska personer med rätt kompetens kunna ansöka om arbetsrollen. Restaurangen ska därefter få en lista med ansökande som matchar dessa krav, och kunna kontakta de som anses vara intressanta. Mötesplatsen har kort sagt kopplat ihop rätt kompetens med rätt företag, men dock enbart för längre anställningar. Cheffle beslutade att expandera mötesplatsen, både i funk- tioner och funktionalitet, för att gå vidare i sin utveckling. Mötesplatsen som användes under 2017 hade begränsningar som hindrade en smidig expandering. Kommande steg för plattformen var att kunna hantera fler användare, men också att ge den mer funktionalitet i form av ett nytt system.
Det nya systemet skulle behandla kommunikationen mellan bemanningsföretag och restauranger vid temporär personalbrist.
1.2 Problem
Cheffle saknade ett system som kunde underlätta restaurangernas behov vid kontakt med be- manningsföretag. Systemet skulle kunna minimera tiden och antalet steg från att behovet har uppstått till att bemanningspersonal är på plats. Systemet skulle kunna ge restaurangerna en bättre överblick av vilken typ av arbetskraft de betalar för. Dessutom ville Cheffle, med anledning av expansionen, att systemet enkelt skulle kunna användas både med den existerande plattformen och med den stundande plattformen. Resultatet av systemet skulle presenteras i form av en digital prototyp som skulle uppfylla följande krav:
1. Det ska utvecklas som en separat modul.
2. Funktionaliteten hos prototypen ska fungera.
3. Restauranger ska kunna begära offerter från bemanningsföretag som har ett samarbete med Cheffle.
4. Systemet ska kunna visa inkomna offerter för att en restaurang ska kunna göra ett val av vilken offert som ska tackas ja till.
5. Det ska vara en minimum viable product (MVP).
En MVP innebar att endast de krav som behövdes för att tidigt kunna visa upp produkten (i detta fall en prototyp) för tidiga användare skulle implementeras. Målet med att skapa en MVP var att kunna få feedback på prototypen.
Eftersom att prototypen skulle vara en MVP bidrog det till att de väldigt vida grundkraven blev ett problem. Bredden av grundkraven gav spelrum för tolkningar. Systemets process behövde fler och tydligare krav. Dessutom fanns inga detaljer om hur användarna skulle använda systemet.
Utefter variationen i grundkrav skulle prototypen utvecklas.
1.3 Syfte
Syftet med uppsatsen var att diskutera och presentera framtagandet av krav, samt bygga ett system, som hädanefter benämns som Offertsystemet. Syftet motiverades av att Cheffle varken hade ett offertverktyg eller några specifika krav för ett eventuellt byggande av detta. Kraven som gavs i delkapitel 1.2 var ej specifika nog för att kunna påbörja utvecklandet av offertsystemet.
Dessa kom att behöva utvecklas.
1.4 Mål
Arbetets mål var att undersöka hur en prototyp för ett offertsystem kunde tas fram för ett företag som driver ett yrkesnätverk inom besöksnäringen.
Uppsatsens effektmål var att erbjuda en funktionell prototyp av ett offertsystem som Cheffle skulle kunna implementera.
1.5. FÖRDELAR, ETIK OCH HÅLLBARHET 7
1.5 Fördelar, etik och hållbarhet
Fördelar som offertsystemet skulle ha var minskad stress hos personalen som arbetade på restau- rangerna. Stressen skulle minskas eftersom att restaurangerna skulle få effektivare hjälp att tillsätta bemanning. Detta innebar att befintlig personal inte skulle behöva arbeta övertid eller ansvara för arbetsuppgifter som ej ingick i deras kontrakt. Därmed kunde en försämrad arbetsmiljö för den befintliga personalen förhindras. Det gick även att nå fler bemanningsföretag samtidigt, jämfört med att behöva ringa upp varje bemanningsföretag för att be om offert. Den förbättrade arbets- miljön var ett steg för restaurangbranschen mot ett hållbarare arbetsklimat som inte tärde på medarbetarna [6].
Intervjuerna som kravframställningen och arbetet byggdes på genomfördes under rättvisa och etiska principer. Intervjuobjekten fick vara med och påverka vad som sades under intervjun. Däre- mot var tre av fyra intervjuer med personer som var i kontakt med Cheffle och en av dem använde sig av deras digitala mötesplats. Detta kan ha påverkat deras svar.
Den etik som offertsystemet kom att röra gällde offertsystemets påverkan på arbete, arbetsmiljö samt arbetsgivare och -tagare. Den oro som fanns rörde huruvida personen som anställdes kunde skyddas av kollektivavtal.
1.6 Metodik
En litteraturstudie genomfördes i början av arbetet för att få en djupare förståelse för olika arbets- metoder och vad ett offertsystem innebar. Litteraturen som användes i litteraturstudien hittades via databaser som kungliga Tekniska Högskolans hade tillgång till under våren 2017. Litteraturstu- dien kom att ligga till grund för ett flertal av de beslut som fattades angående utvecklingsmiljön till kodprototypen.
För att lösa problemet behövde Författarna definiera intressenterna, och sedan ta fram krav för offertsystemet med hjälp av dem. För att kraven skulle vara trovärdiga och genomförbara användes två olika metoder för kravframställningen och datainsamlingen: workshop och intervjuer. De for- mulerades sedan för att mätas vid arbetets slut. För att ta reda på vilka processer som skulle ingå i offertsystemet och kunna definiera vilka intressenterna var genomfördes en workshop tillsammans med Cheffle. Workshopen hjälpte även till med att besluta vilka avgränsningar som behövdes gö- ras. När intressenterna var definierade hölls det intervjuer med dem för ta fram bättre krav över hur systemet skulle användas. Parallellt med intervjuerna pågick utvecklandet av kodprototypen.
I utvecklingsarbetet användes metoden extreme programming (XP). Resultatet kom att verifieras av uppdragsgivaren Cheffle i slutet av arbetet.
1.7 Avgränsningar
En avgränsning som gjordes var att enbart skapa en prototyp som var anpassad för att användas i webbläsaren Google Chrome. Om fler webbläsare hade tagits hänsyn till hade det inneburit att CSS-koden i prototypen hade behövts anpassats till de olika webbläsarna.
En annan avgränsning som gjordes var att inte undersöka hur användargränssnittet skulle an- passas till användarna. Det kom att ha stor inverkan på hur slutresultatet såg ut visuellt sett.
Istället skulle prototypen enbart innehålla den bakomliggande funktionaliteten.
Processen i offertsystemet att kunna tacka ja eller nej till en offert togs ej med. Det på grund utav att Cheffle ej hade bestämt när de skulle kliva ur förmedlingen av bemanning, och att det därför var säkrast att utesluta det från arbetet.
Det beslutades även att offerterna enbart skulle gälla en individ istället för en grupp. En offert för en grupp var en viktigt del av systemet eftersom att restaurangerna vid event ofta behövde flera olika typer av kompetenser. Dock fanns inte resurser i form av tid för att utforska alternativa lösningar. Därför lämnades det utanför arbetet.
8 KAPITEL 1. INTRODUKTION
Att gå djupare på hur en arbetstitel skulle utformas och hur en datastruktur skulle se ut ge- nomfördes inte. Det på grund utav att det problemet har många olika lösningar och det kräver resurser i form av tid för att kunna komma fram till en fungerande lösning. Den resursen fanns ej.
I uppsatsen tas det upp i kapitel 4 en sammanfattning om hur alla kraven implementerades. I kapitel5sammanfattas även hur alla krav tillsammans fungerade i prototypen. Uppsatsen begrän- sas dock genom att i detalj enbart beskriva två av kraven.
1.8 Disposition
I följande kandidatuppsats finns totalt sju kapitel:
Kapitel ett är en introduktion till uppsatsen som berättar bakgrunden till studien och vilket pro- blem som skulle undersökas. Kortfattat berättades det även om målet med arbete, metoder som användes och arbetets koppling till etik och hållbarhet.
Kapitel två är en fördjupad teoretisk bakgrund till hur krav kan tas fram, vad en offert och ett offertsystem är. Det tas även upp varför agila arbetssätt är fördelaktiga och teori om utveckling av mjukvarusystem.
Kapitel tre diskuterar och analyserar val av metoder för att genomföra projektet, samt desig- nen av utförandet.
Kapitel fyra handlar om det utförda arbetet och beskriver de vetenskapliga metoder som användes för implementationen av arbetet.
Kapitel fem presenterar resultatet som framkom från arbetet. En översiktlig beskrivning av proto- typens funktionaliteter finns.
Kapitel sex analyserar och diskuterar resultatet, samt reflekterar över dess relation till hållbar utveckling och etik.
Kapitel sju presenterar en sammanfattning samt förslag på framtida arbete.
Kapitel 2
Teori
Information som läsaren eventuellt inte haft sedan tidigare, som anses vara nödvändig att känna till för vidare läsning av uppsatsen, återfinns i detta kapitel. Kapitlet tar först upp vad en krav- specifikation är, hur de kan tas fram och hur kraven kan se ut. Efter det följer en beskrivning av vad en offert är och de offertsystem som existerade år 2017 som Författarna kunde ta lärdom av.
Kapitlet beskriver även modeller som använts för själva arbetsproceduren samt prototypen. Sist presenteras vad ett ramverk är och varför arbetet krävde ett.
2.1 Kravspecifikation
Som nämnt i avsnitt1.2 var en del av arbetet att ta fram en kravspecifikation för det stundade offertsystemet. Vid skapandet av ett mjukvarusystem behövs riktlinjer eller en guide för att ut- vecklandet ska kunna genomföras smidigt. En kravspecifikation kan användas för att bena ut vad det nya systemet ska innehålla och potentiella begränsningar som kommer att påverka slutresulta- tet. Kraven tas fram med utvecklingsteamet (Författarna) och uppdragsgivaren (Cheffle) och/eller användarna (bemanningsföretag och restauranger).
Orsaken till att en kravspecifikation är ett viktigt arbete beror på att det kan förhindra miss- förstånd i utvecklingsprocessen. Genom kravspecifikationen kan potentiella problem och begräns- ningar definieras. Utan en kravspecifikation kan eventuella feltolkningar bli dyra eftersom att det kräver både tid och resurser för att hantera de negativa konsekvenserna. Speciellt om det uppkom- mer sent under processens gång [7]. För arbetets skull var det också viktigt för Författarna att förstå vilka förväntningar alla intressenter hade för att kunna göra ett lyckat arbete. Kravspeci- fikationen används nämligen även som en checklista mot det färdiga arbetet för att enkelt kunna mäta om arbetet är klart eller inte. Att ta fram en bra och pålitlig kravspecifikation kräver en bra kravteknik. Kravtekniken kan delas upp i fem aktiviteter: kravframställning, modellering- och analyseringskrav, kommunikationskrav, överenskommelsekrav och utvecklingskrav [7], [8].
Kravframställning
I första aktiviteten fokuserar man på problemet och vad som intressenterna är intresserade av att få ut från systemet, istället för potentiella lösningar. Det handlar om att ta fram alla möjliga sorters krav. Aktiviteten definierar även systemets begränsningar [9]. Enligt en studie från 2006 är den mest effektiva tekniken för att ta fram dessa krav intervjuer, vilket Författarna använde i sitt arbete [10].
En annan teknik är att framställa krav i grupp och den fokuserar på att bringa förståelse mellan olika intressenters önskemål. I arbetets fall fanns tre intressenter: Cheffle, bemanningsföretag och restauranger. Alla tre kunde ha olika åsikter om hur offertsystemet kunde användas. Andra tekniker som potentiellt kunde passa arbetet var frågeformulär och undersökningar. De två typerna som användes för att upptäcka krav var workshop och intervjuer.
Workshop En workshop går ut på att intressenterna ska ta fram kraven på produkten tillsam- mans. Beställare, användare och utvecklare är de stora grupperna som deltar i workshopen. Dessa grupper kan innehålla mindre roller som workshopledare, dokumenterare, projektledare, systema- nalytiker, IT representant eller finansiär [11]. Alla ska få berätta om sina krav för de andra parterna,
9
10 KAPITEL 2. TEORI
som sedan förtydligas eller modifieras beroende på vilka parter som blir berörda. Det handlar om att förmedla och förstå vilka behov som varje part har, hur viktiga kraven är och utefter det skapa den mest välfungerande lösningen. En beställare kan till exempel kräva en funktion som utveck- lingsteamet måste säga nej till eftersom att de vet att den inte är genomförbar. De två parterna kan därmed kommunicera angående detta och möjligtvis ge ett förslag på en lösning som ger en snarlik funktion. Workshops bör ha ett konkret mål för att ha en fokuserad grupp och för att innan kunna definiera när gruppen nått målet. En baksida med workshops är att de tar tid och är energikrävande. Ett beslut om ett krav kräver att alla intressenter är överens.
Intervjutekniker Det finns tre olika typer av intervjukategorier: strukturerad, ostrukturerad och semi-strukturerad [9], [12]. En ostrukturerad intervju innebär att intervjuaren inte förbereder vilka frågor som ska ingå och är en passande teknik när ämnet som ska diskuteras inte är tyd- ligt. Motsatsen är en strukturerad intervju med tydliga och planerade frågor. Den strukturerade intervjun styrs av intervjuaren. Den semi-strukturerade intervjun är en kombination av nämnda kategorier. Det innebär att vissa frågor är planerade, men det kommer även dyka upp frågor som upptäcks under intervjun skede. Detta passar när ämnet är känt och intervjuaren vet vilka svar som behövs, men inser också att det finns frågor man ännu inte känner till. Det kan röra sig om att med hjälp av intervjuer ta reda på detaljer om ämnet som berörs, eller bredda kunskaperna i ett område där man inte har tidigare erfarenhet. För Författarna gällde båda dessa punkter eftersom att många detaljer var oklara, och förståelsen för restaurangbranschen var låg.
När en intervju genomförs, oavsett kategori, bör ledande frågor undvikas. Orsaken är att ledande frågor kan få den intervjuade att ge det svar som intervjuaren vill höra istället för det svar som den intervjuade vill ge. Därmed blir svaret påverkat och kan anses som partiskt inflytande [13].
Detta ger falsk data som ej blir trovärdig. Frågor som är slutna, alltså som kan besvaras med ett ja eller nej, bör även de undvikas eftersom att de ger ytterst lite information. Slutna frågor är användbara när intervju behöver analysera kraven i detaljnivå, men först måste intervjuaren uppnå en hög kunskap om området och kraven. Därför är slutna frågor inte en passande teknik för arbetet. Detsamma gäller för varför -frågor [12].
Modellering- och analyseringskrav
Modellering ska ta fram beskrivningar på vad kraven som togs fram i första steget gör för nytta.
Nedan följer ett urval av olika modellkategorier som kan användas.
Det finns två typer av krav: funktionella och icke funktionella. Funktionella krav beskriver vad systemet ska ha för funktionaliteter, medan de icke funktionella kraven tar upp vad för kvalité som krävs av systemet. Att modellera ickefunktionella krav kallas även för att modellera kvalitetskrav.
De ickefunktionella kraven formas av vad de funktionella kraven innehåller. Med det menas att när systemets viktigaste funktioner har definierats brukar de mest betydande ickefunktionella kraven framträda utan större analys [14]. I ett digitalt offertsystem skulle ett funktionellt krav kunna vara att ta emot en offert från ett bemanningsföretag och visualisera det för rätt restaurang. Det icke funktionella kravet skulle kunna vara att bibehålla låg exekveringstid.
En modellering av både systemet och Cheffles roll i det tar fram syftet med systemet, utifrån beteendet av användarna av systemet. Vid konstruktionen av offertsystemet modellerades hur re- stauranger, bemanningsföretag och Företag vill använda systemet.
Kommunikationskrav
I det tredje steget handlar det om hur kraven ska dokumenteras och hur de ska formuleras. Det gäller att kraven ska kunna kommuniceras till alla intressenter på ett effektivt sätt. Det finns olika tekniker för att göra detta [15]. Det som har betydelse är ifall kraven är läsbara, att de går att analysera, skriva om och validera. En variant av teknik är user stories.
User stories En beskrivning av vem som ska kunna göra vad och varför, för att se vilket värde en händelse har. Se tänkbart exempel för ett potentiellt offertsystem nedan.
2.2. EN OFFERT 11
Som en användare som tillhör en restaurang vill jag fylla i ett formulär för att enkelt kom- municera de kunskaper jag efterfrågar.
Som en användare som tillhör en restaurang vill jag se alla inkomna offerter för att kunna jämföra dem efter vad som är lämpligast för mitt behov.
Denna teknik skiljer sig från två liknande tekniker IEEE 830 och Usercase. Där beskrivs antingen enbart funktionerna eller enbart vilken funktion som appliceras på vilken användare. Exempel finns nedan:
IEEE 830: Det ska gå att fylla i ett formulär.
Usercase: Som en restaurang-användare vill jag kunna se alla inkomna offerter.
Överenskommelsekrav
Denna aktivitet handlar om att få de olika intressenterna att vara överens om de bestämda kra- ven. Det är för att validera att de framtagna kraven stämmer överens med samtliga intressenters önskningar. Även om alla parter är överens måste kraven vara rimliga och vetenskapligt möjliga.
Valideringen, som görs av alla intressenter kan därför vara svår.
Utvecklingskrav
I efterhand kan kraven ändras, därför är det viktigt att kunna hantera förändringar. Exempel på förändringar kan vara att ta bort eller lägga till krav. En förändring sker på grund av intressenters nya perspektiv, vilket kan uppstå bland annat efter en intervju. En orsak till förändringar kan vara att kunden inte visste exakt vad den ville ha, utan inser detta först efter att de har sett en prototyp. Ibland upptäcker de inte förrän då att de behöver ställa fler krav, eller behöver en annorlunda lösning. Under arbetets gång skedde intervjuer kontinuerligt för att uppdatera kraven.
2.2 En offert
Innan en kund eller ett företag bestämmer sig för att köpa en tjänst eller påbörja ett samarbete ber de ofta om en offert. En offert är ett erbjudande på ett samarbete eller en tjänst mellan två parter.
Denna kan vara muntlig eller skriftlig, men ska innehålla ett prisförslag och villkor för arbetet. Mer detaljerat bör offerten ta upp viktig information som specifikation av arbetet. I ett offertsystems fall gäller bland annat företagets kontaktinformation, företagets adresser, offertens förfallodatum, tim- och totalpris, datum, arbets- och betalningsvillkor samt villkor för övertid [16]. Detta för att säljaren, det vill säga bemanningsföretagen, ska visa vad de erbjuder till vilket pris. Köparen ska därmed kunna se om det som erbjuds är vad som efterfrågas och om priset känns rimligt. Vad som förmedlas i offerten måste säljaren stå för och köparen kan se över det.
2.2.1 Ett offertsystem
Uppsatsen undersökte tre svenska digitala offertsystem för att skapa underlag till kravspecifikatio- nen. Namnen på företagen var Offerta, ServiceFinder och Dorunner. Alla tre hade som syfte att knyta kontakter mellan kunder och företag, dock mestadels inom bygg- och renoveringsbranschen.
För kunder var syftet att jämföra olika offerter. Processen innehåller fyra olika faser; ansökan, skapa offert, kontakt och betalning.
Ansökan På offertsystemens webbsidor väljs en kategori för vilken hjälp som sökes. Sedan val- des en underkategori för att specificera behovet. Platsinformation uppges för att ange vart arbetet kommer att ske. Till exempel Flytt och Transport följt av Piano och kassaskåpsflytt, vilket för restaurangbranschen skulle kunna vara Bartender följt av Cocktail-bartender. Detta blir en offert- förfrågan.
Skapa offert I detta steg har företaget sett kundens offertförfrågan och ska nu skapa en offert för arbetet. Hos ServiceFinder kan företagen göra en offert efter webbsidans mall eller göra en egen från grunden [17] . Mallen innehåller de viktiga detaljer som nämndes i början av delkapitel2.2.
Den innehåller även ett fält där företagen kan förklara för kunden varför de ska välja just detta företag.
12 KAPITEL 2. TEORI
Kontakt När företaget som skickade en offertförfrågan har fått in offerter kan offerterna jämföras mot varandra. För Offerta och ServiceFinder fick kunden maximalt sex respektive fem offerter att jämföra. Orsaken var att för många alternativ kan göra offertjämförelsen komplicerad. Kundens bedömning går ut på att, förutom att jämföra offerterna i sig, även se bemanningsföretagens om- dömen och deras referenser från tidigare arbeten. När en kund som bestämt vilken offert och vilket bemanningsföretag de vill ha sker kontakt med bemanningsföretaget ofta via telefon eller e-post. De kan träffas för att göra en ordentlig utvärdering av arbetet och specificera priset. Detta steg liknar mycket hur det går till när man söker bemanning i restaurangbranschen. Cheffle som vill utveckla ett nytt offertsystem hoppas kunna minimera eller eliminera dessa steg för att ge en mer effektiv bemanningsprocess. När arbetet är utfört kan kunden ge en omdöme av bemanningsföretaget som blev vald på den webbsida som användes.
Betalning Faktiska fakturor och bestämmelser om jobb sker utanför de olika offertsystemens kontroll. Skälet är att företagen som skapar offerter i många fall måste ha mer information om det önskade arbetet, och ibland göra ett besök för att kunna få en mer exakt bedömning. Alltså sker betalningen mellan kund och bemanningsföretag, istället för via offertsystemet.
2.3 Modeller för systemutveckling
För att utveckla offersystemet på ett effektivt sätt undersöktes olika modeller för systemutveckling.
Nedan presenteras respektive modell med tillhörande metoder inom arbetssätt och prototypfram- tagning.
2.3.1 Arbetsmodell
Det finns två modeller som används inom systemutveckling som är vedertaget de vanligaste. Den äldsta är den traditionella modellen, dit till exempel vattenfallsmodellen tillhör. Den nyare som fick fäste under 2000-talet är den agila modellen. Båda modellerna kommer med fördelar och nackdelar.
Gemensamt för de metoder som ingår i den traditionella modellen är att metoderna är uppdelade i faser. Varje fas måste avslutas innan nästa påbörjas. Projektets resultat mäts genom att avgöra ifall planeringen följdes, och inte ifall resultatet uppfyller kundens förväntningar [18]. Om kraven är tydliga för ett system är en traditionell metod det mest lämpade valet eftersom att det finns tydliga avslut som bestäms innan arbetets utveckling startar. Däremot om kraven inte är lika detaljrika, om det finns en del frågetecken eller om det ändras kring hur kraven ska implementeras är en agil metod ett bra val.
Agil metod innebär ett flexibelt arbetssätt där man jobbar i iterationer. Det handlar om att upp- datera produkten, eller i Författarnas fall även kravspecifikationen, kontinuerligt istället för att enbart leverera den slutgiltiga produkten i slutändan. Tanken är att metoden minimerar tidsspill som skett i tidigare projektarbeten. Tidsspill kan uppstå på grund av missförstånd mellan utveck- lare och beställare, att beställare inte riktigt vet vad de vill ha eller planering som måste göras om från början. Skälen och feltolkningarna upptäcks oftast tidigare med en agil metod eftersom att återkopplingen till intressenterna sker kontinuerligt [19]. Den agila metoden tillåter processen att vara flexibel och kan därmed enkelt justera produktens utveckling om kraven påverkas.
2.3.2 Prototyputveckling
Eftersom att Cheffle önskade en prototyp av typen MVP som slutprodukt undersöktes vad en prototyp innebar. En prototyp beskrivs av IEEE som: A type of development in which emphasis is placed on developing prototypes early in the development process to permit early feedback and analysis in support of the development process [20]. Prototyper används inom mjukvaruutveckling för att enkelt kunna ge en bild av systemet som tagits fram och för att kunna validera att det är en korrekt implementation av kraven [21]. Den prototyputveckling som valdes för arbetet kallas för evolutionär. Alternativet var en Throwaway prototype, där det viktigaste är att arbetet går fort.
Prototypen som skapas är enkel och kommer inte att användas i slutändan. Eftersom att Cheffle ville ha en MVP att bygga vidare på valdes den evolutionära prototyputvecklingen.
2.4. RAMVERK 13
Evolutionär prototypframtagning
Vid användning av evolutionär prototypframtagning innefattar prototypen enbart de krav som är utgör grunden för systemet [22]. Första steget är att implementera kärnkraven, alltså de krav som är fundamentala för systemet. Genom iterativt arbete utökas antalet krav som implementeras. Pro- totypen får även kontinuerlig återkoppling från intressenterna som antingen påverkar existerande krav eller skapar nya. Restauranger och bemanningsföretag hade under arbetet möjlighet att bidra med återkoppling för att utveckla den prototyp som konstruerades. Den slutgiltiga prototypen var en färdig MVP tack vare att konstruktionen av den hade haft fokus på att ta fram ett robust och stabilt system från grunden [21].
2.4 Ramverk
Eftersom att avgränsningarna gjordes för att fokus skulle läggas på att skapa en snabb prototyp med funktionalitet istället för användbarhet, ansågs det behövas ett ramverk för webbutveckling.
Ett ramverk har en mängd samlade funktioner som gör det lättare att utveckla. I Författarnas fall behövdes funktioner för att underlätta det visuella, kommunicera med ett databassystem och möjligheten att skapa ett formulär. En svårighet med ramverk är att problemen som potentiellt uppstår kan vara svåra att lokalisera. Detta beror på att man inte har överblick över all kod. Den blir därmed svår att felsöka. Däremot finns det ofta goda hänvisningar i dokumentationen av ram- verken som kan beskriva hur man bör gå tillväga.
Flask är ett ramverk som är skrivet i Python, som av många forum för webbutveckling anses var enkelt att komma igång med om man inte använt ett ramverk tidigare [23]–[27]. Även om vem som helst kan ha skrivit inläggen, ansåg Författarna att påståendet var trovärdigt eftersom att minst fem olika forum online sade samma sak av flera olika användare. Ramverket har tillägg för bland annat att skapa formulär, logga in, hantera databaser, hantera e-post med mera.
2.5 Modellering av en verksamhet
Att modellera en verksamhet kan göras med olika typer av modeller. En verksamhet kan vara en produkt, vilket i detta fall är offertsystemet. De olika modellerna relaterar till varandra. Alla verksamhetsmodeller tillsammans bidrar till förståelse för verksamheten.
2.5.1 Processmodell
En processmodell består av olika processer i verksamheten. En process är en händelse som genererar data. I modellen förklaras vad som sker i de olika processerna och i vilken ordning som processerna genomförs.
2.5.2 Klassmodell
En klassmodell är ett modelleringsformat som beskriver vilka klasser som ingår i en verksam- hetsmodell. En klass består av ett namn och kan ses som en datatyp, dock utan en detaljerad beskrivning av innehållet i datatypen. En klassmodell presenterar vilken data som behövs för att genomföra olika processer.
För att kunna beskriva relationen mellan två klasser används förekomsten (eng. cardinality) av klassernas data i relationen. Förekomsten presenteras via tecken som står för antalet gånger en klass kan existera i förhållandet mellan de två klasserna. En relation har två ändar, vilket ger rum för att beskriva förekomsten av båda klasserna i relationen. Exempel på tre typer av relationer är följande:
• En till en: 1..1 - 1..1
• En till många: 1..1 - 0..*
• Många till många: 0..* - 0..*
14 KAPITEL 2. TEORI
En asterisk representerar att antalet förekomster ej är fastställt. Ett exempel på en en till en relation är ett gift par. Person A kan bara vara gift med en annan person, och person B kan bara vara gift med en annan person. Alltså kan ingen person vara gift med flera personer samtidigt.
Exempel på en en till många relation är att en grundskola kan ha inga eller flera elever. Medan en elev kan bara gå i en grundskola. Ett exempel för en många till många relation är att en elev kan ta många kurser samtidigt, och en kurs kan ha många elever inskrivna samtidigt.
Kapitel 3
Metoder
Arbetet med att skapa ett offertsystem krävde, liksom andra projekt, att utvecklarna hade den information de behövde. Författarna hade ett krav från Cheffle som gjorde att informationen kunde begränsas. Kravet var att resultatet av arbetet skulle vara en prototyp, som skulle kunna användas med den existerande plattformen men också med en kommande plattform. Utöver det saknades krav på användningen av offertsystemet. Därför inleddes arbetet med en litteraturstudie om olika prototypbyggen, arbetsmetoder, kravframställning och utvecklingsmiljöer.
3.1 Litteraturstudie
Litteraturstudien gick till på sådant sätt att databaserna hos IEEE, ACM och KTHs Divaportal genomsöktes på ämnen som arbetet berörde. Dessa databaser valdes för att IEEE och ACM har många texter relaterade till IT, och KTHs Divaportal har givit bra exempel på liknande arbeten gällande systemutveckling. Eftersom att texterna på IEEE var på engelska och för att maximera antalet relevanta träffar var sökorden på engelska. Sökorden var generellt: web, application, softwa- re, development, requirement, requirement elicitation, workshop, interview techniques och prototype building.
Den litteratur som sedan valdes ut från IEEE och ACM ansågs vara av hög trovärdighet, och därmed vara pålitliga källor. Detta grundades på att de var daterade mellan 1990 och 2010 och att antalet citeringar oftast översteg 20 stycken. Författarna menade att källorna gick att lita på eftersom de fått bekräftelse under lång tid. Utöver nämnda databaser användes även Googles sökmotor för att finna svar på frågor om offerter, offertsystem, olika programmeringsspråk och ar- betsmetoder. För information om offerter och liknande system användes webbsidor för offertystem.
Källorna för språk och metoder var av bra trovärdighet eftersom att de var ursprungskällor. Nedan följer en sammanfattning av de beslut som togs om metoder för arbetet. De följs av beskrivningar av hur varje metod användes.
Baserat på litteraturstudien valde Författarna att arbeta med den agila metoden XP och den evolutionära prototypmetoden. Som tekniker för kravframställning valdes workshops och intervju- er. För prototypen beslutades det att den skulle programmeras i språket Python. Ramverket som valdes var Flask och den valda relationsdatabasen var MySQL.
3.2 Prototyp
Valet föll på en prototyp av evolutionär karaktär, som beslutades tillsammans med Cheffle. Orsaken var grundkravet om att resultatet skulle vara en modul som kunde användas i både den befintliga plattformen och i den kommande plattformen. I och med att en evolutionär prototyp designas med en stadig grund är den gjord för att kunna använda prototypens kod till den slutgiltiga versionen.
15
16 KAPITEL 3. METODER
3.3 Arbetsmetod
Det som avgjorde valet mellan att använda den traditionella modellen eller den agila modellen var att den agila modellen tillät flexibilitet. Metoden tillät förändring av kraven genom kontinuerlig kontakt med intressenterna. På grund av att grundkraven inte var tydliga från början tillät den agila modellen författarna att börja arbeta med utvecklingen av prototypen samtidigt som att kravframställningen pågick. Om den traditionella modellen hade valts hade alla krav behövts fast- ställas innan utvecklingen av prototypen hade kunnat påbörjats. Det skulle bidra till att arbetet med prototypen hade getts kortare tid att bli klart. Det hade påverkat antalet krav som kunde uppfyllas under arbetets gång.
Inom de agila metoderna föll valet på XP främst för att den metoden var anpassad för mind- re projektgrupper och arbetade med mindre iterationer. SCRUM övervägdes eftersom att båda författarna hade använt metoden tidigare, vilket skulle eliminerat tid till att studera en ny metod.
SCRUM krävde dock att minst fyra personer deltog i arbetet för att kunna genomföra metodens dagliga standup-möten, där alla medlemmar skulle presentera vad de har gjort och vad som ska göras. Mötena skulle vara bortkastad tid på grund av att projektgruppen enbart bestod av två personer. Däremot innehöll XP bestämda tekniker som författarna hade använt i tidigare arbeten och där med snabbt kunde komma igång att arbeta med. Ett exempel på en sådan förutbestämd teknik var user stories som användes för att strukturera kraven. User stories användes eftersom att XP byggde på tydlig kommunikation och återkommande återkoppling [28].
Ett annat bra alternativ till arbetsmetod var DSDM som liknade XP med user stories, iterationer, kommunikation och fokus på att få fram en prototyp snabbt och billigt. DSDM hade dessutom inga krav på tekniker av själva arbetet, vilket upplevdes som fritt och flexibelt. Dock använde sig metoden utav en livscykel-syn som krävde en del inlärning vilket gjorde att XP var att föredra. En teknik som XP utnyttjade var parprogrammering, som passade författarna ypperligt bra. Efter att ha gjort en uppskattning av Författarnas kunskaper ansågs parprogrammering som en bra teknik för att snabbt komma igång med utvecklingen och ett bra sätt för att upptäcka buggar i tidigt skede.
3.4 Kravframtagning
Vid framtagandet av kraven valdes teknikerna workshop och intervjuer av semi-strukturerad sort.
Workshopen skedde tillsammans med Cheffle medan intervjuerna riktades mot bemanningsföretag och restauranger.
Workshop En workshop genomfördes tillsammans med Cheffle för att diskutera den odefinie- rade lösningen. Målet med workshopen var att ta reda på hur hela processen för systemet skulle se ut, vilka intressenter som existerade och vilka begränsningar Författarna skulle sätta. Det var ett bra sätt för båda parterna att formulera sina tankar om ett potentiellt offertsystem, eftersom att Författarna inte hade tidigare kunskaper inom offert-området eller mycket erfarenhet av web- butveckling. Samtidigt kunde Cheffle uttrycka sina behov av ett sådant offertsystem, utifrån vilka Författarna kunde klargöra vad de trodde sig klara av och inte. Det medförde att det var lättare att definiera begränsningar för arbetet som berodde på olika faktorer såsom arbetets tidsram, För- fattarnas kompetens och Cheffles krav, samt deras obeslutsamhet om vissa delar av offersystemet.
Det beslutades vid bokningen av workshopen att den skulle ta en timme och ske i ett mötesrum.
Den avsedda platsen som stängde ute eventuella störningar, tillsammans med tidsramen, och det gemensamma målet skapade ett effektiv flöde och ett önskat resultat.
Intervjuer Intervjuer utsågs till en lämplig teknik för att få fram krav från systemets användare.
Ett semi-strukturerat sätt valdes till intervjuerna. Det utfördes genom att ha en del frågor plane- rade i förväg och tid för att öppet diskutera oförberedda frågor. Författarnas avsaknad av kunskap om bemanningsprocessen för restaurangen medförde att de planerade frågorna kändes otillräckliga.
Genom att minska antalet frågor och öppna upp för intervjuobjektet att styra intervjun ansågs det att resultatet från intervjuerna kunde bli mer varierande och givande.
Intervjuerna hade tre områden som behandlades i nämnd ordning: bemanningsprocessens utseende
3.5. UTVECKLINGSMILJÖ 17
vid intervjutillfället, hur ett digitalt offersystem skulle kunna se ut och feedback på Författarnas pappersprototyp. Författarna skapade en pappersprototyp efter deras kunskaper över hur de trodde att ett offertsystem kunde se ut för att kunna få ut mer av intervjuerna. Anledningen var att an- vändare ibland inte vet vad de vill ha av ett system förrän de får se ett förslag på det, och en riktigt prototyp hade inte hunnits utvecklas vid tiden för intervjuerna. Eftersom att pappersprototypen togs upp i slutet av intervjun påverkade den inte användarnas egna tankar om ett offertsystem.
Valet av intressenter att intervjua var begränsat och kan ha påverkat de krav som skapades.
Efter flertalet misslyckade försök att få kontakt med både bemanningsföretag och restauranger, kopplades Cheffle in för stödja processen. Tack vare dem anordnades intervjuer med två beman- ningsföretag och en restaurang, vilka alla haft kontakt med Cheffle innan. De kände till Cheffles digitala mötesplats även om bara restaurangen använde sig av den. Det går att ifrågasätta huruvi- da deras svar reflekterade branschen i sin helhet, och om de på något sätt var partiska med eller mot Cheffle. Den andra restaurangen som intervjuades tillfrågades eftersom att restaurangen låg i närområdet av platsen där offertsystemet utvecklades samt att personalansvarig på restaurang- en ställde upp på en intervju. De hade ingen kontakt med varken Cheffle eller Författarna, men använde sig dock av ett enskilt bemanningsföretag. Deras svar och önskemål kan därför ha varit anpassade för kunder till det bemanningsföretaget.
Intervjuer skedde kontinuerligt under arbetets gång. Den återkommande återkopplingen gjorde arbetet effektivt. Värt att notera var att intervjuobjekten såg pappersprototypen i olika stadium.
Ett alternativ till intervjuerna hade varit en workshop för alla intressenter. Det hade inneburit att Cheffle, bemanningsföretag och restauranger kunde ha diskuterat varandras behov och kommit fram till krav för offertsystemet tillsammans istället för att de samlats in separat. Kraven som hade uppkommit hade haft större vikt eftersom att de varit krav som alla parter varit överens om.
Istället gjordes nu en tolkning och hopsättning av de olika kraven av Författarna. Orsaken till att detta inte skedde var att varken tiden eller erfarenheten fanns för att anordna en stor workshop som skulle kunna ha givit lämpliga resultat.
3.5 Utvecklingsmiljö
Med XP tillkom kravet att resultatet skulle vara en produkt av kod. Python valdes för att det var ett vanligt förekommande programmeringsspråk för utveckling av webbapplikationer samt att det fanns en del kunskap om programmeringsspråket sedan tidigare hos ena Författaren. PHP hade varit ett bra val, men är känt för att inte alltid ha välskriven kod vilket kan ställa till med problem när information behöver sökas i PHP-forum. Eftersom Författarna även var ute efter att utbilda sig själva, noterades det att Python ansågs vara mer användbart, även i områden utanför webbutveckling.
För databashantering krävdes det att systemet kunde kommunicera med Cheffles redan existe- rande system, vilket var en databas baserad på databassystemet MySQL. Ramverket Flask valdes för att det var ett mikroramverk och därmed inte innehöll funktionaliteter som ej kom att använ- das i applikationen. Snabb konstruktion, med enbart funktioner som det fanns behov av valdes enligt Cheffles uppdragsbeskrivning. Den funktionalitet Flask hade som däremot användes och underlättade bygget av prototypen var dock bland annat inloggning, skapa och hantera formulär, skicka mejl från applikationen samt hantera databasanrop. Dessutom krävde det en mindre inlär- ningskurva än ett fullt utvecklat ramverk. Ett exempel på ett fullt utvecklat ramverk var Django.
Django hade en större online community vilket hade kunnat hjälpa om arbetet fastnade i ramverks- specifika frågor. Django hade dock krävt längre startsträcka innan utvecklingen kommit igång på riktigt. Flask lämpar sig dessutom väl med MySQL-databaser eftersom ramverket är designat för att underlätta den typen av kommunikation. Efter alla dessa beslut blev textredigeraren av typen PyCharm eftersom att den är anpassad för utveckling med Python, och var gratis för studenter.
18 KAPITEL 3. METODER
Kapitel 4
Arbetet
För att kunna nå fram till resultatet genomfördes ett grundligt arbete med kravframställning och modellering av offertsystemet. Kapitlet delades in i tre delar för att kunna ge en tydlig presentation av hur vägen till resultatet har genomförts. För att avgränsa omfattningen av kapitlet valdes två krav ut för att beskrivas i mer detalj om hur de implementerades. Dock implementerades alla krav till resultatet.
4.1 Kravframställning och verksamhetsmodellering
Kraven som gavs från Cheffle ansågs vara vaga. Det bidrog till att de var enkla att skapa olika tolkningar om vad som skulle ingå i offertsystemet. Det ledde till att arbetet startade helt från grunden, där även kravframställningen ingick. Efter det skedde intervjuer med bemanningsföretag och restauranger för att samla in krav om hur systemet skulle användas i mer detalj.
4.1.1 Workshop med Cheffle
För att framställa krav genomfördes en workshop i tidigt skede av arbetet. Målet med worksho- pen var att kraven som togs fram skulle kunna användas för att skapa en konceptuell modell över offertsystemet. Workshopen genomfördes tillsammans med handledaren från Cheffle. Resultatet från workshopen kom att användas för att verifiera det slutgiltiga resultatet av arbetet tillsam- mans med grundkraven som nämndes i delkapitel1.2. Ett viktigt delresultat från workshopen var definieringen av vilka intressenter som fanns för offertsystemet. Det var totalt tre stycken: Cheff- le, bemanningsföretag och kunder till Cheffle i form av restauranger. En konceptuell modell av offertsystemet skapades efter workshopen. Den konceptuella modellen beskrev verksamheten (of- fertsystemet) i form av en processmodell.
Processmodellen beskrivs i figur 4.1 och kan beskrivas med att offertsystemet ägdes av Cheffle.
Offertsystemet fungerade som en bro mellan restauranger och bemanningsföretag. I processmo- dellen fanns det fyra processer, som representeras av pilarna. Den första processen var att en restaurang fyllde i ett formulär med deras behov av bemanning, och därmed skapade en offert- förfrågan. Den andra processen skickade offertförfrågan till bemanningsföretaget. Tredje processen innebar att bemanningsföretaget svarade på offertförfrågan med en offert. Fjärde processen beskrev att de inkomna offerterna skulle visas i en gemensam vy för att ge restaurangen möjligheten att jämföra offerterna.
Avgränsningar
Under workshopen fattades det ett beslut om att göra en avgränsning i processen när användarna bestämde sig för att tacka ja eller nej till en offert. Det på grund utav att Cheffle inte hade ett svar på hur den processen skulle gå till eller hur de påföljande kraven såg ut, oberoende svaret.
Författarna skulle behövt skapa en process för de två scenarierna, och dessutom behövt ytterligare tidsresursen på att bland annat kontrollera eventuella lagstiftningar om hur avtal får hanteras.
19
20 KAPITEL 4. ARBETET
Figur 4.1: Processmodell av offertsystemet.
Dessutom hade Författarna behövt besluta om när Cheffle slutar vara en del av kontakten mellan restaurangen och bemanningsföretaget, vilket kunde påverka affärsmodellen. Författarna ansåg att det var bättre om Cheffle kom med en genomtänkt lösning.
En annan betydande begränsning som gjordes var att endast tillåta restauranger att skapa an- sökningar för en enskild person, istället för att göra be om ett arbetslag. Eftersom att restauranger ofta använder bemanning vid större event och under vissa säsonger, skulle det vara av stort intresse att kunna ansöka och ge offert på en grupp istället för en enskild arbetstitel. Hur detta skulle ske ansågs dock vara för komplicerat och lämnades därmed utanför uppgiftens ramar.
Krav enligt processmodell
Kraven som togs fram under workshopen var följande:
1. Som restaurang kan jag fylla i villkor i ett formulär (offertförfrågan).
2. Det ifyllda formuläret ska skickas till utvalda bemanningsföretag.
3. Som bemanningsföretag kan jag svara på en offertförfrågan som skickas till offertsystemet.
4. Offertsystemet visar upp alla offerter för att kunna jämföra dem.
I denna uppsats kommer krav 3 och krav 4 att beskrivas mer ingående, eftersom att uppsatsens omfång inte kan inkludera alla krav i detalj. Krav 1 och krav 2 implementerades, men anses inte av Författarna vara lika intressanta att ta upp i uppsatsen. Implementationen av krav 1 och krav 2 hade samma tillvägagångssätt som krav 3 och krav 4.
För att undvika missförstånd mellan utvecklarna (Författarna) skapade varje författare en pappers- prototyp av offertsystemet utifrån kraven, som sedan sammanslogs till en pappersprototyp. Skälet till varför inte enbart en pappersprototyp skapades, istället för två, var för att tydligare se två olika tolkningar av kraven. Därefter användes en sammanslagning av de två pappersprototyperna, för att endast inkludera de funktionaliteter som Författarna ansåg var mest användarvänliga. Totalt bestämdes det fyra vyer.
• Överblick
En vy för restaurangen att lista alla inkomna offerter och skickade offertförfrågningar.
• Ansökan
För restaurangen att fylla i en offertförfrågan.
• Offert
En vy för att restaurangen skulle kunna jämföra de inkomna offerterna.
4.1. KRAVFRAMSTÄLLNING OCH VERKSAMHETSMODELLERING 21
• Offertjämförelse
En vy för bemanningsföretaget att svara på en offertförfrågan.
Krav 3 kom att beröras av vyn Offert och krav 4 kom att beröras av vyn Offertjämförelse.
Eftersom att det fanns tre olika intressenter behövdes krav från de övriga intressenterna samlas in för att få en korrekt kravbild. Det gällde för både krav 3 och 4.
4.1.2 Krav 3: Svara på en offertförfrågan
För att information om vad ett bemanningsföretag vill lämna ut i en offert genomfördes två inter- vjuer med olika bemanningsföretag. Även två olika restauranger intervjuades. Skälet till att inte enbart bemanningsföretag intervjuades var för att det är restaurangerna som ska kunna fatta ett beslut baserat på den information som ett bemanningsföretag skickar i en offert.
Intervju med bemanningsföretag
I intervjuerna med bemanningsföretagen låg fokus på tre saker: att ta reda på hur den dåvarande processen för leverans av bemanning gick till, från att en offertförfrågan kommer in till att kunden betalt för bemanningen, att undersöka vad för information som bemanningsföretaget kan och är villigt till att ge ut, och hur bemanningsföretaget skulle vilja svara på en offertförfrågan. Gemen- samt för båda intervjuerna var att de genomfördes på ett semi-strukturerat sätt för att undvika ledande frågor. Intervjuerna varade i en timme och genomfördes under lugna förhållanden.
Båda bemanningsföretagen som blev intervjuade var överens om att svaret på offertförfrågan kun- de skrivas i ett formulär som presenterades via en länk som skickats till dem via e-post. Däremot hade bemanningsföretagen två olika processflöden för att distribuera bemanning. Det ena flödet var att offerten skickades direkt efter att bemanningsföretaget kontrollerat med sin personal att det fanns personal som kunde ta det uppdraget. Därefter skickade kunden en bekräftelse och sedan var förhandlingen klar och bemanningspersonalen fick utföra uppdraget hos kunden. Det and- ra flödet var att offerten skickades till kunden när bemanningsföretaget enbart hade kontrollerat att deras personalregister hade den kompetens som krävdes. När offerten vart godkänd kom steget där bemanningsföretaget kontaktade sin personal för att kontrollera att någon kunde ta uppdraget.
Med svaren från bemanningsföretagen fattades beslutet om att en url-länk skulle skickas med i den e-post som skickas med information om en offertförfrågan till bemanningsföretagen. Url-länken skulle länka till vyn Offert och behövde vara unik för varje par av bemanningsföretag och offert- förfrågan. Det fanns en risk med att använda en url-länk och det var att om det enbart krävdes en länk för att nå vyn var risken att det gick att gissa sig till någon annans länk. Det skulle kunna ha inneburit att en annan person än det specifika bemanningsföretaget skulle ha kunnat fylla i en offert i bemanningsföretagets namn. Tre olika förslag på lösningar diskuterades med Cheffle för att få reda på vad för krav på säkerhet som ställs på systemet från uppdragsgivarnas synvinkel.
Diskussionen återfinns i avsnitt7.2.5eftersom att Författarna ansåg att säkerheten borde ha pri- oriterats högre för att hålla en god miniminivå på säkerheten. Det som framkom var att kravet för att skapa en MVP var betydligt mer prioriterat än att ha en säker url-länk. Därefter fattades beslutet om att använda en lösning med en dynamisk url-länk, för att få en fungerande länk utan att behöva ändra i databasen.
Offertformulärets utseende
För att besluta om hur svarsformuläret skulle se ut för att skapa en offert användes återkopplingen från både intervjuerna med bemanningsföretagen och restaurangerna. Under intervjuerna ställdes frågorna vad för information som restauranger ville ha i en offert och hur skulle bemanningsföre- tagen kunna tänka sig att svarsformuläret skulle se ut. Utöver frågorna visades pappersprototypen upp för respektive intressent som därmed fick chansen att ge återkoppling. Ena intervjun med en av restaurangerna hölls i en timme och trettio minuter där det var intervjuobjektet själv som bjöd in till att genomföra intervjun under det tidsspannet. Den andra intervjun med en av restau- rangerna hölls enligt intervjuobjektets önskemål på enbart tjugo minuter. Trots den korta tiden hann frågorna ställas och pappersprototypen att visas upp, samt att betänketid gavs för att ge svar.
22 KAPITEL 4. ARBETET
Bemanningsföretagen sa att de ville enkelt kunna klicka i ifall bemanningspersonalen uppfyller de behov som en restaurang har angivit i offertansökan. Det skulle finnas information om be- manningsföretaget förifyllt, till exempel information om att bemanningsföretaget använde kollek- tivavtal. Restaurangerna var överens om att de ville ha information om bemanningens sociala kompetens. Det ansågs vara viktigt eftersom att restaurangerna vill kunna strategiskt placera ut sociala personer vid till exempel i baren där det är mycket kundkontakt istället för i köket som saknar kontakt med kunder. Den ena restaurangen lyfte fram en önskan om att få bemannings- personalens namn i informationen. Skälet var för att om restaurangen var nöjd med en tidigare kandidat skulle det vara enkelt att känna igen den kandidaten bland de inkomna offerterna.
Med återkopplingen från intervjuerna beslutades det att offertförfrågan inte enbart skulle pre- senteras i den e-post som skickades ut till bemanningsföretagen. Den skulle även synas i vyn som url-länken var kopplad till. Till exempel skulle behoven som en restaurang fyllde i presenteras på separat rad och ha en klickbar ruta som bemanningsföretaget kunde använda för att checka av att det behovet fanns uppfyllt hos bemanningspersonalens kompetens. Däremot fattades ett beslut om att inte begära bemanningspersonalens namn i offerten. Det på grund av att hur bemanningspro- cessen fungerar hos olika bemanningsföretag, se tidigare i detta kapitel.
4.1.3 Krav 4: Visa upp offerter för jämförelse
Till kravet angående att inkomna offerter skulle visas upp för att sedan kunna jämföras för att restaurangen skulle kunna fatta ett beslut användes två intervjuer med två olika restauranger för att framställa krav. Bemanningsföretagen tillfrågades inte på grund av att de är inte den användare som fick tillgång till vyn Offertjämförelse.
Båda restaurangerna sa att priset inte var det som skulle avgöra ett beslut mellan vilken offert som tackas ja till, utan det skulle vara bemanningspersonalens erfarenhet som vägde in tyngst i beslutet.
Återkopplingen på pappersprototypen var positiv och det som lyftes fram var uppskattningen av att få en tydlig överblick över de inkomna offerterna och vad som hade skrivits i offertansökan.
4.1.4 Klassmodell
Med kraven och återkopplingen skapades en andra konceptuell modell. Denna var en klassmodell som visade den data som behövdes för att genomföra processerna beskrivna i processmodellen. Vad en klassmodell är finns återbeskriven i avsnitt2.5.2. Klassmodellen som skapades finns beskriven i figur4.2.
Krav 3 påverkade alla relationer till klassen Offert. Första relationen var att klassen Offert skulle ha förhållandet många till en med klassen Offertförfrågan. Skälet var att en offertförfrågan kunde få flera offerter eller inga alls medan en offert kunde bara gälla för en offertförfrågan. Andra var att klassen Offert skulle ha förhållandet många till en med klassen Bemanningsföretag, för att en offert kan endast skapas av ett bemanningsföretag medan ett bemanningsföretag kan skapa flera offerter. Tredje var att klassen Offert hade ett många till många förhållande med Specialbehov.
Eftersom att ett specialbehov som en restaurang har skapat i offertförfrågan kunde anses som upp- fyllt av en offert eller inte alls, samt att en offert kunde ha uppfyllt flera specialbehov eller inga alls.
Krav 4 hade ingen påverkan på hur klassmodellen designades, eftersom det kravet enbart handlade om att visa data istället för att generera data.
4.2 Modellering och design av databas
Utifrån klassmodellen skapades en logisk databasmodell. Stor vikt lades på att skapa en databas- modell som skulle kunna användas i det system som skulle sätts i drift. Därav granskades den logiska databasmodellen av en universitetsadjunkt vid KTH [29] för att säkerställa kvalitén.
Under utvecklingen av applikationen hände det att enstaka tabeller i databasen behövdes änd- ras. Det på grund utav att återkopplingen från intervjuobjekten kunde påverka utformningen av attributen i de olika tabellerna.
4.3. UTVECKLING AV MVP VERSION AV APPLIKATIONEN 23
Figur 4.2: Klassmodell av offertsystemet.
4.3 Utveckling av MVP version av applikationen
Det eftersträvades att prototypen skulle vara en MVP när applikationen utvecklades. Det ledde till att enbart bakomliggande funktionaliteter implementerades och det grafiska användargränssnittet ej var prioriterat. Det var något som Cheffle hade gjort tydligt som krav under workshopen som hölls i början av arbetet.
För att följa XPs mall skapades user stories från processmodellen och den logiska databasmo- dellen. Alla user stories placerades i en backlog och blev tilldelade en kategori baserat på vilken av de fyra vyerna som de tillhörde. Alla user stories följde formatet som en grupp från Connextra i London [30] tog fram:
Som en <roll>, vill jag <mål/önskan> för att <fördel>
Iterationerna i arbetsprocessen startade här. Varje iteration baserades på olika user stories och en iteration ansågs vara klar när de user stories som tillhörde iterationen klarat enhetstesterna. Alla user stories beskrivs inte i uppsatsen, utan enbart en sammanfattning av de om tillhörde krav 3 och 4. Eftersom att kunskapen ökades i takt med arbetes gång kan omfattningen (antalet user stories) av en iteration ha ökat. Författarna var två stycken under arbetes gång, och arbetade med olika delar av applikationen. Det gjorde att två iterationer arbetades med parallellt.
Krav 3 omfattades av totalt tre user stories.
1. Som ett bemanningsföretag vill jag klicka på en länk i mottaget e-post med information och få fram en vy för att kunna skapa en offert.
2. Som ett bemanningsföretag vill jag kunna se information om den offertförfrågan som jag ska svara på för att veta vad jag svarar på.
3. Som bemanningsföretag vill jag fylla i ett formulär för att svara på kundens offertförfrågan där jag kan förklarar om jag uppfyller behoven och anger pris.
Den beslutsfattande processen för user story ett beskrevs i avsnitt4.1.2. Där togs det upp om att url-länken som kom att användas i de utskickade e-posten skulle implementeras som en dynamisk
24 KAPITEL 4. ARBETET
url-länk.
Krav 4 inkluderade tre olika user stories.
1. Som en användare som tillhör en restaurang vill jag klicka på kommande/pågående/avslutade offertförfrågningar för att se vad de innehåller för offerter.
2. Som en restauranganvändare vill jag se de olika offerterna i en tabell.
3. Som en användare som tillhör en restaurang vill jag gå tillbaka till vyn Överblick från vyn Offertjämförelse.
User story nummer två för krav 4 innebar att i vyn Offertjämförelse skulle alla inkomna offerter för den specifika offertförfrågan presenteras. Arbetet gick ut på att skapa förfrågningar till data- basen som hämtade data om vilka offerter som var inkomna, vilken offertförfrågan det gällde och vad arbetstiteln innebar. Det presenterades visuellt i vyn Offertjämförelse som var unik för varje offertförfrågan.
Gemensamt för alla user stories var att de genomgick ett enhetstest och ett integrationstest.
Enstaka user stories har behövt genomgå regressionstestning för att kontrollera att uppdaterad kod fortfarande uppfyllde tidigare enhetstester och integrationstester.
Kapitel 5
Resultat
Nedan följer resultaten av det skapade offertsystemet. Som nämnt i kapitel4bestod applikationen av fyra vyer: Överblick, Ansökan, Offert och Offertjämförelse. Dock går resultatet bara igenom de två krav som Författarna valt att beskriva på djupet i uppsatsen. Nämligen krav 3 och 4, se delkapitel4.1. Kapitlet ger en bild över hur applikationen såg ut och hur den uppfyllde de olika kraven.
5.1 Sammanfattning
Resultatet var en prototyp skriven i programmeringsspråket Python tillsammans med ramverket Flask. I prototypen går det för restauranganvändare att logga in med användarnamn och lösenord som finns i databasen. I databasen fanns lagrat för restaurangen ett id, dess namn, telefonnum- mer och adress. Databassystemet som användes var relationsdatabasen MySQL. För att skapa en ansökan fanns en knapp uppe i menyn som skickade användaren till ett formulär. Där fanns en rullgardin för att välja arbetstitel, samt fält för att fylla i start- och slutdatum och start- och sluttid för arbetet. De kunde även fylla i tre önskemål de hade på bemanningen och en beskrivning av arbetet och arbetsplatsen. Som förslag gavs om restaurangen bistod med mat eller arbetsklä- der, om det var ett event eller om arbetstillfället hade andra speciella omständigheter. Längst till höger fanns en checklåda för varje bemanningsföretag som Författarna själva lagt in i databa- sen där användarna kunde välja vilka de ville skicka offertförfrågan till. Offertförfrågan avslutades genom att klicka på en knapp med texten ”Skicka”. Detta uppfyllde krav 1 och 2 som beskrevs i4.1.
Live, eller Hotmail som det också kallades, användes som mejlserver för att skicka e-post. E-post användes för att kommunicera offertförfrågan till utvalda bemanningsföretag. Hur de fyllde i en offert beskrivs i delkapitel5.2. Offerten lagrades i databasen och kunde visas upp för restaurangen enligt figur5.3.
Prototypen existerade lokalt på utvecklarnas datorer. Förvaltningen av offertsystemet ansvara- de Cheffle för, efter att ha fått dokumentationen av systemet överlämnad. Dokumentationen fanns lagrad i versionshanteringssystemet GitHub.
Grundkraven som beskrevs i delkapitel1.2uppfylldes. Enligt grundkrav 1 uppfylldes det att pro- totypen var en separat modul. Prototypen var inte inbyggd i Cheffles existerande system. För att uppfylla grundkrav 2 skulle all funktionalitet fungera, vilket redovisas genomgående i denna sam- manfattning. Grundkrav 3 och 4 var funktionalitet som fanns i prototypen och speciellt berördes av de krav som beskrivits i detalj i uppsatsen. De var krav 3, svara på en offertförfrågan, och krav 4, visa upp offerter för jämförelse. Det sista grundkravet var att prototypen var en MVP.
Eftersom att all funktionalitet fungerade kunde prototypen visas upp för tidiga användarna för att få återkoppling.
25
26 KAPITEL 5. RESULTAT
Figur 5.1: Skapa en offert
Figur 5.2: Offertjämförelse
