...

Kwaliteitsoordeel Deelproducten

 Onderzoeksverslag

 Software Design Description (SDD)

Het SDD Het onderzoeks verslag over de database 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. 

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.

Code

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.

 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.

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 ingevoerdVoor 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 DeclaratieServiceTest.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

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.

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. 

 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 (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. 

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 

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. 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 werkteMijn 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.

...

In dit document heb ik gekeken naar wat mijn bijdrage was in dit project 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 eindverslagheb ik zowel daarop als op het gehele project gereflecteerd. Ik ben van mening dat ik veel heb geleerd dit project, waaronder hoe het is om voor een echte opdrachtgever te werken. Hierdoor zijn er ook wat moeilijkere situaties onstaan dan verwacht maar daar zijn we als projectgroep samen goed uit gekomen. 

Bijlagen