Scrum + XP samt konsekvensanalys

Daniel Nimren dt05dn8Douglas Frisk dt05df1

Dept. of Computer Science,Lunds Tekniska Högskola, Sweden{dt05dn8 dt05df1}@student.lth.se

1 mars 2010

Sammanfattning

Denna rapport handlar om hur SCRUM kan integreras i XP med alla dess prin-ciper. Detta sker under kursen ”Programvaruutveckling i grupp” samt ”Coachingför programvaruteam” där målet är att arbeta fram en produkt som ska kun-na användas för tidtagning vid tävlingar i enduro. Konsekvensanalys kommertill viss del vara en del av empirin under kursens gång. Kursen innebär sexlånglabbar, sex veckomöten samt spiketid på fyra timmar varje vecka.

Innehåll

1 Studie 2

1.1 Terminologi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Introduktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 SCRUM 4

2.1 Vad är SCRUM? . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Djupgående terminologi . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.2 Produkt backlog . . . . . . . . . . . . . . . . . . . . . . . 52.2.3 Sprint planering . . . . . . . . . . . . . . . . . . . . . . . 62.2.4 Burn down chart . . . . . . . . . . . . . . . . . . . . . . . 62.2.5 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . 72.2.6 Taskboard . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.7 Daglig SCRUM . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Konsekvensanalys 9

3.1 Vad innebär konsekvensanalys? . . . . . . . . . . . . . . . . . . . 93.2 Olika typer av konsekvensanalyser . . . . . . . . . . . . . . . . . 9

4 SCRUM + XP 10

4.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.2 Empiri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.3 Slutsats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5 Konsekvensanalys i agila projekt 12

5.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125.2 Empiri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125.3 Slutsats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6 Sammanfattning 14

Kapitel 1

Studie

1.1 Terminologi

Iteration En återkommande process, i detta fallet en tidsperiod under vilkenen långlabb, ett veckomöte och fyra timmars individuell spiketid ingår.

Spike En lösning på något problem som man sedan kan använda sig utav iutvecklingen. I detta fall individuellt arbete som görs utanför schemalagdtid.

SCRUM Ett arbetssätt inom agil utveckling, skrivs ofta med stora bokstäverberoende på att Ken Schwaber gjorde det i en av sina tidiga artiklar [1].

eXtreme Programming Ett arbetssätt inom agil utveckling [7]. Härmed käntsom XP.

EDA260 Kursen ”Programvaruutveckling i grupp” på LTH.

EDA270 Kursen ”Coaching för programvauteam” på LTH.

Konsekvensanalys Direktöversättning från termen ”impact analysis” [5].

Story Beskrivning på ett krav ställt av kunden, används som term inom bl.a.XP.

Artefakt (Inom konfigurationshantering) En del i ett projekt, kan vara enklass, ett dokument, en kompilator o.s.v..

Trac En wiki som har integrerad SVN, används i projektet.

2

1.2 Introduktion

Våran djupstudie är baserad på kursen EDA260, i vilken en grupp med i vårtfall åtta studenter ska samarbeta under sex heldagar som var och en utgör eniteration i projektet. Kursen är obligatorisk för de som vill ta ut en examen somcivilingenjör inom data. Det kan medföra en lägre motivation än det kanske hadevarit på en valfri kurs eftersom alla inte har intresse för innehållet, dessutomslumpas teamen ihop så att en bra gemensamhet inom gruppen är inte självklar.Målet för projektet är att utveckla ett tidtagningssystem för motorcykelsportenEnduro. Detta med fokus på samtliga principer som XP medför, utöver dettahar vi valt att skriva våran djupstudie om SCRUM och hur man kan integreradet i XP [3], utöver det har vi delar av SCRUM som fokus i projektgruppen.Kursen innefattar en långlabb, ett veckomöte och fyra timmars spiketid i veckan.Långlabben är ett moment då teamet samlas i en datorsal under en heldag föratt utveckla produkten och brukar inledas med ett möte för att gå igenomdagens schema. Under veckomötet görs estimeringar och planeringar av de kravsom kunden har kommit med sedan den senaste iterationen. På den individuellaspiketiden ska utvecklarna arbeta hemma med något som kan gagna hela teametoch sedan presentera det på morgonmötet under nästa långlabb.

