Examenonderlegger jan '26 K1

Definities

1. Uitgangspunten (minimaal 4)
   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 6)
   Beschrijven architectuur, frameworks, datastromen, beveiliging, perfomance, data strucuren, database ontwerp, etc.
   Deze eigen beinvloeden de technische uitvoering maar beschrijven geen functionaliteiten.
4. Uigangspunten, en eisen voldoen aan:
   Relevantie, specifiek, controleerbaar/meetbaar, consistent, herleidbaar (bron/waarom).

Samengevat

1. Je benoemd kort, puntsgewijs minimaal 5 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).

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.
6. De volgorde is logisch.
7. De planning is concreet, testbaar.

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

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.
2. Elke functionele beschrijving bevat: doel, invoer, uitvoer en foutafhandeling.
3. Wanneer een functionaliteit of use case uit stappen (flow) bestaat, dan wordt deze beschreven. 
4. Alternatieve scenarios 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.

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.

1. Ontwerpkeuzes worden onderbouwd (waarom).
2. Bij tenminste 3 gevallen zijn één of meer alternatieven is/zijn overwogen.
3. Er wordt indien mogelijk beschreven welke keuzes er ten aanzien van security of privacy (AVG).

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

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/of aplicatie die is geinstalleerd en draait.

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

1. De opgeleverde code is gebasseerd op de plannign en ontwerp.

1. code is consistent qua opbouw structuur en documentatie.
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 beschreming tegen SQL-injection.

1. De code staat volledig in 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.

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.

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

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

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.

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.

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

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.