Portfolio Kerntaak examen

• Algemene eisen portfolio
• ChatGPT en Concreet
• Examenonderlegger jan '26 K1
• Examenonderlegger jan '26 K2
• Checklist KT 2026
• Planning KT 2026
• Kentaak examen 2026 Canvas
• Examen Eindgesprek
• Examenprojecten
• Overview project 1 t/m 12
• Project 1 - StagePortaal
• Project 2 - ServiceDesk Portaal
• Project 3 - Fleet Management Portaal
• Project 4 - Voorraad & Defecten Beheer
• Project 5 - Tournooi Planner
• Project 6 - Real-time Feedback Systeem
• Project 7 - Bibliotheek Beheersysteem
• Project 8 - Bezichtigingsbeheer
• Project 9 - Voorraad- en Distributiebeheer
• Project 10 - E-sports Arena
• Project 11 - Sneaker Marketplace
• Project 12 - Studie-Portaal
• Project 13 - GoalGetter
• Project 14 - CoachVision
• Project 15 - MatchUp
• Project 16 - EuroMatch
• Project 17 - ReWear
• Project 18 - StyleCycle
• Project 19 - MediaMeter
• Project 20 - TrendWatch
• --- Archief ---
• K1 Software maken
• K1 W1 Planning
• K1 W2 Ontwerp
• K1 W3 Realisatie
• K1 W4 Testen
• K1 W5 Verbeteren
• K2 Ontwikkelteam
• K2 W1 Overleggen
• K2 W2 Presenteren
• K2 W3 Reflectie
• K2W3 Reflectie voorbeelden
• Voorbeeld Examenproject (2020)
• Check List 2024-2025
• Check List 2025 (vanaf cohort 24 - voorstel)
• Examineringsproces
• Examen Rubics
• Examen Rubics 2024 v 2023
• Onderlegger / Checklist C24 (Crebo 25998)
• Onderlegger / Checklist C24 (Crebo 25998) met gewichten
• Vragen SPL

Algemene eisen portfolio

Portfolio

Jouw portfolio bestaat uit een verzameling documenten.

De documenten dienen via Canvas te worden ingeleverd. Alleen documenten die op Canvas staan tellen mee voor het examen.

Type documenten

Dit kunnen bijvoorbeeld MS Office-documenten, afbeeldingen, screenshots, video’s en geluidsfragmenten zijn.

Jij bent er zelf verantwoordelijk voor dat de examinatoren de documenten kunnen openen en lezen. Gebruik daarom gangbare bestandsformaten zoals pdf, jpg, png, mp3, mp4 en zip.

Maximale grootte van documenten

Zorg ervoor dat bestanden niet onnodig groot zijn. Bestanden tot ongeveer 200 MB zijn goed te verwerken. Extreem grote bestanden (zoals 4K-video’s van vele gigabytes) worden niet geaccepteerd.

Authentiek

Jouw werk is authentiek. Dat betekent dat het jouw eigen werk is.

Indien jouw ingeleverde portfolio werk bevat dat jij niet zelf hebt gemaakt, is er sprake van fraude (plagiaat).

Heb je bijvoorbeeld een groot project waaraan je samen hebt gewerkt, geef dan in de inhoudsopgave duidelijk aan welk deel door jou is gemaakt.

Als werk buiten school is gemaakt, kan een getekende authenticiteitsverklaring van de stagebegeleider en/of de klant als aanvullend bewijsmateriaal worden toegevoegd.

Hoeveelheid

Je moet voor alle acht werkprocessen bewijsmateriaal aanleveren. Voor elk werkproces heb je één of meerdere bewijzen.

Over het algemeen geldt: meer is beter. Heb je drie projecten gedaan (bijvoorbeeld tijdens stage)? Voeg dan van alle projecten iets toe, maar houd het wel relevant.

Concreet

Gebruik van LLM’s (zoals ChatGPT) is toegestaan, maar je werk moet authentiek en niet overdraagbaar zijn. Dit wordt verder uitgelegd op de volgende pagina.

Checklist

Bij elk examenonderdeel hoort een checklist.

De examenkandidaat geeft per checklistitem aan in welke documenten het bewijs te vinden is. Bij documenten vermeld je de pagina of alinea; bij video’s vermeld je de bestandsnaam en de tijd in de video.

Het is belangrijk om zelf aan te geven waar de checklistitems in jouw werk terug te vinden zijn, omdat er op deze manier tijdens de beoordeling geen zaken over het hoofd worden gezien.

Overzicht en structuur

Om het portfolio overzichtelijk en eenvoudig beoordeelbaar te houden:

• Gebruik duidelijke bestandsnamen (bijv. WP2_ontwerpversie2.pdf of WP5_testvideo.mp4).
• Lever je meerdere bestanden in? Voeg dan een readme.txt toe waarin staat wat er in elk bestand staat.
  
• Controleer vóór inleveren of alle links, bestanden en video’s goed openen in Canvas.

Een goed gestructureerd en overzichtelijk portfolio maakt het voor de examinator duidelijk wat je hebt gedaan en vergroot de kans op een soepele beoordeling.

ChatGPT en Concreet

Concreet schrijven

In dit document leer je hoe je concreet en controleerbaar schrijft. Dat betekent dat je uitspraken duidelijk onderbouwt met uitleg, voorbeelden en argumenten. Veel studenten (en ook ChatGPT) gebruiken woorden die mooi klinken, maar weinig zeggen. Het is jouw taak om precies uit te leggen wat je bedoelt en hoe je iets hebt gedaan. Zo laat je zien dat jij begrijpt wat je schrijft en dat het werk echt van jou is.

AI - ChatGPT

Zeker door de komst van AI worden veel documenten minder concreet.

Er staat vaak veel tekst, maar er wordt weinig echte informatie gegeven.

Je kunt ChatGPT of andere LLM’s gebruiken, maar zorg er dan wel voor dat je een concreet en onderbouwd document maakt dat jouw eigen keuzes en inzichten laat zien.

Signaalwoorden

Bijvoeglijke naamwoorden zoals

groter, sneller, slimmer, mooier, efficiënter, geavanceerder, aantrekkelijker

moeten altijd worden uitgelegd. Waarom en hoe is jouw systeem slimmer, mooier of efficiënter? Wat heb je concreet gedaan of veranderd?

Woorden als:

veilig, proactief, creatief, flexibel, aantrekkelijk, betrouwbaar, gestructureerd, praktisch, transparant

worden vaak gebruikt zonder toelichting. Leg altijd uit waarom en hoe iets zo is. Waarom is jouw website veilig? Waarom vind je dat je proactief hebt gehandeld? Geef concrete voorbeelden.

Voorbeelden

• "het systeem is makkelijk om te gebruiken" – hoe dan? Wat maakt het gebruiksvriendelijk?
• "de pagina moet overzichtelijk zijn" – hoe bereik je dat? Denk aan indeling, kleuren, lettertype of gebruik van witruimte.
• "de sfeer moet uitnodigen tot actie, het moet gamers aanspreken" – hoe ga je dit doen? Hoe ziet de site er dan uit, qua kleurgebruik, toon en beeld?
• "door de verbeterde documentatie..." – wat is er precies verbeterd? Geef voorbeelden.
• "de duidelijke documentatie..." – waarom was het duidelijk? Op welk punt? Geef een voorbeeld.
• "Gestructureerde werkwijze" – wat bedoel je hiermee precies? Hoe was je aanpak gestructureerd?

Niet concrete voorbeeldzinnen

• Het team gaf input en feedback, maar ik was voornamelijk verantwoordelijk voor de ontwikkeling en het onderhoud van bepaalde onderdelen van de applicatie.
  (Welke onderdelen? Wat hield jouw verantwoordelijkheid precies in?)

Onvoldoende uitwerking

Dingen die genoemd worden maar niet voldoende zijn uitgewerkt, zijn uiteindelijk ook niet concreet. Beschrijf altijd hoe iets is uitgevoerd en waarom je het zo hebt gedaan.

Voorbeeld ontwerp

• "er moet een zoekbalk komen" – hoe werkt die zoekbalk precies, en waarnaar moet de gebruiker kunnen zoeken?
• "als je een wachtwoord kiest moet dat veilig zijn" – wat is een veilig wachtwoord, en hoe dwingt het systeem dat af?

Voorbeeld testrapport

• "als ik een naam invoer, dan gaat dat fout" – wat gaat er precies fout, en wat zie je op het scherm?
• "als de gebruiker op klikt volgt er een foutmelding" – wat staat er in de foutmelding? Wanneer treedt die op?

Authentiek / niet overdraagbaar

Werk moet authentiek en niet overdraagbaar zijn. Dat betekent dat het te herleiden is tot jou persoonlijk: jouw keuzes, jouw manier van werken en jouw voorbeelden. Het mag niet een algemeen verhaal zijn dat ook voor iemand anders zou kunnen gelden. Laat in je verslag dus duidelijk zien wat jij hebt gedaan, waarom je dat hebt gedaan en wat je ervan hebt geleerd.

Checklist: concreet schrijven

• Heb ik bij elke bewering uitgelegd hoe ik iets heb gedaan?
• Heb ik aangegeven waarom ik een bepaalde keuze heb gemaakt?
• Heb ik voorbeelden gegeven om mijn uitleg te ondersteunen?
• Heb ik vage woorden (zoals “mooi”, “duidelijk”, “efficiënt”) vervangen of toegelicht?
• Is mijn tekst persoonlijk en herleidbaar tot mijn eigen werk?
• Kan iemand die mijn tekst leest zich een duidelijk beeld vormen van wat ik heb gedaan?
• Is de tekst feitelijk juist, specifiek en vrij van algemeenheden of AI-taal?

Examenonderlegger jan '26 K1

Beoordelingsformulier: BF_SD_SD20_B1-K1_3

naar Werkproces 2

B1-K1-W1

Plant werkzaamheden en bewaakt de voortgang

Rubics

1. De Uitgangspunten, technische en functionele eisen en wensen zijn bepaald en gedocumenteerd.

Onderlegger uitgangspunten, eisenen en wensen

Definities

1. Uitgangspunten (minimaal 5)
   Kaders, radwvoorwaarden, eisen of aannames die een globale scope hebben.
2. Functionalele eisen (minimaal 12)
   Beschrijving van wat het systeem moet doen vanuit gebruikersperspectief.
3. Technische eisen (minimaal 5)
   Beschrijven architectuur, frameworks, datastromen, beveiliging, perfomance, data strucuren, database ontwerp, etc.
   Deze eigen beinvloeden de technische uitvoering maar beschrijven geen functionaliteiten.
4. Uitgangspunten, en eisen voldoen aan:
   Relevantie, specifiek, controleerbaar/meetbaar, consistent, herleidbaar (bron/waarom).

Samengevat

Term	Gericht op	Vraag die het beantwoordt	Testbaar?
Uitgangspunt	Kaders en randvoorwaarden	Waar moeten we rekening mee houden?	Indirect / randvoorwaardelijk
Functionele eis	Functionaliteit	Wat moet het systeem doen?	Ja, via testcases
Technische eis	Technische uitvoering	Hoe moet het systeem technisch functioneren?	Ja, meetbaar

1. Je benoemd kort, puntsgewijs minimaal 4 uitgangspunten. Elke uitgangspunt is onderbouwd (waarom) en het is duidelijk waar het uitgangspunt vandaan komt.
2. Je benoemd kort, puntsgewijs minimaal 12 functionele eisen. Elke eis beschrijft observeerbaar gedrag van de software (je kan het zien) en is testbaar.
3. Je benoemd kort, puntsgewijs mininaal 5 technische eisen. Elke eis is concreet (en dus controleerbaar) en elke eis is onderbouwd (waarom).

2. Op basis van de functionaliteit is een complete en realistische planning gemaakt.

Onderlegger planning

1. Alle functionele eisen komen terug in de planning
2. Elke functionaliteit is opgesplitst in concrete taken van max. 4 uur per taak
3. Er is per taak aangegeven op welk onderdeel van de functionaliteit deze betrekking heeft
4. Bij elke taak staat een tijdsinschatting in uren (geheel of halve uren).
5. Totoale ontwikkeltijd is minimaal 40 uur, waarvan ongeveer 20% testen en 10% documenteren.  Je neemt naast de 40 geplande uren nog een extra 4-8 uur op voor onvoorziene omstandigheden (dus totaal 44 uur).
6. De volgorde is logisch (chronolgisch).
7. De planning is concreet, testbaar (eenduidig).

3. De gestelde doelen en planning zijn bewaakt.

Onderlegger bewaking

(bewaking wordt pas uitgevoerd vanaf werkproces 3).

1. Voortgang is gedurende de gehele planning minimaal 5 maal bijgehouden.
2. Voortgang bevat een status: wat is af en wat had moeten zijn en wat is de afwijking.
3. Bij elke afwijking wordt ene actie genomen en beschreven.
4. Aan het eind is een evaluatei/reflectie opnomen.

Checklist

	Criterium	Nee (0)	Beetje (1)	Ja (2)
1	Uitgangspunten, eisen en wensen (6, 4, 2)
1.1	Er zijn minimaal 5 uitgangspunten (kaders/randvoorwaarden) benoemd. Ze zijn onderbouwd en de bron is duidelijk.
1.2	Er zijn minimaal 12 functionele eisen benoemd. Deze beschrijven observeerbaar gedrag en zijn testbaar.
1.3	Er zijn minimaal 5 technische eisen benoemd. Deze zijn concreet (controleerbaar) en onderbouwd.
2	Planning (10, 6, 3)
2.1	Alle functionele eisen komen terug in de planning.
2.2	Taken zijn opgesplitst (max. 4 uur per taak) en gekoppeld aan een specifiek onderdeel van de uitgangspunten, eisen of wensen (1.1, 1.2, 1.3). Taken zijn eenduidig beschreven.
2.3	De totale ontwikkeltijd is minimaal 40 uur (deze 40 uur is gebaseerd op niveau dat verwacht wordt van een MBO-4 examenkandidaat).
2.4	De planning is logisch en chronologisch van opbouw, concreet en testbaar.
2.5	In de planning zijn minimaal 5 overleg/ voortgangs momenten opgenomen.
3	Bewaking (6, 4, 2)
3.1	De voortgang is minimaal 5 keer bijgehouden gedurende de uitvoering van het project. (bevat datum en daadwerkelijke bestede uren)
3.2	Elke voortgangsmeting bevat status, afwijking en een beschreven actie op die afwijking.
3.3	Er is een afsluitende evaluatie/reflectie opgenomen van het verloop van het project.

B1-K1-W2

Ontwerpt software 

Rubics

1. De eisen en wensen zijn vertaald naar een passend, eenduidig en volledig ontwerp.

Onderlegger eisen en wensen

Alle (minimaal 12) functionele eisen uit de planning zijn vertaald naar een ontwerp.

1. Functionaliteiten met betrekking op de GUI zijn voorzien van illustraties (schets, wireframe ) en/of bevatten een eenduidige beschrijving en zijn zodoende testbaar. Complexe functionaliteiten moeten illustraties bevatten.
2. Elke functionele beschrijving bevat: doel, invoer, uitvoer en foutafhandeling.
3. Wanneer een functionaliteit uit stappen (flow) bestaat, dan wordt deze beschreven. 
4. Alternatieve scenarios (de niet standaard flow, zoals cancelen van de winkelwagen of error flow) worden beschreven.

Technische eisen worden in het ontwerp concreet gemaakt. Zo wordt bijvoorbeeld d edatabase in een volledig en juist ERD uitgewerkt.

1. Technische beschrijvingen worden onderbouwd (waarom) en er worden alternatieven beschreven.

2. Er is gebruikgemaakt van relevante of toepasselijke schematechnieken (bijv. activiteitendiagram, klassendiagram, ERD, use case diagram).

Onderlegger schematechnieken

1. Er worden minimaal 2 relevante schema technieken op een juiste en volledige manier toegpast. Bijvoorbeeld een volledig en juist ERD en een (aantal) programma flows.

3. De gemaakte keuzes in het ontwerp zijn onderbouwd met steekhoudende argumenten, waarbij rekening is gehouden met haalbaarheid, privacy en security.

Onderlegger onderbouwing

1. Ontwerpkeuzes worden onderbouwd (waarom).
2. Bij tenminste 3 onderbouwingen zijn één of meer alternatieven is/zijn overwogen.
3. Er wordt beschreven welke keuzes er ten aanzien van security of privacy (AVG) wat specifiek toepasselijk is op hun project. (de onderbouwing waarom security of privacy niet toepasselijk is voldoende).

Checklist

	Criterium	Nee (0)	Beetje (1)	Ja (2)
1	Vertaling eisen naar ontwerp (10,6,3)
1.1	Alle (minimaal 12) functionele eisen uit de planning zijn vertaald naar het ontwerp.
1.2	GUI functionaliteiten hebben schetsen/wireframes of een eenduidige beschrijving en zijn testbaar.
1.3	Elke functionele beschrijving bevat: doel, invoer, uitvoer en foutafhandeling.
1.4	Indien van toepassing zijn stappen (flow) en alternatieve scenario's beschreven.
1.5	Technische eisen zijn concreet gemaakt (bijv. volledig ERD), zijn onderbouwd.
2	Schematechnieken (4, 2, 1)
2.1	Er zijn minimaal 2 relevante, verschillende schematechnieken; ERD, Flow diagram
2.2	De schematechnieken zijn helemaal juist toegepast.
3	Onderbouwing en keuzes (8,5,2)
3.1	Ontwerpkeuzes zijn onderbouwd (waarom is hiervoor gekozen?).
3.2	Bij tenminste 3 ontwerpkeuzes zijn minstens één of meer alternatieve oplossingen overwogen en beschreven.
3.3	Er zijn bewuste keuzes beschreven ten aanzien van security en privacy (AVG).
3.4	Je verantwoord de keuzes die je hebt gemaakt ten aanzien van de haalbaarheid.

B1-K1-W3

Realiseert (onderdelen van) software

Rubics

1. Er is voldoende functionaliteit gerealiseerd binnen de gestelde/geplande tijd.

Onderlegger voldoende functionaliteiten

Wat doet de code?

Bij dit punt gaat het om de hoeveelheid code en of de code werkt. Bij dit punt is minder relevant of de functionaliteiten goed aansluiten bij het ontwerp. De code moet wel een logisch onderdeel van het project zijn.

Richtlijnen hoeveelheid

• Aantal database objecten/entiteiten: 3
• Minimaal 4 to 6 frontend pagina's
• Database met 3 tot 5 tabellen
• Aantal regels code (HTML, CSS, JS en backend): 1000 - 2500 (met hulp van AI)
• bevat Crud functionaliteiten (e.g. Login)

Eisen/checklist

1. Er is minimaal 40 uur geprogrammeerd dit wordt onderbouwd door de hoeveelheid code, complexiteit en door middel van versiebeheer.
2. De code werkt en dit is aangetoond mbv video en applicatie die is geïnstalleerd en draait.

2. De opgeleverde functionaliteiten voldoen aan de eisen en wensen.

Onderlegger functionaliteiten voldoen aan ontwerp

Bij dit punt gaat het met name over de aansluiting aan de planning en het ontwerp.

1. De opgeleverde code is gebasseerd op de planning en ontwerp.
2. De opgeleverde code moet grotendeels voldoen aan de funcitonaliteiten omschreven in het ontwerp.

3. De kwaliteit van de code is goed.

Onderlegger kwaliteit code

