Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: eind versie

Table of Contents

Inleiding

Het is de opdracht om een HR-portaal te ontwikkelen, het hoofddoel van het portaal is werkplaatsbezetting op te slaan, op basis opgeslagen gegevens wordt het declaratieformulier automatisch ingevuld. Daarnaast komen de mogelijkheden om verlofaanvragen te doen en handmatig de declaraties door te geven. Een van de inhoudelijke uitdagingen is kennis op doen van front-end technologie, het framework dat wij gaan gebruiken om het portaal te realiseren is Vue. Het is een framework dat is ontwikkeld door middel van JavaScript, van beide heb ik geen kennis bij aanvang van het project. Het is nodig om onderzoek te doen naar front-end technologie om mijn kennis uit te breiden.

...

Onderzoeksverslag database

Het onderzoek is van voldoende kwaliteit, er zijn op basis van bronnen de kenmerken van drie soorten database systemen onderzocht. Op basis van de bevindingen is er een besluit gevormd. Om een hoger cijfer te geven voor dit deelproduct ga ik de volgende keer meer bronnen raadplegen en de gevonden resultaten afwegen in een tabel, om zo tot een keuze te komen. Omdat er nu een afweging is gemaakt op basis van de bronnen en eigen verwachtingen.

CriteriaCijferToelichting
Er is een hoofdvraag7Hoofdvraag sluit aan op de uitleg uit de inleiding.
Deelvragen sluiten aan op de hoofdvraag7Deelvragen bieden de mogelijkheid om onderbouwing te geven op de hoofdvraag.
Criteria en aanpak zijn opgesteld6De manier waarop een keuze wordt gemaakt is onderbouwt en de aanpak is duidelijk geformuleerd.
Deelvragen dienen ter onderbouwing op het antwoord op de hoofdvraag6In de conclusie worden de punten benoemd in bij de deelvragen meegenomen in het besluit.
Conclusie sluit aan op de hoofdvraag6De hoofdvraag is beantwoord, en het is duidelijk welk systeem aansluit op de te maken implementatie.
Eindcijfer6,6

Software design document

Voor het SDD zijn er in het plan van aanpak criteria opgesteld. Deze criteria staan in de onderstaande tabel en komen uit het plan van aanpak. Per criteria geef ik een cijfer, de losse cijfers vormen gezamenlijk het eindcijfer.

...

CriteriaCijferToelichting
Alle gemaakte test slagen voor 100%8Alle tests slagen. Geen verdere toelichting.
De test coverage is hoger dan 80% van de code waar het nodig is om te testen6De onderdelen die worden getest hebben een dekking van 80% en hoger. Er zijn componenten die ik heb gemaakt die geen tests hebben omdat het simpele functionaliteit bevat. Omdat er dus onderdelen zijn die niet worden getest geef ik voor deze criteria een 6.
Alle tests zijn zinnig en hebben toegevoegde waarde6Ik heb de tests voor de http requests uitgeschreven. Er zijn tests die alleen kijken http requests worden geaccepteerd.
Test Driven Development toegepast4Tests driven development niet toegepast. Ben pas begonnen met testen nadat ik Vue ben gaan beheersen.
Arrange-Act-Assert pattern (Hawkins, 2022)6Er wordt een soortgelijk patroon toegepast waar een mock wordt voorbereid en daarna wordt vergeleken of de uitkomsten overeenkomen.
Evaluate a single concept per test (Hawkins, 2022)7Per test wordt een onderdeel per functie getest
Er is maximaal 1 assertion per test (Summary of “Clean Code” by Robert C. Martin, z.d.)8Iedere test bevat maximaal een assertion.
Eindcijfer deelproduct6,2


Testrapport

Oordeel eindproduct

...

Deze beoordeling is op basis van het front end testrapport.

