1. Inleiding

1.1 Opdracht

Wij hebben van het bedrijf JDI de opdracht gekregen om voor hen een HR-portaal te bouwen. Zelf gebruikte zij telkens excelsheets om veel dingen bij te houden zoals reiskostenvergoedingen en verlof. Zij wouden dit makkelijker maken door een groot deel ervan te automatiseren en het op een centraal punt te kunnen doen. In ons portaal zouden wij verschillende dingen opnemen zoals; het reserveren van een werkplek, reiskosten declaraties aan kunnen maken op basis van je thuis locatie en het kantoor of twee zelf ingevulde locaties, automatisch declaraties aanmaken voor mensen die die dag een plek gereserveerd hebben, verlof aanvragen kunnen doen en deze goedkeuren als je de juiste rechten hebt en wat algemene CRUD mogelijkheden voor het aanmaken, aanpassen en verwijderen van dingen zoals medewerkers, locaties en werkplekken.

1.2 Inhoudelijke uitdagingen

Voor mij is het een aardige tijd geleden dat ik heb geprogrameerd in de talen die we zouden gebruiken in dit project, als herkanser heb ik niet veel lessen gevolgt, dit was dus een beetje opfrissen weer. Verder is een grote uitdaging voor mij dit verslag schrijven en optijd afkrijgen, ik heb al meerdere malen het ISE en OOSE project gedaan en echter alleen vorig semester het ISE project ook daadwerkelijk afgerond.

1.3 Leerdoelen

Leerdoel 1: Duidelijker aangeven aan de groep waar ik aan werk.

Bij het vorige ISE-project werd er door de andere leden aangegeven dat het niet altijd duidelijk was waar ik aan werkte, dit kwam ook een deel doordat we veel vanuit huis werkte. In dit project wil ik dus duidelijker maken wat ik aan het doen ben op de dag.

Acties die ik ga ondernemen om dit te behalen:

• Elke dag bij de daily stand-up aanwezig zijn en duidelijk aangeven wat ik ga doen.
• In de middag na de pauze nog een keer laten weten wat ik de rest van de dag ga doen.
• Bij het online werken na de daily stand-up vragen of het duidelijk is wat ik ga doen.

Mijn leerdoel zal behaald zijn als ik gemiddeld minder dan 1x per week een vraag krijg over wat ik aan het doen ben (buiten de daily stand-up om natuurlijk).

Leerdoel 2: Optijd aanwezig zijn op locatie.

Bij de eerste sprint review was er een retrospective puntje naar voren gekomen, dit was minder te laat zijn. Dit was niet alleen op mij gericht maar meer een iedereen in de groep moet dit doen maar ik merkte van mezelf wel dat dit bij mij inderdaad wel regelmatig voor kwam. Door de bus die ik neem ben ik altijd of 5 minuten te laat of ik moet de bus een half uur eerder nemen, vandaar dat ik vaak net iets later aan kwam.

Acties die ik ga ondernemen om dit te behalen:

• De bus eerder pakken zodat ik altijd optijd ben.
• Als er iets is waardoor ik wat later ben, dit optijd en duidelijk aangeven.

Mijn leerdoel zal behaald zijn als ik gemiddeld minder dan 1x per week later kom dan de afgesproken tijd.

2. Deelproducten

2.1 PvA

Het Plan van Aanpak (PvA) dient duidelijke te maken wat het plan is voor de duur van het project en duidelijke regels opstellen voor zowel de groep als de opdrachtgever.

Hieronder een tabel met per kwaliteitseis een beoordeling en toelichting:

Tabel 1: kwaliteitsoordeel PvA

Ik vind dat de kwaliteit van het PvA goed is, alle belangrijke punten worden aangetikt en zijn van voldoende of hogere kwaliteit. Ook is het doel van het document behaald.

2.2 Onderzoeksverslag

Het onderzoek dient verdieping te tonen over de API en een conclusie te trekken die betrekking heeft tot het project. Het onderzoel dat ik zal beoordelen is het Google Distance Matrix API Onderzoek.

