Skip to main content

Onderlegger / Checklist C24 (Crebo 25998)

Kerntaak 1

B1-K1-W1

Stemt opdracht af, plant werkzaamheden en bewaakt de voortgang

Rubrics

  1. De opdracht, doelen en planning zijn afgestemd.
  2. De kandidaat houdt bij welke werkzaamheden zijn uitgevoerd, welke nog uitgevoerd moeten worden en gaat na of de planning in gevaar komt.
  3. De kandidaat signaleert afwijkingen in de doelen en planning, meldt dit en zoekt (in overleg) naar een (tussen)oplossing.

Onderlegger

() nummers verwijzen naar rubics

  1. Opdracht is beschreven (1).
  2. Doelen zijn beschreven (1).
  3. Planning is beschreven (1, 2).
  4. Indien er een opdrachtgever is, dan is er ook afgestemd (1).
  5. Projectvoortgang is bewaakt (2, 3)
  6. Project bijsturing is uitgevoerd en beschreven (3)

Checklist

(nummers verzijzen naar onderlegger en rubic)

  • Is er beschreven wat er gemaakt moet worden; hoe ziet het eindproduct eruit? (O1, R1)
  • Is er beschreven voor wie het is bedoeld; wie gaan ermee werken? (O1, R1)
  • Welke functionaliteiten moeten minimaal werken? (O1, R1)
  • Zijn alle gewenste functionaliteiten beschreven? (O1, R1)
  • Welke technische uitgangspunten zijn er (techniek, taal, frameworks)? (O1, R1)
  • Welk doel dient het project? Welk probleem wordt opgelost en hoe wordt gemeten of dat gelukt is? (O2, R1)
  • Bevat de planning duidelijke taakbeschrijvingen, plus per taak een geschatte tijd, deadline, verantwoordelijke en resultaatbeschrijving? (O3, R1)
    • Taken zijn nooit groter dan 1 dag (8 uur). (O3, R1)
    • Er is voor minimaal 40 uur programmeerwerk gepland (per persoon).
  • Is van elke taak bijgehouden wanneer deze is begonnen, door wie en wanneer deze klaar was? (O5, R2)
  • Welke wijzigingen zijn er in de planning gemaakt tijdens de uitvoering en zijn deze onderbouwd? (O5, R2)
    • Waarom is het gewijzigd? (O5, R2)
    • Wat waren de opties en waarom is deze optie gekozen? (O5, R2)
    • Is er overleg geweest en zo ja, met wie? (O4, R3)

B1-K1-W2

Maakt een technisch ontwerp voor software

Rubrics

  1. De eisen, wensen en technische randvoorwaarden zijn vertaald naar een passend, eenduidig en volledig (deel)ontwerp.
  2. Er is gebruikt gemaakt van relevante of toepasselijke schematechnieken (bijv. activiteitendiagram, klassendiagram, ERD, use case diagram).
  3. De gemaakte keuzes in het ontwerp zijn onderbouwd met steekhoudende argumenten die passen bij de praktijkrichting.

Onderlegger

() nummers verwijzen naar rubics

  1. Alle functionalieiten zijn beschreven (1)
  2. Alle technische randvoorwaarden zijn beschreven (1)
  3. Het ontwerp bevat passende en relevante schema’s (zoals ERD, activiteitendiagram, use case, flowdiagram) (2)
  4. Alle ontwerpkeuzes zijn onderbouwd met (functionele of technische) argumenten (3).

Checklist

(nummers verwijzen naar onderlegger en rubric)

  • Zijn alle functionele eisen en wensen compleet beschreven? (O1, R1)
  • Zijn alle technische randvoorwaarden volledig en correct vastgelegd (bijv. taal, framework, devices, API’s, database)? (O2, R1)
  • Is per eis of wens aantoonbaar aangegeven hoe deze is vertaald naar het ontwerp? (O1, R1)
  • Zijn alle schermen/componenten/modules uitgewerkt in tekst, schets, mockup of wireframe? (O1, R1)
  • Zijn de datastromen, interacties en relaties tussen onderdelen duidelijk beschreven (flowchart)? (O1, R1)
  • Bevat het ontwerp minimaal 3 relevante en juiste schema’s (ERD, activiteitendiagram, use case, flowdiagram)? (O3, R2)
  • Zijn de gebruikte benamingen consistent tussen schema’s, tekst, datamodel en ontwerp? (O1, R1)
  • Is bij elke ontwerpkeuze een inhoudelijke en logische motivatie gegeven (functioneel of technisch onderbouwd)? (O4, R3)
  • Zijn alternatieve ontwerpopties overwogen en is beschreven waarom een bepaalde keuze is gemaakt? (O4, R3)
  • Is het ontwerp voldoende gedetailleerd zodat een andere ontwikkelaar het systeem kan bouwen zonder extra uitleg? (O1, R1/R2)

