Managed hosting door True

Prototyping niet 'snel en slordig'

Succesvol toepassen van rapid application development, deel 2

 

Voor een grote groep systeemontwikkelaars is prototyping nog steeds een omstreden communicatietechniek bij het realiseren van informatiesystemen. Zij menen dat geen gebruik wordt gemaakt van een duidelijke gefundeerde werkwijze en vinden deze aanpak 'snel en slordig'. Consultant Laurens van Wonderen beschrijft een gestructureerde aanpak die is ontwikkeld op basis van praktijkervaring. Hiermee is prototyping doeltreffend toe te passen binnen rapid application development.

Prototyping is het actief toetsen van een werkend model van delen (partities) van een informatiesysteem, waarin bepaalde aspecten worden benadrukt. Deze techniek wordt vooral gehanteerd bij het ontwikkelen van administratieve informatiesystemen. Veel systeemontwikkelaars passen prototyping niet juist toe. Men realiseert in een kort tijdsbestek een voorbeeldsysteem en gaat het vervolgens door middel van trial and error afstemmen en verder uitwerken met gebruikers. Dit resulteert in veel gevallen in teleurstelling bij het management. Door het uitlopen van het project vallen de kosten namelijk tegen of het systeem blijkt in de praktijk toch niet bruikbaar te zijn.
Desondanks kan prototyping ook succesvol worden toegepast. Vooral binnen rad-projecten speelt het een belangrijke rol als communicatietechniek. Rapid application development gaat namelijk uit van een grote en actieve gebruikersparticipatie. In deze aanpak is prototyping één van de technieken die moet worden gehanteerd om de communicatie en samenwerking tussen de rad-teamleden te vergroten. In zo'n team zijn zowel ontwikkelaars als gebruikers vertegenwoordigd. Alle teamleden zijn verantwoordelijk voor de ontwikkeling van het informatiesysteem. In het team zitten bekwame gebruikers met een goed beeld van wat tegenwoordig in de automatiseringswereld mogelijk is. Zij hebben meestal geen tijd en zin om een groot aantal specificaties te bestuderen zonder dat duidelijk wordt wat het systeem werkelijk gaat inhouden. De betreffende - abstracte - specificaties zijn voor hen moeilijk toegankelijk, op vele wijzen te interpreteren en vaak niet volledig. Door een prototype worden gebruikers in staat gesteld direct te beoordelen of hun wensen op de juiste manier zijn geïnterpreteerd. Het overbrugt de communicatiekloof tussen gebruikers en ontwikkelaars. Een prototype is een middel om snel duidelijkheid te krijgen over bepaalde aspecten van het informatiesysteem. Hierdoor kan een snellere en beter gefundeerde besluitvorming plaatsvinden. Tevens geldt dat het systeem beter zal aansluiten op de wensen van de gebruikersorganisatie als gevolg van de actieve participatie van de gebruikers. Dit zal de acceptatie vereenvoudigen en de invoer van het systeem versnellen. Daarnaast zal het een gunstig effect hebben op toekomstige onderhoudskosten.
Een belangrijke voorwaarde voor het toepassen van prototyping is dat een prototype binnen een kort tijdsbestek kan worden gerealiseerd. Hiervoor zijn tegenwoordig goede i-case-tools beschikbaar. Met behulp van deze tools zijn prototypen op basis van in de repository geregistreerde specificaties te genereren. Wijzigingen in de functionaliteit worden aangebracht door de betreffende specificaties in de repository van het i-case-tool aan te passen en vervolgens het prototype opnieuw te genereren.

Gestructureerd prototypen

Als men bij het toepassen van prototyping niet planmatig, doordacht en gestructureerd werkt, zal prototyping resulteren in een oneindig proces van toetsen, aanpassen, toetsen, aanpassen enzovoort; met als gevolg gefrustreerde gebruikers en ondoorzichtige programmatuur. Om deze problemen te voorkomen heeft Consultdata een gestructureerde aanpak ontwikkeld voor prototyping als onderdeel van de rad-methode. Hierbij wordt onderscheid gemaakt in verschillende soorten prototypen. In elk soort prototype wordt een ander aspect benadrukt, namelijk:
de gebruikersinterface; het gegevensmodel; de functionaliteit, en de
de techniek.
Deze prototypen spelen vooral binnen de user design-fase van rad een belangrijke rol. In deze fase wordt eerst de gebruikersinterface, vervolgens het gegevensmodel en daarna per partitie de functionaliteit afgestemd. Een technisch prototype zal alleen op ad-hoc basis worden gerealiseerd voor het beantwoorden van technische vragen, zie figuur 1.