Hieronder een tabel met per kwaliteitseis een beoordeling en toelichting:

Tabel 2: kwaliteitsoordeel onderzoeksverslag

Ik vind dat de kwaliteit van het onderzoek dus goed is, alle belangrijke punten zijn aangetikt en zijn van voldoende of hogere kwaliteit. Ook is het doel van document behaald.

2.3 SRS

Het Software Requirements Specification (SRS) dient als een soort van plattegrond en plan voor het bouwen van de software, het moet duidelijk maken welke functionaliteit er wordt geimplementeerd en hoe het eruit zal gaan zien zonder te technish te worden.

Hieronder een tabel met per kwaliteitseis een beoordeling en toelichting:

Tabel 3: kwaliteitsoordeel SRS

Ik vind dat de kwaliteit van het SRS goed is, alle punten zijn aangetikt en zijn van voldoende of hogere kwaliteit. Ook is het doel van het document behaald.

2.4 SDD

Het Software Design Description (SDD) dient het te verduidelijken van het ontwerp van de softwarestructuur en alle sub systemen die deel uit maken van de applicatie.

Hieronder een tabel met per kwaliteitseis een beoordeling en toelichting:

Tabel 4: kwaliteitsoordeel SDD

Ik vind dat de kwaliteit van het onderzoek neutraal is, de onderdelen die erin zitten zijn goed uitgewerkt en voldoen aan de eisen, maar er ontbreekt nog een cruciaal onderdeel. Hierdoor is ook het doel niet helemaal behaald, het dient het ontwerp te verduidelijken en dat doet het ook voor de backend en de database maar niet over het geheel.

2.5 Unittests

De unittests dienen aan te tonen dat de geschreven code goed werkt en ook tijdens het project door blijft werken.

Hieronder een tabel met per kwaliteitseis een beoordeling en toelichting:

Tabel 5: kwaliteitsoordeel unittests

Ik vind dat de kwaliteit van de unittests goed is, alle unittests slagen, ze zijn allemaal nuttig en er is een line coverage van 85% over de onderdelen waar het toe doet.

2.6 Stuk code

De code dient als functionaliteit van de applicatie, het is een uitwerking van de use cases en/of non/other functional requirements. Het stukje code dat ik zal beoordelen is DeclaratieAuto.java.

Hieronder een tabel met per kwaliteitseis een beoordeling en toelichting:

Tabel 6: kwaliteitsoordeel stuk code

Ik vind dat de kwaliteit van de code voldoende is, als er gebruik gemaakt wordt van dependency injection zou het naar een goed gaan, de rest is namelijk wel meer dan voldoende.

2.7 Testrapport

Het Testrapport dient aan te tonen hoe het testen verlopen is en of er ergens nog problemen zijn.

Hieronder een tabel met per kwaliteitseis een beoordeling en toelichting:

Tabel 7: kwaliteitsoordeel testrapport

Ik vind dat de kwaliteit van het testrapport nog net voldoende is, voor de frontend ontbreken wel de unittests maar de frontend is niet helemaal niet getest, deze wordt ook meegenomen in de flow tests. Echter is het wel een belangrijk deel dat ontbreekt.

3. Eindproduct

Het doel van het eindproduct was de werkzaamheden van JDI versimpelen door te automatiseren wat kan en er een centraal portaal voor te maken waardoor de excel sheets en persoonlijke aanvragen niet meer nodig zijn.

Hieronder een tabel met per kwaliteitseis een beoordeling en toelichting:

Tabel 8: kwaliteitsoordeel eindproduct

Ik vind dat de kwaliteit van het eindproduct erg goed is, alle bovengenoemde punten zijn voldoende of beter. Alle wensen van de opdrachtgever zijn behandeld op een slack koppeling toevoegen na, hier had de opdrachtgever zelf al vroeg over aangegeven dat dit een heel erg optioneel deel was en meer een extra als er tijd zou zijn. Verder is de enige bug die functionaliteit breek die van het verlof keuren, deze kan echter heel simpel opgelost worden als hier wat tijd voor zou zijn.

