1. Inleiding

Voor het OOSE project kregen wij een opdracht van het bedrijf JDI toegekend. Zij wilde graag een nieuwe HR portaal voor hun bedrijf met daarin de mogelijkheden om werkplekken te kunnen reserveren, reiskosten declareren en verlof aanvragen en goedkeuren. De manier waarop dat nu gedaan wordt is met losse Google Docs en Excel bestanden waardoor het al snel niet meer overzichtelijk is. Aan ons dus de taak om deze wensen in een geautomatiseerde applicatie te maken in de vorm van een website. Deze aspecten willen ze graag gerealiseerd zien worden door middel van Java Spring Boot en Vue.js. Een van de uitdagingen hierin was voor mij dat ik nog nooit met een frontend framework zoals Vue.js heb gewerkt. Dit maakt ook gebruik van een nieuwe soort taal voor mij namelijk javascript. Ook zou samenwerking een uitdaging kunnen worden wanneer er conflicten ontstaan binnen in de projectgroep. 

Dit document is geschreven om te reflecteren op hoe ik om ben gegaan met de bijbehorende projectmethode en om te kijken naar mijn eigen bijdrage bij het gehele project. Ook zal er worden aangetoond welke competenties ik naar mijn idee heb behandeld tijdens het project.

1.1. Leerdoelen

Voor dit project heb ik 2 leerdoelen opgesteld die kort worden toegelicht in dit hoofdstuk. In een verder hoofdstuk zal ik de acties toelichten waarmee ik van plan ben om hieraan te werken en de leerdoelen te realiseren.

1.1.1. Leerdoel 1:

Het eerste leerdoel heb ik meegenomen uit een vorig project omdat ik dit nog steeds wil verbeteren aangezien ik dit een belangrijk aspect van samenwerken vind. 

Mijn eerste leerdoel is het consequent laten weten aan mijn groepsgenoten waar ik mee bezig ben.

1.1.2. Leerdoel 2:

Het tweede leerdoel is een leerdoel dat is opgesteld tijdens het project. Ik heb namelijk de rol van scrummaster (deze rol wordt later in het verslag nog toegelicht) op me genomen voor dit project. Hierbij hoort ook het organiseren van de daily standup en ik kreeg na een week de feedback dat dit beter kon. Naar aanleiding daarvan heb ik toen het leerdoel opgesteld. 

Mijn tweede leerdoel is het geven van een een gestructureerde en strakke daily stand up.

2. Kwaliteitsoordeel Deelproducten

2.1. Plan van Aanpak

In het Plan van Aanpak staan alle afspraken tussen opdrachtgever en projectgroep. Hierin zijn de doelstelling, op te leveren resultaten en de kwaliteitseisen in verwerkt. Ook staat erin tot wanneer het project duurt, wie het project uit zal voeren en wat hierin de randvoorwaarden zijn. Het Plan van Aanpak is al een keer nagekeken door zowel de PS docent als de projectbegeleider en aan de hand van de feedback die zij hebben geleverd is het toen aangepast. Hierbij waren er een aantal punten in hoofdstuk 6 bij de kwaliteitseisen die nog niet goed waren. De eisen waren te vaag opgesteld waardoor het als verschillende dingen opgevat konden worden. Dit hebben wij naar aanleiding van die feedback aangepast en opgestuurd naar JDI om zo een akkoord te vormen over wat het uiteindelijke resultaat zal worden. JDI heeft ons hierna laten weten dat ook zij tevreden waren met het Plan van Aanpak, dus daarom is naar mijn mening de kwaliteit van het Plan van Aanpak van voldoende niveau.

2.2. System Requirements Specification (SRS)

In het SRS staat beschreven wat de eisen zijn aan de te bouwen applicatie, hierin staat dus ook de omvang van het project. Alle user classes worden hierin uitgelegd en er wordt verwoord wat er allemaal geimplementeerd gaat worden. Om de samenhang tussen een aantal termen en actoren in het systeem duidelijk te maken is er een domein model opgesteld met daaronder een glossary die uitlegd wat de verschillende domeinen betekenen. Zo is het duidelijk wat er wordt bedoeld met de naamgeving. Ook worden zoals beschreven in het Plan van Aanpak, de use cases volledig uitgewerkt en in een usecase model gezet. Verder worden de functionele en niet functionele eisen goed verdeeld via de FURPS+ methode. Als laatste staan er de user interface sketches in die van tevoren zijn opgesteld om zo een mooi en duidelijk beeld te schetsen van hoe het uiteindelijke resultaat er uit komt te zien. Als ik kijk naar al deze aspecten van het document ben ik van mening dat we ons goed hebben gehouden aan de opgestelde eisen uit het Plan van Aanpak. Ook aan de hand van de feedback van onze projectbegeleider hebben we nog wat hoofdstukken aangepast waardoor de kwaliteit naar een voldoende niveau is getild.