CriteriaCijferToelichting
Tests hebben een logische naam7De naamgeving spreekt voor zicht. Het is dus gelijk duidelijk wat de test gaat doen.
Er is een verdeling van de te testen onderdelen8De testen met resultaten zijn opgedeeld op basis van functionaliteit. Er is een duidelijk overzicht van het geheel.
100% slagingspercentage8Alle tests slagen.
Alle tests zijn aanwezig6Bij het beoordelen zag ik dat er enkele tests zijn vergeten. Op het moment van schrijven is er geen tijd meer om deze toe te voegen.
Eindcijfer deelproduct6,2

Oordeel eindproduct

OnderdeelCijfer
Code8
Onderzoek6,6.5
SDD6.,8
Unit tests

6.,2

Testrapport6,6

De uiteindelijke code van alle onderdelen samen geef ik een 7 op het moment van schrijven, omdat alle code functioneel is. Er ontbreken op sommige vlakken ontwerp principesontwerpprincipes, zoals het toepassen van interfaces. Zo hebben de mappers geen interface waardoor ze niet voldoen aan het open closed principe. Er zijn nog refactor mogelijkheden op het voor de frontend code. Doordat ik front end development ben gaan leren, had ik niet alle kennis om de code de eerste keer perfect op te bouwen. Hierdoor zijn enkele componenten groter dan nodig en is het nog nodig om deze componenten op te delen in kleinere componenten, i.v.m. tijd tekort neem ik dit mee als leerpunt voor volgenhet een volgende front end opdrachtenopdracht.

Voor het eindoordeel is het nodig om het product te beoordelen op basis van de specificaties in het SRS. Hiervoor heb ik de onderstaande criteria opgesteld.

...

Op basis van de bovenstaande criteria kom ik uit op een 7,6. het gemiddelde cijfer uit mijn eindoordeel komt uit op een ... 7,3 Het doel van de opdrachtgever is bereikt want, het is niet meer nodig om drie spreadsheets bij te houden. Het systeem maakt het nu mogelijk om werkplekken te reserveren, declaraties aan te maken en in te zien. Hetzelfde geldt voor verlofaanvragen. Op basis van het werkplekoverzicht worden automatisch de declaratieformulieren bijgewerkt.

...

Zoals omschreven houden we iedere morgen een daily standup, en is er in de eerste week een beeld gevormd van het op te leveren product. Na het overleg hebben we een vragenlijst doorlopen met de opdrachtgever om er zeker van te zijn dat er geen onduidelijkheden zijn. In de eerste week zijn we erachter gekomen dat het houden van een mid-daily standup niet nodig is op het moment, als iemand ergens mee klaar is geeft die persoon het aan en vertelt diegene aan welke taak de persoon gaat werken. Op het moment van schrijven is er een retrospective gehouden, tijdens de retrospective heb ik feedback ontvangen en ben op basis hiervan een leerdoel gaan formuleren §7.1. Een verbeterpunt voor het werken met de projectmethode is het aanhouden van de uit te werken use cases tijdens de nieuwe sprints. Het is namelijk voorgekomen dat er twee use cases zijn vastgesteld in de eerste sprint. Het doel van scrum is ook om dan alleen de use cases te werken die zijn vastgesteld. Tijdens de eerste sprint is het namelijk voorgekomen dat er aan taken zijn gewerkt die niet op de planning staan. Daardoor was er een database schema databaseschema opgesteld voor het hele domein en niet voor de onderdelen uit de use case, hetzelfde geldt voor het domeinmodel en de schermontwerpen. Wat hiervan het gevolg kan zijn is dat er wijzigingen komen in de implementatie en daardoor kan er tijd verloren gaan door overbodig werk. Om dit te voorkomen is er tijdens de tweede retrospective afgesproken dat er in de rest van de sprints aan de gekozen use cases gaan werken. Met als doel overbodig werk te besparen en doelgericht te werk kunnen gaan.

...