4. Projectmethode

De projectmethode die wij hanteerde was Scrum, Scrum is een agile softwareontwikkelmethode, dat wil zeggen dat er in sprints gewerkt zal worden. Bij Scrum wordt er ook incrementeel gewerkt, dit betekendt dat elke sprint een onderdeel volledig wordt uitgewerkt met documentatie, tests en functionaliteit. Hierdoor krijg je bij elke sprint een opleverbaar product dat elke sprint groeit. Per sprint zijn er een paar use cases gepakt en uitgewerkt, zo heeft de opdrachtgever ook een duidelijk beeld van wat ze die sprint kunnen verwachten. Ook maakte we gebruik van bepaalde Scrum ceremonies zoals; de daily standup, deze deden we elke dag om 9:30, soms is er ook gekozen in de middag nog een kleine standup te doen. Ook hebben we gebruik gemaakt van sprint planningen om de volgende sprint in te delen op basis van de tijden die uit ons planningspoker kwam. Verder hebben we ook een sprint retrospective gehouden na elke sprint om terug te kijken naar wat goed ging, wat beter kon en waar we mee moesten stoppen. Tot slot hebben we ook nog gebruik gemaakt van sprint reviews waarbij we de opdrachtgever lieten zien wat we die sprint af hebben gekregen, wat niet af was en wat we de volgende sprint wouden gaan doen.

Ik vind wij dat dit project goed gebruik hebben gemaakt van wat Scrum ons aanbood, de daily standups waren handig om iedereen op een lijn te krijgen over wat iedereen aan het doen was. De sprint planningen zorgde ervoor dat de sprints goed ingepland konden worden, het kwam natuurlijk wel voor dat we soms net iets te veel taken hadden opgenomen maar het is ook lastig schatten. De sprint retrospectives hielpen erg om te leren van wat goed ging en wat niet zodat we dit de volgende sprint konden aanpassen en hierdoor beter konden werken. Tot slot de sprint reviews waren goed om aan de opdrachtgever aan te tonen wat er gedaan was en wat het plan was voor de volgende sprint. Doordat het incrementeel was hadden we ook elke sprint iets om te laten zien aan de opdrachtgever, dat was voor hun ook een stuk fijner is dan hoe het werkte bij de RUP-methode van ISE-P.

5. Rol

Tijdens het project had ik samen met Connor de rol kwaliteitsmanager dit is uiteindelijk erg goed uitgekomen aangezien ik vooral aan de backend en database werkte en Connor aan de frontend, zo had elk sub systeem zijn eigen kwaliteitsmanager. Tijdens het project heb ik mij buiten mijn eigen bijdrage aan het programeren en documenteren ook beziggehouden met het zorgen dat alles van goede kwaliteit was. Ik heb veel documenten doorgelopen om deze te controleren en heb ook aardig wat pull requests gereviewed, ik kan natuurlijk niet alles nakijken dus als iemand anders dit deed zouden zij zich houden aan de kwaliteitseisen en definition of done die ik heb geschreven en zijn opgenomen in het PvA. Ook heb ik me beziggehouden met wat feedback toepassen die we tussentijds onvangen hadden van onze procesbegeleider.

Situatiebeschrijvingen:

In week 1 had ik in het PvA het hoofdstuk 'Op te leveren producten en kwaliteitseisen' geschreven als kwaliteitsmanager, hier hadden we na het assessment van het PvA feedback op gekregen van de procesbegeleider. Vervolgens ben ik deze aan gaan passen om ervoor te zorgen dat deze beter geformuleert, meer concreet en meer toepasselijk en meetbaar zouden zijn. Na het aanpassen liet ik andere team leden het zien om te vragen of het zo beter was en ze waren hier tevreden mee, dit was fijn want nu wist ik dat ik ze goed verbeterd had. Nu hadden we dus beter opgestelde proces en kwaliteitseisen en was het voor de rest duidelijk waar iets aan moest voldoen als zij dit zouden reviewen.

