...

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

...

Leerdoelen

Voor dit project Heb 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.

...

Kwaliteitsoordeel Deelproducten

 Onderzoeksverslag

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.

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.

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

 Software Design Description (SDD)

...

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

Evaluatie gehanteerde projectmethode

...

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.

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. 

...

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

...

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

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. 

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

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

...