“Ziet er mooi uit. Maar uhm… werkt het ook?”

Omschrijving:

Als je iets ontwikkelt, of het nu een fysiek product is of een stuk code, is het natuurlijk belangrijk dat het werkt. Je moet ermee kunnen doen waarvoor het bedoeld is. Tijdens het ontwikkelen daarom vaak je spullen uitproberen, dit noemen we ‘ad hoc testen’. Om uiteindelijk aan je opdrachtgever aan te tonen dat het product werkt zoals afgesproken is ad hoc testen echter niet genoeg. Je zult structureler te werk moeten gaan.

Je gaat dan uit van het functioneel ontwerp (of de user stories) en verwoordt dit zodanig dat er meetbare specificaties (of ‘definitions of done’) ontstaan. Dan kan je namelijk hiermee een testvraag formuleren die met een eenvoudig ja of nee te beantwoorden is.

Soms is dit makkelijk. Als de wens van een klant is dat een website het logo op elke pagina toont, is de testvraag: staat het logo op elke pagina? (ja/nee)

In andere gevallen is dit veel moeilijker. Als bijvoorbeeld de wens is dat een webapplicatie veel bezoek aankan, zal je eerst moeten definiëren wat er precies bedoeld wordt met veel bezoek. Als normaal bezoek duizend bezoekers per uur is, zou je met de klant bijvoorbeeld af kunnen spreken dat je van het tienvoudige uitgaat voor veel bezoek. Je testvraag zou dan worden: kan de voorpagina van de website 3x per seconde (=10.000x per uur) opgevraagd worden zonder dat de gebruiker langer dan 0.5 seconde hoeft te wachten?

Voor de betrouwbaarheid is het belangrijk dat je niet alleen zelf deze tests kunt uitvoeren, maar dit ook door een ander zou kunnen laten doen. Daarom voeg je deze tests samen in een testplan waarin je ook beschrijft wat er allemaal nodig is om de tests uit te kunnen voeren.

Als je dit testplan vooraf voorlegt aan je opdrachtgever kan dit als je klaar bent tevens als garantie dienen dat je gemaakt hebt wat je met hem of haar hebt afgesproken.

Uitdagingen:

• Je hebt functionele eisen (of user stories)  omgezet naar meetbare specificaties (of definition of done) zodanig dat deze toetsbaar zijn.

Ik kan user stories maken door de eisen van de doelgroep omzetten naar  user stories. Hiervoor heb ik eerst een doelgroep analyse gehouden in periode 2, 3 en 4 voordat de user stories na constante iteratie echt daadwerkelijk af zijn. In periode 3 en 4 heb ik met mijn team de user stories gemaakt.

user stories en definition of done periode 2

User stories periode 3

user stories periode 4

Ik kan dan als de user stories/functioneel ontwerp af zijn omzetten naar een definition of done zodat deze toetsbaar zijn.In periode 3 en 4 heb ik met mijn team de definition of done gemaakt en in periode 2 had ik het zelf gedaan.

user stories en definition of done periode 2

definition of done periode 3

definition of done periode 4

• Je hebt de specificaties zodanig verwoord in een testplan dat met een simpel ja of nee aangegeven kan worden of aan deze specificatie is voldaan.

Ik kan de user stories zo verwoorden dat ze met een simpele ja of nee beantwoord kunnen worden. Dit is te zien in de Testplan van periode 4.

• Je hebt een testplan opgesteld waarin alle aannames (voor de test) en verwachte resultaten (tijdens de test) zijn opgenomen zodanig dat de test eenvoudig door een ander uitgevoerd of herhaald zou kunnen worden.

Ik kan alle user stories in het testplan verwerven en het test plan laat zien hoe die user stories getest worden. Dat maakt het heel overzichtelijk als iemand anders die gaat testen.

Testplan PlastiCats

• Je hebt een testplan uitgevoerd en daarmee bewezen (aan je opdrachtgever) dat het product voldoet aan de specificaties.

