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. Deze aspecten wilden 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.
Leerdoelen
Voor dit project zijn 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.
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.
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.
Kwaliteitsoordeel Deelproducten
Onderzoeksverslag
SDD
Unittests
De geschreven unittests voor het project
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.
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.
Een deelproduct wat naar mijn mening goed in elkaar zit en van hoge kwaliteit is is het vue.Js onderzoek. Dit is dan ook iets
Kijkend naar alle deelproducten die er op dit moment zijn kan ik zeggen dat ik tevreden ben met de kwaliteit hiervan. Bij het werken aan de deelproducten wordt er dan ook gekeken naar de eisen die zijn opgesteld in het Plan van Aanpak waardoor er een duidelijke maat is van welke kwaliteit er verwacht wordt wanneer je klaar bent. De kwaliteit zou naar mijn mening misschien nog hoger kunnen zijn door het gebrek aan gestructureerde reviewsessies.
De kwaliteit van het plan van aanpak is iets waar goed op gelet is aangezien dit een soort contract tussen de projectgroep en de opdrachtgever is. Hier hebben we dan ook in het begin van het project de volle focus opgelegd. Tijdens het assessment over het plan van aanpak hebben we nog een aantal verbeterpunten gekregen die er daarna ook gelijk in verwerkt zijn. Zoals het nu staat ben ik dan ook tevreden met de kwaliteit hiervan.
Het SRS en het SDD zijn deelproducten waar op het moment nog veel aan gewerkt wordt dus waar ik naar mijn idee nog niet een goed kwaliteitsoordeel over kan geven. Wel wordt er aan gewerkt aan de hand van de eisen die in het plan van aanpak staan opgesteld. Hierdoor is wat er op het moment in staat wel in lijn van die eisen.
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.
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.
Beschrijving rollen
In dit project heb ik de rol van Scrum Master 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.
Een verbeterpunt voor het tweede deel van dit project is het georganiseerder maken van de reviewsessies. Dit past goed bij mijn rol en zou ook de de kwaliteit van de deelproducten kunnen verhogen.
Competenties
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.
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).
OOSE P-07: De student bewaakt continu de kwaliteit van de software en het proces door diir 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.
Leerdoelen
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.
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.
Conclusie
In dit document heb ik gekeken en gereflecteerd op een aantal punten die tot nu toe aan bod zijn gekomen bij dit project. Hierin missen nog wel een aantal onderdelen die wel aanwezig zullen zijn bij het eindverslag.
Bijlagen