2.3.  Onderzoeksverslag

Het onderzoeks verslag over de database is naar mijn mening uiteindelijk een goed onderzoek geworden door de structurering van de hoofd- en deelvragen. Dit is pas later aangepast omdat er iets te laks mee om is gegaan in het begin van het project. We kwamen al snel tot de conclusie dat MySQL de beste optie zou worden voor ons project en daardoor is het onderzoek niet volledig afgemaakt. Later in het project is dit wel verbeterd om er zo alsnog een kwalitatief onderzoek van te maken. Bij deze verbetering is de feedback van onze projectbegeleider meegenomen, en zijn er bijpassende deelvragen opgesteld. Ook is hieruit een duidelijke conclusie getrokken waarmee de hoofdvraag wordt beantwoord. Door deze aanpassingen vind ik dat het onderzoek van voldoende kwaliteit is.

2.4.  Software Design Description (SDD)

Het SDD is naar mijn mening uiteindelijk van goede kwaliteit, echter is dit met veel moeite zo gebeurd. Er waren een aantal verkeerde opvatting over met name de sub systems waardoor dit in de laatste week nog omgegooid en aangepast moest worden. Dit had eerder gekund als we als groep vaker feedback hadden gevraagd en het ook bij hadden gehouden met de actuele stand van zaken. De rest van het document is door het project heen wel beter bijgehouden en is dan ook goed uitgewerkt. Kijkend naar de eisen die vernoemd staan zijn deze allemaal gehaald. Ook voldoet het aan het meegegeven SDD Template dat uitgereikt is door de HAN. Uiteindelijke is er een duidelijk document uitgekomen die het ontwerp van de applicatie mooi laat zien.

2.5. Unittests

De geschreven unittests voor het project zijn belangrijk om te kijken of de applicatie als geheel nog werkt. Als er unittests zijn die niet slagen dan betekent dat dat er iets is aangepast in de code waardoor er een bepaalde functionaliteit niet meer werkt. Dit is dan ook waarom er is afgesproken dat er altijd unittests mee worden gecommit als er nieuwe code op de develop branch komt te staan. Zodra alle tests nog steeds slagen wanneer je nieuwe functionaliteit toevoegd dan weet je dat alles goed is gegaan. Doordat wij als projectgroep zo goed mogelijk deze afspraken hebben gevolgd heb ik er vertrouwen in dat er ook kwalitatief goede unittests zijn geschreven voor iedere aparte funtionaliteit. Zo is er niet alleen voor het succes scenario een unittest geschreven bij iedere functionaliteit maar ook voor wanneer er verkeerde informatie wordt ingevoerd. Dit is goed te zien in het bestand DeclaratieServiceTest.java. In deze code wordt er bijvoorbeeld niet alleen getest of een declaratie goed gaat met de goede informatie, maar ook of het fout gaat als er een niet bestaande/verkeerde locatie wordt ingevoerd.

2.6. Code

Voor het beoordelen van een stuk code heb ik ervoor gekozen om de code van het bestand LoginService.java te beoordelen. De code in dit bestand voldoet voor een groot deel aan de opgestelde kwaliteitseisen die zijn opgesteld. Er is namelijk traceability naar de specifieke requirement/Jira taak doordat er vanuit een Jira taak een branch is aangemaakt op de bitbucket. Hierdoor kan er altijd gezien worden bij welke Jira taak de branch hoort en ook andersom. Verder is de code kwaliteit zelf ook van volgoende niveau doordat er als projectgroep is afgesproken en ingesteld dat er minimaal 2 groepsleden de code moeten reviewen voordat dit ook pas echt wordt toegevoegd aan het geheel. Door op deze manier 2 andere personen kritisch te laten kijken naar de code zie je meer dan wanneer je alleen zelf er naar kijkt en hier een oordeel over maakt. Echter staat qua taal nederlands en engels af en toe door elkaar maar dit komt omdat er bepaalde termen zijn waarbij er liever engels werd aangehouden zoals bij getters en setters. Verder zijn alle termen die betrekking hebben tot het bedrijf wel in het nederlands zoals werkplekken en werknemers. Dit is goed te zien in het bestand WerkplekService.java. Wel ben ik ook van mening dat de kwaliteit van de code hoger had kunnen zijn als we beter geplande reviewsessies hadden gehad. Dit is iets wat niet heel structureel werd ingepland waardoor er af en toe misschien wat laks naar het reviewen werd gekeken. Dit hebben we dan echter wel weer aangepast wanneer we die code weer tegen kwamen en zagen dat het niet helemaal in orde was. 

