Het concept van ‘rapid application development’ (rad) is nooit echt aangeslagen omdat het schortte aan een formele aanpak van de implementatie, stelt Bloor Research in een nieuw onderzoek. Maar het gat tussen theorie en implementatie wordt nu gedicht.
De eerste ideeën over rapid application development (rad) werden gepopulariseerd door de consultant, auteur en seminar-tijger James Martin. Hij toonde aan dat door het volgen van een iteratief proces, waarbij de IT-gebruikers voor de ‘input’ zorgen, een applicatie op tijd en volgens de gewenste specificaties kan worden gebouwd. Maar zoals zo vaak in de IT stonden tussen droom en daad, (wetten en) praktische bezwaren.
In 1995 werd daarom in het Verenigd Koninkrijk een consortium opgezet door IT-gebruikers, ondersteund door enkele leidende leveranciers, die zichzelf het doel stelden om een aantal richtlijnen op te stellen voor het beheer van rad-projecten. Deze richtlijnen staan bekend als de ‘dynamic systems development method’ (Dsdm) en zijn door Bloor gebruikt om tot een ‘vergelijkend warenonderzoek’ te komen. Veertien rad-omgevingen worden in het rapport aan de tand gevoeld. Er wordt meer gekeken naar de ontwikkelkwaliteiten dan naar de technische mogelijkheden van de verschillende tools. Om niet appels met peren te vergelijken zijn er drie produktgroepen gedefinieerd: ’tabel-driven’-, ‘model-driven’- tools en ‘component-driven’-tools.
Tabel-driven
De tools in deze categorie zijn het meest interessant om te vergelijken. De werking berust op beslissingstabellen die een hoge mate van flexibiliteit toestaan. Dit soort tools bestaat al langer en het zijn krachtige hulpmiddelen. Het nadeel is dat ze altijd moeilijker in het gebruik zijn dan andere hulpmiddelen. Als gevolg daarvan hebben dit soort tools het minder goed gedaan dan men zou verwachten. Vooral Objectstar (Antares) deed het niet best in de evaluatie. Zijn sterke ‘repository’-structuur maakt het een flexibel systeem, maar het testen van beslissingstabellen en de enigszins beperkte modelleercapaciteit zijn de negatieve zijden. Hetzelfde geldt voor Magic (MSE) en Objectpool (Sapiens). Usoft Developer (Usoft) is de enige in deze categorie die goed in het Dsdm-profiel past. Dit komt omdat er gebruik wordt gemaakt van een aantal verschillende tools.
Model-driven
De meeste tools vallen in de categorie ‘model-driven’ en bevatten zes ontwikkelomgevingen, variërend van een traditionele case-tool tot object-georiënteerde omgevingen. De mogelijkheid om bepaalde stukken code te hergebruiken is een sterk punt, omdat de snelste methode om een applicatie te ontwikkelen, het hergebruiken is van een bestaande objecten via een mal (’template’). Het is daarom niet verbazingwekkend dat tools in deze categorie goed scoren. Binnen deze groep zijn Composer (Texas Instruments) en Snap (Template Software) de beste. Visual Age (IBM) doet het ook goed als gevolg van de object-oriëntatie en de link met Pacbase. Oracle’s Developer/2000 profiteert van zijn case-herkomst maar lijdt aan een zwakke ‘repository’-architectuur. Zowel Natstar (Nat Systems) als Natural (Software AG) voldoen goed maar blinken niet uit.
Component-driven
De rad-hulpmiddelen in de ‘component-driven’-categorie vinden vaak hun oorsprong als 4GL. Er zijn ook een paar Executive Information System (Eis) tools in deze categorie terechtgekomen. Het is de erkenning dat een aantal eis-tools tegenwoordig tot volle wasdom is gekomen en de vergelijking met applicatie-ontwikkelhulpmiddelen kan doorstaan. Cactus van Information Builders is een nieuw produkt dat Focus opvolgt. Cactus doet het goed als applicatie-bouwhulpmiddel en kan veel code hergebruiken.
Open Road van Computers Associates is echter verreweg superieur aan de andere produkten in deze categorie, aldus het Bloor-rapport.