Vi har även valt att ha konsekvensanalys [5] som ett fokus i projektet föratt se om det är möjligt och givande i ett projekt med denna storleken ochomfattningen. Det innebär att vårt team ska gradvis mer ingående analyseraoch spåra beroende mellan klasser och metoder i det pågående projektet föratt på så sätt kunna estimera tidsåtgången för en story baserat på mer änbara just den storyns innehåll. Med gradvis syftar vi på att nivån på kraven aveftertänksamhet vid analysen blir större för varje iteration. Tanken med dettaär att utvecklarna (som antas aldrig ha gjort en konsekvensanalys förr) inteska behöva ta ett för stort steg direkt utan känna sig fram och märka tydligaskillnader under kursens gång.

Med denna studien avser vi att undersöka om SCRUM går att kombineramed ett XP-projekt och framförallt i ett projekt inom kursen EDA260. Våranavsikt är att underlätta processen (eftersom det är just den som SCRUM inriktarsig på) under utveckling. Vi vill också undersöka om konsekvensanalys är vettigtatt använda sig utav i agil utveckling eller om det medför en för stor belastning.

I den här artikeln kommer vi beskriva SCRUM i kapitel 2 samt hur det kanintegreras i XP i kapitel 4 samt beskriva konsekvensanalys i kapitel 3 och dessanvändande i agila projekt i kapitel 5. En sammanfattning finns i kapitel 6.Referenser är presenterade i slutet på artikeln, vissa av referenserna är andra-handsreferenser som har gett bakgrund men inte har blivit använda direkt irapporten (och därav aldrig nämnda).

3

Kapitel 2

SCRUM

2.1 Vad är SCRUM?

SCRUM är ett sätt att arbeta på, det är inte en metod utan snarare ett ramverk[1]. Vilket betyder att inget är satt i sten. Det är upp till varje team hur de villimplementera de delar som det talas om i SCRUM på det sätt som passar dembäst i just deras situation. Situationen i fråga kan mycket väl förändras ochlikaså kommer principerna man talar om i SCRUM förandras med den.

I stora drag är SCRUM en agil infallsvinkel på mjukvaruutveckling och harmycket gemensamt med andra metodiker som t.ex. XP. Men med den storaskillnaden att man inte lägger någon tyngd vid utvecklingsmetodik så som par-programmering, enkel design o.s.v., utan koncentrerar sig enbart på processen,d.v.s. planering, upplägg o.s.v. [8].

Ett SCRUM-team ska vara självorganiserat i den mån att det inte finnsnågon direkt teamledare som styr. Alla medlemmar i teamet är med och targemensamma beslut angående vad som ska göras och hur det ska göras. Samtalla som behöver blandas in blir inblandade när ett beslut ska genomföras. Trotsdetta finns det roller i ett SCRUM-team [3], särskilt dessa:

ScrumMaster Någon som agerar coach till teamet för att få dem att arbetaså smidigt som möjligt och på sin högsta nivå.

Product owner En representant från rörelsen, kunderna och användarna somser till att kraven följs och att det är rätt produkt som blir utvecklad.

Utvecklare Programmerare, designers och folk med specialkunskaper.

I SCRUM arbetar man i sprints, varje sprint börjar med att teamet levererar ettlöfte om vad som ska vara klart efteråt. Efter varje sprint levereras de utlovadedelarna, kodade, testade och integrerade i systemet som utvecklas.

2.2 Djupgående terminologi

SCRUM liksom många andra metodologier och ramverk för att arbeta innehålleren hel del termer med en specifik innebörd, då SCRUM som tidigare nämntsbara är ett ramverk för utveckling i team så är inga av dessa termer exakta,utan snarare författarnas egna tolkningar.

4

Produkt backlog Sprint backlog Aktuell release

Sprint

Daglig sprint

1-4 veckor

Figur 2.1: SCRUM process

2.2.1 Sprint