Ik kan het testplan uitvoeren. Dit is bewezen onder het kopje ‘vraag en beantwoording’ daarna volgt de ‘conclusie’ waar het effect van de resultaten worden besproken.

“Mijn computer is gecrasht en nu ben ik al mijn data kwijt …”

Omschrijving:

Dit zet je in om op een gestructureerde manier samen te werken en te archiveren. Je past versiebeheer toe, zodanig dat het een heel traject goed heeft gewerkt. Je kent meerdere varianten en kan beargumenteren wanneer welke variant in te zetten.

Uitdagingen:

• Je kan door middel van Git or SVN goed samenwerken aan een project, waarbij iedere programmeur zijn eigen inbreng heeft.

Bewijs Materiaal:

Ik heb dit block behaalt omdat ik samen met mijn team heb gewerkt aan het proect tijdens cle waarbij iedereen een beidrage heeft geleverd aan de git repository.

Hieronder is de link naar de repository.

https://github.com/RandomDesigner/Markthal

Omdat mijn terminal niet normaal zonder sudo met github wou werken maakte ik gebruik van sudo.  Dit kwam omdat we problemen hadden met de permissions van de repository dat te maken had met mijn account. Volgens Mathijs zijn view (hij was de repository creator) had hij mij permissions gegeven en dat heb ik ook kunnen zien op zijn scherm maar dat was niet het geval op andere apparaten/accounts. Dus om onnodige werk te voorkomen besloot Mathijs dat ik sudo zal ging gebruiken.

Ik heb gebruik gemaakt van de volgende commands:

• sudo git add .
• sudo git clone (url)
• sudo git commit -m “(hier vul je de waarde van de comment in)”
• sudo git push
• sudo git pull
• sudo git checkout (naam)

Ook werd er uitgelegd hoe ik van branch kon verwisselen door middel van een: sudo git checkout “banch-name”.

Alle command line commands moesten op mijn mac uitgevoerd worden met een sudo omdat er een probleem is met de permissions van onze repository, ook al is mijn account toegevoegd aan de permissions van de  repository blijft mijn terminal fouten geven aan de permissions. Verder werkt alles zoals het hoort.

Hieronder is een screenshot van de command line commands die zijn uitgevoerd.

“Een applicatie zonder content is als een strand zonder zand”

Omschrijving:
‘Content’ is in dit geval niet te verwarren met het synoniem voor ‘tevreden’!
Het gaat in dit geval wel om: Tekstuele (taalkundige) en visuele content die de ervaring van het product verrijkt. Content die klopt, die kwalitatief goed is en past bij het medium, die aansluit bij de doelgroep en (eventueel) een goed beeld geeft van de echte content als het product in gebruik genomen wordt. Je kunt voor de gemaakte producten de juiste content (tekstueel én visueel)creëren waardoor het product bij oplevering gevuld is en de juiste boodschap kan overdragen.

Uitdagingen:

Je content is zodanig op het medium afgestemd dat het de ervaring van het product verrijkt;

In periode 3 heb ik een website gemaakt dat de content uit een database en 2 api’s haalt. Deze content is dus volledig op het medium afgestemd want het hele concept is gebaseerd op het ophalen van content dat het product ultiem verrijkt. 

Het concept was om voor de bezoekers van de Markthal een overzicht te geven met alle kramen erin. Als de Gebruiker op een kraam klikt, dan ziet de gebruiker allemaal content dat het medium verrijkt. Deze content is zelfs dynamisch en past zich aan op de selectie van content waar de user zichzelf begeeft. 