2.7.  Testrapport

In het testrapport worden alle gemaakte tests genoemd samen met de methode die ze testen, het verwachtte resultaat, het echte resultaat en of de test geslaagd is of niet. Dit is dan naar mijn idee ook een goede implementatie van een testrapport omdat hier alle belangrijke informatie instaat die nodig is om een goed overzicht te krijgen van de manier waarop getest is. Ook zijn er niet alleen testen geschreven maar ook flow testen om niet alleen de individuele sub systemen te testen maar ook de samenhang. Hierdoor ontstaat er zekerheid over het werken als geheel en niet alleen als aparte delen van een applicatie. In de bijlage is dan ook te zien dat de service map een line% coverage heeft van 85% en dat alle tests slagen. Verder heb ik er vertrouwen in dat deze tests correcte en kwalitatief goede testen zijn door de gemaakt afspraken van hoofdstuk 2.4 hierboven.

3. Kwaliteitsoordeel eindproduct

Als ik kijk naar het uiteindelijke eindproduct wat is opgeleverd in vergelijking met hoe het staat beschreven in het Plan van Aanpak kan ik zeggen dat ik tevreden ben met de kwaliteit. Alle benoemde op te leveren documenten en resultaten zijn aanwezig en van voldoende kwaliteit. Dit oordeel van kwaliteit haal ik dan ook uit de opgestelde tabel (hoofdstuk 6) waar de kwaliteiteisen in vernoemd staan. Hierin staat bijvoorbeeld dat de broncode 100% geslaagde tests moet hebben met een coverage van 80% in de services en dat het SRS alle uitgewerkte use cases bevat met een use case diagram. Doordat we de kwaliteitseisen van het Plan van Aanpak hebben aangehouden hebben we ervoor gezorgd dat de kwaliteit van voldoende hoogte is. Echter ben ik wel van mening dat de kwaliteit hoger had kunnen zijn, dit komt naar mijn idee doordat we als projectgroep te graag aan de code wilden werken. Hierdoor is het documentatie gedeelte vaak pas achteraf gedaan en is dit een beetje links blijven liggen. Zo hebben we in de laatste week nog een grote verandering moeten maken in het SDD omdat onze implementatie van de Sub Systems niet overeen kwam met hoe het werkelijk uitgewerkt moest worden. Voor een volgend project zou ik dit persoonlijk zelf beter op willen pakken en de documentatie door het gehele project heen op het zelfde niveau willen houden als de code. Al met al ben ik wel tevreden met de kwaliteit van het eindproduct en denk ik dat de opdrachtgever dit ook zal zijn aangezien er zoveel mogelijk wensen geimplementeerd zijn en dit ook goed gecommuniceerd is. 

4. Evaluatie gehanteerde projectmethode

Voor dit project moest er gebruikt gemaakt worden van de projectmethode SCRUM. Zoals staat beschreven in het plan van aanpak is SCRUM een agile manier van te werk gaan. Op deze manier wordt er aan het einde van iedere sprint een product opgeleverd waarbij er nieuwe functionaliteit is toegevoegd. Pas aan het einde van het project zal er een product zijn die alle bedoelde functionaliteit en geimplementeerde use cases bevat. Aan het begin van het project zullen er globale requirements opgesteld worden die uitgewerkt worden in de sprints wanneer ze aan bod komen. Zo staat het aanvragen van verlof als een van de laatste requirements en zal die dus ook pas in de laatste sprint volledig uitgewerkt worden. Ook zijn er een aantal 'ceremonies' in de SCRUM methode zoals de daily standup, reviewsessies en de retrospective. Deze zijn van groot belang aangezien deze ceremonies allemaal bedoeld zijn om de kwaliteit van het werk en de samenwerking te verbeteren. 

