...
- Dont Repeat Yourself (Karanth, 2016) Dit betekent dat het de bedoeling is om geen dubbele code te schrijven. Door dit principe aan te houden wordt de leesbaarheid, testbaarheid en herbruikbaarheid van de code verhoogt.
- Clean Code (Summary of “Clean Code” by Robert C. Martin, z.d.) Dit is een boek geschreven door Robert C. Martin die meerdere software design principes heeft bedacht (https://en.wikipedia.org/wiki/Robert_C._MartinWikipedia contributors, 2022) door de principes aan te houden die zijn omschreven in zijn boek zou iedereen uit het team de code moeten begrijpen (https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29Summary of “Clean Code” by Robert C. Martin, z.d.) "Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability."
...
Het principe DRY waarborg ik door de v-for functionaliteit van Vue toe te passen. Hierdoor wordt er voor iedere werkplek de soort automatisch weergegeven. Als ik deze functionaliteit niet zou gebruiken zou ik handmatig een lijst moeten schrijven van alle werkplaats soorten(FIGUUR).
De code voldoet aan de volgende clean code principes: "Be consistent, If you do something a certain way, do all similar things in the same way", "use searchable names", "Functions do one thing", "Don't comment out code. Just remove".
...
| Criteria | Cijfer | Toelichting |
|---|---|---|
| Architecturaal overzicht | 6 | Overzicht geeft de architectuur weer, voor een hoger raad ik aan om de logo's te gebruiken van de te software e.d. omschrijvingen van de drie systemen mogen uitgebreider. |
| Deployment diagram | 8 | Het deployment diagram voldoet aan de volgende omschrijving (https://creately.com/blog/diagrams/deployment-diagram-tutorial/V.A.P.B.A.A, 2021)Er is terug te zien welke devices, servers en verbindingsprotocollen er nodig zijn. Het diagram komt overeen met de omgevingen waar het zich in afspeelt. |
| Sub-systemen | 6 | Er is een omschrijving bij ieder subsysteem aanwezig, voor de database is iedere kolom toegelicht. |
| Database ontwerp | 5,5 | Alle data die in het domein thuis horen staan in de database. In het ISE-semester is er aangeleerd om verwoordingen op te stellen en deze met de opdrachtgever te bespreken. Dit is niet gedaan en zijn er op eigen inzicht tabellen aangemaakt. Hierdoor bevatten tabellen meer data dan nodig. Zo staat er in de werknemerstabel welke rechten de werknemer heeft. De rechten horen los van elkaar in aparte tabellen te staan. Wat resulteert dat de database in de tweede normaalvorm staat (https://nl.wikipedia.org/wiki/Databasenormalisatie) |
| Ontwerpbeslissingen | 7,5 | Beslissingen zijn opgebouwd op basis van een probleem, daarop is er voor iedere beslissing een oplossing gegeven met onderbouwing. Enkele beslissingen bevatten alternatieve oplossingen. |
| Commentaar verwerken | 8 | Al het commentaar verwerkt na de tussentijdse feedback. |
| Eindcijfer deelproduct | 6,8 |
...
| Criteria | Cijfer | Toelichting |
|---|---|---|
| Alle gemaakte test slagen voor 100% | 8 | Alle tests slagen. Geen verdere toelichting. |
| De test coverage is hoger dan 80% van de code waar het nodig is om te testen | 6 | De 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 waarde | 6 | Ik heb de tests voor de http requests uitgeschreven. Er zijn tests die alleen kijken http requests worden geaccepteerd. |
| Test Driven Development toegepast | 4 | Tests driven development niet toegepast. Ben pas begonnen met testen nadat ik Vue ben gaan beheersen. |
| Arrange-Act-Assert pattern (https://betterprogramming.pub/clean-code-with-unit-tests-5f28020828a5Hawkins, 2022) | 6 | Er wordt een soortgelijk patroon toegepast waar een mock wordt voorbereid en daarna wordt vergeleken of de uitkomsten overeenkomen. |
| Evaluate a single concept per test (https://betterprogramming.pub/clean-code-with-unit-tests-5f28020828a5Hawkins, 2022) | 7 | Per test wordt een onderdeel per functie getest |
| Er is maximaal 1 assertion per test (Summary of “Clean Code” by Robert C. Martin, z.d.) | 8 | Iedere test bevat maximaal een assertion. |
| Eindcijfer deelproduct | 6,2 |
...
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(https://nl.indeed.com/personeel/functiebeschrijving/kwaliteitsmanagerFunctieomschrijving 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 ... 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 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 (https://www.icm.nl/extra/5-conflictstijlen-thomas-kilmann-omgaan-conflicten/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 (https://www.ag5.com/nl/samenwerken-binnen-een-team-tips/) 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.
...
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 (https://www.icm.nl/extra/5-conflictstijlen-thomas-kilmann-omgaan-conflicten/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 mogelijk discussie vermeden. Ik was er bang voor dat ik bij de stijl doordrukken een discussie zou ontstaan doordat de andere groepsgenoten aangaven dat, ze over dit onderwerp meermaals 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.
(https://www.icm.nl/extra/5-conflictstijlen-thomas-kilmann-omgaan-conflicten/Vogelzang, 2022)
Actie 2:
Als tweede actie ga ik voorstellen om ontwerpdocumenten op te stellen als er meerdere groepsleden aan een deelproduct werken. Dit ga ik doen aan het begin van een sprint als de taken worden vastgesteld of als ik met een ander persoon ga samenwerken. De documenten gaan dienen als schakel om ervoor te zorgen dat er geen aannames gemaakt worden, en daarnaast behouden we op deze manier overzicht. Ik ga voorstellen om een kwartier in overleg te gaan over de implementaties, en daarna een kwartier gezamenlijk documentatie opstellen om alle implentatie-afspraken vast te leggen.
...
Verder heb ik deze periode als plezierig ervaren, er heerste een fijne sfeer in de groep. We hebben iedere dag een gewandeld naar Coop in de pauze, 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 z'n alle af te schakelen.
Literatuurlijst
...
9 tips voor succesvol samenwerken binnen een team. (
...
2020,
...
6 augustus).
...
AG5. Geraadpleegd op
...
9 juni 2022, van https://
...
...
...
...
...
...
Functieomschrijving voor Kwaliteitsmanager | Indeed. (z.d.). indeed. Geraadpleegd op 7 juni
...
2022, van https://
...
...
...
com/personeel/functiebeschrijving/kwaliteitsmanager
Hawkins, T. (2022, 7 januari). Clean Code With Unit Tests - Better Programming. Medium. Geraadpleegd op 8 juni 2022, van https://
...
betterprogramming.pub/clean-code-with-unit-tests-5f28020828a5
Karanth, D. (2016, 13 april). Is Your Code DRY or WET? Dzone.Com. Geraadpleegd op 11 mei 2022, van
...
...
...
...
articles/is-your-code-dry-or-wet
Kiefmann, G. (2019, 26 februari). Voorkom miscommunicatie. Coaching Aanzet. Geraadpleegd op 11 mei 2022, van https:/
...
/www.coachingaanzet.nl/voorkom-miscommunicatie/
morresMarketing. (2018, 7 mei). Waarom visualiseren? IRISZ. Geraadpleegd op 11 mei 2022, van https://www.irisz-onderwijsadvies.nl/waarom-visualiseren/
Overzicht van de traditionele gedragscompetenties. (z.d.). van osch. Geraadpleegd op 11 mei 2022, van http://www.van-osch.com/lipoweb/opr0.htm
Processen visualiseren in Process Advisor - Power Automate. (2022, 11 maart). Microsoft Docs. Geraadpleegd op 11 mei 2022, van https://docs.microsoft.com/nl-nl/power-automate/process-advisor-visualize
Summary of “Clean code” by Robert C. Martin. (z.d.). Gist. Geraadpleegd op 11 mei 2022, van https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29
Telvak, R. (2019, 3 mei). A Lite Checklist for UI (User Interface) Testing. Lvivity. Geraadpleegd op 11 mei 2022, van https://lvivity.com/checklist-for-ui-testing
V.A.P.B.A.A. (2021, 27 september). The Easy Guide to UML Deployment Diagrams. Creately Blog. Geraadpleegd op 8 juni 2022, van https://creately.com/blog/diagrams/deployment-diagram-tutorial/
Vogelzang, F. (2022, 22 april). De 5 conflictstijlen van Thomas-Kilmann: hoe ga jij met conflicten om? ICM opleidingen & trainingen. Geraadpleegd op 5 juni 2022, van https://
...
...
...
nl/extra/5-conflictstijlen-thomas-kilmann-omgaan-conflicten/
Wikipedia contributors. (2022, 7 maart). Robert C. Martin. Wikipedia. Geraadpleegd op 5 juni
...
2022, van https://
...
en.wikipedia.org/wiki/Robert_C._Martin
Wikipedia-bijdragers. (2021, 14 januari). Miscommunicatie. Wikipedia. Geraadpleegd op 11 mei 2022, van https://nl.wikipedia.org/wiki/Miscommunicatie
...
Factsheet
| Nummer | Competentie | Link naar het product (JIRA taak) | Beschrijving eigen bijdrage |
|---|---|---|---|
1. | OOSE-P1 | H4 van dit verslag | Opstellen van een gespreksagenda om ervoor te zorgen dat de opdrachtgever weet wat wij van hem verwachten. |
2. | OOSE-P1 | H5 van dit verslag | Reflectie op mijn rol als kwaliteitsmanager met hierin benoemd wat er goed ging en welke verbeterpunten er zijn. |
| 3. | OOSE-P1 | Doelstelling Plan van aanpak | Uitschrijven van de doelstelling in het plan van aanpak. |
| 4. | OOSE-P1 | Plan van aanpak | 14 comments ten behoeve van kwaliteitsverbetering. |
| 5. | OOSE-P1 | Projectgrenzen Plan van aanpak | Uitschrijven van de projectgrenzen in het plan van aanpak. |
| 6. | OOSE-P2 | Use case model | Opstellen van het use case model. |
| 7. | OOSE-P2 | UC: invullen werkplekschema | Uitwerken fully dressed versie van deze use case. |
| 8. | OOSE-P2 | UC: aanvragen verlof | Uitwerken fully dressed versie van deze use case. |
| 9. | OOSE-P2 | Software Requirements Specification | 41 comments ten behoeve van kwaliteitsverbetering. |
| 10. | OOSE-P3 | Google Distance Matrix API Onderzoek | meerdere comments ten behoeve van kwaliteitsverbetering. |
| 11. | OOSE-P3 | Database onderzoek | 12 comments ten behoeve van kwaliteitsverbetering. |
| 12. | OOSE-P3 | Database onderzoek | Onderzoek uitbreiden met hoofdvraag en deelvragen en aansluitende conclussie met correcte APA bronvermelding. |
| 13. | OOSE-P4 | Software Design Description | Ontwerpbeslissingen documenteren front end. |
| 14. | OOSE-P4 | Software Design Description | SOLID en GRASP toelichten sequence diagrammen |
| 15. | OOSE-P4 | Software Design Description | Design front end subsystem uitschrijven |
| 16. | OOSE-P5 | user strories | Helpen met het opstellen van user stories op basis van de use cases. |
| 17. | OOSE-P5 | Bitbucket branches | Branches aanmaken via bitbucket, zie h5 van dit verslag voor meer toelichting. |
| 18. | OOSE-P5 | API documentatie | Opstellen van API documentatie om traceerbaarheid tussen front- en backend te realiseren. |
| 19. | OOSE-P5 | Uitwerken componenten en functionaliteit en tests van werkplek toevoegen, verwijderen, wijzigen. | |
| 20. | OOSE-P5 | CRUD verlof aanvragen en beoordelen | Uitwerken componenten en functionaliteit en tests van verlof aanvragen en beoordelen. |
| 21. | OOSE-P6 | Burndownchart | Door 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-P6 | User stories aanmaken | Opstellen van user stories op basis van de use cases. |
| 23. | OOSE-P6 | Pull requests | Zie starr formulier §4.1 van dit verslag en de grafieken van Bitbucket |
| 24. | OOSE-P7 | §7.2.2.1 van dit verslag | Ik 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-P7 | Testrapport tabellen frontend | Opstellen van tabellen van alle unit tests, om inzicht te geven van alle test met uitkomsten. |
| 26. | OOSE-P7 | Unit tests declaraties | Uitschrijven van alle unit tests die nodig zijn voor de declaraties. |
| 27. | OOSE-P7 | Unit tests gebruikers | Uitschrijven van alle unit tests die nodig zijn voor de gebruikers. |
| 28. | OOSE-P7 | Unit tests verlof | Uitschrijven van alle unit tests die nodig zijn voor de verlofaanvragen. |
| 29. | OOSE-P8 | §7.1.1.1. van dit verslag | Toelichting hoe ik visualiseren heb toegepast om nieuwe stof beter tot me te kunnen nemen. |
| 30. | OOSE-P8 | Vue router | Ik 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-P8 | Front end unit tests met Jest | Tijdens de course DEA heb ik geleerd hoe ik tests schrijf voor de backend. Voor de front end ben ik het Jest framework gaan leren. Hier heb ik geleerd hoe ik data fetches kan mocken. |
| 32. | OOSE-P8 | Functionaliteit Vue | Ik 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. |