Met de opkomst van de client/server-technologie veranderde er ook iets aan de manier waarop automatiseerders applicaties gingen ontwikkelen: rad (rapid application development) deed zijn intrede. Rad staat een iteratieve aanpak van applicatieontwikkeling voor, gebaseerd op prototyping, timeboxing en gebruikersparticipatie. Daarmee fungeerde rad als tegenhanger van de klassieke watervalmethoden zoals sdm (system development methodology.
Rad kreeg wereldwijde bekendheid door missiewerk van James Martin in het begin van de jaren negentig. Er verschenen talloze rad-tools op de markt. Een inventarisatie van Bloor Research uit 1997 leverde al het kolossale aantal van 150 producten op. ‘Toch’, zo schreven de onderzoekers, ‘moeten we rad in het juiste perspectief zien. Het is beslist niet zo dat met de rad-methodiek elk ontwikkelproject binnen de vastgestelde tijd- en geldlimieten kan worden afgerond. Er zullen altijd heel slechte ontwikkelaars zijn die roet in het eten gooien.’
Rick van der Lans verwoordde het in zijn boekje ‘Automatisering, mythen, sprookjes en fabels’ (Academic Service, 1998) als volgt: ‘Voor velen onder ons (ontwikkelaars) is het werken volgens rad een vrijbrief om de meest complexe spaghetticode te schrijven. De gebruikers-interface wordt direct aan de databasestructuur gekoppeld. Het modulair opzetten van de code is ineens volledig ondergeschikt aan de gebruikers-interface. Als dit inderdaad rad is, wat ik niet denk, dan hoop ik maar dat het nooit in de auto- of vliegtuigindustrie wordt toegepast. Auto’s die er prachtig uitzien en zeer eenvoudig te bedienen zijn, maar die gammel in elkaar zitten en waarvan de onderhoudskosten de pan uitvliegen, daar zitten we niet op te wachten. Hetzelfde geldt uiteraard voor de software.’
In 1994 werd in Engeland het Dsdm-consortium opgericht met als doel een allesomvattende rad-aanpak te ontwikkelen om applicaties op tijd, binnen het vastgestelde budget en bovendien van voldoende kwaliteit op te leveren. Het consortium startte met zeventien leden. Inmiddels is het uitgegroeid tot een internationale organisatie met meer dan duizend leden. Ook in Nederland (http://www.dsdm.nl), waar eind vorig jaar voor het eerst een heus congres werd georganiseerd dat door 250 Dsdm-aanhangers werd bezocht. Mede omdat Jennifer Stapleton deel uitmaakte van de sprekersstal. Stapleton is één van de oprichters van het Dsdm-consortium in Engeland. Als voorzitter van de technische werkgroep leverde zij een belangrijke bijdrage in de ontwikkeling van de methode, die een beschrijving geeft van ‘projectbeheer, projectplanning, prototyping, timeboxing, configuratiemanagement, testen, kwaliteitsbewaking, rollen en verantwoordelijkheden (van gebruikers en automatiseerders), teamstructuren, hulpmiddelen, risicobeheer, onderhoudbaarheid, hergebruik en contacten tussen aanbieder en afnemer’. En dat alles in een rad-omgeving.
In opdracht van het Consortium schreef mevrouw Stapleton een boekje dat eind vorig jaar bij Academic Service is uitgekomen. Het boek is getooid met de uiterst saaie, maar bijzonder heldere titel ‘Dynamic Systems Development Method (Dsdm), de methode in de praktijk.’ Het is de vlag die precies de lading dekt, aangezien het een overzicht biedt van de methode en een beschrijving van een aantal casestudies die inzicht geven in de successen en problemen bij Dsdm-projecten.
In een nawoord verklaart Stapleton: ‘Zoals bij elke Dsdm-ontwikkeling is dit boek tot stand gekomen in een zeer strak tijdschema: twintig dagen werk met een vaste einddatum voor het inleveren van de tekst’. Als professioneel schrijver beweer ik dat dat onmogelijk is. De literatuurlijst vermeldt acht boeken die Stapleton heeft geraadpleegd. Ik neem aan dat de vier boeken die ze ter lezing aanbeveelt, ook heeft doorgenomen. Bovendien zal ze de acht cases moeten hebben bestudeerd, voordat ze zich kon zetten aan een beschrijving. Fysiek en intellectueel is het onmogelijk om al dat lees- en schrijfwerk in twintig dagen te doen.
Maar waarschijnlijk bedoelt Stapleton het niet zo. Pas nadat ze alle literatuur had bestudeerd, talloze gesprekken had gevoerd, aantekeningen had gemaakt, haar ervaringen had overdacht en het nodige denkwerk had verricht, heeft ze zich achter de tekstverwerker gezet om de noodzakelijke letters op papier te zetten. Hoe lang de voorbereidende werkzaamheden (het creatieve proces) heeft geduurd, vermeldt Stapleton niet. Ook geeft ze niet aan wat er na het inleveren van de tekst bij de drukker is gebeurd. Misschien is er een heleboel ellende geweest bij het nazien van de drukproeven, het drukken of de distributie van het boek.
Het is niet zo interessant om te weten dat Stapleton twintig dagen achter de tekstverwerker heeft gezeten om het boek te schrijven. Het is ook geen creatieve prestatie. Het is een kwestie van ijzeren zelfdiscipline. Of het hele boekproject op tijd en binnen budget is opgeleverd, weten we niet.
Het is in een IT-project niet zo’n prestatie om een applicatie binnen de gestelde termijn te schrijven. Mits er maar degelijk en creatief voorwerk is verricht. Dat wil zeggen, wanneer alle technische en functionele specificaties helder en vastomlijnd zijn beschreven. De meeste problemen treden op in het voor- en natraject. Vanwege machtspolitiek, falende managers of regelrechte onkunde en onervarenheid. En daar helpt geen ontwikkelmethode tegen. Ook geen Dsdm.
Jennifer Stapleton: DSDM, Dynamic Systems Development Method – De methode in de praktijk. Academic Service. ISBN 90 395 1091 1. Prijs: f 39,50
