Prototyping: de nieuwe vorm van documenteren

Inleiding

In de afgelopen decennia is de complexiteit van IT-systemen fors toegenomen. Daar waar IT-systemen in het verleden vaak het automatiseren van bestaande bedrijfsprocessen en verdienmodellen betekenden, spelen IT-systemen nu in toenemende mate een belangrijke rol in het veranderen van deze processen en verdienmodellen. Hierdoor wordt de rol van IT-systemen steeds belangrijker en is de afhankelijkheid van de systemen toegenomen.

Het is dan ook niet verwonderlijk dat er een grote behoefte is ontstaan aan het goed documenteren van onder andere de functionele aspecten van deze systemen. De afgelopen jaren is er veel tijd besteed aan het vastleggen en ontwerpen van de systemen voordat deze werden ontwikkeld en in productie werden genomen. Dit resulteerde veelal in een uitgebreide set met documentatie, waaronder een functioneel ontwerp van bijvoorbeeld meer dan honderd pagina’s. Het ontwerp en de documentatie daarvan namen veel tijd in beslag. Helaas kwam men er pas vaak na de implementatie achter dat de gebouwde functionaliteit niet in lijn was met de verwachtingen van de gebruikers.

Door de toenemende en snel veranderende vraag van alle stakeholders (business, eindgebruikers, investeerders et cetera) is het niet haalbaar om zo veel tijd in dit ontwerp- en documentatieproces te steken. Daarnaast is de laatste jaren gebleken dat het door de constant veranderende vraag steeds belangrijker wordt om in een vroeg stadium ontwerpen te kunnen aanpassen en te kunnen afstemmen met de stakeholders.

Dit artikel biedt een handreiking om de toenemende en constant veranderende vraag op een flexibele wijze te ondersteunen. Met behulp van de genoemde voorbeelden en methoden wordt het mogelijk de ontwerpfase op een agile manier in te richten. Allereerst worden de problemen van de klassieke wijze van ontwerpen en documenteren uitgelegd, waarna concrete oplossingen worden gegeven voor het ontwerp op een agile wijze met behulp van prototyping en wireframes. Daarnaast komt aan bod hoe het prototype een rol kan spelen in het documenteren van het systeem.

Problemen met de klassieke manier van documenteren

Door de jaren heen ben ik betrokken geweest bij de ontwikkeling en het ontwerp van tal van complexe IT-systemen voor profit- en non-profitorganisaties. Of het nu ging om de uitbreiding van bestaande systemen of het geheel opnieuw ontwerpen van systemen, in veel gevallen werd voor de aanvang van de ontwikkeling op een watervalachtige wijze een grote hoeveelheid documentatie opgesteld. Deze documentatie lijkt een bepaalde mate van controle te geven, maar helaas, schijn bedriegt. In deze paragraaf zal ik de grootste problemen met deze wijze van documenteren nader beschrijven. Hierbij wil ik wel benadrukken dat het uitgebreid documenteren van complexe systemen een goede zaak is, alleen dat er veel gewonnen kan worden in de wijze waarop.

Documentatie is vaak te technisch van aard

Hier volgt een voorbeeld van een technische beschrijving.

Dit voorbeeld beschrijft wat er gebeurt in het systeem. Om echter te verifiëren of het correct is wat hier gebeurt, dient onder andere de business betrokken te worden. Zelfs voor iemand met een technische achtergrond is de tekst erg lastig te verifiëren. Weet u exact wat er bedoeld wordt? Nu is dit een voorbeeld uit een technisch document. Dit maakt het lezen van de tekst complexer. Het volgende voorbeeld laat echter zien dat ook een functionele omschrijving van het systeem vaak lastig te interpreteren is voor alle betrokkenen.

Veel systemen worden op deze wijze gedocumenteerd. Dit brengt een groot risico met zich mee, namelijk: hoe kan men garanderen dat de juiste functionaliteit wordt ontwikkeld op het moment dat de betrokkenen niet in staat zijn de functionele aspecten van een systeem te begrijpen?

Documentatie wordt niet of nauwelijks gelezen door ontwikkelaars

