Sinds 1995 wordt er gewerkt aan een standaard raamwerk voor incrementele applicatie-ontwikkeling. Dat is vreemd, want de principes van rad (rapid application development) zijn toch al meer dan twaalf jaar bekend. Het onderzoeksbureau Bloor Research heeft dat raamwerk, opgezet door het Dsdm-consortium (dynamic systems development method), gebruikt voor de evaluatie en vergelijking van een aantal ontwikkeltools. De resultaten zijn neergelegd in het rapport ‘Fast development software, an evaluation and comparison of rad tools’.
Het Dsdm-consortium is twee jaar geleden opgericht in Engeland en telt nu meer dan honderd leden: gebruikersorganisaties, softwareleveranciers en IT-bedrijven. De doelstelling van deze club is "het ontwikkelen van een rad-methode die beter past bij de moderne dynamische bedrijfsomgeving van de traditionele ontwikkelmethoden". Dsdm is de feitelijke uitwerking van een management- en beheerfilosofie voor incrementele applicatie-ontwikkeling die is gebaseerd op de ervaringen met rad bij de gebruikersorganisaties die lid zijn van het consortium.
De methode, die volledig leveranciers- en technologie-onafhankelijk is, biedt een raamwerk voor het beheren en beheersen van rad-projecten. Overigens is er onlangs ook een Dsdm-Benelux opgericht met als belangrijkste doelstelling: "het actief promoten van rapid application development als benadering voor systeem-ontwikkeling op basis van de ‘dynamic systems development method’ en het stimuleren van discussie en terugkoppeling uit de praktijk ter verbetering van de kwaliteit en de snelheid van software-ontwikkeling en ondersteunde produkten en systemen". Deze schitterende volzin is afkomstig van de initiatiefnemers ASZ Automatisering Sociale Zekerheid, CMG Finance, Data Sciences, DCE Nederland, ICL, Inter Access en Ordina Overheid.
Evaluatie
Bloor Research heeft het raamwerk van Dsdm als uitgangspunt genomen voor de evaluatie en vergelijking van een aantal rad-tools. Daarbij is niet zozeer gekeken naar de technische mogelijkheden van de tool, alswel naar de geschiktheid van het product om een applicatie volgens de rad-principes op te leveren. Er zijn zo’n 150 ontwikkeltools op de markt.
Bijna alle claimen rad te ondersteunen. Voor het onderzoek is een vragenlijst gestuurd naar een groot aantal leveranciers. In ieder geval naar de leveranciers die lid zijn van het Dsdm-consortium en naar een aantal tool-leveranciers van wie bekend is dat zij zich met hun producten nadrukkelijk op de rad-markt profileren. Aanbieders die geen ‘rad-cultuur’ hebben, zijn niet benaderd. Volgens Bloor Research is het belangrijk dat gebruikersorganisaties kunnen rekenen op goede ondersteuning door de leverancier. De belangrijkste aanbieders van ontwikkeltools kunnen dat niet, zo menen de onderzoekers. Maar zij voegen aan deze harde opmerking wel onmiddellijk de zinssnede toe: "in een snel veranderende markt hebben we ongetwijfeld enkele producten gemist die redelijkerwijs toch bij het onderzoek betrokken hadden moeten worden." Het was opvallend dat een aantal leveranciers de vragenlijst niet terugstuurde. Ja, er waren ook leveranciers die expliciet vroegen om niet bij het onderzoek betrokken te worden. "Lezers moeten hierover maar zelf hun conclusies trekken", staat in het rapport te lezen. Wordt daarmee gesuggereerd dat er leveranciers zijn die de boel domweg belazeren? Bloor Research geeft daarop geen antwoord. Er zijn ook leveranciers die rad weliswaar goed ondersteunen en er desondanks voor hebben gekozen om geen lid van het Dsdm-consortium te worden. Bloor Research zet vraagtekens achter de betrokkenheid van deze leveranciers bij het rad-proces. Dsdm heeft een kritische massa bereikt. Iedere tool-leverancier die door de markt serieus genomen wil worden, zal Dsdm via een lidmaatschap van het consortium moeten ondersteunen. Dat vindt Bloor Research tenminste.
‘Table-driven’
Om geen appels met peren te vergelijken, heeft Bloor Research de producten in een drietal categorieën onderverdeeld: ’table-driven’ (rules-based), ‘model-driven’ en ‘component-driven’. De ontwikkeltools zijn beoordeeld op zes aspecten: methodische ondersteuning, bouwsnelheid, ontwerp, hergebruik, testen en ‘deployment’ (een ‘restrubriek’ waaronder vallen schaalbaarheid, configuratiebeheer, projectmanagement en onderhoudfaciliteiten). Daarnaast is ook gekeken naar portabiliteit, interoperabiliteit, opleidingsmogelijkheden en ondersteuning van de leverancier.
De onderzoekers beschouwen de ’table-driven’ tools als de meest interessante. Het fundament van deze tools is een rules engine, waarmee een grote mate van flexibiliteit wordt bereikt in het ontwikkelproces. De tools in deze categorie hebben een rad-oorsprong en bieden bij uitstek de middelen die nodig zijn om een rad-project te ondersteunen. Nadeel is echter wel dat ze vanwege de complexiteit moeilijker in gebruik zijn dan tools uit andere categorieën. Om die reden deden ze het in het onderzoek niet zo goed. Dat geldt voor Objectstar (voorheen Huron), dat weliswaar heel flexibel is, maar in de testfase niet goed scoort. Ook de ietwat beperkte modelleer-capaciteit is een minpunt. Hetzelfde geldt voor Magic van de gelijknamige firma en Objectpool van Sapiens.
USoft Developer van Usoft (het vroegere Nederlandse Topsystems) is volgens Bloor Research de enige tool in deze categorie die voldoet aan het Dsdm-profiel. Dat komt voornamelijk vanwege de uitgebreide set van gereedschappen. De ontwikkelomgeving zou nog beter scoren, wanneer de repository niet zo’n integraal onderdeel zou uitmaken van de applicatie. Daardoor kunnen zaken als configuratiemanagement of versiebeheer niet op de juiste wijze worden uitgevoerd zonder de uiteindelijke applicatie te beïnvloeden.
‘Model-driven’
De ‘model-driven’ tools zijn rijk vertegenwoordigd. Het gaat hier om zes produkten die varieren van traditionele Case-tools tot en met anderssoortige object-georiënteerde omgevingen. Modelleringstechnieken kunnen de productiviteit van de ontwikkelaar verhogen en een beter begrip kweken voor de ‘business’-processen. Daarom neemt het gebruik van deze technieken een belangrijke plaats in in het raamwerk van Dsdm. 
Ook de mogelijkheid tot hergebruik is een belangrijk kenmerk. De snelste manier om een applicatie te ontwikkelen, is het gebruik van een bestaande template. Het wekt daarom nauwelijks bevreemding te constateren dat de tools in deze categorie het beter deden dan die in andere segmenten. Binnen de categorie van ‘model-driven’ tools scoorden Composer van Texas Instruments en Snap van Template Software het best.
Composer heeft zowel krachtige en breed inzetbare modelleringstools als een bijzonder krachtige repository-architectuur. De zwakte van Composer ligt in de manier waarop het testtraject wordt benaderd. Snap doet het heel goed vanwege het gebruik van applicatie templates die een groot deel van de toepassing in een pre-ontwikkelstadium kan leveren. Snap ondersteunt geen datamodellering, maar steunt op de hulp van de database zelf.
Visualage van IBM komt eveneens goed uit de evaluatie te voorschijn vanwege zijn object-oriëntatie en koppeling met Pacbase. Oracle heeft wel wat aan zijn Case-achtergrond, maar mist goede testgereedschappen, terwijl ook de repository-architectuur van Designer & Developer/2000 vrij zwak is. Natstar en Natural zijn niet slecht, maar springen er niet echt uit.
‘Component-driven’
Het gereedschap voor applicatie-ontwikkeling dat in deze categorie thuishoort, is afkomstig van 4GL- en eis-leveranciers. De opname van eis-tools is een erkenning van het feit dat veel van deze tools vandaag de dag dezelfde mogelijkheden hebben als een volledige applicatie-ontwikkelomgeving. Dat producten als Gentia, Holos en Pilot niet in het onderzoek betrokken zijn, is "geenszins een weerspiegeling van hun mogelijkheden", zo verontschuldigt Bloor Research zich. Dat betekent derhalve dat de betreffende leveranciers de vragenlijst niet hebben teruggestuurd, dan wel uitdrukkelijk hebben verzocht buiten beeld te mogen blijven. Het belangrijkste verschil tussen ‘normale’ applicaties en eis-toepassingen, is dat de laatste voornamelijk ‘read-only’ zijn en bedoeld voor gebruikers die niet zijn geïnteresseerd in de complexiteit van de applicatie. Om die reden hebben deze tools niet alle elementen die karakteristiek zijn voor een bredere ontwikkelomgeving. Afgezet tegen het Dsdm-raamwerk voldoen ze dan ook niet echt. SAS en Inphere zijn bijvoorbeeld zwak in configuratiemanagement en het automatisch produceren van documentatie. Begrijpelijk, want dat zijn gebieden die voor eis-tools niet zo belangrijk zijn. Aan de andere kant voldoen beide tools wel op terreinen als applicatiebouw en -testen.
Cactus is een nieuw product van Information Builders en de opvolger van Focus. Zoals te verwachten van een nieuw ontwikkeltool, is Cactus zeer goed in het bouwtraject en in het hergebruik van componenten. De test- en modelleringstools zijn daarentegen zwak. Openroad van Computer Associates is duidelijk superieur aan de andere tools in deze categorie. Hoewel Openroad methodisch niet zo sterk is, wordt veel vergoed door de gebruikte taal en de mogelijkheid tot hergebruik.
Juiste perspectief
Het is duidelijk dat de iteratieve en evolutionaire manier om applicaties te ontwikkelen heel efficient is en goede resultaten kan opleveren. "Toch", zo schrijven 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 hele slechte ontwikkelaars zijn die roet in het eten gooien." Rick van der Lans verwoordde het in zijn column voor het jongste nummer van CM Corporate als volgt: "Voor velen onder ons (ontwikkelaars) is het werken volgens rad een vrijbrief om de meest complexe spaghetticode te schrijven. De user-interface wordt direct aan de databasestructuur gekoppeld. Het modulair opzetten van de code is ineens volledig ondergeschikt aan de user-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."
Cok de Zwart, freelance medewerker Computable
De negen uitgangspunten van dsdm
Dsdm-teams moeten bevoegd zijn om beslissingen te nemen.
Dsdm-teams bestaan uit gebruikers en ontwikkelaars. Het team moet zelfstandig kunnen besluiten over het aanpassen van functionaliteit zonder dat zij in alle gevallen goedkeuring van het hoger management nodig hebben.
De werkwijze is gericht op frequente oplevering van produkten.
Een dsdm-team richt zich op het opleveren van werkende prototypes of systeemdelen binnen een afgesproken tijdspanne. Dit stelt het team in staat om de beste benadering te kiezen om de vereiste produkten binnen de gegeven tijd te realiseren.
De aanpak is iteratief en incrementeel.
Dsdm stelt het team in staat om systemen incrementeel te ontwikkelen. De ontwikkelaars kunnen optimaal gebruik maken van de terugkoppeling van de gebruikers om snel te komen tot een bruikbaar systeem.
Toepasbaarheid voor het kunnen uitvoeren van de bedrijfsactiviteiten is het criterium voor acceptatie.
Dsdm richt zich op het op tijd opleveren van voldoende functionaliteit die de bedrijfsactiviteiten ondersteunt. Het systeem kan desgewenst later worden verfijnd of uitgebreid.
Alle veranderingen zijn omkeerbaar.
Iteratief ontwikkelen maakt het mogelijk om terug te komen op eerder gemaakte keuzen.
Functionaliteit wordt gedefinieerd op een hoog niveau.
Tijdens het ontwikkeltraject wordt functionaliteit verder gedetailleerd op basis van voortschrijdend inzicht.
Testen vindt plaats gedurende de gehele ontwikkelfase.
Testen wordt niet beschouwd als een afzonderlijke activiteit. Terwijl het systeem incrementeel wordt ontwikkeld, wordt het beoordeeld en getest door ontwikkelaars en gebruikers.
Goede samenwerking tussen alle bij het project betrokken partijen is essentieel.
Keuzen die betrekking hebben op het project mogen niet worden gehinderd door restrictieve procedures. Afspraken met externe leveranciers dienen voldoende flexibiliteit te bieden.
Actieve gebruikersparticipatie is een voorwaarde.
De gebruikers en ontwikkelaars werken als één team samen gedurende het gehele ontwikkeltraject.
