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, fraemworks, 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.