Gebruikersinterface

Ten behoeve van het afstemmen van de gebruikersinterface wordt een prototype gemaakt met een menu, een aantal schermen en enkele rapportages. Dit prototype heeft tot doel de look and feel af te stemmen: hoe voelt het systeem aan bij de gebruiker. Bij grafische applicaties gaat het dan om lettertypes, buttons, list of values enzovoort. Het niet of te laat afstemmen van de 'look & feel' kan leiden tot een inconsequente gebruikersinterface. Tevens bestaat het gevaar dat in een later stadium - tijdens het prototypen van bijvoorbeeld de functionaliteit - veel tijd verloren gaat aan discussie over dit onderwerp. Heeft de organisatie al standaarden voor de gebruikersinterface, dan is het toch verstandig deze door middel van een prototype af te stemmen met de gebruikers uit het rad-team. Zeker als de betreffende gebruikers in de praktijk nog niet werken met de gebruikersinterface in kwestie.

Gegevensmodel

Bij het toepassen van rad komt het gegevensmodel in twee stappen tot stand. In eerste instantie wordt het gegevensmodel in kaart gebracht in één of meer workshops, waarbij gebruik wordt gemaakt van de Metaplanning (brown paper)-techniek. Vervolgens wordt het gegevensmodel getoetst en verder uitgewerkt met behulp van prototyping.
Het prototype bestaat uit default, vanuit het i-case-tool gegenereerde applicaties. De gebruiker controleert en toetst het gegevensmodel op basis van gegevens uit de praktijk. Daarnaast wordt gebruik gemaakt van formulieren (figuur 2), waarmee per entiteit onder andere de onderstaande zaken worden gevalideerd:
definitie van de entiteit; relaties met andere entiteiten; ontbrekende of overbodige attributen; formaat van attributen;
optionaliteit, en geldende voorwaarden.
Automatiseerders hebben vaak bezwaar tegen deze vorm van prototyping. "Gebruikers kunnen geen gegevensmodel toetsen" is een veel gehoorde opmerking. In de praktijk is gebleken dat gebruikers dit zeker aankunnen. Het prototype maakt het immers mogelijk dat zij zich volledig concentreren op de structuur van de gegevens van hun systeem. Wel is het van belang dat de toetsers goed worden voorgelicht over het doel van het betreffende prototype. Als er toch opmerkingen over de functionaliteit worden gemaakt, dan worden deze niet genegeerd, maar genoteerd en in het eerste functionele prototype meegenomen.
Door het gegevensmodel zo vroeg in het traject uit te werken en expliciet te toetsen, is een goede basis gelegd voor het toekomstige systeem. Het gegevensmodel zal nog niet voor 100 procent stabiel zijn. Toch voorkomt deze werkwijze zoveel mogelijk dat later in het traject grote arbeidsintensieve wijzigingen in de gegevensstructuur moeten plaatsvinden.
In de requirements planning-fase van rad is het systeem onderverdeeld in partities. Deze kunnen vervolgens met behulp van prototypen functioneel worden uitgewerkt. Dat kan na elkaar gebeuren of eventueel parallel aan elkaar door verschillende teams.

Functionaliteit

Na het gegevensmodel wordt de uiteindelijke functionaliteit bepaald met behulp van prototypen. Functionele prototypen stellen de gebruiker in staat direct een beeld te vormen over de tot dan toe gerealiseerde functionaliteit en over de mate waarin deze eventueel moet worden aangepast. De functionaliteit wordt per partitie afgestemd; de partities worden op iteratieve wijze ontwikkeld.
Tijdens de workshops wordt gebruik gemaakt van een toetsscenario dat samen met de gebruikers van tevoren wordt opgesteld. Het verdient aanbeveling om ook tijdens het toetsen gebruik te maken van 'echte' gegevens zoals dossiers, formulieren enzovoort. De bij het prototype gemaakte op- en aanmerkingen worden in het rad-team besproken en eventueel meegenomen in het prototype voor de volgende iteratie. Na de laatste iteratie gaan de gebruikers (executive owners) akkoord met de op te leveren functionaliteit van de betreffende partitie. Dit wordt gedaan op basis van het laatste functionele prototype en een opsomming van de nog niet gerealiseerde op- en aanmerkingen.