Programmeurs houden van het creëren van systemen en het technisch oplossen van problemen. Een herkenbaar beeld is dan ook dat een ontwerper zegt tegen een programmeur: ‘Maar dit staat op pagina 65 van het functioneel ontwerp omschreven, waarom is dit dan niet gebouwd?’ Uit eigen ervaring kan ik concluderen dat naarmate de hoeveelheid documentatie toeneemt, deze minder nauwkeurig wordt gelezen. Een programmeur zal eerder beginnen met programmeren dan met het doorlezen van grote stapels papier. Vaak worden technische en functionele documenten door ontwikkelaars vluchtig gescand en vervolgens zullen de meeste programmeurs naar eigen inzicht de ‘gewenste’ functionaliteit ontwikkelen. Doorgaans leidt dit tot een systeem dat gebouwd is conform de documentatie. Op zich is de impact van dit probleem minder dramatisch dan het lijkt. De meeste stakeholders waren namelijk niet in staat de geschreven tekst correct te beoordelen. Veelal wordt afgegaan op dat wat ontwikkeld wordt en zichtbaar is. Na de oplevering leidt dit tot ingrijpende wijzigingen omdat de stakeholders vinden dat de ontwikkelde software niet aan hun eisen voldoet. Dit leidt tot budgetoverschrijdingen of zelfs het stopzetten van projecten. Men kan zich terecht afvragen wat het nut nog is van het langdurige documentatieproces bij aanvang van een project.

Bijwerken van documentatie kost veel tijd en gebeurt daarom vaak niet

Het opstellen van documentatie op de klassieke manier kost erg veel tijd. Gedurende de ontwikkeling of het in productie zijn van systemen worden er veel wijzigingen doorgevoerd. Aangezien deze aanpassingen vaak al op een iteratieve manier plaatsvinden, worden ze vaak niet verwerkt in de documentatie (ook tijdens de beheerfase van een project). Simpelweg omdat er geen tijd of budget voor is, of omdat er niet aan gedacht wordt. In veel gevallen is na een aantal wijzigingen de uitgebreide set van documentatie niet meer in lijn met het operationele systeem. Hierdoor verliest de documentatie al haar waarde en kan men deze investering als verloren beschouwen.

Documentatie kan op verschillende manieren worden geïnterpreteerd

Het laatste grote probleem betreft een ander vlak, namelijk dat van interpretatie. Als u bijvoorbeeld denkt aan een lawn chair, dan denkt u vast niet aan de stoel in figuur 1. Een beschrijving van functionaliteit zal niet altijd tot dezelfde oplossing leiden. Tekst laat zich vaak op verschillende wijzen interpreteren. Het is dan ook zeer lastig om een beeld te krijgen van een applicatie wanneer deze alleen tekstueel is beschreven. Door de interpretatieverschillen wordt het lastig de beschreven functionaliteit te controleren op correctheid. Hoe kunnen we met een tekstuele beschrijving garanderen dat het juiste ontwikkeld gaat worden?

Figuur 1. Een andere interpretatie van ‘lawn chair’.

Samengevat zien we de volgende problemen met de klassieke wijze van documenteren:

1. Documenten zijn te technisch van aard en worden hierdoor niet begrepen door de stakeholders. Klopt het wel wat er in de documentatie staat? En voldoet de ontworpen functionaliteit wel aan de verwachtingen van de stakeholders?
2. Documentatie wordt vaak niet gelezen door de ontwikkelaars.
3. Documentatie wordt vaak niet up-to-date gehouden. Welke waarde heeft een achterhaald document nog?
4. Documentatie kan op verschillende manieren worden geïnterpreteerd. Hebben de stakeholders en de ontwikkelaars de documentatie op de juiste wijze geïnterpreteerd?

Een andere manier van documenteren

Hoe kunnen we ervoor zorgen dat documenteren nuttig wordt? Om hier een antwoord op te geven moeten we een onderscheid maken tussen technische documentatie (bedoeld voor de technische inrichting van een systeem) en functionele documentatie gericht op het overbrengen van de eisen en wensen van de stakeholders (business, eindgebruikers et cetera).

Aangezien de huidige manier van documenteren niet het gewenste resultaat oplevert en erg tijdrovend is, moeten we dan maar ophouden met documenteren? Nee, zeker niet, maar wat moeten we dan wel?

Iedereen kent de uitdrukking ‘een afbeelding zegt meer dan duizend woorden’. Hoe kunnen we gebruikmaken van afbeeldingen gedurende het ontwikkeltraject? Het antwoord hierop is: door prototyping toe te passen. Maar wat is een prototype eigenlijk? Er bestaan tal van verschillende definities van ‘prototype’. In dit artikel wordt deze definitie gebruikt: ‘Door gebruik te maken van visualisatie snel inzicht geven in een idee (concept, proces of product) voor alle betrokkenen (stakeholders).’ Hierbij worden de volgende uitgangspunten gehanteerd:

• Een prototype levert meerwaarde wanneer dit gebruikt wordt gedurende het complete ontwikkeltraject van een product.
• Visualisatie maakt complexe materie te begrijpen voor alle betrokkenen.
• Een prototype wordt iteratief ontwikkeld en betrokkenheid van de stakeholders is noodzakelijk.

Prototypes worden van oudsher veelvuldig toegepast in het ontwerpproces van bijvoorbeeld gebouwen, auto’s en andere voorwerpen. Het is dan ook niet verwonderlijk dat prototyping een vlucht neemt binnen de softwareontwikkeling.

Hoe kunnen we prototypes goed toepassen voor softwareontwikkeling?

Zoals de bovenstaande definitie aangeeft kan een aantal van de eerdergenoemde problemen worden opgelost door middel van prototyping, maar hoe kan dit worden toegepast binnen de softwareontwikkeling? Het deels programmeren van een stuk code als prototype is een tijdrovende zaak en daarbij is de kans groot dat het prototype van de ontworpen applicatie niet blijkt te werken en moet worden aangepast. Een ander probleem van deze aanpak is dat een programmeur de rol van de ontwerper dient over te nemen.

Op welke wijze kunnen we dan wel prototyping inzetten? De oplossing hiervoor zijn wireframes. Wireframes zijn een visueel hulpmiddel ofwel de bouwtekeningen van een systeem. Denk hierbij aan de lijntekeningen van een architect bij bijvoorbeeld de bouw van een huis (blueprint). Voor het vastleggen van het ontwerp van een website kunnen met deze schetsen de paginalay-out en content maar ook de navigatiestructuur worden gevisualiseerd. Zo zijn in figuur 2 wireframes gebruikt voor het ontwerp van een nieuwe interface voor een webapplicatie.

Figuur 2. Toepassing van wireframes voor het ontwerp van een nieuwe interface voor een webapplicatie.

De ontwerper kan met behulp van wireframes aan het begin van een traject de functionaliteit van een applicatie vastleggen. Hierbij wordt er in eerste instantie gekeken naar de benodigde functionaliteit. Als er gebruik wordt gemaakt van de agile Scrum-methodiek, zullen de user stories het uitgangspunt zijn voor het opzetten van deze prototypes. We zien ook vaak dat er nieuwe user stories ontstaan op basis van het prototype. Door deze prototypes wordt vaak inzichtelijk of de huidige set van user stories alle wensen van de stakeholders afdekt.

Een user story bestaat uit de volgende onderdelen:

Ik als [doelgroep] (bijvoorbeeld: websitebezoeker) kan [actie] (bijvoorbeeld: inloggen op de website), zodat ik [reden] (bijvoorbeeld: privéberichten kan ontvangen van andere gebruikers).

Er bestaat een onderscheid tussen de gedetailleerdheid van prototypes, namelijk tussen low-fidelity en high-fidelity prototypes. Een low-fidelity prototype is bijvoorbeeld een schets op papier, terwijl een high-fidelity prototype bijvoorbeeld een uitgewerkt grafisch en interactief prototype in HTML is (zie figuur 3).

Figuur 3. Low-fidelity en high-fidelity prototypes.

Wanneer wordt welk soort prototype gebruikt? Verderop zal ik uitgebreider stilstaan bij de inzet van de verschillende prototypes in een agile ontwikkelproces. De inzet van de verschillende vormen van prototypes is afhankelijk van het gewenste eindresultaat, maar algemeen kunnen we stellen dat er altijd eerst een globale schets op papier wordt gemaakt voordat men overgaat naar een meer high-fidelity prototype. Het schetsen van een interface met pen en papier is nu eenmaal de snelste en eenvoudigste manier om een applicatie in beeld te brengen en eenvoudig aan te passen. Na deze schets is het wenselijk om over te gaan naar interactieve prototypes. Met bepaalde tools kan men eenvoudig interactieve prototypes maken waar alle stakeholders mee kunnen interacteren. Hiermee wordt niet alleen de indeling van een applicatie inzichtelijk gemaakt, maar wordt ook de interactie (ofwel de flow van de applicatie) duidelijk zonder dat er code hoeft te worden geschreven.

Daar waar een afbeelding meer zegt dan duizend woorden, kunnen we wel stellen dat interactie meer zegt dan duizend afbeeldingen. Het grote voordeel van het gebruik van interactieve prototypes is dat het ontwerp en de flow van de applicatie in een vroeg stadium kunnen worden getest bij alle stakeholders. In de praktijk werkt het erg goed om de stakeholders bij elkaar te brengen en in een workshopsetting door deze interactieve wireframes heen te lopen en op deze manier de verfijning van de eisen en wensen te bespreken.[Aan het eind van dit artikel vindt u een overzicht van verschillende tools die hiervoor kunnen worden gebruikt.]

