Snelle systeemontwikkeling stelt nieuwe eisen aan Heao BI

‘Rapid application development’ is nu bijna een decennium oud. Inmiddels hebben diverse vormen van snelle systeemontwikkeling het licht gezien, die overigens grote overeenkomsten vertonen. In de opleiding Heao Bedrijfskundige Informatica (BI) zou meer aandacht besteed moeten worden aan de eisen die rad met zich meebrengt, zoals communicatieve vaardigheden. De visie van een docent BI en een rad-consultant

Steeds luider klinken er geluiden om de opleiding Heao-BI te herzien, zodat deze in de pas blijft lopen met recente ontwikkelingen in het vakgebied. De bevindingen van de visitatiecommissie die in 1992 alle hbo-opleidingen Bedrijfskundige Informatica bezocht, gaven dit al aan. De commissie onderkende dat er ontwikkelingen gaande waren die maakten dat de traditionele driedeling in deskundigheid aan het vervagen was. Deze driedeling, waarop een groot aantal opleidingen Heao-BI tot dan toe geënt was, kwam in het kort neer op het volgende:

• Kennis van de bedrijfsprocessen waarop het te ontwikkelen systeem betrekking heeft: zogenaamde domeinkennis.
  
• Kennis en beheersing van analysemethoden uit de informatica. Het doel van de inzet van deze deskundigheid is het formuleren van de functionele en kwaliteitseisen waaraan het concrete systeem moet voldoen.
  
• Kennis en beheersing van de methoden die nodig zijn om op grond van die eisen het concrete systeem te realiseren.
  De dragers van deze kennis waren respectievelijk de gebruikers, de bi’ers en de programmeurs. De bedrijfsinformaticus (bi’er) fungeerde in deze optiek als intermediair tussen de gebruikers en de programmeurs.
  

Rapid application development (rad) is één van de ontwikkelingen die het noodzakelijk maakt de opleiding Heao-BIG te herzien.
Eerst wordt een kort overzicht gegeven van diverse snelle ontwikkelmethoden. De overeenkomsten tussen de verschillende methoden worden vervolgens gebruikt om conclusies te trekken over de benodigde vaardigheden voor de bi’er om in een rad-traject te kunnen participeren.

Rad: kleine teams

‘Rapid application development’ is een systeemontwikkelmethode van James Martin uit het begin van de jaren negentig. Ondanks de treffende beschrijving van deze methode door Martin zijn er maar weinig vakgenoten die zich de inhoud van zijn boek hebben eigen gemaakt. Dit blijkt wel uit het feit dat sommigen van ons denken dat rad staat voor:
jad, client server, een ‘license to hack’, objectgeoriënteerd ontwerpen en realiseren, snelle vierde-generatietalen en case-hulpmiddelen; anderen denken dat rad alleen maar bestemd is voor kleine ‘stand-alone’ projecten.
De methode die James Martin beschrijft, is gebaseerd op een viertal peilers: methode, tools, mensen en management. Met behulp van deze peilers wordt aangegeven dat rad niet ‘doe maar wat’ betekent, maar dat systeemontwikkeling met rad volgens van tevoren overdachte stappen en fasering verloopt. De methode rad kent daarbij achtereenvolgens de fasen: ‘requirementsplanning’, ‘user design’, ‘construction’ en ‘cut-over’. Een praktisch toepasbare terminologie is: definitiestudie, ontwerp en toetsen van het ontwerp met behulp van prototypes, afbouw en ingebruikname. Prototypes kunnen alleen maar tot een onderhoudbaar systeem doorgroeien met herbruikbare componenten als gebruik gemaakt wordt van geïntegreerde case-tools. James Martin schrijft ook dat rad betekent dat kleine teams van gebruikers en automatiseringsdeskundigen samen aan de oplossing van een bedrijfsprobleem werken. Hierbij geeft hij ook aan welke mensen het team moeten bemannen om rad succesvol toe te passen. Samenwerken met gebruikers betekent een zware wissel op de communicatieve vaardigheden van ontwikkelaars. Daarnaast reikt hij de projectmanager ook hulpmiddelen aan om het project te kunnen leiden. Een voorbeeld hiervan is het feit dat de gebruikers zelf aangeven welke functionaliteit binnen de beschikbare tijd de hoogste prioriteit heeft en het feit dat kwaliteit grote aandacht hoort te krijgen. Alleen de juiste toepassing van alle peilers leidt tot het in korte tijd realiseren van systemen van goede kwaliteit tegen lage kosten. Rad, zoals beschreven door James Martin, past uitstekend in de information engineering-ontwikkelmethodiek maar is ook los van IE toepasbaar.

Praktijkervaring in dsdm