Kijkend naar de manier waarop er als groep omgegaan wordt met de bij dit project horende projectmethode ben ik hier tevreden mee. Er wordt zo goed mogelijk geprobeerd om volgens de theoretische richtlijnen te werken maar dit gaat niet altijd zoals het hoort. De manier van reviewen kan namelijk op een meer gestructureerde manier dan waarop het nu gaat. Nu wordt er namelijk even snel gevraagd of er mensen naar kunnen kijken terwijl die ook met hun eigen ding bezig zijn. Hierdoor gebeurt het nog wel is dat er toch niet helemaal goed naar wordt gekeken en er veranderingen worden gedaan in code die niet helemaal kloppen. Voor een volgend project zou ik er graag aan willen werken dat er actieve reviewsessies in worden gepland om zo hopelijk de kwaliteit van het project te verhogen. Kijkend naar hoe er met de andere aspecten van SCRUM om is gegaan ben ik hier dus wel blij mee, dit werd dan ook bevestigd door zowel de goede retrospective, als de inhoud van de retrospectives.

5. Beschrijving rollen

In dit project heb ik de rol van Scrum Master (Plan van aanpak H7 en H8) op mij genomen. Deze rol houdt in dat ik verantwoordelijk ben voor het naleven van de scrum ceremonies in de groep. Hierbij horen bijvoorbeeld de daily standup, de review sessies en de retrospective. De reden hierachter is omdat ik mezelf vaak wat meer op de achtergrond zet als het gaat om taken die bij deze rol horen, zoals het organiseren van de daily standup en het zorgen dat een aantal aspecten van de projectmethode goed worden doorgevoerd. Door deze rol op me te nemen hoop ik mijzelf hierin te ontwikkelen en zo ook wat sterker in mijn schoenen te gaan staan. 

Zoals verwacht ging dit in het begin nog niet helemaal goed en was met name de daily standup nog vrij rommelig. Echter kreeg ik dit vrij snel te horen tijdens de eerste meeting met de PS docent. Tijdens deze meeting was er een moment om feedback te ontvangen en hier heb ik me toen voor opengesteld. Dit was achteraf gezien een goed idee omdat ik toen een aantal tips kreeg over hoe ik de daily standup kon verbeteren en dus ook over hoe ik beter mijn rol kon vervullen. Sindsdien ben ik met meer focus bezig gegaan op het verbeteren van de daily standup, aangezien ik dit ook opgenomen heb ik een van mijn leerdoelen. Hierover zal ik meer uitleggen in hoofdstuk 7 over de leerdoelen.

Een aspect van mijn rol die ik naderhand gezien beter op had moeten pakken was het kwalitatief beter maken van de review sessies. Deze sessies zijn erg belangrijk om de kwaliteit van de code tot een hoger niveau te tillen. Als ik terugkijk op het project hebben we eigenlijk bijna geen reviewsessies gehad en was het vaak even snel maar wel aandachtig kijken. Dit is uiteindelijk ook goed gegaan maar ik ben van mening dat dit beter had gekund als we actieve reviewsessies hadden ingepland. Hierin zou ik mezelf dan ook graag in willen ontwikkelen.

6. Competenties

6.1. OOSE P-04: De student ontwerpt de software van een systeem en documenteert deze onder andere met behulp van UML Diagrammen en decision templates in een SDD

In het begin van het project heb ik samen met Gino de gehele structuur van de database ontworpen en verwerkt in een CDM. Uit dit CDM is een PDM gegenereert die uiteindelijk is het SDD is gekomen. Dit proces is een paar keer uitgevoerd omdat na iedere sprint er nieuwe functionaliteiten bij kwamen die ook een nieuwe toevoeging met zich mee brachten in de data structuur. In de loop van het project zijn er daarom ook een aantal beslissingen genomen en gedocumenteerd met betrekking tot het ontwerp.

6.2. OOSE P-05: De student implementeert een gedistributeerd systeem, evalueert het ontwerp en de realisatie daarvan en zorgt voor traceerbaarheid daartussen en naar de functionele en niet-functionele eisen

