K1 Software maken

• K1 W1 Planning
• K1 W2 Ontwerp
• K1 W3 Realisatie
• K1 W4 Testen
• K1 W5 Verbeteren

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).

--