Het begrip rad is nogal aan slijtage onderhevig en veel vakgenoten willen meer houvast dan Martin hen biedt.
Veel Britse bedrijven hebben hun expertise in de snelle ontwikkeling van systemen samengebracht in een leveranciersonafhankelijke methode: dynamic systems development method (dsdm) Deze expertise is, onder andere, vastgelegd in negen ‘principles of dsdm’. Deze uitgangspunten vormen de basis voor een gebruikershandleiding waarin zeer bruikbare en tastbare aanwijzingen voor de projectmanager zijn beschreven. Zo worden de verschillende rollen van deelnemers in dsdm gedetailleerder beschreven dan bij James Martin het geval is en verschijnen er geregeld ‘white-papers’, bijvoorbeeld over de uitbesteding van rad-projecten. Opgemerkt moet worden dat de meeste elementen van dsdm weer terug te leiden zijn tot de oorspronkelijke peilers van rad-aanpak van James Martin. Dsdm moet, zeker in Groot-Brittannië, worden gezien als een de-facto standaard voor snelle ontwikkeltrajecten waarin de praktijkervaringen van veel bedrijven gebundeld zijn. Ook het feit dat ontwikkelaars gecertificeerd kunnen worden als dsdm-ontwikkelaar en het feit dat een bruikbare handleiding beschikbaar is, draagt bij aan de populariteit. Of Dsdm-Benelux zo’n zelfde standaard is, zal in de toekomst moeten blijken.

Iad en jad

Iteratieve of incremental application development (iad) is de snelle systeemontwikkelmethode zoals die door Cap Gemini wordt beschreven. Ondanks het feit dat de terminologie van deze methode ietwat verwarrend is, vertoont zij veel overeenkomsten met de vorige twee methoden. Zo is rad bij Cap Gemini een van de manieren waarop op iteratieve wijze systemen te ontwikkelen zijn en niet de integrale ontwikkelmethode die James Martin in gedachten had. Net zoals Martin rad plaatst binnen het brede kader van information engineering plaatst Cap Gemini iad binnen een IT-architectuur.
Joint application development (jad) zoals beschreven door Woods en Silver is niet echt een systeemontwikkelmethode in de zin dat deze beschrijft hoe men een systeem ontwikkelt vanaf eerste idee tot ingebruikname. Jad is meer een filosofie over de gezamenlijke inspanning van een team om te komen tot besluiten aangaande verschillende aspecten van de systeemontwikkeling. Het is gestructureerd rond een workshop (een jad-sessie), waar men samenkomt om te werken en om besluiten te nemen. De sessie kent een gedetailleerde agenda, visuele hulpmiddelen, een ‘facilitator’ of workshop-leider en een notulist. James Martin noemt dit ook: ‘some primitive jad-workshops are conducted without automated tools’. Jad is dus ook geen systeemontwikkelmethode in de strikte zin van het woord. De eerder genoemde methoden maken gebruik van jad-achtige workshops. Deze techniek wordt niet alleen in de systeemontwikkeling gebruikt maar ook bijvoorbeeld bij de het opstellen van bedrijfstrategieën en marketingplannen.

Overeenkomsten