Een van de werkzaamheden die ik heb gedaan voor deze competentie is het ontwerpen van de backend van het inlog systeem in de applicatie. Dit was in het begin lastig om te ontwerpen omdat ik dit nog nooit had gedaan, maar met wat hulp ben ik hier toch uitgekomen. Hierbij is toen ook een sequence diagram samen met de design keuzes gemaakt die mooi de stappen en handelingen van het systeem laat zien (SDD). Dit had ik echter beter kunnen doen door eerst het ontwerp te maken en daarna pas bezig te gaan met het implementeren. Voor ik begon met het schrijven van de code heb ik een branch aangemaakt op de Bitbucket vanuit Jira om zo de traceerbaarheid naar de taak goed op niveau te houden. In deze branch is het Issue nummer meegenomen en welke subtaak er behandeld en uitgewerkt wordt. Bij het uitwerken van deze taak is er rekening gehouden met de niet-functionele eis NFR14 (SRS H7.5).

6.3. OOSE P-07: De student bewaakt continu de kwaliteit van de software en het proces door o.a. reviews en gestructureerd testen en stuurt waar nodig bij.

Om de kwaliteit van de software hoog te houden heb ik een aantal opmerkingen achter gelaten bij pull requests van andere groepsgenoten. Hierin vraag ik bijvoorbeeld naar unittests, en zorg ik ervoor dat de testdata correct in de database komt. Door dit te doen kwam er correcte data in de database en heb ik ervoor gezorgd dat de unittests gelijk werden gemaakt in plaats van dat dat later nog werd gedaan. Op gebied van gestructureerd testen heb ik zelf ook mijn deel bijgedragen door ervoor te zorgen dat ik bij iedere code die ik op de develop branch wil zetten, ik ook de bijbehorende unittests maak. In deze pullrequest is goed te zien dat ik nieuwe functionaliteit toevoeg en hier gelijk ook unittesten bij commit. Hierdoor is er altijd een manier om te kijken waar bepaalde aspecten van de code fout gaan. Door 1 keer alle tests te runnen krijg je een goed overzicht van alle functionaliteit en of het nog werkt. 

7. Leerdoelen

7.1. Leerdoel 1

Mijn eerste leerdoel is een leerdoel dat voort gekomen is uit meer online werken maar wat ik alsnog belangrijk vind om aan te werken. Ik heb vaker moeite gehad met het laten weten aan groepsgenoten waar ik mee bezig was. Dit zorgde ervoor dat mijn groepsgenoten niet precies wisten waar ik mee bezig was en of ik al af waarvan ik had gezegd dat ik eraan zou werken. Online was hiervoor bij mij de drempel net te hoog om dit altijd te laten weten, dus dan deed ik het maar niet. Dit is iets wat ik graag wil verbeteren en waar ik dan ook mee aan de slag wil. Een manier waarop ik dit wil aanpakken is het zo vaak mogelijk fysiek op locatie werken, waardoor je ook meer contact hebt met elkaar over dingen die niet altijd over het project gaan. Ik verwacht dat hierdoor de drempel voor communicatie lager wordt en dat ik makkelijker kan laten weten waar ik sta met mijn werkzaamheden. Thijmen kwam met het idee om ook smiddags een mid daily standup te doen om zo ook door de dag heen meer duidelijkheid te krijgen over waar we op dat moment stonden met de werkzaamheden die we hadden afgesproken. Dit heb ik ook als erg fijn ervaren omdat dit nog een kans was voor mij om aan mijn groepsleden te laten weten waar ik mee bezig was en wat ik nog van plan was voor die dag. Uiteindelijk heeft het mij heel erg geholpen om veel fysiek op locatie te werken door de laag drempeligheid voor communicatie op die manier. Ook kwam ik er achter dat er een betere werksfeer ontstond op locatie dan wanneer we online werkte waardoor ik makkelijker op mijn groepsgenoten af kon stappen om een update te geven. 

7.2. Leerdoel 2