En sprint i SCRUM är en tidsperiod som brukar vara mellan en vecka och enmånad. Undersökningar har visat att det är vanligast med två veckor. Underdenna tiden är målet för teamet att klara av ett visst antal uppgifter som mankommer fram till i början av sprinten.

2.2.2 Produkt backlog

En produkt backlog är en enkelt beskriven lista på vad kunden vill ha, medkundens terminologi. Det är med en sådan alla SCRUM projekt börjar. Den skainnehålla alla krav, stories, funktioner etc. Varje krav, story eller funktion börvara beskriven med ett antal fält [3]:

ID Ett vanligt automatiskt inkrementerat nummer som kan identifiera varjestory.

Namn Ett kort och beskrivande namn som lätt skiljer storyn från andra stories.

Prioritet Ett nummer talar om hur viktig storyn är relativt alla andra stories.Kan bestämmas i vilket spann som helst bara man håller sig inom detunder hela projektet.

Inledande estimering Ett mått på hur lång tid man uppskattar att storynkommer ta att implementera relativt alla andra stories. Även här ett num-mer i vilket spann som helt så länge man är konsekvent.

Demonstration En kort beskrivning på hur man kan demonstrera storyn närden är klar, D.v.s. hur den är tänkt att fungera.

Anteckningar Annan information som inte passar i något av de andra fälten.

Ibland uppkommer det beroende som kunden inte uttryckligen har ett kravpå men som krävs för att implementera andra krav, dess kallas för tekniskastories. Vanligt är att dessa läggs till i listan på kundens krav för att underlättalogistiken i projektet.

Men som sagt så är SCRUM endast ett ramverk och det är fullt möjligt attlägga till fler fält vid behov samt ta bort fält som känns överflödiga.

5

2.2.3 Sprint planering

Inför varje sprint behövs det en bra och utförlig plan på vad som ska göras klartunder sprinten [3]. ScrumMastern håller då ett möte för att klargöra kundensförväntningar och krav, samt komma fram till hur många man-timmar man haratt jobba med, för att man ska veta hur många stories man räknar med att klaraav. Det är under planeringsmötet som estimeringen av stories sker. Det finnsmånga olika sätt att estimera och alla är förmodligen lika bra i den situationsom den är anpassad för. Vilken man väljer är upp till ScrumMastern och oftaså experimenteras det för att komma fram till vilken det är. Kunden bör ocksånärvara för att prioritera vilka stories som bör göras först och beroende på hurde estimerades även förändra prioriteringen om det behövs.

Huvudmålet är att utvecklarna ska kunna jobba ostört under hela sprintenoch på så vis uppnå maximal produktivitet. Det är därför viktigt att utveck-larna tänker igenom varje story tillräckligt för att komma på eventuella frågorredan då och på så vis spara den tid det tar att kontakta kunden senare underutvecklingen, även kundens tid är ju dyr.

Under mötet bestäms även hur lång nästa sprint ska vara. Generellt sätt ären kortare sprint att föredra, dock inte så kort att ingenting hinns med för attman inte får upp farten.

Kort sprint = kort feedback cykel = frekventare leveranser =frekventare kundfeedback = mindre tid spenderad i fel riktning =snabbare inlärning

Normalt är att ha lika långa sprinter under hela projektet men ibland tar deten sprint eller två innan man har bestämt sig för vilken längd som passar bäst ijust det projektet. Men liksom tidigare är det fritt fram att ändar uppfattningunder projektets gång.

Att ha ett kollektivt mål under en sprint gör så att hela gruppen arbetarmer tillsammans för att nå det. Ett mål är inte alltid så lätt att formulera ochvid brist på ett är det bättre med ett halvdant mål än inget alls, det kan t.o.m.vara ”imponera på företagsledningen”.

2.2.4 Burn down chart

