Portfolio Kerntaak examen

• Algemene eisen portfolio
• K1 Software maken
• K1 W1 Planning
• K1 W2 Ontwerp
• K1 W3 Realisatie
• K1 W4 Testen
• K1 W5 Verbeteren
• K2 Ontwikkelteam
• K2 W1 Overleggen
• K2 W2 Presenteren
• K2 W3 Reflectie
• K2W3 Reflectie voorbeelden
• Examenproject
• Check List 2024-2025
• Check List 2025 (vanaf cohort 24)
• ChatGPT en Concreet
• Examen Eindgesprek
• Examineringsproces
• Examen Rubics
• Examen Rubics 2024 v 2023

Algemene eisen portfolio

Portfolio

Jouw portfolio bestaat uit een verzameling documenten.

De documenten dienen via Canvas te zijn ingeleverd. Alleen documenten die op Canvas staan tellen mee voor het examen.

Type documenten

Dit kunnen bijvoorbeeld MS Office documenten, plaatjes, screen dumps, video's en geluidsfragmenten zijn.

Jij bent er zelf voor verantwoordelijk dat de examinatoren de documenten kunnen lezen. Gebruik dus gangbare bestandsformaten zoals pdf, jpg, png, mp3, mp4 en zip.

Map per werkproces

Jouw portfolio kent een (hoofd)map per werkproces. Er zijn 8 werkprocessen. Binnen het werkproces mag je alles indelen zoals je wilt.

Per werkproces is er één document waarin alle documenten die bij dit werkproces horen zijn beschreven. Dit document heet inhoudsopgave. De template voor dit document vind je hier.

Authentiek

Jouw werk is authentiek. Dit betekent dat het je eigen werk is.

Indien je ingeleverde portfolio werk bevat dat jij niet zelf hebt gemaakt dan is er sprake van fraude (plagiaat).

Heb je nu bijvoorbeeld een groot ontwerp waar jij een deel van hebt gemaakt. Geef dan duidelijk in de inhoudsopgave aan wat jouw deel is.

Indien werk buiten school is gemaakt kan een getekende authenticiteitsverklaring van de stagebegeleider en/of van de klant als aanvullend bewijsmateriaal worden opgeleverd. 

Hoeveelheid

Je moet voor 8 werkprocessen bewijzen aanleveren. Voor elk werkproces heb je één of meerdere bewijzen.

Over het algemeen geldt; meer is beter. Je hebt drie projecten gedaan (op stage)? Voeg van alles wat bij, maar houd het wel relevant.

K1 Software maken

K1 W1 Planning

Werkproces 1 van kerntaak 1 gaat over planning en ontwerp.

Je ontvangt de opdracht.

Je moet aantonen dat je het volgende beheerst.

Eisen

1. Je gaat jezelf inlezen, zoekt eventueel zaken op, je wint advies in van anderen en probeert een zo goed mogelijk plaatje (in je hoofd) te maken van wat je moet gaan bouwen.
2. Je gaat met de opdrachtgever en eventueel andere betrokkenen in gesprek om alles door te nemen en om eventuele onduidelijkheden verder te verduidelijken.
3. Je zet alle eisen en wensen op papier (dat kan in user stories) en koppelt dat terug.
   
4. Je maakt een planning als dan niet volgens een agile development proces. Je laat zien dat je doorlooptijden kan inschatten en je kunt logische prioritering aanbrengen door bijvoorbeeld MoSCoW-methode).
5. Je houd de planning in de gaten en stelt die zo nodig bij. Onderbouw deze afwijkingen en evalueer middels een of meerdere reflectieverslagen.

Bewijsmateriaal

Wat kun je als bewijsmateriaal aanleveren in je portfolio?

1. Een situatiebeschrijving (vooraf) van context van de opdracht als deze buiten school is uitgevoerd (zie apart kopje hieronder).
2. Een beschrijving van hoe je je hebt voorbereid op de opdracht.
3. Een document met eisen en wensen dat is besproken en is goedgekeurd door de opdrachtgever.
   
4. Een document met de planning.
   Planning is logisch, correct en er is een vorm van prioritering aangebracht.
   
5. Een ondertekend gespreksverslag en/of video-fragment.
   Het gesprek verloop goed opgebouwd (kop-romp-staart). Je past LSD toe; luisteren, samenvatten en doorvragen.
6. Refelctieverslag(en).

Template

Hier is een template om een planning te maken: Projectplan (template).docx

Let met het 'invullen' van deze template, voldoe je nog niet aan alle eisen.

Situatiebeschrijving

Als je de opdracht op school uitvoert dan kennen wij de omgeving. Als je de opdracht buiten school uitvoert voeg dan een situatie beschrijving toe. Dit is een beschrijving van de situatie vooraf.

Hierin beantwoord je de volgende vragen:

• Voor wie maak je de opdracht?
• Wat is jouw relatie met de opdrachtgever (kennis, familie, onbekende,....)?
• Wat zijn de afspraken met de opdrachtgever, denk aan tijd, deadlines en vergoeding.
• Aan wie rapporteer jij? Dus aan wie geef je aan als je bijvoorbeeld iets niet op tijd af dreigt te krijgen?
• Met wie werk je samen? Doe je dit alleen of met een groep?
• Wat zijn precies je taken?
• Hoeveel tijd schat je in totaal bezig te zijn met de opdracht?
• Welke kennis heb je nodig voor de opdracht?
• Beschik jij over alle benodigde kennis en zo niet, joe ga je dat op lossen?
• Zijn er overige zaken die van belang zijn voor de examinator om te weten als hij deze opdracht gaat beoordelen?

Beoordelingsrichtlijnen

• Eisen en wensen zijn in de vorm van user story's beschreven; er zijn er minimaal 3 goede user-stories beschreven. In een goede user story staat de rol, de functionaliteit en het doel (Als- wil ik - zodat).
• Is het duidelijk wanneer het project volgens de planning plaats vindt?
• Is er per taak beschreven wat er moet worden gedaan, door wie en hoe lang het duurt?
• Is een taak met zoveel detail beschreven dat er met een marge van +/- 50% kan worden bepaald hoeveel tijd er voor nodig is? De tijd die is geschat is reëel of is goed onderbouwd.
  
• Er wordt aangetoond dat gedurende het project de planning wordt bewaakt. Er wordt minimaal op drie momenten bepaald waar het project staat (loopt voor, op planning of loopt achter).

Deze beoordelingsrichtlijnen zijn gebaseerd op de SPL "Beoordelingsformulier praktijkexamen" (examencode SD_SD20_B1-K1-2_1V1, crebo 25604).

K1 W2 Ontwerp

Werkproces 2 van kerntaak 1 gaat over ontwerp.