Tijdens sprint sprint 3 had Thijmen een pull request aangemaakt voor de functionaliteit gebruikers lijst ophalen. Ik ben deze pull request gaan nakijken om te bepalen of hij van voldoende kwaliteit was. Omdat er een paar stukjes code in stonden die terwijl hij aan het programeren was veranderd waren moesten die delen ook aangepast worden in zijn pull request om ervoor te zorgen dat er geen niet werkende code op de develop kwam. Ook werd er in een van de functies het wachtwoord mee opgehaald, deze was voor deze functie niet van belang dus ook daar liet ik een comment over achter. Thijmen zag dat ik de comments had achtergelaten en was aan de slag gegaan met het aanpassen, toen dit gedaan was keek ik er weer overheen en vond ik een verandering die bestaande functionaliteit in de knoop zou kunnen brengen dus ook hier liet ik een comment over achter. Hier kreeg ik vervolgens een reactie op die mij geruststelde en vervolgens kon het dus gemerged worden. Nu hadden we dus een voldoende stuk code die goede functionaliteit toevoegde en niks anders in de problemen bracht.

Tijdens het uitvoeren van mijn rol heb ik geleerd om soms iets zorgvuldiger te kijken na het werk dat ik na kijk en ook niet te vergeten de code ook zelf te runnen om te kijken of het bij mij ook goed gaat, dit deed ik soms wel soms niet. Voor een volgende keer kan ik hier dus beter op letten.

Deze rol past best goed bij mij vind ik zelf, ik vind het vaak wel leuk om werk na te kijken en ben er ook wel redelijk zorgvuldig in. Ook ben ik zelf soms wel een beetje een perfectionist als het gaat om dingen gelijk en consistent krijgen dus dit kan soms ook hiermee helpen.

6. Competenties

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

De eerste stap voor het ontwerpen van de database, de datastructuur achter de hele applicatie, was een CDM opstellen. Deze heb ik samen met de hulp van Niels gemaakt. Ik heb vervolgens in het SDD het data ontwerp voor de database gemaakt, hierin is het PDM opgenomen met tabel beschrijvingen en per kolom een omschrijving. Ook zijn hierin de design decision opgenomen die ik heb gemaakt bij het opstellen van de uiteindelijke versie van de database. Omdat we incrementeel werkte is de database niet in een keer volledig afgerond, deze is door de loop van het project meerdere malen aangepast (PDM op 29-04-22, PDM op 09-06-22). Het goed hebben van de database was erg belangrijk omdat elk ander sub systeem afhankelijk is van de datastructuur die hier is opgenomen.

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

In het SRS is het domein model opgenomen, omdat we incrementeel werkte heb ik deze regelmatig aangepast en uitgebreid tot de uiteindelijke versie die daar nu is te vinden (Domein model op 08-04-22). Verder waren er in het SRS ook User stories opgenomen, deze heb ik gekoppeld aan de use cases die we hadden opgesteld om traceerbaarheid toe te voegen. Ook gebruikte wij op Jira de Story Map om taken op te delen in epics, ik heb de bijbehorende use cases toegevoegd aan de epics om meer traceerbaarheid toe te voegen. Tot slot heb ik ook al mijn branches via Jira aangemaakt zo stond altijd de issue bij de branch en de issue was dus via de epic terug te leiden naar de bijbehordende use case. Dit allemaal zorgt ervoor dat de code en documentatie erg traceerbaar zijn en het makkelijk te achterhalen is wat waarbij hoort en waarom het dus is gedaan. Bij mijn vorige project kregen we als commentaar vaak dat de traceerbaarheid niet genoeg was, daarom heb ik daar deze keer extra goed op gelet.

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