Ett burn down chart är en graf som utrycker t.ex. en iterations progress i antalestimerade poäng mot tiden [3]. I figur 2.2 visas ett exempel på ett burn downchart, på den horisontella axeln har vi enheten tid och på den vertikala axelnantal återstående estimerade poäng. Målet är att man ska veta om man liggerbra till i tiden genom att använda sig utav den raka linjen som går genomgrafen. Efter iteration fyra kan man se att avståndet mellan följelinjen och denverkliga linjen blir allt för stor, det vill säga, det var för mycket att göra. Dettaåtgärdades av att ScrumMastern tillsammans med kunden valde bort storiessom var lågprioriterade och på så vis ledde linjen tillbaks där man ville se den.Likaså hade en omvänd situation krävt att nya stories skulle tillkomma.

Det finns även alternativet att använda sig utav kalkylblad för att på ettenklare sätt kunna producera en graf med automatiskt ritad medianlinje (somanvänds för att se när den riktiga linjen förväntas korsa x-axeln och på så visge ett estimat på hur man ligger till i förhållande till den planerade sluttiden).

6

Tid

Poän

g

Figur 2.2: Exempel på burn down chart

2.2.5 Sprint backlog

En sprint backlog börjar med att se ut precis som en produkt backlog fast in-nehåller endast de stories som teamet planerar att genomföra under kommandesprint. Efter hand har ScrumMastern i uppgift att bocka av de stories som ärklara samt uppdatera estimeringarna efter hand för att på så vis få en klar bildöver hur långt sprinten är gången. Dessa uppgifter överförs till en burn downchart. [3]

2.2.6 Taskboard

Under projektets gång brukar man använda sig av en tavla eller whiteboard föratt illustrera vilka stories som finns att göra osv. Denna brukar kallas för task-board [3], se figur 2.3 för ett exempel på hur det kan var strukturerat. Exempletär uppdelat i fälten: icke påbörjade stories, påbörjade stories, klara stories, opla-nerade stories (tekniska stories), burn down chart, nya stories (om de gamla tarslut). Den fungerar på det viset att en utvecklare plockar ett storykort från deicke påbörjade och flyttar det till påbörjat när han ska implementera den. Närhan är klar flyttar han den till klara stories och fyller i burn down charten såatt den blir uppdaterad.

2.2.7 Daglig SCRUM

Det dagliga SCRUMet är ett möte som, liksom termen antyder, hålls dagligen.När under dagen det hålls är upp till teamet och framför allt ScrumMastern. Istora drag är det antingen på morgonen innan utvecklarna har dragit igång meddagens arbete eller på eftermiddagen innan dagen tar slut. För- och nackdelarfinns med båda och det är åter igen upp till teamet vad som passar bäst i denrelevanta situationen.

Termen stand up meeting är också vanlig och går helt enkelt ut på att dendagliga SCRUMen utförs stående för att alla ska vara så vakna på som möjligtoch få mötet avklarat så snabbt som möjligt.

Mötet är till för att prata om det som har gjorts sedan senaste mötet samtdiskutera framtida händelser så som implementeringsförslag på stories eller för-slag på förändringar.

7

Icke påbörjadestories

Påbörjadestories

Klarastories

Burn down chart

Nya storiesOplanneradestories

Figur 2.3: Exempel på burn down chart

8

Kapitel 3

Konsekvensanalys

3.1 Vad innebär konsekvensanalys?

Liksom ordet antyder så innebär konsekvensanalys en analys av konsekvenservid förändring av t.ex. klasser eller metoder och ofta dokument som manualero.s.v.. Med komplexiteten som de flesta av dagens projekt bär med sig är detväldigt nyttigt att se till så att man har en väl fungerande konsekvensanalys.Som på ett strukturerat sätt går igenom det som behöver förändras och på såvis ger en mer korrekt estimering av förändringen. Det som man vill uppnå efteren konsekvensanalys är att man vill veta vilken del av koden som måste testasom, vilken del av koden som måste skrivas om och få en bättre tidsestimeringpå det som ska implementeras [9]. På så vis minimeras antal fel i koden samteffektiviteten förbättras.

3.2 Olika typer av konsekvensanalyser