Je hebt alle eisen en wensen duidelijk op papier (of in user story's).

Je moet aantonen dat je het volgende beheerst.

Eisen

Je hebt één of meerdere ontwerp documenten gemaakt.

De eisen en wensen (user story's) zijn vertaald naar een ontwerp. In dit ontwerp wordt duidelijk wat er wordt gebouwd hoe het er (ongeveer) uit gaat zien en welke objecten/entiteiten je gaat maken.

In het ontwerp moet je laten zien dat je ontwerpdiagrammen beheerst zoals: activiteitendiagram, klassendiagram, ERD, Use-casediagrammen.

Het ontwerp wordt onderbouwd waarbij zaken als security, privacy en ethiek aan de orde kunnen komen.

Hoe maak je een GUI ontwerp?

Er zijn talloze handige online tools om GUI ontwerpen te maken.

Tools voor ontwerpen GUI:

• https://www.lucidchart.com (gebruik 'Website blockframe')
  
• http://www.phpform.org/
• https://app.lucidchart.com
• Top 25 free Mockup and Wireframe tools. 
• De nummer 1, Frame Box
• chatGPT (laat een GUI in HTML maken, open in de browser en maak een schermafdruk)

Bewijsmateriaal

Wat kun je als bewijsmateriaal aanleveren in je portfolio?

1. De opdrachtbeschrijving als je dit buiten school hebt uitgevoerd.
   
2. Eén of meerdere ontwerpdocumenten.
   De ontwerpdocumenten zijn door jouw zelf gemaakt en beschrijven een aanzienlijk deel van de software(aanpassingen). Een aanzienlijk deel is een deel wat minimaal 40 uur kost op te coderen.
   De ontwerpdocumenten voldoen aan de eisen (zie hierboven).

Beoordelingsrichtlijnen

1. De user story's (uit kerntaak 1, planning) zijn vertaald in een ontwerp.
2. Het ontwerp laat zoveel mogelijk grafisch zien wat er gebouwd gaat worden. Wanneer er geen grafische vorm wordt gegeven dan moet de gebruikersinterface zo goed mogelijk zijn beschreven in text, aangevuld met ruwe schetsen (wireframes).
3. Er zijn minimaal twee schematechnieken toegepast, (bijvoorbeeld ERD, activiteitendiagram, klassendiagram, Use Case diagram)
4. De keuzes in het ontwerp worden onderbouwd. Hierbij is bijvoorbeeld rekening gehouden met ethiek, privacy en security.
5. De onderwerpen Privacy, Security en Ethiek zijn beschreven.
   

(zie voor de up-to-date checklist: https://www.roc.ovh/books/portfolio-kerntaak-examen/page/check-list

De beoordelingsrichtlijnen zijn gebaseerd op de SPL "Beoordelingsformulier praktijkexamen" (crebo 25604).

K1 W3 Realisatie

Werkproces 3 van kerntaak 1 gaat over de realisatie, het coderen.

Je ontvangt de opdracht. Zorg ervoor dat als je de opdracht buiten school maakt dat de opdrachtbeschrijving duidelijk op papier staat. Voeg dit toe aan je portfolio.

Je moet aantonen dat je het volgende beheerst.

Eisen

1. Je hebt voldoende functionaliteiten gemaakt.
   Dit is natuurlijk afhankelijk van de vorm en de tijd. Maar je moet denken aan 16 tot 40 uur 'puur' programmeerwerk (dus zonder inrichten computer, overleg, ontwerp en dergelijke). Hoe meer hoe beter want dan kunnen we beter de kwaliteit beoordelen.
2. De kwaliteit van de functionaliteit is goed en voldoet aan de vastgestelde eisen.
3. De kwaliteit van de code is goed.
   De structuur klopt (bijv. MVC), de foutafhandeling is goed en je hebt rekening gehouden met security. De code werkt efficiënt (is dus niet onnodig langzaam).
4. De code is opgesteld volgens de code conventions.
   Dit zijn afspraken die je onderling maakt over de vorm van de code.
5. De code ziet er verzorgd uit.
   Dit heeft raakvlakken met de kwaliteit van de code. Het gaat erom of de code goed leesbaar is. DIt heeft ook te maken met structuur, naamgeving en commentaar.
6. Versiebeheer is toegepast.
   Je kan de ontwikkeling van het product laten zien aan de hand van versiebeheer. Je kunt dus terugkijken in oude versies.

Bewijsmateriaal

Wat kun je als bewijsmateriaal aanleveren in je portfolio?

1. De opdrachtbeschrijving als de opdracht buiten school is gemaakt.
2. De delen van het ontwerp (user stories) die jij hebt gecodeerd.
3. Logboek waarin je per dag bijhoud wat je hebt gedaan. Beschrijf ook kort waar je tegenaan liep en hoe je dat hebt opgelost.
4. De code in een vorm dat die door een ander kan worden geïnstalleerd. De code is dus compleet met database en korte installatie handleiding.
5. De code conventions en een checklist waaruit blijkt dat je code is gecontroleerd.
6. Documentatie waarin je de structuur en opbouw van je code uitlegt en eventueel onderbouwt.
7. Documentatie waarin je uitlegt hoe en wat je hebt gedaan om je applicatie secure/veilig te maken.
   
8. Je hebt een repository (bijvoorbeeld in SVN of GIT) en laat bijvoorbeeld in een filmpje zien hoe je daar mee werkt.
   
9. Documentatie waarin je uitlegt hoe jij versiebeheer gebruikt.

Beoordelingsrichtlijnen

1. Er is minimaal 40 uur besteed aan het implementeren van User story's.
   
2. De opgeleverde functionaliteiten werken en voldoen in minimaal 80% van de scenario aan de user story. Dit betekent dat foutieve, ongewenste of missende functionaliteit alleen in uitzonderlijke gevallen mag optreden.
3. Er kan worden aangetoond dat er rekening is gehouden met: efficiëntie van de code, goede performance, foutafhandeling, invoercontrole, security, beveiliging.
   
4. De code is op een uniforme manier gemaakt waarbij bijvoorbeeld gebruik gemaakt is van een code conventie.
   
5. De code is voor een buitenstaander goed leesbaar door het gebruik van goede variabele namen en functies en commentaar in de code. Deze naamgeving is Engels of Nederlands.
   
6. Er is gebruik gemaakt van versiebeheer. Vanuit het versiebeheer kunnen tenminste 5 oude versies van de code worden getoond.

(Punt 1 en 3 zijn cruciaal)

Deze beoordelingsrichtlijnen zijn gebaseerd op de SPL "Beoordelingsformulier praktijkexamen" (examencode SD_SD20_B1-K1-2_1V1, crebo 25604).

--

K1 W4 Testen

Werkproces 4 van kerntaak 1 gaat over het testen van software.

Je moet aantonen dat je het volgende beheerst.

Eisen

1. Je kunt een testplan opstellen. Het testplan sluit aan op het ontwerp (of user stories).
2. Het testplan heeft voldoende stappen en scenario's beschreven. Als alles testscenario's goed zijn doorlopen dan is er voldoende zekerheid over de juisten werking van de applicatie.
3. Je kunt een goed testrapport opstellen. Ui het testrapport is op te maken wat er is getest en wat de resultaten zijn.

Bewijsmateriaal

Wat kun je als bewijsmateriaal aanleveren in je portfolio?

1. Een door jouw opgesteld testplan.
   Het testrapport dient alle testen die nodig zijn om bepaalde functionaliteiten te testen te bevatten. De omschrijving moet eenduidig zijn. Testen moeten vanuit het testplan reproduceerbaar zijn.
2. Een door jouw opgesteld testrapport.
   Het testrapport dient alle resultaten te bevatten. Bij de bevindingen geef je ook aan wat jouw aanbeveling en/of conclusies zijn.
3. Een document waarin je uitlegt hoe het testen organisatorisch is verlopen en wat precies je rol was. Wie was jouw opdrachtgever, aan wie rapporteerde jij, waren er meer testers, wat deed je als je een fout had gevonden, etc.
4. Een reflectieverslag van hoe het testen is verlopen: wat ging goed en wat zou je de volgende keer anders doen?

Beoordelingsrichtlijnen

1. Het testplan omvat minimaal drie user story's. Van de user story's worden gemiddeld 5 test scenario's opgesteld. Er zijn dus minimaal 15 test scenario's beschreven.
2. De test scenario's zijn door een derde persoon na te spelen. Dit betekent dat: (1) de beginsituatie is beschreven waarbij de dataset eventueel beschreven of toegevoegd is (denk aan database export), (2) de gewenste juiste uitkomst is beschreven en (3) de stappen om te komen tot het resultaat zijn beschreven.
   
   Er zijn naast de hoofdscenario's ook alternatieve scenario's beschreven. Hierbij valt te denken aan bijvoorbeeld het invoeren van grenswaarden of foutieve waarden. Alternatieve scenario's testen vaak of de foutopvang juist is.
3. Het testrapport toont aan dat alle testscenario's zijn uitgevoerd en wat de resultaten zijn. De resultaten bevatten waar mogelijk conclusies en/of er wordt een algemene conclusie beschreven. Deze kan worden versterkt met een aanbeveling.

Deze beoordelingsrichtlijnen zijn gebaseerd op de SPL "Beoordelingsformulier praktijkexamen" (examencode SD_SD20_B1-K1-2_1V1, crebo 25604).

Testrapport (template).docx

--

K1 W5 Verbeteren

Werkproces 5 van kerntaak 1 gaat over verbteren of aanpassen van de software.

Je ontvangt de opdracht.

Je moet aantonen dat je het volgende beheerst.

Eisen

1. Je hebt de software gestest en vanuit het testen heb je verbetervoorstellen gedaan. Deze verbetervoorstellen mogen buiten de scope van het ontwerp leggen. De verbetervoorstellen worden onderbouwd.
2. Tijdens de oplevering van de software heb je dingen gezien die beter kunnen. Hieruit heb je verbetervoorstellen gedaan. Deze verbetervoorstellen zijn goed onderbouwd.
3. Je hebt voor jezelf een reflectie gemaakt over het product. Hieruit heb je verbetervoorstellen gedaan. Deze verbetervoorstellen zijn goed onderbouwd.

Het uitvoeren van de verteringen is geen onderdeel van dit werkproces, maar kan wel als onderdeel mee worden genomen in werkproces 2 (realisatie).

Bewijsmateriaal

Wat kun je als bewijsmateriaal aanleveren in je portfolio?

1. Eigen gemaakte verbetervoorstellen.
2. Een beschrijving van hoe je bent gekomen tot het opstellen van de verbetervoorstellen. Deed je dat alleen, met wie heb je overlegd, kreeg je input. Wie hebben je verbetervoorstellen gelezen? Hoe lang heb je er over gedaan en in welke periode heb je de voorstellen gemaakt.

Beoordelingsrichtlijnen

1. Er zijn verbetervoorstellen gedaan die zijn gebaseerd beschreven bevindingen. Dit is het testrapport, maar kunnen ook incidentmeldingen zijn vanuit de productieomgeving (tijdens een stage). Er wordt in ieder geval aangetoond wat de basis is van de verbeteringen.
2. Er zijn verbetervoorstellen gedaan vanuit de opleveringen. Je levert altijd op aan een opdrachtgever (of klant). Vraag de opdrachtgever of er verbeteringen kunnen worden aangebracht. Wanneer deze er niet zijn dan aantonen dat de klant geen verbetervoorstellen heeft.
3. Er zijn verbetervoorstellen gedaan vanuit de (eigen) reflectie van het product.

Deze beoordelingsrichtlijnen zijn gebaseerd op de SPL "Beoordelingsformulier praktijkexamen" (examencode SD_SD20_B1-K1-2_1V1, crebo 25604).

--

K2 Ontwikkelteam

K2 W1 Overleggen

Werkproces 1 van kerntaak 2 gaat over hoe je in een ontwikkelteam hebt samengewerkt.

Je moet aantonen dat je het volgende beheerst:

Eisen

1. Je werkt actief mee.
   Dit betekent dat je deel van het team uitmaakt en dat je initiatieven neemt. Dat kan zijn dat je de juiste vragen stelt of de juiste onderwerpen aandraagt. Dit doe je natuurlijk op een constructieve manier.
2. Je stemt regelmatig af.
   Je zorgt ervoor dat je regelmatig, bijvoorbeeld 1x per dag of 1x per week overleg hebt met jouw leidinggevende.
3. Je legt afspraken vast.
   Je zorgt er ook voor dat afspraken met jouw opdrachtgever en/of klant worden vastgelegd en je hebt hierin een actieve rol.

Bewijsmateriaal

Wat kun je als bewijsmateriaal aanleveren in je portfolio?

1. Een (reflectie)verslag over hoe jij hebt samengewerkt in het ontwikkelteam. Wat was jouw rol, wat waren jouw sterkte punten, wat waren je minder goede punten. Wat zou je de volgende keer anders doen?
   Vraag je teamgenoten ook om input.
2. Een filmpje dat een indruk geeft van het team en hoe jullie overleggen. Het gaat hierbij om een indruk dus 1 à 2 minuten film is meer dan genoeg.
3. Een beschrijving en/of reflectieverslag over hoe je hebt afgestemd. Hoe ging dat, wat ging goed en wat kon beter?
4. Door jouw vastgelegde afspraken. De afspraken zijn eenduidig, bevatten een datum en een deadline en het is duidelijk voor wie de afspraken bedoeld zijn.
5. Een beschrijving en/of reflectieverslag over hoe het maken van afspraken is gegaan. Zijn alle afspraken altijd nagekomen en waarom wel of niet? Wat ging goed en wat zou je een volgende keer anders aanpakken?
   
6. Een filmpje dat een indruk geeft van hoe jij afstemt. Het gaat hierbij om een indruk dus 1 à 2 minuten film is meer dan genoeg.

--

K2 W2 Presenteren

Werkproces 2 van kerntaak 2 gaat over presenteren.

Je moet aantonen dat je het volgende beheerst:

Eisen

1. Je doet een presentatie.
   Je presenteert overtuigd, duidelijk en je verhaal is afgestemd op de doelgroep.
2. Informeren betrokkenen.
   Je legt betrokkenen (leidinggevende of klant) uit hoe zaken werken en je stelt vragen om te controleren of de informatie goed is overgekomen.
3. Feedback ontvangen.
   Je ontvang feedback, staat daarvoor open en reageert goed op feedback.

Bewijsmateriaal

Wat kun je als bewijsmateriaal aanleveren in je portfolio?

1. Een filmpje en beschrijving van één of meer presentaties.
2. Een zelfgemaakte PowerPoint (of soortgelijk) van een presentatie die jij hebt gegeven. Geef ook een beschrijving van de presentatie; voor wie en wanneer en wat was het doel van de presentatie.
3. Een beschrijving van wanneer jij wie hebt geïnformeerd en hoe jij hebt gecontroleerd of de betrokkenen alles goed begrepen hadden?
4. De feedback die jij hebt ontvangen en een beschrijving van de situatie en wat jij met de feedback hebt gedaan.
   Ook hier zou je ook een kort filmpje kunnen laten zien waarin jij feedback krijgt.

--

K2 W3 Reflectie

Werkproces 3 van kerntaak 2 gaat over reflectie.

Waarschijnlijk heb je al meerdere reflecties gemaakt; deze kun je ook gebruiken voor dit werkproces.

Je moet aantonen dat je het volgende beheerst:

Eisen

1. Je kunt een reflectieverslag opstellen waarin je terugkijkt naar je eigen handelen en waarbij je positieve en verbeterpunten van het proces noemt. Je maakt hierbij onderscheid tussen de teamprestaties en je eigen prestaties.
2. Je ontvang al dan niet op eigen verzoek feedback en je reageert daar constructief en adequaat op.
3. Tijdens meetings/overleggen reageer jij proactief en heb je een actieve positieve houding.

Checklist

1. Gaat het verslag over jouw handelen?
2. Benoem je goede punten over jouw handelen?
3. Benoem je verbeterpunten over jouw handelen?
4. Maak je onderscheid tussen jouw handelen en dat van het team waar jij deel van uit maakt?
5. Geef je in het verslag aan dat je feedback hebt gehad en hoe je daarop reageert?
6. Beschrijf je in het verslag dat jij een pro-actieve houding hebt (dus dat jij initiatief laat zien)

Bewijsmateriaal

Wat kun je als bewijsmateriaal aanleveren in je portfolio?

1. Reflectieverslagen waarin je duidelijk onderscheid maakt tussen: positieve punten en verbeterpunten en tussen teamprestaties en eigen prestaties.
2. Een beschrijving van wie je wanneer in welke situatie feedback kreeg en hoe je daarop hebt gereageerd. Je laat dit verlag tekenen door degene van wie je de feedback kreeg.
   Voor dit punt is een beschrijving over één voorval niet voldoende. Vul dit bewijs aan met een filmpje of stel eerdere beschrijvingen op.
3. Een beschrijving van een meeting en hoe jij daar een proactieve houding hebt laten zien. Je laat dit verslag tekenen door de voorzitter van de meeting.
   Voor dit punt is een beschrijving over één voorval niet voldoende. Vul dit bewijs aan met een filmpje of stel eerdere beschrijvingen op.

Template

Template voor maken reflectieverslag volgens methode STARR:  STARR Voorbeeld en template.docx .

--

K2W3 Reflectie voorbeelden

Voorbeeld 1 - veel voorkomend

Reflectie

Ik vond het goed van mezelf dat ik probeerde om het probleem volledig zelfstandig op te lossen, zelf als het uiteindelijk niet gelukt is om de ticket die dag af te handelen.

Als ik wat eerder XXX om hulp vroeg had ik waarschijnlijk de ticket die dag wel af kunnen ronden.

Volgende keer moet ik dus wat eerder om hulp vragen, of een afspraak maken over hoe ik een vraag achter kan laten voor als mijn begeleider het minder druk heeft. Ik moet ook leren wat sneller vragen te stellen, en dat ik niet altijd 100% zelfstandig moet zijn.

Voorbeeld 2 - beter?

Reflectie

Wat ging goed en wat niet?

Ik probeerde laatst een probleem helemaal zelf op te lossen tijdens een project. Hoewel ik het goed vond dat ik dit probeerde, lukte het niet om de taak die dag af te ronden. Dit liet me zien dat ik soms te lang wacht om hulp te vragen.

Wat was het probleem?

Het probleem was dat ik te lang aarzelde om hulp te vragen. Ik dacht dat ik alles alleen moest kunnen doen om te laten zien dat ik het aan kon. Hierdoor raakte ik vast en verspilde ik tijd, wat het project vertraagde en me gestrest maakte.

Wat ga ik anders doen?

Om dit te verbeteren, ga ik de volgende dingen anders doen:

1. Sneller Hulp Vragen: Ik zal eerder om hulp vragen, al bij de eerste tekenen dat ik vastloop. Dit voorkomt dat ik te veel tijd verlies.

2. Beter Afspreken Over Vragen: Ik maak afspraken met mijn begeleider over hoe en wanneer ik vragen kan stellen, vooral als hij of zij druk is. Dit kan via e-mail of tijdens geplande momenten.

3. Balans Vinden: Ik moet leren dat het oké is om hulp te vragen en dat dit juist laat zien dat ik serieus bezig ben en wil leren. Het is niet erg om soms samen te werken.

Evaluatie van de verandering, helpt het?

Om te zien of deze veranderingen helpen, zal ik:

• Feedback Vragen: Regelmatig aan mijn begeleider en teamgenoten vragen hoe ze vinden dat ik het doe met hulp vragen en samenwerken.
• Reflecteren: Na elk project nadenken over hoe vaak ik hulp heb gevraagd en of dit het werk makkelijker maakte.
• Zelf Nakijken: Letten op mijn eigen stress en tevredenheid om te zien of ik me beter voel tijdens het werk.

Door dit te doen, hoop ik beter te worden in mijn werk en minder gestrest te zijn, en een goede balans te vinden tussen zelf dingen doen en samenwerken.

Voorbeeld 3 - uitgebreid

Reflectie

Over het algemeen vond ik het voor de eerste keer dat ik met deze programma’s heb gewerkt goed gaan. Ik heb het gevoel dat ik door deze opdracht goed voorbereid ben op volgende opdrachten die ik ga krijgen, omdat deze opdracht heel veel verschillende elementen heeft. Ik liep niet al te veel vast, ik kwam vaak snel op de oplossingen en ik heb goede begeleiding gehad. Ook ben ik erg tevreden met het eindresultaat. Het ziet er goed en mooi uit en alles werkt. Maar niet alles ging even goed, sommige dingen konden beter en zou ik bij een volgende opdracht anders doen.

Wat ging er goed?

Bij het maken van het ontwerp wist ik gelijk wat ik wilde en daarom ging het stijlen van de pagina ging voor mij erg goed. Ik had een duidelijke visie voor het uiterlijk en dit heb ik ook precies zo uitgevoerd. Ook had ik werken met material UI had ik snel onder de knie en verliep dit allemaal vrij soepel. Ik ben daarom ook erg tevreden met het resultaat.

Naast de styling ging het eerste deel van het maken van de site ook erg goed. Ik had een video die mij precies begeleide bij wat ik aan het doen was en zo ging het allemaal erg makkelijk. Ik snapte alles ook goed door de duidelijke uitleg. Deze video was voor mij een goede oplossing voor niet weten waar ik moest beginnen. Vaak als er een tutorial wordt gebruikt dan doe je gewoon na wat er gebeurt en snap je aan het einde vaak niet wat je precies hebt gedaan. Hier had ik een oplossing voor gevonden door achteraf aantekeningen te maken met daarin een uitleg in mijn eigen woorden. Voor mij werkte dit erg goed en zo snapte ik aan het einde alles, omdat ik het eigenlijk opnieuw aan mezelf aan het uitleggen was.

Wat kan ik verbeteren?

Tijdens het werken aan dit project heb ik een aantal verbeterpunten gevonden voor zowel coderen als mijn manier van werken. Als eerste is een groot verbeterpunt voor mij dat ik eerder op hulp moet vragen. Omdat ik graag alles zelf wil doen en alles zelf wil uitzoeken kan dit mij soms behoorlijk in de weg zitten en vertragen in het proces. Bij dit project heb ik bijvoorbeeld soms wel 3 weken met 1 probleem gezeten omdat ik het zelf wilde uitzoeken. In het vervolg zou ik graag willen leren om eerder om hulp te vragen en een balans te vinden tussen zelf oplossen en hulp vragen.  Omdat iemand anders de oplossing misschien sneller kan vinden en dit gelijk ziet. Dit scheelt behoorlijk wat tijd.

Als tweede verbeterpunt heb ik om een betere planning te maken. In het proces van dit project ben ik eerst gaan werken en heb ik daarna pas een planning gemaakt. Dit zou ik bij een volgende opdracht anders doen, omdat dit voor meer structuur tijdens het werken zorgt. Ook denk ik dat het zo zou helpen bij mijn andere verbeterpunten. Door het maken van het examen portfolio heb ik ook kunnen leren hoe ik een goede planning maak en mij aan deze planning kan houden.

Als laatste verbeterpunt heb ik dat ik beter moet werken met versie beheer. Ik had voor deze opdracht een kladblok gebruikt als versie beheer. Dit werkte redelijk goed, alleen kon ik dit niet makkelijk terughalen in het programma waar ik in werk. Zo zijn er ook andere manieren om te werken met versie beheer zoals GIT. Als ik hiermee had gewerkt kon in alle bestanden in hetzelfde programma halen voor overzicht.

Verbeteren en omgaan met feedback

In de code ging de feedback vooral over dingen zoals foutmeldingen afhandelen en toevoegen en informatie aan de URL toevoegen. In de URL moest er informatie zoals een ID en pagina’s nummers toegevoegd worden. Dit zijn wat kleinere dingen waar ik tijdens het werken niet aan had gedacht, maar door de feedback wel heb toegevoegd aan de website. Door aanpassingen te doen in de code.  Zo is ook de gebruiksvriendelijkheid verbeterd. Ook heb afhandelen van foutmeldingen had ik niet overal aan gedacht. Op bijvoorbeeld de homepagina moest ik bij de zoekbalk een melding toevoegen wanneer er geen resultaten zijn de overeengekomen met de zoekopdracht. Dit heb ik gedaan door een functie te maken die daarvoor zorgt. Deze functie heb ik ook vaker kunnen hergebruiken voor de andere pagina’s. Als laatste heb ik feedback gekregen over het responsive maken van de afbeeldingen op de website zodat deze ook mooi staan op een ander scherm. Dit heb ik gedaan met SASS door breakpoints toe te voegen. De rest van de website was al responsive door Material UI.

Voorbeeld 4

Reflectie

Nu de uiteindelijke reflectie. Persoonlijk vond ik dat de meeste dingen goed gingen, vanaf het brainstormen over het ontwerp tot het voltooien van de volledige website. Het ging over het algemeen best wel goed. De samenwerking verliep als gepland. Beide waren we tevreden met onze rollen gedurende dit project.

Wij hadden als team elkaar wel wat feedback gegeven. Ik gaf XXX de volgende feedback: Betere communicatie, onze communicatie was prima, maar kon wel beter. Al eerder verteld dat we vaker een meeting konden hebben, of vaker met elkaar afspreken. XXX kon vaker een update geven als hij wat gedaan, maar voor de rest heeft XXX het supergedaan tijdens dit project. Toen gaf XXX mij feedback. XXX gaf mij de volgende feedback: Ook XXX vond dat ik meer kon communiceren. XXX vond dat ik ook te weinig updates gaf, waar ik het mee eens ben. Ik kon vaker updates geven over hoe ver ik was met de website. Bijvoorbeeld, als ik met een stukje code klaar was, dan kan ik dat direct vertellen, dan was XXX er ook meteen op de hoogte van. Of als ik even niet bezig ben, dat ik dat ook vertel, want dan weet XXX ook dat ik even niet bezig ben. XXX gaf mij ook als feedback dat ik te lange pauzes nam, niet van 2 uur, maar echt van dagen. Als je een project met elkaar begint, moet je er vol voor gaan, zei XXX . Ik kan het niet anders eens zijn met wat XXX hier zegt, ik nam veel te veel pauze. XXX gaf dit aan na een aantal weken, en heb hier meteen verandering in gebracht. Verder in het project is het goed gegaan en gaan lange pauzes meer genomen. Verder had XXX geen feedback meer op mij.

Ten slotte, mijn gedrag om feedback te ontvangen en actie te ondernemen om mijn gedrag te verbeteren, laat zien dat ik niet alleen initiatief kan tonen bij het nemen van beslissingen, maar ook bij het maken van verbeteringen en goede communicatie. De lessen die ik heb gehad met XXX , over samenwerking en communicatie kan ik in de toekomst toepassen in andere situaties waarin teamwork en regelmatige communicatie heel belangrijk zijn

Examenproject

Case "PoC Share Wheels"

Het Bedrijf

Het bedrijf "Share Wheels" heeft tot doel om een platform aan te bieden waarmee het mogelijk is om jouw auto te verhuren. Het bedrijf is een start-up en wil graag een app ontwikkelen waarmee het de gebruiker in staat stelt om hun auto te verhuren. Het bedrijf bestaat uit drie vrienden die een programmeur zoeken om een "proof of concept" (PoC) te maken, dat is zeg maar een soort testversie waarmee het concept van het delen van een auto kan worden getest.

De drie vrienden hebben eerder een start-up opgezet en hebbend deze verkocht. Deze start-up had software ontwikkeld om epidemieën beter te kunnen voorspellen. De vrienden hebben geen tekort aan kapitaal en zijn in staat om lange tijd geld te investeren zonder dat er winst hoeft te worden gemaakt. Zij willen voorlopig alleen samenwerken met ZZP'ers.

Het Concept

Het idee is dat de een auto wordt aangeboden. Om een auto te kunnen verhuren moet je geregistreerd zijn. Ook de auto huurder zal zich moeten registreren. Bij de registratie moet ook worden gecontroleerd of de huurder in bezit is van een geldig rijbewijs.

De huurder kan aangeven welke auto hij wanneer te huur wil aanbieden. De verhuurder kan binnen een bepaalde prijs range ook aangeven wat de huurprijs is. De huurprijs is opgebouwd uit een kilometerprijs en een dagprijs. De verhuurder kan aangeven wie hij in aanmerking wil laten komen voor de verhuur van zijn auto. Dat kan hij doen door aan te geven hoe lang de huurder in bezit moet zijn van een rijbewijs.

De verhuurder geeft per dag van de week aan welk dagdeel de auto beschikbaar is.

In principe wordt een auto alleen verhuurd aan iemand uit dezelfde buurt.

De App

De app moet de verhuurder en de huurder bij elkaar brengen. In het PoC hoeft de app nog geen betaling te ondersteunen. De betaling van de huurder aan de verhuurder gebeurt dus voorlopig buiten de app om. De app dient er dus voor om huurder en verhuurder bij elkaar te brengen. De app moet er uitnodigend uitzien en een goede performance hebben. De gegevens van de huurder en verhuurder moeten beveiligd worden opgeslagen.

In de PoC hoeft nog geen 2 factor authenticatie te worden geïmplementeerd, maar in een eventueel vervolg versie moet dit wel.

De app moet op Android en IOS kunnen draaien en als het de ontwikkeling versneld, mag in de PoC ook een webpagina worden gebruikt. Die moet er dan wel uitzien als een App.

De app moet gegevens verzamelen, zodat er meer inzicht wordt verkregen in deze markt. Er moet worden vastgelegd wanneer de app wordt gebruikt en welke tijden de vraag naar een huurauto het grootst is. Ook moet er worden bijgehouden op welke tijdstippen auto's voor de verhuur worden aangeboden. Deze informatie is nodig om het prijsmodel te kunnen optimaliseren.

Web App

De web app moet de volgende functies hebben:

1. Invoeren van verhuurders informatie.
2. Zoeken naar verhuurders.
3. Lijst maken van alle verhuurders.
4. Kunnen aanpassen en verwijderen van een verhuurder.
5. De website wordt beveiligd via een login. Wachtwoorden moeten veilig worden opgeslagen.
6. Zoeken mogelijk op meerdere velden (Google-stijl).
7. Een import om verhuurders informatie in een keer importeren of te exporteren in XML of JSON.
8. Een mooie uitnodigende GUI waarin op een snelle en handige manier de beschikbaarheid per dag kan worden veranderd.
9. Systeem is volledig responsive en de interface is geoptimaliseerd voor Laptop en mobiel.

• Beheer module voor login’s met reset password.
• Extra beveiliging maken voor opslag wachtwoord door middel van hashing en salt.
• Kom met een eigen voorstel ter verbetering van de eerste versie van het product. Vraag wel goedkeuring aan de klant (docent).

Projectmedewerkers taken en verantwoordelijkheden

Je doet dit project met 2 of 3 man.

Voer je dit project met 2 man uit dan kies je minimaal 6 functionaliteiten uit de lijst. Ben je met drie man dan kies je 9 functionaliteiten.

Je bent met jou Team verantwoordelijk voor alle gekozen functionaliteiten. Je verdeelt wel de taken maar jullie worden beoordeeld op het proces en product dat jullie samen uitvoeren.

Heb je zelf een idee (punt 12), prima, maar overleg met de klant (of docent) en vraag goedkeuring.

--

Check List 2024-2025

Kerntaakexamen

Het examen bestaat uit 2 kerntaken met in totaal 8 werkprocessen.

Kerntaak-1: uitvoeren van een project (5 werkprocessen)
Kerntaak-2: samenwerken in een team (3 werkprocessen)

Voor het examen moet het ingeleverde werk aan officiële eisen voldoen. Deze zijn samengevat in de onderstaande checklist.

Kerntaak 1

Algemeen

• Gaat jouw planning, ontwerp, realisatie, testen en verbeteren over één project?
• Zijn er minimaal 3 user story's beschreven?
  Werk je samen met anderen: heeft ieder teamlid 3 unieke user story's beschreven?
• Is bij elke opdracht duidelijk wie wat heeft gedaan?
• Werk je samen met anderen: Alleen bij de planning (KT1, W1) mag één gemeenschappelijk document worden ingeleverd, alle andere documenten zijn individueel.

K1W1: Planning

1. Is er beschreven wat er gebouwd moet worden?
2. Is er beschreven waarom het gebouwd moet worden?
3. Zijn alle eisen beschreven?
4. Zijn er minimaal 3 user story's beschreven
    Werk je samen met anderen: 2 teamleden? 6 userstory's   3 teamleden? 9 userstory's  etc.
5. Staan de user story's in het formaat "als ..... wil ik ..... zodat ....."?
6. Zijn de user story's en eisen concreet en éénduidig (testbaar)?
7. Is er een takenlijst waarin alle taken staan en zijn deze project-specifiek?
8. Zijn er overleggen gepland?
9. Is bij elke taak beschreven hoe lang deze duurt?
10. Is bij elke taak beschreven wie deze moet uitvoeren?
11. Staan de taken op de juiste volgorde?
12. Zijn er prioriteiten gesteld?
13. Is de voortgang bewaakt?

K1W2: Ontwerp

1. Is elke user story uit de planning vertaald naar een ontwerp waardoor je een beeld krijgt hoe de user story er uit gaat zien?
2. Zijn er in het ontwerp tekeningen/schetsen van de User Interface te vinden?
3. Zijn er minimaal 2 schematechnieken toegepast, (bijvoorbeeld ERD, activiteitendiagram, klassendiagram, Use Case diagram)?
4. Zijn de keuzes in het ontwerp concreet onderbouwd/uitgelegd?
5. Zijn de onderwerpen ethiek, privacy en security besproken?
6. Zijn de onderwerpen ethiek, privacy en security specifiek alleen van toepassing op jouw project?

K1W3: Realisatie

1. Bevat je project code (maak je gebruik van datastructuren (variabelen, arrays....), flow control (loops), functies/methoden)?
2. Heb je minimaal 3 user story's opgeleverd?
   Werk je samen met anderen: 2 teamleden? 6 userstory's   3 teamleden? 9 userstory's  etc.
3. Heeft de realisatie (dus dit onderdeel), ongeveer 40 uur gekost?
   Werk je samen met anderen: 2 teamleden? 80 uur   3 teamleden? 120 uur etc.
   
4. Voldoet het resultaat aan het ontwerp?
5. Worden fouten in de code afgehandeld (error handling)?
6. Heb je rekening gehouden met security?
7. Is er volgens een standaard geprogrammeerd (inspringen, variabele naamgeving en dergelijke)?
8. Is de code goed leesbaar en begrijpelijk. Is er zinvol commentaar toegevoegd?
9. Heb je op een juiste manier versie beheer toegepast?
10. Videobestand(en) <= 400 MB?

K1W4: Testen

1. Zijn er per user story min. 5 testscenario's opgesteld?
2. Is bij elk testscenario concreet en eenduidig beschreven wat de beginsituatie was?
3. Is bij elk testscenario concreet en eenduidig beschreven wat de gewenste uitkomst was?
4. Zijn er alternatieve testscenario's beschreven?
5. Zijn er fouten gevonden?
6. Is elk testscenario uitgevoerd en zijn de bevindingen vastgelegd?
7. Is bij elk testscenario beschreven wat de conclusie/aanbeveling is?
8. Zijn alle scenario's concreet en eenduidig beschreven zodat er geen discussie kan ontstaan over de bevindingen?
   

AI/ChatGPT geeft vrijwel nooit concreet en eenduidige teksten!

K1W5: Verbetervoorstellen

1. Zijn er 2 of meer verbeteringen beschreven die zijn gebaseerd op de bevindingen uit het testrapport (W4)?
2. Zijn er 2 of meer verbeteringen beschreven die zijn gebaseerd op de bevindingen vanuit de oplevering?
   
3. Zijn er 2 of meer verbeteringen beschreven die zijn gebaseerd op de eigen reflectie?
4. Zijn de verbetervoorstellen eenduidig en concreet beschreven?

Kerntaak 2

K2W1: Overleggen

1. Stel je (relevante) vragen tijdens het overleg?
2. Breng jij wat mee naar het overleg, breng je bijvoorbeeld een onderwerp in?
3. Laat je zien dat je regelmatig afstemt?
4. Laat je zien dat je afspraken vastlegt?
5. Laat je zien dat je afspraken na komt?
6. Doe je actief mee met het overleg?
7. Videobestand <= 400 MB?

K2W2: Presenteren

1. Presenteer je overtuigend (positief, met passie, trots en met een goede energie)?
2. Onderbouw je je presentatie met goede argumenten?
3. Presenteer je een duidelijk verhaal?
4. Is de presentatie afgestemd op de doelgroep?
5. Stel je vragen aan de betrokkenen om te controleren of ze de presentatie begrijpen?
6. Reageer je op de juiste manier op vragen/feedback?
7. Gaat de presentatie over de stage of een ander onderwerp dat te maken heeft met het vak van software developer?
8. Videobestand <= 400 MB?

K2W3: Reflectie

1. Gaat het verslag over jouw handelen?
2. Benoem je goede punten over jouw handelen?
3. Benoem je verbeterpunten over jouw handelen?
4. Maak je onderscheid tussen jouw handelen en dat van het team waar je deel van uit maakt?
5. Beschrijf je feedback die je hebt gekregen?
   
6. Beschrijf je wat je hebt gedaan met de feedback?
7. Beschrijf je in het verslag dat jij een proactieve houding hebt (dus dat je initiatief laat zien).
8. Wees concreet (dus geen AI)!
   Teksten die je kan kopiëren en voor een (willekeurige) andere reflectie ook zouden kunnen gelden, zijn niet goed.
   Gebruik details!
   

Check List 2025 (vanaf cohort 24)

Kerntaak examens

Het kerntaakexamen heeft 8 werkprocessen verdeeld over twee kernexamens; kerntaak-1 en kerntaak-2.

Kerntaak-1 gaat over het uitvoeren van een project en kerntaak-2 gaat over het samenwerken in een team.

Voor het examen moet je aan een aantal officiële eisen voldoen. Deze zijn samengevat in de onderstaande check-list.

Kerntaak 1

Algemeen

• Gaat Kerntaak 1 (planning, ontwerp, realisatie, testen en verbeteren) over één project?
• Heeft elk persoon minimaal (liefst iets meer) 3 goede user story's op zich genomen?
• Is bij elke opdracht duidelijk wie wat heeft gedaan?
• Alleen bij de planning (KT1, W1) mag één gemeenschappelijk document worden ingeleverd, alle andere documenten zijn individueel.

Planning

1. Is er beschreven wat er gebouwd moet worden?
2. Is er beschreven waarom het gebouwd moet worden?
3. Zijn alle eisen beschreven?
   
4. Is de user story concreet en eenduidig (testbaar)?
5. Is er takenlijst waarin alle taken staan?
6. Zijn er overleggen gepland?
7. Is bij elke taak beschreven hoe lang deze duurt?
8. Is bij elke taak beschreven wie deze moet uitvoeren?
9. Staan de taken op de juiste volgorde?
10. Zijn er prioriteiten gesteld?
11. Is de voortgang bewaakt?

Ontwerp

1. Zijn de functionaliteiten vertaald naar een ontwerp waardoor je een beeld krijgt hoe de applicatie er uit komt te zien?
2. Zijn er in het ontwerp tekeningen/schetsen van de User Interface te vinden?
3. Zijn er minimaal twee schematechnieken toegepast, (bijvoorbeeld ERD, activiteitendiagram, klassendiagram, Use Case diagram)?
4. De keuzes in het ontwerp worden onderbouwd/uitgelegd?
5. Is er bij de onderbouwing rekening gehouden met de onderwerpen usability, ethiek, privacy en security?
6. Is de onderbouwing specifiek genoeg; dus niet algemeen maar specifiek voor jouw project?
   

Realisatie

1. Bevat je project code waarin je gebruik maakt van datastructuren (variabelen, arrays....), flow control (loops), functies/methods en dergelijke?
   
2. Heeft de realisatie (dus dit onderdeel), ongeveer 40 uur per persoon gekost?
3. Voldoet het resultaat aan het ontwerp?
4. Worden fouten in de code goed afgehandeld (error handling)?
5. Heb je rekening gehouden met security?
6. Is er volgens een standaard geprogrammeerd (inspringen, variabele naamgeving en dergelijke)?
7. Is de code goed leesbaar en begrijpelijk. Is er zinvol commentaar toegevoegd?
8. Heb je op een juiste manier versie beheer toegepast?

Testen

1. Zijn er per user story zijn minimaal 5 testscenario's opgesteld?
2. Is bij elk testscenario concreet en eenduidig beschreven wat de beginsituatie was?
3. Is bij elk testscenario concreet en eenduidig beschreven wat de gewenste uitkomst was?
4. Zijn er alternatieve testscenario's beschreven?
5. Zijn er fouten gevonden?
6. Is elk testscenario uitgevoerd en zijn de bevindingen vastgelegd?
7. Is bij elk testscenario beschreven wat de conclusie/aanbeveling is?
8. Zijn alle scenario's concreet en eenduidig beschreven zodat er geen discussie kan ontstaan over de bevindingen?
   

AI/ChatGPT geeft vrijwel nooit concreet en eenduidige teksten!

Verbetervoorstellen

1. Zijn er twee of meer verbeteringen beschreven die zijn gebaseerd op de bevindingen uit het testrapport (W4)?
2. Zijn er twee of meer verbeteringen beschreven die zijn gebaseerd op de bevindingen vanuit de oplevering?
   
3. Zijn er twee of meer verbeteringen beschreven die zijn gebaseerd op de eigen reflectie?
4. Zijn de verbetervoorstellen zijn eenduidig, concreet beschreven?

Kerntaak 2

Overleggen

1. Stel je (relevante) vragen tijdens het overleg?
2. Breng jij wat mee naar het overleg, breng je bijvoorbeeld een onderwerp in?
3. Laat je zien dat je regelmatig afstemt?
4. Laat je zien dat je afspraken vastlegt?
5. Laat je zien dat je afspraken na komt?
6. Doe je actief mee met het overleg?

Presenteren

1. Presenteer je overtuigend (positief, met passie, trots en met een goede energie)?
2. Onderbouw je je presentatie met goede argumenten?
3. Presenteer je een duidelijk verhaal?
4. Is de presentatie afgestemd op de doelgroep?
5. Stel je vragen aan de betrokkenen om te controleren of ze de presentatie begrijpen?
6. Reageer je op de juiste manier op vragen/feedback?
7. Gaat de presentatie over de stage of een ander onderwerp dat te maken heeft met het vak van software developer?

Reflectie

Je voldoet aan alle exameneisen als je tenminste ja kunt antwoorden op deze vragen.

1. Gaat het verslag over jouw handelen?
2. Benoem je goede punten over jouw handelen?
3. Benoem je verbeterpunten over jouw handelen?
4. Maak je onderscheid tussen jouw handelen en dat van het team waar je deel van uit maakt?
5. Beschrijf feedback die je hebt gekregen?
   
6. Beschrijf je wat je hebt gedaan met de feedback?
7. Beschrijf je in het verslag dat jij een pro-actieve houding hebt (dus dat je initiatief laat zien)

--

ChatGPT en Concreet

AI - ChatGPT

Zeker door de komst van AI zijn veel documenten niet concreet.

Er staat veel tekst, maar er wordt weinig informatie verteld.

Je kunt ChatGPT of andere LLM gebruiken, maar je moet wel zorgen dat je een concreet document maakt.

Signaalwoorden

Bijvoeglijke naamwoorden zoals

groter, sneller, slimmer, mooier, efficiënter, geavanceerder, aantrekkelijker

moeten altijd worden uitgelegd. Waarom en hoe is jouw systeem slimmer, mooier, efficiënter, .....?

Woorden als:

veilig, proactief, creatief, flexibel, aantrekkelijk, betrouwbaar, gestructureerd, praktisch, transparant

worden vaak gebruikt zonder uitleg. Waarom is jouw website veilig. Of waarom vind je dat je proactief hebt gehandeld?

Voorbeelden

• "het systeem is makkelijk om te gebruiken" - hoe dan?
• "de pagina moet overzichtelijk zijn"- hoe dan?
  
• "de sfeer moet uitnodigen tot actie, het moet gamers aanspreken" - en hoe ga je dit dan doen, hoe gaat de site eruit zien?
  
• "door de verbeterde documentatie..." - wat is er dan verbeterd?
• "de duidelijke documentatie..." - waarom was het duidelijk, op welk punt, voorbeeld?
• "Gestructureerde wijze" - wat bedoel je hier precies mee? Voorbeeld?

Niet concrete voorbeeldzinnen

• Het team gaf input en feedback, maar ik was voornamelijk verantwoordelijk voor de ontwikkeling en het onderhoud van bepaalde onderdelen van de applicatie.

Onvoldoende uitwerken

Dingen die worden genoemd, maar niet voldoende worden uitgewerkt zijn uiteindelijk ook niet concreet.

Voorbeeld ontwerp

• "er moet een zoekbalk komen" - hoe en waarnaar moet ik dan kunnen zoeken?
• "als je een wachtwoord kiest moet dat veilig zijn" - wat is een veilig wachtwoord en hoe wordt dit afgedwongen?

Voorbeeld testrapport

• "als ik een naam invoer, dan gaat dat fout" - wat gaat er precies fout, wat zie je?
• "als de gebruiker op klikt volgt er een foutmelding" - wat staat er in de foutmelding?
  

Examen Eindgesprek

Authenticiteit

Tijdens het eindgesprek wordt vooral gekeken naar de authenticiteit. Dat houdt in dat er wordt bepaald of al het werk echt door jou zelf is gemaakt.

Verbeterpunten

Als er tijdens het nakijken kleine zaken onjuist zijn of missen kan hier ook naar worden gevraagd. Het zou kunnen dat jij alsnog kan aantonen dat iets wel voldoet en je zou daarmee je score omhoog kunnen halen. Dit kan maar op enkele punten omdat niet alle 8 werkprocessen uitgebreid besproken kunnen worden.

Beperkte tijd

Je kunt overal vragen over krijgen. Meestal worden maar een paar werkprocessen bevraagd. Dat omdat er maar beperkte tijd is.

Zorg ervoor dat je jouw portfolio kan presenteren en als je al vermoed dat er zaken ontbreken, probeer je daar dan op voor te bereiden. Je code werkt dus en alle documenten heb je bij de hand!

Checklist voor het gesprek

• Laptop opgeladen, lader mee?
• (Windows) updates gedraaid?
• Software werkt allemaal (XAMPP, VSC, etc.)
• Portfolio staat klaar (dus niet ergens eerst moeten downloaden en/of unzippen)?
• Alles getest?
• ...en vergeet je ID niet!

Vragen die je kan verwachten

Maar let op, alles kan gevraagd worden, zeker als er zaken in je portfolio niet duidelijk zijn. Maar hieronder zie je een aantal vragen die regelmatig gesteld worden.

Algemeen

• Wie waren alle betrokkenen van dit project?
• Hoe verliep de samenwerking?
  
• Ben je tevreden met het eindproduct?
• Hoe lang ben je in totaal bezig geweest met het project?
• Welk onderdeel was het meeste werk?
• Wat is de belangrijkste les die je hebt geleerd?
• Welke tip zou geven aan andere studenten die dit examen moeten doen?
• Wat vond je het lastigste om te doen en waarom?

Planning

• Wie is je opdrachtgever?
• In hoeverre klopte jouw planning? Zou je achteraf gezien de planning anders hebben gemaakt?
• Staan er dingen in de planning die je niet of anders hebt uitgevoerd? Waarom?
• Heb je dingen uitgevoerd die niet in de planning staan? Waarom?
• In de planning staat dat je "abc" ging doen, kan je dat laten zien?

Ontwerp

• Op welke punten ben je van je ontwerp afgeweken en zo ja, waarom?
• Zou je achteraf gezien een ander ontwerp hebben gemaakt?
• Is het nuttig om een ontwerp te maken?
• Waarom heb je onderwerp "abc" wel/niet opgenomen in je ontwerp?
• Wat is het belangrijkste onderdeel van het ontwerp?

Realisatie

• Kan je laten zien wat je hebt gemaakt?
• Kan je user story X laten zien?
• Kan je de code van user story X laten zien?
• Welke code vond je het lastigste om te maken, kan je dat laten zien en uitleggen?
• Stel je zou de kleur van ... willen veranderen, waar in de code doe je dat dan?
• Kan je jouw database laten zien?
• Kan je laten zien waar je commentaar in de code hebt toegevoegd?
• Heb je volgens een standaard geprogrammeerd, welke?
• Kan je een oude versie van de code laten zien?

Testen

• Kan je test X uitvoeren en laten zien dat het klopt wat je in het testrapport hebt beschreven?
• Welke bevinding is het belangrijkst en waarom?

Verbeterpunten

• Kan je laten zien wat je precies bedoeld met verbeterpunt X?
• Welk verbeterpunt vind jij de belangrijkste en waarom?

Overleggen

• Kun je meer informatie geven over het filmpje?
• Hoe vaak hadden jullie overleg?
• Met wie waren jullie in overleg?
• Wat was jou rol in het overleg?
• Hoe heb jij afspraken vastgelegd en kan je dat laten zien?
• Hoe kan je aantonen dat je ook echt de afspraken bent nagekomen?
• Had je achteraf gezien meer of juist minder overleggen willen hebben, leg uit?

Presenteren

• Kan je vertellen waar en voor wie de presentatie werd gehouden?
• Hoe had jij van tevoren bedacht welk niveau en welk details jouw presentatie moest zijn?
• Kreeg je onverwachte vragen of feedback? Licht toe?
• Wat zou je een volgende keer anders doen als je weer een presentatie moest houden?

Reflectie

• Kun je meer vertellen over de feedback die je kreeg (wanneer was dat, was dat eenmalig, wie gaf je de feedback, hoe kwam het over en hoe regeerde je)?
• Wat heb jij veranderd naar aanleiding van de feedback? Kan je een voorbeeld geven van die verandering?
• Wat zijn de drie belangrijkste verbeterpunten?
• Wat is het nut van het maken een reflectie?

Examineringsproces

(naar aanleiding van calibratie-sessie 17-april 2024)

Examenafspraken Kerntaak 1 en 2:

• Alleen als alle kerntaken met een voldoende zijn beoordeeld kan een kandidaat examen doen in de vorm van een (examen)eindgesprek. 
• Het hoofddoel van het gesprek is de authenticiteitscontrole. In een enkel geval kan, indien nodig, de beoordeling worden gewijzigd. 
• De eindpresentatie wordt zoveel mogelijk beoordeeld door onafhankelijke beoordelaars (geen eigen docent, geen mentor). 
• De duur van het examengesprek is 15 minuten, met 10 minuten overhead per gesprek; 5 minuten introductie (met kandidaat) en 5 minuten nabespreken (zonder kandidaat). 
• K1W3 (realisatie) dient altijd te worden besproken. Daarnaast dient minimaal de helft van de te examineren werkprocessen worden besproken. Als richtlijn worden de volgende gesprekstijden aangehouden: K1W3  5 minuten, en andere werkprocessen elk ongeveer 2 minuten. Het totale gesprek zal, afhankelijk van het de te bespreken werkprocessen, niet meer dan 15 minuten duren, met een minimum van 5 minuten. 
• Op het beoordelingsformulier wordt aangegeven welke werkprocessen tijdens het eindgesprek zijn besproken. Eventuele aanpassing in beoordeling dient te worden toegelicht.
  

Follow-up plan: 

• Kerntaak 2 wordt uitgevoerd tijdens de eerste stage, met de herkansing tijdens de tweede stage. De beoordeling van deze kerntaak vindt plaats op school. 
• De BPV-begeleider initieert het contact met het (leer)bedrijf en controleert of de te examineren werkprocessen uitvoerbaar zijn. Het (leer)bedrijf wordt geïnformeerd over hun rol bij de examinering op de werkplek. 
• Er komt een nieuwe onderlegger speciaal voor de beoordeling van de kerntaken. 

 

Examen Rubics

Examen Rubics

Portfolio-examen SPL Rubics  SD_SD20_PF1_B1-K1-K2_2v1.

K1W1 - Planning

1. De uitgangspunten zijn juist verwerkt (Definition of done) en de eisen en wensen zijn verwerkt in de user stories.
   
2. De user stories voldoen aan de criteria (wie, wat, waarom en realistisch).
   
3. Op basis van de user stories is een complete en realistische planning gemaakt.
4. De voortgang is bewaakt en de juiste keuzes/afwegingen zijn gemaakt op basis van prioriteiten.
   

K1W2 - Ontwerp

1. De user stories zijn vertaald naar een passend, eenduidig en volledig ontwerp (sluit aan op wensen en eisen).
   
2. Er is gebruik 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, waarbij rekening is gehouden met bijv. ethiek, privacy en security.
   

K1W3 - Realisatie

1. Er is voldoende inhoud van de user stories gerealiseerd binnen de gestelde/geplande tijd.
2. De opgeleverde functionaliteiten voldoen aan de eisen en wensen.
3. De kwaliteit van de code is goed. Dit uit zich onder andere in: structuur van de code, validatie, efficiëntie, foutafhandeling en terugkoppeling, security (veilig programmeren). 
4. De code is opgesteld volgens code conventions.
5. De code is verzorgd, leesbaar, gestructureerd en voorzien van zinvol commentaar.
6. Versiebeheer is effectief toegepast.

K1W4 - Testen

1. De testcases in het testplan sluiten aan op de user stories en bevatten alle scenario's.
2. De stappen, het gewenste resultaat en testdata zijn benoemd. Niet alleen het hoofdscenario, maar ook alternatieve scenario's. 
3. De stappen, het gewenste resultaat en testdata zijn benoemd. Niet alleen het hoofdscenario, maar ook alternatieve scenario's. 

K1W5 - Verbeteren

1. De juiste verbetervoorstellen zijn gedaan vanuit het testen.
2. De juiste verbetervoorstellen zijn gedaan vanuit de oplevering.
3. De juiste verbetervoorstellen zijn gedaan vanuit de reflectie.

K2W1 - Overleggen

1. De kandidaat neemt actief deel waarbij relevante onderwerpen worden ingebracht en de juiste vragen worden gesteld.
2. De kandidaat stemt regelmatig en tijdig af met projectteamleden en opdrachtgever over de voortgang en eventuele knelpunten.
3. De gemaakte afspraken zijn eenduidig vastgelegd.
4. De kandidaat houdt zich aan gemaakte afspraken.

K2W2 - Presenteren

1. De kandidaat presenteert een overtuigend, duidelijk, beargumenteerd verhaal, afgestemd op de doelgroep.
2. De kandidaat stelt gerichte vragen om te controleren of de betrokkenen goed geïnformeerd zijn over het opgeleverde werk.
3. De kandidaat reageert adequaat op feedback.

K2W3 - Reflectie

1. De kandidaat benoemt  zowel positieve als verbeterpunten van het proces van zowel eigen als teamprestaties.
2. De kandidaat reageert adequaat op de ontvangen feedback.
3. De kandidaat heeft een proactieve houding tijdens reflectiemeetings.

--

Examen Rubics 2024 v 2023

Portfolio-examen SPL Rubics  SD_SD20_PF1_B1-K1-2_3v1.

Kerntaak 1

K1W1 - Planning

Nieuw

1. De uitgangspunten, technische en functionele eisen en wensen zijn bepaald en gedocumenteerd.
   • De eisen zijn zodanig concreet beschreven dat een objectieve buitenstaander kan bepalen wanneer het project klaar is.
2. Op basis van de functionaliteit is een complete en realistische planning gemaakt.
   • In de planning komen de user stories terug.
   • De planning is realistisch volgens professionele inschatting.
   • Planning is consistent (ruim of krap) en de tijdsaanduiding is eenduidig (dus bijvoorbeeld in uren).
   • De taken zijn voldoende fijnmazig. Richtlijn: in uren of dagdelen.
3. De gestelde doelen en planning zijn bewaakt.

Oud

1. De uitgangspunten zijn juist verwerkt (Definition of done) en de eisen en wensen zijn verwerkt in de user stories.
   
2. De user stories voldoen aan de criteria (wie, wat, waarom en realistisch).
   
3. Op basis van de user stories is een complete en realistische planning gemaakt.
4. De voortgang is bewaakt en de juiste keuzes/afwegingen zijn gemaakt op basis van prioriteiten.

Beoordeling

1. Opdracht, doelen en planning zijn afgestemd
2. Voorgang is bewaakt
3. Reageert op afwijkingen

Verandering

1. User story's zijn niet meer verplicht
2. Beoordeling anders; is minder concreet en punt 'reageert op afwijking' is erbij.

K1W2 - Ontwerp

Nieuw

1. De eisen en wensen zijn vertaald naar een passend, eenduidig en volledig ontwerp.
2. Er is gebruik gemaakt van relevante of toepasselijke schematechnieken (bijv. activiteitendiagram, klassendiagram, ERD, use case diagram).
   • Minimaal 2 goede schematechnieken die inhoudelijk voor het grootste gedeelte (80%) inhoudelijk juist zijn.
3. De gemaakte keuzes in het ontwerp zijn onderbouwd met steekhoudende argumenten, waarbij rekening is gehouden met haalbaarheid, privacy en security.
   • Er wordt uitgelegd waarom keuzes zijn gemaakt en twee van de vier onderwerpen (ethiek, privacy, security en useability) worden daarbij besproken.

Oud

1. De user stories zijn vertaald naar een passend, eenduidig en volledig ontwerp (sluit aan op wensen en eisen).
   
2. Er is gebruik 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, waarbij rekening is gehouden met bijv. ethiek, privacy en security.

Beoordeling

1. Eisen, wensen zijn eenduidig vastgelegd
   
2. Schematechnieken
3. Onderbouwing

Verandering

1. User story's zijn niet meer verplicht
2. Beoordeling is ongewijzigd.

K1W3 - Realisatie

Nieuw

1. Er is voldoende inhoud van de functionaliteit gerealiseerd binnen de gestelde/geplande tijd.
   
   • Er is minimaal 40 uur (netto) aan de realisatie gewerkt.
2. De opgeleverde functionaliteiten voldoen aan de eisen en wensen.
   • De user stories en eisen en wensen zijn voor minimaal 80% gerealiseerd. Eventuele afwijkingen zijn gedocumenteerd in de planningsvoortgang.
3. De kwaliteit van de code is goed.
   • Code bevat eigen toegevoegd commentaar.
   • Identation (inspringen) van code is correct.
   • Naamgeving van variabelen, objecten en functies is consistent.
4. Versiebeheer is effectief toegepast.
   • Er zijn ten minste 3 oude versies van het project aanwezig. Deze versies moeten de geschiedenis van de code laten zien. (dus 3 versies die allemaal van één dag zijn is niet goed).

Oud

1. Er is voldoende inhoud van de user stories gerealiseerd binnen de gestelde/geplande tijd.
2. De opgeleverde functionaliteiten voldoen aan de eisen en wensen.
3. De kwaliteit van de code is goed. Dit uit zich onder andere in: structuur van de code, validatie, efficiëntie, foutafhandeling en terugkoppeling, security (veilig programmeren). 
4. De code is opgesteld volgens code conventions.
5. De code is verzorgd, leesbaar, gestructureerd en voorzien van zinvol commentaar.
6. Versiebeheer is effectief toegepast.

Beoordeling

1. Gerealiseerde functionaliteiten
   
2. Kwaliteit (voldoet aan eisen en wensen)
   
3. Kwaliteit
4. Versiebeheer

Verandering

1. User story's zijn niet meer verplicht.
2. Kwaliteit van de code is één punt (geen code conventies meer).
   
3. Beoordeling op minderpunten omdat kwaliteit v. code en code conventies eruit, dus meer nadruk op functionaliteiten.
4. Omdat er meer naar de opgeleverde code wordt gekeken is dit lastiger te halen met weinig opgeleverde functionaliteit (WP sites zijn nog lastiger).

K1W4 - Testen

Nieuw

1. De testcases in het testplan sluiten aan op de functionaliteit en bevatten alle scenario's.
   • Er zijn minimaal 5 scenario's nauwkeurig beschreven. Per test zijn 3 variaties beschreven. Er worden dus minimaal 15 testen uitgevoerd.
2. De kandidaat heeft voor alle toegewezen of geplande functionaliteit testscenario's of testcases gemaakt.
   • Alle functionaliteiten worden door de testen 'geraakt'.
3. De kandidaat voert de testactiviteiten correct en volgens het testplan uit. 
4. Het testrapport bevat testresultaten van alle functionaliteiten. Alle resultaten worden voorzien van de juiste conclusies.
   

Oud

1. De testcases in het testplan sluiten aan op de user stories en bevatten alle scenario's.
2. De stappen, het gewenste resultaat en testdata zijn benoemd. Niet alleen het hoofdscenario, maar ook alternatieve scenario's. 
3. De stappen, het gewenste resultaat en testdata zijn benoemd. Niet alleen het hoofdscenario, maar ook alternatieve scenario's. 

Beoordeling

1. Er moet een testvorm of methodiek zijn gekozen.
   
2. Alles is getest
   
3. Resultaten zijn beschreven
   
4. Er is een testplan en ene testrapport, die aan dezelfde eisen voldoen...?
   

Verandering

1. User stories zijn er uit.
2. Testplan moet alles omvatten.
3. Uitvoering is apart punt (weegt zwaarder).
4. Conclusies zijn niet meer verplicht.

K1W5 - Verbeteren

Nieuw

1. Analyseert systematisch alle beschikbare informatiebronnen voor mogelijke aanpassingen aan de software.
2. Interpreteert en vertaalt wensen, reacties, testresultaten en/of meldingen naar realiseerbare verbetervoorstellen.
3. Stelt vast welke werkzaamheden benodigd zijn, evenals een haalbare planning. 

Oud

1. De juiste verbetervoorstellen zijn gedaan vanuit het testen.
2. De juiste verbetervoorstellen zijn gedaan vanuit de oplevering.
3. De juiste verbetervoorstellen zijn gedaan vanuit de reflectie.

Beoordeling

1. Analyse voor aanpassingen door gebruik te maken van bronnen.
   
2. Verbetervoorstellen
   
3. Planning

Verandering

1. Onderscheid tussen de bronnen minder relevant.
2. Verbetervoorstellen dienen realiseerbaar te zijn.
3. Planning voor verbetervoorstellen.
4. Er worden bronnen geraadpleegd om tot goede verbetervoorstellen te komen.

Kerntaak 2

K2W1 - Overleggen

Nieuw

1. De kandidaat neemt actief deel aan het overleg waarbij relevante onderwerpen worden ingebracht en de juiste vragen worden gesteld. 
2. De kandidaat stemt regelmatig en tijdig af met projectteamleden en opdrachtgever over de voortgang en eventuele knelpunten.
3. De gemaakte afspraken zijn eenduidig vastgelegd.
4. De kandidaat houdt zich aan gemaakte afspraken.
   

Oud

1. De kandidaat neemt actief deel waarbij relevante onderwerpen worden ingebracht en de juiste vragen worden gesteld.
2. De kandidaat stemt regelmatig en tijdig af met projectteamleden en opdrachtgever over de voortgang en eventuele knelpunten.
3. De gemaakte afspraken zijn eenduidig vastgelegd.
4. De kandidaat houdt zich aan gemaakte afspraken.

Beoordeling

1. 
   

Verandering

Geen.

K2W2 - Presenteren

Nieuw

1. De kandidaat legt de functionaliteiten uit met een goed opgebouwd en met argumenten onderbouwd verhaal.
2. De kandidaat stemt de stijl van communiceren en de presentatiemiddelen af op de toehoorders.
3. De kandidaat beantwoordt vragen met steekhoudende argumenten. 

Oud

1. De kandidaat presenteert een overtuigend, duidelijk, beargumenteerd verhaal, afgestemd op de doelgroep.
2. De kandidaat stelt gerichte vragen om te controleren of de betrokkenen goed geïnformeerd zijn over het opgeleverde werk.
3. De kandidaat reageert adequaat op feedback.

Beoordeling

 

Verandering

1. Presentatie gaat over project.
2. Geen verplichte vragen meer tijdens presentatie.
3. Geen beoordeling op de reactie op feedback.
4. Vragen worden beantwoord én onderbouwd.

K2W3 - Reflectie

Nieuw

1. De kandidaat benoemt zowel positieve- als verbeterpunten van het proces van zowel eigen als teamprestaties.
2. De kandidaat reageert actief op ontvangen feedback

Oud

1. De kandidaat benoemt  zowel positieve als verbeterpunten van het proces van zowel eigen als teamprestaties.
2. De kandidaat reageert adequaat op de ontvangen feedback.
3. De kandidaat heeft een proactieve houding tijdens reflectiemeetings.

Beoordeling

 

Verandering

1. Meetings zijn niet meer van toepassing.

--