# Examentraining B1-K1 # B1-KT1 - Op te leveren *De templates voor de documenten staan hiernaast. Hieronder staan wat er in de documenten moet staan.* ### Overzicht
KerntaakWatKern
B1-K1-W1Goedgekeurd PvEUse Cases
B1-K1\_W2Realistische Planning (Projectplan)Planning
B1-K1-W3Functioneel OntwerpSchermen (Site-map - Wireframes)
Technisch OntwerpFlow diagram en ERD
B1-K1-W4OntwikkelomgevingWerkende ontwikkelomgeving
Documentatie OntwikkelomgevingConfiguratie ontwikkelomgeving
### Algemeen Elk document begint met: **Documentnaam**
Naam leerling Max Bisschop
Leerlingnummer 999
Datum 28 september 2019
Versie 1.0 1ste versie, 22 septembet 2019
Versie 2.0aangepast na klantbespreking van 26 septmeber
Het document heeft **paginanummers** en voor lange documenten maak je een **inhoudsopgave** (kan automatisch in Word). Vervolgens dien je alle **paragrafen** zoals hieronder is beschreven op te nemen. ### 01 Programma van Eisen
ParagraafOmschrijving
Inleiding... heeft ons gevraagd om een Applicatie te ontwikkelen. Dit document beschrijft de wensen van ...en dient als input voor het meer gedetailleerde projectplan
BedrijfKorte omschrijving van het bedrijf. Benoem het primaire bedrijfsprocess waarvoor de applicatiewordt ontwikkeld.
AanleidingBeschrijf de reden; wat wil de opdrachtgever bereiken?
DoelgroepenVoor wie is de applicatie; alle groepen benoemen.
User Stories / Overzicht functionaliteitenEen complete lijst met use cases (in tekst).
OverigSecurity, beperkingen, aanvullende eisen
### 02 Projectplan
ParagraafOmschrijving
InleidingDit projectplan geeft een gedetailleerd overzicht van alle activitieten die moeten worden uitgevoerd voor de ontwikkeling en oplevering van .....
ProejctdoelstellingKort en SMART. Kijk ook naar de aanleiding uit het PvE
Project betrokkenenNoem iedereen die aan het project meewerkt. Benoem naam en rol. Rollen zijn: , projectleider, opdrachtgever, gebruikersgroep, developer, tester,...
BenodigdhedenWat heb je nodig voor de uitvoering van het project? In in ieder geval werkende ontwikkelomgeving, FO, TO, ...
Takenlijst PlanningZie complete lijst....
ProjectgrenzenWat doen we niet; wat valt buiten het project.
### 03 Functioneel Ontwerp
ParagraafOmschrijving
InleidingHet functioneel ontwerp is een gedetailleerde beschrijving van de applicatie ..... Het ontwerp zal worden afgestemd met ...
RollenBenoem de rollen nog een keer (die volgen uit de use cases)
Site-Map / NavigatiestructuurHoe kan je door de applicatie navigeren. Dit komt overeen met de menu-strucuur. Zie voorbeeld.
Standaard Lay-outWire Frame van de *standaard* scherm-layout, zie voorbeeld
Eén of twee schermen uittekenenMock-up of wire frame, zie voorbeelden.
SchermbeschrijvingKorte omschrijving van *alle* schermen (waarvoor dent hetscherm?) en *alle* invoer- en uitvoervelden benoemen. Benoem ook wie (rollen) het scherm kan gebuiken.
FunctionaliteitenUse Cases (PvE) - Schermen relatie
### 04 Technisch Ontwerp
ParagraafOmschrijving
Inleiding
Applicatie Componenten OverzichtCliënt, Web Server (PHP Laralvel), Database Server
ApplicatieflowDit is een process flow van de use cases. Werk in inder geval de complexere use cases uit. Zie voorbeeld.
Database StructuurDatabase diagram (bijv uit phpmyadmin)
### 05 Documentatie Ontwikkelomgeving
ParagraafOmschrijving
Inleiding
Hardware benodigdhedenGeef aan welke hardware benogdheden je nodig hebt
Software benodigdhedenMaak een lijst van alle software benodigdheden inclusief versies; PHP, Laravel, Node.js, Vue.js, bootstrap, database, OS, ...)
ConfiguratieBelangrijke (afwijkende) configuratie. Denk ook aan development specifieke zaken zoals debugging, error messages, root login.
TestenBeschrijf een aantal stappen die je moet nemen om alles te testen
### Voorbeelden #### Activiteitenlijst (TO)
ActiviteitToelichting
Projectplan schrijvenBij kleinere projecten kun je deze drie stappen ook samenvoegen
Projectplan bespreken
Projectplan aanpassen
Functioneel Ontwerp schrijvenBij kleinere projecten kun je deze drie stappen ook samenvoegen
Functioneel Ontwerp bespreken
Functioneel Ontwerp aanpassen
Technisch Ontwerp schrijvenBij kleinere projecten kun je deze drie stappen ook samenvoegen
Technisch ontwerp doorspreken met developers
Database ontwerp en opzetten
Ontwikkelomgeving inrichten
Ontwikkelomgeving documenteren
Development 1Deel dit op in stukken. het liefst in stukken die je ook kunt weglaten
Development 2zodat de klant kan kiezen en kan prioriseren.
Development 3
Design CSS en graphicsIndien nodig - als het eenvoudig blijft kun je dit natturlijk weglaten.
Technische testJe moet alle functionaliteiten een keer samen testen
Bugs oplossen10%-20% van de development tijd.
Opleveren aan klant in acceptatie omgeving ofPlaats je de applicatie in een aparte omgeving waar de klant kan testen
Tonen aan klantof geef je een demo aan de kant?
Feedback van klant verwerken
Opleveren naar productieOverzetten van code naar productie-omgeving
Config aanpassen naar productieaanpassen van logging, error messages, db login, etc.
Acceptatietest klantdit zijn geen uren die je in rekening kunt brengen maar zijn wel uren die de klant moet investeren.
Bugs oplossen
Opleveren alle documentatie en afrondingDit is meer alles verzamalen en opsturen en formeel project afronden door de klant te vragen of alles akkoord is.
#### Standaard Scherm Lay-out (FO) ![](https://www.roc.ovh/uploads/images/gallery/2019-10/scaled-1680-/image-1571911483027.png) #### Site-Map / Navigatiestructuur (FO) ![](https://www.roc.ovh/uploads/images/gallery/2019-10/scaled-1680-/image-1571911618325.png) ![](https://www.roc.ovh/uploads/images/gallery/2019-10/scaled-1680-/image-1571912904669.png) #### Mock-up of wire frames (FO) ![](https://www.roc.ovh/uploads/images/gallery/2019-10/scaled-1680-/image-1571911803434.png) ![](https://www.roc.ovh/uploads/images/gallery/2019-10/scaled-1680-/image-1571911778252.png) #### Applicatie flow (TO) ![](https://www.roc.ovh/uploads/images/gallery/2019-10/scaled-1680-/image-1571912667103.png) ![](https://www.roc.ovh/uploads/images/gallery/2019-10/scaled-1680-/image-1571912721718.png) # Beschrijving B1-K1 ### B1-K1 Levert een bijdrage aan het ontwikkeltraject #### B1-K1-W1: Stelt de opdracht vast ##### Resultaat 1. Een door de opdrachtgever goedgekeurde opdracht waarin de beschikbare informatie, de eisen en behoeften van de opdrachtgever zijn verwerkt (programma van eisen). ##### Vraaggesprek - (v) Je stelt je voor. - (v) Je leidt het gesprek en vertelt wat het doel van het gesprek is. - (i) Je stelt de voorbereide vragen. - (i/v) Je luistert naar wat de klant zegt en gaat in op wat de klant zegt en vraagt door. - (v) Je vat steeds samen wat de opdrachtgever gezegd heeft. - (i) Je geeft gevraagd en ongevraagd advies. - (v) Je spreekt begrijpelijk (geen vaktaal). - (v) Je spreek duidelijk en verstaanbaar. - .(v) Je vertelt aan het einde van het gesprek wat de verdere procedure is. - (v) Je maakt aantekeningen. - (v) Je stelt je klantvriendelijk op tijdens het gesprek. (LSD) ##### Programma van Eisen - Inhoud - Vorm - Onderbouwing #### Beoordeling
Voorbereiding1
Gespreksvorm3
Gespreksinhoud3
Inhoud Programma van Eisen3
Vorm Programma van Eisen3
Onderbouwing3
Toelichting en om goedkeuring vragen1
Voldoende bij 9 punten (van de 17) of meer plus voldoende eisen in Programma van Eisen. #### Beoordeling PvE
HoodstukWatPunten
InleidingGlobale omschrijving3
Doel van document3
BedrijfCore Business benoemen3
Bedrijfsprocessen die van belang zijn voor dit project3
AanleidingWaarom een nieuwe applicatie?3
Hoe werkt het nu?3
Wat betekent het invoeren van een nieuwe app voor de medewerkers?3
DoelgroepenZo specifiek mogelijk, dus niet *medewerker*, maar bijv. *administratief medewerker*.6
FunctionlaiteitenBeschrijf deze per doelgroep25
SecurityLogin/publlieke toegang,...6
Aanvullende eisenDit zijn vaak de eisen die niet wordne benoemd maar die worden verondersteld.6
BeperkingenDit zijn ook vaak eisen die worden verondersteld maar die expliciet niet worden uitgevoerd. Denk bijvoorbeeld aan browser-ondersteuning.6
AlgemeenBeschrijf *geen* vaagheden: we zouden een ... kunnen implementeren (Eventuele vragen apart benoemen).8
Zakelijk net taalgebruikt.6
Goed Nederlands.6
Alles ziet er netjes uit (dus bijv. geen template-aanwijzigingen meer laten staan).5
Op tijd ingeleverd (elke dag te laat -1 punt)5
TOTAAL 100
--- #### B1-K1-W2: Levert een bijdrage aan het projectplan ##### Resultaat 1. Een realistische planning (inclusief voortgangsgesprekken) voor de realisatie van de applicatie, media-uiting of game. ##### Projectplan ##### Geeft toelichting op projectplan aan projectleider #### Beoordeling (Dit zijn de globale beoordelingscriteria '18 en vorig)
Projectdoelstellingen en risico's30%
Project activiteiten30%
Planning30%
Afstemmen10%
Voldoende bij 5 punten of meer. ('19 en volgende) #### Beoordeling Projectplan
HoodstukWatPunten
InleidingGlobale omschrijving1
Doel van document1
ProjectdoelstellingenBeschrijf zo [SMART](http://www.carrieretijger.nl/functioneren/management/leidinggeven/doelen-stellen/smart) mogelijk wanneer dit project een succes is. Wees concreet/specifiek, meetbaar, haalbaar, realistisch en tijdgebonden. Dus **niet**: de website moet er mooi uit zien.20
Leden projectgroep / de betrokkenenWie zijn er betrokken, noem, namen en rollen. Rollen die in ider geval van belang zijn, zijn: informatie-analyst (FO), projectledeider, opdrachtgever, gebruikers (wees specifiek), testers (wees specifiek), developers.5
RandvoorwaardenBenodigdheden: beschikbaarheid van resources (mensen en midellen), zoals hardware, netwerk, werkplek (als je op locatie gaat ontwikkelen), bepaalde input, ....)10
Takenlijst/PlanningWees zo specifiek mogelijk, zie template. Je wordt beoordelen op een reeele planning en een complete takenlijst. Groet taken opdelen in kleinere taken; er moet een evenwichtige verdeling uitkomen: dus *niet* 1, uur, 1 uur en 2 weken. 30
Risico'sZie template15
ProjectgrenzenDeze volgen meestal uit de 'beperkingen' uit het PvE5
AlgemeenZakelijk net taalgebruikt.5
Goed Nederlands.5
Alles ziet er netjes uit (dus bijv. geen template-aanwijzigingen meer laten staan).3
TOTAAL 100
#### B1-K1-W3: Levert een bijdrage aan het ontwerp ##### Resultaat 1. Een bijdrage aan het ontwerpdocument. ##### Versie 1 Functioneel Ontwerp - Inleiding - Navigatie-site map - Lijst van alle pagina's - Paginaontwerp - Grafische stijl Bepspreken Functioneel Ontwerp Opdrachtgeven/Projectleider. Maak 2de versie Functioneel Ontwerp #### Beoordeling
Functionaliteiten zijn beschreven met priorisering3
Schematechnieken, wireframe, sitemap,...3
GUI met saemnhang tussen schermen3
Toelichting en om toestemming vragen3
Voldoende bij 6 punten of meer plus alle functionaliteiten (uit PvE) dienen te zijn beschreven. #### B1-K1-W4: Bereidt de realisatie voor ##### Resultaat 1. De realisatie is voorbereid en startklaar. 2. De ontwikkelomgeving is ingericht volgens de geldende regels, procedures en conform de ontwerpen. 3. De documentatie m.b.t. de inrichting van de ontwikkelomgeving is in orde. 4. Document Ontwikkelomgeving 5. Alle benodigde software voor de ontwikkelomgeving is correct geïnstalleerd, geconfigureerden getest. #### Document met beschrijving ontwikkelomgeving #### Ontwikkelomgeving geinstalleerd en getest #### Beoordeling
Benodigde hard- en software volledig beschreven3
Ontwikkelomgeving juist geinstalleerd en geconfigureerd1
Ontwikkelomgeving is getest1
Documentatie is correct en volledig1
Voldoende bij test waaruit blijkt dat alles werkt en minimaal 3 punten. \-- # Case 'Project Kinderopvang' ### Project Kinderopvang Je bent als applicatieontwikkelaar werkzaam bij internetbedrijf FastDevelopement. Dit bedrijf maakt in opdracht maatwerk (web)applicaties voor haar opdrachtgevers. Aan jou is gevraagd een webapplicatie te ontwikkelen voor de administratie van Kinderopvang Klavertje Vier. Kinderopvang Klavertje Vier is een kinderdagverblijf (KDV) gevestigd in Diemen Noord, die de opvang verzorgt voor 0 tot 4 jarigen. Ouders brengen hun kinderen wekelijks 1 of meer dagen naar het KDV. Er zijn momenteel drie groepen, Ioor, Kanga en Poeh. Per groep is ruimte voor maximaal 10 kinderen en per groep zijn 2 leidsters. Ouders hebben per kind een contract met het KDV waarop staat op welke weekdagen zij hun kind brengen. Indien een ouder een contract wil voor meer dagen per week en er is geen plek vrij, dan komt dat kind voor die dag(en) op de wachtlijst. Indien er een plek vrij komt, dan hebben deze kinderen voorrang boven nieuwe kinderen. Onlangs is er veel nieuwbouw in de buurt gerealiseerd. Hier zijn veel jonge gezinnen komen wonen. Hierdoor is de vraag naar kinderopvang dermate toegenomen dat het bestuur van Klavertje Vier heeft besloten om een extra groep te starten. Deze uitbreiding heeft ook geleid tot een toename van het administratieve werk. Om de administratie efficiënt te laten verlopen heeft het bestuur besloten om hiervoor een webapplicatie te laten ontwikkelen. Directeur Boris Brand van Klavertje Vier heeft de volgende aanvraag bij FastDevelopement ingediend: Wij hebben behoefte aan een webapplicatie waarmee we op eenvoudige wijze de administratie van het kinderdagverblijf kunnen bijhouden. Deze applicatie moet ons de volgende functionaliteit bieden: - - Een alfabetische lijst van alle kinderen van het KDV met voornaam, achternaam, geboortedatum, naam van de ouder en telefoonnummer en bijzonderheden. - Een weekoverzicht met per dag welke kinderen verwacht worden. - Een weekoverzicht met per dag welke kinderen naar het KDV komen: Kinderen worden in principe op de afgesproken dagen naar het KDV gebracht, maar ze komen niet als ze ziek zijn of op vakantie zijn. In dat geval kan een ouder hun kind een extra dag brengen. Een extra dag brengen is bestemd voor de kinderen die in de afgelopen tijd een of meer dagen gemist hebben omdat zij ziek waren of op vakantie. - Eens per kwartaal een uitdraai van de nota’s volgens de bijlage. Hierop worden de contractueel vastgelegde aantal dagen in rekening gebracht. - Een uitdraai van de wachtlijst. Op de wachtlijst staan de reeds geplaatste kinderen (die meer dagen willen) en nieuwe kinderen die nog niet op het KDV zitten # W1 Opdracht vaststellen; gesprek en PvE (1.0) Doel van dit werkproces is onderzoeken en vaststellen wat de wensen en eisen van de klant zijn, en dit af te stemmen. Dit dient als input voor de projectplanning waarin een urenschatting en/of kostenraming staat. #### Wat moet je doen? 1. Je ontvangt een globale beschrijving van het project en soms ook voorbeeldrapportages die de applicatie moet kunnen produceren. Analyseer deze informatieen probeer je voor te stellen wat hoe de applicatie er uit moet gaan zien. 2. Is de beschrijving onduidelijk, of ontbreekt er informatie? Noteer dat dan in de vorm van een vragenlijst die je gebruikt voor het gesprek met de opdrachtgever. 3. Je voert een gesprek met de opdrachtgever om alle eisen waaraan de applicatie moet voldoen, duidelijk te krijgen. (zie volgende pagina hoe dat gesprek wordt beoordeeld). Tijdens het gesprek noteer jede extra informatie die je van de opdrachtgever krijgt. 4. Na het gesprek kun je (als het goed is) document “Programma van Eisen”maken. 5. Dit documentbespreekje kort met de opdrachtgever en je laat het goedkeuren. #### Doel van het Programma van Eisen In het Programma van Eisen staat aan welke eisen de applicatie moet voldoen. Je verwerkt in dit document alleaangeleverde informatie van het startdocument (opdracht van klant), voorbeeldrapportages en alles wat de opdrachtgever tijdens het gesprek met je heeft besproken. De opdrachtgever moet het eens zijn met de inhoud van dit document. Het document Programma van Eisen is het uitgangspunt voor het projectplan en later voor het ontwerp en de realisatie van de applicatie. Je dient de [template Programma van Eisen](http://www.roc.ovh/attachments/1) te gebruiken. Je bent vrij om zelf hoofdstukken/kopjes toe te voegen. Doe dit als dit ten geode komt aan de inhoud of de opbouw van het verhaal. Je kunt ervoor kiezen om enkelen details in het PvE op te nemen die misschien in het Functioneel ontwerp thuis zouden horen. Dit doe je dan vooral om de klant te laten zien dat je goed hebt geluisterd. Ga hierin ook weer neit te ver. Eisen voor het Programma van Eisen 1. Het document heefteen titelblad, een inhoudsopgaveen de pagina’s zijn genummerd. 2. Het taalgebruik is zakelijk en begrijpelijk voor niet-vakgenoten. 3. Minimaal alle gevraagde onderdelen zijn beschreven. ##### Het gesprek 1. (v) Je stelt je voor. 2. (v) Je leidt het gesprek en vertelt wat het doel van het gesprek is. 3. (i) Je stelt de voorbereide vragen. 4. (i/v) Je luistert naar wat de klant zegt en gaat in op wat de klant zegt en vraagt door. 5. (v) Je vat steeds samen wat de opdrachtgever gezegd heeft. 6. (i) Je geeft gevraagd en ongevraagd advies. 7. (v) Je spreekt begrijpelijk (geen vaktaal). 8. (v) Je spreek duidelijk en verstaanbaar. 9. .(v) Je vertelt aan het einde van het gesprek wat de verdere procedure is. 10. (v) Je maakt aantekeningen 11. (v) Je stelt je klantvriendelijk op tijdens het gesprek Gebruik de gesprekstechniek *Luisteren - samenvatten - doorvragen, let op met oordelen en laat advies geen oordeel zijn.* ##### Luisteren knikken, hummen en oogcontact. ##### Samenvatten als ik het goed begrijp dan wil je dus...... ##### Doorvragen let op aannames, vaagheden, meningen en tegenstrijdigheden, voorbeelden: - "het zou mooi zijn als de banner er echt springt", dit is vaag en is een soort mening. - "ik vind de meeste websites saai", ook dit is vaag en wat betekent dit voor de eisen voor de nieuwe web site? - "Printen hoeven we het niet over te hebben, wnat dat wordt door de browser toch wel ondersteund", dit is een aanname, is dat echt wel zo? - "Mijn site moet super goed beveileig zijn, ik wil echt wachtwoorden van 30 willekeurige karakters.*",* hier kan ene tegenstrijd in zitten want niemand onthoud zo'n wachtwoord en waarschijnlijk wordt die dus opgeschreven. *[Assumptions is the mother of al fuck-ups](https://www.youtube.com/watch?v=PbPa3MGlVS8 "Filmpje")* ### Beoordeling Erg belangrijk om te weten is, hoe je wordt beoordeeld. Je krijgt punten voor de volgende onderdelen
OnderdeelAantal punten
Voorbereiding1
gespreksvorm3 = aantal (in)(v's/9)
gespreksinhoud3 = aantal i's
inhoud PvE\*)3
vorm PvE3
onderbouwing3
toelichting en om goedkeuring vragen1
**TOTAAL**17
Let op als er te veel eisen ontbreken in het PvE dan wordt er een onvoldoende gegeven. Goed haal je bij 14 punten of meer Voldoende haal je bij 9 punten of meer Onvoldoende haal je bij 8 punten en minder. Tevens kan er een onvoldoende worden gegeven wanneer één van de onderdelen ver beneden de maat is, voorbeelden: je scheldt de klant uit, je hebt niets voorbereid en zelfs de opdracht niet doorgelezen, er ontbreken te veel eisen in het PvE.

De beschreven beoordelingsstructuur en normering in dit document is gebasseerd op oude examens en één en ander zou in toekomstige examens hiervan kunnen afwijken.

# Vraaggesprek - Uit de praktijk ### Vragen (uit de praktijk) - Vergeet niet de project specifieke vragen, zijn er onduidelijkheden in de opdracht? Doe geen (of zo min mogelijk) aannames! - Wie (wie in welke rol) gaat het systeem gebruiken? - Van elke rol, wat is de input en/of output - Zijn er andere programma’s of Databases waarmee het programma moet samenwerken; email systeem, single sign-on? - Zijn er andere technische randvoorwaarden (taal, platform; Unix of Windows)? - Zijn er speciale eisen ten aanzien van continuïteit (wat gaat er mis als het system even niet werkt)? - Wat zijn de eisen ten aanzien van gebruikersaantallen, performance en schaalbaarheid? - In welke omgeving gaat het system draaien; beveiligd intranet of op internet. Let ook op als je op de applicatie op ene intranet gaat draaien dan heb je niet zomaar toegang tot internet en dat beperkt dan bepaalde mogelijkheden zoals online CSS. - Als het systeem op internet gaat draaien; waar bij welke hosting partij, wie regelt dat en zijn er specifieke eisen die de hosting partij stelt? - Is er naar alternatieven (denk ook aan Excel) gekeken, zo ja naar welke en waarom zijn deze afgevallen? - Hoe wordt het process tot nu toe uitgevoerd, op papier? Kan ik dat zien? - Moeten gebruikers aanloggen, zo ja hoeveel rollen zijn er? - Voorbeelden, op papier? - Zijn er eisen of wensen ten aanzien van de planning of budget? - Wat zijn de kei-harde eisen en zijn er ook 'nice to have's'? - Hoe en wie gaat het systeem onderhouden? Wat zijn de eisen ten aanzien van onderhoud aan de applicatie? ### Tips uit de praktijk voor gesprek Zet alle vragen op papier. Probeer in een *natuurlijk process* alle vragen te stellen. Een goede eerste vraag kan zijn: *"ik heb het hele verhaal van u goed gelezen en een aantal vragen op papier gezet die kunnen we langslopen maar misschien kunt u eerst nog een keer in het kort vertellen wat u precies wilt en waarom u het wilt?"* Let ook om de waarom, wat is de business case? Welk probleem wordt hier opgelost? Als er geen probleem wordt opgelost dan is het project vaak gedoemd te mislukken. In een latere fase kunnen gebruikers ook gaan mokken of zelfs tegenwerken. Verandering vinden ze vaak niet leuk. Door het doel (het oplossen van een probleem) scherp te houden kun je uitleggen waarom je het doet. Maak tijdens het gesprek gewoon chronologisch aantekeningen. In de praktijk (niet in je examen) zou je ook kunnen vragen om het gesprek op te nemen, dan is het echter nog steeds van belang om aantekeningen te maken (waarom?). Jij wilt wat leren dus laat de klant zoveel mogelijk praten (als jij praat leer je immers niets). Zorg alleen dat hij niet teveel van het onderwerp weg gaat. Reflecteer (LSD) en check aan het eind van het gesprek of al je voorbereidde vragen zijn beantwoord. Vraag om een email-adres om eventuele vragen die later ontstaan nog te kunnen stellen. Probeer het product voor je te zien. --- # W1, Vragen KDV Klavertje Vier (PvE 2.0) ### Eindopdracht PvE Ter voorbereiding voor het maken van het specifiek PvE kunnen de onderstaande vragen worden gesteld in het klantgesprek. Als de antwoorden duidelijk zijn moet er voldoende informatie beschikaar zijn om een PvE op te stellen. In de les zullen we deze vragen bespreken. Schrijf zelf de antwoorden op en verwerk deze in versie 2 van het PvE. De beoordeling voor versie 2.0 zal volgens het opgenomen schema gebeuren en zal voor 30% meetellen voor eindcijfer. Deadline: zaterdag 4 oktober 14:00 uur. Inleveren in Word via Teams. ### Eindcijfer Het eindcijfer bepaald de voordracht voor het examen.
PvE versie 1.0 (of gesprek incl. voorbereiding)10%
PvE versie 2.030%
Projectplan 1.020%
Funcitoneel Ontwerp40%
### Vragenlijst 1. Hoe wordt de administratie nu bijgehouden en waarom werkt dat niet goed? *Met deze vraag wordt duidelijk wat het nieuwe systeem precies moet oplossen. Je wilt immers niet dat het nieuwe systeem de problemen van het huidige systeem niet (gedeeltelijk) oplost!* 2. Wat werkt er wel heel goed aan het huidige systeem? *Belangrijk, want mogelijk kan dit ook vertaald worden in een eis/wens. Anders zal het betekenen dat de medewerkers misschien iets moeten 'inleveren'.* 3. Wie gaat het systeem gebruiken? Welke rol hebben deze gebruikers en hoeveel zijn dat er? *Dit kan je ook helpen de functionaliteiten te beschrijven. Functionaliteiten lijken soms op elkaar maar vanuit verschillende rollen zijn ze toch anders.* 4. Je kunt je nu afvragen welke functionaliteiten bij welke rol horen, als dat niet duidelijk is moet je dat vragen! 5. Security: waar wordt de site gehost? Op welk netwerk draait het? Moet er en login komen? Zo ja voor wie? Moeten er certifiacten (SSL) worden geimplementeerd? *Voor PvE is het nog niet zo van belang hoe de login precies werkt dat komt bij het FO.* 6. Overige eisen: denk aan deadline, budget, snelheid, flexibiliteit (in dit geval bijvoorbeeld groepsgrootte), printen, emailen, off-line documenten bewaren, ondersteuning browser(s), hosting, server platform. #### Beoordeling PvE 2.0
HoodstukWatPunten
InleidingGlobale omschrijving3
Doel van document3
BedrijfCore Business benoemen3
Bedrijfsprocessen die van belang zijn voor dit project3
AanleidingWaarom een nieuwe applicatie?3
Hoe werkt het nu?3
Wat betekent het invoeren van een nieuwe app voor de medewerkers?3
DoelgroepenZo specifiek mogelijk, dus niet *medewerker*, maar bijv. *administratief medewerker*.6
FunctionlaiteitenBeschrijf deze per doelgroep25
SecurityLogin/publlieke toegang,...6
Aanvullende eisenDit zijn vaak de eisen die niet wordne benoemd maar die worden verondersteld.6
BeperkingenDit zijn ook vaak eisen die worden verondersteld maar die expliciet niet worden uitgevoerd. Denk bijvoorbeeld aan browser-ondersteuning.6
AlgemeenBeschrijf *geen* vaagheden: we zouden een ... kunnen implementeren (Eventuele vragen apart benoemen).8
Zakelijk net taalgebruikt.6
Goed Nederlands.6
Alles ziet er netjes uit (dus bijv. geen template-aanwijzigingen meer laten staan).5
Op tijd ingeleverd (elke dag te laat -1 punt)5
TOTAAL 100
--- # W2, Projectplan ### Projectplan Het doel van het projectplan is duidelijk te geven wat het doel is en wat er nodig is om dit doel te bereiken. Planning en projectdoelstelling zijn de belangrijkste ingrediënten van het projectplan (en de helft van de punten). #### Projectdoelstelling Wanneer is het project een succes? Hoe kun je dit (zo) meetbaar (mogelijk) maken? Dit is lastig, maar stel jezelf deze vraag en overleg het met de klant. Wat wil de klant bereiken? Het doel is bijna nooit "*het bouwen van een site*". De site dient namelijk ergens voor. Je wilt er iets mee bereiken. Doelen zijn vaak hiërarchisch, bijvoorbeeld: 1. Het doel van de website is om meer naamsbekendheid te krijgen. 2. Het doel van meer naamsbekendheid is om meer omzet te genereren. 3. Het doel van meer omzet is om meer winst te maken. 4. Het doel van meer winst is om een extra winkel te kunnen openen. 5. Het doel van een extra winkel is om..... In dit voorbeeld zou ik het doel van de website omschrijven als: *Het doel van de website is om bezoekers te genereren waardoor de naamsbekendheid omhoog gaat en daardoor meer omzet kan worden gegenereerd*. Dit doel is heel mooi [SMART](https://www.youtube.com/watch?v=1-SvuFIQjK8) te maken:
SpecificWebsite bezoeker genereren
MeasurableVia weblogs meten; doel 2000 unieke gebruikers/week
Achievable/ActionableVia extra Adds (Google) en maandelijkse kortingsbonnen via de webste is dit haalbaar
RelevantBinnen het budget is voor het eind van het jaar een bezoekersaantal van 800 unieke bezoekers per week realistisch en haalbaar. Dit is relevant, omdat dit een goede indicatie geeft of de 200 bezoekers/week haalbaar is.
Time relatedBinnen 10 maanden moet het doel van 2000 unieke gebruikers per week kunnen worden gehaald.
Dit hoeft niet allemaal in het projectplan te staan maar het kan wel helpen om het doel scherp te stellen. Als het doel niet duidelijk is, kun je dit heel lastig SMART maken. Voor het project Klavertje Vier zou het projectdoel als volgt kunnen worden gesteld: *Het project heeft tot doel om ervoor te zorgen dat na de uitbreiding van 3 naar 4 groepen, de adminstratie niet meer tijd kwijt is met het bijhouden van de administratie*. Laten we de aspecten van SMART voor dit doel eens bijkijken:
SpecificAdministratieve last mag niet toenemen
MeasurableHoeveel tijd is men nu kwijt en hoeveel tijd is men na uitbreiding kwijt.
Achievable/ActionableDoor de gegevens in te laten zien door de leidsters verwachten we minder kwijt bezig te zijn met het beantwoorden van vragen en besparen we op dat punt tijd.
RelevantDe administratieve last is nu zodanig dat als die groter wordt, er een extra persoon moet worden aangenomen. Dit betekent een toename van terugkerende kosten die hoger zullen zijn dan de kosten voor een applicatie.
Time relatedVoor de uitbreiding moet de applicatie in gebruik worden genomen en kunnen we het effect al vrij snel meten.
### Planning De planning bestaat uit het faseren, plannen en begroten en meestal staan deze gecombineerd in een overzicht. #### Faseren De planning bestaat uit fases. Een fase is een duidelijk onderdeel waarvan je goed kan controleren of het daadwerkelijk af is. De fases moeten niet te groot zijn, omdat je dan lastiger kunt meten tijdens het project of je nog op schema ligt of dat je uitloopt. Na elke fase wil je namelijk kunnen controleren of je nog binnen je planning zit.Als dat niet zo is dan moet je namelijk onderzoeken waarom je uit de planning bent gelopen en wat je er aan kunt doen om alsnog de deadline te halen. Dit is een essentieel onderdeel van projectmanagement en een taak van de projectleider. De fasering helpt de project leider dus om gedurende de uitvoering van het project een vinger aan de pols te houden. #### Planning De planning bestaat uit twee componenten wanneer en hoelang. Vaak zit er in een projectplan een volgorde. Je kun niet beginnen met testen voordat je een product hebt. Soms kun je ook niet beginnen wanneer je dat zou willen, omdat medewerkers pas beschikbaar zijn vanaf een bepaalde datum. Het is voor alle betrokkenen belangrijk om te weten wanneer zij wat moeten doen. Dan kunnen zij daar rekening mee houden in hun eigen planning. Uiteraard moet je deze beschikbaarheid met de betrokkenen afstemmen. Voor wat betreft de bouw kun je een opdeling maken, bijvoorbeeld: database opzetten en vullen met (test)data dan kun je per scherm een planning maken. Heb je dan alles; denk goed na want niet alle functies zijn altijd op een scherm te herleiden. Loop je use cases nog eens na en bepaal voor jezelf of je in alles hebt voorzien. Dan komt natuurlijk testen, eerst technisch en dan door de klant. Uiteindelijk moet je natuurlijk nog tijd inruimen voor bug-solving en ander nazorg. Het geheel kan in een eenvoudige tabel worden weergegeven. ![](https://www.roc.ovh/uploads/images/gallery/2019-10/scaled-1680-/image-1570271287304.png) Alle mogelijke werkzaamheden staan hieronder. De grijze blokken stellen de fases voor: ontwerp, development en oplevering. Afhankelijk van heel veel factoren kun je voor elk blok ongeveer 30% van de tijd rekenen: Blok1, ontwerp 20%-40%, blok2 development 20%-30%, blok 3 oplevering 20%-40%. Development met een framework zoals laravel gaat over het algemeen sneller, maar de oplevering kan weer langer duren, omdat er meer afhankelijkheden zijn. Bij Agile development zal de ontwerp fase en de oplevering weer kleiner zijn.
ActiviteitToelichting
Projectplan schrijvenBij kleinere projecten kun je deze drie stappen ook samenvoegen
Projectplan bespreken
Projectplan aanpassen
Functioneel Ontwerp schrijvenBij kleinere projecten kun je deze drie stappen ook samenvoegen
Functioneel Ontwerp bespreken
Functioneel Ontwerp aanpassen
Technisch Ontwerp schrijvenBij kleinere projecten kun je deze drie stappen ook samenvoegen
Technisch ontwerp doorspreken met developers
Database ontwerp en opzetten
Ontwikkelomgeving inrichten
Ontwikkelomgeving documenteren
Development 1Deel dit op in stukken. het liefst in stukken die je ook kunt weglaten
Development 2zodat de klant kan kiezen en kan prioriteren.
Development 3
Design CSS en graphicsIndien nodig - als het eenvoudig blijft kun je dit natuurlijk weglaten.
Technische testJe moet alle functionaliteiten een keer samen testen
Bugs oplossen10%-20% van de development tijd.
Opleveren aan klant in acceptatie omgeving ofPlaats je de applicatie in een aparte omgeving waar de klant kan testen
Tonen aan klantof geef je een demo aan de kant?
Feedback van klant verwerken
Opleveren naar productieOverzetten van code naar productie-omgeving
Config aanpassen naar productieaanpassen van logging, error messages, db login, etc.
Acceptatietest klantdit zijn geen uren die je in rekenign kunt brengen maar zijn wel uren die de klant moet investeren.
Bugs oplossen
Opleveren alle documentatie en afrondingDit is meer alles verzamelen en opsturen en formeel project afronden door de klant te vragen of alles akkoord is.
Een meer gedetailleerd en visueel aantrekkelijker manier om de planning te maken is met tools zoals *teamgantt* of *Microsoft Project.* Met Excel kun je ook een schema maken waarin je de taken onder elkaar zet en de dag planning in de kolommen zet. ![](https://www.roc.ovh/uploads/images/gallery/2019-10/scaled-1680-/image-1570271530651.png) ### Indeling en Beoordeling
HoodstukWatPunten
InleidingGlobale omschrijving1
Doel van document1
ProjectdoelstellingenBeschrijf zo [SMART](http://www.carrieretijger.nl/functioneren/management/leidinggeven/doelen-stellen/smart) mogelijk wanneer dit project een succes is. Wees concreet/specifiek, meetbaar, haalbaar, realistisch en tijdgebonden. Dus **niet**: de website moet er mooi uit zien.20
Leden projectgroep / de betrokkenenWie zijn er betrokken, noem, namen en rollen. Rollen die in ider geval van belang zijn, zijn: informatie-analyst (FO), projectledeider, opdrachtgever, gebruikers (wees specifiek), testers (wees specifiek), developers.5
RandvoorwaardenBenodigdheden: beschikbaarheid van resources (mensen en midellen), zoals hardware, netwerk, werkplek (als je op locatie gaat ontwikkelen), bepaalde input, ....)10
Takenlijst/PlanningWees zo specifiek mogelijk, zie template. Je wordt beoordelen op een reeele planning en een complete takenlijst. Groet taken opdelen in kleinere taken; er moet een evenwichtige verdeling uitkomen: dus *niet* 1, uur, 1 uur en 2 weken. 30
Risico'sZie template15
ProjectgrenzenDeze volgen meestal uit de 'beperkingen' uit het PvE5
AlgemeenZakelijk net taalgebruikt.5
Goed Nederlands.5
Alles ziet er netjes uit (dus bijv. geen template-aanwijzigingen meer laten staan).3
TOTAAL 100
# W3, Functioneel Ontwerp ### Het Ontwerpproces in het kort ##### Programma van Eisen *Van idee naar opdracht, ook wel projectinitiatie.* We hebben een opdracht van een klant ontvangen en hebben de klant geïnterviewd. Hieruit hebben wij de opdrachtbrief in de vorm van het Programma van Esien opgesteld. Hierin staat de opdracht beschreven. ##### Projectplan *Van opdracht naar wat we nodig hebben?* Na het PvE zijn we aan de slag gegaan met een detail planning; het projectplan. Het doel van het projectplan is vooral te bepalen wat we nodig hebben voor het uitvoeren van de opdracht. We delen het hele project op in kleinere taken en laten zien wat we nodig hebben voor het uitvoeren van deze taken, het gaat hierbij dan om uren, mensen en midellen.Vanuit het projectplan volgt een planning. ##### Functioneel Ontwerp *Van opdracht naar hoe?* Dit is eigenlijk het document waar het allemaal om gaat. Hierin staat in detail besproken wat we gaan maken. Dit document is een detail-uitwerking van het PvE. ##### Technisch Ontwerp (geen onderdeel van K1) *Hoe zit het technisch in elkaar?* Dit is een onderdeel van het ontwerp process waar de klant niet direct meer bij betrokken is. Het gaat hier voornamelijk om technische zaken. Het database ontwerp staat vaak centraal in dit document. ### Functioneel ontwerp als blauwdruk van de website In feite is een FO de blauwdruk voor de website, webwinkel of applicatie. Het FO bestaat voornamelijk uit tekst, maar mindmaps, illustraties en dergelijke kunnen de functionaliteiten visueel weergeven. Ondersteuning met beeld of voorbeelden is verstandig, het zorgt voor extra verduidelijking. Vervolgens biedt het functioneel ontwerp input voor het uiteindelijke technisch ontwerp (TO) en grafisch ontwerp (GO). De basis voor het uiteindelijke eindresultaat wordt voornamelijk bepaald door het FO. ### Functioneel ontwerp voor programmeur Een FO geeft een programmeur houvast en zekerheid. Zonder duidelijke briefing, zonder duidelijk FO gaat een programmeur eigen invulling geven en die invulling komt vaak niet overeen met die van de klant. Een FO biedt duidelijke richtlijnen waar niet of nauwelijks vanaf geweken hoeft te worden gedurende het realisatieproces. Dit voorkomt miscommunicatie en vertraging gedurende het project. ### Waaruit bestaat een functioneel ontwerp? Elk functioneel ontwerp is bij elke bedrijf anders; er geen standaard formaat voor. Wel is er een aantal elementen die eigenlijk altijd deel uitmaken van het FO: - Inleiding - Doelgroep - Doelen van de website - Structuur van website - Uitwerking verschillende pagina’s - Functionaliteiten per pagina - Input voor design (GO) en techniek (TO) - Optionele functionaliteiten ### Wat zijn wireframes of mockups? [Top 25 free Mockup and Wireframe tools.](https://codecondo.com/free-wireframe-tools/) | [De nummer 1, Frame Box](http://framebox.org) Wireframes, ook wel mockups genoemd, zijn een visueel hulpmiddel bij het ontwikkelen van een website of -applicatie. Ze kunnen gezien worden als de bouwtekening van een website, waarin een overzicht wordt gegeven van de verschillende onderdelen die op een website aanwezig zullen zijn. In de wireframes worden zaken vastgelegd als navigatie, indeling en inhoud, zonder gebruik te maken van een grafisch ontwerp. Het grote voordeel is dat alleen op de inhoud gefocust wordt en *niet* op het grafische aspect. ![](http://www.roc.ovh/uploads/images/gallery/2019-10/scaled-1680-/image-1570263438612.png) ### Waarom een functioneel ontwerp? “Je laat toch ook geen keuken bouwen zonder ontwerp?” De investering in een FO is absoluut verstandig. Het voorkomt valkuilen, uitloop in planning, meerwerk kosten en andere nadelige zaken gedurende het project. Ik durf het zelfs zo te stellen dat een project zonder of met een half FO, vaker uitloopt en vaker boven begroting uitkomt dan een project met een compleet FO. Daarnaast is een FO een waardevol communicatiemiddel. Bij een groot webdevelopment project komen vaak meerdere expertises kijken, bijvoorbeeld: opdrachtgever, online marketing bureau, copywriter, projectmanager, designer, programmeur en derden. Het FO is de blauwdruk, het centrale uitgangspunt van waaruit iedere betrokkene werkt. Dit bevordert de onderlinge communicatie en het reduceert de kans op ruis. ### Tweakers Quote [Arjan A in "Voordelen van het opstellen van een functioneel ontwerp"](https://gathering.tweakers.net/forum/list_message/21771907#21771907) *...Het doel van een FO is onder andere om duidelijk te stellen welke functionaliteiten geboden (gaan) worden en welke niet. Aannames dienen te worden uitgesloten.* *...Het scheelt gezeik over "dit en dat moest er ook in" en dus tijd. ...*...*Overigens is de bedoeling van een FO niet dat je het achteraf schrijft. Dan kan je net zo goed een handleiding gaan maken......* ### Agile en Functioneel Ontwerp Voordat Agile Development zoals SCRUM werd omarmt, bestond het FO vaak uit dikke boekwerken waarin elke detail is uitgewerkt. Voor het opstellen van het ontwerp was je soms met meerdere personen ongeveer even lang bezig als met de werkelijke bouw. Tijdens grote projecten hanteerde we vaak de 30% regel: 30% van de tijd ontwerp - 30% bouw - 30% testen en bugs oplossen. De 10% die over was was dan onvoorzien en ging meestal in de laatste fase zitten. Met Agile development is dat anders, maar je ziet nod steeds dat een soort FO in eerste instantie wel wordt gemaakt. Er wordt een soort super sprint in gedefinieerd waarin het begin van een project in detail wordt uitgewerkt. In mijn laatste werk was het FO dan onderdeel van het projectplan. \-- # W3 Functioneel Ontwerp - Flow ### Flow Gemaakt met [lucidchart.com](https://www.lucidchart.com) ![](https://www.roc.ovh/uploads/images/gallery/2019-10/scaled-1680-/image-1570389595872.png) ### Wireframe Wireframe, gemaakt met [WireFrameSketcher](https://wireframesketcher.com/download.html) (voor Mac en Windows) ![](https://www.roc.ovh/uploads/images/gallery/2019-10/scaled-1680-/image-1570391039016.png) # W3 FO van Use Case naar Wireframe ### Overzicht Een use case is de meest eenvoudige/primitieve vorm van het beschrijven van een functionalitiet. Voorbeelden: Bij een bank applicatie, use case; *"een gebruiker wil geld overmaken"*. 1. Gebruiker logged in 2. Gebruiker gaat naar rekening voerzicht 3. Indien er meerdere rekeningen zijn selecteer de jusite rekening 4. Kies overschrijven 5. Vul alle gegevens in 6. Valideer en authoriseer de transactie Een use case wordt vaak grafisch weergegeven. Vanuit de verschillende use cases worden schermen ontworpen, de naviagatie tussen deze schermen kan wordne weergegeven in een schem-diagram. Van Use Case naar scherm diagram kan een grote stap zijn en je kan een soort mix maken van scherm diagram en sue case diagram. Van deze drie diagrammen wordt in deze les een voorbeeld gegeven. De voorbeelden komen uit de 'Kinderdagverblif Case' . ### Use Case De interactie van een gebruiker met het systeem. Is een eenvoudige stappen grafisch stappen model van een handeling die een gebruiker kan doen. Vanuit de use cases kun je schermen gaan ontwerpen en zul je ook zien dat bepaalde schermen on meerdere use cases terug komen. Elk use case is een functionaliteit. Een complete lijst van use cases helpt vaak bij de planning.
### Van use case naar Site Map In onderstaande diagram zijn meerdere use cases gecombineerd. De nummers verwijzen naar schermen die elder in het FO moeten worden getekend of beschreven.
### Schermen | Site Map (voorbeeld!)
### Wireframe Let ook op dat je bij een Wire Frame een verwijzing maakt naar het schermen diagram.
# Huiswerk ### Huiswerk week 7 *(deadline maandag 21 october 2019)* We gaan verder met de Case "Project Kinderopvang". Door de oefening met het flow diagram hebben we beter inzicht gekregen in de functionaliteiten. Er zijn verschillende flow diagrammen. Lees daarover in: [https://www.roc.ovh/books/examentraining-b1-k1/page/w3-fo-van-use-case-naar-wireframe](https://www.roc.ovh/books/examentraining-b1-k1/page/w3-fo-van-use-case-naar-wireframe) Lees eventueel ook nog een keer het verhaal over FO: [https://www.roc.ovh/books/examentraining-b1-k1/page/w3-functioneel-ontwerp](https://www.roc.ovh/books/examentraining-b1-k1/page/w3-functioneel-ontwerp) Maak nu opnieuw een lijstje met *alle* Use Cases. Create/Update/Delete kun je meestal samenvoegen. Read, raadplegen is vaak een aparte use case. Dus de lijst ziet er als volgt uit: 1. Als leidster wil ik een overzicht kunnen lezen van de geplande bezetting. 2. Als administratief medewerker wil ik kunnen aanloggen en kunnen zien wie onze klanten zijn aan de hand van de naam- en adressgegevens. 3. Als administratief medewerker wil ik kunnen aanloggen en een in een lijst met klanten kunnen zoeken op voornaam of achternaam. 4. Als administratief medewerker wil ik kunnen aanloggen, een klant kunnen opzoeken om vervolgens van deze klant.... etc. 5. etc. etc. Kijk nu naar je schermenflow (alias site-map) en verbeter die als je dat wilt. Nummer de schermen en geef per use case aan welke schermen daarvoor gebruikt worden. Probeer het aantal schermen niet te groot te maken. Een gebruiker wil voor een bepaalde use case niet door tig schermen heen navigeren. Aan de andere kant; te veel informatie op een scherm is ook weer niet handig want dan wordt het te complex en de applicatie kan trager worden. Geef per scherm een korte omschrijving zodat duidelijk wordt hoe het scherm er in grote lijnen uitziet en wat je er mee kunt. Beschrijf de naviagatiemogelijkheden. Bijvoorbeeld als je op een overzicht zit en je kunt vanuit het overizcht naar een scherm springen om een onderdeel te veranderen beschrijf dan hoe dat werkt. Bijvoorbeeld, hoe kom je in het edit-scherm? Als je tevreden bent over je schermflow dan ga je je planning maken. Dit is het kern-onderdeel van het projectplan. lees hiervoor: [https://www.roc.ovh/books/examentraining-b1-k1/page/w2-projectplan](https://www.roc.ovh/books/examentraining-b1-k1/page/w2-projectplan) Je kunt het verhaal over projectdoelstelling voor nu nog even overslaan. Dus samengevat verwacht ik een net document met daarin: 1. Een *complete* lijst met use cases. 2. Een site-map (flow van schermen) met schermnummering en schermbeschrijving. 3. Bij elke use case aangeven welke schermen erbij horen. 4. Een beschrijving van het projectdoel. 5. Een planning zoals die in het projectplan moet komen. Samenwerken mag met maximaal 1 andere persoon en aangeven met wie. Graag de genoemde onderdelen in één Word docuement inleveren in Teams. \-- Na de vakantie is er nog één keer de gelegenheid om vragen te stellen, documenten door te nemen en dan zullen alle drie de documenten (Pve, Projectplan en Functioneel Ontwerp) moeten worden ingeleverd. Alleen als dit zijn ingeleverd en het resultaat is voldoende kan je voor het examen worden voorgedragen. De onderdelen die je nu inlevert zijn de kern van de drie documenten. Als je ze neit inlevert dan mis je de laatste kans op goede feedback. \-- Week 8: PvE en Projectplan inleveren Week 9: FO inleveren Week 10: uitloop en laatste tips. ### Huiswerk week 6 Voordat we het projectplan gaan maken gaan we eerst een onderdeel van het Funtioneel Ontwerp maken. Lees allereerst dit door: [https://www.roc.ovh/books/examentraining-b1-k1/page/w3-functioneel-ontwerp](https://www.roc.ovh/books/examentraining-b1-k1/page/w3-functioneel-ontwerp) Dan: (1) maak een flow diagram van schermen: elke scherm is een blokje en tussen de blokjes staan pijltjes die aangeven dat je van het een scherm naar het andere scherm kan navigeren. Je wordt beoordeeld op een compleet design. (2) maak een wireframe van het planningsscherm waarop de leidsters kunnen zien wie er wanneer komt. Dit scherm moet alle gewenste functionaliteiten bevatten. Inleveren in een Word document of in een link naar de gewenste informatie. Voorbeelden: [https://www.roc.ovh/books/examentraining-b1-k1/page/w3-functioneel-ontwerp---flow](https://www.roc.ovh/books/examentraining-b1-k1/page/w3-functioneel-ontwerp---flow) (hierin staan ook verwijzingen naar de gebruikte tools, maar je bent vrij om elke tool die je wilt te gebruiken). \--