‘Fast-Track’ en ‘Approach’ zijn snelle ontwikkelmethoden zoals beschreven door Oracle en U-Soft. Beide vertonen veel overeenkomsten met de hiervoor genoemde methoden maar zijn toegesneden op de ontwikkelhulpmiddelen van de betreffende organisaties.
‘Model-based application development’ (mad) is te zien als een vorm van rad, waarbij echter sterk de nadruk ligt op modelleren, en waarbij systemen vanuit een modelmatige ‘gepopuleerde repository’ gegenereerd moeten kunnen worden. De toepassing is nog niet wijd verbreid en is te zien als een, wellicht wat theoretische, aanvulling op de eerder genoemde methoden.
Er bestaan geen grote verschillen tussen de diverse snelle ontwikkelmethoden. De overeenkomsten zijn echter veel opvallender en onderstrepen dat de traditionele rollen aan het veranderen zijn.
Gezamenlijke inspanning van gebruikers en automatiseerders
Doordat de toegankelijkheid van hardware en software voor de gebruiker is toegenomen, is deze beter dan in het verleden in staat de wensen met betrekking tot het nieuwe systeem kenbaar te maken. Een intermediair tussen de gebruikers en de programmeurs, die eerst de gebruikerswensen inventariseert en deze vervolgens formaliseert, is daarom minder noodzakelijk. Een gezamenlijke inspanning van gebruikers en automatiseerders betekent dat de traditionele rol van ‘de functionele specificaties’ als onderwerp van discussies over wat nu precies wel en wat nu precies niet gewenst is, komt te vervallen. Indien er problemen ontstaan, moet men die als team proberen op te lossen. Gebruikers en automatiseerders hebben hierin gelijke verantwoordelijkheid. Dit betekent dat men meer dan in het verleden in staat moet zijn standpunten te herzien en fouten te kunnen toegeven.
Prototyping met tools tijdens de workshop.
Doordat de ontwikkelhulpmiddelen steeds meer geïntegreerd raken en de generatie van applicatiecode een steeds belangrijkere rol gaat spelen, is de driedeling analist, ontwerper en programmeur aan het verdwijnen. In de workshops (de ‘frontoffice’) worden functionele eisen geïnventariseerd en direct op conceptueel niveau vastgelegd, waarbij vrij snel een database en default-applicatie gegenereerd kan worden. Voor een effectieve workshop dienen de ontwikkelaars in staat te zijn gebruikerswensen direct te vertalen naar het prototyping-tool. Dit vergt van de ontwikkelaars niet alleen dat zij uit de voeten kunnen met het tool, maar ook dat zij kunnen luisteren naar de gebruikers en over een zekere onbevangenheid beschikken. Buiten het zicht van de gebruikers (de ‘back-office’) kunnen vervolgens gespecialiseerde tool-deskundigen de applicatie op maat afbouwen.
Methodisch te werk gaan is niet synoniem voor het mechanisch gebruik van de analysemethoden en schematechnieken voor gegevens- en/of procesanalyse. In de intermediaire rol van de bi’er was een grote behoefte aan het formeel kunnen specificeren van gebruikerswensen. In een rad-traject staan zowel de workshops als de inzet van prototyping-tools garant voor een hoog ‘hier-en-nu’ gehalte en is de behoefte aan formele schematechnieken als communicatiemiddel sterk afgenomen. Echter, het interpreteren van gebruikerswensen en deze direct kunnen vertalen naar het prototype vraagt (nog steeds) van de ontwikkelaar goede analytische vaardigheden.
Voor een rad-traject betekent ‘methodisch te werk gaan’ echter meer. Het structureren van de workshops, het leiden van het team door de verschillende fasen van het traject, het in de gaten houden van de iteraties van het prototype en de totale doorlooptijd van het project, het strak houden aan de tijdsplanning vanwege de ’time-box’, vergen zeker een methodische aanpak.
Functionaliteit is de afhankelijke variabele.
Niet langer wordt er gefocust op 100 procent van de gewenste functionaliteit. Het invullen van de onderhandelingsruimte doet opnieuw een groot beroep op de teamgeest. Degenen met de domeinkennis moeten kunnen beoordelen welke functionaliteit absoluut noodzakelijk is en welke functionaliteit wel gemist kan worden. De ontwikkelaars moeten een gedegen inschatting kunnen maken van de haalbaarheid van de wensen en de risico’s van het project binnen de gestelde tijdslimiet. Om het team een gefundeerde beslissing te kunnen laten nemen over de uit te werken functionaliteit moeten de ontwikkelaars zo min mogelijk sturen maar tegelijkertijd de gebruikers wel wijzen op de consequenties van hun beslissingen. Dit is geen eenvoudige taak en vraagt naast veel ervaring een flinke hoeveelheid zelfkennis.

Communicatieve vaardigheden

Het kunnen deelnemen aan workshops in een rad-traject in de rol van workshop-leider, ontwikkelaar of in een andere ondersteunende rol dan automatiseerder, vraagt meer persoonlijke, sociale en communicatieve vaardigheden van een afgestudeerde bi’er dan de intermediaire rol. Indien men de student Heao-BI wil voorbereiden op bedrijfsmatige omgevingen waar naast de meer traditionele aanpakken voor systeemontwikkeling ook in toenemende mate plaats is voor rad, zal er binnen de opleidingen expliciet aandacht moeten zijn voor deze relatief nieuwe aspecten. Dat hierbij ook de gehanteerde werkvormen binnen de opleiding vernieuwd zullen moeten worden, staat voor de auteurs als een paal boven water. Hoorcolleges zijn nu eenmaal niet het meest geschikte middel om vaardigheden te trainen. De rol van docent in werkcollege’s, stages en workshops zal daarbij sterke overeenkomsten gaan vertonen met de faciliterende rol van de informatiedeskundige in de systeemontwikkelingstrajecten met behulp van een van de snelle ontwikkelmethoden. Even zo logisch is dat de automatiseringsdeskundigen die al werkzaam zijn in de automatisering, zich bezinnen op de rol die zij in rad-projecten kunnen en willen vervullen.
 
Peter Odenhoven is docent bedrijfskundige informatica aan de Hogeschool Holland
Rob Stroober is rad-consultant bij Consultdata