Voor het eerste gesprek met de opdrachtgever was het nodig om te verdiepen in de opdracht, hieruit volgen een aantal vragen. Om de opdrachtgever te laten weten waar hij aan toe is heb ik voorgesteld een gespreksagenda te maken met daarin de onderwerpen die aan bod komen, met de tijd de we hebben per onderdeel om het gesprek optimaal te benutten. Door tijden erbij te zetten kunnen we ervoor waken dat er niet te lang over een onderwerp wordt gesproken. Door de vragen en de agenda aan te leveren weet de opdrachtgever waar hij aan toe is, en wat er wordt verwacht. Het resultaat is dat, de opdrachtgever bij aanvang van het gesprek aangeeft dat wij de eerste groep zijn die een gespreksagenda toe stuurt. Hij gaf aan dat hij hier zeer content mee is. Wat ik hieruit meeneem is, dat ik bij volgende kennismakingsgesprekken met een opdrachtgever een gespreksagenda ga opstellen, omdat dit als professioneel wordt ervaren en zo weten beide partijen wat er besproken wordt. Wat ik volgende keer anders zou doen is bij de vragenlijst enkele vragen toevoegen die andere vragen tegenspreken. Als er dan in het gesprek blijkt dat de juiste en onjuiste vraag beide goed zijn, dan weet ik dat het nodig is om door te vragen omdat er dan toch onduidelijkheden zijn.

...

Voor het project heb ik de rol kwaliteitsmanager op me genomen. Zoals omschreven in het plan van aanpak "Eindverantwoordelijke voor de kwaliteit van het project. Belangrijke rol bij de code reviews.". In de functie-omschrijving van een kwaliteitsmanager (Functieomschrijving voor Kwaliteitsmanager | Indeed, z.d.) staat dat de kwaliteitsmanager de bedrijfsprocessen gaat monitoren die invloed hebben op de kwaliteit van een product. Hierbij hoort het uitvoeren van kwaliteitsanalyses en het voorzien van kwaliteitsverbeteringen aan de implementatie. Ik wil er tijdens dit project achter komen hoe de rol kwaliteitsmanager invloed heeft op de uiteindelijke implementatie. Om dit doel te behalen heb ik het leerdoel dat te lezen is in §6.2 opgesteld. De situatiebeschrijving uit §7.2.2.1. beschrijft hoe ik aan mijn leerdoel heb gewerkt en tevens komt hier mijn rol als kwaliteitsmanager naar voor. Het opstellen van deze documentatie heeft een positief effect op de verdere werkzaamheden. Wat verbeterd kan worden is dat de API-documentatie niet mee is genomen tijdens het reviewen. Met als gevolg dat er van enkele endpoints geen documentatie beschikbaar is. Wat ik de volgende keer anders ga doen is ervoor zorgen dat de documentatie onderdeel wordt van de taak. Door het als verplicht onderdeel op te nemen is het nodig dat er een review komt. Door ervoor te zorgen dat er een review komt vinden de groepsleden mogelijke fouten en/of gebrekken gebreken in de documentatie.

Tijdens dit project heb ik geleerd dat, een kwaliteitsmanager stevig in zijn schoenen moet staan. Want het is nodig om aan te geven dat onderdelen niet voldoen aan de eisen, daarnaast is het ook nodig om daarop te anticiperen en daardoor een ander teleur moet stellen omdat er werk aangepast moet worden of extra werkzaamheden toewijzen om aan de eisen te voldoen. Ik merk dat een kwaliteitsmanager de conflicthanteringsstijlen (Vogelzang, 2022) doordrukken, samenwerken en compromis sluiten toe moet passen. Doordrukken omdat het nodig is om met deze rol op te komen voor de kwaliteit en daarom andere erop aan spreken, ook als er andere groepsgenoten het er niet mee eens zijn. De stijl compromis sluiten en samenwerken hangen sterk samen met doordrukken omdat het beter werkt om als team tot een oplossing te komen, in plaats van een oplossing door te drukken. Uit de volgende bron (9 tips voor succesvol samenwerken binnen een team, 2020)  blijkt dat het nodig is om met elkaar in overleg te gaan over de kwaliteit en elkaar daarop aanspreken, want als dit niet wordt gedaan lever je zelden het best mogelijke resultaat.

...