Mijn tweede leerdoel is gebaseerd op een van de ervaringen die naar voren kwam tijdens de eerste retrospective. Hierin kreeg ik de feedback van mijn groepsgenoten dat de daily standup wat strakker en wat georganiseerder mocht. Aangezien ik de daily standup een belangrijk aspect en begin van de dag vind wilde ik dit graag meenemen in een van mijn leerdoelen. Door dit te doen zal ik meer bezig gaan aan het verbeteren van de daily standup en zo hopelijk ook een deel van de productiviteit en duidelijkheid voor die dag te verbeteren. Ik wil de daily standup gaan verbeteren door er een vaste structuur in te zetten. Hierin ben ik van plan om met de klok mee ieder groepslid, inclusief mezelf langs te gaan met een aantal vragen. Hierbij vraag ik wat ze gister hebben gedaan, wat daar de voortgang van is en waar ze vandaag aan gaan werken. Wanneer iedereen is geweest zal ik kort samengevat nog een keer zeggen wat er voor die dag voor iedereen op de planning staat en dan kunnen we aan de slag. Op deze manier zal er naar mijn idee meer duidelijkheid en structuur in komen, waardoor de productiviteit hopelijk omhoog zal gaan. Ik heb aan mijn groepsleden gevraagd of ze hierop wilde letten en om feedback erover te laten merken in de retrospectives en dit is ook gebeurd. In de retrospectives heb ik dan ook te horen gekregen dat de manier waarop de latere daily standups werden gehouden als fijn en gestructureerd zijn ervaren. Wel miste ik af en toe het samenvatten aan het eind van de retro dus dat is iets wat ik mee zal nemen in verdere projecten wanneer ik deze rol weer op me zou nemen. Door dit in mijn leerdoel op te nemen heb ik mezelf ook meer ontwikkeld in het leiden van een gesprek. Voorheen hield ik me altijd meer op de achtergrond van een gesprek en ging ik mee in de meesten dingen. Omdat de sfeer in de groep goed zat wat het voor mij ook makkelijker om de leiding te nemen in een gesprek zoals de daily standup.

8.  Conclusie

Nu ik aan het einde van het project ben kan ik op een tevreden manier terug kijken naar de werkzaamheden die ik heb uitgevoerd en wat ik hiervan heb geleerd. Kijkend naar het eindproduct hebben wij ons best gedaan om hier zo veel mogelijk wensen van JDI in te verwerken en dit is naar mijn mening ook gelukt. De oplevering presentatie voor JDI is 15 juni, hiervoor moeten we nog wel een presentatie maken. Als ik terugkijk naar wat JDI van de applicatie vond tijdens de sprintreviews heb ik er vertrouwen in dat ze het eindproduct goed genoeg zullen vinden om het ook in gebruik te gaan nemen mochten ze dat willen. 

Een van de uitdagingen die ik in de inleiding heb genoemd, het werken met Vue.JS, is iets wat ik geprobeerd heb maar waar ik uiteindelijk niet veel mee heb gedaan. Hierdoor ben ik me meer gaan focussen op de backend van de applicatie, en hier voelde ik me dan ook comfortabeler. Door een paar belangrijke scrum aspecten op me te nemen met de rol van Scrum master heb ik ook nieuwe eigenschappen ontwikkeld, namelijk het meer initiatief nemen in gesprekken. Voorheen was ik wat stiller en vond ik alles prima maar door nu bijvoorbeeld een daily standup te leiden moest ik ook meer structuur aanbrengen in een gesprek. Een ander uitdaging die in de inleiding stond was het samenwerken. Hiermee heb ik in vorige kleinere projecten voor school wel is moeite mee gehad, maar dat ging in dit project een stuk beter. Iedereen communiceerde goed met elkaar wanneer ze een keer een afspraak hadden staan op het midden van de dag zodat de rest hiervan op de hoogte was. Zo hebben zowel ik als Thijmen een keer sollicitatie gesprek gehad voor een stageplek. Hier werd goed mee omgegaan en ook netjes om heen gepland. Ook hadden we afgesproken om iedere dag een wandeling naar de Coop te maken om zo even buiten te zijn en weg te zijn van de omgeving waar we de hele tijd in aan het werken waren. Dit was ook erg fijn omdat je dan even je hoofd leeg kon maken en daarna weer met een soort nieuwe start de middag kon beginnen. Door de tijd van het jaar waarin dit project plaats vond waren er ook veel vrije dagen zoals pinksteren, hemelvaart, pasen etc.. Hierdoor werd het rooster een soort gatenkaas maar doordat er goed gepland werd zijn we hier niet meer in de problemen gekomen. Wel hebben we hierdoor een paar keer wat vaste afspraak momenten moeten verzetten maar dit ging ook soepel. 

Al met al kan ik zeggen dat ik dus veel geleerd heb tijdens dit project, niet alleen door mezelf te ontwikkelen maar ook door een aantal van de positieve ervaringen die hierboven benoemd staan. 

9. Bijlagen

9.1.  Fact sheet

9.2. Screenshots van test coverages