Projectverslag
Individueel projectverslag_ OOSE-project – HR Portaal JDI |
Thijmen Schoonbeek
10 juni 2022
...
Na het tussentijdse verslag heb ik als feedback gekregen dat ik mijn beoordeling meetbaar moet maken. Om dit te realiseren zal ik het document ‘Toelichting op het PvA’ (Toelichting op het PvA, z.d.) gebruiken, en de criteria vergelijken met ons product (de tabelvorm is geïnspireerd door de aanpak van Connor, dit lijkt mij een goede methode om meetbaar inzicht in mijn beoordeling te geven).
Criterium | Beoordeling | Toelichting |
Inleiding | 7.5 | De inleiding is uitgebreid beschreven en bevat;
- Doel van het document - Korte introductie van de opdracht - Leeswijzer Ook wordt belangrijke informatie genoemt zoals de organisatiestructuur van JDI. Dit is namelijk erg van belang om de rollen binnen het HR Portaal goed te kunnen modeleren. |
Achtergrond van het project | 6.5 | In principe bevat het wel de onderdelen uit het eerdergenoemde document. Echter, bij nader inzien is het een heel kort onderdeel en had er bijvoorbeeld meer toegelicht kunnen worden welke belangen er spelen bij het HR Portaal en waarom het belangrijk is voor JDI om over te stappen op een digitale oplossing. |
Doelstelling, opdracht en op te leveren resultaten voor het bedrijf en school | 8 | Over dit onderdeel ben ik heel tevreden. Alle kopjes zijn in voldoende detail uitgewerkt op basis van de toelichting op het PvA, en aan het einde is een duidelijke opsomming beschikbaar van de concrete resultaten die we als team moeten opleveren. |
Projectgrenzen | 7 | Dit onderdeel was tussentijds nog niet zo goed, omdat het een heel negatief beeld gaf van onze tijdsbesteding. Inmiddels is dit verholpen doordat onze werkuren bovenaan zijn gezet, en de tekst een stuk positiever zal lezen voor de opdrachtgever. Ook is het mooi opgesplitst in een stukje organisatie, en een stuk over de inhoudelijke grenzen. |
Randvoorwaarden | 8.5 | Duidelijke randvoorwaarden. Het gaat erom dat onze behoeftes voor een goede projectuitvoering duidelijk zijn, en dit hoofdstuk geeft een overzichtelijke beschrijving zonder onnodige tekst. |
Op te leveren producten en kwaliteitseisen en uit te voeren activiteiten | 7.5 | Ook dit onderdeel was tussentijds nog niet zo SMART, maar is inmiddels een stuk duidelijker omschreven. Wat mij betreft is de tabelvorm een hele mooie manier om zowel voor het team als voor de opdrachtgever duidelijk te krijgen wat er gedaan zal worden in het project. |
Ontwikkelmethoden | 7 | Dit onderdeel was oorspronkelijk alleen de eerste alinea, maar nu er verdere toelichting bij is gekomen over de Scrum methodiek is het een ruime voldoende waard. |
Projectorganisatie en communicatie | 7.5 | Duidelijk in tabelvorm omschreven wie er bij het project betrokken zijn en wat ieders taak inhoud. Komt overeen met de beschrijving in de Toelichting op het PvA. |
Planning | 5 | Het geeft in hele grote lijnen wel weer wanneer belangrijke momenten binnen het project plaatsvinden, maar wat mij betreft is het te leeg en algemeen om echt nut te hebben. Zelf heb ik geen gebruik meer gemaakt van deze planning. |
Risico’s | 8 | Risico’s die van toepassing waren op het project mooi in tabelvorm omschreven. Lijkt mij helemaal goed. |
Al met al komt er voor het PvA een 7.3 uit voor mij.
...
Binnen dit project heb ik het Vue.js onderzoek geschreven. Dit zal dan ook het onderzoek zijn die ik ga beoordelen. Ik ben eerst op zoek gegaan naar een aantal meetbare criteria om mijn onderzoek op te beoordelen. Hiervoor heb ik een overzichtelijk document gevonden van de Universiteit van Utrecht (Schrijfwijzer Voor Moderne Talen: Onderzoeksverslag, 2020). Onderstaand heb ik per criteria een oordeel gegeven om tot een eindcijfer te komen.
Criterium | Beoordeling | Toelichting |
Inleiding | 7 | Mijn inleiding bevat een goede introductie van het onderzoek, en geeft ook aan waarom het onderzoek nodig is. Verbeterpunt is dat ik de onderzoeksvragen in een apart hoofdstuk heb gezet, die horen eigenlijk hier bij de inleiding te komen. |
Theoretisch kader | 6.5 | Ik heb de uitgangspunten en criteria van mijn onderzoek duidelijk omschreven. Wetenschappelijke theorie mist nog wel (dat komt ook omdat het onderwerp zelf al niet heel wetenschappelijk is). Eventueel hadden er meer professionele artikelen genoemt kunnen worden i.p.v. bijvoorbeeld de reddit link. |
Methode | 7.5 | Aanpak is helder beschreven in hoofdstuk 4.1 van het onderzoek. Zoals eerder benoemt zijn ook de criteria duidelijk aanwezig. |
Kern/resultaten | 6.5 | Per deelvraag zijn resultaten vastgelegd. Er is gebruik gemaakt van een vergelijkende tabel. Geen grafieken. Wel duidelijk de bronnen aangegeven, al had dit netter gekund in apa stijl. |
Conclusie | 6 | De conclusie geeft een duidelijke terugkoppeling naar de hoofdvraag. Wel vraag ik me terugkijkend op het onderzoek af of het vergelijkende onderzoek met andere front-end frameworks echt nut heeft gehad, omdat dit eigenlijk niet meer terugkomt in de hoofdvraag of de conclusie. |
Discussie | 1 | Discussie ontbreekt |
Al met al kom ik uit op een 5.8. Dit komt wel omdat ik de discussie niet mee heb genomen in mijn front-end framework onderzoek. Als ik de discussie buiten beschouwing laat komt er een nette 6.7 uit.
...
Voor de concrete beoordeling van het SRS zal ik gebruik maken van de criteria die aan het begin van het project in het Plan van Aanpak zijn vastgelegd.
Criterium | Beoordeling | Toelichting |
Introduction | 8 | Alle onderdelen zijn ingevuld, geeft een duidelijke introductie voor het SRS. |
Domain model | 5.5 | Ziet er erg chaotisch uit omdat het domein vaak veranderd is door het project heen. De glossary is wel een mooie toevoeging die het model verhelderd. |
Use case model | 7 | Geeft de use cases, en de verhoudingen met de actors duidelijk weer. |
Use case descriptions | 6 | Schrijfstijl is niet consistent. System sequence diagrammen bevatten nog steeds tekst als ‘popup’ terwijl dit niet de bedoeling is. Sommige tabellen zijn zo kort dat ik mij afvraag of de beschrijving echt iets toevoegd. |
Other functional requirements | 7 | Duidelijk maar wel heel kort. |
User stories | 8 | Goed wat mij betreft, deze user stories geven een goed beeld van wat het HR Portaal uiteindelijk moet kunnen. |
Non functional requirements | 7 | Mooi uitgebreid uitgewerkt, wel had de beschrijving bij een aantal requirements wat meer SMART gekund. |
User interface sketches | 9.5 | Heel goed, dit heeft erg geholpen door de loop van het project. Zeer uitgebreid uitgewerkt, met kleurkeuzes, layouts, etc. |
Alles bij elkaar kom ik voor het SRS uit op een 7.3.
...
Mijn beoordeling van het deployment diagram is gebasseerd op een externe bron waarin een duidelijke uitleg gegeven werd over het bouwen van deployment diagrams (Ugochi, 2021).
Criterium | Beoordeling | Toelichting |
Introduction | 7 | Duidelijke inleiding die voldoet aan de template kopjes. Wat mij betreft hadden we de definitions tabel later nog moeten aanvullen, om de nieuwe definitions toe te voegen. |
Architectural overview | 6.5 | Overview zelf zit goed in elkaar. Beschrijving had een stuk uitgebreider gekund. |
Deployment diagram | 8 | Ons diagram komt mooi overeen met de internetbron die ik geraadpleegd heb (Ugochi, 2021). Het bevat alle benodigde componenten (frontend, backend, database) en geeft wat mij betreft een duidelijk overzicht van de flow van ons HR Portaal. |
Subsystems | 5.5 | Op het moment van schrijven mist het front-end subsystem. De backend subsystem is in groot detail beschreven, met een zeer uitgebreide class diagram. |
Database design | 6 | De database ontwerpen bevatten alle benodigde velden, maar sommige tabellen hadden nog opgesplitst kunnen worden om dubbele informatie te voorkomen. De uitleg onder het diagram is wel heel uitgebreid. |
Uitwerking design decisions | 6.5 | Duidelijk uitgewerkt in tabellen. Het probleem hierbij was dat we dit pas aan het einde hebben vastgelegd en niet tijdens de brainstorm sessies in het project zelf. Dit betekend hoogstwaarschijnlijk dat er nog een stuk meer belangrijke beslissingen zijn genomen dan hier genoemd. |
Al met al kom ik voor het SDD uit op een 6.6.
...
Beoordeling criteria PvA
Criterium | Beoordeling | Toelichting |
100% geslaagde unittests | 8 | Zie figuur 1. Aan de hand van het commando ‘mvn test’ heb ik gevalideerd dat de tests slagen. |
Minimaal 80% unittest coverage
| 5.5 | Coverage voor de geschreven tests (alleen de services klasses zijn getest) is inderdaad 80%. Zelf vraag ik me wel af of alleen het testen van de services daadwerkelijk voldoende is geweest om alle vulnerabilities uit ons HR Portaal te verhelpen en om echt te bewijzen dat alles werkt zoals het moet werken. |
Code geschreven in Nederlands
| 5 | Heel inconsistent. Bijvoorbeeld ‘createDeclaraties’ is een combinatie van Engels en Nederlands. |
Traceable naar specifieke requirements en constraints
| 8 | Het is allemaal traceable gemaakt aan de hand van het test rapport. Dit rapport beoordeel ik ook nog in zijn geheel in hoofdstuk 2.7. |
Werkende build op Jenkins | 8 | De laatste Jenkins build werkt inderdaad. Zie figuur 2 voor details. |
Voor het eerste onderdeel, de beoordeling aan de hand van het PvA, komt er voor mij een 6.9 uit.
Figure 1: mvn test uitgevoerd, alle tests in de backend slagen
...
Beoordeling criteria externe bron (Unit Testing Best Practices, 2021)
Criterium | Beoordeling | Toelichting |
Tests Should Be Fast | 8 | Het bouwen en runnen van alle 91 tests duurde minder dan een halve minuut. |
Tests Should Be Simple
| 7.5 | Zeker het geval. Tests zijn opgedeeld in kleine onderdelen met maximaal 1 assertion aan het einde. |
Test Shouldn’t Duplicate Implementation Logic | 7.5 | We testen alleen voor het resultaat, zonder code over te nemen uit de implementatie. |
Tests Should Be Readable | 5.5 | Het arrange, act, assert patroon komt niet in alle tests duidelijk naar voren. De volgorde staat in de meeste tests goed, maar het is lastig te zien waar bijvoorbeeld het act onderdeel begint en het arrange deel ophoudt. |
Tests Should Be Deterministic | 7.5 | Klasses zijn gemocked en er is gezorgd dat testen waar dan ook altijd hetzelfde resultaat geven. Dit houdt bijvoorbeeld in dat onze backend tests niet afhankelijk zijn van de inhoud van de database. Dit is verder gevalideerd met de sonarqube tooling. |
Make Sure They’re Part of the Build Process | 7.5 | Na iedere nieuwe build op de Jenkins kregen we ook automatisch een rapport terug of de tests nog steeds goed gaan. |
Distinguish Between The Many Types of Test Doubles and Use Them Appropriately | 7 | Correct toegepast, bijvoorbeeld door gebruik te maken van mocks, en when().thenReturn commandos. |
Adopt a Sound Naming Convention for Your Tests | 5 | Eigenlijk geen naamgevingsstandaard voor opgesteld, waardoor tests veelal verschillende naamgeving hebben. Ook loopt Nederlands en Engels door elkaar. |
Don’t Couple Your Tests With Implementation Details | 7.5 | Iedere test gaat maximaal over een paar methodes. Ten eerste om afhankelijke methodes te mocken en vervolgens om het resultaat van de target-methode te verkrijgen. Dit zijn implementation details die essentieel zijn voor de unit tests. |
Al met al komt er voor mijn beoordeling aan de hand van de externe bron een 7.0 uit.
...
Ik zal het deelproduct code beoordelen aan de hand van de 7 attributen van goede code (Tikayatray, 2022).
Criterium | Beoordeling | Toelichting |
The Code Must Be Readable
| 7.5 | Ik heb gezorgd dat mijn code goed gestructureerd is en dat regels niet te lang zijn. Ik heb over de naamgeving nagedacht zodat uit de variabele en functienamen al is af te lezen wat de code doet. Als een functie te lang werd, in dit geval bijvoorbeeld het ophalen van het werkplekoverzicht, heb ik dit opgedeeld in losse, kortere, functies. |
The Code Must Be Scalable
| 7 | Ik heb nergens magic numbers of vaste waardes gebruikt. Wel heb ik bij de ontwikkeling van mijn features ongeveer 20 mensen aangehouden, omdat dit al bekend was vanuit de opdracht. |
The Code Must Be Testable
| 7.5 | Door mijn code op te delen in losse functies, en op te splitsen in lagen, is het zeer goed testbaar. |
The Code Does What Is Asked For
| 6 | De code haalt inderdaad alle gegevens op die in de front-end nodig zijn voor het werkplek overzicht. Wel moest Tobias de resultaten nog een beetje omvormen in de front-end zodat het beter aansloot op de tabel vormgeving. Dit had ook in de backend gekund, zodat Tobias het niet meer hoefde te doen. |
The Code Fails Gracefully
| 7.5 | Duidelijke http status codes gebruikt, en nederlandse error messages teruggegeven. |
The Code Is Easy to Extend
| 6.5 | De meeste code voor het ophalen van het werkplekoverzicht is uitbreidbaar, met uitzondering van de opbouw van een week. Er is custom code geschreven om de eerste datum die wordt opgehaald op de maandag te laten vallen, dus als er later bijvoorbeeld gekozen wordt om het overzicht vanaf de zondag te laten beginnen zal dit nog een beetje moeite kosten om om te schrijven. |
The Code Is Reusable | 5 | De code voor het werkplek overzicht en de functies die ik hiervoor heb geschreven worden nergens anders gebruikt. |
Al met al kom ik voor het onderdeel code uit op een 6.7.
...
Om het testrapport zelf te beoordelen zal ik gebruik van de (magere) criteria die in het Plan van Aanpak staan:
Criterium | Beoordeling | Toelichting |
Bevat alle unittests
| 8 | Het testrapport geeft inderdaad inzicht in alle unittests. |
Bevat zowel de verwachte resultaten als de daadwerkelijke resultaten van de unittests
| 8 | Het testrapport is opgedeeld in duidelijke tabellen die inzicht geven in de verwachting, het daadwerkelijke resultaat, en of de tests geslaagd zijn. |
Bevat integratie testen | 8 | Er zijn meerdere integratie testen aanwezig die de flow van het hele systeem (dus over zowel frontend, backend en database) testen. |
Opmerking bij de bovenstaande tabel; oorspronkelijk waren alleen de bovenste 2 criteria in het PvA genoemd, maar ik vind de integratie testen ook een belangrijk onderdeel om mee te nemen in de beoordeling.
...
Om het eindproduct te beoordelen zal ik terugkijken op de beoordeling van alle deelproducten bij elkaar. Voordat ik dit doe, zal ik eerst een beoordeling opstellen van de User Stories uit het SRS, omdat deze stories een goed beeld geven van de gewenste functionaliteit.
Criterium | Beoordeling | Toelichting |
Als werkgever wil ik dat werknemers kunnen aangeven op welke flexwerkplek bezet wordt, zodat er een overzicht is van beschikbare werkplekken. | 8 | Dit is mogelijk, via een simpele knop in het werkplek overzicht. |
Als werknemer wil ik de mogelijkheid om reiskosten te declareren, zodat ik een reiskostenvergoeding krijg. | 5.5 | Dit is mogelijk, maar het werkt niet volledig. Bijvoorbeeld het declareren van reiskosten samen met een bijlage is niet volledig geïmplementeerd maar alleen in de backend. |
Als werknemer wil ik verlof aan vragen zodat ik vrije dagen kan opnemen (op een digitale manier). | 8 | Dit is mogelijk via een simpele popup. |
Als werkgever wil ik de optie hebben om een verlof verzoek van een werknemer goed/af te keuren. | 8 | Dit kan door middel van een knop in het beheerders portaal, en er kan ook een reden worden meegegeven. |
Als werkgever wil ik een Slack koppeling zodat ik werknemers een bericht met goed/afkeuring kan sturen voor het aangevraagde verlof. | 1 | Niet geïmplementeerd |
Als zowel werkgever als werknemer wil ik een overzicht hebben van alle werkplekken met alle werknemers die zich daarop hebben ingeschreven. | 8 | Dit is gelijk als je het HR Portaal opent zichtbaar. |
Als werkgever wil ik de optie hebben om werknemers te beheren zodat ik nieuwe werknemers kan aannemen, gegevens kan veranderen of oude werknemers kan verwijderen. | 6.5 | Het is inderdaad mogelijk voor beheerders om de werknemers accounts te beheren. Wel waren er nog wat issues met het verwijderen van accounts, omdat bijvoorbeeld het probleem kan ontstaan dat er geen beheerdersaccounts over zijn, waardoor de accounts niet meer gemanaged kunnen worden. |
Als werkgever wil ik de optie hebben werkplekken te beheren zodat ik nieuwe werplekken kan toevoegen, gegevens kan veranderen of oude kan verwijderen. | 8 | Werkplekken kunnen inderdaad beheert worden. |
Al met al kom ik terugkijkend op de originele user stories uit op een 6.6.
...
Verder heb ik hierbij voor het 'design decisions' onderdeel elke beslissing toegelicht als volgt:
Decision | Description |
Alternatives | Het alternatief was om de gebruiker niet van een keuze te voorzien, en bijvoorbeeld altijd de afstand door het systeem te laten berekenen. |
Arguments | Er is besloten om beide methodes te ondersteunen, omdat de automatische berekening gebruikersvriendelijk en betrouwbaar is. Aan de andere kant was in communicatie van de opdrachtgever naar voren gekomen dat ook het declareren aan de hand van kilometers gewenst is. Daarom is gekozen om het allebei te implementeren. |
Decision | Er is besloten om beide methodes te ondersteunen, afhankelijk van het reistype. Zo wordt een OV reis aan de hand van een afstand gedeclareerd, en voor een reis tussen werklocaties kan door de werknemer gekozen worden of hij/zij de afstand wil declareren, of de locaties. |
Problem/Issue | Een reis kan worden gedeclareerd met twee locaties, waarbij de afstand door het systeem wordt berekend. Het kan ook worden gedeclareerd met de kilometers, en dan hoeft er niks te worden berekend. |
Bij deze onderdelen (de sequence diagrammen en de design decisions) is het grootste verbeterpunt de volledigheid. Momenteel zijn er maar 4 sequence diagrammen aanwezig, en slechts een deel van de beslissingen is vastgelegd. Dit komt voornamelijk doordat we pas aan het einde de documentatie op orde zijn gaan maken, terwijl de meeste grote beslissingen toen al eerder genomen waren. Ook hadden we sub-system onderdeel in de SDD eerst verkeerd begrepen, waardoor we niet het hele backend als 1 sub-system hebben behandeld. Omdat dit heel laat in het project nog verbeterd moest worden hebben we gekozen om simpelweg de bestaande sequence diagrammen over te nemen en samen te voegen in het backend onderdeel.
...
In deze bijlage vindt u een factsheet die mijn competenties aantoont aan de hand van voorbeelden. De OOSE-competenties zijn als volgt:
OOSE P-01. De student kan een project uitvoeren op basis van Scrum en een plan van aanpak en hierop zowel op individueel als projectniveau evalueren en reflecteren.
OOSE P-02. De student maakt een analyse van de eisen en wensen voor de software van een systeem, en documenteert deze in een Software Requirements Specification (SRS)
OOSE P-03. De student voert een kwalitatief en kwantitatief onderzoek op een systeem uit en levert hierover een onderzoeksrapport op.
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 Software Design Specification (SDD)
OOSE P-05. De student implementeert een gedistribueerd systeem, evalueert het ontwerp en de realisatie daarvan en zorgt voor traceerbaarheid daartussen en naar de functionele en niet-functionele eisen.
OOSE P-06. De student maakt gebruik van de aangereikte ontwikkeltools om het project te organiseren en bij te sturen en ondersteunt de leden van het ontwikkelteam bij hun taakuitoefening.
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.
OOSE P-08. De student kan zich zelfstandig verder verdiepen in de beroepstaak.
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Opmerking bij bovenstaand factsheet; ik heb de facts voor competentie 3 opgesplitst in de hoofdstukken van het Vue.js onderzoek, omdat het anders niet aan de 3-5 facts zou voldoen. Ik heb het hele Vue.js onderzoek geschreven.
...