Techniek

Als laatste prototype onderscheiden we het technische prototype. Dit benadrukt een bepaald technisch aspect waarover onduidelijkheid bestaat. Het prototype heeft tot doel technische vragen te beantwoorden over bijvoorbeeld prestatie, conversie van gegevens, geheugengebruik, netwerk-configuratie enzovoort. In de regel zijn bij deze vorm van prototyping geen gebruikers aanwezig. Wel worden de resultaten achteraf met de gebruikers uit het rad-team afgestemd.

Aandachtspunten

Men moet niet uit het oog verliezen dat bepaalde delen van het te realiseren systeem niet met behulp van prototypen tot stand kunnen komen. Denk bijvoorbeeld aan complexe batches of interfaces met andere systemen. Deze functionaliteit zal op de traditionele manier moeten worden ontwikkeld.
Bij het beoordelen van de functionaliteit van een partitie is het belangrijk dat de betreffende gebruikers een goed beeld krijgen van de samenhang van de functionaliteit binnen de partitie. Het is bijvoorbeeld niet de bedoeling dat één scherm wordt besproken. Men loopt dan het risico dat de functionaliteit met een te beperkte blik wordt beoordeeld. Dit kan leiden tot een steeds weer wijzigende functionaliteit.
Voor het toepassen van prototyping is een goede voorbereiding essentieel. Anders dreigt prototyping een onbeheersbaar proces te worden. Vooraf moet met de gebruikers uit het rad-team worden vastgesteld wie de prototypen gaan toetsen, wanneer getoetst gaat worden en hoeveel iteraties maximaal worden doorlopen. De ervaring leert dat voor de gebruikersinterface en het gegevensmodel maximaal twee iteraties voldoende zijn. Bij functioneel prototyping zal per partitie - afhankelijk van de complexiteit - twee tot vijf maal worden geïtereerd.

Praktijk

In de praktijk is gebleken dat het onderscheiden van verschillende soorten prototypen een goed middel is om prototyping binnen een rad-project op een gestructureerde en - niet minder belangrijk - beheersbare manier te laten plaatsvinden. Tevens is gebleken dat de gebruikers zich nauw betrokken gaan voelen bij de ontwikkeling van hun informatiesysteem. Het systeem wordt niet meer vóór hen maar juist mét hen gerealiseerd.
 
Drs Laurens van Wonderen is werkzaam als rad-consultant van Consultdata Nederland te Diemen.

Partities

Een systeem van bijvoorbeeld duizend functiepunten kan niet in zijn geheel tot een prototype worden verwerkt. De gebruiker kan een dergelijk groot systeem niet goed overzien. Het is daarom beter dit op te delen in 'partities'. Elke partitie is een duidelijk afgebakend deel, waarvan de functionaliteit zelfstandig met de gebruiker kan worden afgestemd. De verschillende partities kunnen na elkaar maar ook parallel door verschillende teams worden ontwikkeld. Denk aan honderd tot driehonderd functiepunten voor bruikbare partities.

Resultaten prototyping

Indien goed toegepast, kan prototyping:

  • de communicatiekloof overbruggen;
  • meer inzicht geven in de toekomstige situatie;
  • leiden tot snellere en betere besluitvorming;
  • de acceptatie vereenvoudigen en invoer versnellen;
  • resulteren in minder onderhoudskosten.

 
Het eerste deel van deze serie beschreef de weerstanden van automatiseerders bij het invoeren van 'rapid application development', en hoe deze overwonnen kunnen worden. Het derde en laatste deel zal behandelen hoe workshops kunnen leiden tot kwaliteitsverhoging.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/1318983). © Jaarbeurs IT Media.

?


Lees meer over


 
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×