Examenonderlegger jan '26 K1

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

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

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

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

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

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.

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.

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.

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.

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.

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. (Dit is anders dan de moscow tabel in de planning)

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.