# 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
Kerntaak | Wat | Kern |
B1-K1-W1 | Goedgekeurd PvE | Use Cases |
B1-K1\_W2 | Realistische Planning (Projectplan) | Planning |
B1-K1-W3 | Functioneel Ontwerp | Schermen (Site-map - Wireframes) |
Technisch Ontwerp | Flow diagram en ERD | |
B1-K1-W4 | Ontwikkelomgeving | Werkende ontwikkelomgeving |
Documentatie Ontwikkelomgeving | Configuratie ontwikkelomgeving |
Naam leerling | Max Bisschop |
Leerlingnummer | 999 |
Datum | 28 september 2019 |
Versie 1.0 | 1ste versie, 22 septembet 2019 |
Versie 2.0 | aangepast na klantbespreking van 26 septmeber |
Paragraaf | Omschrijving |
Inleiding | ... heeft ons gevraagd om een Applicatie te ontwikkelen. Dit document beschrijft de wensen van ...en dient als input voor het meer gedetailleerde projectplan |
Bedrijf | Korte omschrijving van het bedrijf. Benoem het primaire bedrijfsprocess waarvoor de applicatiewordt ontwikkeld. |
Aanleiding | Beschrijf de reden; wat wil de opdrachtgever bereiken? |
Doelgroepen | Voor wie is de applicatie; alle groepen benoemen. |
User Stories / Overzicht functionaliteiten | Een complete lijst met use cases (in tekst). |
Overig | Security, beperkingen, aanvullende eisen |
Paragraaf | Omschrijving |
Inleiding | Dit projectplan geeft een gedetailleerd overzicht van alle activitieten die moeten worden uitgevoerd voor de ontwikkeling en oplevering van ..... |
Proejctdoelstelling | Kort en SMART. Kijk ook naar de aanleiding uit het PvE |
Project betrokkenen | Noem iedereen die aan het project meewerkt. Benoem naam en rol. Rollen zijn: , projectleider, opdrachtgever, gebruikersgroep, developer, tester,... |
Benodigdheden | Wat heb je nodig voor de uitvoering van het project? In in ieder geval werkende ontwikkelomgeving, FO, TO, ... |
Takenlijst Planning | Zie complete lijst.... |
Projectgrenzen | Wat doen we niet; wat valt buiten het project. |
Paragraaf | Omschrijving |
Inleiding | Het functioneel ontwerp is een gedetailleerde beschrijving van de applicatie ..... Het ontwerp zal worden afgestemd met ... |
Rollen | Benoem de rollen nog een keer (die volgen uit de use cases) |
Site-Map / Navigatiestructuur | Hoe kan je door de applicatie navigeren. Dit komt overeen met de menu-strucuur. Zie voorbeeld. |
Standaard Lay-out | Wire Frame van de *standaard* scherm-layout, zie voorbeeld |
Eén of twee schermen uittekenen | Mock-up of wire frame, zie voorbeelden. |
Schermbeschrijving | Korte omschrijving van *alle* schermen (waarvoor dent hetscherm?) en *alle* invoer- en uitvoervelden benoemen. Benoem ook wie (rollen) het scherm kan gebuiken. |
Functionaliteiten | Use Cases (PvE) - Schermen relatie |
Paragraaf | Omschrijving |
Inleiding | |
Applicatie Componenten Overzicht | Cliënt, Web Server (PHP Laralvel), Database Server |
Applicatieflow | Dit is een process flow van de use cases. Werk in inder geval de complexere use cases uit. Zie voorbeeld. |
Database Structuur | Database diagram (bijv uit phpmyadmin) |
Paragraaf | Omschrijving |
Inleiding | |
Hardware benodigdheden | Geef aan welke hardware benogdheden je nodig hebt |
Software benodigdheden | Maak een lijst van alle software benodigdheden inclusief versies; PHP, Laravel, Node.js, Vue.js, bootstrap, database, OS, ...) |
Configuratie | Belangrijke (afwijkende) configuratie. Denk ook aan development specifieke zaken zoals debugging, error messages, root login. |
Testen | Beschrijf een aantal stappen die je moet nemen om alles te testen |
Activiteit | Toelichting |
Projectplan schrijven | Bij kleinere projecten kun je deze drie stappen ook samenvoegen |
Projectplan bespreken | |
Projectplan aanpassen | |
Functioneel Ontwerp schrijven | Bij kleinere projecten kun je deze drie stappen ook samenvoegen |
Functioneel Ontwerp bespreken | |
Functioneel Ontwerp aanpassen | |
Technisch Ontwerp schrijven | Bij kleinere projecten kun je deze drie stappen ook samenvoegen |
Technisch ontwerp doorspreken met developers | |
Database ontwerp en opzetten | |
Ontwikkelomgeving inrichten | |
Ontwikkelomgeving documenteren | |
Development 1 | Deel dit op in stukken. het liefst in stukken die je ook kunt weglaten |
Development 2 | zodat de klant kan kiezen en kan prioriseren. |
Development 3 | |
Design CSS en graphics | Indien nodig - als het eenvoudig blijft kun je dit natturlijk weglaten. |
Technische test | Je moet alle functionaliteiten een keer samen testen |
Bugs oplossen | 10%-20% van de development tijd. |
Opleveren aan klant in acceptatie omgeving of | Plaats je de applicatie in een aparte omgeving waar de klant kan testen |
Tonen aan klant | of geef je een demo aan de kant? |
Feedback van klant verwerken | |
Opleveren naar productie | Overzetten van code naar productie-omgeving |
Config aanpassen naar productie | aanpassen van logging, error messages, db login, etc. |
Acceptatietest klant | dit zijn geen uren die je in rekening kunt brengen maar zijn wel uren die de klant moet investeren. |
Bugs oplossen | |
Opleveren alle documentatie en afronding | Dit is meer alles verzamalen en opsturen en formeel project afronden door de klant te vragen of alles akkoord is. |
Voorbereiding | 1 |
Gespreksvorm | 3 |
Gespreksinhoud | 3 |
Inhoud Programma van Eisen | 3 |
Vorm Programma van Eisen | 3 |
Onderbouwing | 3 |
Toelichting en om goedkeuring vragen | 1 |
Hoodstuk | Wat | Punten |
Inleiding | Globale omschrijving | 3 |
Doel van document | 3 | |
Bedrijf | Core Business benoemen | 3 |
Bedrijfsprocessen die van belang zijn voor dit project | 3 | |
Aanleiding | Waarom een nieuwe applicatie? | 3 |
Hoe werkt het nu? | 3 | |
Wat betekent het invoeren van een nieuwe app voor de medewerkers? | 3 | |
Doelgroepen | Zo specifiek mogelijk, dus niet *medewerker*, maar bijv. *administratief medewerker*. | 6 |
Functionlaiteiten | Beschrijf deze per doelgroep | 25 |
Security | Login/publlieke toegang,... | 6 |
Aanvullende eisen | Dit zijn vaak de eisen die niet wordne benoemd maar die worden verondersteld. | 6 |
Beperkingen | Dit zijn ook vaak eisen die worden verondersteld maar die expliciet niet worden uitgevoerd. Denk bijvoorbeeld aan browser-ondersteuning. | 6 |
Algemeen | Beschrijf *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 |
Projectdoelstellingen en risico's | 30% |
Project activiteiten | 30% |
Planning | 30% |
Afstemmen | 10% |
Hoodstuk | Wat | Punten |
Inleiding | Globale omschrijving | 1 |
Doel van document | 1 | |
Projectdoelstellingen | Beschrijf 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 betrokkenen | Wie 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 |
Randvoorwaarden | Benodigdheden: beschikbaarheid van resources (mensen en midellen), zoals hardware, netwerk, werkplek (als je op locatie gaat ontwikkelen), bepaalde input, ....) | 10 |
Takenlijst/Planning | Wees 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's | Zie template | 15 |
Projectgrenzen | Deze volgen meestal uit de 'beperkingen' uit het PvE | 5 |
Algemeen | Zakelijk net taalgebruikt. | 5 |
Goed Nederlands. | 5 | |
Alles ziet er netjes uit (dus bijv. geen template-aanwijzigingen meer laten staan). | 3 | |
TOTAAL | 100 |
Functionaliteiten zijn beschreven met priorisering | 3 |
Schematechnieken, wireframe, sitemap,... | 3 |
GUI met saemnhang tussen schermen | 3 |
Toelichting en om toestemming vragen | 3 |
Benodigde hard- en software volledig beschreven | 3 |
Ontwikkelomgeving juist geinstalleerd en geconfigureerd | 1 |
Ontwikkelomgeving is getest | 1 |
Documentatie is correct en volledig | 1 |
Onderdeel | Aantal punten |
Voorbereiding | 1 |
gespreksvorm | 3 = aantal (in)(v's/9) |
gespreksinhoud | 3 = aantal i's |
inhoud PvE\*) | 3 |
vorm PvE | 3 |
onderbouwing | 3 |
toelichting en om goedkeuring vragen | 1 |
**TOTAAL** | 17 |
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.0 | 30% |
Projectplan 1.0 | 20% |
Funcitoneel Ontwerp | 40% |
Hoodstuk | Wat | Punten |
Inleiding | Globale omschrijving | 3 |
Doel van document | 3 | |
Bedrijf | Core Business benoemen | 3 |
Bedrijfsprocessen die van belang zijn voor dit project | 3 | |
Aanleiding | Waarom een nieuwe applicatie? | 3 |
Hoe werkt het nu? | 3 | |
Wat betekent het invoeren van een nieuwe app voor de medewerkers? | 3 | |
Doelgroepen | Zo specifiek mogelijk, dus niet *medewerker*, maar bijv. *administratief medewerker*. | 6 |
Functionlaiteiten | Beschrijf deze per doelgroep | 25 |
Security | Login/publlieke toegang,... | 6 |
Aanvullende eisen | Dit zijn vaak de eisen die niet wordne benoemd maar die worden verondersteld. | 6 |
Beperkingen | Dit zijn ook vaak eisen die worden verondersteld maar die expliciet niet worden uitgevoerd. Denk bijvoorbeeld aan browser-ondersteuning. | 6 |
Algemeen | Beschrijf *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 |
Specific | Website bezoeker genereren |
Measurable | Via weblogs meten; doel 2000 unieke gebruikers/week |
Achievable/Actionable | Via extra Adds (Google) en maandelijkse kortingsbonnen via de webste is dit haalbaar |
Relevant | Binnen 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 related | Binnen 10 maanden moet het doel van 2000 unieke gebruikers per week kunnen worden gehaald. |
Specific | Administratieve last mag niet toenemen |
Measurable | Hoeveel tijd is men nu kwijt en hoeveel tijd is men na uitbreiding kwijt. |
Achievable/Actionable | Door 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. |
Relevant | De 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 related | Voor de uitbreiding moet de applicatie in gebruik worden genomen en kunnen we het effect al vrij snel meten. |
Activiteit | Toelichting |
Projectplan schrijven | Bij kleinere projecten kun je deze drie stappen ook samenvoegen |
Projectplan bespreken | |
Projectplan aanpassen | |
Functioneel Ontwerp schrijven | Bij kleinere projecten kun je deze drie stappen ook samenvoegen |
Functioneel Ontwerp bespreken | |
Functioneel Ontwerp aanpassen | |
Technisch Ontwerp schrijven | Bij kleinere projecten kun je deze drie stappen ook samenvoegen |
Technisch ontwerp doorspreken met developers | |
Database ontwerp en opzetten | |
Ontwikkelomgeving inrichten | |
Ontwikkelomgeving documenteren | |
Development 1 | Deel dit op in stukken. het liefst in stukken die je ook kunt weglaten |
Development 2 | zodat de klant kan kiezen en kan prioriteren. |
Development 3 | |
Design CSS en graphics | Indien nodig - als het eenvoudig blijft kun je dit natuurlijk weglaten. |
Technische test | Je moet alle functionaliteiten een keer samen testen |
Bugs oplossen | 10%-20% van de development tijd. |
Opleveren aan klant in acceptatie omgeving of | Plaats je de applicatie in een aparte omgeving waar de klant kan testen |
Tonen aan klant | of geef je een demo aan de kant? |
Feedback van klant verwerken | |
Opleveren naar productie | Overzetten van code naar productie-omgeving |
Config aanpassen naar productie | aanpassen van logging, error messages, db login, etc. |
Acceptatietest klant | dit zijn geen uren die je in rekenign kunt brengen maar zijn wel uren die de klant moet investeren. |
Bugs oplossen | |
Opleveren alle documentatie en afronding | Dit is meer alles verzamelen en opsturen en formeel project afronden door de klant te vragen of alles akkoord is. |
Hoodstuk | Wat | Punten |
Inleiding | Globale omschrijving | 1 |
Doel van document | 1 | |
Projectdoelstellingen | Beschrijf 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 betrokkenen | Wie 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 |
Randvoorwaarden | Benodigdheden: beschikbaarheid van resources (mensen en midellen), zoals hardware, netwerk, werkplek (als je op locatie gaat ontwikkelen), bepaalde input, ....) | 10 |
Takenlijst/Planning | Wees 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's | Zie template | 15 |
Projectgrenzen | Deze volgen meestal uit de 'beperkingen' uit het PvE | 5 |
Algemeen | Zakelijk net taalgebruikt. | 5 |
Goed Nederlands. | 5 | |
Alles ziet er netjes uit (dus bijv. geen template-aanwijzigingen meer laten staan). | 3 | |
TOTAAL | 100 |