B1-K1-W3

Realiseert (onderdelen van) software 

Rubrics

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

Onderlegger

 

  1. De geplande functionaliteiten zijn binnen de afgesproken tijd gerealiseerd of er is duidelijk verantwoord waarom dit niet volledig gelukt is (1).
  2. Er wordt ten minste 40 uur verantwoord voor dit werkproces. (1)
  3. De gerealiseerde functionaliteiten werken volgens de vooraf opgestelde eisen, wensen en acceptatiecriteria (2).
  4. Edge cases, foutafhandeling en uitzonderingssituaties zijn functioneel juist afgehandeld (2).
  5. De code heeft een duidelijke structuur (3)
  6. De code volgt relevante best practices (bijv. DRY, SRP, scheiding van concerns, herbruikbare functies, valide input-checks) (3).
  7. De opmaak van de code is netjes (inspringen). (3)
  8. Er is voldoende zinvol commentaar toegevoegd. (3)
  9. De naamgeving van variabelen, functies, methods en classes is consistent en duidelijk (3)
  10. De kandidaat heeft commit-historie die laat zien dat er regelmatig, logisch en stapsgewijs gewerkt is (4).
  11. Commits bevatten betekenisvolle commit messages die duidelijk maken wát er is veranderd en waarom (4).
  12. De kandidaat gebruikt branches, merges en/of pull requests op een manier die past bij de omvang van het project (4).

Checklist

(nummers verwijzen naar onderlegger en rubric)

  • Zijn de geplande functionaliteiten gerealiseerd binnen de afgesproken tijd, of is duidelijk verantwoord waarom dit niet gelukt is? (O1, R1)
  • Is er minimaal 40 uur aan werkzaamheden verantwoord binnen dit werkproces? (O2, R1)
  • Werken alle opgeleverde functionaliteiten volgens de vooraf opgestelde eisen en wensen? (O3, R2)
  • Zijn edge cases, foutafhandeling en uitzonderingssituaties correct en functioneel afgehandeld? (O4, R2)
  • Is de code logisch gestructureerd en duidelijk opgezet waarbij de code is opgedeeld in een duidelijke directory-structuur en is de code zinvol is opgedeeld in bestanden? (O5, R3)
  • Volgt de code relevante best practices (DRY, SRP, scheiding van concerns, herbruikbare functies, inputvalidatie)? (O6, R3)
  • Is de code netjes opgemaakt, inclusief correct inspringen? (O7, R3)
  • Is er voldoende zinvol commentaar toegevoegd waar dat nodig is? (O8, R3)
  • Zijn namen van o.m. variabelen, functies, methods en classes consistent en duidelijk gekozen? (O9, R3)
  • Laat de commit-historie zien dat er regelmatig, logisch en stapsgewijs gewerkt is? (O10, R4)
  • Bevatten commits betekenisvolle commit messages die duidelijk maken wát en waarom iets is aangepast? (O11, R4)
  • Worden branches, merges en/of pull requests toegepast op een manier die past bij de omvang van het project? (O12, R4)
Extra toeliching

DRY (Don’t Repeat Yourself)
Voorkomt dubbele code. Wanneer dezelfde logica op meerdere plekken staat, breng je het onder in één gedeelde functie of module. Dit maakt onderhoud eenvoudiger en vermindert fouten.

Herbruikbare functies
Functies die zo zijn geschreven dat ze op meerdere plekken en in verschillende situaties toepasbaar zijn. Ze zijn klein, duidelijk gedefinieerd en afhankelijk van zo min mogelijk specifieke context. Deze functies zijn de bouwblokken van de code.

SRP (Single Responsibility Principle)
Elke functie, klasse of module moet precies één duidelijke taak hebben. Dit maakt code begrijpelijker, testbaarder en minder foutgevoelig.

Scheiding van concerns
Splits verschillende verantwoordelijkheden in aparte lagen of bestanden. Bijvoorbeeld: HTML voor structuur, CSS voor vormgeving, JavaScript/PHP voor logica. Dit verhoogt overzicht en onderhoudbaarheid.

Inputvalidatie
Controleer alle gegevens die van gebruikers, API’s of formulieren binnenkomen. Je controleert of ze aanwezig, geldig en veilig zijn voordat je ze gebruikt, om fouten, beveiligingslekken en onverwacht gedrag te voorkomen.

Abstractie
Abstractie verbergt details, waardoor functies herbruikbaar worden en duplicatie verdwijnt.

B1-K1-W4

Test software 

Rubrics

  1. De kandidaat heeft passende testvormen en testmethodieken gekozen.
  2. De kandidaat heeft voor alle toegewezen of geplande functionaliteiten testscenario’s of testcases gemaakt.
  3. Het testrapport bevat testresultaten van alle functionaliteiten. Alle resultaten worden voorzien van de juiste conclusies.
Back to top