Om de traceerbaarheid mogelijk te maken zijn er user strories opgesteld op basis van de usecases, op basis van de user stories zijn er taken opgesteld. Het is de afspraak dat in in Jira branches worden aangemaakt per taak. Zo is het nu te zien welke branche bij welke taak hoort. Het is voorgekomen dat ik via Github desktop of Bitbucket branches heb aangemaakt, het gevolg hiervan is dat er bij die taken niet terug te vinden in Jira. Ik ben hier op aangesproken door een groepslid. Hierna was het mij duidelijk wat hier mis mee is, en ben vanaf dat moment taken gaan aanmaken in Jira. Zoals te zien is in de onderstaande afbeeling, is het niet duidelijk welke branches horen bij een taak. Na het toepassen van de feedback worden branches aangemaakt zoals de onderste rij is te zienee. Ik heb hiervan geleerd hoe ik software traceerbaar maak. In vervolg project ga ik taken aanmaken vanuit Jira om ervoor te zorgen dat het overzichtelijk blijft welke taak bij welke branche hoort. Zoals te lezen in §7.2.2.1 heb ik ervoor gezorgd dat er API-documentatie wordt opgesteld, door dit voor te stellen is er traceerbaarheid mogelijk gemaakt voor de communicatie tussen front- en backend.

...

Tijdens dit project heb ik de rol als kwaliteitsmanager, zoals te lezen in §7.2.2.1 is mij opgevallen dat de communicatie tussen front- en backend niet soepel verliep. Om daar iets aan te doen heb ik het initiatief genomen om API-documentatie op te stellen. De groepsleden zijn akkoord gegaan met het voorstel en zijn het gaan toepassen sinds dien. Omdat ik dit project een van het front end developers ben, heb ik de meeste pull requests met betrekking tot het front end beoordeeld. Om ervoor te zorgen we de kwaliteit en funtionaliteit functionaliteit waarborgen heb ik unit tests geschreven voor het front end, dit zijn werkzaamheden die ik samen met Tobias heb uitgevoerd. Een ander document waar ik veel aandacht aan heb besteed is het SRS, hier heb ik 41 comments geplaatst en deze verwerkt met de groepsgenoten.

...

Door te kijken naar een visualisatie, krijg je meer inzicht waar kansen liggen voor verbetering (Processen visualiseren in Process Advisor - Power Automate, 2022). Bij het visualiseren word je gedwongen om keuzes te maken tussen hoofd- en bijzaken, hierdoor wordt de boodschap compact. Kun je het niet simpel visualiseren? Dan betekend het dat het onderwerp nog onduidelijk is. Bij het bespreken van een visualisatie dan spreekt een beeld meer dan een woord, het zorgt ervoor dat hetgeen dat wordt besproken duidelijk is voor andere. (morresMarketing, 2018)

Actie 1: visualiseren

...

Tijdens de eerste retrospective is mij verteld dat het opvalt dat, ik bij het leren van het Vue de te maken onderdelen als een groot geheel zie, en hierdoor neig het overzicht te verliezen. Om hieraan te werken kies ik ervoor om hier een van de leerdoelen van te maken.Het is mijn taak om het mogelijk te maken om een werkplek toe te voegen aan een bedrijfslocatie. Hiervoor ben ik een stappenplan gaan uittekenen d.m.v. Miro, het is nog niet duidelijk voor mij hoe data wordt doorgegeven aan onderliggende componenten, hiervoor ga ik voorbeelden opzoeken en de implementatie daarop uitwerken. Door een stappenplan te maken (FIGUUR) heb ik meer overzicht wat er moet gebeuren, om dit te testen heb ik overleg gehad met een groepsgenoot en hij gaf aan dat het duidelijk is wat er moet gebeuren. Zodoende ben ik stapsgewijs de implementatie gaan uitwerken. Door op deze manier te werken hou ik overzicht van de te maken onderdelen en kan ik op een logische manier de code opbouwen. Anders komt het voor dat ik bij het leren van nieuwe stof van alles ga proberen, logischerwijs loop ik dan vast en dan raak ik dus sneller het overzicht kwijt. Dus ik merk dat op deze manier werken mij zeker helpt om nieuwe onderwerpen te leren en toe te passen. Het kost tevens wel meer tijd om een heel stappenplan te maken van alle onderdelen. Met als conclusie dat ik geen stappenplannen ga maken voor onderdelen waar ik voldoende kennis over heb, omdat het meer tijd kost en tijd is kostbaar.