1. code is consistent qua opbouw structuur en documa`entatie. (e.g. zelfde style comments, naamgeving, taal keuze)
2. Variabelen, functies, methods, bestanden, databaselementen hebben duidelijk en betekenisvolle namen
3. Code is voor 80% opgebouwd uit functies en functies doen één ding en zijn niet langer dan 60 regels.
4. Bestanden bevatten maximaal 400 regels code.
5. De hele code base heeft een duidelijke structuur.
6. Er is geen dubelle code (DRY).
7. Geen onnodig commentaar, maar alleen om code ter verduidelijken.
8. In de code worden fouten duidelijk afgehandeld (try/catch).
9. Wachtwoorden en dergelijke worden niet in plain taxt opgeslagen.
10. Er is bescherming tegen SQL-injection.

4. Versiebeheer is effectief toegepast.

Onderlegger versiebeheer

1. De code staat volledig in GIT versiebeheer.
2. Via versiebeheer zijn tenminste 5 versies beschikbaar en deze versies zijn min of meer gelijk verdeeld over de projecttijd zodat de opbouw en ontwikkeling te volgen is.
3. Commits zijn logisch opgebouwd, met duidelijke beschrijvingen.

Checklist

	Criterium	Nee (0)	Beetje (1)	Ja (2)
1	Gerealiseerde functionaliteit & Kwantiteit (4, 2, 1)
1.1	Er is minimaal 40 uur geprogrammeerd (onderbouwd door hoeveelheid code, complexiteit en versiebeheer).
1.3	De code werkt en dit is aangetoond (video en/of draaiende applicatie).
2	Aansluiting op eisen en wensen (4, 2, 1)
2.1	De opgeleverde code is in zijn algemeenheid zichtbaar gebaseerd op de gemaakte planning en het ontwerp.
2.2	Alle eisen en wensen zijn verwerkt volgens de (evetnueel aangepaste) planning
3	Kwaliteit van de code (12, 8, 3)
3.1	Naamgeving: Code is consistent, variabelen/functies hebben betekenisvolle namen.
3.2	De code heeft een gangbare, consistente en duidelijke mappen structuur.
3.3	Geen onnodig commentaar, maar alleen om code ter verduidelijken en er is geen dubbele code (DRY).
3.4	De code is modulair opgezet. Je gebruikt functies met één duidelijke taak. Bestanden bevatten maximaal 400 regels.
3.5	Robuustheid: Fouten worden opgevangen, afgehandeld (try/catch), database constraints zijn aanwezig, etc.
3.6	Security: Geen plain text wachtwoorden en bescherming tegen SQL-injection, en bijvoorbeeld CSRF, ....
4	Versiebeheer (8, 5, 3)
4.1	De code staat volledig in GIT versiebeheer.
4.2	Er zijn tenminste 5 versies beschikbaar, verdeeld over de projecttijd (opbouw is te volgen).
4.3	Commits zijn logisch opgebouwd en hebben duidelijke beschrijvingen.
4.4	Temminste 5 commits zijn duidelijk te koppelen aan functionaliteiten, zoals in de planning staat beschreven.

B1-K1-W4

Test software

1. De testcases in het testplan sluiten aan op de functionaliteiten en bevatten alle relevante scenario’s.

Definitie

Testcases: Een testcase is een gedetailleerde beschrijving van de input, acties en de verwachte output waarmee wordt vastgesteld of een specifiek onderdeel van de software correct functioneert volgens de gestelde eisen.

Onderlegger Kwaliteit Testcases

1. De testcases beschrijven duidelijk de uitgangssituatie (pre-condities), de actie (teststappen) en het verwachte resultaat.
2. Er is onderscheid gemaakt tussen de Happy Flow (alles gaat goed) en Alternative/Unhappy Flows (foutieve invoer of uitzonderingen).
3. De testcases zijn herhaalbaar: iemand anders moet de test op basis van de beschrijving exact zo kunnen uitvoeren.
4. De gekozen testdata is relevant en dekt de grenswaarden (boundary testing) indien van toepassing.

2. De kandidaat heeft voor alle toegewezen of geplande functionaliteiten testscenario’s of testcases opgesteld.

Onderlegger Volledigheid (Dekking)

1. Er is een duidelijk overzicht (bijv. een matrix) waarin elke requirement of functionaliteit is gekoppeld aan minimaal één testcase.
2. Er zijn geen functionaliteiten 'vergeten'; de scope van de test komt overeen met de scope van de realisatie.
3. De prioriteit van de testcases is bepaald wat moet absoluut werken, wat is nice-to-have. (Dit is anders dan de moscow tabel in de planning)

3. De kandidaat voert de testactiviteiten correct en volgens het testplan uit.

Onderlegger Uitvoering

1. De tests zijn daadwerkelijk uitgevoerd op de software (aantoonbaar via logs, screenshots of database-states).
2. Bij de uitvoering is geregistreerd wat het werkelijke resultaat was (versus het verwachte resultaat).
   

4. Het testrapport bevat testresultaten van alle functionaliteiten, voorzien van de juiste conclusies.

Onderlegger Rapportage & Conclusie

1. Het testrapport geeft per testcase duidelijk aan: Geslaagd (Pass) of Gefaald (Fail).
2. Voor gevonden fouten (bevindingen/bugs) is een duidelijke beschrijving gemaakt.
3. Er wordt een eindconclusie getrokken over de kwaliteit van de software (bijv. "vrijgave voor productie" of "herstel nodig") en deze wordt onderbouwd. 
4. De rapportage is begrijpelijk voor de opdrachtgever en het ontwikkelteam.

Checklist

Vul in de kolom 'Locatie & Bewijslast' exact in waar het bewijs te vinden is (Bestandsnaam + Pagina/Screenshot nr).

Nr	Criterium (Wat moet je aantonen?)	nee (0)	Beetje(1)	ja (2)
1	Kwaliteit Testcases (8, 5, 3)
1.1	De testcases bevatten een pre-conditie, actie en verwacht resultaat.
1.2	Er zijn zowel Happy Flow als Unhappy Flow (foutscenario's) tests uitgewerkt.
1.3	De gekozen testdata is concreet en dekt randgevallen.
1.4	Alle tests zijn reproduceerbaar met dezelfde eenduidige uitkomsten.
2	Volledigheid / Dekking (4, 2, 1)
2.1	Je maakt een matrix waarbij je een relatie legt tussen test en functionaliteit. Hiermee toon je aan hoe goed elke functionaliteit is getest..
2.2	Alle functionaliteiten zijn getest.
3	Uitvoering (4, 2, 1)
3.1	Het werkelijke resultaat is bij elke uitgevoerde test vastgelegd.
3.2	Je toont bewijs van de daadwerkelijke uitvoering (screenshots, logs, database-status) van de tests.
4	Rapportage & Conclusie (4, 2, 1)
4.1	Testresultaten en gevonden fouten (bugs) zijn duidelijk geregistreerd (omschrijving + ernst) en bevatten de juiste conclusie.
4.2	Het rapport bevat een duidelijke eindconclusie/advies over de softwareversie.

B1-K1-W5

Doet verbetervoorstellen voor de software

Rubrics

1. Analyseert systematisch alle beschikbare informatiebronnen op mogelijke aanpassingen aan de software.
2. Interpreteert en vertaalt wensen, reacties, testresultaten en meldingen naar realiseerbare verbetervoorstellen.
3. Stelt vast welke werkzaamheden nodig zijn en maakt een haalbare planning.

Onderlegger

1. Analyseert systematisch alle beschikbare informatiebronnen op mogelijke aanpassingen aan de software.

Onderlegger Analyse

1. De kandidaat verzamelt input uit diverse bronnen (bijv. testrapporten, gebruikersfeedback, error-logs, code reviews of backlog-items).
2. De kandidaat filtert de informatie op relevantie en urgentie (niet elke melding is een verbetering).
3. Er is sprake van een systematische aanpak: de analyse is navolgbaar en niet gebaseerd op willekeur.

2. Interpreteert en vertaalt wensen, reacties, testresultaten en meldingen naar realiseerbare verbetervoorstellen.

Onderlegger Verbetervoorstellen

1. Het verbetervoorstel is concreet beschreven: het is duidelijk wat er technisch of functioneel moet veranderen.
2. De kandidaat toont aan waarom dit een verbetering is (bijv. performance winst, betere UX, schonere code).
3. Het voorstel is technisch haalbaar binnen de context van het project en de architectuur.
4. De kandidaat houdt rekening met de impact van de wijziging op andere systeemonderdelen (impactanalyse).

3. Stelt vast welke werkzaamheden nodig zijn en maakt een haalbare planning.

Onderlegger Planning & Taken

1. Het verbetervoorstel is uitgewerkt in een lijst met benodigde werkzaamheden (taken/subtaken).
2. Er is een inschatting gemaakt van de benodigde tijd (uren/storypoints) per taak.
3. De taken zijn ingepland in de tijd (bijv. in een sprint of roadmap) en de deadline is realistisch.

Checklist

		Nee (0)	Beetje (1)	Ja (2)
1	Analyse (6,4,2)
1.1	Je hebt minimaal 2 verschillende bronnen gebruikt (bijv. logs, feedback, reflectie en resultaten van testcases) voor je analyse.
1.2	Je analyseert en prioritiseert de mogelijke aanpassingen.
1.3	Je hebt analyseert hoeveel tijd elke aanpassing kost. De totale tijd van alle aanpassingen is minimaal 8 uur aan werk.
2	Verbetervoorstel (4,2,1)
2.1	Elke verbeter voorstel is concreet uitgewerkt (het is duidelijk wat er moet gebeuren).
2.3	Elk verbeter voorstel is realistisch,
3	Planning (4,2,1)
3.1	Je hebt het voorstel opgesplitst in een (technisch) stappenplan
3.2	Er is een realistische inschatting gemaakt van de tijd per taak.

Examenonderlegger jan '26 K2

Beoordelingsformulier: BF_SD_SD24_B1-K2_1

naar Werkproces 1

B1-K2-W1

Voert overleg

Rubics

1. De kandidaat neemt actief deel aan het overleg waarbij relevante onderwerpen worden ingebracht en de juiste vragen worden gesteld.

Onderlegger Actieve Deelname

1. De kandidaat is aanwezig bij het overleg en levert meerdere keren een inhoudelijke en relevante bijdrage.
   1. De kandidaat brengt minstens één relevant onderwerp in dat betrekking heeft op het project, de voortgang of een probleem.
   2. De kandidaat stelt minimaal één vraag die bijdraagt aan verduidelijking, besluitvorming of verbetering van het project.
   3. De kandidaat reageert op bijdragen van anderen (bijvoorbeeld door feedback te geven of door te bouwen op wat een ander zegt).
   4. De kandidaat blijft bij het onderwerp en toont voorbereiding (bijv. verwijst naar eerder besproken punten, eigen werk of projectdoelen).

2. De kandidaat stemt regelmatig en tijdig af met projectteamleden en opdrachtgever over de voortgang en eventuele knelpunten.

Onderlegger Afstemmen

1. De kandidaat heeft minimaal 5 aantoonbare contactmomenten met teamleden en/of opdrachtgever (bijv. via overleg, chat, mail, logboek). 

2. De kandidaat bespreekt de voortgang op meerdere momenten (minimaal 3) in het project (niet alleen aan het einde).

3. De kandidaat meldt knelpunten tijdig, vóórdat ze de voortgang ernstig belemmeren.

4. De kandidaat vraagt actief om feedback of bevestiging bij belangrijke keuzes of veranderingen.

5. De communicatie is duidelijk, beknopt en gericht op voortgang (niet vrijblijvend of te laat).

3. De gemaakte afspraken zijn eenduidig vastgelegd.

Onderlegger Afspraken

1. Alle afspraken worden schriftelijk vastgelegd (bijv. in notulen, een verslag, takenlijst, of projecttool). 

   1. De vastlegging bevat altijd: wat is afgesproken, wie verantwoordelijk is, en wanneer het gereed moet zijn.

   2. De afspraken zijn begrijpelijk en concreet, zonder ruimte voor meerdere interpretaties.

   3. De afspraken worden gedeeld met alle relevante betrokkenen.

2. De kandidaat levert werk op volgens de afgesproken deadlines.

4. De kandidaat houdt zich aan gemaakte afspraken.

Onderlegger

1. De kwaliteit van het opgeleverde werk voldoet aan wat vooraf is afgesproken.

2. De kandidaat communiceert tijdig als een afspraak niet kan worden nagekomen en stelt zelf een alternatief voor.

3. De kandidaat komt opdagen bij geplande overleggen of meldt zich vooraf af met reden.

4. Er zijn geen (of nauwelijks) signalen van gemiste afspraken of klachten van teamleden/opdrachtgever.

Checklist

		Nee (0)	Beetje (1)	Ja (2)
1	Actieve deelname (8,5,3)
1.1	Je brengt minstens één relevant onderwerp in dat betrekking heeft op het project, de voortgang of een probleem.
1.2	Je stelt minimaal één vraag die bijdraagt aan verduidelijking, besluitvorming of verbetering van het project.
1.3	Je reageert op bijdragen van anderen (bijvoorbeeld door feedback te geven of door te bouwen op wat een ander zegt).
1.4	Je toont voorbereiding (bijv. verwijst naar eerder besproken punten, eigen werk of projectdoelen).
2	Afstemmen (8,5,3)
2.1	Je kunt aantonen dat je 5 verschillende contactmomenten hebt gehad om af te stemmen.
2.2	Je toont aan dat je ten minste 3keer hebt afgestemd over de voortgang. Hierbij toon je inhoudelijk duidelijk aan wat er is afgestemd.
2.3	Je hebt minimaal 1 maal afgestemd over een knelpunt. Hierbij toon je inhoudelijk duidelijk aan wat er over het knelpunt is afgestemd.
2.4	Je hebt minimaal 1 maal om feedback gevraagd. Hierbij toon je aan om welke feedback je hebt gevraagd en wat de inhod van de feedback was.
3	Afspraken vastleggen (4,2,1)
3.1	Er zijn tenmiste 3 duidelijke voorbeelden waaruit blijkt dat afspraken zijn vastgelegd. De afspraken zijn hierin concreet en duidelijk beschreven.
3.2	Bij de afsprakan staat wat, wie en wanneer.
4	Afspraken nakomen (4,2,1)
4.1	Je kan tenmiste 3 voorbeelden geven van afspraken die zijn nagekomen.
4.2	Jouw stage-leider bevestigt dat afspraken zijn nagekomen en indien dit niet het geval was dat jij daarover vooraf duidelijk hebt gecomuniceerd.

B1-K2-W2

Presenteert het opgeleverde werk 

Rubics

1. De kandidaat legt de functionaliteiten uit met een goed opgebouwd en met argumenten onderbouwd verhaal.

Onderlegger Uitleg

Eis: De presentatie gaat over een IT project.

1. De uitleg heeft een duidelijke structuur: inleiding (wat en waarom), kern (wat je wilt vertellen) en afsluiting (samenvatting, vervolg, vragen).
2. De kandidaat benoemt de belangrijkste functionaliteiten zonder irrelevante details.
3. De kandidaat onderbouwt keuzes of werkwijze met concrete argumenten (bijv. gebruiksgemak, techniek, ontwerpkeuze).

2. De kandidaat stemt de stijl van communiceren en de presentatiemiddelen af op de toehoorders.

Onderlegger Afstemmen

1. De kandidaat past taalgebruik en tempo aan het kennisniveau van de toehoorders aan (geen vakjargon bij leken, wel technische termen bij experts).
2. De kandidaat maakt bewust gebruik van ondersteunende middelen (bijv. slides, demo, visuele voorbeelden) die helpen om de boodschap te verduidelijken.
3. De presentatie is visueel overzichtelijk (goede leesbaarheid, geen overvolle slides, kernpunten zichtbaar).
4. De kandidaat maakt actief oogcontact, spreekt duidelijk en reageert op signalen van het publiek (bijv. vragen, verwarring, aandacht).
5. Het taalgebruik, de toon en houding zijn professioneel, respectvol en afgestemd op de context (bijv. opdrachtgever, klas, team).

3. De kandidaat beantwoordt vragen met steekhoudende argumenten.

Onderlegger Beantwoorden

1. De kandidaat luistert aandachtig naar de gestelde vraag en geeft een relevant antwoord.
2. Antwoorden worden onderbouwd met logische argumenten, voorbeelden of verwijzingen naar eigen werk.
3. De kandidaat erkent wanneer hij iets niet weet en reageert professioneel (bijv. belooft op te zoeken of toelichting te geven na afloop).

4. Argumenten tonen inzicht in de achterliggende keuzes, principes of werking van de oplossing.

5. De toon van de reactie is rustig, respectvol en zelfverzekerd, ook bij kritische vragen.

Checklist

		Nee (0)	Beetje (1)	Ja (2)
1	Kwaliteit van uitleg (6,4,2)
1.1	De presentatie heeft een duidelijke structuur (inleiding, kern, afsluiting).
1.2	De belangrijkste functionaliteiten worden benoemd zonder irrelevante details.
1.3	Keuzes/werkwijze worden onderbouwd met concrete argumenten (techniek/ontwerp).
2	Afstemming op doelgroep (6,4,2)
2.1	Taalgebruik en tempo zijn aangepast aan het kennisniveau van de toehoorders.
2.2	Ondersteunende middelen (slides/demo) zijn effectief en visueel overzichtelijk.
2.3	Er is sprake van actieve interactie (oogcontact, inspelen op vragen/verwarring).
3	Beantwoorden van vragen (4,2,1)
3.1	Vragen worden aandachtig beluisterd en relevant beantwoord met logische argumenten.
3.2	De houding bij het beantwoorden is professioneel, rustig en zelfverzekerd.

B1-K2-W3

Reflecteert op het werk 

Rubics

1. De kandidaat benoemt zowel positieve als verbeterpunten van het proces van zowel eigen als teamprestaties.

Onderlegger positieve- en verbeterpunten

1. De kandidaat benoemt minstens één concreet positief punt over het eigen proces.

2. De kandidaat benoemt minstens één concreet positief punt over over het teamproces.

3. De kandidaat benoemt minstens één concreet verbeterpunt over het eigen proces

4. De kandidaat benoemt minstens één concreet verbeterpunt punt over het teamproces.

5. De genoemde punten zijn onderbouwd met voorbeelden of situaties uit de praktijk (geen algemeenheden).
   De genoemnde punten zijn dus specifiek en zijn "niet overdraagbaar".

6. De kandidaat toont reflectie: legt verband tussen gedrag, resultaat en mogelijke verbetering.

7. De toon is constructief — gericht op leren en verbeteren, niet op schuld of lof zonder onderbouwing.

2. De kandidaat reageert actief op ontvangen feedback.

Onderlegger Reactie Feedback

1. De kandidaat benoemd heel specifiek de feedback (geen algemeenheden).
   De feedback is "niet overdraagbaar".

2. De kandidaat vertaalt de feedback naar concrete verbeteracties (bijv. aanpassing in werkwijze, presentatie of product).

3. De kandidaat past zichtbaar iets aan op basis van ontvangen feedback.

4. De kandidaat toont een open en lerende houding tijdens en na het ontvangen van feedback.

Checklist

		Nee (0)	Beetje (1)	Ja (2)
1	Reflectie op resultaat en proces (6,4,2)
1.1	Je benoemt zowel een specifiek eigen positief- als verbeterpunt (onderbouwd).
1.2	Je benoemt zowel een specifiek team positief- als verbeterpunt (onderbouwd).
1.3	Je legt een duidelijk verband tussen jouw gedrag, het resultaat en mogelijke verbeteringen.
2	Reactie op feedback (6,4,2)
2.1	Je benoemt specifiek ontvangen feedback en vertaalt dit naar concrete verbeteracties.
2.2	Er is bewijs dat je zichtbaar zaken hebt aangepast op basis van de feedback.
2.3	Je toont gedurende het gehele proces een open en lerende houding.

Checklist KT 2026

Hieronder staan 8 checklists op basis waarvan het kerntaakexamen wordt beoordeeld.

Naast deze beoordeling geldt voor al het werk dat het authentiek moet zijn.

Kerntaak 1 - Project uitvoeren

1. Checklist B1-K1-W1 (Planning & Voortgang)

1. Er zijn minimaal 5 uitgangspunten (kaders/randvoorwaarden) benoemd. Ze zijn onderbouwd en de bron is duidelijk.
2. Er zijn minimaal 12 functionele eisen benoemd. Deze beschrijven observeerbaar gedrag en zijn testbaar.
3. Er zijn minimaal 5 technische eisen benoemd. Deze zijn concreet (controleerbaar) en onderbouwd.
   
   
4. Alle functionele eisen komen terug in de planning.
5. Taken zijn opgesplitst (max. 4 uur per taak) en gekoppeld aan een specifiek onderdeel van de uitgangspunten, eisen of wensen (1.1, 1.2, 1.3). Taken zijn eenduidig beschreven.
6. De totale ontwikkeltijd is minimaal 40 uur (deze 40 uur is gebaseerd op niveau dat verwacht wordt van een MBO-4 examenkandidaat).
7. De planning is logisch en chronologisch van opbouw, concreet en testbaar.
8. In de planning zijn minimaal 5 overleg/ voortgangs momenten opgenomen.
   
   
9. De voortgang is minimaal 5 keer bijgehouden gedurende de uitvoering van het project. (bevat datum en daadwerkelijke bestede uren)
10. Elke voortgangsmeting bevat status, afwijking en een beschreven actie op die afwijking.
11. Er is een afsluitende evaluatie/reflectie opgenomen van het verloop van het project.

2. Checklist B1-K1-W2 (Ontwerp)

1. Alle (minimaal 12) functionele eisen uit de planning zijn vertaald naar het ontwerp.
2. GUI functionaliteiten hebben schetsen/wireframes of een eenduidige beschrijving en zijn testbaar.
3. Elke functionele beschrijving bevat: doel, invoer, uitvoer en foutafhandeling.
4. Indien van toepassing zijn stappen (flow) en alternatieve scenario's beschreven.
5. Technische eisen zijn concreet gemaakt (bijv. volledig ERD), zijn onderbouwd.
   
   
6. Er zijn minimaal 2 relevante, verschillende schematechnieken; ERD, Flow diagram
7. De schematechnieken zijn helemaal juist toegepast.
   
   
8. Ontwerpkeuzes zijn onderbouwd (waarom is hiervoor gekozen?).
9. Bij tenminste 3 ontwerpkeuzes zijn minstens één of meer alternatieve oplossingen overwogen en beschreven.
10. Er is beschreven welke keuzes er ten aanzien van security of privacy (AVG) zijn gemaakt.

3. Checklist B1-K1-W3 (Realisatie)

1. Er is minimaal 40 uur geprogrammeerd (onderbouwd door hoeveelheid code, complexiteit en versiebeheer).
2. De code werkt en dit is aangetoond (video en/of draaiende applicatie).
   
   
3. De opgeleverde code is in zijn algemeenheid zichtbaar gebaseerd op de gemaakte planning en het ontwerp.
4. Alle eisen en wensen zijn verwerkt volgens de (eventueel aangepaste) planning
   
   
5. Naamgeving: Code is consistent, variabelen/functies hebben betekenisvolle namen.
6. De code heeft een gangbare, consistente en duidelijke mappen structuur.
7. Geen onnodig commentaar, maar alleen om code ter verduidelijken en er is geen dubbele code (DRY).
8. De code is modulair opgezet. Je gebruikt functies met één duidelijke taak. Bestanden bevatten maximaal 400 regels.
9. Robuustheid: Fouten worden opgevangen, afgehandeld (try/catch), database constraints zijn aanwezig, etc.
10. Security: Geen plain text wachtwoorden en bescherming tegen SQL-injection, en bijvoorbeeld CSRF, ....
    
    
11. De code staat volledig in GIT versiebeheer.
12. Er zijn tenminste 5 versies beschikbaar, verdeeld over de projecttijd (opbouw is te volgen).
13. Commits zijn logisch opgebouwd en hebben duidelijke beschrijvingen.
14. Tenminste 5 commits zijn duidelijk te koppelen aan functionaliteiten, zoals in de planning staat beschreven.

4. Checklist B1-K1-W4 (Testen)

1. De testcases bevatten een pre-conditie, actie en verwacht resultaat.
2. Er zijn zowel Happy Flow als Unhappy Flow (foutscenario's) tests uitgewerkt.
3. De gekozen testdata is concreet en dekt randgevallen.
4. Alle tests zijn reproduceerbaar met dezelfde eenduidige uitkomsten.
   
   
5. Je maakt een matrix waarbij je een relatie legt tussen test en functionaliteit. Hiermee toon je aan hoe goed elke functionaliteit is getest..
6. Alle functionaliteiten zijn getest.
   
   
7. Het werkelijke resultaat is bij elke uitgevoerde test vastgelegd.
8. Je toont bewijs van de daadwerkelijke uitvoering (screenshots, logs, database-status) van de tests.
   
   
9. Testresultaten en gevonden fouten (bugs) zijn duidelijk geregistreerd (omschrijving + ernst) en bevatten de juiste conclusie.
10. Het rapport bevat een duidelijke eindconclusie/advies over de softwareversie.

5. Checklist B1-K1-W5 (Verbeteren)

1. Je hebt minimaal 2 verschillende bronnen gebruikt (bijv. logs, feedback, reflectie en resultaten van testcases) for je analyse.
2. Je analyseert en prioritiseert de mogelijke aanpassingen.
3. Je hebt analyseert hoeveel tijd elke aanpassing kost. De totale tijd van alle aanpassingen is minimaal 8 uur aan werk.
   
   
4. Elke verbeter voorstel is concreet uitgewerkt (het is duidelijk wat er moet gebeuren).
5. Elk verbeter voorstel is realistisch,
   
   
6. Je hebt het voorstel opgesplitst in een (technisch) stappenplan
7. Er is een realistische inschatting gemaakt van de tijd per taak.

Kerntaak 2 - Samenwerken

1. Checklist B1-K2-W1 (Voert overleg)

1. Je brengt minstens één relevant onderwerp in dat betrekking heeft op het project, de voortgang of een probleem.
2. Je stelt minimaal één vraag die bijdraagt aan verduidelijking, besluitvorming of verbetering van het project.
3. Je reageert op bijdragen van anderen (bijvoorbeeld door feedback te geven of door te bouwen op wat een ander zegt).
4. Je toont voorbereiding (bijv. verwijst naar eerder besproken punten, eigen werk of projectdoelen).
   
   
5. Je kunt aantonen dat je 5 verschillende contactmomenten hebt gehad om af te stemmen.
6. Je toont aan dat je ten minste 3 keer hebt afgestemd over de voortgang. Hierbij toon je inhoudelijk duidelijk aan wat er is afgestemd.
7. Je hebt minimaal 1 maal afgestemd over een knelpunt. Hierbij toon je inhoudelijk duidelijk aan wat er over het knelpunt is afgestemd.
8. Je hebt minimaal 1 maal om feedback gevraagd. Hierbij toon je aan om welke feedback je hebt gevraagd en wat de inhoud van de feedback was.
   
   
9. Er zijn tenminste 3 duidelijke voorbeelden waaruit blijkt dat afspraken zijn vastgelegd. De afspraken zijn hierin concreet en duidelijk beschreven.
10. Bij de afspraken staat wat, wie en wanneer.
    
    
11. Je kan tenminste 3 voorbeelden geven van afspraken die zijn nagekomen.
12. Jouw stage-leider bevestigt dat afspraken zijn nagekomen en indien dit niet het geval was dat jij daarover vooraf duidelijk hebt gecommuniceerd.

2. Checklist B1-K2-W2 (Presenteert het opgeleverde werk)

1. De presentatie heeft een duidelijke structuur (inleiding, kern, afsluiting).
2. De belangrijkste functionaliteiten worden benoemd zonder irrelevante details.
3. Keuzes/werkwijze worden onderbouwd met concrete argumenten (techniek/ontwerp).
   
   
4. Taalgebruik en tempo zijn aangepast aan het kennisniveau van de toehoorders.
5. Ondersteunende middelen (slides/demo) zijn effectief en visueel overzichtelijk.
6. Er is sprake van actieve interactie (oogcontact, inspelen op vragen/verwarring).
   
   
7. Vragen worden aandachtig beluisterd en relevant beantwoord met logische argumenten.
8. De houding bij het beantwoorden is professioneel, rustig en zelfverzekerd.

3. Checklist B1-K2-W3 (Reflecteert op het werk)

1. Je benoemt zowel een specifiek eigen positief- als verbeterpunt (onderbouwd).
2. Je benoemt zowel een specifiek team positief- als verbeterpunt (onderbouwd).
3. Je legt een duidelijk verband tussen jouw gedrag, het resultaat en mogelijke verbeteringen.
   
   
4. Je benoemt specifiek ontvangen feedback en vertaalt dit naar concrete verbeteracties.
5. Er is bewijs dat je zichtbaar zaken hebt aangepast op basis van de feedback.
6. Je toont gedurende het gehele proces een open en lerende houding.

---

Planning KT 2026

			Les	Doel	Inleveren
5-jan	9-jan		Inleiding	Project Bepalen	Projectvoorstel
12-jan	16-jan	K1W1	Planning	Planning maken
19-jan	23-jan	K1W2	Ontwerp	Ontwerp maken	Planning
26-jan	30-jan	K1W3	Bouwen / Samenwerken	Bouwen	Ontwerp
2-feb	6-feb	K1W3	Bouwen	Bouwen	Samenwerken
9-feb	13-feb	K1W3	Bouwen	Bouwen
16-feb	20-feb	K1W4	Testen	Testen	Bouwen
23-feb	27-feb
2-mrt	6-mrt	K1W5	Verbeteren	Verbeteren	Testen
9-mrt	13-mrt	K2W2	Presenteren	Presenteren	Verbeteren
16-mrt	20-mrt	K2W3	Reflectie	Reflectie	Presenteren
23-mrt	27-mrt	K2W2	Presenteren	Presenteren	Verbeteren
30-mrt	3-apr	K2W3	Reflectie	Reflectie	Presenteren
6-apr	10-apr		Afsluiting (individueel plan)	Herkansing 1	Reflectie
13-apr	17-apr		Afsluiting (individueel plan)	Herkansing 2	Herkansing 1
20-apr	24-apr	DEADLINE	Voorbereiden gesprek	Voorbereiden gesprek	Herkansing 2

Kentaak examen 2026 Canvas

K1W0 Voorbereiding

💡 Uitleg

Voor je kerntaak-portfolioexamenen moet je een project inleveren.

Het project moet aan een aantal eisen voldoen.

Jij moet een project bedenken, het liefst uit de praktijk, dat voldoet aan alle eisen.

Jouw project moet authentiek zijn, dat JIJ het hebt gedaan en jij moet ook kunnen uitleggen in het exameneindgesprek wat je hebt gedaan hoe en waarom.

✔️Checklist

Elk examenonderdeel heeft een checklist. Jij moet zelf controleren of je aan de checklist voldoet.

Om even snel een quick scan te maken of jouw project voldoet, kan je de volgende criteria controleren:

1. Er is minimaal 40 uur geprogrammeerd (onderbouwd door hoeveelheid code, complexiteit en versiebeheer).
2. Er geprogrammeerd volgens de principes van OOP of functioneel pogrammeren.
3. Er wordt gebruik gemaakt van een database.
   
4. WJe maakt gebruik van standaard programmeertalen en/of frameworks?
5. Er is gebruik gemaakt van GIT versiebeheer.
6. In GIT staan meerdere versies over de gehele ontwikkel periode.
7. Je kunt jouw werk presenteren: live zetten en film van maken.

Alle eisen kan je vinden in de officieël checklist.

🛠️ Opdracht

Jij maakt een projectbeschrijving en legt hierin in een paar zinnen waar jouw project over gaat en waarom je dit project kiest.

Jij beschrijft de uitgangspunten van jouw project. Dit zijn algemene zaken die gelden, zoals:

• Taal/Framework
• Database
• Hosting/platform
• Wie gaan het gebruiken
• Algemene eisen aan de applicatie

Voorbeeld uitwerking uitgangspunten

Projectbeschrijving: StudiePlanner Plus

Wat is het project? StudiePlanner Plus is een webapplicatie die studenten helpt hun huiswerk, deadlines en tentamens te organiseren in één overzichtelijk dashboard. In tegenstelling tot standaard agenda's, berekent deze app op basis van de moeilijkheidsgraad hoeveel tijd je per dag moet besteden aan een vak om de deadline stressvrij te halen.

Waarom dit project? Ik heb voor dit project gekozen omdat veel medestudenten moeite hebben met plannen en vaak pas op het laatste moment beginnen. Door dit proces te automatiseren, help ik niet alleen anderen hun resultaten te verbeteren, maar leer ik zelf ook complexe algoritmes voor tijdmanagement implementeren.

Uitgangspunten van het project

(werkt de volgende punten zelf verder uit)

• Technieken - Taal & Framework, API's?
• database - welke database gebruiken we om gegevens op te slaan?
• Hosting - waar wordt de applicatie gehost en wat zijn de eisen aan het hosting platform?
• Plartform - op welke platformen moet de app draaine (mobiel, laptop,...)
• Afhankelijkheden - andere servcies, API's
• Doelgroep - wie zijn je gebruikers en wat is hun rol?
• Algemene eisen, veiligheid, AVG, mobiel, laptop.
• Overig, bijvoorbeeld de applicatie moet een "one page app" worden.

In de volgende stap gaan we de projectbeschrijving en uitgangspunten verder uitewerken tot een planning.

Last but not least, vul je de checklist in en beoordeel je of jow project aan de belangrijkste eisen voldoet.

📤Inleveren

1. Uitgewerkte en complete initaitie document in PDF
   Je kunt hiervoor deze template gebruiken: http://www.wijs.ovh/generic-forms/index.html?form=K1W0
   

K1W1 Planning

Plant werkzaamheden en bewaakt de voortgang

💡 Uitleg

Je maakt een planning voor je project.

De volledige uitleg wordt tijdens de les gegeven en besproken.

Vanuit de planning is duidelijk wat je gaat en hoe je het gaat bouwen en je hebt je bouwproject opgesplitst in dudielijke taken.

We ondersheiden uitgangspunten, functionele- en technische eisen.

Uitgangspunten

Kaders, randvoorwaarden, eisen of aannames die een globale scope hebben.

Functionele Eisen

Beschrijving van wat het systeem moet doen vanuit gebruikersperspectief.

Technische eisen

Beschrijven architectuur, frameworks, datastromen, beveiliging, perfomance, data strucuren, database ontwerp, etc.
Deze eigen beinvloeden de technische uitvoering maar beschrijven geen functionaliteiten.

Alle Uitgangspunten, en eisen voldoen zijn:
Relevantie, specifiek, controleerbaar/meetbaar, consistent, herleidbaar (bron/waarom).

Authenticiteit

Alle onderdelen die je benoemd zijn concreet, eenduidig en specifiek voor jouw project. Een algemene planning of lijst van taken die je voor elke project zou kunnen maken is niet goed.

Als jouw planningstaken dus 1 op 1 voor een elk ander project zouden kunnen gelden ben je niet specifief genoeg.

✔️Checklist

1. Er zijn minimaal 5 uitgangspunten (kaders/randvoorwaarden) benoemd. Ze zijn onderbouwd en de bron is duidelijk.
2. Er zijn minimaal 12 functionele eisen benoemd. Deze beschrijven observeerbaar gedrag en zijn testbaar.
3. Er zijn minimaal 5 technische eisen benoemd. Deze zijn concreet (controleerbaar) en onderbouwd.
   
   
4. Alle functionele eisen komen terug in de planning.
5. Taken zijn opgesplitst (max. 4 uur per taak) en gekoppeld aan een specifiek onderdeel van de uitgangspunten, eisen of wensen (1.1, 1.2, 1.3). Taken zijn eenduidig beschreven.
6. De totale ontwikkeltijd is minimaal 40 uur (deze 40 uur is gebaseerd op niveau dat verwacht wordt van een MBO-4 examenkandidaat).
7. De planning is logisch en chronologisch van opbouw, concreet en testbaar.
8. In de planning zijn minimaal 5 overleg/ voortgangs momenten opgenomen.
   
   
9. De voortgang is minimaal 5 keer bijgehouden gedurende de uitvoering van het project. (bevat datum en daadwerkelijke bestede uren)
10. Elke voortgangsmeting bevat status, afwijking en een beschreven actie op die afwijking.
11. Er is een afsluitende evaluatie/reflectie opgenomen van het verloop van het project.

🛠️ Opdracht

Maak een planning die voldoet aan de examencriteria.

Vul de checklist in: http://www.wijs.ovh/generic-forms/index.html?form=K1W1

📤Inleveren

1. Uitgewerkte en complete planning in PDF
2. Ingevulde checklist in PDF
3. Eventueel aanvullende bewijzen.

K1W2 Ontwerp

Ontwerpt software 

💡 Uitleg

Je maakt een ontwerp voor je project.

De volledige uitleg wordt tijdens de les gegeven en besproken.

...

✔️ Checklist

1. Alle (minimaal 12) functionele eisen uit de planning zijn vertaald naar het ontwerp.
2. GUI functionaliteiten hebben schetsen/wireframes of een eenduidige beschrijving en zijn testbaar.
3. Elke functionele beschrijving bevat: doel, invoer, uitvoer en foutafhandeling.
4. Indien van toepassing zijn stappen (flow) en alternatieve scenario's beschreven.
5. Technische eisen zijn concreet gemaakt (bijv. volledig ERD), zijn onderbouwd.
   
   
6. Er zijn minimaal 2 relevante, verschillende schematechnieken; ERD, Flow diagram
7. De schematechnieken zijn helemaal juist toegepast.
   
   
8. Ontwerpkeuzes zijn onderbouwd (waarom is hiervoor gekozen?).
9. Bij tenminste 3 ontwerpkeuzes zijn minstens één of meer alternatieve oplossingen overwogen en beschreven.
10. Er is beschreven welke keuzes er ten aanzien van security of privacy (AVG) zijn gemaakt.

🛠️ Opdracht

Maak een ontwerp dat voldoet aan de examencriteria.

Vul de checklist in: http://www.wijs.ovh/generic-forms/index.html?form=K1W2

📤Inleveren

1. Uitgewerkte en compleet ontwerp in PDF
2. Ingevulde checklist in PDF
3. Eventueel aanvullende bewijzen/bijlagen.

K1W3 Bouw

Realiseert (onderdelen van) software

💡 Uitleg

Maak je project en vergeet niet GitHub te gebruiken en je voortgang bij te houden.

De volledige uitleg wordt tijdens de les gegeven en besproken.

✔️ Checklist

1. Er is minimaal 40 uur geprogrammeerd (onderbouwd door hoeveelheid code, complexiteit en versiebeheer).
2. De code werkt en dit is aangetoond (video en/of draaiende applicatie).
   
   
3. De opgeleverde code is in zijn algemeenheid zichtbaar gebaseerd op de gemaakte planning en het ontwerp.
4. Alle eisen en wensen zijn verwerkt volgens de (eventueel aangepaste) planning
   
   
5. Naamgeving: Code is consistent, variabelen/functies hebben betekenisvolle namen.
6. De code heeft een gangbare, consistente en duidelijke mappen structuur.
7. Geen onnodig commentaar, maar alleen om code ter verduidelijken en er is geen dubbele code (DRY).
8. De code is modulair opgezet. Je gebruikt functies met één duidelijke taak. Bestanden bevatten maximaal 400 regels.
9. Robuustheid: Fouten worden opgevangen, afgehandeld (try/catch), database constraints zijn aanwezig, etc.
10. Security: Geen plain text wachtwoorden en bescherming tegen SQL-injection, en bijvoorbeeld CSRF, ....
    
    
11. De code staat volledig in GIT versiebeheer.
12. Er zijn tenminste 5 versies beschikbaar, verdeeld over de projecttijd (opbouw is te volgen).
13. Commits zijn logisch opgebouwd en hebben duidelijke beschrijvingen.
14. Tenminste 5 commits zijn duidelijk te koppelen aan functionaliteiten, zoals in de planning staat beschreven.

🛠️ Opdracht

Maak de software die voldoet aan de examencriteria.

Vul de checklist in: http://www.wijs.ovh/generic-forms/index.html?form=K1W3

📤Inleveren

1. Een link naar je werkende code
2. Een filmpje waarin je demonstreert dat je code werkt (max. 3 minuten en max. 200MB)
3. Een publieke link naar github met je code (in bestand github.txt)
4. Ingevulde checklist in PDF
5. Eventueel aanvullende bewijzen/bijlagen.

K1W4 Testen

Test software

💡 Uitleg

Je maakt een testrapport voor je project.

De volledige uitleg wordt tijdens de les gegeven en besproken.

...

✔️ Checklist

1. De testcases bevatten een pre-conditie, actie en verwacht resultaat.
2. Er zijn zowel Happy Flow als Unhappy Flow (foutscenario's) tests uitgewerkt.
3. De gekozen testdata is concreet en dekt randgevallen.
4. Alle tests zijn reproduceerbaar met dezelfde eenduidige uitkomsten.
   
   
5. Je maakt een matrix waarbij je een relatie legt tussen test en functionaliteit. Hiermee toon je aan hoe goed elke functionaliteit is getest..
6. Alle functionaliteiten zijn getest.
   
   
7. Het werkelijke resultaat is bij elke uitgevoerde test vastgelegd.
8. Je toont bewijs van de daadwerkelijke uitvoering (screenshots, logs, database-status) van de tests.
   
   
9. Testresultaten en gevonden fouten (bugs) zijn duidelijk geregistreerd (omschrijving + ernst) en bevatten de juiste conclusie.
10. Het rapport bevat een duidelijke eindconclusie/advies over de softwareversie.

🛠️ Opdracht

Maak een testrapport dat voldoet aan de examencriteria.

Vul de checklist in: http://www.wijs.ovh/generic-forms/index.html?form=K1W4

📤Inleveren

1. Uitgewerkte en compleet testrapport in PDF
2. Ingevulde checklist in PDF
3. Eventueel aanvullende bewijzen/bijlagen.

K1W5 Verbeteren

Doet verbetervoorstellen voor de software

💡 Uitleg

Je maakt een verbtervoorstel voor je project.

De volledige uitleg wordt tijdens de les gegeven en besproken.

....

✔️ Checklist

1. Je hebt minimaal 2 verschillende bronnen gebruikt (bijv. logs, feedback, reflectie en resultaten van testcases) for je analyse.
2. Je analyseert en prioritiseert de mogelijke aanpassingen.
3. Je hebt analyseert hoeveel tijd elke aanpassing kost. De totale tijd van alle aanpassingen is minimaal 8 uur aan werk.
   
   
4. Elke verbeter voorstel is concreet uitgewerkt (het is duidelijk wat er moet gebeuren).
5. Elk verbeter voorstel is realistisch,
   
   
6. Je hebt het voorstel opgesplitst in een (technisch) stappenplan
7. Er is een realistische inschatting gemaakt van de tijd per taak.

🛠️ Opdracht

Maak een verbtervoorstel dat voldoet aan de examencriteria.

Vul de checklist in: http://www.wijs.ovh/generic-forms/index.html?form=K1W5

📤Inleveren

1. Uitgewerkte en compleet verbtervoorstel in PDF
2. Ingevulde checklist in PDF
3. Eventueel aanvullende bewijzen/bijlagen.

K2W1 Overleg

Voert overleg

💡 Uitleg

Je maakt een verbtervoorstel voor je project.

De volledige uitleg wordt tijdens de les gegeven en besproken.

....

✔️ Checklist

1. Je brengt minstens één relevant onderwerp in dat betrekking heeft op het project, de voortgang of een probleem.
2. Je stelt minimaal één vraag die bijdraagt aan verduidelijking, besluitvorming of verbetering van het project.
3. Je reageert op bijdragen van anderen (bijvoorbeeld door feedback te geven of door te bouwen op wat een ander zegt).
4. Je toont voorbereiding (bijv. verwijst naar eerder besproken punten, eigen werk of projectdoelen).
   
   
5. Je kunt aantonen dat je 5 verschillende contactmomenten hebt gehad om af te stemmen.
6. Je toont aan dat je ten minste 3 keer hebt afgestemd over de voortgang. Hierbij toon je inhoudelijk duidelijk aan wat er is afgestemd.
7. Je hebt minimaal 1 maal afgestemd over een knelpunt. Hierbij toon je inhoudelijk duidelijk aan wat er over het knelpunt is afgestemd.
8. Je hebt minimaal 1 maal om feedback gevraagd. Hierbij toon je aan om welke feedback je hebt gevraagd en wat de inhoud van de feedback was.
   
   
9. Er zijn tenminste 3 duidelijke voorbeelden waaruit blijkt dat afspraken zijn vastgelegd. De afspraken zijn hierin concreet en duidelijk beschreven.
10. Bij de afspraken staat wat, wie en wanneer.
    
    
11. Je kan tenminste 3 voorbeelden geven van afspraken die zijn nagekomen.
12. Jouw stage-leider bevestigt dat afspraken zijn nagekomen en indien dit niet het geval was dat jij daarover vooraf duidelijk hebt gecommuniceerd.
    

🛠️ Opdracht

Vul de checklist in: http://www.wijs.ovh/generic-forms/index.html?form=K2W1

📤Inleveren

1. Ingevulde checklist in PDF
2. Bewijzen (screenshots, video en deregelijke) die je in je checklist hebt vermeld.
3. Eventueel aanvullende bewijzen/bijlagen.

K2W2 Presenteren

Presenteert het opgeleverde werk

💡 Uitleg

Je maakt een verbtervoorstel voor je project.

De volledige uitleg wordt tijdens de les gegeven en besproken.

....

✔️ Checklist

1. De presentatie heeft een duidelijke structuur (inleiding, kern, afsluiting).
2. De belangrijkste functionaliteiten worden benoemd zonder irrelevante details.
3. Keuzes/werkwijze worden onderbouwd met concrete argumenten (techniek/ontwerp).
   
   
4. Taalgebruik en tempo zijn aangepast aan het kennisniveau van de toehoorders.
5. Ondersteunende middelen (slides/demo) zijn effectief en visueel overzichtelijk.
6. Er is sprake van actieve interactie (oogcontact, inspelen op vragen/verwarring).
   
   
7. Vragen worden aandachtig beluisterd en relevant beantwoord met logische argumenten.
8. De houding bij het beantwoorden is professioneel, rustig en zelfverzekerd.

🛠️ Opdracht

Vul de checklist in: http://www.wijs.ovh/generic-forms/index.html?form=K2W2

📤Inleveren

1. Ingevulde checklist in PDF
2. Bewijzen (video) die je in je checklist hebt vermeld.
3. Eventueel aanvullende bewijzen/bijlagen.

K2W3 Reflecteren

Reflecteert op het werk

💡 Uitleg

Je maakt een verbtervoorstel voor je project.

De volledige uitleg wordt tijdens de les gegeven en besproken.

....

✔️ Checklist

1. Je benoemt zowel een specifiek eigen positief- als verbeterpunt (onderbouwd).
2. Je benoemt zowel een specifiek team positief- als verbeterpunt (onderbouwd).
3. Je legt een duidelijk verband tussen jouw gedrag, het resultaat en mogelijke verbeteringen.
   
   
4. Je benoemt specifiek ontvangen feedback en vertaalt dit naar concrete verbeteracties.
5. Er is bewijs dat je zichtbaar zaken hebt aangepast op basis van de feedback.
6. Je toont gedurende het gehele proces een open en lerende houding.
   

🛠️ Opdracht

Maak de reflectie.

Vul de checklist in: http://www.wijs.ovh/generic-forms/index.html?form=K2W3

📤Inleveren

1. Je reflectie in PDF.
2. Ingevulde checklist in PDF
   
3. Eventueel aanvullende bewijzen/bijlagen.

Examen Eindgesprek

Het Eindgesprek: Tips & Vragen

Het eindgesprek is de afronding van je examen. De assessoren gebruiken dit gesprek om vast te stellen of je over de juiste competenties beschikt.

Authenticiteit

Tijdens het eindgesprek wordt kritisch gekeken naar de authenticiteit. De assessoren bepalen of het opgeleverde werk daadwerkelijk door jouzelf is gemaakt en of je de gemaakte keuzes kunt onderbouwen.

Kansen bij onvolkomenheden

Mochten er tijdens het beoordelen van je portfolio kleine zaken onjuist zijn of ontbreken, dan wordt hier tijdens het gesprek naar gevraagd. Dit is jouw kans om mondeling aan te tonen dat je de stof beheerst, wat je score positief kan beïnvloeden. Let op: door de beperkte tijd kunnen niet alle acht werkprocessen uitgebreid behandeld worden; focus je dus op de kern.

Focus van het gesprek

In principe kan elke onderdeel van je examen bevraagd worden. Vanwege de beperkte tijd (meestal 20-30 minuten) maken de assessoren vaak een selectie van een aantal werkprocessen waar zij meer over willen weten.

Zorg dat je jouw portfolio direct kunt presenteren. Bereid je extra goed voor op onderdelen waarvan je zelf al vermoedt dat ze minder sterk zijn. Zorg dat je applicatie werkend klaarstaat en dat alle documentatie direct oproepbaar is.

---

Checklist voor het gesprek

• Laptop volledig opgeladen en lader binnen handbereik?
• Systeemvrije dag? (Windows/Software-updates vooraf uitgevoerd?)
• Lokale server en tools operationeel? (XAMPP, VS Code, Git, etc.)
• Portfolio lokaal beschikbaar? (Voorkom vertraging door downloaden of unzippen)
• Werking van de applicatie gecontroleerd in de examensituatie?
• Vergeet je geldig identiteitsbewijs niet!

---

Vragen die je kunt verwachten

Hoewel de vragen variëren per project, zijn dit de meest voorkomende onderwerpen die de assessoren behandelen:

Algemeen

• Wie waren de belanghebbenden (stakeholders) bij dit project?
• Hoe verliep het contact met de opdrachtgever en/of collega's?
• Ben je tevreden met de kwaliteit van het eindproduct? Wat zou een 'versie 2.0' bevatten?
• Wat was, technisch gezien, het meest uitdagende onderdeel?
• Wat is de belangrijkste les die je tijdens dit examen hebt geleerd?
• Welk advies zou je een student geven die volgend jaar dit examen doet?

Planning & Organisatie

• In hoeverre kwam de realiteit overeen met je initiële planning?
• Welke onvoorziene omstandigheden dwongen je om je planning aan te passen?
• Je gaf in de planning aan dat je "abc" op een bepaalde dag zou afronden; kun je laten zien hoe dat is verlopen?

Ontwerp & Voorbereiding

• Op welke punten wijkt het eindproduct af van het technisch ontwerp en waarom?
• Waarom heb je specifiek voor deze database-structuur (ERD) gekozen?
• Hoe heeft het ontwerp je geholpen tijdens de realisatiefase?

Realisatie (Code & Techniek)

• Kun je de werking van User Story X demonstreren in de applicatie?
• Kun je de code van je belangrijkste algoritme of functie toelichten?
• Stel dat ik de functionele eis "..." toevoeg, waar in de code zou je dit dan implementeren?
• Hoe heb je de veiligheid van de gegevens gewaarborgd? (SQL-injection / XSS)
• Volgens welke code-conventies of standaarden heb je geschreven?
• Kun je de tabelrelaties in je database laten zien via PHPMyAdmin?

Testen & Kwaliteit

• Kun je Test X uit je testrapport nu 'live' uitvoeren?
• Wat was de meest kritieke bug die je tijdens het testen vond en hoe heb je deze opgelost?

Communicatie & Reflectie

• Hoe heb je de gemaakte afspraken met de opdrachtgever vastgelegd?
• Hoe heb je bepaald welk technisch niveau je presentatie moest hebben voor de doelgroep?
• Welke feedback kreeg je tijdens je voortgangsgesprekken en hoe is dit verwerkt in de code?
• Als je naar je eigen proces kijkt, wat zijn dan je drie belangrijkste verbeterpunten voor een volgend project?

Gids: De Code Walkthrough

Als de assessor vraagt: "Laat de code van je inlogsysteem eens zien", is het verleidelijk om simpelweg door de file te scrollen. Doe dit niet. Volg de 'Happy Path' methode.

1. Volg de 'Happy Path'

Leg je code uit aan de hand van een gebruikersactie. Begin niet bij regel 1, maar vertel een verhaal:

• Input: "De gebruiker vult het formulier in op login.php."
• Verwerking: "Zodra er op verzenden wordt geklikt, vang ik de data op en controleer ik eerst met htmlspecialchars() of er geen schadelijke scripts in staan."
• Database: "Daarna gebruik ik een Prepared Statement om de gebruiker op te zoeken in de database. Dit voorkomt SQL-injection."
• Resultaat: "Als het wachtwoord klopt via password_verify(), maak ik een $_SESSION aan en stuur ik de gebruiker naar het dashboard."

2. Benoem je 'Best Practices'

Assessoren 'vinken' begrippen af in hun hoofd. Zorg dat je deze termen letterlijk noemt terwijl je de code aanwijst:

• Don't Repeat Yourself (DRY): "Zoals je hier ziet, gebruik ik include 'header.php', zodat ik de navigatiebalk maar op één plek hoef te onderhouden."
• Separation of Concerns: "Ik heb mijn database-connectie in een apart bestand (db.php) gezet, zodat mijn logica gescheiden blijft van mijn configuratie."
• Datatypen & Validatie: "Bij het invoeren van een kilometerstand (of ticket-ID) controleer ik eerst of het wel echt een int (integer) is."

3. Wees eerlijk over fouten of 'TODO's'

Als een assessor een stukje code aanwijst dat niet perfect is, raak dan niet in paniek. Gebruik het als een kans om je reflectievermogen te tonen:

"Klopt, op deze plek is de validatie nog beperkt. Als ik meer tijd had gehad, had ik hier een Regex-controle toegevoegd om te checken of het kenteken wel aan het Nederlandse formaat voldoet. Dat staat ook in mijn verbeterpunten beschreven."

Presentatie-hacks:

• Zoom in: Gebruik CTRL + in VS Code zodat de assessoren je code goed kunnen lezen op afstand of op een kleiner scherm.
• Dark Mode: Zorg dat je editor een prettig contrast heeft.
• Tabbladen: Zet de belangrijkste bestanden (bijv. db.php, index.php en je CSS) alvast open in je editor voordat je de kamer binnenstapt.

---

Met deze voorbereiding en de checklists hierboven straal je zelfverzekerdheid uit. Je laat zien dat je niet alleen een 'coder' bent, maar een beginnend professional die begrijpt wat hij bouwt en waarom.

Gids: Het ERD Presenteren

De assessor wil niet horen welke tabelnamen je hebt, maar waarom de relaties tussen die tabellen essentieel zijn voor de werking van de applicatie.

1. De "Single Point of Truth"

Begin met de kern: de gebruikers. Leg uit hoe de verschillende entiteiten met elkaar verbonden zijn:

• De Entiteiten: "Ik heb gekozen voor drie kerntabellen: Users, Tickets (of Meldingen) en Categories."
• De Relatie (1-op-N): "De belangrijkste relatie is die tussen de gebruiker en het ticket. Dit is een één-op-veel relatie: één gebruiker kan meerdere meldingen maken, maar een melding hoort altijd bij één specifieke gebruiker."
• Foreign Keys: "Om dit technisch te realiseren, sla ik het user_id op als Foreign Key in de ticket-tabel. Hiermee waarborg ik de data-integriteit."

2. Normalisatie en Efficiëntie

Laat zien dat je hebt nagedacht over een schone database:

"Ik heb de categorieën (Hardware/Software) in een aparte tabel gezet in plaats van als tekst in de ticket-tabel. Hierdoor is mijn database genormaliseerd. Als we later een categorienaam willen aanpassen, hoeft dat maar op één plek in de database en verandert het automatisch voor alle gekoppelde tickets."

3. Voorbereiding op "Stel dat..." vragen

Assessoren testen je ontwerp vaak door een wijziging voor te stellen:

• Vraag: "Stel dat een ticket door meerdere monteurs tegelijk opgepakt moet worden?"
• Jouw antwoord: "In mijn huidige ontwerp is dat een 1-op-N relatie (één monteur per ticket). Om dat mogelijk te maken, zou ik een koppeltabel moeten toevoegen om er een N-op-M relatie (veel-op-veel) van te maken."

Presentatie-hacks voor je ERD:

• Pointer: Gebruik je muis (of een laserpointer) om de lijnen tussen de tabellen aan te wijzen terwijl je de relatie benoemt.
• PK/FK: Wijs expliciet de Primary Key (het gouden sleuteltje) en de Foreign Key aan.
• Legenda: Zorg dat je ERD duidelijk de datatypen laat zien (bijv. INT, VARCHAR(255), DATETIME).

---

Laatste tip: Oefen deze uitleg één keer hardop. Als je de termen Primary Key, Foreign Key en Eén-op-veel relatie vloeiend gebruikt, heb je de helft van de punten voor je database-ontwerp al binnen.

De 5 Meest Gemaakte Fouten

(en hoe ze te voorkomen)

Veel studenten gaan de mist in op zaken die niets met hun code te maken hebben, maar alles met hun houding en voorbereiding.

1. "Ik weet het niet" (Zonder vervolg)

Het is oké om een technisch detail even niet te weten, maar "Ik weet het niet" is een dooddoener.

• De Oplossing: Zeg: "Ik weet de exacte PHP-functie hiervoor niet uit mijn hoofd, maar ik kan je wel de logica uitleggen van hoe ik het heb opgelost..." of "Dat onderdeel heb ik opgezocht in de documentatie van PHP.net."

2. "Het werkte gisteren nog..."

De grootste nachtmerrie van elke student: een demo die crasht. Vaak komt dit door onverwachte updates of een vergeten database-import.

• De Oplossing: Test je applicatie 15 minuten voor het gesprek op de locatie zelf. Maak een back-up van je database (SQL-export) en zet je code eventueel ook op een USB-stick als extra veiligheid.

3. Te passief afwachten

Studenten die alleen "Ja" of "Nee" antwoorden, dwingen de assessor om te blijven 'trekken'. Dit wekt de indruk dat je niet trots bent op je werk.

• De Oplossing: Neem het initiatief. Als een assessor vraagt naar je inlogscherm, vertel dan ook direct waarom je voor die specifieke beveiliging hebt gekozen. Laat zien dat je de expert bent van jouw eigen project.

4. Code laten zien die je niet begrijpt

Als je een stuk code van StackOverflow of AI hebt gebruikt zonder het te begrijpen, val je door de mand zodra de assessor vraagt: "Wat gebeurt er op regel 42?".

• De Oplossing: Gebruik alleen code die je kunt uitleggen. Heb je hulp gehad? Zorg dan dat je elk onderdeel van die code hebt uitgeplozen en kunt verantwoorden.

5. Geen bewijs van testen

Beweren dat je applicatie "bugvrij" is zonder dat je kunt laten zien hoe je dat hebt getest, is ongeloofwaardig.

• De Oplossing: Houd je testrapport bij de hand. Wijs een fout aan die je tijdens het bouwen vond en laat zien hoe je die hebt opgelost. Assessoren houden van studenten die kritisch zijn op hun eigen werk.

---

De "Gouden Regel" voor je gesprek:

"Don't just show, tell why." (Laat niet alleen zien wat je hebt gemaakt, maar vertel vooral waarom je het zo hebt gedaan.)

Je hebt nu de projectbriefing, de technische handleidingen, de code-walkthrough gids en de ERD-presentatie. Je bent er helemaal klaar voor. Veel succes met je examen!

Examenprojecten

Overview project 1 t/m 12

StagePortaal (TalentMatch)

TalentMatch verbindt lokale MBO-studenten met leerbedrijven door stagevacatures overzichtelijk en AVG-proof aan te bieden. Bedrijven beheren hun eigen vacatures en reacties, terwijl studenten via een persoonlijk dashboard direct kunnen solliciteren. De opdracht focust op een zakelijke uitstraling met specifieke visuele eisen zoals een sidebar-navigatie en interactieve vacature-kaarten.

ServiceDesk Portaal (FixIT)

FixIT is een ticketingsysteem waarmee medewerkers van een logistiek centrum technische storingen eenvoudig kunnen melden bij de IT-afdeling. IT-beheerders krijgen een centraal overzicht om meldingen te prioriteren, te bewerken en van oplossingen te voorzien. De technische uitdaging ligt in het bouwen van een veilige administratie-omgeving met handige filters die werken via URL-parameters.

Fleet Management Portaal (DriveSafe)

DriveSafe wordt gebruikt door chauffeurs om defecten aan voertuigen direct via hun telefoon of tablet door te geven aan de werkplaats. Monteurs beheren de reparaties en prioriteren meldingen op basis van de urgentie voor de verkeersveiligheid. Het project vereist een industriële interface die geoptimaliseerd is voor touchscreens en sterke gegevensvalidatie voor kentekens en kilometerstanden.

Voorraad & Defecten Beheer (StockCheck)

StockCheck is een meldingsportaal voor eventlocaties waarmee vloerpersoneel defecte apparatuur of lage voorraden direct kan rapporteren aan de technische dienst en inkoop. Het ontwerp volgt een "Mobile First" gedachte met een zwevende navigatiebalk voor optimaal gebruiksgemak tijdens het werk. De kern van de opdracht is het correct koppelen van specifieke zalen en locaties aan de binnengekomen meldingen.

Toernooi Planner (MatchPoint)

MatchPoint vervangt handmatige papieren schema's door een digitaal platform waar tennisspelers hun wedstrijden en actuele poulestanden kunnen volgen. De wedstrijdleiding voert uitslagen in, wijst banen toe en bewaakt de voortgang van het toernooi. Technisch is dit project uitdagend vanwege de complexe SQL-logica die nodig is om ranglijsten te berekenen op basis van gewonnen sets.

Real-time Feedback Systeem (PulseCheck)

PulseCheck verzamelt korte klantbeoordelingen via QR-codes op de winkelvloer om de prestaties van filialen direct in kaart te brengen. Klanten vullen anoniem hun score en toelichting in, waarna bedrijfsleiders de resultaten per locatie analyseren in een afgeschermd dashboard. Het project vereist een sterke focus op mobiele gebruikerservaring en beveiliging tegen kwaadaardige tekstinvoer.

Bibliotheek Beheersysteem (BookFlow)

BookFlow laat leerlingen een digitale catalogus doorzoeken en boeken reserveren, terwijl mediabeheerders de uitleningen en innames registreren. Een cruciaal onderdeel is de automatische berekening van inleverdata en het signaleren van boeken die te laat zijn teruggebracht. Je leert hier werken met complexe SQL-joins om gegevens van boeken, leningen en gebruikers in één overzicht te combineren.

Bezichtigingsbeheer (KeyMaster)

KeyMaster wordt gebruikt door makelaars om woningbezichtigingen in te plannen en de status van sleutels en aanvragen efficiënt bij te houden. Klanten kunnen online aanvragen indienen voor woningen en in hun eigen dashboard de status van hun afspraken inzien. De nadruk ligt op privacybescherming van gevoelige gegevens en het werken met specifieke datum-filters in de database.

Voorraad- en Distributiebeheer (Vuller)

Vuller is een portaal voor vrijwilligers van een stichting waarmee zij hun dagelijkse bezorgroutes voor voedselpakketten kunnen inzien en leveringen kunnen afmelden. De logistiek manager wijst adressen toe aan bezorgers en volgt live de voortgang per wijk. Het systeem stroomlijnt het proces door te garanderen dat elke levering aan de juiste vrijwilliger is gekoppeld.

E-sports Arena (Respawn & Conquer)

Respawn & Conquer fungeert als de centrale bron voor online toernooien, waar gamers hun persoonlijke uitslagen en de actuele competitie-ranking kunnen volgen. Toernooi-organisatoren gebruiken de match-maker interface om spelers te koppelen, lobby-codes te delen en winnaars te valideren. De technische diepgang zit in de database-relaties waarbij twee unieke spelers aan één wedstrijdrecord worden gekoppeld.

Sneaker Marketplace (SoleExchange)

SoleExchange biedt leden van de community de mogelijkheid om exclusieve sneakers te koop aan te bieden aan andere verzamelaars en biedingen uit te brengen op beschikbare items. Medewerkers treden op als admins om de echtheid van de schoenen te controleren voordat de verkoop definitief wordt goedgekeurd. Veiligheid is bij dit project essentieel om te voorkomen dat gebruikers onrechtmatig biedingen van anderen aanpassen of verwijderen.

Studie-Portaal (StudyBuddy)

StudyBuddy helpt studenten hun studietijd te organiseren door vakken, taken en cijfers centraal in één overzichtelijk dashboard te beheren. De applicatie berekent automatisch gemiddelden en geeft visuele waarschuwingen wanneer deadlines kritiek worden of cijfers onvoldoende zijn. Dit project is bij uitstek geschikt voor wie zijn vaardigheden in wiskundige backend-logica en database-integriteit wil bewijzen.

 

Complexiteit

P#	Naam (MVP)	Uren (Briefing)	Complexiteit	Kern-uitdaging (W3/Realisatie)
1	StagePortaal (TalentMatch)	40u	Medium	KPI-berekeningen via COUNT() query [11].
2	ServiceDesk Portaal (FixIT)	40-45u	Medium	1-op-N relatie en SQL filtering via GET parameters [12, 19].
3	Fleet Management (DriveSafe)	40-45u	Medium	Inputvalidatie voor kentekens en kilometerstanden [13].
4	Voorraad & Defecten (StockCheck)	40-45u	Medium	Mobile First layout en koppeling van zalen aan meldingen [20, 21].
5	Toernooi Planner (MatchPoint)	40-45u	Hoog	N-op-M relaties en sorteren op complexe poulestanden [6, 15].
6	Feedback Systeem (PulseCheck)	40-45u	Medium/Hoog	Anonieme data-entry en gemiddelde scores berekenen per filiaal [22, 23].
7	Bibliotheek Beheer (BookFlow)	40-45u	Hoog	Datum-logica (vandaag + 28 dagen) en SQL JOINs over 3 tabellen [17].
8	Bezichtigingsbeheer (KeyMaster)	40-45u	Medium/Hoog	SQL datum-functies (CURDATE) en strikte autorisatie-checks [9, 18].
9	Distributiebeheer (Vuller)	40-45u	Medium/Hoog	Live statistieken (% bezorgd) en route-autorisatie [24].
10	E-sports Arena (Respawn)	40-45u	Hoog	Match-tabel met twee verwijzingen naar één player-tabel [25].
11	Sneaker Marketplace (SoleExchange)	40-45u	Hoog	Biedings-systeem (N-op-M) en beveiliging tegen ID-manipulatie [26, 27].
12	Studie-Portaal (StudyBuddy)	40-45u	Medium/Hoog	Wiskundige backend-berekeningen voor gemiddelden [28].

Project 1 - StagePortaal

Projectbriefing: TalentMatch

Datum: 11 december 2025

Opdrachtgever: Ondernemersvereniging "MKB Regio Connect"

Contactpersoon: Dhr. J. van de Velde (Voorzitter)

---

1. Achtergrond en Probleemstelling

Onze ondernemersvereniging vertegenwoordigt 50+ lokale bedrijven. Wij merken dat de aansluiting tussen lokale MBO-studenten en onze leerbedrijven stroef verloopt. Bedrijven zoeken stagiairs, maar bereiken de scholen lastig. Studenten weten vaak niet welke leuke bedrijven er in de buurt zitten.

Momenteel houden we vacatures bij in een Excel-sheet en worden CV’s via e-mail heen en weer gestuurd. Dit is onoverzichtelijk, foutgevoelig en voldoet niet aan de privacywetgeving (AVG).

2. Doelstelling

Wij zoeken een webontwikkelaar die voor ons een Minimum Viable Product (MVP) kan bouwen van een online stageplatform: "TalentMatch".

Het doel is een webapplicatie waar bedrijven zelf hun vacatures kunnen plaatsen en beheren, en waar studenten eenvoudig kunnen reageren. Het systeem moet laagdrempelig, overzichtelijk en veilig zijn.

3. Doelgroepen

1. Studenten: Willen zoeken naar stages en direct reageren zonder gedoe.

2. Bedrijven: Willen vacatures plaatsen, aanpassen en zien wie er gereageerd heeft.

4. Gewenste Functionaliteiten (Must-Haves)

Wij verwachten in de eerste versie (MVP) minimaal de volgende functies:

• Registratie & Login:

  • Gescheiden accounts voor 'Studenten' en 'Bedrijven'.

  • Veilige inlog (wachtwoorden mogen niet leesbaar zijn voor beheerders).

• Voor Bedrijven:

  • Een eigen dashboard na inloggen.

  • Mogelijkheid om een nieuwe stagevacature toe te voegen (Titel, Omschrijving, Periode, Eisen).

  • Mogelijkheid om eigen vacatures aan te passen of te verwijderen (CRUD).

  • Inzicht in wie er op hun vacatures gereageerd heeft.

• Voor Studenten:

  • Een overzichtspagina van alle actuele vacatures.

  • Een detailpagina per vacature met alle informatie.

  • Een knop/formulier om direct te reageren (solliciteren) op een vacature.

  • Een overzicht in hun eigen dashboard waarop ze hebben gereageerd en wat de status is.

• Algemeen:

  • Het platform moet werken op desktop en mobiel (Responsive).

5. Technische Eisen & Randvoorwaarden

Omdat wij werken met beperkte budgetten voor hosting, hebben wij de volgende technische voorkeuren:

• Taal: PHP (versie 8+).

• Database: MySQL / MariaDB.

• Design: Mag gebruik maken van standaard CSS of een licht framework, maar moet wel een eigen 'look & feel' hebben die past bij een zakelijke markt (zie bijlage).

• Beveiliging: Gezien we met persoonsgegevens werken (namen, e-mailadressen), is beveiliging tegen SQL-injectie en sessie-hijacking cruciaal.

• Privacy: Het systeem moet 'AVG-proof' ontworpen worden (geen onnodige data opslaan).

6. Budget en Planning

Wij begrijpen dat softwareontwikkeling tijd kost. Echter, wij willen graag snel live met een eerste versie.

• Beschikbaar budget: Wij gaan uit van circa 40 uur ontwikkeltijd voor deze eerste versie.

• Deadline: Wij ontvangen graag een oplevering binnen 6 weken na goedkeuring van de offerte.

7. Gevraagde actie

Graag ontvangen wij van u:

1. Een Plan van Aanpak (inclusief functioneel ontwerp/schetsen).

2. Een Ureninschatting per onderdeel.

3. Een Offerte voor de realisatie van dit MVP.

---

BIJLAGE: Specifieke Design & Interface Wensen

Let op: Deze wensen zijn cruciaal voor de acceptatie van het eindproduct.

Onze marketingafdeling heeft net een nieuwe huisstijl ontwikkeld. Wij accepteren geen standaard "Bootstrap-blauw" of grijze templates. Het ontwerp moet voldoen aan de volgende specifieke visuele eisen:

1. Verplicht Kleurenpalet: De applicatie moet gebruikmaken van onze specifieke huisstijlkleuren. Gebruik CSS-variabelen (:root) om dit consistent toe te passen:

   • Primaire Actiekleur (Knoppen/Links): #E63946 (Koraalrood).

   • Hoofdkleur (Headers/Navigatie): #1D3557 (Diep Oceaanblauw).

   • Achtergrond Dashboards: #F1FAEE (Off-white/Mint).

   • Status Meldingen:

     • Succes/Open: #2A9D8F (Groen).

     • Error/Gesloten: #E63946 (Rood).

2. Dashboard Layout (Sidebar Navigatie): Voor het ingelogde gedeelte (Bedrijf & Student) willen wij geen navigatiebalk bovenin de pagina.

   • Wij willen een verticale sidebar aan de linkerkant van het scherm die altijd zichtbaar blijft.

   • In deze sidebar staat het logo, de menu-items onder elkaar, en onderaan de "Uitloggen" knop.

3. De "Vacature-Kaart": Op de overzichtspagina voor studenten willen wij de vacatures niet onder elkaar in een simpele tabel zien.

   • Toon vacatures als "Cards" (Tegels) in een grid van 2 of 3 naast elkaar (op desktop).

   • Elke kaart moet een "Status Badge" in de rechterbovenhoek hebben (bijv: "Nieuw" = Groen).

4. Interactieve Feedback:

   • Alle knoppen moeten een duidelijke :hover state hebben.

   • Na verzending van een formulier moet er een gekleurde notificatiebalk verschijnen (Feedback aan de gebruiker).

5. De "Welkom" Widget: Op het dashboard van het bedrijf willen wij bovenaan direct drie grote cijfers zien (KPI's):

   1. Totaal aantal vacatures.

   2. Aantal openstaande sollicitaties.

   3. Datum van laatste login.

---

Tips voor jouw Examenportfolio

Dit document kun je direct gebruiken om je examen-criteria af te vinken:

1. W1 (Klantvraag & Planning):

   • De briefing bevat je Functionele Eisen (wat moet het doen?) en Niet-functionele eisen (AVG/Design). Noteer deze letterlijk in je PvA.

   • De klant noemt een budget van 40 uur. Maak een planning die hierop uitkomt (bijv. 10 uur database, 10 uur login, 20 uur CRUD/Design).

2. W2 (Ontwerp):

   • Teken je wireframes exact zoals de klant vraagt: met een Sidebar en Cards. Als je dit niet doet, voldoe je niet aan de "Specificaties van de klant".

3. W3 (Realisatie):

   • Let op de "KPI Widget" (Eis 5 in de bijlage). Dit dwingt je om een COUNT() query te schrijven. Dit is een uitstekend bewijs van SQL-kennis voor de examencommissie.

4. Verantwoording:

   • Als je bij het CGI-gesprek de vraag krijgt: "Waarom heb je deze kleuren gekozen?", is het antwoord: "Dit was een harde eis uit de briefing van de opdrachtgever."

Project 2 - ServiceDesk Portaal

Projectbriefing

Projectnaam: ServiceDesk Portaal "FixIT"

Datum: 11 december 2025

Opdrachtgever: Logistiek Centrum "De Haven"

Contactpersoon: Mevr. S. Bakker (Hoofd Automatisering)

---

1. Achtergrond en Probleemstelling

Binnen ons logistiek centrum werken 80 medewerkers die dagelijks afhankelijk zijn van scanners, computers en printers. Als er iets stuk gaat, lopen medewerkers nu naar de IT-afdeling of sturen ze een WhatsApp-bericht naar één van de beheerders.

Hierdoor raken meldingen kwijt, weten we niet wat de status is van een reparatie en hebben we geen inzicht in hoeveel storingen er eigenlijk zijn. Dit moet geprofessionaliseerd worden.

2. Doelstelling

Wij willen een web-based ticketingsysteem (FixIT) laten ontwikkelen.

Medewerkers moeten zelf eenvoudig een storing ("Ticket") kunnen aanmaken. De IT-afdeling moet deze tickets centraal kunnen beheren, prioriteren en afmelden.

3. Doelgroepen

1. Medewerkers (Gebruikers): Willen snel melden dat hun PC stuk is en zien wanneer het gemaakt is.

2. IT-Support (Beheerders): Willen een lijst met openstaande taken, gesorteerd op prioriteit.

4. Gewenste Functionaliteiten (Must-Haves)

Voor het MVP verwachten wij de volgende functies:

• Authenticatie:

  • Inlogscherm voor alle gebruikers.

  • Rol-verdeling in de database: user (medewerker) en admin (IT-support).

• Voor Medewerkers:

  • Dashboard met overzicht van eigen gemelde tickets.

  • Formulier om een nieuw ticket aan te maken (Onderwerp, Beschrijving, Categorie: Hardware/Software).

  • Zichtbare status van hun ticket (bijv. "In Behandeling" of "Opgelost").

• Voor IT-Support (Admins):

  • Centraal dashboard met alle openstaande tickets van het hele bedrijf.

  • Detailpagina per ticket om deze te bewerken.

  • Mogelijkheid om de Status (Open/Closed) en Prioriteit (Laag/Hoog) aan te passen.

  • Mogelijkheid om een "Admin Opmerking" (oplossing) toe te voegen aan het ticket.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) in combinatie met MySQL.

• Code Architectuur: Gebruik van includes voor header/footer om dubbele code te voorkomen.

• Veiligheid: Alle invoer (forms) moet 'sanitized' worden om XSS te voorkomen. Gebruik Prepared Statements voor SQL.

• Data Integriteit: Een ticket moet altijd gekoppeld zijn aan de gebruiker die het heeft aangemaakt (Relational Database ID).

6. Budget en Planning

• Tijdsinvestering: Wij schatten dit project op circa 40-45 uur ontwikkeling.

• Oplevering: Deadline in overleg, bij voorkeur binnen 5 weken.

7. Gevraagde actie

1. Lever een Functioneel Ontwerp (wat gaat het systeem doen?).

2. Lever een Technische Schets (ERD van de database + Wireframes).

3. Realiseer de applicatie en lever de broncode op via Git.

---

BIJLAGE: Specifieke Design & Interface Wensen

Omdat het systeem de hele dag open staat op de schermen van IT-support, zijn de visuele eisen strikt. Wij willen een professionele "SaaS" (Software as a Service) uitstraling.

1. Kleurcodering van Prioriteiten (Must-have):

   • In de ticket-lijsten moet de prioriteit direct visueel herkenbaar zijn d.m.v. gekleurde labels ('badges') of randen:

     • Laag: Blauw of Grijs.

     • Normaal: Groen.

     • Hoog / Spoed: Fel Rood (#D32F2F).

2. De "Top-Bar" Navigatie:

   • In tegenstelling tot veel andere systemen, willen wij geen sidebar. Wij willen een strakke, donkere navigatiebalk (Header) over de volledige breedte bovenin.

   • Rechts in deze balk moet de naam van de ingelogde gebruiker staan met een klein profiel-icoon.

3. Ticket Detail Weergave:

   • Wanneer je op een ticket klikt, moet de pagina in twee kolommen verdeeld zijn:

     • Links (70%): De beschrijving van het probleem en de oplossing.

     • Rechts (30%): Een "Infobox" met metadata (Datum aangemaakt, Naam melder, Huidige Status).

   • Toelichting: Dit toont aan dat je met Grid of Flexbox kolommen kunt maken.

4. De "Admin Quick-Filter":

   • Boven de lijst met tickets moeten 3 grote knoppen staan waarmee de admin direct de lijst kan filteren:

     1. "Alles tonen"

     2. "Alleen Spoed"

     3. "Alleen Openstaand"

   • Dit vereist het gebruik van GET parameters in de URL (bijv: dashboard.php?filter=spoed) en de verwerking daarvan in je SQL query.

---

Tips voor jouw Examenportfolio

Waarom is deze opdracht geschikt voor je examen?

1. Complexiteit (W3): Het systeem vereist dat je een gebruiker (User ID) koppelt aan een ticket. Dit is een 1-op-N relatie. Zonder deze relatie werkt het systeem niet.

2. SQL Parameters (W3): De eis "Admin Quick-Filter" (punt 4 in de bijlage) is de perfecte manier om te laten zien dat je veilige SQL-queries kunt bouwen op basis van input (WHERE status = ?).

3. Veiligheid (W1/W3): Omdat gebruikers input leveren (tekst in tickets), moet je "Input Sanitization" (htmlspecialchars) toepassen om XSS-aanvallen te voorkomen. Dit is een verplicht onderdeel van de exameneisen.

4. Testen (W4): Je kunt heel makkelijk scenario's testen:

   • "Als ik inlog als medewerker, mag ik de 'Verwijder Ticket' knop NIET zien."

   • "Als ik filter op Spoed, mag ik geen blauwe tickets zien."

Project 3 - Fleet Management Portaal

Projectbriefing

Projectnaam: Fleet Management Portaal "DriveSafe"

Datum: 18 december 2025

Opdrachtgever: Transportbedrijf "SnelWeg Logistiek"

Contactpersoon: Dhr. R. Verhoeven (Wagenparkbeheerder)

---

1. Achtergrond en Probleemstelling

SnelWeg Logistiek heeft 60 chauffeurs op de weg. Chauffeurs merken regelmatig gebreken op aan hun voertuig (bijv. een kapotte lamp, rammelende motor of een deuk). Momenteel worden deze gebreken doorgegeven via briefjes op het planbord of mondeling in de kantine.

Hierdoor worden reparaties vergeten, rijden chauffeurs onveilig rond en heeft de werkplaats geen overzicht van de onderhoudsdruk. Dit proces moet geprofessionaliseerd worden.

2. Doelstelling

Wij willen een web-based wagenpark-portaal (DriveSafe) laten ontwikkelen.

Chauffeurs moeten zelf eenvoudig een defect ("Melding") kunnen registreren. De werkplaats (monteurs) moet deze meldingen centraal kunnen inplannen, prioriteren en afmelden.

3. Doelgroepen

1. Chauffeurs (Gebruikers): Willen onderweg via tablet of telefoon snel een defect melden en zien wanneer hun voertuig weer veilig is.

2. Monteurs (Beheerders): Willen een lijst met openstaande reparaties, gesorteerd op urgentie voor de verkeersveiligheid.

4. Gewenste Functionaliteiten (Must-Haves)

Voor het MVP verwachten wij de volgende functies:

• Authenticatie:

  • Inlogscherm voor alle medewerkers.

  • Rol-verdeling in de database: chauffeur (user) en monteur (admin).

• Voor Chauffeurs:

  • Dashboard met overzicht van eigen actieve meldingen.

  • Formulier "Defect Melden" (Kenteken, Kilometerstand, Omschrijving, Type: Mechanisch/Elektrisch/Carrosserie).

  • Statusoverzicht van hun melding (bijv. "In Afwachting" of "Gereed").

• Voor Monteurs (Admins):

  • Centraal dashboard met alle defecte voertuigen van het hele bedrijf.

  • Detailpagina per melding om de reparatie te verwerken.

  • Mogelijkheid om de Status (Open/In Reparatie/Gereed) en Urgentie (Veiligheidsrisico: Ja/Nee) aan te passen.

  • Mogelijkheid om een "Monteur Notitie" (vervangen onderdelen) toe te voegen.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) in combinatie met MySQL.

• Code Architectuur: Gebruik van includes voor navigatie en database-connectie.

• Veiligheid: Gebruik van PDO Prepared Statements is verplicht. Alle output via htmlspecialchars().

• Data Integriteit: Elke melding moet gekoppeld zijn aan de user_id van de chauffeur (Relational Database ID).

6. Budget en Planning

• Tijdsinvestering: Geschat op circa 40-45 uur ontwikkeling.

• Oplevering: Deadline binnen 5 weken na start.

7. Gevraagde actie

1. Lever een Functioneel Ontwerp (user stories en procesflow).

2. Lever een Technische Schets (ERD van de database + Wireframes).

3. Realiseer de applicatie en lever de broncode op via Git.

---

BIJLAGE: Specifieke Design & Interface Wensen

De werkplaats gebruikt grote touchscreens. De interface moet een "Industriële & Clean" uitstraling hebben.

1. Kleurcodering van Urgentie:

   • In de lijsten moet de ernst van het defect direct visueel herkenbaar zijn:

     • Geen risico: Blauw of Grijs (bijv. cosmetisch defect).

     • Aandacht nodig: Oranje (bijv. onderhoud binnenkort).

     • ONVEILIG / STOP: Fel Rood (#D32F2F) (bijv. remproblemen).

2. De Sidebar Navigatie:

   • Wij willen een vaste sidebar aan de linkerkant (Dark Mode). Bovenin de sidebar staat het bedrijfslogo.

   • Onderin de sidebar moet de naam van de ingelogde chauffeur/monteur staan met de uitlogknop.

3. Melding Detail Weergave (Flexbox):

   • Bij het bekijken van een melding moet de informatie verdeeld zijn met kolommen:

     • Links (60%): De uitgebreide omschrijving en de werkplaats-notities.

     • Rechts (40%): Technische metadata (Kenteken, Kilometerstand, Datum melding).

4. De "Workshop Quick-Filter":

   • Boven de lijst moeten 3 tabs staan waarmee de monteur de lijst kan filteren:

     1. "Alle Voertuigen"

     2. "Directe Veiligheidsrisico's"

     3. "Wacht op Reparatie"

   • Dit moet werken via GET parameters in de URL (bijv: overzicht.php?filter=gevaar) en verwerkt worden in de SQL-query.

---

Tips voor jouw Examenportfolio

Waarom is deze opdracht geschikt voor je examen?

1. Complexiteit (W3): De relatie tussen een voertuigmelding en de chauffeur (User ID) is een 1-op-N relatie, essentieel voor het aantonen van database-vaardigheden.

2. SQL Parameters (W3): Het bouwen van de "Workshop Quick-Filter" laat zien dat je veilige SQL-queries kunt schrijven op basis van URL-input.

3. Validatie (W3): Input zoals kilometerstanden (cijfers) en kentekens (patronen) vereisen specifieke validatie, wat een sterk punt is in je documentatie.

4. Testen (W4): Test scenario's: "Kan een chauffeur de reparatie-notitie van een monteur aanpassen?" of "Toont het filter correct alleen de voertuigen met een veiligheidsrisico?".

Project 4 - Voorraad & Defecten Beheer

Projectbriefing

Projectnaam: Voorraad & Defecten Beheer "StockCheck"

Datum: 18 december 2025

Opdrachtgever: Event-locatie "De Festiviteit"

Contactpersoon: Dhr. J. Willems (Operationeel Manager)

---

1. Achtergrond en Probleemstelling

Event-locatie "De Festiviteit" beschikt over 12 verschillende zalen en 4 bars. Tijdens events merken kelners en barpersoneel vaak dat apparatuur (zoals een biertap, koffiemachine of verlichting) defect is of dat specifieke voorraad (zoals fusten of glaswerk) kritiek laag is.

Nu wordt dit doorgegeven op bierviltjes of via een rommelige groepsapp. De technische dienst en de inkoper missen hierdoor het overzicht, waardoor events soms starten met kapotte apparatuur of te weinig voorraad.

2. Doelstelling

Wij willen een intern meldingsportaal (StockCheck) laten ontwikkelen.

Personeel moet op de werkvloer direct een melding kunnen maken. De technische dienst en inkoop moeten deze meldingen centraal kunnen beheren, prioriteren en afvinken.

3. Doelgroepen

1. Vloerpersoneel (Gebruikers): Willen direct melden dat een koelkast niet koelt en zien of de melding is opgepakt.

2. Facilitair Beheer (Admins): Willen een lijst met taken (reparaties/bestellingen), gesorteerd op urgentie voor het volgende event.

4. Gewenste Functionaliteiten (Must-Haves)

Voor het MVP verwachten wij de volgende functies:

• Authenticatie:

  • Inlogscherm voor medewerkers.

  • Rol-verdeling in de database: staff (user) en facilitair (admin).

• Voor Vloerpersoneel:

  • Dashboard met een lijst van hun eigen actieve meldingen.

  • Formulier "Nieuwe Melding" (Locatie/Zaal, Omschrijving, Type: Defect/Voorraadtekort).

  • Zichtbare status (bijv. "In wachtrij", "Wordt geregeld", "Afgehandeld").

• Voor Facilitair Beheer (Admins):

  • Centraal overzicht van alle openstaande meldingen van de gehele locatie.

  • Detailpagina om per melding actie te ondernemen.

  • Mogelijkheid om de Status en de Impact (Kritiek/Niet-kritiek) aan te passen.

  • Mogelijkheid om een "Logboek Notitie" (bijv: onderdeel besteld) toe te voegen.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) en MySQL.

• Code Architectuur: Gebruik van includes voor de navigatie en database-instellingen.

• Veiligheid: Verplichte beveiliging tegen SQL-injection via Prepared Statements en XSS via htmlspecialchars().

• Data Integriteit: Elke melding is via een Foreign Key gekoppeld aan de user_id van de melder.

6. Budget en Planning

• Tijdsinvestering: Wij schatten dit project op circa 40-45 uur.

• Oplevering: Prototype binnen 5 weken.

7. Gevraagde actie

1. Lever een Functioneel Ontwerp.

2. Lever een Technische Schets (ERD + Wireframes).

3. Realiseer de applicatie en lever de broncode op via Git.

---

BIJLAGE: Specifieke Design & Interface Wensen

De look & feel moet passen bij een moderne horeca-omgeving: donkere achtergronden met "Neon" accentkleuren voor status-indicatoren.

1. Visuele Impact-indicatie:

   • In de meldingslijst moet de impact direct opvallen:

     • Lage impact: Grijze rand (bijv. kapot lampje in gang).

     • Medium impact: Gele rand (bijv. voorraad fusten bijna op).

     • KRITIEK: Dikke, rode gloed/rand (#FF0000) (bijv. hoofdtap defect vóór bruiloft).

2. De "Floating" Navigatie:

   • Wij willen een zwevende navigatiebalk onderin het scherm (Mobile First gedachte), zodat personeel met hun duim makkelijk tussen "Home" en "Melden" kan schakelen.

   • Op desktop moet deze balk gewoon bovenin vaststaan (sticky top).

3. Melding Detail (Split View):

   • Gebruik CSS Grid voor de detailpagina:

     • Header (100%): De locatie/zaal naam in een groot font.

     • Main (70%): De omschrijving en de admin-notities.

     • Sidebar (30%): Tijdstip van melding, naam medewerker en een dropdown voor de status.

4. De "Manager Filter":

   • Boven de lijst moeten knoppen staan voor snelle filtering via de URL (GET):

     1. "Toon Alles"

     2. "Kritieke Meldingen"

     3. "Alleen Voorraadtekorten"

---

Tips voor jouw Examenportfolio

Waarom is deze opdracht geschikt voor je examen?

1. Complexiteit (W3): De koppeling tussen zalen/locaties en meldingen dwingt je tot een goede relationele database-opzet.

2. SQL Parameters (W3): De "Manager Filter" laat zien dat je variabelen veilig uit de URL kunt halen en kunt binden aan een SQL query.

3. UX/UI (W1): De Mobile First navigatie-eis laat zien dat je kunt werken met Responsive Design en moderne layout-technieken.

4. Testen (W4): Test of een gewone medewerker de status niet zelf stiekem naar "Afgehandeld" kan zetten via de URL of het formulier.

Project 5 - Tournooi Planner

Projectbriefing

Projectnaam: Toernooi Planner "MatchPoint"

Datum: 18 december 2025

Opdrachtgever: Tennisvereniging "De Gravelbijters"

Contactpersoon: Dhr. A. Fedder (Wedstrijdcommissaris)

Student: Joey

---

1. Achtergrond en Probleemstelling

Bij onze tennisvereniging organiseren we jaarlijks het "Club Open" toernooi. Momenteel worden de standen en uitslagen bijgehouden op papieren schema's die in de kantine hangen. Spelers moeten fysiek naar de kantine komen om te zien wanneer ze moeten spelen of wat de stand in de poule is.

De wedstrijdleiding verliest het overzicht bij regenvertragingen en spelers weten vaak niet waar ze aan toe zijn. Dit moet gedigitaliseerd worden in een overzichtelijk portaal.

2. Doelstelling

Wij willen een online toernooisysteem (MatchPoint) laten ontwikkelen.

Spelers moeten hun eigen wedstrijdschema en de actuele standen kunnen bekijken. De wedstrijdleiding moet uitslagen kunnen invoeren, banen kunnen toewijzen en de voortgang bewaken.

3. Doelgroepen

1. Spelers (Gebruikers): Willen hun geplande wedstrijden zien en de uitslagen van hun poule volgen.

2. Wedstrijdleiding (Admins): Willen een overzicht van alle wedstrijden en de mogelijkheid om scores en winnaars te registreren.

4. Gewenste Functionaliteiten (Must-Haves)

Voor het MVP verwachten wij de volgende functies:

• Authenticatie:

  • Inlogscherm voor spelers en organisatie.

  • Rol-verdeling: speler (user) en leider (admin).

• Voor Spelers:

  • Persoonlijk dashboard met eigen geplande wedstrijden.

  • Overzichtspagina met de actuele stand (Punten/Sets) in hun poule.

  • Zichtbare status van de wedstrijd (bijv. "Gepland", "Bezig" of "Gespeeld").

• Voor Wedstrijdleiding (Admins):

  • Centraal dashboard met alle wedstrijden van het toernooi.

  • Detailpagina per wedstrijd om de Score (bijv. 6-4, 6-2) in te voeren.

  • Mogelijkheid om een Baan toe te wijzen (bijv. Baan 1, Baan 2).

  • Knop om een wedstrijd officieel te "Sluiten" (winnaar bepalen).

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) en MySQL.

• Code Architectuur: Gebruik van includes voor de lay-out elementen.

• Veiligheid: SQL-injectie preventie (Prepared Statements) en XSS-bescherming bij het tonen van spelernamen.

• Data Integriteit: Een wedstrijd (match) moet gekoppeld zijn aan minimaal twee users (spelers). Dit is een 1-op-N of N-op-M relatie.

6. Budget en Planning

• Tijdsinvestering: Ontwikkelingstijd van circa 40-45 uur.

• Oplevering: Volledig werkend systeem vóór het begin van het toernooiseizoen.

7. Gevraagde actie

1. Lever een Functioneel Ontwerp.

2. Lever een Technische Schets (ERD met minimaal Users en Matches + Wireframes).

3. Realiseer de applicatie en lever de broncode op via Git.

---

BIJLAGE: Specifieke Design & Interface Wensen

De vereniging wil een sportieve, frisse uitstraling met de kleuren wit, groen en donkerblauw.

1. Status Labels (Badges):

   • In de lijsten moet de status van een partij direct herkenbaar zijn:

     • Gepland: Grijze achtergrond.

     • Bezig: Fel Groene achtergrond (Live).

     • Afgelopen: Donkerblauwe achtergrond.

2. De "Scoreboard" Navigatie:

   • Wij willen een strakke top-navigatie waar in het midden groot de naam van het huidige toernooi staat.

   • Aan de linkerkant de links naar "Mijn Wedstrijden" en aan de rechterkant het profiel van de speler.

3. Match Detail View (2-Koloms):

   • Maak gebruik van een zijpaneel voor extra informatie:

     • Links (75%): Het actuele scoreverloop en de namen van de spelers (groot).

     • Rechts (25%): "Wedstrijd-info" box met de toegewezen Baan, Starttijd en de Scheidsrechter.

4. De "Leiding Quick-Filter":

   • Boven het totaaloverzicht moeten filters staan (via GET parameters):

     1. "Toon Alle Wedstrijden"

     2. "Nu op de Baan (Bezig)"

     3. "Nog Gepland"

---

Tips voor jouw Examenportfolio

Waarom is deze opdracht geschikt voor je examen?

1. Complexiteit (W3): Je werkt met relaties tussen spelers en wedstrijden. Het tonen van een poulestand vereist slimme SQL queries (bijv. ORDER BY gewonnen_sets DESC).

2. Beveiliging (W1/W3): Je moet voorkomen dat een speler via de URL de score van zijn eigen wedstrijd aanpast (autorisatie-check).

3. Gebruikerservaring (W1): Het visueel maken van de status (Bezig vs Gepland) is een belangrijk onderdeel van de front-end eisen.

Project 6 - Real-time Feedback Systeem

Projectbriefing

Projectnaam: Real-time Feedback Systeem "PulseCheck"

Datum: 18 december 2025

Opdrachtgever: Retail Groep "De Markt"

Contactpersoon: Dhr. T. Hendriks (Operationeel Manager)

---

1. Achtergrond en Probleemstelling

Retail Groep "De Markt" wil stoppen met lange, saaie online vragenlijsten waar klanten geen tijd voor hebben. In plaats daarvan willen we "Pulse-Surveys": korte, krachtige vragenlijsten van maximaal 3 vragen die via een QR-code op de winkelvloer direct door klanten kunnen worden ingevuld.

We willen geen standaard pakket zoals SurveyMonkey, omdat we de data direct willen koppelen aan onze eigen filiaalnummers en medewerkers-ID's voor interne prestatie-analyses. De anonimiteit van de klant moet gewaarborgd blijven, maar de data moet wel direct actiegericht zijn voor de bedrijfsleider.

2. Doelstelling

Wij willen een custom-built survey platform (PulseCheck) laten ontwikkelen.

Klanten moeten zonder account een korte vragenlijst kunnen invullen. De bedrijfsleiders moeten in een afgeschermd beheerpaneel de resultaten per filiaal kunnen inzien en analyseren.

3. Doelgroepen

1. Klanten (Anonieme Gebruikers): Willen binnen 30 seconden hun mening geven over de wachttijd en vriendelijkheid.

2. Bedrijfsleiders (Admins): Willen per filiaal zien wat de gemiddelde score is en welke opmerkingen klanten achterlaten.

4. Gewenste Functionaliteiten (Must-Haves)

Voor het MVP verwachten wij de volgende functies:

• Toegang & Authenticatie:

  • De survey zelf is publiek toegankelijk (geen login).

  • Inlogscherm voor admins (bedrijfsleiders) om resultaten te bekijken.

• De Pulse-Survey (Voor Klanten):

  • Invulformulier met 3 verplichte velden: Score (1-5 sterren), Categorie (Service/Prijs/Assortiment) en Toelichting (tekst).

  • Automatische registratie van het filiaal-ID (via een hidden field of URL-parameter).

  • Vriendelijke bedankpagina na verzending.

• Het Dashboard (Voor Admins):

  • Overzicht van alle binnengekomen feedback in een tabel.

  • Berekening van de gemiddelde score per filiaal.

  • Mogelijkheid om een survey-antwoord te markeren als "Gelezen" of "Actie ondernomen".

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) en MySQL.

• Code Architectuur: Gebruik van includes voor de database-connectie en herbruikbare UI componenten.

• Veiligheid: Omdat klanten tekst invoeren, is XSS preventie (htmlspecialchars) cruciaal. Gebruik Prepared Statements voor het opslaan van antwoorden.

• Data Integriteit: Elke feedback-entry moet gekoppeld zijn aan een bestaand filiaal-ID in de database.

6. Budget en Planning

• Tijdsinvestering: Geschat op circa 40-45 uur.

• Oplevering: Prototype binnen 5 weken.

7. Gevraagde actie

1. Lever een Functioneel Ontwerp (wat is de flow van de klant?).

2. Lever een Technische Schets (Database ontwerp + Mobile Wireframes).

3. Realiseer de applicatie en lever de broncode op via Git.

---

BIJLAGE: Specifieke Design & Interface Wensen

Omdat de klant dit op hun eigen telefoon invult, moet de survey 100% geoptimaliseerd zijn voor mobile (Mobile First).

1. Visual Feedback (Rating):

   • De 5-sterren score moet visueel aantrekkelijk zijn. Gebruik kleurverloop:

     • Score 1-2: Rood (Slecht).

     • Score 3: Oranje/Geel (Gemiddeld).

     • Score 4-5: Helder Groen (#2E7D32) (Top).

2. Clean Header:

   • Geen ingewikkelde menu's. Alleen een logo gecentreerd bovenin en een subtiele filiaalnaam eronder.

3. Admin Detail View (70/30 Split):

   • Wanneer een admin op een feedback-item klikt:

     • Links (70%): De volledige toelichting van de klant in een leesbaar font.

     • Rechts (30%): De metadata (Datum/Tijd, Filiaalnummer, IP-adres check).

4. De "Analytics Filter":

   • De admin moet bovenin de lijst kunnen filteren via URL parameters (GET):

     1. "Toon alle scores"

     2. "Alleen Negatief (1-2 sterren)"

     3. "Alleen deze week"

---

Tips voor jouw Examenportfolio

Waarom is deze opdracht geschikt voor je examen?

1. Complexiteit (W3): Je moet omgaan met publieke data-entry (de klant) en geprivilegieerde data-viewing (de admin). De link met filiaal-ID's is een klassieke 1-op-N relatie.

2. SQL Parameters (W3): De "Analytics Filter" dwingt je om veilige SQL te schrijven die reageert op URL-input.

3. Validation & Security (W1/W3): Omdat de survey openstaat voor iedereen, is input-validatie (bijv. maximale tekstlengte) en sanitization essentieel om de database schoon te houden.

Project 7 - Bibliotheek Beheersysteem

Projectbriefing

Projectnaam: Bibliotheek Beheersysteem "BookFlow"

Datum: 18 december 2025

Opdrachtgever: Brede School "Het Leerpark"

Contactpersoon: Mevr. L. de Vries (Mediabeheerder)

---

1. Achtergrond en Probleemstelling

Brede School "Het Leerpark" heeft een bibliotheek met ruim 2.000 boeken. Momenteel wordt het uitlenen bijgehouden in Excel. Dit is foutgevoelig: we weten vaak niet wie welk boek heeft, of de inleverdatum is verstreken en leerlingen kunnen de catalogus niet inzien.

Dit leidt tot verlies van boeken en een enorme administratieve druk. We willen dit professionaliseren met een systeem waarbij leerlingen zelfredzaam zijn en beheerders controle houden.

2. Doelstelling

De ontwikkeling van een web-based uitleensysteem (BookFlow).

Leerlingen moeten online de catalogus doorzoeken en reserveringen plaatsen. De mediabeheerder moet aanvragen verwerken, termijnen bewaken en de inname van boeken efficiënt registreren.

3. Doelgroepen

1. Leerlingen (Gebruikers): Willen direct zien of een boek 'thuis' is en wanneer zij hun eigen boeken moeten inleveren.

2. Mediabeheerders (Admins): Willen met minimale handelingen uitleningen registreren en proactief 'te laat' meldingen inzien.

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie:

  • Inlogscherm met rol-verdeling: student en librarian.

• Voor Leerlingen:

  • Dashboard met eigen actieve leningen en historie.
  • Doorzoekbare catalogus (Titel, Auteur, Categorie).
  • Knop "Reserveer Boek" (alleen mogelijk indien boek status 'Beschikbaar' heeft).

• Voor Mediabeheerders (Admins):

  • Uitleentermijn beheer: Mogelijkheid om bij uitgifte de inleverdatum aan te passen (default 4 weken).
  • Snel-registratie: Een dedicated "Uitleen-scherm" waar via een dropdown (of zoekveld) een leerling en boek gekoppeld kunnen worden.
  • Dashboard: Overzicht van alle actieve uitleningen, gesorteerd op inleverdatum.
  • Statusbeheer: Detailpagina om een lening af te ronden of de staat van het boek (notitie) bij te werken.

5. Technische Eisen & Randvoorwaarden

• PHP 8.x & MySQL: Gebruik van PDO voor database-interactie.
• Security: Verplichte password_hash voor accounts, Prepared Statements tegen SQL-injection en htmlspecialchars tegen XSS.
• Validatie: Een boek kan niet worden uitgeleend als de huidige status 'Uitgeleend' is.
• Architectuur: Logische mappenstructuur (bijv. /assets, /includes, /admin).

6. Budget en Planning

• Tijdsinvestering: 40-45 uur.
• Oplevering: Werkend MVP inclusief testrapport binnen 5 weken.

---

BIJLAGE: Design & UI Wensen

1. Status Labels: Gebruik visuele indicators (badges) in de tabel: Beschikbaar (Groen), Uitgeleend (Grijs), Te laat (Rood).
2. UX voor Admins: Het uitleenscherm moet 'keyboard-friendly' zijn (tabben tussen velden) voor snelle verwerking aan de balie.
3. Split-Screen Detail: Op de detailpagina van een boek: links de boekinformatie, rechts de uitleenhistorie van dat specifieke boek (wie had het wanneer?).

---

Extra Tips voor je Portfolio

1. Datum-logica (W3): Laat in je code zien hoe je met PHP de 'inleverdatum' berekent (vandaag + 28 dagen) en hoe je dit vergelijkt met de huidige datum om de status 'Te laat' te triggeren.
2. Joins (W3): In je Admin Dashboard gebruik je SQL JOINs om gegevens uit de tabellen gebruikers, boeken en leningen in één overzicht te tonen.

Project 8 - Bezichtigingsbeheer

Projectbriefing

Projectnaam: Bezichtigingsbeheer "KeyMaster"

Datum: 18 december 2025

Opdrachtgever: Makelaardij "De Gouden Sleutel"

Contactpersoon: Dhr. M. van Ommen (Eigenaar)

---

1. Achtergrond en Probleemstelling

Makelaardij De Gouden Sleutel beheert 150 huurwoningen. Wanneer er een woning vrijkomt, melden zich tientallen geïnteresseerden. Momenteel worden afspraken voor bezichtigingen in een papieren agenda genoteerd. Hierdoor is het onduidelijk wie er komt kijken, of de sleutel wel aanwezig is op kantoor en welke feedback de kijkers hebben gegeven.

Potentiële huurders bellen constant voor de status van hun aanvraag. Dit zorgt voor enorme drukte aan de telefoon. We willen een systeem waar makelaars bezichtigingen inplannen en klanten de status van hun afspraak kunnen inzien.

2. Doelstelling

De ontwikkeling van een portaal voor bezichtigingen (KeyMaster).

Klanten moeten online een aanvraag kunnen doen voor een woning. De makelaar moet deze aanvragen kunnen omzetten in een geplande afspraak, een sleutelstatus bijhouden en na afloop feedback noteren.

3. Doelgroepen

1. Klanten (Gebruikers): Willen zien of hun aanvraag is goedgekeurd en wanneer ze verwacht worden bij de woning.

2. Makelaars (Admins): Willen een dagoverzicht van alle geplande bezichtigingen en de status van de woning (bijv. "Verhuurd").

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie:

  • Inloggen voor klanten en makelaars.
  • Rollen: klant en makelaar.

• Voor Klanten:

  • Dashboard met hun actuele aanvragen en geplande datums.
  • Formulier "Bezichtiging Aanvragen" (Adres woning, Voorkeursdatum, Inkomen-indicatie).

• Voor Makelaars (Admins):

  • Centraal dashboard met alle binnengekomen aanvragen.
  • Planningsmodule: Een datum en tijdstip definitief koppelen aan een aanvraag.
  • Sleutelbeheer: Bijhouden of de sleutel op kantoor ligt of dat de huidige bewoner open doet.
  • Feedback-veld: Na de bezichtiging noteren of de klant interesse heeft of heeft afgehaakt.

5. Technische Eisen & Randvoorwaarden

• PHP 8.x & MySQL: Gebruik van PDO.
• Data Koppeling: Elke afspraak (appointment) moet gekoppeld zijn aan een property_id en een user_id.
• Veiligheid: Gebruik Prepared Statements voor alle queries en XSS-bescherming bij de adresgegevens.

6. Budget en Planning

• Ontwikkeltijd: 40-45 uur.
• Deadline: Binnen 5 weken.

---

BIJLAGE: Design & UI Wensen

1. Status Badges: Geef afspraken een kleur: Aanvraag (Blauw), Ingepland (Geel), Afgerond (Groen), Geannuleerd (Rood).
2. De "Daily View" Filter: De makelaar moet met één klik kunnen filteren op "Afspraken van Vandaag" (gebruik WHERE date = CURDATE() in je SQL).
3. Adres Detail: In het overzicht moet het adres van de woning groot en vetgedrukt staan, met daaronder de naam van de klant.

---

Waarom dit goed is voor je examen:

1. SQL Datum-functies: Je laat zien dat je kunt werken met DATE types en filters op specifieke dagen.
2. Privacy (W1/W3): Klanten mogen elkaars aanvragen en inkomensgegevens absoluut niet zien. Dit is een perfecte case om je autorisatie-checks (PHP sessies icm SQL) te bewijzen.
3. Complexiteit: Het omzetten van een 'losse' aanvraag naar een 'geplande afspraak' vereist een status-update in je database, wat een kernproces is van een applicatie-ontwikkelaar.

Project 9 - Voorraad- en Distributiebeheer

Projectbriefing

Projectnaam: Voorraad- en Distributiebeheer "Vuller"

Datum: 8 januari 2026

Opdrachtgever: Stichting "De Reikende Hand"

Contactpersoon: Mevr. S. Broodstra (Logistiek Manager)

Student: [Naam Student]

---

1. Achtergrond en Probleemstelling

Onze stichting zamelt voedselpakketten in voor gezinnen in de regio. Momenteel werken we met Excel-lijsten om bij te houden welke vrijwilliger welk pakket op welk adres moet afleveren. Dit zorgt voor fouten: soms staan twee vrijwilligers bij hetzelfde adres, of worden pakketten vergeten.

Daarnaast hebben de bezorgers onderweg geen inzicht in hun route of specifieke afleverinstructies (bijv. "pakket achter het tuinhek"). We hebben behoefte aan een centraal systeem dat de logistiek stroomlijnt.

2. Doelstelling

Wij willen een web-based portaal (Vuller) laten ontwikkelen voor het beheren van bezorgroutes.

Vrijwilligers moeten op hun telefoon hun eigen route kunnen zien en pakketten als "afgeleverd" kunnen markeren. De logistiek manager moet routes kunnen aanmaken, vrijwilligers koppelen en de status van alle leveringen live kunnen volgen.

3. Doelgroepen

1. Bezorgers (Vrijwilligers): Willen hun toegewezen adressen zien en de status van een levering bijwerken.

2. Logistiek Managers (Admins): Willen een totaaloverzicht van de voorraad en de voortgang van de bezorgingen per wijk.

4. Gewenste Functionaliteiten (Must-Haves)

Voor het MVP verwachten wij de volgende functies:

• Authenticatie:

  • Inloggen voor vrijwilligers en managers.
  • Rollen: vrijwilliger en manager.

• Voor Vrijwilligers:

  • Dashboard met de lijst van af te leveren pakketten voor vandaag.
  • Detailpagina per adres met afleverinstructies en een knop "Markeer als Bezorgd".
  • Overzicht van eigen voltooide leveringen.

• Voor Managers (Admins):

  • Beheerpagina om nieuwe leveringen (adressen + inhoud pakket) toe te voegen.
  • Mogelijkheid om een levering toe te wijzen aan een specifieke vrijwilliger.
  • Live dashboard met statistieken: Hoeveel % van de pakketten is al bezorgd?

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) en MySQL.
• Code Architectuur: Gebruik van een duidelijke mappenstructuur en header/footer includes.
• Veiligheid: Beveiliging tegen SQL-injectie en het valideren of een vrijwilliger alleen zijn eigen routes kan inzien.
• Data Integriteit: Een levering (delivery) is gekoppeld aan één vrijwilliger (user), maar een vrijwilliger kan meerdere leveringen hebben (1-op-N relatie).

6. Budget en Planning

• Tijdsinvestering: Ontwikkelingstijd van circa 40-45 uur.
• Oplevering: Een werkend prototype (MVP) inclusief testdata.

---

BIJLAGE: Specifieke Design & Interface Wensen

De stichting wil een betrouwbare en rustige uitstraling: wit, lichtgrijs en 'hulpvaardig' oranje.

1. Status Badges:

   • In Magazijn: Grijze badge.
   • Onderweg: Oranje badge.
   • Afgeleverd: Groene badge.

2. De "Route-Tracker" Navigatie:

   • Top-navigatie met in het midden de tekst "Vuller - Logistiek Systeem".
   • Rechtsboven een duidelijke melding als er nog onbezorgde pakketten op de lijst staan.

3. Bezorging Detail View (2-Koloms):

   • Links (70%): Adresgegevens (groot) en de inhoud van het pakket (bijv. "Pakket A: Gezin 4 pers.").
   • Rechts (30%): "Klant-notities" box met informatie over de bewoner of de locatie van de voordeur.

4. Manager Filter:

   • Filteren op wijk (bijv. ?wijk=Centrum) en op vrijwilliger om snel te zien wie nog op pad is.

Project 10 - E-sports Arena

Projectbriefing

Projectnaam: E-sports Arena "Respawn & Conquer"

Datum: 8 januari 2026

Opdrachtgever: Gaming Community "The Final Boss"

Contactpersoon: Dhr. K. 'NoobSlayer' Visser (Toernooi Organisator)

Student: Joey

---

1. Achtergrond en Probleemstelling

Onze community organiseert maandelijks online 1v1 toernooien voor verschillende games. Momenteel communiceren we via Discord-chats over wie tegen wie moet spelen. Uitslagen worden handmatig in een Google Sheet geplakt, wat vaak leidt tot verwarring over de huidige 'bracket' en wie de volgende tegenstander is.

Spelers missen hun matches omdat ze niet weten wanneer hun lobby klaarstaat, en de admins worden overspoeld met vragen over de tussenstand. We hebben een eigen portaal nodig dat fungeert als de 'Single Source of Truth' voor onze spelers.

2. Doelstelling

Wij willen een toernooi-dashboard (Respawn) laten ontwikkelen.

Gamers moeten kunnen inloggen om hun aankomende matches en de 'Kill/Death' ratio of puntenstand te zien. De toernooi-leiding (Game Masters) moet lobby-codes kunnen delen, spelers aan matches kunnen koppelen en de winnaars kunnen bevestigen.

3. Doelgroepen

1. Players (Gebruikers): Willen direct zien in welke 'Lobby' ze worden verwacht en wat hun ranking is.

2. Game Masters (Admins): Willen matches aanmaken, scores valideren en valsspelers kunnen markeren/verwijderen.

4. Gewenste Functionaliteiten (Must-Haves)

Voor het MVP verwachten wij de volgende functies:

• Authenticatie:

  • Login met 'GamerTag' en wachtwoord.
  • Rollen: player en gamemaster.

• Voor Players:

  • Persoonlijke 'Quest Log' (Dashboard) met actieve en komende matches.
  • Zichtbare Lobby-code voor de match (bijv. "A1-B99").
  • Leaderboard van de huidige competitie gebaseerd op gewonnen rondes.

• Voor Game Masters (Admins):

  • Match-maker interface: Koppel twee spelers aan een nieuwe match.
  • Uitslagen invoeren (bijv. 16-12) en de winnaar aanwijzen.
  • Systeem om matches op "Pending Validation" te zetten bij geschillen.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) en MySQL.
• Beveiliging: Sterke focus op rollen-beheer; spelers mogen nooit de score van een ander aanpassen.
• Front-end: Responsive design (spelers gebruiken vaak een tweede scherm of telefoon naast hun PC).
• Data Relatie: Een match-tabel die verwijst naar twee unieke ID's uit de player-tabel (Player 1 vs Player 2).

6. Budget en Planning

• Tijdsinvestering: Ontwikkelingstijd van circa 40-45 uur.
• Oplevering: Broncode via Git, inclusief een SQL-dump met test-gamers.

---

BIJLAGE: Specifieke Design & Interface Wensen

Het design moet een "Dark Mode" gamer-esthetiek hebben: donkergrijs/zwart, met neon-accenten in paars en cyaan.

1. Match Status Badges:

   • Waiting: Grijze gloed.
   • Warm-up: Cyaan (Ready to join).
   • In-Game: Paars (Live).
   • GG (Finished): Goud/Geel.

2. De "HUD" Navigatie:

   • Een sticky top-navigatie die lijkt op een 'Heads-Up Display' met de toernooinaam in een futuristisch font.

3. Match View (2-Koloms Split):

   • Links (75%): "Versus" scherm: Player 1 Avatar vs Player 2 Avatar, met daaronder de score-input.
   • Rechts (25%): "Server Info": Map-naam, Lobby-code en de naam van de Game Master die toezicht houdt.

4. GM Quick-Filter:

   • Knoppen om direct te filteren op "Matches zonder winnaar" of "Matches met conflict".

Project 11 - Sneaker Marketplace

Projectbriefing

Projectnaam: Sneaker Marketplace "SoleExchange"

Datum: 8 januari 2026

Opdrachtgever: Streetwear Boutique "The Kickz"

Contactpersoon: Dhr. M. Air (Eigenaar)

Student: Joey

---

1. Achtergrond en Probleemstelling

De markt voor exclusieve sneakers is enorm gegroeid. Onze klanten willen niet alleen schoenen kopen, maar hun eigen 'deadstock' (ongedragen schoenen) kunnen aanbieden aan andere verzamelaars. Momenteel gebeurt dit via onoverzichtelijke Marktplaats-advertenties waar veel fraude plaatsvindt.

We hebben een veilig, besloten platform nodig waar onze community leden hun sneakers kunnen aanbieden. De winkel (wij als organisatie) fungeert als tussenpersoon die de echtheid controleert voordat een deal wordt gesloten.

2. Doelstelling

Ontwikkel een Sneaker Trading Platform (SoleExchange).

Leden moeten hun sneakers kunnen uploaden (maat, merk, conditie). Andere gebruikers kunnen hierop een bod uitbrengen. Zodra een koper en verkoper akkoord zijn, moet het systeem de status bijwerken naar 'Verificatie' (waarbij de schoen naar de winkel wordt gestuurd).

3. Doelgroepen

1. Verzamelaars (Gebruikers): Willen hun collectie beheren, advertenties plaatsen en biedingen doen op andere schoenen.

2. Authenticators (Admins): Medewerkers van de winkel die de schoenen controleren op echtheid en de uiteindelijke verkoop goedkeuren.

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie:

  • Inloggen voor verzamelaars.
  • Rollen: collector en admin.

• Voor Verzamelaars:

  • "My Closet": Een overzicht van je eigen aangeboden sneakers.
  • Marktplaats-overzicht: Alle beschikbare sneakers van andere leden.
  • Biedings-systeem: Een bod kunnen uitbrengen op een item.

• Voor Admins (The Kickz Staff):

  • Dashboard met verkochte items die wachten op controle.
  • Knop om een item op 'Verified' (Echt) of 'Rejected' (Nep) te zetten.
  • Gebruikersbeheer om malafide verkopers te blokkeren.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) en MySQL.
• Beveiliging: Voorkom dat gebruikers elkaars biedingen verwijderen of aanpassen via de URL (ID-manipulatie).
• UX: Gebruik van afbeeldings-URL's om de schoenen visueel aantrekkelijk te tonen.
• Data Relatie: Een tabel `bids` die gekoppeld is aan zowel een `user` (de bieder) als een `sneaker_id`.

---

BIJLAGE: Specifieke Design & Interface Wensen

De uitstraling moet 'Urban' en 'High-end' zijn: Veel witruimte, strakke zwarte letters en rode accenten (zoals het bekende merk 'Supreme').

1. Conditie Labels:

   • DS (Deadstock/Nieuw): Felrode badge.
   • VNDS (Zo goed als nieuw): Zwarte badge.
   • Used: Grijze badge.

2. De "Price-Ticker" Navigatie:

   • Een navigatiebalk waarin naast de links ook een kleine 'ticker' (looptekst) staat met de laatste verkopen.

3. Product Card Design:

   • In het overzicht moeten de schoenen in een 'grid' staan met een hover-effect waarbij het hoogste bod direct zichtbaar wordt.

Project 12 - Studie-Portaal

Projectbriefing

Projectnaam: Studie-Portaal "StudyBuddy"

Datum: 8 januari 2026

Opdrachtgever: Studentenraad "Beter Leren"

Contactpersoon: Dhr. L. De Boeck (Studentenvoorzitter)

Student: Joey

---

1. Achtergrond en Probleemstelling

Studenten hebben vaak moeite met het organiseren van hun studietijd. Informatie staat verspreid over verschillende systemen, PDF's raken kwijt in downloads en de voortgang van projecten is onduidelijk. Vooral bij groepsopdrachten is het lastig om te zien wie wat heeft gedaan.

Er is behoefte aan een centrale web-app waar studenten hun vakken kunnen beheren, bronnen (links/notities) kunnen opslaan en hun cijfers kunnen bijhouden om hun gemiddelde te berekenen.

2. Doelstelling

Wij willen een Persoonlijk Studie Dashboard (StudyBuddy) laten ontwikkelen.

Het platform moet studenten helpen bij het plannen. De kern van de app is het beheren van 'Vakken' (Courses) en de bijbehorende 'Taken' (Tasks) en 'Cijfers' (Grades).

3. Doelgroepen

1. Studenten (Gebruikers): Willen hun eigen vakken, deadlines en behaalde cijfers inzien.

2. Docenten/Beheerders (Admins): Willen vakken kunnen aanmaken en algemene aankondigingen of studiemateriaal kunnen pushen naar alle studenten.

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie:

  • Inloggen met een studentnummer.
  • Rollen: student en admin (docent).

• Voor Studenten:

  • Overzicht van actieve vakken (bijv. PHP, Databases, Nederlands).
  • Deadline-lijst: Taken die gesorteerd zijn op datum.
  • Cijferlijst: Invoer van behaalde resultaten met automatische berekening van het gemiddelde.

• Voor Admins (Docenten):

  • Nieuwe vakken toevoegen aan het systeem.
  • Studiemateriaal (links naar documenten) koppelen aan een vak.
  • Overzicht van hoeveel studenten een vak volgen.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) en MySQL.
• Beveiliging: SQL-injectie preventie. Zorg dat een student alleen zijn *eigen* cijfers kan zien en bewerken.
• Wiskundige Logica: De backend moet het gemiddelde berekenen op basis van de ingevoerde cijfers uit de database.
• Data Relatie: Een vak (course) heeft meerdere taken (tasks) en meerdere cijfers (1-op-N relatie).

---

BIJLAGE: Specifieke Design & Interface Wensen

De look-and-feel moet rustgevend en productief zijn: Pastelkleuren (lichtblauw, zachtgroen) en een 'clean' wit dashboard.

1. Deadline Indicators:

   • Kritiek (binnen 2 dagen): Rode tekst + klok-icoon.
   • Gepland: Blauwe badge.
   • Voltooid: Doorgestreepte tekst met een groen vinkje.

2. De "Focus" Navigatie:

   • Minimale zijbalk (Sidebar) met iconen voor: Dashboard, Mijn Cijfers, Materialen en Instellingen.

3. Grade View (Tabel):

   • Een strakke tabel waar cijfers onder de 5.5 automatisch een rode achtergrond krijgen.

Project 13 - GoalGetter

Projectbriefing

Projectnaam: Teammanager App "GoalGetter"

Datum: 15 januari 2026

Opdrachtgever: Voetbalvereniging “SV KickOff”

Contactpersoon: Dhr. P. Vermeer (Teamcoach JO19-1)

Student: Milan

---

1. Achtergrond en Probleemstelling

Binnen de vereniging wordt veel tijd verloren aan het coördineren van trainingen, wedstrijden en aanwezigheid van spelers. Communicatie verloopt nu via verschillende WhatsApp-groepen en Excel-schema’s, wat leidt tot verwarring en gemiste wedstrijden.

De club wil één centraal platform waar trainers, spelers en ouders hun planning, statistieken en communicatie kunnen beheren.

2. Doelstelling

Wij willen een Teammanager App (GoalGetter) ontwikkelen die alle teamactiviteiten centraliseert.

De app moet helpen bij het plannen van trainingen, beheren van teamleden en inzicht geven in prestaties per speler en team.

3. Doelgroepen

1. Trainers (Admins): Willen snel zien wie aanwezig is, teams indelen en statistieken beheren.

2. Spelers (Gebruikers): Willen hun wedstrijden, statistieken en teamberichten bekijken.

3. Ouders: Willen meldingen ontvangen over wedstrijden en aanwezigheid van hun kind bevestigen.

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie:

  • Inloggen met lidnummer of e-mail.
  • Rollen: trainer, speler, ouder.

• Voor Spelers:

  • Overzicht van komende trainingen en wedstrijden.
  • Eigen statistieken bekijken (doelpunten, assists, kaarten).
  • Aanwezigheid bevestigen of afmelden.

• Voor Trainers:

  • Teamselectie maken voor wedstrijden.
  • Statistieken invoeren per speler.
  • Berichten versturen naar spelers of ouders.

• Voor Ouders:

  • Meldingen ontvangen over aanvangstijden en locatie van wedstrijden.
  • Afwezigheid van hun kind melden.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) en MySQL.
• Beveiliging: Rolgebaseerde toegang; alleen trainers mogen teamstatistieken bewerken.
• Data Relatie: Een team heeft meerdere spelers (1-op-N) en een speler heeft meerdere statistieken (1-op-N).
• Logica: De backend berekent automatisch het gemiddelde aantal doelpunten per wedstrijd en de teamvorm (W-D-L).

---

BIJLAGE: Specifieke Design & Interface Wensen

De look-and-feel moet sportief en energiek zijn: kleuren in clubstijl (groen/wit), duidelijke iconen en een mobielvriendelijke interface.

1. Status-Indicators:

   • Wedstrijd gewonnen: Groene badge met trofee-icoon.
   • Gelijkspel: Gele badge.
   • Verloren: Rode badge met kruis-icoon.

2. Navigatie:

   • Onderbalk met iconen voor: Home, Team, Wedstrijden, Statistieken en Berichten.

3. Statistiekenweergave:

   • Grafieken tonen prestaties per speler en teamtrend over de tijd.

--

Project 14 - CoachVision

Projectbriefing

Projectnaam: Voetbal Analyse Dashboard "CoachVision"

Datum: 15 januari 2026

Opdrachtgever: KNVB Innovatie-afdeling

Contactpersoon: Dhr. J. van den Berg (Technisch Analist)

Student: Daan

---

1. Achtergrond en Probleemstelling

Bij veel amateur- en semi-professionele voetbalclubs worden wedstrijdgegevens nog handmatig bijgehouden. Hierdoor ontbreekt inzicht in prestaties op team- en individueel niveau. Trainers baseren beslissingen vaak op gevoel in plaats van data.

De KNVB wil een digitaal dashboard ontwikkelen waarmee coaches eenvoudig data kunnen verzamelen, analyseren en visualiseren, zodat trainingen en tactische keuzes beter onderbouwd kunnen worden.

2. Doelstelling

Het doel is om een Voetbal Analyse Dashboard (CoachVision) te ontwikkelen dat inzicht biedt in spelersprestaties, teamontwikkeling en wedstrijdstatistieken.

De tool moet visueel sterk zijn, realtime data kunnen verwerken en trainers ondersteunen in hun tactische beslissingen.

3. Doelgroepen

1. Trainers: Willen inzicht in de prestaties van spelers en teams om trainingen te optimaliseren.

2. Data-analisten: Willen gegevens verzamelen, filteren en exporteren voor verdere analyse.

3. Teamleiders: Willen snel rapportages kunnen delen met bestuur of spelersgroep.

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie:

  • Inloggen met clubaccount.
  • Rollen: trainer, analist, beheerder.

• Dashboard voor Trainers:

  • Overzicht van wedstrijdresultaten, doelpuntenmakers en conditiestatus.
  • Automatische berekening van teamvorm (laatste 5 wedstrijden).
  • Heatmaps en pass-statistieken per speler.

• Voor Analisten:

  • Data importeren vanuit CSV of tracking-sensoren.
  • Statistische filters toepassen (bijv. balbezit, afstand gelopen, succesratio passes).
  • Exporteren naar Excel of PDF voor rapportages.

• Voor Beheerders:

  • Gebruikersrechten beheren.
  • Teams, spelers en seizoenen aanmaken of archiveren.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x), MySQL en gebruik van Chart.js voor visualisaties.
• Beveiliging: JWT-authenticatie en SSL-verbinding verplicht.
• API-koppelingen: Mogelijkheid om data te ontvangen van GPS-trackers of sport-API’s (zoals SportMonks).
• Data Relatie: Een speler kan meerdere statistieken per wedstrijd hebben (1-op-N-relatie).

---

BIJLAGE: Specifieke Design & Interface Wensen

Het dashboard moet professioneel en overzichtelijk zijn: donkere modus met clubaccentkleuren (donkerblauw, oranje) en duidelijke datavisualisaties.

1. Visualisaties:

   • Grafieken voor doelpunten, balbezit en afstand per speler.
   • Kaartweergave (heatmap) met looplijnen over het veld.

2. Navigatie:

   • Sidebar met secties voor: Dashboard, Spelers, Wedstrijden, Analyse en Instellingen.

3. Rapportageweergave:

   • Downloadbare rapporten in PDF met clublogo en prestatiegrafieken.

Project 15 - MatchUp

Projectbriefing

Projectnaam: Schooltoernooi Planner "MatchUp"

Datum: 15 januari 2026

Opdrachtgever: MBO College Stad – Sport & Beweging

Contactpersoon: Mevr. K. van Es (Docent Sport)

Student: Ruben

---

1. Achtergrond en Probleemstelling

Tijdens sportdagen en toernooien op school is het lastig om overzicht te houden over wedstrijden, uitslagen en standen. Schema’s worden vaak handmatig gemaakt in Excel of op papier, wat fouten en vertragingen oplevert.

De opleiding wil een eenvoudige webapp waarmee studenten en docenten een toernooi kunnen organiseren, teams kunnen indelen en automatisch een speelschema kunnen genereren.

2. Doelstelling

Het doel is een Schooltoernooi Planner (MatchUp) te ontwikkelen waarmee wedstrijden, teams en scores digitaal beheerd kunnen worden.

De app moet toegankelijk zijn voor studenten en docenten, overzichtelijk werken op mobiel, en automatisch de poulestanden bijhouden.

3. Doelgroepen

1. Studenten (Spelers): Willen hun team, wedstrijdtijden en uitslagen bekijken.

2. Docenten (Organisatoren): Willen teams aanmaken, het speelschema genereren en standen bijhouden.

3. Toeschouwers: Willen de actuele stand van het toernooi zien.

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie:

  • Inloggen met schoolaccount.
  • Rollen: student en docent.

• Voor Studenten:

  • Inzien van het eigen team, poule en wedstrijden.
  • Live tussenstanden en uitslagen volgen.
  • Teamfoto en teamnaam aanpassen.

• Voor Docenten:

  • Teams aanmaken en wedstrijden genereren (automatisch schema).
  • Uitslagen invoeren en standen automatisch laten berekenen.
  • Winnaar van het toernooi bepalen.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) en MySQL.
• Logica: Automatische poule-indeling en puntentelling (3 punten winst, 1 punt gelijk, 0 verlies).
• Beveiliging: Alleen docenten kunnen uitslagen invoeren of wijzigen.
• Data Relatie: Een team speelt meerdere wedstrijden (1-op-N) en elke wedstrijd hoort bij één poule.

---

BIJLAGE: Specifieke Design & Interface Wensen

De interface moet sportief en helder zijn: veel witruimte met accenten in blauw en oranje (schoolkleuren), en duidelijke iconen voor teams en standen.

1. Poule-overzicht:

   • Tabel met teams, gespeelde wedstrijden, punten en doelsaldo.
   • Automatische kleur voor koploper (groen) en laatste plaats (rood).

2. Navigatie:

   • Tabs of knoppen voor: Poules, Wedstrijden, Uitslagen en Ranglijst.

3. Score-invoer:

   • Docentinterface met invoervelden voor thuis- en uitteam, plus scorevalidatie.

Project 16 - EuroMatch

Projectbriefing

Projectnaam: European School Cup Manager "EuroMatch"

Datum: 15 januari 2026

Opdrachtgever: European Schools Federation (ESF)

Contactpersoon: Mevr. L. Schneider (Projectcoördinator Sport en ICT)

Student: Elias

---

1. Achtergrond en Probleemstelling

De European Schools Federation organiseert jaarlijks een sporttoernooi met teams uit verschillende landen. De organisatie gebruikt momenteel losse Excel-bestanden en e-mails om wedstrijden en scores bij te houden. Dit leidt tot fouten, vertragingen en taalverwarring tussen teams uit verschillende landen.

Er is behoefte aan een centrale, meertalige webapplicatie waarmee het toernooi digitaal kan worden beheerd: teams registreren, wedstrijden plannen, scores bijhouden en statistieken tonen per land en team.

2. Doelstelling

Het doel is om een European School Cup Manager (EuroMatch) te ontwikkelen die alle landen, teams, wedstrijden en uitslagen samenbrengt in één overzichtelijk systeem.

De app moet ondersteuning bieden voor meerdere talen, automatische tijdzone-afstemming en uitgebreide statistieken per land.

3. Doelgroepen

1. Teamcoaches: Willen hun team inschrijven, spelers beheren en resultaten invoeren.

2. Organisatoren (Admins): Willen het volledige toernooi beheren, schema’s genereren en rapportages exporteren.

3. Internationale bezoekers: Willen live de standen en statistieken volgen in hun eigen taal.

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie & Rollen:

  • Inloggen met e-mail of teamcode.
  • Rollen: coach, admin, viewer.
  • Tweetrapsverificatie voor beheerders.

• Meertalige Ondersteuning:

  • Taalkeuze: Engels, Nederlands, Frans, Duits en Spaans.
  • Automatische vertaling van teamnamen en landen via een taaltabel in de database.

• Voor Coaches:

  • Teams aanmaken met vlag, spelerslijst en schoolnaam.
  • Uitslagen invoeren of bevestigen.
  • Teamstatistieken bekijken (doelpunten, winstpercentage).

• Voor Organisatoren:

  • Automatisch wedstrijdschema genereren op basis van poules en tijdzones.
  • Resultaten valideren en standen automatisch laten berekenen.
  • Exporteren van rapporten naar PDF of Excel per land.

• Voor Bezoekers:

  • Live scorebord met vlaggen van deelnemende landen.
  • Filteren op land, poule of datum.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x), MySQL, JavaScript (Chart.js voor grafieken).
• Beveiliging: SQL-prepared statements, CSRF-tokens en SSL.
• Internationalisatie: Gebruik van gettext() voor meertalige ondersteuning.
• Data Relatie: Elk land heeft meerdere teams (1-op-N), elk team meerdere wedstrijden (1-op-N).
• Tijdzones: Wedstrijdtijden automatisch converteren naar lokale tijd van gebruiker.

---

BIJLAGE: Specifieke Design & Interface Wensen

De interface moet een internationale uitstraling hebben met vlag-iconen, een moderne typografie en lichte achtergrond. Kleuren gebaseerd op het thema blauw (Europa) en goud (prestatie).

1. Dashboard:

   • Kaart van Europa met deelnemende landen gemarkeerd.
   • Top 5 landen zichtbaar op basis van behaalde punten.

2. Navigatie:

   • Bovennavigatie met vlag-iconen voor taalkeuze en dropdown voor landenfilter.

3. Statistiekenweergave:

   • Grafieken per land (doelpunten, winstpercentage, fair play-score).
   • Automatisch kleurenschema op basis van landvlag (bijv. rood-geel voor Spanje).

Project 17 - ReWear

Projectbriefing

Projectnaam: Tweedehands Kledingplatform "ReWear"

Datum: 15 januari 2026

Opdrachtgever: Stichting Duurzaam Jong

Contactpersoon: Mevr. F. Mulder (Projectleider Circulaire Economie)

Student: Noor

---

1. Achtergrond en Probleemstelling

Veel jongeren willen duurzamer leven, maar hebben moeite om betaalbare en milieuvriendelijke kleding te vinden. Tweedehands kleding wordt steeds populairder, maar online platforms zijn vaak onoverzichtelijk of gericht op winst in plaats van hergebruik.

Er is behoefte aan een gebruiksvriendelijk platform waar jongeren tweedehands kleding kunnen ruilen, verkopen of doneren — met aandacht voor duurzaamheid, hergebruik en eerlijke mode.

2. Doelstelling

Het doel is om een Tweedehands Kledingplatform (ReWear) te ontwikkelen dat het makkelijk maakt om kleding een tweede leven te geven.

De app moet gebruikers helpen om hun kleding te uploaden, ruilpartners te vinden en inzicht te krijgen in hun duurzame impact.

3. Doelgroepen

1. Jongeren (Hoofdgebruikers): Willen kleding verkopen, ruilen of doneren op een veilige en makkelijke manier.

2. Beheerders: Willen toezicht houden op advertenties, gebruikers en duurzaamheidsscore.

3. Duurzaamheidsorganisaties: Willen inzicht in hoeveel kleding via het platform wordt hergebruikt.

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie:

  • Registratie met e-mail of Google-account.
  • Rollen: gebruiker en beheerder.

• Voor Gebruikers:

  • Kleding uploaden met foto, maat, merk en staat (nieuw, goed, gedragen).
  • Zoeken op categorie, maat of locatie.
  • Ruilfunctie: bied kleding aan in ruil voor andere items.
  • Berichten sturen via een intern chatsysteem.

• Voor Beheerders:

  • Advertenties goedkeuren of verwijderen bij misbruik.
  • Statistieken bekijken over aantal ruilen, verkopen en donaties.
  • Gebruikersaccounts beheren.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x), MySQL en een REST API voor mobiele koppeling.
• Beveiliging: Alleen ingelogde gebruikers kunnen kleding uploaden of berichten sturen.
• Afbeeldingen: Automatisch verkleinen bij upload om opslag te beperken.
• Data Relatie: Een gebruiker heeft meerdere advertenties (1-op-N) en berichten (1-op-N).
• Duurzaamheidslogica: De app berekent hoeveel CO₂ en water per ruil bespaard wordt.

---

BIJLAGE: Specifieke Design & Interface Wensen

De uitstraling moet fris, jong en duurzaam zijn: gebruik van pastelgroen, beige en wit met minimalistische iconen en zachte schaduwen.

1. Productoverzicht:

   • Rasterweergave van kledingstukken met foto, maat en prijs/ruiloptie.
   • Duidelijk label voor “Ruilbaar” of “Gratis”.

2. Navigatie:

   • Vaste onderbalk met iconen voor: Home, Upload, Ruilen, Chat en Profiel.

3. Duurzaamheidsweergave:

   • Kleine teller die toont hoeveel kledingstukken een gebruiker al heeft hergebruikt.
   • Groene animatie bij succesvolle ruil of donatie.

Project 18 - StyleCycle

Projectbriefing

Projectnaam: Tweedehands Verkoopplatform "StyleCycle"

Datum: 15 januari 2026

Opdrachtgever: Startup “EcoWear BV”

Contactpersoon: Dhr. T. van Aalst (Founder & CEO)

Student: Zoë

---

1. Achtergrond en Probleemstelling

De tweedehands kledingmarkt groeit snel, maar veel platforms zijn complex of vragen hoge commissies. Gebruikers zoeken een betrouwbaar en gebruiksvriendelijk platform waar ze eenvoudig hun kleding kunnen verkopen, kopen of ruilen — zonder verborgen kosten.

EcoWear BV wil een platform laten ontwikkelen dat zich richt op transparante handel, duurzaamheid en een lage drempel voor particuliere verkopers.

2. Doelstelling

Het doel is om een Tweedehands Verkoopplatform (StyleCycle) te realiseren waar gebruikers kleding kunnen aanbieden, verkopen en veilig afrekenen.

De applicatie moet betrouwbaar, mobielvriendelijk en financieel veilig zijn, met focus op een prettige gebruikerservaring en duurzaamheid.

3. Doelgroepen

1. Particuliere verkopers: Willen eenvoudig kleding uploaden, prijzen bepalen en contact met kopers onderhouden.

2. Kopers: Zoeken naar betaalbare tweedehands kleding en willen veilig kunnen betalen.

3. Beheerders: Zorgen voor controle op advertenties, betalingen en misbruik.

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie & Profielen:

  • Registratie met e-mail of Google-account.
  • Profielpagina met beoordelingensysteem (sterren en feedback).
  • Verificatie via e-mail of telefoonnummer.

• Verkoop & Koopfunctionaliteit:

  • Kleding uploaden met titel, beschrijving, prijs, maat, categorie en foto’s.
  • Zoeken en filteren op maat, merk, prijs of staat (nieuw, gedragen, vintage).
  • Biedfunctie: gebruikers kunnen op items bieden of direct kopen (“Koop Nu”).

• Betaalsysteem:

  • Integratie met Mollie of Stripe voor iDEAL, PayPal en creditcard.
  • Geld wordt vastgehouden tot het pakket is ontvangen (“escrow”-systeem).
  • Automatische vergoeding van commissie aan het platform (5%).

• Berichten & Notificaties:

  • Chatfunctie tussen koper en verkoper met automatische vertaling (Nederlands/Engels).
  • Pushmeldingen bij biedingen, verkopen en verzending.

• Beheerfunctionaliteit:

  • Controle op verboden producten (AI-beeldherkenning op merk/logo’s).
  • Dashboard met statistieken over omzet, gebruikers en transacties.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x), MySQL en JavaScript voor dynamische elementen.
• Beveiliging: SSL, wachtwoordhashing (bcrypt), CSRF-bescherming en veilige betalings-API’s.
• Afbeeldingen: Compressie en automatische watermarking.
• Data Relatie: Een gebruiker heeft meerdere producten (1-op-N) en meerdere transacties (1-op-N).
• Betaallogica: Transactiestatussen: “in behandeling”, “betaald”, “verzonden”, “voltooid”.

---

BIJLAGE: Specifieke Design & Interface Wensen

De interface moet modern en commercieel ogen, vergelijkbaar met Vinted of Depop. Gebruik van witruimte, lichte pastelkleuren en afgeronde randen zorgt voor vertrouwen en gebruiksgemak.

1. Productoverzicht:

   • Tegelweergave met productfoto, prijs en verkoperscore.
   • Hover-effect toont snelle acties: “Bied”, “Chat”, “Favoriet”.

2. Navigatie:

   • Vaste bovenbalk met zoekveld, categorieën, verkoopknop en profielicoon.
   • Mobiel: onderbalk met iconen voor Home, Verkoop, Chat, Favorieten en Profiel.

3. Betalingsflow:

   • Stap-voor-stap checkout met adres, verzendmethode en betaling.
   • Bevestigingspagina met statusoverzicht en track-&-trace.

Project 19 - MediaMeter

Projectbriefing

Projectnaam: Kijk- en Luisteronderzoek Platform "MediaMeter"

Datum: 15 januari 2026

Opdrachtgever: Nationaal Onderzoeksbureau voor Media (NOM)

Contactpersoon: Dhr. R. Jacobs (Onderzoekscoördinator)

Student: Emma

---

1. Achtergrond en Probleemstelling

Omroeporganisaties en adverteerders willen weten hoeveel mensen naar bepaalde programma’s luisteren of kijken. Huidige methodes, zoals steekproeven en vragenlijsten, zijn onnauwkeurig en traag. Data uit streamingdiensten en podcasts worden bovendien niet goed gecombineerd met traditionele media-cijfers.

Er is behoefte aan een digitaal platform dat kijk- en luistergedrag betrouwbaar kan registreren, analyseren en visualiseren — zowel voor lineaire uitzendingen als online streams.

2. Doelstelling

Het doel is een Media Analyse Platform (MediaMeter) te ontwikkelen dat real-time inzicht geeft in kijk- en luistergedrag.

Het platform moet data verzamelen via verschillende bronnen (TV, radio, streaming, podcasts) en deze combineren in overzichtelijke rapportages.

3. Doelgroepen

1. Onderzoeksbureaus: Willen gedetailleerde data per programma, tijdstip en platform.

2. Omroepen: Willen snel zien welke programma’s goed scoren bij welke doelgroep.

3. Adverteerders: Willen weten op welke momenten hun reclames het meeste bereik hebben.

4. Gewenste Functionaliteiten (Must-Haves)

• Dataverzameling:

  • Automatisch importeren van kijk- en luisterdata via API’s van NPO, Spotify, YouTube en Nielsen.
  • Handmatige invoer mogelijk voor kleinere omroepen.
  • Dagelijkse synchronisatie en validatie van data.

• Dashboard & Visualisatie:

  • Grafieken en tabellen met bereik per zender, programma en tijdslot.
  • Vergelijkfunctie tussen radio, tv en online streams.
  • Export naar Excel, PDF of Power BI.

• Gebruikersrollen:

  • onderzoeker: data analyseren en rapportages maken.
  • beheerder: bronnen koppelen, gebruikers beheren.
  • gast: beperkte weergave van publieke trends.

• Analysetools:

  • Gemiddelde kijktijd per programma berekenen.
  • Top-10 uitzendingen per week automatisch genereren.
  • Demografische verdeling (leeftijd, regio) tonen via filters.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x), MySQL, Chart.js voor grafieken.
• API-koppelingen: Integratie met NPO-Data, Spotify API en YouTube Analytics.
• Beveiliging: OAuth2-authenticatie en SSL-verbinding verplicht.
• Data Relatie: Eén uitzending kan meerdere datapunten hebben (1-op-N) per platform.
• Prestaties: Geoptimaliseerde queries en caching voor grote datasets.

---

BIJLAGE: Specifieke Design & Interface Wensen

De interface moet zakelijk en datagedreven zijn: donkere achtergrond, contrasterende accentkleuren (blauw/oranje) en duidelijke grafieken.

1. Dashboardweergave:

   • Line-charts voor trends per dag/week.
   • Pie-charts voor mediatype-verdeling (radio, tv, online).
   • Interactieve tijdlijn met filteropties.

2. Navigatie:

   • Sidebar met secties voor: Dashboard, Uitzendingen, Analyse, Rapportages, Instellingen.

3. Rapportages:

   • Automatische weekrapporten met top-programma’s en bereikscijfers.
   • Downloadknop voor PDF-versie met logo en datum.

Project 20 - TrendWatch

Projectbriefing

Projectnaam: Social Media Analyse Platform "TrendWatch"

Datum: 15 januari 2026

Opdrachtgever: Communicatiebureau “Insight Digital”

Contactpersoon: Mevr. J. van der Steen (Head of Strategy)

Student: Maxime

---

1. Achtergrond en Probleemstelling

Bedrijven besteden steeds meer aan online marketing, maar hebben weinig inzicht in wat er écht leeft op sociale media. Data zijn verspreid over platforms zoals Instagram, TikTok, X (Twitter) en LinkedIn. Zonder overzicht is het moeilijk om trends te herkennen of campagnes te evalueren.

Er is behoefte aan één centrale omgeving waar berichten, hashtags, volgersaantallen en reacties automatisch worden verzameld en geanalyseerd. Zo kunnen communicatieprofessionals beter inspelen op actuele thema’s.

2. Doelstelling

Het doel is om een Social Media Analyse Platform (TrendWatch) te ontwikkelen dat inzicht geeft in merkprestaties, trending onderwerpen en doelgroepgedrag.

Het platform moet automatisch data verzamelen via API’s en duidelijke grafieken tonen voor bereik, sentiment en engagement.

3. Doelgroepen

1. Marketingteams: Willen weten welke berichten goed scoren en wanneer hun publiek actief is.

2. Communicatieadviseurs: Willen trends en sentimenten in de publieke opinie volgen.

3. Bedrijfsleiding: Wil inzicht in het totale online imago van het merk.

4. Gewenste Functionaliteiten (Must-Haves)

• Dataverzameling:

  • Koppeling met social media-API’s (Instagram Graph API, X API, TikTok for Developers, LinkedIn Insights).
  • Automatische import van likes, reacties, shares, hashtags en volgersaantallen.
  • Dagelijkse synchronisatie met historische opslag (database logging).

• Analyse & Visualisatie:

  • Sentimentanalyse op basis van reacties (positief, neutraal, negatief).
  • Top 10 posts per kanaal (hoogste engagement).
  • Trendgrafieken met hashtagfrequentie per dag.
  • Heatmap met activiteit per uur van de dag.

• Gebruikersrollen:

  • analist: bekijkt en exporteert data.
  • beheerder: beheert accounts, API-sleutels en instellingen.
  • gast: alleen weergave van openbare trends.

• Rapportages:

  • Automatische maandrapporten met belangrijkste statistieken.
  • Export naar PDF of PowerPoint met grafieken en merklogo’s.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x), MySQL en Python voor dataverwerking (NLTK of TextBlob voor sentimentanalyse).
• API-koppelingen: OAuth 2.0 authenticatie met alle social media-platforms.
• Beveiliging: Beperk toegang via token-gebaseerde login en SSL-certificaat.
• Data Relatie: Eén merk heeft meerdere social accounts (1-op-N), en elk account heeft meerdere posts (1-op-N).
• Prestaties: Asynchrone verwerking via cronjobs voor API-updates.

---

BIJLAGE: Specifieke Design & Interface Wensen

De interface moet modern en datavisueel zijn, met een dashboardstijl vergelijkbaar met marketingtools als Hootsuite of Sprout Social.

1. Dashboard:

   • KPI-kaarten met aantal volgers, engagementrate en sentiment per kanaal.
   • Grafieken met groei over tijd per platform.
   • Donutchart voor verdeling positief/neutraal/negatief sentiment.

2. Navigatie:

   • Sidebar met secties: Dashboard, Posts, Hashtags, Analyse, Rapporten.
   • Filterbalk bovenaan met platform-selectie (Instagram, TikTok, etc.).

3. Rapportageweergave:

   • Automatische screenshotfunctie voor presentaties.
   • Kleurenthema per merk (instelbaar in instellingen).

--- Archief ---

Alles hieronder is mogelijk verouderd of nog niet helemaal af.

K1 Software maken

K1 W1 Planning

Werkproces 1 van kerntaak 1 gaat over planning en ontwerp.

Je ontvangt de opdracht.

Je moet aantonen dat je het volgende beheerst.

Eisen

1. Je gaat jezelf inlezen, zoekt eventueel zaken op, je wint advies in van anderen en probeert een zo goed mogelijk plaatje (in je hoofd) te maken van wat je moet gaan bouwen.
2. Je gaat met de opdrachtgever en eventueel andere betrokkenen in gesprek om alles door te nemen en om eventuele onduidelijkheden verder te verduidelijken.
3. Je zet alle eisen en wensen op papier (dat kan in user stories) en koppelt dat terug.
   
4. Je maakt een planning als dan niet volgens een agile development proces. Je laat zien dat je doorlooptijden kan inschatten en je kunt logische prioritering aanbrengen door bijvoorbeeld MoSCoW-methode).
5. Je houd de planning in de gaten en stelt die zo nodig bij. Onderbouw deze afwijkingen en evalueer middels een of meerdere reflectieverslagen.

Bewijsmateriaal

Wat kun je als bewijsmateriaal aanleveren in je portfolio?

1. Een situatiebeschrijving (vooraf) van context van de opdracht als deze buiten school is uitgevoerd (zie apart kopje hieronder).
2. Een beschrijving van hoe je je hebt voorbereid op de opdracht.
3. Een document met eisen en wensen dat is besproken en is goedgekeurd door de opdrachtgever.
   
4. Een document met de planning.
   Planning is logisch, correct en er is een vorm van prioritering aangebracht.
   
5. Een ondertekend gespreksverslag en/of video-fragment.
   Het gesprek verloop goed opgebouwd (kop-romp-staart). Je past LSD toe; luisteren, samenvatten en doorvragen.
6. Refelctieverslag(en).

Template

Hier is een template om een planning te maken: Projectplan (template).docx

Let met het 'invullen' van deze template, voldoe je nog niet aan alle eisen.

Situatiebeschrijving

Als je de opdracht op school uitvoert dan kennen wij de omgeving. Als je de opdracht buiten school uitvoert voeg dan een situatie beschrijving toe. Dit is een beschrijving van de situatie vooraf.

Hierin beantwoord je de volgende vragen:

• Voor wie maak je de opdracht?
• Wat is jouw relatie met de opdrachtgever (kennis, familie, onbekende,....)?
• Wat zijn de afspraken met de opdrachtgever, denk aan tijd, deadlines en vergoeding.
• Aan wie rapporteer jij? Dus aan wie geef je aan als je bijvoorbeeld iets niet op tijd af dreigt te krijgen?
• Met wie werk je samen? Doe je dit alleen of met een groep?
• Wat zijn precies je taken?
• Hoeveel tijd schat je in totaal bezig te zijn met de opdracht?
• Welke kennis heb je nodig voor de opdracht?
• Beschik jij over alle benodigde kennis en zo niet, joe ga je dat op lossen?
• Zijn er overige zaken die van belang zijn voor de examinator om te weten als hij deze opdracht gaat beoordelen?

Beoordelingsrichtlijnen

• Eisen en wensen zijn in de vorm van user story's beschreven; er zijn er minimaal 3 goede user-stories beschreven. In een goede user story staat de rol, de functionaliteit en het doel (Als- wil ik - zodat).
• Is het duidelijk wanneer het project volgens de planning plaats vindt?
• Is er per taak beschreven wat er moet worden gedaan, door wie en hoe lang het duurt?
• Is een taak met zoveel detail beschreven dat er met een marge van +/- 50% kan worden bepaald hoeveel tijd er voor nodig is? De tijd die is geschat is reëel of is goed onderbouwd.
  
• Er wordt aangetoond dat gedurende het project de planning wordt bewaakt. Er wordt minimaal op drie momenten bepaald waar het project staat (loopt voor, op planning of loopt achter).

Deze beoordelingsrichtlijnen zijn gebaseerd op de SPL "Beoordelingsformulier praktijkexamen" (examencode SD_SD20_B1-K1-2_1V1, crebo 25604).

K1 W2 Ontwerp

Werkproces 2 van kerntaak 1 gaat over ontwerp.

Je hebt alle eisen en wensen duidelijk op papier (of in user story's).

Je moet aantonen dat je het volgende beheerst.

Eisen

Je hebt één of meerdere ontwerp documenten gemaakt.

De eisen en wensen (user story's) zijn vertaald naar een ontwerp. In dit ontwerp wordt duidelijk wat er wordt gebouwd hoe het er (ongeveer) uit gaat zien en welke objecten/entiteiten je gaat maken.

In het ontwerp moet je laten zien dat je ontwerpdiagrammen beheerst zoals: activiteitendiagram, klassendiagram, ERD, Use-casediagrammen.

Het ontwerp wordt onderbouwd waarbij zaken als security, privacy en ethiek aan de orde kunnen komen.

Hoe maak je een GUI ontwerp?

Er zijn talloze handige online tools om GUI ontwerpen te maken.

Tools voor ontwerpen GUI:

• https://www.lucidchart.com (gebruik 'Website blockframe')
  
• http://www.phpform.org/
• https://app.lucidchart.com
• Top 25 free Mockup and Wireframe tools. 
• De nummer 1, Frame Box
• chatGPT (laat een GUI in HTML maken, open in de browser en maak een schermafdruk)

Bewijsmateriaal

Wat kun je als bewijsmateriaal aanleveren in je portfolio?

1. De opdrachtbeschrijving als je dit buiten school hebt uitgevoerd.
   
2. Eén of meerdere ontwerpdocumenten.
   De ontwerpdocumenten zijn door jouw zelf gemaakt en beschrijven een aanzienlijk deel van de software(aanpassingen). Een aanzienlijk deel is een deel wat minimaal 40 uur kost op te coderen.
   De ontwerpdocumenten voldoen aan de eisen (zie hierboven).

Beoordelingsrichtlijnen

1. De user story's (uit kerntaak 1, planning) zijn vertaald in een ontwerp.
2. Het ontwerp laat zoveel mogelijk grafisch zien wat er gebouwd gaat worden. Wanneer er geen grafische vorm wordt gegeven dan moet de gebruikersinterface zo goed mogelijk zijn beschreven in text, aangevuld met ruwe schetsen (wireframes).
3. Er zijn minimaal twee schematechnieken toegepast, (bijvoorbeeld ERD, activiteitendiagram, klassendiagram, Use Case diagram)
4. De keuzes in het ontwerp worden onderbouwd. Hierbij is bijvoorbeeld rekening gehouden met ethiek, privacy en security.
5. De onderwerpen Privacy, Security en Ethiek zijn beschreven.
   

(zie voor de up-to-date checklist: https://www.roc.ovh/books/portfolio-kerntaak-examen/page/check-list

De beoordelingsrichtlijnen zijn gebaseerd op de SPL "Beoordelingsformulier praktijkexamen" (crebo 25604).

K1 W3 Realisatie

Werkproces 3 van kerntaak 1 gaat over de realisatie, het coderen.

Je ontvangt de opdracht. Zorg ervoor dat als je de opdracht buiten school maakt dat de opdrachtbeschrijving duidelijk op papier staat. Voeg dit toe aan je portfolio.

Je moet aantonen dat je het volgende beheerst.

Eisen

1. Je hebt voldoende functionaliteiten gemaakt.
   Dit is natuurlijk afhankelijk van de vorm en de tijd. Maar je moet denken aan 16 tot 40 uur 'puur' programmeerwerk (dus zonder inrichten computer, overleg, ontwerp en dergelijke). Hoe meer hoe beter want dan kunnen we beter de kwaliteit beoordelen.
2. De kwaliteit van de functionaliteit is goed en voldoet aan de vastgestelde eisen.
3. De kwaliteit van de code is goed.
   De structuur klopt (bijv. MVC), de foutafhandeling is goed en je hebt rekening gehouden met security. De code werkt efficiënt (is dus niet onnodig langzaam).
4. De code is opgesteld volgens de code conventions.
   Dit zijn afspraken die je onderling maakt over de vorm van de code.
5. De code ziet er verzorgd uit.
   Dit heeft raakvlakken met de kwaliteit van de code. Het gaat erom of de code goed leesbaar is. DIt heeft ook te maken met structuur, naamgeving en commentaar.
6. Versiebeheer is toegepast.
   Je kan de ontwikkeling van het product laten zien aan de hand van versiebeheer. Je kunt dus terugkijken in oude versies.

Bewijsmateriaal

Wat kun je als bewijsmateriaal aanleveren in je portfolio?

1. De opdrachtbeschrijving als de opdracht buiten school is gemaakt.
2. De delen van het ontwerp (user stories) die jij hebt gecodeerd.
3. Logboek waarin je per dag bijhoud wat je hebt gedaan. Beschrijf ook kort waar je tegenaan liep en hoe je dat hebt opgelost.
4. De code in een vorm dat die door een ander kan worden geïnstalleerd. De code is dus compleet met database en korte installatie handleiding.
5. De code conventions en een checklist waaruit blijkt dat je code is gecontroleerd.
6. Documentatie waarin je de structuur en opbouw van je code uitlegt en eventueel onderbouwt.
7. Documentatie waarin je uitlegt hoe en wat je hebt gedaan om je applicatie secure/veilig te maken.
   
8. Je hebt een repository (bijvoorbeeld in SVN of GIT) en laat bijvoorbeeld in een filmpje zien hoe je daar mee werkt.
   
9. Documentatie waarin je uitlegt hoe jij versiebeheer gebruikt.

Beoordelingsrichtlijnen

1. Er is minimaal 40 uur besteed aan het implementeren van User story's.
   
2. De opgeleverde functionaliteiten werken en voldoen in minimaal 80% van de scenario aan de user story. Dit betekent dat foutieve, ongewenste of missende functionaliteit alleen in uitzonderlijke gevallen mag optreden.
3. Er kan worden aangetoond dat er rekening is gehouden met: efficiëntie van de code, goede performance, foutafhandeling, invoercontrole, security, beveiliging.
   
4. De code is op een uniforme manier gemaakt waarbij bijvoorbeeld gebruik gemaakt is van een code conventie.
   
5. De code is voor een buitenstaander goed leesbaar door het gebruik van goede variabele namen en functies en commentaar in de code. Deze naamgeving is Engels of Nederlands.
   
6. Er is gebruik gemaakt van versiebeheer. Vanuit het versiebeheer kunnen tenminste 5 oude versies van de code worden getoond.

(Punt 1 en 3 zijn cruciaal)

Deze beoordelingsrichtlijnen zijn gebaseerd op de SPL "Beoordelingsformulier praktijkexamen" (examencode SD_SD20_B1-K1-2_1V1, crebo 25604).

--

K1 W4 Testen

Werkproces 4 van kerntaak 1 gaat over het testen van software.

Je moet aantonen dat je het volgende beheerst.

Eisen

1. Je kunt een testplan opstellen. Het testplan sluit aan op het ontwerp (of user stories).
2. Het testplan heeft voldoende stappen en scenario's beschreven. Als alles testscenario's goed zijn doorlopen dan is er voldoende zekerheid over de juisten werking van de applicatie.
3. Je kunt een goed testrapport opstellen. Ui het testrapport is op te maken wat er is getest en wat de resultaten zijn.

Bewijsmateriaal

Wat kun je als bewijsmateriaal aanleveren in je portfolio?

1. Een door jouw opgesteld testplan.
   Het testrapport dient alle testen die nodig zijn om bepaalde functionaliteiten te testen te bevatten. De omschrijving moet eenduidig zijn. Testen moeten vanuit het testplan reproduceerbaar zijn.
2. Een door jouw opgesteld testrapport.
   Het testrapport dient alle resultaten te bevatten. Bij de bevindingen geef je ook aan wat jouw aanbeveling en/of conclusies zijn.
3. Een document waarin je uitlegt hoe het testen organisatorisch is verlopen en wat precies je rol was. Wie was jouw opdrachtgever, aan wie rapporteerde jij, waren er meer testers, wat deed je als je een fout had gevonden, etc.
4. Een reflectieverslag van hoe het testen is verlopen: wat ging goed en wat zou je de volgende keer anders doen?

Beoordelingsrichtlijnen

1. Het testplan omvat minimaal drie user story's. Van de user story's worden gemiddeld 5 test scenario's opgesteld. Er zijn dus minimaal 15 test scenario's beschreven.
2. De test scenario's zijn door een derde persoon na te spelen. Dit betekent dat: (1) de beginsituatie is beschreven waarbij de dataset eventueel beschreven of toegevoegd is (denk aan database export), (2) de gewenste juiste uitkomst is beschreven en (3) de stappen om te komen tot het resultaat zijn beschreven.
   
   Er zijn naast de hoofdscenario's ook alternatieve scenario's beschreven. Hierbij valt te denken aan bijvoorbeeld het invoeren van grenswaarden of foutieve waarden. Alternatieve scenario's testen vaak of de foutopvang juist is.
3. Het testrapport toont aan dat alle testscenario's zijn uitgevoerd en wat de resultaten zijn. De resultaten bevatten waar mogelijk conclusies en/of er wordt een algemene conclusie beschreven. Deze kan worden versterkt met een aanbeveling.

Deze beoordelingsrichtlijnen zijn gebaseerd op de SPL "Beoordelingsformulier praktijkexamen" (examencode SD_SD20_B1-K1-2_1V1, crebo 25604).

Testrapport (template).docx

--

K1 W5 Verbeteren

Werkproces 5 van kerntaak 1 gaat over verbteren of aanpassen van de software.

Je ontvangt de opdracht.

Je moet aantonen dat je het volgende beheerst.

Eisen

1. Je hebt de software gestest en vanuit het testen heb je verbetervoorstellen gedaan. Deze verbetervoorstellen mogen buiten de scope van het ontwerp leggen. De verbetervoorstellen worden onderbouwd.
2. Tijdens de oplevering van de software heb je dingen gezien die beter kunnen. Hieruit heb je verbetervoorstellen gedaan. Deze verbetervoorstellen zijn goed onderbouwd.
3. Je hebt voor jezelf een reflectie gemaakt over het product. Hieruit heb je verbetervoorstellen gedaan. Deze verbetervoorstellen zijn goed onderbouwd.

Het uitvoeren van de verteringen is geen onderdeel van dit werkproces, maar kan wel als onderdeel mee worden genomen in werkproces 2 (realisatie).

Bewijsmateriaal

Wat kun je als bewijsmateriaal aanleveren in je portfolio?

1. Eigen gemaakte verbetervoorstellen.
2. Een beschrijving van hoe je bent gekomen tot het opstellen van de verbetervoorstellen. Deed je dat alleen, met wie heb je overlegd, kreeg je input. Wie hebben je verbetervoorstellen gelezen? Hoe lang heb je er over gedaan en in welke periode heb je de voorstellen gemaakt.

Beoordelingsrichtlijnen

1. Er zijn verbetervoorstellen gedaan die zijn gebaseerd beschreven bevindingen. Dit is het testrapport, maar kunnen ook incidentmeldingen zijn vanuit de productieomgeving (tijdens een stage). Er wordt in ieder geval aangetoond wat de basis is van de verbeteringen.
2. Er zijn verbetervoorstellen gedaan vanuit de opleveringen. Je levert altijd op aan een opdrachtgever (of klant). Vraag de opdrachtgever of er verbeteringen kunnen worden aangebracht. Wanneer deze er niet zijn dan aantonen dat de klant geen verbetervoorstellen heeft.
3. Er zijn verbetervoorstellen gedaan vanuit de (eigen) reflectie van het product.

Deze beoordelingsrichtlijnen zijn gebaseerd op de SPL "Beoordelingsformulier praktijkexamen" (examencode SD_SD20_B1-K1-2_1V1, crebo 25604).

--

K2 Ontwikkelteam

K2 W1 Overleggen

Werkproces 1 van kerntaak 2 gaat over hoe je in een ontwikkelteam hebt samengewerkt.

Je moet aantonen dat je het volgende beheerst:

Eisen

1. Je werkt actief mee.
   Dit betekent dat je deel van het team uitmaakt en dat je initiatieven neemt. Dat kan zijn dat je de juiste vragen stelt of de juiste onderwerpen aandraagt. Dit doe je natuurlijk op een constructieve manier.
2. Je stemt regelmatig af.
   Je zorgt ervoor dat je regelmatig, bijvoorbeeld 1x per dag of 1x per week overleg hebt met jouw leidinggevende.
3. Je legt afspraken vast.
   Je zorgt er ook voor dat afspraken met jouw opdrachtgever en/of klant worden vastgelegd en je hebt hierin een actieve rol.

Bewijsmateriaal

Wat kun je als bewijsmateriaal aanleveren in je portfolio?

1. Een (reflectie)verslag over hoe jij hebt samengewerkt in het ontwikkelteam. Wat was jouw rol, wat waren jouw sterkte punten, wat waren je minder goede punten. Wat zou je de volgende keer anders doen?
   Vraag je teamgenoten ook om input.
2. Een filmpje dat een indruk geeft van het team en hoe jullie overleggen. Het gaat hierbij om een indruk dus 1 à 2 minuten film is meer dan genoeg.
3. Een beschrijving en/of reflectieverslag over hoe je hebt afgestemd. Hoe ging dat, wat ging goed en wat kon beter?
4. Door jouw vastgelegde afspraken. De afspraken zijn eenduidig, bevatten een datum en een deadline en het is duidelijk voor wie de afspraken bedoeld zijn.
5. Een beschrijving en/of reflectieverslag over hoe het maken van afspraken is gegaan. Zijn alle afspraken altijd nagekomen en waarom wel of niet? Wat ging goed en wat zou je een volgende keer anders aanpakken?
   
6. Een filmpje dat een indruk geeft van hoe jij afstemt. Het gaat hierbij om een indruk dus 1 à 2 minuten film is meer dan genoeg.

--

K2 W2 Presenteren

Werkproces 2 van kerntaak 2 gaat over presenteren.

Je moet aantonen dat je het volgende beheerst:

Eisen

1. Je doet een presentatie.
   Je presenteert overtuigd, duidelijk en je verhaal is afgestemd op de doelgroep.
2. Informeren betrokkenen.
   Je legt betrokkenen (leidinggevende of klant) uit hoe zaken werken en je stelt vragen om te controleren of de informatie goed is overgekomen.
3. Feedback ontvangen.
   Je ontvang feedback, staat daarvoor open en reageert goed op feedback.

Bewijsmateriaal

Wat kun je als bewijsmateriaal aanleveren in je portfolio?

1. Een filmpje en beschrijving van één of meer presentaties.
2. Een zelfgemaakte PowerPoint (of soortgelijk) van een presentatie die jij hebt gegeven. Geef ook een beschrijving van de presentatie; voor wie en wanneer en wat was het doel van de presentatie.
3. Een beschrijving van wanneer jij wie hebt geïnformeerd en hoe jij hebt gecontroleerd of de betrokkenen alles goed begrepen hadden?
4. De feedback die jij hebt ontvangen en een beschrijving van de situatie en wat jij met de feedback hebt gedaan.
   Ook hier zou je ook een kort filmpje kunnen laten zien waarin jij feedback krijgt.

--

K2 W3 Reflectie

Werkproces 3 van kerntaak 2 gaat over reflectie.

Waarschijnlijk heb je al meerdere reflecties gemaakt; deze kun je ook gebruiken voor dit werkproces.

Je moet aantonen dat je het volgende beheerst:

Eisen

1. Je kunt een reflectieverslag opstellen waarin je terugkijkt naar je eigen handelen en waarbij je positieve en verbeterpunten van het proces noemt. Je maakt hierbij onderscheid tussen de teamprestaties en je eigen prestaties.
2. Je ontvang al dan niet op eigen verzoek feedback en je reageert daar constructief en adequaat op.
3. Tijdens meetings/overleggen reageer jij proactief en heb je een actieve positieve houding.

Checklist

1. Gaat het verslag over jouw handelen?
2. Benoem je goede punten over jouw handelen?
3. Benoem je verbeterpunten over jouw handelen?
4. Maak je onderscheid tussen jouw handelen en dat van het team waar jij deel van uit maakt?
5. Geef je in het verslag aan dat je feedback hebt gehad en hoe je daarop reageert?
6. Beschrijf je in het verslag dat jij een pro-actieve houding hebt (dus dat jij initiatief laat zien)

Bewijsmateriaal

Wat kun je als bewijsmateriaal aanleveren in je portfolio?

1. Reflectieverslagen waarin je duidelijk onderscheid maakt tussen: positieve punten en verbeterpunten en tussen teamprestaties en eigen prestaties.
2. Een beschrijving van wie je wanneer in welke situatie feedback kreeg en hoe je daarop hebt gereageerd. Je laat dit verlag tekenen door degene van wie je de feedback kreeg.
   Voor dit punt is een beschrijving over één voorval niet voldoende. Vul dit bewijs aan met een filmpje of stel eerdere beschrijvingen op.
3. Een beschrijving van een meeting en hoe jij daar een proactieve houding hebt laten zien. Je laat dit verslag tekenen door de voorzitter van de meeting.
   Voor dit punt is een beschrijving over één voorval niet voldoende. Vul dit bewijs aan met een filmpje of stel eerdere beschrijvingen op.

Template

Template voor maken reflectieverslag volgens methode STARR:  STARR Voorbeeld en template.docx .

--

K2W3 Reflectie voorbeelden

Voorbeeld 1 - veel voorkomend

Reflectie

Ik vond het goed van mezelf dat ik probeerde om het probleem volledig zelfstandig op te lossen, zelf als het uiteindelijk niet gelukt is om de ticket die dag af te handelen.

Als ik wat eerder XXX om hulp vroeg had ik waarschijnlijk de ticket die dag wel af kunnen ronden.

Volgende keer moet ik dus wat eerder om hulp vragen, of een afspraak maken over hoe ik een vraag achter kan laten voor als mijn begeleider het minder druk heeft. Ik moet ook leren wat sneller vragen te stellen, en dat ik niet altijd 100% zelfstandig moet zijn.

Voorbeeld 2 - beter?

Reflectie

Wat ging goed en wat niet?

Ik probeerde laatst een probleem helemaal zelf op te lossen tijdens een project. Hoewel ik het goed vond dat ik dit probeerde, lukte het niet om de taak die dag af te ronden. Dit liet me zien dat ik soms te lang wacht om hulp te vragen.

Wat was het probleem?

Het probleem was dat ik te lang aarzelde om hulp te vragen. Ik dacht dat ik alles alleen moest kunnen doen om te laten zien dat ik het aan kon. Hierdoor raakte ik vast en verspilde ik tijd, wat het project vertraagde en me gestrest maakte.

Wat ga ik anders doen?

Om dit te verbeteren, ga ik de volgende dingen anders doen:

1. Sneller Hulp Vragen: Ik zal eerder om hulp vragen, al bij de eerste tekenen dat ik vastloop. Dit voorkomt dat ik te veel tijd verlies.

2. Beter Afspreken Over Vragen: Ik maak afspraken met mijn begeleider over hoe en wanneer ik vragen kan stellen, vooral als hij of zij druk is. Dit kan via e-mail of tijdens geplande momenten.

3. Balans Vinden: Ik moet leren dat het oké is om hulp te vragen en dat dit juist laat zien dat ik serieus bezig ben en wil leren. Het is niet erg om soms samen te werken.

Evaluatie van de verandering, helpt het?

Om te zien of deze veranderingen helpen, zal ik:

• Feedback Vragen: Regelmatig aan mijn begeleider en teamgenoten vragen hoe ze vinden dat ik het doe met hulp vragen en samenwerken.
• Reflecteren: Na elk project nadenken over hoe vaak ik hulp heb gevraagd en of dit het werk makkelijker maakte.
• Zelf Nakijken: Letten op mijn eigen stress en tevredenheid om te zien of ik me beter voel tijdens het werk.

Door dit te doen, hoop ik beter te worden in mijn werk en minder gestrest te zijn, en een goede balans te vinden tussen zelf dingen doen en samenwerken.

Voorbeeld 3 - uitgebreid

Reflectie

Over het algemeen vond ik het voor de eerste keer dat ik met deze programma’s heb gewerkt goed gaan. Ik heb het gevoel dat ik door deze opdracht goed voorbereid ben op volgende opdrachten die ik ga krijgen, omdat deze opdracht heel veel verschillende elementen heeft. Ik liep niet al te veel vast, ik kwam vaak snel op de oplossingen en ik heb goede begeleiding gehad. Ook ben ik erg tevreden met het eindresultaat. Het ziet er goed en mooi uit en alles werkt. Maar niet alles ging even goed, sommige dingen konden beter en zou ik bij een volgende opdracht anders doen.

Wat ging er goed?

Bij het maken van het ontwerp wist ik gelijk wat ik wilde en daarom ging het stijlen van de pagina ging voor mij erg goed. Ik had een duidelijke visie voor het uiterlijk en dit heb ik ook precies zo uitgevoerd. Ook had ik werken met material UI had ik snel onder de knie en verliep dit allemaal vrij soepel. Ik ben daarom ook erg tevreden met het resultaat.

Naast de styling ging het eerste deel van het maken van de site ook erg goed. Ik had een video die mij precies begeleide bij wat ik aan het doen was en zo ging het allemaal erg makkelijk. Ik snapte alles ook goed door de duidelijke uitleg. Deze video was voor mij een goede oplossing voor niet weten waar ik moest beginnen. Vaak als er een tutorial wordt gebruikt dan doe je gewoon na wat er gebeurt en snap je aan het einde vaak niet wat je precies hebt gedaan. Hier had ik een oplossing voor gevonden door achteraf aantekeningen te maken met daarin een uitleg in mijn eigen woorden. Voor mij werkte dit erg goed en zo snapte ik aan het einde alles, omdat ik het eigenlijk opnieuw aan mezelf aan het uitleggen was.

Wat kan ik verbeteren?

Tijdens het werken aan dit project heb ik een aantal verbeterpunten gevonden voor zowel coderen als mijn manier van werken. Als eerste is een groot verbeterpunt voor mij dat ik eerder op hulp moet vragen. Omdat ik graag alles zelf wil doen en alles zelf wil uitzoeken kan dit mij soms behoorlijk in de weg zitten en vertragen in het proces. Bij dit project heb ik bijvoorbeeld soms wel 3 weken met 1 probleem gezeten omdat ik het zelf wilde uitzoeken. In het vervolg zou ik graag willen leren om eerder om hulp te vragen en een balans te vinden tussen zelf oplossen en hulp vragen.  Omdat iemand anders de oplossing misschien sneller kan vinden en dit gelijk ziet. Dit scheelt behoorlijk wat tijd.

Als tweede verbeterpunt heb ik om een betere planning te maken. In het proces van dit project ben ik eerst gaan werken en heb ik daarna pas een planning gemaakt. Dit zou ik bij een volgende opdracht anders doen, omdat dit voor meer structuur tijdens het werken zorgt. Ook denk ik dat het zo zou helpen bij mijn andere verbeterpunten. Door het maken van het examen portfolio heb ik ook kunnen leren hoe ik een goede planning maak en mij aan deze planning kan houden.

Als laatste verbeterpunt heb ik dat ik beter moet werken met versie beheer. Ik had voor deze opdracht een kladblok gebruikt als versie beheer. Dit werkte redelijk goed, alleen kon ik dit niet makkelijk terughalen in het programma waar ik in werk. Zo zijn er ook andere manieren om te werken met versie beheer zoals GIT. Als ik hiermee had gewerkt kon in alle bestanden in hetzelfde programma halen voor overzicht.

Verbeteren en omgaan met feedback

In de code ging de feedback vooral over dingen zoals foutmeldingen afhandelen en toevoegen en informatie aan de URL toevoegen. In de URL moest er informatie zoals een ID en pagina’s nummers toegevoegd worden. Dit zijn wat kleinere dingen waar ik tijdens het werken niet aan had gedacht, maar door de feedback wel heb toegevoegd aan de website. Door aanpassingen te doen in de code.  Zo is ook de gebruiksvriendelijkheid verbeterd. Ook heb afhandelen van foutmeldingen had ik niet overal aan gedacht. Op bijvoorbeeld de homepagina moest ik bij de zoekbalk een melding toevoegen wanneer er geen resultaten zijn de overeengekomen met de zoekopdracht. Dit heb ik gedaan door een functie te maken die daarvoor zorgt. Deze functie heb ik ook vaker kunnen hergebruiken voor de andere pagina’s. Als laatste heb ik feedback gekregen over het responsive maken van de afbeeldingen op de website zodat deze ook mooi staan op een ander scherm. Dit heb ik gedaan met SASS door breakpoints toe te voegen. De rest van de website was al responsive door Material UI.

Voorbeeld 4

Reflectie

Nu de uiteindelijke reflectie. Persoonlijk vond ik dat de meeste dingen goed gingen, vanaf het brainstormen over het ontwerp tot het voltooien van de volledige website. Het ging over het algemeen best wel goed. De samenwerking verliep als gepland. Beide waren we tevreden met onze rollen gedurende dit project.

Wij hadden als team elkaar wel wat feedback gegeven. Ik gaf XXX de volgende feedback: Betere communicatie, onze communicatie was prima, maar kon wel beter. Al eerder verteld dat we vaker een meeting konden hebben, of vaker met elkaar afspreken. XXX kon vaker een update geven als hij wat gedaan, maar voor de rest heeft XXX het supergedaan tijdens dit project. Toen gaf XXX mij feedback. XXX gaf mij de volgende feedback: Ook XXX vond dat ik meer kon communiceren. XXX vond dat ik ook te weinig updates gaf, waar ik het mee eens ben. Ik kon vaker updates geven over hoe ver ik was met de website. Bijvoorbeeld, als ik met een stukje code klaar was, dan kan ik dat direct vertellen, dan was XXX er ook meteen op de hoogte van. Of als ik even niet bezig ben, dat ik dat ook vertel, want dan weet XXX ook dat ik even niet bezig ben. XXX gaf mij ook als feedback dat ik te lange pauzes nam, niet van 2 uur, maar echt van dagen. Als je een project met elkaar begint, moet je er vol voor gaan, zei XXX . Ik kan het niet anders eens zijn met wat XXX hier zegt, ik nam veel te veel pauze. XXX gaf dit aan na een aantal weken, en heb hier meteen verandering in gebracht. Verder in het project is het goed gegaan en gaan lange pauzes meer genomen. Verder had XXX geen feedback meer op mij.

Ten slotte, mijn gedrag om feedback te ontvangen en actie te ondernemen om mijn gedrag te verbeteren, laat zien dat ik niet alleen initiatief kan tonen bij het nemen van beslissingen, maar ook bij het maken van verbeteringen en goede communicatie. De lessen die ik heb gehad met XXX , over samenwerking en communicatie kan ik in de toekomst toepassen in andere situaties waarin teamwork en regelmatige communicatie heel belangrijk zijn

Voorbeeld Examenproject (2020)

Case "PoC Share Wheels"

Het Bedrijf

Het bedrijf "Share Wheels" heeft tot doel om een platform aan te bieden waarmee het mogelijk is om jouw auto te verhuren. Het bedrijf is een start-up en wil graag een app ontwikkelen waarmee het de gebruiker in staat stelt om hun auto te verhuren. Het bedrijf bestaat uit drie vrienden die een programmeur zoeken om een "proof of concept" (PoC) te maken, dat is zeg maar een soort testversie waarmee het concept van het delen van een auto kan worden getest.

De drie vrienden hebben eerder een start-up opgezet en hebbend deze verkocht. Deze start-up had software ontwikkeld om epidemieën beter te kunnen voorspellen. De vrienden hebben geen tekort aan kapitaal en zijn in staat om lange tijd geld te investeren zonder dat er winst hoeft te worden gemaakt. Zij willen voorlopig alleen samenwerken met ZZP'ers.

Het Concept

Het idee is dat de een auto wordt aangeboden. Om een auto te kunnen verhuren moet je geregistreerd zijn. Ook de auto huurder zal zich moeten registreren. Bij de registratie moet ook worden gecontroleerd of de huurder in bezit is van een geldig rijbewijs.

De huurder kan aangeven welke auto hij wanneer te huur wil aanbieden. De verhuurder kan binnen een bepaalde prijs range ook aangeven wat de huurprijs is. De huurprijs is opgebouwd uit een kilometerprijs en een dagprijs. De verhuurder kan aangeven wie hij in aanmerking wil laten komen voor de verhuur van zijn auto. Dat kan hij doen door aan te geven hoe lang de huurder in bezit moet zijn van een rijbewijs.

De verhuurder geeft per dag van de week aan welk dagdeel de auto beschikbaar is.

In principe wordt een auto alleen verhuurd aan iemand uit dezelfde buurt.

De App

De app moet de verhuurder en de huurder bij elkaar brengen. In het PoC hoeft de app nog geen betaling te ondersteunen. De betaling van de huurder aan de verhuurder gebeurt dus voorlopig buiten de app om. De app dient er dus voor om huurder en verhuurder bij elkaar te brengen. De app moet er uitnodigend uitzien en een goede performance hebben. De gegevens van de huurder en verhuurder moeten beveiligd worden opgeslagen.

In de PoC hoeft nog geen 2 factor authenticatie te worden geïmplementeerd, maar in een eventueel vervolg versie moet dit wel.

De app moet op Android en IOS kunnen draaien en als het de ontwikkeling versneld, mag in de PoC ook een webpagina worden gebruikt. Die moet er dan wel uitzien als een App.

De app moet gegevens verzamelen, zodat er meer inzicht wordt verkregen in deze markt. Er moet worden vastgelegd wanneer de app wordt gebruikt en welke tijden de vraag naar een huurauto het grootst is. Ook moet er worden bijgehouden op welke tijdstippen auto's voor de verhuur worden aangeboden. Deze informatie is nodig om het prijsmodel te kunnen optimaliseren.

Web App

De web app moet de volgende functies hebben:

1. Invoeren van verhuurders informatie.
2. Zoeken naar verhuurders.
3. Lijst maken van alle verhuurders.
4. Kunnen aanpassen en verwijderen van een verhuurder.
5. De website wordt beveiligd via een login. Wachtwoorden moeten veilig worden opgeslagen.
6. Zoeken mogelijk op meerdere velden (Google-stijl).
7. Een import om verhuurders informatie in een keer importeren of te exporteren in XML of JSON.
8. Een mooie uitnodigende GUI waarin op een snelle en handige manier de beschikbaarheid per dag kan worden veranderd.
9. Systeem is volledig responsive en de interface is geoptimaliseerd voor Laptop en mobiel.

• Beheer module voor login’s met reset password.
• Extra beveiliging maken voor opslag wachtwoord door middel van hashing en salt.
• Kom met een eigen voorstel ter verbetering van de eerste versie van het product. Vraag wel goedkeuring aan de klant (docent).

Projectmedewerkers taken en verantwoordelijkheden

Je doet dit project met 2 of 3 man.

Voer je dit project met 2 man uit dan kies je minimaal 6 functionaliteiten uit de lijst. Ben je met drie man dan kies je 9 functionaliteiten.

Je bent met jou Team verantwoordelijk voor alle gekozen functionaliteiten. Je verdeelt wel de taken maar jullie worden beoordeeld op het proces en product dat jullie samen uitvoeren.

Heb je zelf een idee (punt 12), prima, maar overleg met de klant (of docent) en vraag goedkeuring.

--

Check List 2024-2025

Kerntaakexamen

Het examen bestaat uit 2 kerntaken met in totaal 8 werkprocessen.

Kerntaak-1: uitvoeren van een project (5 werkprocessen)
Kerntaak-2: samenwerken in een team (3 werkprocessen)

Voor het examen moet het ingeleverde werk aan officiële eisen voldoen. Deze zijn samengevat in de onderstaande checklist.

Kerntaak 1

Algemeen

• Gaat jouw planning, ontwerp, realisatie, testen en verbeteren over één project?
• Zijn er minimaal 3 user story's beschreven?
  Werk je samen met anderen: heeft ieder teamlid 3 unieke user story's beschreven?
• Is bij elke opdracht duidelijk wie wat heeft gedaan?
• Werk je samen met anderen: Alleen bij de planning (KT1, W1) mag één gemeenschappelijk document worden ingeleverd, alle andere documenten zijn individueel.

K1W1: Planning

1. Is er beschreven wat er gebouwd moet worden?
2. Is er beschreven waarom het gebouwd moet worden?
3. Zijn alle eisen beschreven?
4. Zijn er minimaal 3 user story's beschreven
    Werk je samen met anderen: 2 teamleden? 6 userstory's   3 teamleden? 9 userstory's  etc.
5. Staan de user story's in het formaat "als ..... wil ik ..... zodat ....."?
6. Zijn de user story's en eisen concreet en éénduidig (testbaar)?
7. Is er een takenlijst waarin alle taken staan en zijn deze project-specifiek?
8. Zijn er overleggen gepland?
9. Is bij elke taak beschreven hoe lang deze duurt?
10. Is bij elke taak beschreven wie deze moet uitvoeren?
11. Staan de taken op de juiste volgorde?
12. Zijn er prioriteiten gesteld?
13. Is de voortgang bewaakt?

K1W2: Ontwerp

1. Is elke user story uit de planning vertaald naar een ontwerp waardoor je een beeld krijgt hoe de user story er uit gaat zien?
2. Zijn er in het ontwerp tekeningen/schetsen van de User Interface te vinden?
3. Zijn er minimaal 2 schematechnieken toegepast, (bijvoorbeeld ERD, activiteitendiagram, klassendiagram, Use Case diagram)?
4. Zijn de keuzes in het ontwerp concreet onderbouwd/uitgelegd?
5. Zijn de onderwerpen ethiek, privacy en security besproken?
6. Zijn de onderwerpen ethiek, privacy en security specifiek alleen van toepassing op jouw project?

K1W3: Realisatie

1. Bevat je project code (maak je gebruik van datastructuren (variabelen, arrays....), flow control (loops), functies/methoden)?
2. Heb je minimaal 3 user story's opgeleverd?
   Werk je samen met anderen: 2 teamleden? 6 userstory's   3 teamleden? 9 userstory's  etc.
3. Heeft de realisatie (dus dit onderdeel), ongeveer 40 uur gekost?
   Werk je samen met anderen: 2 teamleden? 80 uur   3 teamleden? 120 uur etc.
   
4. Voldoet het resultaat aan het ontwerp?
5. Worden fouten in de code afgehandeld (error handling)?
6. Heb je rekening gehouden met security?
7. Is er volgens een standaard geprogrammeerd (inspringen, variabele naamgeving en dergelijke)?
8. Is de code goed leesbaar en begrijpelijk. Is er zinvol commentaar toegevoegd?
9. Heb je op een juiste manier versie beheer toegepast?
10. Videobestand(en) <= 400 MB?

K1W4: Testen

1. Zijn er per user story min. 5 testscenario's opgesteld?
2. Is bij elk testscenario concreet en eenduidig beschreven wat de beginsituatie was?
3. Is bij elk testscenario concreet en eenduidig beschreven wat de gewenste uitkomst was?
4. Zijn er alternatieve testscenario's beschreven?
5. Zijn er fouten gevonden?
6. Is elk testscenario uitgevoerd en zijn de bevindingen vastgelegd?
7. Is bij elk testscenario beschreven wat de conclusie/aanbeveling is?
8. Zijn alle scenario's concreet en eenduidig beschreven zodat er geen discussie kan ontstaan over de bevindingen?
   

AI/ChatGPT geeft vrijwel nooit concreet en eenduidige teksten!

K1W5: Verbetervoorstellen

1. Zijn er 2 of meer verbeteringen beschreven die zijn gebaseerd op de bevindingen uit het testrapport (W4)?
2. Zijn er 2 of meer verbeteringen beschreven die zijn gebaseerd op de bevindingen vanuit de oplevering?
   
3. Zijn er 2 of meer verbeteringen beschreven die zijn gebaseerd op de eigen reflectie?
4. Zijn de verbetervoorstellen eenduidig en concreet beschreven?

Kerntaak 2

K2W1: Overleggen

1. Stel je (relevante) vragen tijdens het overleg?
2. Breng jij wat mee naar het overleg, breng je bijvoorbeeld een onderwerp in?
3. Laat je zien dat je regelmatig afstemt?
4. Laat je zien dat je afspraken vastlegt?
5. Laat je zien dat je afspraken na komt?
6. Doe je actief mee met het overleg?
7. Videobestand <= 400 MB?

K2W2: Presenteren

1. Presenteer je overtuigend (positief, met passie, trots en met een goede energie)?
2. Onderbouw je je presentatie met goede argumenten?
3. Presenteer je een duidelijk verhaal?
4. Is de presentatie afgestemd op de doelgroep?
5. Stel je vragen aan de betrokkenen om te controleren of ze de presentatie begrijpen?
6. Reageer je op de juiste manier op vragen/feedback?
7. Gaat de presentatie over de stage of een ander onderwerp dat te maken heeft met het vak van software developer?
8. Videobestand <= 400 MB?

K2W3: Reflectie

1. Gaat het verslag over jouw handelen?
2. Benoem je goede punten over jouw handelen?
3. Benoem je verbeterpunten over jouw handelen?
4. Maak je onderscheid tussen jouw handelen en dat van het team waar je deel van uit maakt?
5. Beschrijf je feedback die je hebt gekregen?
   
6. Beschrijf je wat je hebt gedaan met de feedback?
7. Beschrijf je in het verslag dat jij een proactieve houding hebt (dus dat je initiatief laat zien).
8. Wees concreet (dus geen AI)!
   Teksten die je kan kopiëren en voor een (willekeurige) andere reflectie ook zouden kunnen gelden, zijn niet goed.
   Gebruik details!
   

Check List 2025 (vanaf cohort 24 - voorstel)

Dit is nog niet officeel!!

Kerntaak examens

Het kerntaakexamen heeft 8 werkprocessen verdeeld over twee kernexamens; kerntaak-1 en kerntaak-2.

Kerntaak-1 gaat over het uitvoeren van een project en kerntaak-2 gaat over het samenwerken in een team.

Voor het examen moet je aan een aantal officiële eisen voldoen. Deze zijn samengevat in de onderstaande check-list.

Kerntaak 1

Algemeen

• Gaat Kerntaak 1 (planning, ontwerp, realisatie, testen en verbeteren) over één project?
• Heeft elk persoon minimaal (liefst iets meer) 3 goede user story's op zich genomen?
• Is bij elke opdracht duidelijk wie wat heeft gedaan?
• Alleen bij de planning (KT1, W1) mag één gemeenschappelijk document worden ingeleverd, alle andere documenten zijn individueel.

Planning

1. Is er beschreven wat er gebouwd moet worden?
2. Is er beschreven waarom het gebouwd moet worden?
3. Zijn alle eisen beschreven?
   
4. Is de user story concreet en eenduidig (testbaar)?
5. Is er takenlijst waarin alle taken staan?
6. Zijn er overleggen gepland?
7. Is bij elke taak beschreven hoe lang deze duurt?
8. Is bij elke taak beschreven wie deze moet uitvoeren?
9. Staan de taken op de juiste volgorde?
10. Zijn er prioriteiten gesteld?
11. Is de voortgang bewaakt?

Ontwerp

1. Zijn de functionaliteiten vertaald naar een ontwerp waardoor je een beeld krijgt hoe de applicatie er uit komt te zien?
2. Zijn er in het ontwerp tekeningen/schetsen van de User Interface te vinden?
3. Zijn er minimaal twee schematechnieken toegepast, (bijvoorbeeld ERD, activiteitendiagram, klassendiagram, Use Case diagram)?
4. De keuzes in het ontwerp worden onderbouwd/uitgelegd?
5. Is er bij de onderbouwing rekening gehouden met de onderwerpen usability, ethiek, privacy en security?
6. Is de onderbouwing specifiek genoeg; dus niet algemeen maar specifiek voor jouw project?
   

Realisatie

1. Bevat je project code waarin je gebruik maakt van datastructuren (variabelen, arrays....), flow control (loops), functies/methods en dergelijke?
   
2. Heeft de realisatie (dus dit onderdeel), ongeveer 40 uur per persoon gekost?
3. Voldoet het resultaat aan het ontwerp?
4. Worden fouten in de code goed afgehandeld (error handling)?
5. Heb je rekening gehouden met security?
6. Is er volgens een standaard geprogrammeerd (inspringen, variabele naamgeving en dergelijke)?
7. Is de code goed leesbaar en begrijpelijk. Is er zinvol commentaar toegevoegd?
8. Heb je op een juiste manier versie beheer toegepast?

Testen

1. Zijn er per user story zijn minimaal 5 testscenario's opgesteld?
2. Is bij elk testscenario concreet en eenduidig beschreven wat de beginsituatie was?
3. Is bij elk testscenario concreet en eenduidig beschreven wat de gewenste uitkomst was?
4. Zijn er alternatieve testscenario's beschreven?
5. Zijn er fouten gevonden?
6. Is elk testscenario uitgevoerd en zijn de bevindingen vastgelegd?
7. Is bij elk testscenario beschreven wat de conclusie/aanbeveling is?
8. Zijn alle scenario's concreet en eenduidig beschreven zodat er geen discussie kan ontstaan over de bevindingen?
   

AI/ChatGPT geeft vrijwel nooit concreet en eenduidige teksten!

Verbetervoorstellen

1. Zijn er twee of meer verbeteringen beschreven die zijn gebaseerd op de bevindingen uit het testrapport (W4)?
2. Zijn er twee of meer verbeteringen beschreven die zijn gebaseerd op de bevindingen vanuit de oplevering?
   
3. Zijn er twee of meer verbeteringen beschreven die zijn gebaseerd op de eigen reflectie?
4. Zijn de verbetervoorstellen zijn eenduidig, concreet beschreven?

Kerntaak 2

Overleggen

1. Stel je (relevante) vragen tijdens het overleg?
2. Breng jij wat mee naar het overleg, breng je bijvoorbeeld een onderwerp in?
3. Laat je zien dat je regelmatig afstemt?
4. Laat je zien dat je afspraken vastlegt?
5. Laat je zien dat je afspraken na komt?
6. Doe je actief mee met het overleg?

Presenteren

1. Presenteer je overtuigend (positief, met passie, trots en met een goede energie)?
2. Onderbouw je je presentatie met goede argumenten?
3. Presenteer je een duidelijk verhaal?
4. Is de presentatie afgestemd op de doelgroep?
5. Stel je vragen aan de betrokkenen om te controleren of ze de presentatie begrijpen?
6. Reageer je op de juiste manier op vragen/feedback?
7. Gaat de presentatie over de stage of een ander onderwerp dat te maken heeft met het vak van software developer?

Reflectie

Je voldoet aan alle exameneisen als je tenminste ja kunt antwoorden op deze vragen.

1. Gaat het verslag over jouw handelen?
2. Benoem je goede punten over jouw handelen?
3. Benoem je verbeterpunten over jouw handelen?
4. Maak je onderscheid tussen jouw handelen en dat van het team waar je deel van uit maakt?
5. Beschrijf feedback die je hebt gekregen?
   
6. Beschrijf je wat je hebt gedaan met de feedback?
7. Beschrijf je in het verslag dat jij een pro-actieve houding hebt (dus dat je initiatief laat zien)

--

Examineringsproces

(naar aanleiding van calibratie-sessie 17-april 2024)

Examenafspraken Kerntaak 1 en 2:

• Alleen als alle kerntaken met een voldoende zijn beoordeeld kan een kandidaat examen doen in de vorm van een (examen)eindgesprek. 
• Het hoofddoel van het gesprek is de authenticiteitscontrole. In een enkel geval kan, indien nodig, de beoordeling worden gewijzigd. 
• De eindpresentatie wordt zoveel mogelijk beoordeeld door onafhankelijke beoordelaars (geen eigen docent, geen mentor). 
• De duur van het examengesprek is 15 minuten, met 10 minuten overhead per gesprek; 5 minuten introductie (met kandidaat) en 5 minuten nabespreken (zonder kandidaat). 
• K1W3 (realisatie) dient altijd te worden besproken. Daarnaast dient minimaal de helft van de te examineren werkprocessen worden besproken. Als richtlijn worden de volgende gesprekstijden aangehouden: K1W3  5 minuten, en andere werkprocessen elk ongeveer 2 minuten. Het totale gesprek zal, afhankelijk van het de te bespreken werkprocessen, niet meer dan 15 minuten duren, met een minimum van 5 minuten. 
• Op het beoordelingsformulier wordt aangegeven welke werkprocessen tijdens het eindgesprek zijn besproken. Eventuele aanpassing in beoordeling dient te worden toegelicht.
  

Follow-up plan: 

• Kerntaak 2 wordt uitgevoerd tijdens de eerste stage, met de herkansing tijdens de tweede stage. De beoordeling van deze kerntaak vindt plaats op school. 
• De BPV-begeleider initieert het contact met het (leer)bedrijf en controleert of de te examineren werkprocessen uitvoerbaar zijn. Het (leer)bedrijf wordt geïnformeerd over hun rol bij de examinering op de werkplek. 
• Er komt een nieuwe onderlegger speciaal voor de beoordeling van de kerntaken. 

 

Examen Rubics

Examen Rubics

Portfolio-examen SPL Rubics  SD_SD20_PF1_B1-K1-K2_2v1.

K1W1 - Planning

1. De uitgangspunten zijn juist verwerkt (Definition of done) en de eisen en wensen zijn verwerkt in de user stories.
   
2. De user stories voldoen aan de criteria (wie, wat, waarom en realistisch).
   
3. Op basis van de user stories is een complete en realistische planning gemaakt.
4. De voortgang is bewaakt en de juiste keuzes/afwegingen zijn gemaakt op basis van prioriteiten.
   

K1W2 - Ontwerp

1. De user stories zijn vertaald naar een passend, eenduidig en volledig ontwerp (sluit aan op wensen en eisen).
   
2. Er is gebruik gemaakt van relevante of toepasselijke schematechnieken (bijv. activiteitendiagram, klassendiagram, ERD, use case diagram).
   
3. De gemaakte keuzes in het ontwerp zijn onderbouwd met steekhoudende argumenten, waarbij rekening is gehouden met bijv. ethiek, privacy en security.
   

K1W3 - Realisatie

1. Er is voldoende inhoud van de user stories gerealiseerd binnen de gestelde/geplande tijd.
2. De opgeleverde functionaliteiten voldoen aan de eisen en wensen.
3. De kwaliteit van de code is goed. Dit uit zich onder andere in: structuur van de code, validatie, efficiëntie, foutafhandeling en terugkoppeling, security (veilig programmeren). 
4. De code is opgesteld volgens code conventions.
5. De code is verzorgd, leesbaar, gestructureerd en voorzien van zinvol commentaar.
6. Versiebeheer is effectief toegepast.

K1W4 - Testen

1. De testcases in het testplan sluiten aan op de user stories en bevatten alle scenario's.
2. De stappen, het gewenste resultaat en testdata zijn benoemd. Niet alleen het hoofdscenario, maar ook alternatieve scenario's. 
3. De stappen, het gewenste resultaat en testdata zijn benoemd. Niet alleen het hoofdscenario, maar ook alternatieve scenario's. 

K1W5 - Verbeteren

1. De juiste verbetervoorstellen zijn gedaan vanuit het testen.
2. De juiste verbetervoorstellen zijn gedaan vanuit de oplevering.
3. De juiste verbetervoorstellen zijn gedaan vanuit de reflectie.

K2W1 - Overleggen

1. De kandidaat neemt actief deel waarbij relevante onderwerpen worden ingebracht en de juiste vragen worden gesteld.
2. De kandidaat stemt regelmatig en tijdig af met projectteamleden en opdrachtgever over de voortgang en eventuele knelpunten.
3. De gemaakte afspraken zijn eenduidig vastgelegd.
4. De kandidaat houdt zich aan gemaakte afspraken.

K2W2 - Presenteren

1. De kandidaat presenteert een overtuigend, duidelijk, beargumenteerd verhaal, afgestemd op de doelgroep.
2. De kandidaat stelt gerichte vragen om te controleren of de betrokkenen goed geïnformeerd zijn over het opgeleverde werk.
3. De kandidaat reageert adequaat op feedback.

K2W3 - Reflectie

1. De kandidaat benoemt  zowel positieve als verbeterpunten van het proces van zowel eigen als teamprestaties.
2. De kandidaat reageert adequaat op de ontvangen feedback.
3. De kandidaat heeft een proactieve houding tijdens reflectiemeetings.

--

Examen Rubics 2024 v 2023

Portfolio-examen SPL Rubics  SD_SD20_PF1_B1-K1-2_3v1.

Kerntaak 1

K1W1 - Planning

Nieuw

1. De uitgangspunten, technische en functionele eisen en wensen zijn bepaald en gedocumenteerd.
   • De eisen zijn zodanig concreet beschreven dat een objectieve buitenstaander kan bepalen wanneer het project klaar is.
2. Op basis van de functionaliteit is een complete en realistische planning gemaakt.
   • In de planning komen de user stories terug.
   • De planning is realistisch volgens professionele inschatting.
   • Planning is consistent (ruim of krap) en de tijdsaanduiding is eenduidig (dus bijvoorbeeld in uren).
   • De taken zijn voldoende fijnmazig. Richtlijn: in uren of dagdelen.
3. De gestelde doelen en planning zijn bewaakt.

Oud

1. De uitgangspunten zijn juist verwerkt (Definition of done) en de eisen en wensen zijn verwerkt in de user stories.
   
2. De user stories voldoen aan de criteria (wie, wat, waarom en realistisch).
   
3. Op basis van de user stories is een complete en realistische planning gemaakt.
4. De voortgang is bewaakt en de juiste keuzes/afwegingen zijn gemaakt op basis van prioriteiten.

Beoordeling

1. Opdracht, doelen en planning zijn afgestemd
2. Voorgang is bewaakt
3. Reageert op afwijkingen

Verandering

1. User story's zijn niet meer verplicht
2. Beoordeling anders; is minder concreet en punt 'reageert op afwijking' is erbij.

K1W2 - Ontwerp

Nieuw

1. De eisen en wensen zijn vertaald naar een passend, eenduidig en volledig ontwerp.
2. Er is gebruik gemaakt van relevante of toepasselijke schematechnieken (bijv. activiteitendiagram, klassendiagram, ERD, use case diagram).
   • Minimaal 2 goede schematechnieken die inhoudelijk voor het grootste gedeelte (80%) inhoudelijk juist zijn.
3. De gemaakte keuzes in het ontwerp zijn onderbouwd met steekhoudende argumenten, waarbij rekening is gehouden met haalbaarheid, privacy en security.
   • Er wordt uitgelegd waarom keuzes zijn gemaakt en twee van de vier onderwerpen (ethiek, privacy, security en useability) worden daarbij besproken.

Oud

1. De user stories zijn vertaald naar een passend, eenduidig en volledig ontwerp (sluit aan op wensen en eisen).
   
2. Er is gebruik gemaakt van relevante of toepasselijke schematechnieken (bijv. activiteitendiagram, klassendiagram, ERD, use case diagram).
   
3. De gemaakte keuzes in het ontwerp zijn onderbouwd met steekhoudende argumenten, waarbij rekening is gehouden met bijv. ethiek, privacy en security.

Beoordeling

1. Eisen, wensen zijn eenduidig vastgelegd
   
2. Schematechnieken
3. Onderbouwing

Verandering

1. User story's zijn niet meer verplicht
2. Beoordeling is ongewijzigd.

K1W3 - Realisatie

Nieuw

1. Er is voldoende inhoud van de functionaliteit gerealiseerd binnen de gestelde/geplande tijd.
   
   • Er is minimaal 40 uur (netto) aan de realisatie gewerkt.
2. De opgeleverde functionaliteiten voldoen aan de eisen en wensen.
   • De user stories en eisen en wensen zijn voor minimaal 80% gerealiseerd. Eventuele afwijkingen zijn gedocumenteerd in de planningsvoortgang.
3. De kwaliteit van de code is goed.
   • Code bevat eigen toegevoegd commentaar.
   • Identation (inspringen) van code is correct.
   • Naamgeving van variabelen, objecten en functies is consistent.
4. Versiebeheer is effectief toegepast.
   • Er zijn ten minste 3 oude versies van het project aanwezig. Deze versies moeten de geschiedenis van de code laten zien. (dus 3 versies die allemaal van één dag zijn is niet goed).

Oud

1. Er is voldoende inhoud van de user stories gerealiseerd binnen de gestelde/geplande tijd.
2. De opgeleverde functionaliteiten voldoen aan de eisen en wensen.
3. De kwaliteit van de code is goed. Dit uit zich onder andere in: structuur van de code, validatie, efficiëntie, foutafhandeling en terugkoppeling, security (veilig programmeren). 
4. De code is opgesteld volgens code conventions.
5. De code is verzorgd, leesbaar, gestructureerd en voorzien van zinvol commentaar.
6. Versiebeheer is effectief toegepast.

Beoordeling

1. Gerealiseerde functionaliteiten
   
2. Kwaliteit (voldoet aan eisen en wensen)
   
3. Kwaliteit
4. Versiebeheer

Verandering

1. User story's zijn niet meer verplicht.
2. Kwaliteit van de code is één punt (geen code conventies meer).
   
3. Beoordeling op minderpunten omdat kwaliteit v. code en code conventies eruit, dus meer nadruk op functionaliteiten.
4. Omdat er meer naar de opgeleverde code wordt gekeken is dit lastiger te halen met weinig opgeleverde functionaliteit (WP sites zijn nog lastiger).

K1W4 - Testen

Nieuw

1. De testcases in het testplan sluiten aan op de functionaliteit en bevatten alle scenario's.
   • Er zijn minimaal 5 scenario's nauwkeurig beschreven. Per test zijn 3 variaties beschreven. Er worden dus minimaal 15 testen uitgevoerd.
2. De kandidaat heeft voor alle toegewezen of geplande functionaliteit testscenario's of testcases gemaakt.
   • Alle functionaliteiten worden door de testen 'geraakt'.
3. De kandidaat voert de testactiviteiten correct en volgens het testplan uit. 
4. Het testrapport bevat testresultaten van alle functionaliteiten. Alle resultaten worden voorzien van de juiste conclusies.
   

Oud

1. De testcases in het testplan sluiten aan op de user stories en bevatten alle scenario's.
2. De stappen, het gewenste resultaat en testdata zijn benoemd. Niet alleen het hoofdscenario, maar ook alternatieve scenario's. 
3. De stappen, het gewenste resultaat en testdata zijn benoemd. Niet alleen het hoofdscenario, maar ook alternatieve scenario's. 

Beoordeling

1. Er moet een testvorm of methodiek zijn gekozen.
   
2. Alles is getest
   
3. Resultaten zijn beschreven
   
4. Er is een testplan en ene testrapport, die aan dezelfde eisen voldoen...?
   

Verandering

1. User stories zijn er uit.
2. Testplan moet alles omvatten.
3. Uitvoering is apart punt (weegt zwaarder).
4. Conclusies zijn niet meer verplicht.

K1W5 - Verbeteren

Nieuw

1. Analyseert systematisch alle beschikbare informatiebronnen voor mogelijke aanpassingen aan de software.
2. Interpreteert en vertaalt wensen, reacties, testresultaten en/of meldingen naar realiseerbare verbetervoorstellen.
3. Stelt vast welke werkzaamheden benodigd zijn, evenals een haalbare planning. 

Oud

1. De juiste verbetervoorstellen zijn gedaan vanuit het testen.
2. De juiste verbetervoorstellen zijn gedaan vanuit de oplevering.
3. De juiste verbetervoorstellen zijn gedaan vanuit de reflectie.

Beoordeling

1. Analyse voor aanpassingen door gebruik te maken van bronnen.
   
2. Verbetervoorstellen
   
3. Planning

Verandering

1. Onderscheid tussen de bronnen minder relevant.
2. Verbetervoorstellen dienen realiseerbaar te zijn.
3. Planning voor verbetervoorstellen.
4. Er worden bronnen geraadpleegd om tot goede verbetervoorstellen te komen.

Kerntaak 2

K2W1 - Overleggen

Nieuw

1. De kandidaat neemt actief deel aan het overleg waarbij relevante onderwerpen worden ingebracht en de juiste vragen worden gesteld. 
2. De kandidaat stemt regelmatig en tijdig af met projectteamleden en opdrachtgever over de voortgang en eventuele knelpunten.
3. De gemaakte afspraken zijn eenduidig vastgelegd.
4. De kandidaat houdt zich aan gemaakte afspraken.
   

Oud

1. De kandidaat neemt actief deel waarbij relevante onderwerpen worden ingebracht en de juiste vragen worden gesteld.
2. De kandidaat stemt regelmatig en tijdig af met projectteamleden en opdrachtgever over de voortgang en eventuele knelpunten.
3. De gemaakte afspraken zijn eenduidig vastgelegd.
4. De kandidaat houdt zich aan gemaakte afspraken.

Beoordeling

1. 
   

Verandering

Geen.

K2W2 - Presenteren

Nieuw

1. De kandidaat legt de functionaliteiten uit met een goed opgebouwd en met argumenten onderbouwd verhaal.
2. De kandidaat stemt de stijl van communiceren en de presentatiemiddelen af op de toehoorders.
3. De kandidaat beantwoordt vragen met steekhoudende argumenten. 

Oud

1. De kandidaat presenteert een overtuigend, duidelijk, beargumenteerd verhaal, afgestemd op de doelgroep.
2. De kandidaat stelt gerichte vragen om te controleren of de betrokkenen goed geïnformeerd zijn over het opgeleverde werk.
3. De kandidaat reageert adequaat op feedback.

Beoordeling

Verandering

1. Presentatie gaat over project.
2. Geen verplichte vragen meer tijdens presentatie.
3. Geen beoordeling op de reactie op feedback.
4. Vragen worden beantwoord én onderbouwd.

K2W3 - Reflectie

Nieuw

1. De kandidaat benoemt zowel positieve- als verbeterpunten van het proces van zowel eigen als teamprestaties.
2. De kandidaat reageert actief op ontvangen feedback

Oud

1. De kandidaat benoemt  zowel positieve als verbeterpunten van het proces van zowel eigen als teamprestaties.
2. De kandidaat reageert adequaat op de ontvangen feedback.
3. De kandidaat heeft een proactieve houding tijdens reflectiemeetings.

Beoordeling

Verandering

1. Meetings zijn niet meer van toepassing.

--

Onderlegger / Checklist C24 (Crebo 25998)

Kerntaak 1

B1-K1-W1

Stemt opdracht af, plant werkzaamheden en bewaakt de voortgang

Rubrics

1. De opdracht, doelen en planning zijn afgestemd.
2. De kandidaat houdt bij welke werkzaamheden zijn uitgevoerd, welke nog uitgevoerd moeten worden en gaat na of de planning in gevaar komt.
3. De kandidaat signaleert afwijkingen in de doelen en planning, meldt dit en zoekt (in overleg) naar een (tussen)oplossing.

Onderlegger

() nummers verwijzen naar rubics

1. Opdracht is beschreven (1).
2. Doelen zijn beschreven (1).
3. Planning is beschreven (1, 2).
4. Indien er een opdrachtgever is, dan is er ook afgestemd (1).
5. Projectvoortgang is bewaakt (2, 3)
6. Project bijsturing is uitgevoerd en beschreven (3)

Checklist

(nummers verzijzen naar onderlegger en rubic)

• Is er beschreven wat er gemaakt moet worden; hoe ziet het eindproduct eruit? (O1, R1)
• Is er beschreven voor wie het is bedoeld; wie gaan ermee werken? (O1, R1)
• Welke functionaliteiten moeten minimaal werken? (O1, R1)
• Zijn alle gewenste functionaliteiten beschreven? (O1, R1)
• Welke technische uitgangspunten zijn er (techniek, taal, frameworks)? (O1, R1)
• Welk doel dient het project? Welk probleem wordt opgelost en hoe wordt gemeten of dat gelukt is? (O2, R1)
• Bevat de planning duidelijke taakbeschrijvingen, plus per taak een geschatte tijd, deadline, verantwoordelijke en resultaatbeschrijving? (O3, R1)
  • Taken zijn nooit groter dan 1 dag (8 uur). (O3, R1)
  • Er is voor minimaal 40 uur programmeerwerk gepland (per persoon).
• Is van elke taak bijgehouden wanneer deze is begonnen, door wie en wanneer deze klaar was? (O5, R2)
• Welke wijzigingen zijn er in de planning gemaakt tijdens de uitvoering en zijn deze onderbouwd? (O5, R2)
  • Waarom is het gewijzigd? (O5, R2)
  • Wat waren de opties en waarom is deze optie gekozen? (O5, R2)
  • Is er overleg geweest en zo ja, met wie? (O4, R3)

B1-K1-W2

Maakt een technisch ontwerp voor software

Rubrics

1. De eisen, wensen en technische randvoorwaarden zijn vertaald naar een passend, eenduidig en volledig (deel)ontwerp.
2. Er is gebruikt gemaakt van relevante of toepasselijke schematechnieken (bijv. activiteitendiagram, klassendiagram, ERD, use case diagram).
3. De gemaakte keuzes in het ontwerp zijn onderbouwd met steekhoudende argumenten die passen bij de praktijkrichting.

Onderlegger

() nummers verwijzen naar rubics

1. Alle functionalieiten zijn beschreven (1)
2. Alle technische randvoorwaarden zijn beschreven (1)
3. Het ontwerp bevat passende en relevante schema’s (zoals ERD, activiteitendiagram, use case, flowdiagram) (2)
   
4. Alle ontwerpkeuzes zijn onderbouwd met (functionele of technische) argumenten (3).
   

Checklist

(nummers verwijzen naar onderlegger en rubric)

• Zijn alle functionele eisen en wensen compleet beschreven? (O1, R1)
• Zijn alle technische randvoorwaarden volledig en correct vastgelegd (bijv. taal, framework, devices, API’s, database)? (O2, R1)
• Is per eis of wens aantoonbaar aangegeven hoe deze is vertaald naar het ontwerp? (O1, R1)
• Zijn alle schermen/componenten/modules uitgewerkt in tekst, schets, mockup of wireframe? (O1, R1)
• Zijn de datastromen, interacties en relaties tussen onderdelen duidelijk beschreven (flowchart)? (O1, R1)
• Bevat het ontwerp minimaal 3 relevante en juiste schema’s (ERD, activiteitendiagram, use case, flowdiagram)? (O3, R2)
  
• Zijn de gebruikte benamingen consistent tussen schema’s, tekst, datamodel en ontwerp? (O1, R1)
• Is bij elke ontwerpkeuze een inhoudelijke en logische motivatie gegeven (functioneel of technisch onderbouwd)? (O4, R3)
• Zijn alternatieve ontwerpopties overwogen en is beschreven waarom een bepaalde keuze is gemaakt? (O4, R3)
• Is het ontwerp voldoende gedetailleerd zodat een andere ontwikkelaar het systeem kan bouwen zonder extra uitleg? (O1, R1/R2)

B1-K1-W3

Realiseert (onderdelen van) software 

Rubrics

1. Er is voldoende inhoud van de functionaliteiten gerealiseerd binnen de gestelde/geplande tijd.
2. De opgeleverde functionaliteiten voldoen aan de eisen en wensen.
3. De kwaliteit van de code is goed.
4. Versiebeheer is effectief toegepast.

Onderlegger

() nummers verwijzen naar rubics

1. De geplande functionaliteiten zijn binnen de afgesproken tijd gerealiseerd of er is duidelijk verantwoord waarom dit niet volledig gelukt is (1).
2. Er wordt ten minste 40 uur verantwoord voor dit werkproces. (1)
3. De gerealiseerde functionaliteiten werken volgens de vooraf opgestelde eisen, wensen en acceptatiecriteria (2).
4. Edge cases, foutafhandeling en uitzonderingssituaties zijn functioneel juist afgehandeld (2).
5. De code heeft een duidelijke structuur (3)
6. De code volgt relevante best practices (bijv. DRY, SRP, scheiding van concerns, herbruikbare functies, valide input-checks) (3).
7. De opmaak van de code is netjes (inspringen). (3)
8. Er is voldoende zinvol commentaar toegevoegd. (3)
9. De naamgeving van variabelen, functies, methods en classes is consistent en duidelijk (3)
   
10. De kandidaat heeft commit-historie die laat zien dat er regelmatig, logisch en stapsgewijs gewerkt is (4).
11. Commits bevatten betekenisvolle commit messages die duidelijk maken wát er is veranderd en waarom (4).
12. De kandidaat gebruikt branches, merges en/of pull requests op een manier die past bij de omvang van het project (4).

Checklist

(nummers verwijzen naar onderlegger en rubric)

• Zijn de geplande functionaliteiten gerealiseerd binnen de afgesproken tijd, of is duidelijk verantwoord waarom dit niet gelukt is? (O1, R1)
• Is er minimaal 40 uur aan werkzaamheden verantwoord binnen dit werkproces? (O2, R1)
• Werken alle opgeleverde functionaliteiten volgens de vooraf opgestelde eisen en wensen? (O3, R2)
  
• Zijn edge cases, foutafhandeling en uitzonderingssituaties correct en functioneel afgehandeld? (O4, R2)
• Is de code logisch gestructureerd en duidelijk opgezet waarbij de code is opgedeeld in een duidelijke directory-structuur en is de code zinvol is opgedeeld in bestanden? (O5, R3)
• Volgt de code relevante best practices (DRY, SRP, scheiding van concerns, herbruikbare functies, inputvalidatie)? (O6, R3)
• Is de code netjes opgemaakt, inclusief correct inspringen? (O7, R3)
• Is er voldoende zinvol commentaar toegevoegd waar dat nodig is? (O8, R3)
• Zijn namen van o.m. variabelen, functies, methods en classes consistent en duidelijk gekozen? (O9, R3)
• Laat de commit-historie zien dat er regelmatig, logisch en stapsgewijs gewerkt is? (O10, R4)
• Bevatten commits betekenisvolle commit messages die duidelijk maken wát en waarom iets is aangepast? (O11, R4)
  

Extra toeliching

DRY (Don’t Repeat Yourself)
Voorkomt dubbele code. Wanneer dezelfde logica op meerdere plekken staat, breng je het onder in één gedeelde functie of module. Dit maakt onderhoud eenvoudiger en vermindert fouten.

Herbruikbare functies
Functies die zo zijn geschreven dat ze op meerdere plekken en in verschillende situaties toepasbaar zijn. Ze zijn klein, duidelijk gedefinieerd en afhankelijk van zo min mogelijk specifieke context. Deze functies zijn de bouwblokken van de code.

SRP (Single Responsibility Principle)
Elke functie, klasse of module moet precies één duidelijke taak hebben. Dit maakt code begrijpelijker, testbaarder en minder foutgevoelig.

Scheiding van concerns
Splits verschillende verantwoordelijkheden in aparte lagen of bestanden. Bijvoorbeeld: HTML voor structuur, CSS voor vormgeving, JavaScript/PHP voor logica. Dit verhoogt overzicht en onderhoudbaarheid.

Inputvalidatie
Controleer alle gegevens die van gebruikers, API’s of formulieren binnenkomen. Je controleert of ze aanwezig, geldig en veilig zijn voordat je ze gebruikt, om fouten, beveiligingslekken en onverwacht gedrag te voorkomen.

Abstractie
Abstractie verbergt details, waardoor functies herbruikbaar worden en duplicatie verdwijnt.

B1-K1-W4

Test software

Rubrics

1. De kandidaat heeft passende testvormen en testmethodieken gekozen.
2. De kandidaat heeft voor alle toegewezen of geplande functionaliteiten testscenario’s of testcases gemaakt.
3. Het testrapport bevat testresultaten van alle functionaliteiten. Alle resultaten worden voorzien van de juiste conclusies.

Onderlegger

() nummers verwijzen naar rubics

1. Je voert ten minste één integratietest uit. (1)
2. Er is minimaal één geautomatiseerde test uitgevoerd met een geschikte tool (bijv. Selenium, Playwright of een alternatieve testtool). (1)
   
3. Er is risk-based getest: op basis van een risicoanalyse zijn de belangrijkste tests als eerste uitgevoerd. (1)
4. Voor alle toegewezen of geplande functionaliteiten zijn testscenario’s of testcases opgesteld met duidelijke input, stappen en verwachte output. (2)
5. De testcases bevatten zowel happy flows, edge cases als foutgevallen. (2)
6. Je bepaalt waar performance een risico kan vormen en voert indien relevant performance-gerelateerde tests uit. (1/2 – optioneel afhankelijk van opdracht)
7. Testscenario’s zijn volledig en zo beschreven dat een andere tester ze onafhankelijk kan uitvoeren. (2)
8. Het testrapport bevat de resultaten van alle uitgevoerde tests, inclusief datum, testomgeving en eventuele bijzonderheden. (3)
9. Bij elk testresultaat is duidelijk aangegeven of de test geslaagd is, inclusief een toelichting bij afwijkingen. (3)
10. Er zijn juiste en logische conclusies getrokken op basis van de testresultaten, inclusief aanbevelingen of vervolgstappen. (3)

Checklist

(nummers verwijzen naar onderlegger en rubric)

• Is er ten minste één integratietest uitgevoerd? (O1, R1)
• Is er minimaal één geautomatiseerde test uitgevoerd met een geschikte tool (bijv. Selenium, Playwright)? (O2, R1)
  
• Is er risk-based getest op basis van een vooraf uitgevoerde risicoanalyse? (O3, R1)
• Zijn er voor alle  functionaliteiten testscenario’s of testcases opgesteld? (O4, R2)
• Bevatten de testcases happy flows, edge cases en foutgevallen? (O5, R2)
• Zijn performance-gerelateerde tests uitgevoerd? (O6, R1/R2) - moet dit?
• Zijn de testscenario’s volledig en zo beschreven dat een andere tester ze onafhankelijk kan uitvoeren? (O7, R2)
• Bevat het testrapport resultaten van alle uitgevoerde tests, inclusief datum, omgeving en bijzonderheden? (O8, R3)
• Is bij elk testresultaat duidelijk aangegeven of de test geslaagd is en is er een toelichting bij afwijkingen? (O9, R3)
• Zijn er logische en correcte conclusies getrokken op basis van alle testresultaten, inclusief aanbevelingen of vervolgacties? (O10, R3)

B1-K1-W5

Doet verbetervoorstellen voor de software 

Rubrics

De kandidaat analyseert systematisch alle beschikbare informatiebronnen voor mogelijke aanpassingen aan de software.

De kandidaat interpreteert en vertaalt wensen, reacties, testresultaten en/of meldingen naar realiseerbare verbetervoorstellen.

De kandidaat stelt vast welke werkzaamheden benodigd zijn, evenals een haalbare planning.

Onderlegger

() nummers verwijzen naar rubics

1. Alle relevante informatiebronnen zijn systematisch verzameld en geanalyseerd (bijv. testresultaten, foutmeldingen, logs, gebruikersfeedback, codekwaliteit, performancegegevens). (1)
2. De kandidaat toont aan dat de informatieobjectief en volledig is geïnterpreteerd (bijv. clustering van problemen, oorzaakanalyse, categorisatie). (1)
3. Er is een duidelijke probleemanalyse gemaakt, inclusief onderliggende oorzaken (root cause analysis). (1)
4. Wensen, reacties, testresultaten of meldingen zijn vertaald naar één of meerdere concrete, haalbare verbetervoorstellen. (2)
5. De verbetervoorstellen zijn functioneel en technisch onderbouwd, inclusief motivatie waarom deze verbeteringen waardevol zijn. (2)
6. Elk verbetervoorstel bevat een duidelijke beschrijving van de impact en gevolgen voor gebruikers, data, functionaliteit of onderhoud. (2)
7. Er is onderscheid gemaakt tussen kleine verbeteringen en grotere wijzigingen (bijv. quick wins vs. major improvements). (2)
8. Er is per verbetervoorstel vastgesteld welke werkzaamheden nodig zijn (bijv. analyse, ontwerp, codewijziging, testen, documentatie). (3)
9. De benodigde tijd, afhankelijkheden en risico’s zijn ingeschat en beschreven. (3)
10. Er is een haalbare planning opgesteld voor de realisatie van de verbeteringen (bijv. volgorde, prioriteit, tijdsinschatting, sprintplanning). (3)

Checklist

(nummers verwijzen naar onderlegger en rubric)

1. Zijn alle relevante informatiebronnen verzameld en systematisch geanalyseerd (zoals logs, testresultaten, foutmeldingen, gebruikersfeedback)? (O1, R1)
2. Is de verzamelde informatie objectief en volledig geïnterpreteerd (bijv. clustering, patronen, oorzaken)? (O2, R1)
3. Is er een duidelijke probleemanalyse gemaakt, inclusief onderliggende oorzaken (root cause analysis)? (O3, R1)
4. Zijn wensen, reacties, testresultaten of meldingen vertaald naar concrete, haalbare verbetervoorstellen? (O4, R2)
5. Zijn de verbetervoorstellen functioneel en technisch onderbouwd? (O5, R2)
6. Bevat elk verbetervoorstel een duidelijke beschrijving van de impact (gebruikers, data, functionaliteit, onderhoud)? (O6, R2)
7. Is onderscheid gemaakt tussen kleine verbeteringen (quick wins) en grotere wijzigingen? (O7, R2)
8. Is per verbetervoorstel vastgesteld welke werkzaamheden nodig zijn (ontwerp, code, testen, documentatie)? (O8, R3)
9. Zijn tijdsinschatting, afhankelijkheden en risico’s beschreven? (O9, R3)
10. Is een haalbare planning opgesteld voor de uitvoering van de verbeteringen (volgorde, prioriteit, tijdsinschatting)? (O10, R3)

Onderlegger / Checklist C24 (Crebo 25998) met gewichten

Kerntaak 1

B1-K1-W1 - Stemt opdracht af, plant werkzaamheden en bewaakt de voortgang

Rubrics

1. De opdracht, doelen en planning zijn afgestemd. (Weight: 33%)
2. De kandidaat houdt bij welke werkzaamheden zijn uitgevoerd, welke nog uitgevoerd moeten worden en gaat na of de planning in gevaar komt. (Weight: 33%)
3. De kandidaat signaleert afwijkingen in de doelen en planning, meldt dit en zoekt (in overleg) naar een (tussen)oplossing. (Weight: 34%)

Onderlegger

() nummers verwijzen naar rubics

1. Opdracht is beschreven (1). (Weight: 20%)
2. Doelen zijn beschreven (1). (Weight: 20%)
3. Planning is beschreven (1, 2). (Weight: 20%)
4. Indien er een opdrachtgever is, dan is er ook afgestemd (1). (Weight: 10%)
5. Projectvoortgang is bewaakt (2, 3). (Weight: 15%)
6. Project bijsturing is uitgevoerd en beschreven (3). (Weight: 15%)

Checklist

(nummers verzijzen naar onderlegger en rubic)

• Is er beschreven wat er gemaakt moet worden; hoe ziet het eindproduct eruit? (O1, R1) (Weight: 12%)
• Is er beschreven voor wie het is bedoeld; wie gaan ermee werken? (O1, R1) (Weight: 8%)
• Welke functionaliteiten moeten minimaal werken? (O1, R1) (Weight: 10%)
• Zijn alle gewenste functionaliteiten beschreven? (O1, R1) (Weight: 10%)
• Welke technische uitgangspunten zijn er (techniek, taal, frameworks)? (O1, R1) (Weight: 10%)
• Welk doel dient het project? Welk probleem wordt opgelost en hoe wordt gemeten of dat gelukt is? (O2, R1) (Weight: 15%)
• Bevat de planning duidelijke taakbeschrijvingen, plus per taak een geschatte tijd, deadline, verantwoordelijke en resultaatbeschrijving? (O3, R1)
  • Taken zijn nooit groter dan 1 dag (8 uur). (O3, R1) (Weight: 5%)
  • Er is voor minimaal 40 uur programmeerwerk gepland (per persoon). (Weight: 5%)
• Is van elke taak bijgehouden wanneer deze is begonnen, door wie en wanneer deze klaar was? (O5, R2) (Weight: 10%)
• Welke wijzigingen zijn er in de planning gemaakt tijdens de uitvoering en zijn deze onderbouwd? (O5, R2)
  • Waarom is het gewijzigd? (O5, R2) (Weight: 3%)
  • Wat waren de opties en waarom is deze optie gekozen? (O5, R2) (Weight: 3%)
  • Is er overleg geweest en zo ja, met wie? (O4, R3) (Weight: 4%)

B1-K1-W2 - Maakt een technisch ontwerp voor software

Rubrics

1. De eisen, wensen en technische randvoorwaarden zijn vertaald naar een passend, eenduidig en volledig (deel)ontwerp. (Weight: 40%)
2. Er is gebruikt gemaakt van relevante of toepasselijke schematechnieken (bijv. activiteitendiagram, klassendiagram, ERD, use case diagram). (Weight: 30%)
3. De gemaakte keuzes in het ontwerp zijn onderbouwd met steekhoudende argumenten die passen bij de praktijkrichting. (Weight: 30%)

Onderlegger

() nummers verwijzen naar rubics

1. Alle functionalieiten zijn beschreven (1) (Weight: 30%)
2. Alle technische randvoorwaarden zijn beschreven (1) (Weight: 25%)
3. Het ontwerp bevat passende en relevante schema's (zoals ERD, activiteitendiagram, use case, flowdiagram) (2)
   (Weight: 25%)
4. Alle ontwerpkeuzes zijn onderbouwd met (functionele of technische) argumenten (3).
   (Weight: 20%)

Checklist

(nummers verwijzen naar onderlegger en rubric)

• Zijn alle functionele eisen en wensen compleet beschreven? (O1, R1) (Weight: 12%)
• Zijn alle technische randvoorwaarden volledig en correct vastgelegd (bijv. taal, framework, devices, API's, database)? (O2, R1) (Weight: 10%)
• Is per eis of wens aantoonbaar aangegeven hoe deze is vertaald naar het ontwerp? (O1, R1) (Weight: 10%)
• Zijn alle schermen/componenten/modules uitgewerkt in tekst, schets, mockup of wireframe? (O1, R1) (Weight: 10%)
• Zijn de datastromen, interacties en relaties tussen onderdelen duidelijk beschreven (flowchart)? (O1, R1) (Weight: 8%)
• Bevat het ontwerp minimaal 3 relevante en juiste schema's (ERD, activiteitendiagram, use case, flowdiagram)? (O3, R2)
  (Weight: 15%)
• Zijn de gebruikte benamingen consistent tussen schema's, tekst, datamodel en ontwerp? (O1, R1) (Weight: 5%)
• Is bij elke ontwerpkeuze een inhoudelijke en logische motivatie gegeven (functioneel of technisch onderbouwd)? (O4, R3) (Weight: 10%)
• Zijn alternatieve ontwerpopties overwogen en is beschreven waarom een bepaalde keuze is gemaakt? (O4, R3) (Weight: 10%)
• Is het ontwerp voldoende gedetailleerd zodat een andere ontwikkelaar het systeem kan bouwen zonder extra uitleg? (O1, R1/R2) (Weight: 10%)

B1-K1-W3 - Realiseert (onderdelen van) software

Rubrics

1. Er is voldoende inhoud van de functionaliteiten gerealiseerd binnen de gestelde/geplande tijd. (Weight: 25%)
2. De opgeleverde functionaliteiten voldoen aan de eisen en wensen. (Weight: 25%)
3. De kwaliteit van de code is goed. (Weight: 25%)
4. Versiebeheer is effectief toegepast. (Weight: 25%)

Onderlegger

() nummers verwijzen naar rubics

1. De geplande functionaliteiten zijn binnen de afgesproken tijd gerealiseerd of er is duidelijk verantwoord waarom dit niet volledig gelukt is (1). (Weight: 15%)
2. Er wordt ten minste 40 uur verantwoord voor dit werkproces. (1) (Weight: 10%)
3. De gerealiseerde functionaliteiten werken volgens de vooraf opgestelde eisen, wensen en acceptatiecriteria (2). (Weight: 15%)
4. Edge cases, foutafhandeling en uitzonderingssituaties zijn functioneel juist afgehandeld (2). (Weight: 10%)
5. De code heeft een duidelijke structuur (3) (Weight: 10%)
6. De code volgt relevante best practices (bijv. DRY, SRP, scheiding van concerns, herbruikbare functies, valide input-checks) (3). (Weight: 10%)
7. De opmaak van de code is netjes (inspringen). (3) (Weight: 5%)
8. Er is voldoende zinvol commentaar toegevoegd. (3) (Weight: 5%)
9. De naamgeving van variabelen, functies, methods en classes is consistent en duidelijk (3)
   (Weight: 5%)
10. De kandidaat heeft commit-historie die laat zien dat er regelmatig, logisch en stapsgewijs gewerkt is (4). (Weight: 5%)
11. Commits bevatten betekenisvolle commit messages die duidelijk maken wát er is veranderd en waarom (4). (Weight: 5%)
12. De kandidaat gebruikt branches, merges en/of pull requests op een manier die past bij de omvang van het project (4). (Weight: 5%)

Checklist

(nummers verwijzen naar onderlegger en rubric)

• Zijn de geplande functionaliteiten gerealiseerd binnen de afgesproken tijd, of is duidelijk verantwoord waarom dit niet gelukt is? (O1, R1) (Weight: 10%)
• Is er minimaal 40 uur aan werkzaamheden verantwoord binnen dit werkproces? (O2, R1) (Weight: 5%)
• Werken alle opgeleverde functionaliteiten volgens de vooraf opgestelde eisen en wensen? (O3, R2)
  (Weight: 15%)
• Zijn edge cases, foutafhandeling en uitzonderingssituaties correct en functioneel afgehandeld? (O4, R2) (Weight: 10%)
• Is de code logisch gestructureerd en duidelijk opgezet waarbij de code is opgedeeld in een duidelijke directory-structuur en is de code zinvol is opgedeeld in bestanden? (O5, R3) (Weight: 10%)
• Volgt de code relevante best practices (DRY, SRP, scheiding van concerns, herbruikbare functies, inputvalidatie)? (O6, R3) (Weight: 10%)
• Is de code netjes opgemaakt, inclusief correct inspringen? (O7, R3) (Weight: 5%)
• Is er voldoende zinvol commentaar toegevoegd waar dat nodig is? (O8, R3) (Weight: 5%)
• Zijn namen van o.m. variabelen, functies, methods en classes consistent en duidelijk gekozen? (O9, R3) (Weight: 5%)
• Laat de commit-historie zien dat er regelmatig, logisch en stapsgewijs gewerkt is? (O10, R4) (Weight: 10%)
• Bevatten commits betekenisvolle commit messages die duidelijk maken wát en waarom iets is aangepast? (O11, R4) (Weight: 10%)
  

B1-K1-W4 - Test software

Rubrics

1. De kandidaat heeft passende testvormen en testmethodieken gekozen. (Weight: 35%)
2. De kandidaat heeft voor alle toegewezen of geplande functionaliteiten testscenario's of testcases gemaakt. (Weight: 35%)
3. Het testrapport bevat testresultaten van alle functionaliteiten. Alle resultaten worden voorzien van de juiste conclusies. (Weight: 30%)

Onderlegger

() nummers verwijzen naar rubics

1. Je voert ten minste één integratietest uit. (1) (Weight: 15%)
2. Er is minimaal één geautomatiseerde test uitgevoerd met een geschikte tool (bijv. Selenium, Playwright of een alternatieve testtool). (1)
   (Weight: 15%)
3. Er is risk-based getest: op basis van een risicoanalyse zijn de belangrijkste tests als eerste uitgevoerd. (1) (Weight: 10%)
4. Voor alle toegewezen of geplande functionaliteiten zijn testscenario's of testcases opgesteld met duidelijke input, stappen en verwachte output. (2) (Weight: 15%)
5. De testcases bevatten zowel happy flows, edge cases als foutgevallen. (2) (Weight: 10%)
6. Je bepaalt waar performance een risico kan vormen en voert indien relevant performance-gerelateerde tests uit. (1/2 – optioneel afhankelijk van opdracht) (Weight: 5%)
7. Testscenario's zijn volledig en zo beschreven dat een andere tester ze onafhankelijk kan uitvoeren. (2) (Weight: 10%)
8. Het testrapport bevat de resultaten van alle uitgevoerde tests, inclusief datum, testomgeving en eventuele bijzonderheden. (3) (Weight: 10%)
9. Bij elk testresultaat is duidelijk aangegeven of de test geslaagd is, inclusief een toelichting bij afwijkingen. (3) (Weight: 5%)
10. Er zijn juiste en logische conclusies getrokken op basis van de testresultaten, inclusief aanbevelingen of vervolgstappen. (3) (Weight: 5%)

Checklist

(nummers verwijzen naar onderlegger en rubric)

• Is er ten minste één integratietest uitgevoerd? (O1, R1) (Weight: 15%)
• Is er minimaal één geautomatiseerde test uitgevoerd met een geschikte tool (bijv. Selenium, Playwright)? (O2, R1)
  (Weight: 15%)
• Is er risk-based getest op basis van een vooraf uitgevoerde risicoanalyse? (O3, R1) (Weight: 10%)
• Zijn er voor alle  functionaliteiten testscenario's of testcases opgesteld? (O4, R2) (Weight: 15%)
• Bevatten de testcases happy flows, edge cases en foutgevallen? (O5, R2) (Weight: 10%)
• Zijn performance-gerelateerde tests uitgevoerd? (O6, R1/R2) - moet dit? (Weight: 5%)
• Zijn de testscenario's volledig en zo beschreven dat een andere tester ze onafhankelijk kan uitvoeren? (O7, R2) (Weight: 10%)
• Bevat het testrapport resultaten van alle uitgevoerde tests, inclusief datum, omgeving en bijzonderheden? (O8, R3) (Weight: 10%)
• Is bij elk testresultaat duidelijk aangegeven of de test geslaagd is en is er een toelichting bij afwijkingen? (O9, R3) (Weight: 5%)
• Zijn er logische en correcte conclusies getrokken op basis van alle testresultaten, inclusief aanbevelingen of vervolgacties? (O10, R3) (Weight: 5%)

B1-K1-W5 - Doet verbetervoorstellen voor de software

Rubrics

De kandidaat analyseert systematisch alle beschikbare informatiebronnen voor mogelijke aanpassingen aan de software. (Weight: 35%)

De kandidaat interpreteert en vertaalt wensen, reacties, testresultaten en/of meldingen naar realiseerbare verbetervoorstellen. (Weight: 35%)

De kandidaat stelt vast welke werkzaamheden benodigd zijn, evenals een haalbare planning. (Weight: 30%)

Onderlegger

() nummers verwijzen naar rubics

1. Alle relevante informatiebronnen zijn systematisch verzameld en geanalyseerd (bijv. testresultaten, foutmeldingen, logs, gebruikersfeedback, codekwaliteit, performancegegevens). (1) (Weight: 15%)
2. De kandidaat toont aan dat de informatieobjectief en volledig is geïnterpreteerd (bijv. clustering van problemen, oorzaakanalyse, categorisatie). (1) (Weight: 10%)
3. Er is een duidelijke probleemanalyse gemaakt, inclusief onderliggende oorzaken (root cause analysis). (1) (Weight: 10%)
4. Wensen, reacties, testresultaten of meldingen zijn vertaald naar één of meerdere concrete, haalbare verbetervoorstellen. (2) (Weight: 15%)
5. De verbetervoorstellen zijn functioneel en technisch onderbouwd, inclusief motivatie waarom deze verbeteringen waardevol zijn. (2) (Weight: 10%)
6. Elk verbetervoorstel bevat een duidelijke beschrijving van de impact en gevolgen voor gebruikers, data, functionaliteit of onderhoud. (2) (Weight: 10%)
7. Er is onderscheid gemaakt tussen kleine verbeteringen en grotere wijzigingen (bijv. quick wins vs. major improvements). (2) (Weight: 5%)
8. Er is per verbetervoorstel vastgesteld welke werkzaamheden nodig zijn (bijv. analyse, ontwerp, codewijziging, testen, documentatie). (3) (Weight: 10%)
9. De benodigde tijd, afhankelijkheden en risico's zijn ingeschat en beschreven. (3) (Weight: 5%)
10. Er is een haalbare planning opgesteld voor de realisatie van de verbeteringen (bijv. volgorde, prioriteit, tijdsinschatting, sprintplanning). (3) (Weight: 10%)

Checklist

(nummers verwijzen naar onderlegger en rubric)

1. Zijn alle relevante informatiebronnen verzameld en systematisch geanalyseerd (zoals logs, testresultaten, foutmeldingen, gebruikersfeedback)? (O1, R1) (Weight: 15%)
2. Is de verzamelde informatie objectief en volledig geïnterpreteerd (bijv. clustering, patronen, oorzaken)? (O2, R1) (Weight: 10%)
3. Is er een duidelijke probleemanalyse gemaakt, inclusief onderliggende oorzaken (root cause analysis)? (O3, R1) (Weight: 10%)
4. Zijn wensen, reacties, testresultaten of meldingen vertaald naar concrete, haalbare verbetervoorstellen? (O4, R2) (Weight: 15%)
5. Zijn de verbetervoorstellen functioneel en technisch onderbouwd? (O5, R2) (Weight: 10%)
6. Bevat elk verbetervoorstel een duidelijke beschrijving van de impact (gebruikers, data, functionaliteit, onderhoud)? (O6, R2) (Weight: 10%)
7. Is onderscheid gemaakt tussen kleine verbeteringen (quick wins) en grotere wijzigingen? (O7, R2) (Weight: 5%)
8. Is per verbetervoorstel vastgesteld welke werkzaamheden nodig zijn (ontwerp, code, testen, documentatie)? (O8, R3) (Weight: 10%)
9. Zijn tijdsinschatting, afhankelijkheden en risico's beschreven? (O9, R3) (Weight: 5%)
10. Is een haalbare planning opgesteld voor de uitvoering van de verbeteringen (volgorde, prioriteit, tijdsinschatting)? (O10, R3) (Weight: 10%)

Vragen SPL

Vraag 1

In het kerntaakexamen voor Software Development bestaat kerntaak 1 uit vijf werkprocessen. Een student moet alle vijf werkprocessen met een voldoende afronden. Wanneer één werkproces, bijvoorbeeld werkproces 3, onvoldoende is, moet de hele kerntaak opnieuw worden uitgevoerd. Alleen het onvoldoende werkproces opnieuw laten maken leidt tot inconsistenties, omdat werkproces 3 afhankelijk is van de eerdere werkprocessen, planning en ontwerp. Een gedeeltelijke herkansing ondermijnt de samenhang en betrouwbaarheid van de beoordeling.

Binnen het beoordelingssysteem van het ROC geldt dat bij meerdere beoordelingen van hetzelfde onderdeel het hoogste cijfer telt. Dit betekent dat een student in de herkansing werkproces 1 en 2 opnieuw mag inleveren en daar zelfs lager op kan scoren, zonder dat dit gevolgen heeft voor eerder behaalde voldoendes. Het examen vereist echter dat een kerntaak als één geheel en in samenhang wordt beoordeeld. Daarom moet de student alle werkprocessen opnieuw aantonen om een volledig en consistent product op te leveren.

Hoe adviseert SPL om te gaan met deze inconsistentie?

1. De kandidaat kan inderdaad een eerdere gehaald voldoende naar beneden bijgesteld krijgen, of;
2. De kandidaat levert een volledig nieuw portfolio in en de eerdere beoordeling kan niet naar beneden worden bijgesteld. De inhoud van de reeds behaalde werkprocessen is alleen relevant voor de beoordeling van de nog niet behaalde werkprocessen.

Vraag 2

Daarnaast speelt het volgende probleem: in werkproces 1 van kerntaak 1 moet een planning worden opgesteld én gemonitord. Een groot deel van de beoordelingscriteria gaat over het monitoren van de planning tijdens de uitvoering van het project. Dit monitoren kan pas plaatsvinden wanneer het project in werkproces 3 en verder daadwerkelijk wordt uitgevoerd. Daardoor is werkproces 1 niet als opzichzelfstaand onderdeel te beoordelen; de kwaliteit van de planning blijkt pas tijdens werkproces 3, de uitvoering.

Dit betekent dat, strikt genomen, dat het hele portfolio van alle vijf werkprocessen in één keer beoordeeld zou moeten worden om de beoordeling valide te houden. In de praktijk wordt het portfolio echter stapsgewijs opgebouwd en tussentijds beoordeeld, zodat studenten tijdig feedback krijgen en kunnen verbeteren. Het nadeel hiervan is dat een formele eindbeoordeling per werkproces niet volledig los kan worden gezien van het geheel.

De kernvraag is daarom hoe deze praktijk te verenigen is met de formele eis van samenhang. Een student kan tussentijds een voldoende krijgen per werkproces en daardoor worden toegelaten tot het examen, maar de uiteindelijke beoordeling van (in dit voorbeeld) kerntaak 1 blijft een integrale beoordeling, waarin de werkprocessen als samenhangend geheel worden gewogen. Hiermee wordt recht gedaan aan zowel de opbouw van het portfolio-onderwijs als de exameneisen voor consistentie, maar dit naar kandidaten lastig te verantwoorden omdat de studenten tijdens het bouwen van hun portfolio geen indicatie/feedback hebben gehad dat er iets niets klopt en dit dan tijdens het mondeling examen pas naar voren komt. Daarnaast kost dit veel extra inzet en tijd van de examinatoren en docenten hetgeen had kunnen worden voorkomen door de opbouw van Kerntaak 1 volledig chronologisch te houden.

De door ons voorgestelde oplossing is om een 'pseude'-werkproces in te voeren, werkprocessen 3.5. Deze wordt na of tijdens werkproces 3 beoordeeld. Het lastige hieraan is dat dit alleen via een vertaling aansluit bij de rubics en dit op zijn minst ondoorzichtig is voor studenten.

1. Hoe is dit door SPL bedoeld?
2. Hoe kan dit hele proces efficiënt worden begeleid en hoe gaan andere colleges hiermee om?
   

--