När man pratar om konsekvensanalys för mjukvaruutveckling brukar man delaupp begreppen i två fack, det ena är statisk konsekvensanalys och det andraär dynamisk konsekvensanalys (som båda är en del utav vad som också brukarkallas beroendeanalys). Skillnaden är att man vid statisk konsekvensanalys ana-lyserar källkoden för att på så vis kunna anta olika utfall vid körning av koden,när man istället analyserar utfallen vid en dynamisk konsekvensanalys. Förde-len med statisk konsekvensanalys är att den som analyserar får tänka igenomkällkoden mer ingående och på så vis får en bättre förståelse, dock med nack-delen att det ofta slutar i en all för fingranulär analys. Den dynamiska ansatsenger och andra sidan en mer precis analys men dock med nackdelen att koden isig inte granskas i samband med analysen.

9

Kapitel 4

SCRUM + XP

4.1 Bakgrund

Scrum är ett av de sätten att arbeta i team som blommat ut på senare år,det används flitigt ute i industrin. SCRUM är som tidigare nämnts ett ramverk(snarare än en arbetsmetod) med tyngdpunkt på den administrativa processenoch med målet att maximera avkastning på investering. Med andra ord innebärdet att i SCRUM finns det principer för att hantera utvecklingen medan de prin-ciper som vi använder oss av från XP ska garantera oss en hög standard. KenSchwaber (som tillsammans med Jeff Sutherland formulerade den första versio-nen av SCRUM) och Kane Mar har tidigare gjort ett försök i att sammansvetsaSCRUM med XP i ett mjukvaruprojekt [8]. Vi har som mål att försöka appliceraderas metodik på kursen EDA260.

4.2 Empiri

Eftersom varje sprint inte var längre än en dag kändes det överflödigt att för-söka integrera dagliga sprintar i detta projektet. Det innebär att den dagligaSCRUMen i vårt fall reflekterar en hel iteration/sprint och inte riktigt är så somen daglig SCRUM är tänkt. Utan i stället tog upp delar av det som bör tas uppunder en sprint planering.

För att till så stor del som möjligt imitera en Burn down chart använde videt inbyggda verktyget i Trac (se fig 4.1 för en skärmdump från iteration två)för att lägga in varje story och task, vilken ger oss en procent på hur långt vihar kommit under varje iteration. Vi kan gissa på den återstående tiden meninte få en så klar tid som det är meningen att man ska få.

Våra veckomöten och andra sidan reflekterar i större drag det som i SCRUMkallas för sprint planering eftersom det är då vi estimerar stories och planerarinför nästkommande iteration/sprint.

Under varje iteration/sprint fanns det stories uppsata på väggen under ru-brikerna ”klara”, ”prio 1” och ”prio 2”. För att försöka imitera en taskboard.

10

Figur 4.1: Skärmdump från Tracen över en implementation av burn down chart

4.3 Slutsats

Eftersom det börjas på flera stories sammtidigt så kommer det medföra att,enligt ett Burn down chart, det inte blir gjort något alls förrän efter ett partimmar. Vilket gör att tidsestimeringen som Burn down chart tillhandahåller blirväldigt labil och näst intill omöjlig att använda. Detta hade kunnat åtgärdas medlängre iterationer, precis som det är meningen att det ska vara på en arbetsplats.Tillsammans med en Sprint backlog fann vi dock att detta gav en tillräckligtöverskådlig process med tanke på den korta tiden som det skulle täcka.

Vi anser att det var tillräckligt med att sätta upp stories på väggen för attefterlikna ett taskboard, eftersom vi ändå inte hade möjligheten att rita ett burndown chart som gav någon vettig information. Hade våran ”taskboard” använtssom det var tänkt tror vi att en bra överblick över aktuell iteration/sprint hadevarit tydlig, men eftersom eleverna allt som oftast glömde bort att flytta storiestill ”klara” delen så fallerade detta till viss del. Detta tror vi kan bero till stordel på att vi som coacher misslyckdes med att definiera story done på ett tydligtsätt. Vi tog för mycket för givet och inser att det är viktigt att vara övertydligpå alla punkter eftersom man inte kan anta att alla ligger på samma nivå i ettteam som inte är handplockat.

11

Kapitel 5

Konsekvensanalys i agila

projekt

5.1 Bakgrund

Med kursen konfigurationshantering (EDAN10) i ryggen kändes det naturligtatt införa begreppet konsekvensanalys i denna kursen också, eftersom det gångpå gång visat sig vara ett väldigt kraftfullt verktyg inte minst inom mjukvaru-branchen.

