Checklist KT 2026

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

1. Uitgangspunten, eisen en wensen (6, 4, 2)
2. Er zijn minimaal 5 uitgangspunten (kaders/randvoorwaarden) benoemd. Ze zijn onderbouwd en de bron is duidelijk.
3. Er zijn minimaal 12 functionele eisen benoemd. Deze beschrijven observeerbaar gedrag en zijn testbaar.
4. Er zijn minimaal 5 technische eisen benoemd. Deze zijn concreet (controleerbaar) en onderbouwd.
5. Planning (10, 6, 3)
6. Alle functionele eisen komen terug in de planning.
7. 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.
8. De totale ontwikkeltijd is minimaal 40 uur (deze 40 uur is gebaseerd op niveau dat verwacht wordt van een MBO-4 examenkandidaat).
9. De planning is logisch en chronologisch van opbouw, concreet en testbaar.
10. In de planning zijn minimaal 5 overleg/ voortgangs momenten opgenomen.
11. Bewaking (6, 4, 2)
12. De voortgang is minimaal 5 keer bijgehouden gedurende de uitvoering van het project. (bevat datum en daadwerkelijke bestede uren)
13. Elke voortgangsmeting bevat status, afwijking en een beschreven actie op die afwijking.
14. Er is een afsluitende evaluatie/reflectie opgenomen van het verloop van het project.

2. Checklist B1-K1-W2 (Ontwerp)

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

3. Checklist B1-K1-W3 (Realisatie)

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

4. Checklist B1-K1-W4 (Testen)

• Kwaliteit Testcases (8, 5, 3)
• De testcases bevatten een pre-conditie, actie en verwacht resultaat.
• Er zijn zowel Happy Flow als Unhappy Flow (foutscenario's) tests uitgewerkt.
• De gekozen testdata is concreet en dekt randgevallen.
• Alle tests zijn reproduceerbaar met dezelfde eenduidige uitkomsten.
• Volledigheid / Dekking (4, 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..
• Alle functionaliteiten zijn getest.
• Uitvoering (4, 2, 1)
• Het werkelijke resultaat is bij elke uitgevoerde test vastgelegd.
• Je toont bewijs van de daadwerkelijke uitvoering (screenshots, logs, database-status) van de tests.
• Rapportage & Conclusie (4, 2, 1)
• Testresultaten en gevonden fouten (bugs) zijn duidelijk geregistreerd (omschrijving + ernst) en bevatten de juiste conclusie.
• Het rapport bevat een duidelijke eindconclusie/advies over de softwareversie.

5. Checklist B1-K1-W5 (Verbeteren)

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

---