Om dit duidelijker te maken: Als de gebruiker op de website komt dan ziet hij/zij een overzicht van alle kramen in de markthal dat betrekt dus niet de restaurants. Deze komen van mijn database met een titel en foto. Als de user op een kraam klikt dan gaat de website naar de volgende rendering van dynamische data op basis van de selectie. (De gebruiker verplaatst niet van pagina tot pagina) Daaruit kan de gebruiker ervoor kiezen om meer context van de kraam te laten zien of de gebruiker kan gelijk verder gaan naar de recepten overzicht rendering ook met titel en foto. Deze recepten hebben iets te maken hebben met de producten van de kraam. Daarna kan de gebruiker weer op een recept titel of foto klikken waardoor de gebruiker naar de volgende rendering gaat waar de titel,  de foto, de benodigdheden voor het recept tevoorschijn komen.

De website is hier te vinden.

Je kent de doelgroep en hebt daar je content zodanig op afgestemd dat het product de beoogde boodschap overbrengt;

Doelgroep Onderzoek

In het begin van periode 3 gingen mijn team en ik gezamenlijk naar de markthal om de doelgroep te interviewen. Zo konden we de doelgroep in kaart  brengen een daarmee konden we aan de slag met het verder ontwerpen. Doordat we de doelgroep nu kennen gingen we meteen aan de slag om een style guide. Dit zou de content die we zouden tonen nog beter laten afstemmen op de doelgroep.

De content is zodanig op de doelgroep afgestemd omdat de content altijd formeel is en geen onnodige taal fouten bevat. De content is ook deels afkomstig van een api die de gebruiker/doelgroep alleen pas ziet wanneer de gebruiker dat wilt. Deze content bevat de behoeften van de doelgroep juist en kan de gebruiker/doelgroep zelfs inspireren voor wat ze willen gaan eten in de toekomst.

De website is hier te vinden.

Je content bevat doordachte visuele ondersteuning (foto’s, grafieken, schema’s, kleuren, beelden, lettertypes) en deze is zodanig afgestemd dat ze een geheel vormt;

De website is ontworpen met een ‘style guide’ waarbij verschillende fonts, font grootes en font kleuren zijn bepaald. Verder maakt het ook gebruik van foto’s van de kramen en gerechten die gemaakt kunnen worden met de producten van de kraam.  Ook zijn er foto’s aanwezig in bepaald scherm waarbij de foto’s van social network instagram die gebaseerd zijn op de huidige kraam selectie van de gebruiker. Dit is gekoppeld aan ons product dat de ervaring nog meer verhoogd.

Je kunt een concept zodanig overtuigend presenteren dat de klant akkoord gaat met de voorgestelde uitwerking.

In periode 3 hebben we nog onderzoek gedaan of de doelgroep akkoord gaat met de voorgestelde functionaliteiten van het concept. Hiervoor zijn we gezamenlijk naar de markthal gegaan. Ons team van periode 3 bestond uit 4 personen, we hadden ons verdeeld in 2 groepen. Per groep zou iemand de vragen van de vragenlijst een voor een stellen aan de doelgroep.  Aan het einde van de interview presenteerden we duidelijk de functionaliteiten van ons concept zonder slides te gebruiken. Het resultaat hiervan is dat iedereen die we hebben gesproken zeer positief zijn  over onze voorgestelde uitwerking.

De resultaten van het onderzoek zijn hier te vinden.

Aan het einde van de CLE periode 3 was er ook een eindmarkt waar ik mede studenten ons concept zodanig pitchte dat ze onder de indruk waren van ons concept. En dan moet ik toevoegen dat het ook mede verantwoordelijk was doordat ons concept goed doordacht was en een basis bevat die ik had bezorgd die in de toekomst nog verder uitgewerkt zou kunnen worden.

Bewijs Materiaal:

Omschrijving:

• Er is planmatig te werk gegaan bij het maken van software waarbij het volgende is duidelijk geworden:
  • je bent in staat het vraagstuk in deelproblemen op te delen en hebt aangetoond dat je de deelfunctionaliteit hebt kunnen benoemen met hun individuele verantwoordelijkheid.

Ik ben in staat om het vraagstuk in deelproblemen op te delen omdat ik met mijn team in periode 3 en 4 een functioneel ontwerp heb gemaakt waarbij  we alle deelproblemen in een document hebben geformuleerd en daarbij elke verantwoordelijkheid benoemd. Het functionele ontwerp document staat onderin de blog post.

