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

Uitgangspunten (minimaal 4)
Kaders, radwvoorwaarden, eisen of aannames die een globale scope hebben.
Functionalele eisen (minimaal 12)
Beschrijving van wat het systeem moet doen vanuit gebruikersperspectief.
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.
Uigangspunten, 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

Je benoemd kort, puntsgewijs minimaal 5 uitgangspunten. Elke uitgangspunt is onderbouwd (waarom) en het is duidelijk waar het uitgangspunt vandaan komt.
Je benoemd kort, puntsgewijs minimaal 12 functionele eisen. Elke eis beschrijft observeerbaar gedrag van de software (je kan het zien) en is testbaar.
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

Alle functionele eisen komen terug in de planning
Elke functionaliteit is opgesplitst in concrete taken van max. 4 uur per taak
Er is per taak aangegeven op welk onderdeel van de functionaliteit deze betrekking heeft
Bij elke taak staat een tijdsinschatting in uren (geheel of halve uren).
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.
De volgorde is logisch.
De planning is concreet, testbaar.

3. De gestelde doelen en planning zijn bewaakt.

Onderlegger bewaking

(bewaking wordt pas uitgevoerd vanaf werkproces 3).

Voortgang is gedurende de gehele planning minimaal 5 maal bijgehouden.
Voortgang bevat een status: wat is af en wat had moeten zijn en wat is de afwijking.
Bij elke afwijking wordt ene actie genomen en beschreven.
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 (8, 5, 2)
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 functionaliteit.
2.3	De totale ontwikkeltijd is minimaal 40 uur (incl. 20% testen, 10% documenteren) + 4-8 uur buffer.
2.4	De planning is logisch van opbouw, concreet en testbaar.
3	Bewaking (6, 4, 2)
3.1	De voortgang is minimaal 5 keer bijgehouden gedurende de planning.
3.2	Elke voortgangsmeting bevat status, afwijking en een beschreven actie op die afwijking.
3.3	Er is een afsluitende evaluatie/reflectie opgenomen.

B1-K1-W2

Ontwerpt software

Rubics

De eisen en wensen zijn vertaald naar een passend, eenduidingen volledig ontwerp.
Er is gebruikgemaakt van relevante of toepasselijke schematechnieken (bijv. activiteitendiagram, klassendiagram, ERD, use case diagram).
De gemaakte keuzes in het ontwerp zijn onderbouwd met steekhoudende argumenten, waarbij rekening is gehouden met haalbaarheid, privacy en security.

Onderlegger

Vanuit de planning zijn volgt dat het ontwerp aansluit bij de beschreven eisen.

Er wordt onderscheid gemaakt tussen de functionele eisen waarvan er minimaal 12 moeten zijn beschreven en technische eisen waarvan er minimaal 6 moeten zijn beschreven.

Voor elke eis kan 0,1 of 2 punten worden gegeven.

Voor technische eisen geldt dat ze eenduidig en onderbouwd zijn beschreven.

Checklist

Alle functionele eisen zijn beschreven
Functionaliteiten met betrekking op de GUI zijn voorzien van illustraties (schets, wireframe )en/of bevatten een eenduidige beschrijving en zijn zodoende testbaar.
Elke functionele beschrijving bevat: doel, invoer, uitvoer en foutafhandeling.
Wanneer een functionaliteit of use case uit stappen (flow) bestaat, dan wordt deze beschreven.
Alternatieve scenarios worden beschreven.
Alle technische eisen zijn eenduidig beschreven/uitgewerkt.
Technische beschrijvingen worden onderbouwd (waarom) en er worden alternatieven beschreven.
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.
Ontwerpkeuzes worden onderbouwd (waarom).
Bij tenminste 3 gevallen zijn één of meer alternatieven is/zijn overwogen.
Er wordt indien mogelijk beschreven welke keuzes er ten aanzien van security of privacy (AVG).

B1-K1-W3

Realiseert (onderdelen van) software

Rubics

Er is voldoende functionaliteit gerealiseerd binnen de gestelde/geplande tijd.
De opgeleverde functionaliteiten voldoen aan de eisen en wensen.
De kwaliteit van de code is goed.
Versiebeheer is effectief toegepast.

Onderlegger

Voldoende functionaliteiten

Er is minimaal 40 uur geprogrammeerd dit wordt onderbouwd door de hoeveelheid code, complexiteit en door middel van versiebeheer.

De code werkt en dit is aangetoond mbv video en/of aplicatie die is geinstalleerd en draait.

Opgeleverde functionaliteiten

De opgeleverde code is gebasseerd op de plannign en ontwerp.

Kwaliteit

De code voldoet aan de volgende kwaliteitsnormen:

code is consistent qua opbouw structuur en documentatie.
Variabelen, functies, methods, bestanden, databaselementen hebben duidelijk en betekenisvolle namen
Code is voor 80% opgebouwd uit functies en functies doen één ding en zijn niet langer dan 60 regels.
Bestanden bevatten maximaal 400 regels code.
De hele code base heeft een duidelijke structuur.
Er is geen dubelle code (DRY).
Geen onnodig commentaar, maar alleen om code ter verduidelijken.
In de code worden fouten duidelijk afgehandeld (try/catch).
Wachtwoorden en dergelijke worden niet in plain taxt opgeslagen.
Er is beschreming tegen SQL-injection.

Versiebeheer

De code staat volledig in versiebeheer.

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.

Commits zijn logisch opgebouwd, met duidelijke beschrijvingen.

Checklist

...

B1-K1-W4

Test software

Rubics

De testcases in het testplan sluiten aan op de functionaliteiten en bevatten alle relevante scenario’s.
De kandidaat heeft voor alle toegewezen of geplande functionaliteiten testscenario’s of testcases opgesteld.
De kandidaat voert de testactiviteiten correct en volgens het testplan uit.
Het testrapport bevat testresultaten van alle functionaliteiten, voorzien van de juiste conclusies.

Onderlegger

B1-K1-W5

Doet verbetervoorstellen voor de software

Rubics

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