Projectverslag
Het projectverslag moet je zien als een tentamen dat je succesvol gemaakt hebt: een toets waarmee jij laat zien wat je van het project geleerd en begrepen hebt. Het verslag geeft een afdoende beeld van het werk dat je gedaan hebt in het project (in termen van kwantiteit en kwaliteit), en maakt je deskundigheid ten aanzien van het project (en in de verdiepende semesters: het profiel waarin je gaat afstuderen) voldoende inzichtelijk. Je maakt een selectie van hoogte- (of diepte)punten waarmee je je deskundigheid kunt tonen. Die beoordeel je kritisch, en zo laat je zien wat je geleerd en begrepen hebt. Het projectverslag is, (net als straks het afstudeer- en stageverslag) het startpunt van je individuele beoordeling.
Lees de projecthandleiding voor de concrete opdracht voor het porjectverslag dat je bij OOSE moet schrijven.
Een voldoende verslag:
- Bevat alle gevraagde onderdelen uit het nakijkmodel
- Is waarheidsgetrouw. Hiermee wordt bedoeld: in overeenstemming met waarnemingen van de betrokken docenten. Het gaat er dus om dat je recht doet aan jezelf (vergeet belangrijke dingen niet te melden, daarmee doe je jezelf te kort), maar ook dat je de zaken niet mooier maakt dan ze waren.
- Is op voldoende punten correct, en onderbouwd. Hiermee wordt bedoeld: je maakt correcte verwijzingen naar relevante bronnen, je maakt voldoende relevante verwijzingen naar eigen materiaal (per competentie 3-5 verwijzingen/links), én je tekst is inhoudelijk correct en logisch opgebouwd.
In de basissemesters zijn de volgende onderdelen opgenomen in het verslag:
1) Een inleiding met: |
|
2) Een onderbouwd oordeel over de kwaliteit van de geleverde deelproducten: |
|
3) Een onderbouwd oordeel over de kwaliteit van het eindproduct als geheel: |
|
4) Een evaluatie van de gehanteerde projectmethode: |
|
5) Een beschrijving van de rol(len) die je hebt gehad in het project waarin je inzichtelijk maakt: |
|
6) Een nadere toelichting op (zie projecthandleiding voor de competenties die in jouw semester moeten worden toegelicht) competenties waarin per competentie: |
|
7) Laat concreet zien hoe je gewerkt hebt aan je leerdoelen en hoe je gevorderd bent: |
|
8) Een conclusie die: |
|
9) De tekst voldoet aan de eisen zoals gesteld in de ICA-controlekaart en is maximaal 8 A4, of een vergelijkbare digitale hoeveelheid (dat is ca 4500 woorden, bijlagen niet meegerekend) |
10) Een bijlage, de factsheet, met daarin per competentie: (NB: dit is een van alle competenties, dus óók de links die je in het projectverslag hebt staan): |
|
Individueel projectverslag_ OOSE-project – HR Portaal JDI |
Thijmen Schoonbeek
11 mei 2022
OOSE-project groep Perlman
Opdrachtgever: JDI
Projectbegeleider: Jaap Papavoine
Professional skills begeleider: Sjir Schütt
Versie 1.0
1 Inleiding
In dit project zal ik binnen een team van 5 studenten een HR Portaal realiseren. Het portaal is voor een extern bedrijf. In ons geval is dit bedrijf JDI Smart Web applications. Er is ons gevraagd om het huidige systeem, wat vooral aan de hand van spreadsheats gaat, te optimaliseren met een online hr portaal. Op dit portaal kunnen werknemers en werkgevers inloggen om zaken zoals de werkplek registratie en de reiskosten declaraties te beheren.
Het doel van dit document is om mijn individuele bijdrage aan het OOSE-project te verantwoorden, maar ook om aan te geven wat mijn ervaringen waren binnen dit project en wat ik de volgende keer anders zou doen.
1.1 Inhoudelijke uitdagingen
Over het algemeen denk ik dat het project voor mij goed te doen zal zijn. Vooral omdat ik hiervoor al het i-project en het ISE project heb gehad. Ook zijn er door het project heen meerdere malen nutshell talks die voor mij zaken zoals sonarcube verduidelijken. Met de backend onderdelen heb ik al ervaring opgedaan tijdens de afgelopen periode, dus daar heb ik vertrouwen in. De front-end onderdelen zullen voor mij een stuk uitdagender zijn, omdat ik nog niet eerder met een framework zoals Vue.js heb gewerkt. Zelfs nadat ik twee dagen onderzoek gedaan had naar Vue en het vergeleek met andere frameworks zoals React, heb ik het nog steeds niet helemaal onder de knie.
1.2 Leerdoelen
Leerdoel 1: zelf initiatief nemen met plannen, en minder afwachtend te werk gaan.
Leerdoel 2: communicatie-skills verbeteren zodat het voor teamgenoten direct duidelijk is wat ze van mij kunnen verwachten, of wat ik aan hen vraag.
2 Oordeel kwaliteit geleverde producten
In dit hoofdstuk zal ik voor de deelproducten de kwaliteit beoordelen. Ik kijk in dit hoofdstuk dus terug op wat we als team hebben opgeleverd aan school en aan de opdrachtgever binnen JDI, en ik beoordeel of ik tevreden ben met het opgeleverde werk. Tegelijk laat ik aan de hand van deze beoordelingen zien dat ik over deze producten heb nagedacht en dat ik weet waar de sterke en zwakke punten van alle deelproducten binnen dit project liggen.
2.1 Deelproduct 1 - Plan van Aanpak
Het Plan van Aanpak is een essentieel onderdeel voor een succesvol project, omdat het Perlman ontwikkelteam hierin van tevoren vastlegt hoe we alle onderdelen binnen het project zullen aanpakken en wat we van elkaar en van de opdrachtgever verwachten.
Een groot feedbackpunt wat tijdens het assesment van het plan van aanpak naar voren kwam, was dat het nog niet genoeg op de opdrachtgever gericht is, maar meer op het ontwikkelteam. Zo kwam er duidelijk naar voren dat veel van onze tijd naar pauze, overleg en andere zaken gaat waardoor er minder tijd overblijft voor het echte programmeren. Hier moeten we zorgen dat het plan wat positiever overkomt, bijvoorbeeld door de overige activiteiten kort samen te vatten, in plaats van hier heel veel aandacht aan te besteden.
Voor de rest ben ik zelf heel tevreden met het plan. De eisen en grenzen die in het plan zijn gesteld zijn redelijk, en maken het binnen het team en richting de opdrachtgever duidelijk wat er van ons kan worden verwacht.
2.2 Deelproduct 2 – SRS
Op het moment dat ik dit schijf is de SRS nog niet helemaal af, er missen nog wat use case descriptions. Echter zal ik beoordelen wat er wel is. Om te beginnen ben ik tevreden over de volledigheid van het document (nogmaals, met uitzondering van de missende use case descriptions). Een groot voordeel van de verslaglegging in dit OOSE project voor mij was dat er in Confluence al een overzicht beschikbaar is van alle onderdelen die in onze documentatie worden verwacht. Zo bevat het SRS al alle hoofdstukken en subkopjes, en is het voor ons team eenvoudiger om hierover na te denken en de kopjes in te vullen. De algemene beschrijven en de actors zijn wat mij betreft duidelijk; werkgever en werknemer en verder hebben we ook de gebruikte technieken en operating systems onderbouwd. Zelf vond ik het nog niet heel logisch om het overzicht van de product functions al in de inleiding te hebben omdat deze pas een stuk later worden uitgewerkt, maar dit was al op deze manier voorgedaan. De inhoudt van het use case diagram is duidelijk, maar deze moet eventueel nog geupdatet worden. Ik ben momenteel bezig met de use case beschrijvingen en merk dat een deel hiervan verouderd is ten opzichte van het systeem wat we binnen het team hebben bedacht. Zo zijn er taken in de sprint die niet overeenkomen met een van de use cases, en ook zijn er use cases zoals ‘berekenen reisafstand’ die eigenlijk alleen door het systeem worden gedaan, waardoor ik niet zeker weet of ze in het schema thuishoren.
Wat betreft de non-functionele requirements, hiervoor heb ik internetbronnen geraadpleegd om inspiratie op te doen, omdat dit in mijn ogen vaak lastig is om concreet op te schrijven. Zo is het van belang dat de site makkelijk te leren en begrijpen is, maar dit is moeilijk om meetbaar te maken. Momenteel denk ik dat er voor de requirements nog wat aanpassingen nodig zullen zijn, maar ik ben wel tevreden met de volledigheid van de non functionele requirements.
Vervolgens hebben we de user stories ook uitgewerkt. Ik vind dit zelf heel handig werken omdat het makkelijk leesbaar is. Binnen de zes zinnen die we voor de user stories hebben geschreven wordt het snel duidelijk wat de scope is van het project, en wat de uiteindelijke eisen aan het hr portaal zullen zijn.
Zoals bovenaan genoemd missen er nog wat use case descriptions, maar de bestaande descriptions zijn wat mij betreft duidelijk. Ze geven een overzicht van de interactie tussen de werknemer/werkgever en het systeem aan de hand van logische stappen. Zelf heb ik hiervoor vooral de technieken gebruikt die we in de vorige periode hebben geleerd.
2.3 Deelproduct 3 – Werkplek overzicht
Ik heb tot nu toe aan een aantal verschillende onderdelen van het portaal gewerkt, maar aangezien het werkplekoverzicht een redelijk groot onderdeel is en ik hier het meeste heb geleerd zal ik hierop ingaan. Zelf heb ik voor het werkplek overzicht de backend code geschreven. Ik ben hier tevreden mee, omdat het goed aansluit op de frontend, en de benodigde functionaliteit bevat om gebruikers van het hr portaal van een plekkenoverzicht te voorzien. Ik heb voor dit onderdeel de structuur aangehouden die ons de vorige periode is aangeleerd, met resources, services, dto’s, dao’s, etc. Om het op deze manier netjes in lagen op te delen. Ook heb ik unit-tests geschreven om de backend voor het werkplek overzicht te testen. Dit zorgt ervoor dat we zeker weten dat de code doet wat hij moet doen.
Huidig is een verbeterpuntje bij dit onderdeel nog de documentatie. Tot nu toe ben ik veel bezig geweest met code schrijven en testen, maar niet zo zeer met de bijbehorende javadoc en uitleg. Ik zal even met het team moeten overleggen hoe we de documentatie willen aanpakken, en vervolgens de werkplek overzicht backend moeten uitbreiden om een duidelijk beeld te geven van de functionaliteit van mijn code.
3 Evaluatie projectmethode
Voor dit project gebruiken we de Scrum methode. Ten opzichte van de RUP methode vindt ik het hieraan fijn dat de beginfase wat korter is. Dit zorgt ervoor dat we na het plan van aanpak gelijk aan de slag konden. Het voordeel hiervan is dat het praktische werken duidelijk maakt waar voor mij de knelpunten zitten, en welke onderdelen mij juist goed afgaan. Ook is er voor het hele team meer tijd over om de tools te leren en de code te maken.
Ook vind ik het fijn aan scrum dat er aan aantal vaste momenten bestaan, zoals de retrospective en de sprint review. Dit zorgt ervoor dat we iedere sprint weten waar we aan toe zijn en ook naar het volgende moment kunnen toewerken. Verder geeft de retrospective een duidelijk beeld van hoe we de volgende sprint kunnen optimaliseren.
Ik heb in het plan van aanpak nog een stuk geschreven over de methode, zie hiervoor hoofdstuk 7; ontwikkelmethode.
Het enige wat soms onhandig is aan onze methode van werken, is dat taken soms te lang in review kunnen blijven hangen. Voor de veiligheid bestaat een systeem waarbij ieder onderdeel door twee teamleden wordt gereviewed. Op zich is dit een goed idee, maar het zorgt ervoor dat sommige onderdelen soms meer dan een week blijven hangen voordat ze in Done komen te staan. Een manier om dit op te lossen zou zijn om een duidelijk systeem in te voeren waarmee teamleden kunnen aangeven wanneer een nieuwe taak openstaat voor review, zodat hier meer prioriteit aan gegeven wordt.
4 Rollenbeschrijving
In het OOSE project is mijn hoofdrol de Planner. Ik moet ervoor zorgen dat het voor iedereen duidelijk is wat er wanneer af moet zijn en dat er voor iedere sprint realistische taken worden opgesteld.
Tot nu toe vind ik het wel een behoorlijke uitdaging om planner te zijn, omdat ik van mezelf niet zo goed ben in plannen. Aan de andere kant zorgt het er ook voor dat dit een goede ontwikkelkans is, die ik hopelijk ook kan meenemen naar volgende projecten.
Een uitdaging voor mij is om de taak van Planner goed op mij te nemen en niet per ongeluk uit handen te geven. Zo komt het bij het begin van een nieuwe sprint wel voor dat teamgenoten het plannen tijdens een gesprek een beetje overnemen. Dat is natuurlijk goed bedoelt, maar het beste zou zijn als ik het zelf onder de knie kan krijgen zodat ik de planningspoker efficiënt kan leiden, en de afspraken ook in de Jira kan opnemen.
5 Uitwerking competenties
In dit hoofdstuk zal ik mijn competenties in detail aantonen aan de hand van situatiebeschrijvingen en voorbeelden in het project.
OOSE P-03. De student voert een kwalitatief en kwantitatief onderzoek op een systeem uit en levert hierover een onderzoeksrapport op.
Vroeg in dit OOSE project heb ik mij gefocust op het schrijven van een onderzoek over het Vue.js front-end framework. Dit onderzoek staat ook op confluence onder het kopje 'Onderzoeken'. Om te beginnen heb ik voor mijzelf duidelijk gemaakt wat er in het onderzoek naar voren moest komen, en waar het onderzoek uiteindelijk voor dient. Een belangrijk onderdeel hiervan is het opstellen van de hoofdvraag, en de daarop volgende deelvragen. Vervolgens heb ik vooral aan de hand van externe bronnen de deelvragen beantwoord. Hierbij heb ik bijvoorbeeld vergelijkende onderzoeken geraadpleegd, wat blijkt uit deze afbeelding:
Terugkijkend op dit onderzoek denk ik niet dat het de 7 uur waard is geweest die ik erin heb gestopt. Aan het begin van het project was het eigenlijk al duidelijk dat Vue.js het front-end framework naar keuze zou worden. Aangezien het rapport voor een groot deel gaat over de criteria aan het front-end framework, en over de vergelijking met andere frameworks, is dit niet helemaal nodig geweest. Gelukkig is uit het onderzoek naar voren gekomen dat Vue ook echt past bij dit project. Hierbij kan het wel zo zijn dat, aangezien we al van plan waren om Vue te gebruiken, dit het onderzoek biased heeft gemaakt.
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)
Ik heb tot nu toe binnen het project twee onderdelen ontworpen die hierop van toepassing zijn. Ten eerste het architectuur overview:
Dit ontwerp geeft een high-level idee van de structuur van het hr portaal. Momenteel is het nog een redelijk eenvoudig ontwerp, en in de laatste sprint zullen hier nog dingen zoals de Slack oplossing aan worden toegevoegd. Ik heb mijn best gedaan om het ontwerp consistent en overzichtelijk te houden, bijvoorbeeld door het gebruik van de icoontjes die visueel weergeven wat ieder onderdeel betekend.
Ten tweede ben ik ook bezig geweest met het Sub Systeem B: declareren reiskosten. Aangezien dit onderdeel ook overeenkwam met mijn programmeertaken, heb ik het documentatie gedeelte ook op mij genomen. Hier is het sequence diagram dat weergeeft hoe een declaratie kan worden aangemaakt:
Verder heb ik hierbij voor het 'design decisions' onderdeel een 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. |
6 Conclusie
In dit document heb ik mijn bijdrage beschreven in het OOSE project. In deze tussentijdse versie missen nog een aantal onderdelen, zoals de beschrijving van mijn competenties. Ik zal dit oplossen in het eindverslag. Ik hoop dat dit document goed laat zien waar voor mij de uitdagingen liggen in het OOSE project, en waar ik juist goed aan heb kunnen werken. Aangezien mijn leerdoelen voor de projecten tot nu toe veelal hetzelfde zijn gebleven, zal ik ook tijdens dit project goed focussen op het verbeteren van mijn communicatie en mijn planningsvaardigheden.
Een groot voordeel van dit project ten opzichte van de twee projecten hiervoor, is dat het voor een echte opdrachtgever is. Voor mij werkt het motiverend om te zien dat Wim van JDI enthousiast is over de producten die we als team hebben gemaakt.
7 Bijlagen
7.1 Fact sheet
In deze bijlage vindt u een factsheet die mijn competenties aantoont aan de hand van voorbeelden. De ISE-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.
|
| ||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||
Tussentijds is de factsheet mij nog niet gelukt. Wel heb ik competenties uitgewerkt in hoofdstuk 5.
|
| ||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||
|
|
7.2 Leerdoelen
In deze bijlage vindt u een verdere toelichting bij mijn leerdoelen. Mijn leerdoelen zijn sinds het ISE project eigenlijk niet veranderd, want mijn grootste verbeterpunten zitten nog steeds in het plannen en communiceren.
8.2.1 Eerste leerdoel - Plannen
Ik wil in dit project beter plannen en minder afwachtend te werk gaan. Ik wil meer initiatief nemen om zelf iets te gaan doen, zonder op het team te wachten zodat zij mij vertellen wat ik moet gaan doen.
Aanleiding
In eerdere projecten was ik zeer afwachtend, wat betekend dat ik pas productief werd als anderen mij vertelden wat ik moest gaan doen. Dit zorgt voor een minder productieve houding en mijn bijdrage in het project lijdt hieronder.
Actiepunten
Zelf meedenken met de project-planning, is een belangrijke taak binnen mijn rol.
Begin van iedere dag een duidelijke lijst met dingen opstellen die ik die dag kan doen. Deze lijst moet voldoende punten bevatten om de rest van de dag productief bezig te kunnen zijn.
Mid-daily standup om te kijken waar ik (en de rest van het team) staan en waar we mee bezig kunnen.
Kijken naar welke dagdelen ik het meest productief kan werken.
Einddoel
Meer initiatief nemen en zelf actie ondernemen, zonder te wachten tot teamleden mij een taak geven.
8.2.2 Tweede leerdoel - Communiceren
Ik wil in dit project mijn ideeën en mijn mening duidelijk op de rest van het team overbrengen. Ik wil mijn communicatie-skills verbeteren zodat het voor teamgenoten direct duidelijk is wat ze van mij kunnen verwachten, of wat ik aan hen vraag.
Aanleiding
In het i-project van afgelopen schooljaar kon ik soms onduidelijk doen, waardoor het voor teamgenoten niet helder was waar ik mee bezig was of wat ik aan hun vroeg. Dit levert problemen op omdat het ten eerste inefficiënt is om meerdere keren dingen te moeten herhalen, en ten tweede kan het ervoor zorgen dat ik aan de verkeerde dingen ga werken.
Actiepunten
Ik wil rustig en helder praten.
Ik wil na mijn woord gedaan te hebben, nagaan of het ook duidelijk is overgekomen.
Ik moet beter voorbereiden op gesprekken, standups, etc.
Einddoel
Ik wil duidelijk communiceren en zorgen dat het bij overleg direct duidelijk is waar ik het over heb en wat anderen van mij kunnen verwachten. Als ik een vraag heb aan een teamgenoot, moet deze gelijk duidelijk zijn.
7.3 Bronnen
Onderwijsonline documenten. (z.d.). Onderwijsonline. Geraadpleegd op 11 mei 2022, van https://han.onderwijsonline.nl/elearning/lesson/4NoG0RvN
7.4 Logboek
Ik heb op confluence iedere dag bijgehouden wat ik die dag heb gedaan. Dit kunt u terugvinden onder Toetsing -> Teamlid 4 -> Logboek teamlid 4.