Tabel 1. Wireframe: wat is het en wat is het niet?

Prototyping binnen agile development

De laatste jaren zien we een toename in de vraag naar user experience design en usability design. Deze ontwerpmethoden hebben één belangrijk kenmerk gemeen: hoe kun je ervoor zorgen dat de applicatie niet alleen eenvoudig is in gebruik maar dat de beleving en de flow van de applicatie correct aansluiten bij de doelen en belevingen van de gebruikers? Het uiteindelijke doel: verhogen van de klantvriendelijkheid, het klantvertrouwen maar ook de klantproductiviteit. Prototyping, mits goed toegepast, is hierbij noodzakelijk.

Begin met prototyping/ontwerpen bij de start van het project. Direct beginnen met prototyping en ontwerpen is van essentieel belang voor het succes van een applicatie. Meerdere onderzoeken hebben aangetoond dat het aanpassen van ontwerpfouten in latere fasen van een traject tot honderd keer zoveel geld kost als het vroegtijdig goed opzetten van het ontwerp ([HFI14]). Moeten we dan weer terug naar de watervalmethode om dit ontwerp aan het begin te doen? Absoluut niet.

Met behulp van prototyping kan het ontwerp op dezelfde wijze worden opgedeeld als bij de te ontwikkelen functionaliteit gebeurt op basis van user stories. In agile Scrum-trajecten zien we eigenlijk twee veelgebruikte manieren om de prototypefase iteratief te laten verlopen:

1. Ontwerp/prototyping loopt één iteratie voor op de ontwikkeling (maar kan tijdens de ontwikkelingsiteratie worden bijgesteld).
2. Ontwerp/prototyping vindt plaats gedurende de iteratie en het hele team is erbij betrokken.

Hierbij zien we dat vooral de tweede methode veel gebruikt wordt bij start-ups die gebruikmaken van de lean-start-upmethodologie, terwijl er bij grotere softwareontwikkeling vaak gekozen wordt voor de eerste implementatie. Figuur 4 geeft schematisch weer hoe dit er in een planning uit kan zien.

Figuur 4. Planningsoverzicht.

Het inpassen van prototyping binnen de agile ontwikkelmethodiek heeft de volgende voordelen:

• Visualisatie helpt stakeholders bij het formuleren van hun eisen en wensen. Hierbij werkt een prototype beter dan een lijst user stories.
• Interactie en functionaliteit worden snel getest bij de stakeholders en gebruikers.
• Het design kan snel worden aangepast aan technische onmogelijkheden.
• Programmeurs en user experience designers werken nauw samen, waardoor de juiste applicatieonderdelen worden gebouwd.
• Programmeurs werken met een interactief prototype en hoeven hierdoor geen stapels documentatie te lezen.

Wat is er gebeurd met de documentatie?

Wanneer gebruik wordt gemaakt van agile Scrum, wordt begonnen met het opstellen van de user stories. De user stories vormen de basis voor alle ontwikkelingen. Ze dienen gezien te worden als deel van de documentatie. Aan het einde van een iteratie wordt namelijk op basis van deze user stories bepaald of dat wat gebouwd wordt voldoende functioneert. Aangezien een user story nog geen beeld geeft van de daadwerkelijke implementatie, vullen interactieve wireframes dit gat op.

Met de moderne tooling om interactieve wireframes op te stellen kan tekst worden toegevoegd aan de interactieve wireframes. Hierbij gaat het niet om het beschrijven van wat geprototyped is, maar vooral van wat niet geprototyped is. Op het moment dat er een wijziging in de applicatie moet worden doorgevoerd, dient deze eerst te worden voorgelegd aan de stakeholders, ofwel: het prototype moet ook worden gewijzigd. Hierdoor ontstaat er altijd een up-to-date ontwerp dat voor elke stakeholder te begrijpen is.

Conclusie

Ontwerp begint een steeds belangrijkere rol te spelen binnen de softwareontwikkeling. Daarbij is het van belang dat nieuwe functionaliteit steeds sneller wordt opgeleverd. Met behulp van interactieve wireframes kunnen we al in de beginfase van de ontwikkeling nauwkeurig toetsen of het systeem voldoet aan de wensen van de stakeholders. Daarnaast kan deze methodiek van ontwikkeling voor een correcte set van documentatie zorgen aan het einde van de ontwikkeling, maar ook gedurende de beheerfase van het systeem. Een prototype kan eenvoudig worden bijgewerkt.