...

Ik heb de taak op me genomen om het mogelijk te maken om werkplekken toe te voegen. Tijdens het uitwerken merkte ik op dat er naast een naam voor de werkplek, er ook een soort nodig is om de werkplek aan te koppelen. (FIGUUR) Op basis van de toelichting van de opdrachtgever leek het me overbodig om een soort toe te kennen, omdat de opdrachtgever aangeeft dat hun bijvoorbeeld een algemene werkplek hebben en een focuswerkplek. Dus mij lijkt het dubbelop om een ruimte zo te noemen en dan ook nog aan te geven dat het een van de soorten hetzelfde is. Dit heb ik aangegeven aan de personen die bezig zijn met de backend van dit onderdeel, hieruit kreeg ik de reactie dat het handig is om te hebben. Hier was ik het niet geheel mee eens, maar heb het voor lief genomen. Om de situatie terug te koppelen maak ik gebruik van een conflicthanteringsmodel (Vogelzang, 2022) Wat ik heb gedaan is de stijl vermijden en toegeven toepassen. Door de stijl vermijden en toegeven toe te passen is er tijd gewonnen, en een mogelijke discussie vermeden. Ik was er bang voor dat ik er bij de stijl doordrukken een discussie zou ontstaan doordat, de andere groepsgenoten aangaven dat, ze over dit onderwerp meermaals te hebben besproken. Als ik terug kijk op deze situatie besluit ik dat, de volgende keer als er een zelfde soort situatie is een middenweg voor te stellen en dus de stijl compromis sluiten toepassen. Met als compromis het besluit bij de opdrachtgever neer te leggen. Op die manier kan er ook geen onderlinge discussie ontstaan over wat de opdrachtgever mogelijk wilt. Daardoor hoeft er ook geen conflict vermeden te worden en krijgt de opdrachtgever de implementatie zoals gewenst.

...

Ik ben zeer tevreden met het resultaat dat we opleveren aan de opdrachtgever. In hoofdstuk 3 heb ik toelichting gegeven op het eindproduct en hieruit blijkt dat het doel van het hele project is behaald, het is voor de opdrachtgever niet meer nodig om meerdere spreadsheets bij te houden. Tijdens de retrospectives hebben we ons als groep kunnen ontwikkelen en ik ook als persoon door de feedback rondesfeedbackrondes. Hierdoor ben ik op het leerdoel gekomen om te gaan visualiseren, door dit te gaan doen had ik minder moeite om nieuwe onderdelen op te pakken met het front end framework. Van de feedback rondes feedbackrondes heb ik ook geleerd hoe ik een balans kan vinden tussen vragenstellen vragen stellen aan andere personen en het zelf uitzoeken. Ook heeft het nut gehad om een vragenkanaal op te stellen.

...

Verder heb ik deze periode als plezierig ervaren, er heerste een fijne sfeer in de groep. We hebben gingen iedere dag een gewandeld pauze naar de Coop in de pauzewandelen, in deze tijd kon iedereen even zijn gedachtes verzetten en kon iedereen weer geconcentreerd verder. De meeste dagen hebben we aan het eind van de dag de laatste 15 minuten een afsluitend spel gedaan om met gezamenlijk af te schakelen.

...

NummerCompetentieLink naar het product (JIRA taak)Beschrijving eigen bijdrage

1.

OOSE-P1H4 van dit verslagOpstellen van een gespreksagenda om ervoor te zorgen dat de opdrachtgever weet wat wij van hem verwachten.

2.

