Examentraining B1-K1

(oude versie een nieuwe versie wordt gemaakt)
B1-K1-W1, Stelt de opdracht vast (vraaggesprek, PvE)
B1-K1-W2, Levert een bijdrage aan het projectplan (Projectplan)
B1-K1-W3, Levert een bijdrage aan het ontwerp (FO/TO)
B1-K1-W4, Bereidt de realisatie voor (Inrichten testen en documenteren dev. omgeving)

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

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.0 aangepast 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

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

02 Projectplan

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.

03 Functioneel Ontwerp

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

04 Technisch Ontwerp

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)

05 Documentatie Ontwikkelomgeving

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

Voorbeelden

Activiteitenlijst (TO)

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.

Standaard Scherm Lay-out (FO)

Site-Map / Navigatiestructuur (FO)

       

 

Mock-up of wire frames (FO)

        

Applicatie flow (TO)

         

 

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

(LSD)

Programma van Eisen

Beoordeling

Voorbereiding 1
Gespreksvorm 3
Gespreksinhoud 3
Inhoud Programma van Eisen 3
Vorm Programma van Eisen 3
Onderbouwing 3
Toelichting en om goedkeuring vragen 1

Voldoende bij 9 punten (van de 17) of meer plus voldoende eisen in Programma van Eisen.

Beoordeling PvE

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

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's 30%
Project activiteiten 30%
Planning 30%
Afstemmen 10%

Voldoende bij 5 punten of meer.

('19 en volgende)

Beoordeling Projectplan

Hoodstuk Wat Punten
Inleiding Globale omschrijving 1
  Doel van document 1
Projectdoelstellingen Beschrijf zo 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

B1-K1-W3: Levert een bijdrage aan het ontwerp

Resultaat
  1. Een bijdrage aan het ontwerpdocument.
Versie 1 Functioneel Ontwerp

Bepspreken Functioneel Ontwerp Opdrachtgeven/Projectleider.

Maak 2de versie Functioneel Ontwerp

Beoordeling

Functionaliteiten zijn beschreven met priorisering 3
Schematechnieken, wireframe, sitemap,... 3
GUI met saemnhang tussen schermen 3
Toelichting en om toestemming vragen 3

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 beschreven 3
Ontwikkelomgeving juist geinstalleerd en geconfigureerd 1
Ontwikkelomgeving is getest 1
Documentatie is correct en volledig 1

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:

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 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:

Assumptions is the mother of al fuck-ups

Beoordeling

Erg belangrijk om te weten is, hoe je wordt beoordeeld.

Je krijgt punten voor de volgende onderdelen

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

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)

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%

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

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

 

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 te maken:

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.

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:

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.

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.

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.

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.

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.

Indeling en Beoordeling

Hoodstuk Wat Punten
Inleiding Globale omschrijving 1
  Doel van document 1
Projectdoelstellingen Beschrijf zo 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

 

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:

Wat zijn wireframes of mockups?

Top 25 free Mockup and Wireframe tools. | De nummer 1, Frame Box

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.

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"

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

Wireframe

Wireframe, gemaakt met WireFrameSketcher   (voor Mac en Windows)

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

Lees eventueel ook nog een keer het verhaal over FO: 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 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

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
(hierin staan ook verwijzingen naar de gebruikte tools, maar je bent vrij om elke tool die je wilt te gebruiken).

--