• voor de flow van het systeem ben je in staat om stappen in het proces vooraf uit te denken (pseudo code)

Ik ben in staat om de flow van het systeem in stappen vooraf uit te denken omdat ik met mijn team in periode 3 en 4 een technisch ontwerp heb gemaakt waarbij we de pseudo code vooraf hebben bedacht. Het technische ontwerp document staat onderin de blog post.

• je bent zelfstandig tot technische oplossingen gekomen voor deelproblemen (geen oplossingen van anderen of internet overgenomen). Daar waar nodig is hier technisch onderzoek aan vooraf gegaan waardoor je tot de juiste conclusie bent gekomen.

Ik ben instaat om zelfstandig tot technische oplossingen te komen omdat ik dat ook heb gedaan in periode 3 en 4. Doordat ik de kennis  bij de lessen van programmeren eigen heb gemaakt ben ik daartoe instaat om in projecten op eigen oplossingen te komen.

• gemaakte keuzes zijn vastgelegd (gedocumenteerd) en verantwoord, zodanig dat uit de verantwoording de kwaliteit van jouw keuzes blijkt.

ik ben instaat om gemaakte keuzes vast te leggen en te verantwoorden omdat we gezamenlijk als team in periode 3 en 4 bepaalde keuzes hebben moeten maken met een bepaalde reden en dat is dus de verantwoording. Alle gemaakte keuzes en verantwoordingen zijn te vinden in de technische ontwerpen document onder in de blog post.

• Je kunt op professionele wijze je ontwerp documenteren:
  • technische keuzes zijn vastgelegd en verantwoord

ik ben instaat om gemaakte keuzes vast te leggen en te verantwoorden omdat we gezamenlijk als team in periode 3 en 4 bepaalde keuzes hebben moeten maken met een bepaalde reden en dat is dus de verantwoording. Alle gemaakte keuzes en verantwoordingen zijn te vinden in de technische ontwerpen document onder in de blog post.

• er is een match tussen functioneel ontwerp en technisch ontwerp

Ik ben instaat om een match te maken met het functioneel ontwerp en het technische ontwerp omdat mijn pseudocode / systeem flow overeenkomt met de functionaliteiten van de game in periode 4.

• Je gebruikt standaarden zodat communicatie vereenvoudigd wordt zoals:
  • klassendiagram
  • ERD
  • Flow chart

Ik kan gebruik maken van standaarden zoals een klassen diagram, ERD en Flowchart omdat dit helpt het concept duidelijker uit te kunnen leggen. Met deze standaarden kan je visueel je concept uit leggen en veel gestructureerder dan als je het zelf moet uitleggen zonder deze standaarden.

• Er is rekening gehouden met hergebruik van code voor onderdelen in hetzelfde project en voor toekomstige projecten. (denk aan: HTML-Templates, css classes, functie-libraries, config-bestanden)

Alle code die ik heb gemaakt in periode 3 en 4 kan ik hergebruiken in toekomstige projecten. In mijn geval is het alleen javascript maar dat betekent niet dat ik het niet kan hergebruiken.

Bewijs Materiaal

Functioneel & Technisch Ontwerp Document CLE 4

Technische Ontwerpen Document CLE 3

Functioneel Ontwerp Document CLE 3

PlastiCats Klassen Diagram/UML CLE 4

QRP ERD CLE 2 

ERD CLE 3

PlastiCats ERD CLE 4

Flow Chart CLE 4

Site Map CLE 2 (user)

Site Map CLE 2 (admin)

Omschrijving:

De doelgroep van het product en de omgeving waarbinnen het product gebruikt gaat worden, zijn in kaart gebracht (context).

Je kunt meerdere testmethoden benoemen, zodanig dat je kunt afwegen wanneer je in het proces bij welke testpersonen de test kunt afnemen.