Zoals ik beschreven heb bij hoofdstuk 5 was mijn rol kwaliteitsmanager, hier heb ik 2 situatiebeschrijvingen verwoord met daarin elk 1 voorbeeld van een concrete bijdrage. De eerste situatie beschreef het opstellen van het hoofdstuk 'Op te leveren producten en kwaliteitseisen' in het PvA en de feedback die hierop ontvangen was verwerken. De tweede situatie beschreef een review doen over een pull request gemaakt door Thijmen en hier comments op achter laten die vervolgens verbeterd zijn. Verder heb ik ook de sprint retrospectives bijgewoond, hierbij heb ik een foto van het bord van de eerste retro gemaakt. Verder heb ik ook tests geschreven voor de code die ik heb gemaakt, een voorbeeld hiervan zijn de tests van de methode addWerkplek. Dit allemaal was natuurlijk erg belangrijk voor het project zodat de kwaliteit conctinu bewaakt werd en alles van hoge kwaliteit was en ook daadwerkelijk wekte naar behoren.

7. Leerdoelen

7.1 Leerdoel 1: Duidelijker aangeven aan de groep waar ik aan werk.

Mijn eerste leerdoel ging over het duidelijker aangeven aan de rest van de groep waar ik aan werk, dit was namelijk iets dat werd aangegeven als feedback door mijn groepsgenoten uit mijn vorige project. We werkte vooral veel thuis en hier was niet super veel communicatie door de dag heen dit heeft hier ook voor gezorgd natuurlijk, maar we hebben ook wel op locatie gewerkt dus het was niet alleen dat. Nu hebben we dit project bijna elke dag wel op school gewerkt en slechts enkele dagen vanuit huis, dit hielp ook erg hiermee.

De acties die ik had opgesteld waren als volgt:

• Elke dag bij de daily stand-up aanwezig zijn en duidelijk aangeven wat ik ga doen.
• In de middag na de pauze nog een keer laten weten wat ik de rest van de dag ga doen.
• Bij het online werken na de daily stand-up vragen of het duidelijk is wat ik ga doen.

Mijn leerdoel zal behaald zijn als ik gemiddeld minder dan 1x per week een vraag krijg over wat ik aan het doen ben (buiten de daily stand-up om natuurlijk).

Voor mijn eerste actie, ik heb het niet gered om elke dag optijd te zijn voor de daily standup, dit was vooral aan het begin van het project, later in het project ben ik wel bijna altijd bij geweest. Nu heb ik aan het begin dan wel als ik te laat was alsnog even in de groep aangegeven waar ik op moment mee bezig was op wat ik van plan was om te gaan doen. Voor de tweede actie, als ik in de middag bezig was met iets anders dan ik had aangegeven heb ik dit vermeld, soms deden we ook een kleine mid daily standup om dit aan te geven. Voor de derde actie, bij de daily standup hebben we geprobeerd erin te houden aan het einde een kleine samenvatting te geven van wat iedereen nu ging doen, diet diende dus ook bij te dragen aan deze actie voor mij. Verder heb ik tijdens het project amper gehoord dat mensen niet wisten wat ik deed.

Als ik nu dus kijk naar de acties die ik heb ondernomen en de resultaten daarvan kan ik zeggen dat dit leerdoel behaald is. Het doel dat ik heb opgesteld is behaald en ik voelde ook dat alles een stuk duidelijker verliep, dat kan ook komen doordat ik het erg fijn vond om in deze groep te werken, de sfeer was erg fijn dus had ik niet zo veel moeiten met dingen aantonen.

 Voor een volgende keer zal ik proberen het zo te houden, misschien zou ik alleen wel wat beter ook kunnen vragen aan andere of het ook daadwerkelijk duidelijk is aangezien ik dat nu niet echt heb gedaan en daar dus niks concreets voor heb.

7.2 Leerdoel 2: Optijd aanwezig zijn op locatie.

Mijn tweede leerdoel ging over het optijd aanwezeg zijn op locatie, dit is iets wat in de eerste sprint retrospective naar boven kwam als een feedback punt op de groep, er waren niet veel dagen waarop iedereen er optijd was. Ik herkende dit ook wel bij mezelf en weet van mezelf dat als mijn motivatie daalt ik meer geneigt ben om te laat te komen. Hier wou ik deze keer dus iets tegen doen. De tweede helft van het project is het nu ook een stuk beter gegaan.

De acties die ik had opgesteld waren als volgt:

• De bus eerder pakken zodat ik altijd optijd ben.
• Als er iets is waardoor ik wat later ben, dit optijd en duidelijk aangeven.

Mijn leerdoel zal behaald zijn als ik gemiddeld minder dan 1x per week later kom dan de afgesproken tijd.

Voor mijn eerste actie, ik heb geprobeerd elke dag een bus eerder te pakken dit betekende dat ik 25 minuten voor de afgesproken tijd aanwezig was op school, dit ging wel goed. Ik heb het echter niet elke dag gered, soms pakte ik nog de bus waardoor ik 5 minuten later was, maar dit was wel flink verminderd. Voor de tweede actie, de momenten waarop ik de bus later pakte liet ik dit weten voor de tijd waarop we zouden beginnen, dit zou vaak 30 minuten zijn voor begintijd. Voor dagen waarbij ik van te voren wist dat ik afwezig zou zijn of later zou aansluiten liet ik dit ook van tevoren ook weten, vaak een paar dagen van te voren en herhaalde ik het nog een keer de dag ervoor of het stond ook in onze calender. Dit allemaal zorgte voor een vlottere werksfeer waarbij de daily standup optijd kon beginnen met iedereen aanwezig, ook de algemene sfeer in een groep is natuurlijk beter als je niet steeds te laat bent. Als ik kijk naar de tweede helft van het project ben ik niet vaak meer telaat gekomen waarbij ik dit niet al van tevoren had aangegeven, dit is dus wel minder dan 1x per week gemiddeld geweest.

Als ik nu dus kijk naar de acties die ik heb ondernomen en de resultaten daarvan kan ik zeggen dat dit leerdoel behaald is. Het doel dat ik heb opgesteld is behaald en alles liep een stuk soepeler.

Voor een volgende keer zal ik proberen dit voort te zetten en nog meer erop te letten en bewust te zijn van wat de invloed hierop is in de groep. Ook als verbetering van de uitvoering van dit leerdoel zou ik zeggen dat ik meer dingen concreet bij moet houden zoals het aantal keren dat het wel voor kwam zodat ik hier direct een conclusie uit zou kunnen trekken.

8. Conclusie

Het project is afgerond en het eindproduct is opgeleverd. Wij hebben ons best gedaan om alle wensen van JDI te implementeren en een voldoende portaal op te leveren. Voor JDI zelf hebben wij op 15-06-22 om 16:00 nog een presentatie om ons werk gemaakt voor hun voor te leggen. Ook hebben wij voor school nog een assessment om ons project voor te dragen en beoordeeld te worden, dit is op 23-06-22 om 11:00, op mijn verjaardag. Het product dat wij hebben opgeleverd bevat alle wensen van de opdrachtgever die haalbaar waren binnen de gegeven tijd. Het doel van het project zou ook gedekt moeten zijn, het doel zoals opgenomen in de inleiding was een HR-portaal maken die het werk van JDI zou versimpelen. Op dit moment hebben wij van de opdrachtgever nog geen tevredenheid of oordeel ontvangen, hier kan ik dus nog niks over zeggen, alleen dat ze telkens tijdens de sprint reviews telkens al positief verast waren met het product. Ik als onderdeel van de projectgroep kan echter zeggen dat ik tevreden ben met ons resultaat.

In mijn inleiding heb ik het gehad over inhoudelijke uitdagingen, hierin beschreef ik dat ik twee verschillende uitdagingen had: het programeren in de taal waarmee we aan de slag gingen, en het schrijven van mijn projectverslag, dit verslag. Voor het eerste deel, ik pakte al snel weer op hoe we hiermee te werk gingen, na de eerste week programeren ging alles al erg soepel en zat ik er weer helemaal terug in. Voor het tweede deel, het schrijven van dit verslag, ik heb wederom tussentijds niks ingeleverd hiervoor, ik heb dus ook geen feedback kunnen krijgen hierover. Dit kwam doordat ik er op dat moment nog niet aan had gewerkt, ik werk goed onder tijdsdruk en aangezien het tussentijds optioneel is maakte ik me hier geen zorgen over. Nu heb ik uiteindelijk wel een goed en volledig verslag geschreven dat hopelijk de voldoende waard is.