Tanken bakom detta var att vi skulle uppnå en bättre kodkvalitet samt färrerefaktoriseringar. Vi förväntade oss att det inte skulle bli några speciellt svårakonsekvensanalyser eftersom detta projektet är väldigt linjärt och inför specielltmånga tänkbara fällor.

5.2 Empiri

Från och med andra veckomötet använde vi oss utav konsekvensanalys i sam-band med estimeringen av stories. Gruppen delades upp i två mindre gruppersom var för sig satt och diskuterade konsekvensanalysen för att komma framtill något som sen kunde jämföras med resultatet från den andra gruppen. Omde två gruppernas konekvensanalys inte överensstämde så gick gruppen igenomdet tillsammans och redde ut och diskuterade eventuella oklarheter som kan haorsakat avvikningen. Eftersom konsekvensanalys mer eller mindre kan göras huringående som helst valde vi att lägga det på vad vi ansåg vara en ytlig nivå somborde klaras av utan att ha läst om ämnet i fråga. Tillvägagångssättet som viville att vårt team skulle använda var i stil med [9]:

• Identifiera artefakter som kommer behöva modifieras.

• Spåra andra artefakter som korrelerar med den aktuella artefakten.

• Spåra vidare på samma sätt tills inga fler vägar i en tänkt graf hittas.

• Gå igenom alla spårade artefakter och undersök om de behöver förändras.

12

5.3 Slutsats

Dock visade det sig att det var en aning för svårt att följa arbetsflödet som vihade valt. Konsekvensanalysen blev allt som oftast ganska misslyckad och kundesluta med resultat som:

Det här påverkar alla klasser

Vilket självklart inte är en speciellt bra och utförlig analys. Detta visade sigdessutom genom fruktansvärda refaktoriseringsproblem som antagligen uppkomtill stor del på grund av en undermålig konsekvensanalys.

Vid eftertanke tror vi att det hade varit bättre att inte vänta tills iterationtvå innan man introducerar konsekvensanalys samt att börja i små steg, kanskemed enbart punkt ett i listan.

13

Kapitel 6

Sammanfattning

Eftersom skillnaderna på SCRUM och XP ofta behandlar olika delar av utveck-lingen är det en ganska naturlig process att kombinera de båda. Den relativtkorta period som denna kursen varar känns dock som lite för kort för att dettaska kunna implementeras på ett smidigt sätt. Men vi är båda övertygade omatt idéen är bra och att den förmodligen skulle fungera smärtfritt i ett projektav den större magnituden.

Projekt ute på arbetsplatser använder redan konsekvensanalys och det av enanledning, hade det gjorts grundligt och på rätt sätt i vårat projekt är vi säkrapå att det hade gett oss ett annat resultat, ett bättre resultat. En av våra frågorinnan projektet började var om konsekvensanalys var värt den extra tiden dettar i ett agilt projekt. Med facit i hand så; nej, det var det inte, vi misslyckadesmed största sannolikhet av två skäl. För det första så fanns det inte nog medtid på veckomötena för att hinna göra en djupgående analys av varje story ochför den andra så saknades kompetensen för att göra en.

14

Litteraturförteckning

[1] SCRUM development process, Advanced development methods, Ken Sch-waber

[2] Best Practices in Scrum Project Management and XP Agile Software Deve-lopment, 2004, Object Mentor, Inc. and Advanced Development Methods

[3] Scrum and XP from the Trenches, Henrik Kniberg 2007 C4Media Inc.

[4] Agile project management with Scrum, Microsoft Press, Ken Schwaber2004

[5] Change Impact Analysis for Object-Oriented Programs, Barbara G. Ryder2001

[6] XP Pocket Guide, Shane Warden 2003

[7] Embracing Change with XP, Kent Beck, IEEE 1999

[8] Scrum with XP, Kane Mar & Ken Schwaber, 22 mars 2002, Prentice Hall

[9] Change Impact Analysis, Martin Ward, Software Technology Research LabDe Montfort University

15