Je kunt verantwoorden welke test(s) je inzet binnen de ontwikkeling van het specifieke product.

Je kunt reflecteren op hoe de echte gebruikers naar jouw verwachting gaan reageren op jouw product.

Uitdagingen:

• Je kent meerdere testmethoden, zodat je de verschillen tussen de testmethoden kunt benoemen;

Nu ik het jaar achter de rug heb, heb ik voor de ontwerpen vakken meerdere test methodes geleerd. Namelijk de Clickstream onderzoek, Card Sorting Test, 5 Second Test, A/B Test en Blackbox test.

Ik weet dat je bij het Click stream onderzoek bent naar de dominante pad van je website/applicatie/game. Je laat je doelgroep bepaalde acties uitoefenen en werkt de resultaten uit tot een clickstream van het dominante pad.  Met ook de paden die je andere test persoon hebben afgelegd maar niet het dominante pad blijkt te zijn.

Een Cad sorting Test laat je tester je voorbedachte navigatie termen  verdelen in de volgorde die voor hun het  meest logisch lijkt.

Bij een 5 Second Test, test je hoe goed je test persoon je website/applicatie/game kan onthouden nadat de test persoon 5 seconden de tijd heeft gehad om de indeling, kleuren, text en andere elementen te kunnen bekijken.

Met een A/B test test je van je groep test personen de ene helft variant A en bij de andere helft variant B van je website/applicatie/game.

Tenslotte de Black Box test waarbij de tester alleen kijkt naar de functionaliteit maar de tester kent de werking van de applicatie niet.

• Je kan een test opzet maken, zodat je aan de hand daarvan de test kan uitvoeren;

Ik heb inmiddels meerdere testplannen opgezet en uitgevoerd, hier zijn een paar voorbeelden:

5 second test QRP versie 2

Black Box Test QRP versie 2

Card Sorting Test QRP versie 2

Testplan PlastiCats

• Je hebt verschillende typen tests uitgevoerd, waarbij je de gemaakte keuzes onderbouwt;

In de bovenstaande documenten staan de gemaakte keuzes. wel kan ik hier vertellen dat die keuzes verschillen tussen de layout van je website, toon/font/lettertype/kleur/achtergrondkleur of werking van applicatie. Dus de keuzes die gemaakt kunnen  worden hebben te maken met de structuur, detail of werking van de applicatie.

• Je hebt je product met (tenminste 3) representatieve deelnemers getest;

Zoals te zien is in de documenten zijn de 5 Second Test en A/B Test door 3 deelnemers getest.

• Je kunt testresultaten analyseren, documenteren en visualiseren, om de testresultaten inzichtelijk te maken voor anderen;

Ik heb inmiddels meerdere testplannen opgezet en uitgevoerd met test resultaten die ik geanalyseerd heb en gevisualiseerd heb, hier zijn een paar voorbeelden:

5 second test QRP versie 2

Black Box Test QRP versie 2

Card Sorting Test QRP versie 2

Testplan PlastiCats

• Je kunt uit de tests conclusies trekken die je inzicht geven voor een volgende iteratie of stap in het proces.

De documenten hierboven bevatten conclusies na de resultaten die mij hielpen met het concept verder uit te werken.

“We kunnen gewoon gelijk beginnen met bouwen, toch?”

Omschrijving:

Je hebt voor tenminste 2 verschillende devices interactie-ontwerpen uitgewerkt. Je kent de onderdelen die samen informatie-, interface- en interactie-ontwerpen vormen en de verschillen hiertussen en kunt hiervoor verschillende media- en device vormen interactie-ontwerpen maken.

Uitdagingen:

• Je kunt uit het concept de functionele requirements extraheren, zodanig dat je tot een onderbouwd informatie-, interface- en interactie-ontwerp kunt komen;

Ik kan vanuit een Technische Ontwerp en Functioneel Ontwerp de functionele requirements extraheren zodat de informatie-, interface- en interactie-ontwerpen gemaakt kunnen worden.