Verder zijn er mijn leerdoelen, deze heb ik in het hoofdstuk hierboven besproken. Beide leerdoelen heb ik wel behaald, dit is een goede vooruitgang aangezien dit wel punten waren waarop ik wist dat ik vaak de mist in ging. Het is dus erg fijn hier iets aan te hebben gedaan.

Tot slot nog het project als geheel. De projectgroep was erg fijn om mee te werken, de sfeer was erg goed en ik denk nog wel het beste van alle groepjes waar ik tot nu toe in heb gezeten. Er was een goede balans tussen serieus werken en ook nog wel wat grappen tussendoor maken. Ook de gezamelijke wandeling naar de Coop en de afsluiter aan het einde van de dag hielpen hier ook wel echt mee. Zo had je een moment dat niet werkgericht was om toch een beetje te bonden. Ook de projectmethode waarmee we hebben gewerkt was erg fijn en paste goed bij het project in mijn ogen. Verder heb ik ditmaal ook mijn verslag wederom optijd af gekregen dus hopelijk ben ik nu wel klaar met het project (op de assessment na).

Als laatste moet ik wel zeggen dat dit verslag op confluence maken erg vervelend was, ik mis veel van de functionaliteiten zoals het simpel kunnen linken naar een hoofdstuk in plaats van alleen de gehele pagina. Hierdoor heb je als je naar meerdere dingen in een document wilt verwijzen telkens dezelfde link en moet er in het document gezocht worden naar het deel waar het over gaat. Ook zorgt dit ervoor dat de link telkens hetzelfde is terwijl er over ander werk gepraat wordt, maar voor het verslag wordt er wel steeds gezeged 'links naar 3-5 specifieke bijdragen'. Dit is een punt wat ik wel jammer vond.

9. Bronnenlijst

HAN Studiecentra - APA: Bronnenlijst. (2022, 9 mei). HAN. Geraadpleegd op 9 juni 2022, van https://specials.han.nl/sites/studiecentra/auteursrechten/bronnen-vermelden/apa-normen/

10. Bijlage

10.1 Factsheet

Voor de uitgeschreven competenties zie bijlage 10.3.

10.2 AIM controlekaart

CONTROLEKAART DOCUMENTEN_
Een document dient aan alle onderstaande criteria te voldoen.
Algemeen
1. Het document is op tijd en op de juiste plek en wijze ingeleverd.
2. Het document oogt netjes (geen verspringend lettertype, geen rommelige vormgeving en geen onleesbare stukken tekst).
3. Het document is voorzien van een titel, studentnaam of -namen (alfabetisch geordend), studentnummers, klas, groepsnummer, docentnaam of -namen, datum, course/semestergegevens en versienummer.
4. Het document is voorzien van een inhoudsopgave en paginanummers. Opbouw
5. Het stuk is opgebouwd uit hoofdstukken, paragrafen en alinea’s. Het document bevat in ieder geval een inleiding, kerntekst en conclusie.
6. Bijlagen, plaatjes en tabellen hebben een naam en een nummer en zijn een zinvolle aanvulling op de hoofdtekst.
7. Er is sprake van APA-bronvermelding en er is een APA-literatuurlijst aanwezig. Stijl, spelling en grammatica
8. Het document is doelgericht geschreven en in de schrijfstijl is rekening gehouden met de doelgroep.
9. Vervoegingen van werkwoorden zijn correct gespeld. Er staan maximaal drie foutief gespelde werkwoorden op een willekeurige pagina.
10. Woorden zijn correct gespeld. Er staan maximaal drie foutief gespelde woorden op een willekeurige pagina.
11. Het document is in de actieve vorm geschreven. Het bevat nagenoeg geen lijdende zinnen.

10.3 Uitgeschreven competenties

In het OOSE-project (schooljaar 2021-2022) moet je voldoen aan acht competenties. Dit zijn:

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.