OOSE-P1H5 van dit verslagReflectie op mijn rol als kwaliteitsmanager met hierin benoemd wat er goed ging en welke verbeterpunten er zijn.
3.OOSE-P1Doelstelling Plan van aanpakUitschrijven van de doelstelling in het plan van aanpak.
4.OOSE-P1Plan van aanpak14 comments ten behoeve van kwaliteitsverbetering.
5.OOSE-P1Projectgrenzen Plan van aanpakUitschrijven van de projectgrenzen in het plan van aanpak.
6.OOSE-P2Use case modelOpstellen van het use case model.
7.OOSE-P2UC: invullen werkplekschemaUitwerken fully dressed versie van deze use case.
8.OOSE-P2UC: aanvragen verlofUitwerken fully dressed versie van deze use case.
9.OOSE-P2Software Requirements Specification41 comments ten behoeve van kwaliteitsverbetering.
10.OOSE-P3Google Distance Matrix API Onderzoekmeerdere comments ten behoeve van kwaliteitsverbetering.
11.OOSE-P3Database onderzoek12 comments ten behoeve van kwaliteitsverbetering.
12.OOSE-P3Database onderzoekOnderzoek uitbreiden met hoofdvraag en deelvragen en aansluitende conclussie met correcte APA bronvermelding.
13.OOSE-P4Software Design DescriptionOntwerpbeslissingen documenteren front end.
14.OOSE-P4Software Design DescriptionSOLID en GRASP toelichten sequence diagrammen
15.OOSE-P4Software Design DescriptionDesign front end subsystem uitschrijven
16.OOSE-P5user stroriesHelpen met het opstellen van user stories op basis van de use cases.
17.OOSE-P5 Bitbucket branchesBranches aanmaken via bitbucket, zie h5 van dit verslag voor meer toelichting.
18.OOSE-P5API-documentatieOpstellen van API-documentatie om traceerbaarheid tussen front- en backend te realiseren.
19.OOSE-P5Uitwerken componenten en functionaliteit en tests van werkplek toevoegen, verwijderen, wijzigen.
20.OOSE-P5CRUD verlof aanvragen en beoordelenUitwerken componenten en functionaliteit en tests van verlof aanvragen en beoordelen.
21.OOSE-P6BurndownchartDoor uren te loggen op de taken hebben we de burndownchart actueel gehouden. Zo maakt deze tool het inzichtelijk of de sprint volgens de geplande tijd verloopt.
22.OOSE-P6User stories aanmakenOpstellen van user stories op basis van de use cases.
23.OOSE-P6Pull requestsZie starr formulier §4.1 van dit verslag en de grafieken van Bitbucket
24.OOSE-P7§7.2.2.1 van dit verslagIk heb ervoor gezorgd dat er API-documentatie wordt gemaakt. Om misverstanden te voorkomen en overzicht te houden over alle endpoints en de bijhorende data.
25.OOSE-P7Testrapport tabellen frontendOpstellen van tabellen van alle unit tests, om inzicht te geven van alle test met uitkomsten.
26.OOSE-P7Unit tests declaraties Uitschrijven van alle unit tests die nodig zijn voor de declaraties.
27.OOSE-P7Unit tests gebruikersUitschrijven van alle unit tests die nodig zijn voor de gebruikers.
28.OOSE-P7Unit tests verlof Uitschrijven van alle unit tests die nodig zijn voor de verlofaanvragen.
29.OOSE-P8§7.1.1.1. van dit verslagToelichting hoe ik visualiseren heb toegepast om nieuwe stof beter tot me te kunnen nemen.
30.OOSE-P8Vue routerIk heb me verdiept in Vue router, een groepslid heeft de router toegevoegd en ik wist niet hoe de router werkt. Nadat ik me heb verdiept hierin heb ik pagina's toegevoegd om navigeerbaarheid toe te voegen aan de website.
31.OOSE-P8Front end unit tests met JestTijdens de course DEA heb ik geleerd hoe ik tests schrijf voor de backend. Voor het front end ben ik het Jest framework gaan leren. Hier heb ik geleerd hoe ik data fetches kan mocken.
32.OOSE-P8Functionaliteit VueIk wist niet hoe ik data kon doorgeven tussen componenten. Hiervoor ben ik gaan zoeken in de documentatie met als resultaat dat het mogelijk is met $emit functionaliteit. Het eerste onderdeel waar ik mee ben gaan expirmenteren is het component dat het gekozen werkpleksoort doorgeeft aan het parent component.