• Je kunt voor een informatie-, interface- en interactie-ontwerp de verschillende onderdelen benoemen, zodanig dat je weet welke functie deze documenten in het geheel hebben en wat hun rol in dit geheel is;

In het Technische Ontwerp en Functioneel Ontwerp  staat al aangegeven wat de rollen zijn van de verschillende onderdelen

• Je kunt voor tenminste 2 verschillende devices een informatie-, interface- en interactie-ontwerp opstellen, zodanig dat het aansluit op de doelgroep en de context;

Ik kan informatie-, interface- en interactie-ontwerpen voor 2 verschillende devices maken. Door middel van een Sitemap, navigatie modellen, content areas, wireframes, activity diagram, style guide en werkend prototype.

In periode 3 heb ik samen met mijn CLE team voor de markthal informatie-, interface- en interactie-ontwerpen voor een mobile device en een tablet device gemaakt.

Hier is het Interactie Ontwerp Markthal te vinden.

• Het informatie-, interface- en interactie-ontwerp is volledig, zodanig dat je het kunt omzetten in een werkend prototype.

Hier is de markthal prototype en jammer genoeg heb ik niet het werkelijke eind product die 100% klopt volgens de informatie-, interface- en interactie-ontwerpen.

• sudo git add .
• sudo git commit -m “”
• sudo git push
• sudo git pull

Ook werd er uitgelegd hoe ik van branch kon verwisselen door middel van een: sudo git checkout “banch-name”.

Alle command line commands moesten op mijn mac uitgevoerd worden met een sudo omdat er een probleem is met de permissions van onze repository, ook al is mijn account toegevoegd aan de permissions van de  repository blijft mijn terminal fouten geven aan de permissions. Verder werkt alles zoals het hoort.

Hieronder is een screenshot van de command line commands die zijn uitgevoerd.

Ook ging ik verder werken aan de code die voor de user stories af gemaakt moesten worden. Hier maakte ik een goed begin aan het project door de main.js bestand aan te maken en daar als eerste alle functies in een goede volgorde toe te voegen zoals we dat die dag ervoor hadden geleerd van onze docenten. Ook maakte ik gebruik van een inventarisatie word bestand met daarin alle functies uitgeschreven op basis van de user stories van must-haves en de should-haves.

Verder kreeg ik de code niet af die dag alleen heb ik wel een begin gemaakt aan een paar functies en met wat debugging zou het werken

Vandaag had ik de moscow analyse gemaakt in voorbereiding op de sprint 2

Wat heb ik vandaag gedaan:

Er is een begin gemaakt aan de prototype waarbij een website gebouwd zal worden wel hadden we de vorige week al een paper prototype en wireframes af. Maar we wouden een functionele prototype hebben voor vrijdag.

De database tabellen zijn afgemaakt en een tabel is bijna helemaal voorzien van informatie. Dit was echt een tijd rovend proces.

Ook ben ik een cursus van pluralsight begonnen waarbij ik een beetje heb geleerd over het begrip van fluid, adaptive en responsive mobile website.

Uitdagingen:

• Je hebt relevante bronnen op een correcte wijze verwerkt in tekst en bronnenlijst zodanig dat anderen een goed inzicht krijgen in je onderbouwing.

• Je hebt het onderzoeksdoel zodanig afgebakend dat je een onderzoeksvraag kunt formuleren.

• Je kan een onderzoeksmethode selecteren en uitwerken zodanig dat je daarmee een antwoord kunt vinden op de onderzoeksvraag.

• Je weet data te verzamelen en weer te geven zodanig dat je conclusies kunt trekken en aanbevelingen kunt doen.

• Je kunt zodanig op je eigen onderzoek reflecteren dat de sterke en zwakke punten van het onderzoek en jouw rol daarin duidelijk worden.

• Je gaat zodanig met je onderzoeksomgeving en deelnemers om dat je hiermee respect toont.