...
Kwaliteitsoordeel Deelproducten
In dit hoofdstuk zal ik een
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
...
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
...
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
Dit onderdeel heb ik nog niet verwerkt
Leerdoelen
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
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.
Database: https://bitbucket.aimsites.nl/projects/BUGAYQ/repos/database/pull-requests/16/overview
vraag naar tests: https://bitbucket.aimsites.nl/projects/BUGAYQ/repos/jdi-werknemersbeheer/pull-requests/62/overview
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 werkzaamhedenHet behandelen van mijn eerste leerdoel is nog niet iets waar ik actief mee bezig ben geweest.
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 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
