Enligt en artikel av Raturi et al. [34] bör man ta hänsyn till hållbar utveckling redan när man skriver kravspecifikationen. Det ska då tas hänsyn till miljö, hälsa, sociala, ekonomiska och tekniska aspekter när kraven formuleras samt ställas krav på dessa aspekter i kravspecifika- tionen.
När kravspecifikationen skrevs för Complyzer togs inte hänsyn till hållbar utveckling. Det hade kunnat göras genom att titta på hur systemet fördelas mellan klient och server. Gruppen skulle kunnat kravsatt att större delen av produkten skulle ligga på en server som drivs av förnybar energi.
Servern som används är tillhandahållen av Amazon och enligt deras hemsida för webbtjän- ster (aws.amazon.com) finns möjligheten att använda deras servrar som klimatkompenserar. Dessa servrar finns i vad Amazon kallar koldioxidneutrala zoner (eng: carbon neutral zones). Att använda sig av servrar i dessa zoner för projektet är något som skulle kunna bidra till hållbar utveckling. [35]
6.6. Arbetet i ett vidare sammanhang
Produkten finns, som det nämndes tidigare, på en server och data uppdateras en gång om dagen. Detta är både mer tidseffektivt, bättre för miljön och billigare för kunden än om data skulle hämtas mer frekvent. Detta gäller med förutsättningen att själva hanteringen av den lagrade datan inte använder mer resurser än vad det hade gjort att hämta data direkt. Att hämta data en gång om dagen var ett krav på produkten. Detta krav spelar in på hållbar utveckling då det är mer miljövänligt att hämta mer sällan, eftersom mindre resurser behöver dedikeras till att hämta data. För att veta exakt hur stor miljöpåverkan de valda metoderna skulle ha i förhållande till de alternativa metoderna skulle mätningar behöva utföras. Eftersom produkten gör det enklare och snabbare att sammanställa konkurrentanalyser kan den gynna marknadseknomin. Mer konkurrenskraftiga företag sänker priserna på produkterna och tjänsterna vilket i sin tur skapar en bättre marknad för konsumenter. Pro- dukten bidrar med ekonomisk stabilitet till samhället eftersom företag kan fortsätta existera och gynna ekonomin.
7
Slutsatser
I följande kapitel besvaras de frågeställningar som togs fram i kapitel 1.3.
7.1
Värde för kund
Produkten Complyzer har implementerats modulärt för att enklare kunna vidareutvecklas samt för att enklare kunna integreras i det befintliga systemet Boardeaser [1]. Koden har granskats och testats för att hitta och eliminera buggar i systemet. Kunden har även fått med enhetstesterna till produkten, på dennes begäran, då dessa kan vara användbara för att skapa förståelse för funktionerna som testats.
Kunden ville att produkten skulle kunna få ut så mycket data som möjligt om företag från affärssystemet Bisnode [18] samt presentera denna datan grafiskt. Gruppen fokuserade därför på att hämta datan från Bisnode samt strukturera upp datan så att den går att ladda upp i kundens befintliga system.
En systemanatomi har tagits fram samt en systemskiss/arkitekturdokument för att kun- den enklare ska kunna sätta sig in i systemet. En användarmanual har skrivits för produkten, som även innehåller kort om hur kunden kommer igång med Flask [14]. All kod har doku- menterats väl för att göra det enkelt för kunden att sätta sig in i koden så att denne kan vidareutveckla produkten.
Eftersom produkten ska användas för kommersiellt bruk har gruppen inte använt några bibliotek som är öppen källkod.
Sammanfattningsvis har värde för kunden skapats genom att följa kundens riktlinjer, samt gjort produkten modulär och levererat kod och dokumentation som förenklar vidareutveck- ling och integration av projektet.
7.2
Gemensamma erfarenheter
Projektet Complyzer gav många viktiga erfarenheter till projektgruppen, både positiva och negativa erfarenheter, som presenteras nedan.
7.3. Systemanatomi
Positiva erfarenheter
Gruppen har haft en öppen kommunikation mellan gruppens medlemmar vilket har bidragit till att eventuella problem har identifierats och lösts tidigt. Detta har sparat tid då inga nya problem uppstått i samband med de första problemen.
För att gruppen skulle utvecklas utvärderades varje sprint. Genom dessa utvärderingar kunde problem inom gruppen tas upp och diskuteras för att sedan lösas. Ju tidigare og- ynnsamma beteenden eller arbetssätt behandlades desto mindre skada gjorde dem. Gruppen utvärderade sprintarna under deras sprintåterblickar.
Genom att gruppen var öppen för förslag för byte av verktyg som inte fungerade till- räckligt bra kunde mycket tid sparas. Gruppen bytte verktygen både för sin kanban-tavla samt sitt tidsrapporteringssystem.
Negativa erfarenheter
En av de viktigaste erfarenheterna från projektet var hur lätt det var för missförstånd att uppstå. Speciellt vid kommunikation via e-post, då den visuella aspekten saknas, var det extra viktigt att vara tydlig.
Gruppen fick erfara att det var väldigt svårt att tidsuppskatta uppgifter i början av projektet. För att förenkla detta infördes beprövade metoder som planeringspoker, vilket medförde att tiden det tog att tidsuppskatta uppgifter sänktes och precisionen på tidsuppskattningen ökades.
7.3
Systemanatomi
Att använda en systemanatomi i ett småskaligt agilt mjukvaruprojekt har flera för- och nackdelar man bör betänka innan den används. En fördel är att det är lätt att få en överblick över vad systemet ska ha för funktionaliteter och hur de relaterar till varandra. En annan är att det är en relativt stabil systembeskrivning i jämförelse med exempelvis en designspeci- fikation, då den mer utgår från vad systemet ska klara av istället för hur det ska utföras. Systemanatomin kan också bidra till att öka den gemensamma förståelsen över vad systemet ska uträtta, då den dels kan tas fram gemensamt, och dels kan tas fram i ett tidigt skede. Dessutom kan den senare användas för att underlätta konstruktionen av en designskiss. Det som försvårar användningen av systemanatomin är att den är inte lika vedertagen som till exempel designskissar i form av UML-diagram. Det gör att verifikation med kunden kan försvåras om det är svårt att få till ett fysiskt möte.
7.4
Integration av moduler
Genom att arbeta med parprogrammering, sprida kunskaper och ha en tydlig bild över sys- temet har projektgruppen kunnat utveckla moduler separat. Eftersom gruppen har arbetat på samma plats har alla medlemmar snabbt blivit informerade om skissen över modulerna ändrades så att alla kunde arbeta mot samma bild. Om det inte funnits en tydlig skiss över modulerna hade förmodligen inte integrationen av de olika modulerna fungerat lika smidigt som den gjort.
Något som upplevdes som ett mindre problem var att det stundvis var ostrukturerat i versionhanteringen och detta bidrog med mindre problem vid integrering. För att verkligen se hur arbetsmetoden och verktygen som användes underlättade eller försvårade integration
7.5. Anpassning av Scrum
så hade projektet förmodligen behövt utföras under en längre period.
Från projektet och arbetet med integration kan lärdomen tas att god kommunikation, ord- ning och reda på kod, och väl definierade riktlinjer för utveckling och versionhantering gör det enklare att integrera separat utvecklade moduler.
7.5
Anpassning av Scrum
Att använda sig av en arbetsmetodik har upplevts som något bra av projektkmedlemmarna under projektet. Om det faktiskt är Scrum som är bäst för den här typen av projekt eller om det är något annat är dock oklart. För att ta reda på en sådan sak så skulle någon annan arbetsmetodik behöva anpassas på ett liknande projekt.
För just projektet med systemet Complyzer har en modifierad version av Scrum fungerat bra, specifikt inkluderingen av parprogrammering. Parprogrammering har gjort att kunskapen kring olika områden i projektet fördelas mellan två personer. Kunskapsspridningen och kommunikationen upplevdes som positiv bland annat på grund av att det oftast fanns någon på plats, eller någon tillgänglig, som hade koll på ett specifikt område i systemet.
Strukturen som den modifierade versionen av Scrum har skapat i projektet är den största nyttan som dragits från den projekstyrningsmetodiken. Inkluderingen av kanban-tavla via Trello, med tidsrapportering inkluderat, har underlättat projektet mycket. Detta eftersom all information gällande arbetsuppgifter, hur lång tid de bör ta och hur mycket tid de tog, var samlad på ett och samma ställe.
Att aktivt arbeta med att underlätta administrativa uppgifter, spridning av information, och kommunikation är något som fungerade väldigt bra för projektgruppen. Detta möjlig- gjordes till stor del på grund av Scrum och särskilt inkluderingen av parprogrammering samt nyttjandet av en kanban-tavla med tillhörande tidsrapportering.