Betrouwbare software is geen utopie

Het artikel ‘Vrijgavecriteria moeten een rol spelen bij investeringsbesluit’ van Hans Sassenburg (Automatisering Gids 11 april) geeft terecht aandacht aan de problematiek van softwarereleases en releasecriteria, een gebied dat onderbelicht is. Ik wil hierbij een tweetal aanvullende punten inbrengen. Het eerste punt betreft het belang van het tijdig doen van een release, eventueel ten koste van de geplande functionaliteit. Het tweede punt gaat over de positieve invloed van ‘agile’­methoden op de releaseproblematiek. De ervaring leert dat het essentieel is om de doorlooptijd van een softwareproject kort te houden en een release te doen na maximaal een half jaar. Dit geldt in elk geval voor kleine tot middelgrote projecten tot circa acht personen. Het is hierbij beter om prioriteiten te stellen in de functionaliteit en de scope van het project te beperken, dan om de oplevering (herhaaldelijk) uit te stellen, hetgeen in de praktijk vaak gebeurt. Hiervoor is een tweetal redenen aan te voeren. Ten eerste kan door tijdig een release te doen voorkomen worden dat het te bouwen systeem wordt ingehaald door zijn veranderende context. Het risico bestaat dat men continu bezig blijft met het verwerken van wijzigingen en het systeem niet af komt. Ook wordt voorkomen dat men de oorspronkelijke business case uit het oog verliest en het project een doel op zichzelf wordt ­ de functionaliteit kan altijd mooier en beter. Ten tweede is een release een belangrijke mijlpaal en motiverende factor voor de betrokkenen, zoals ontwikkelaars, projectleider en klant. Verschuivende releasedata werken demotiverend en verlagen de geloofwaardigheid van het project, ook in de ogen van de rest van de organisatie. Het vasthouden aan de releasedatum en het vervolgens beperken van de functionaliteit mag overigens niet ten koste gaan van de interne kwaliteit van de software. Het doen van een release betekent niet alleen dat het systeem op een bepaalde datum moet draaien, maar ook dat het een maand later nog steeds draait en blijft draaien. Als het niet mogelijk lijkt een release te definiëren die in circa een half jaar te realiseren is, is het verstandig jezelf de vraag te stellen of er wellicht te grote risico’s worden genomen en de ambities van het project te hoog zijn. Extra risico’s Het artikel van Sassenburg bevat aannames over de wijze waarop projecten ingericht zijn, namelijk grofweg volgens het watervalmodel, waarbij integratie relatief laat plaatsvindt en er een testfase aan het eind is die vaak uit de hand loopt. Deze wijze van inrichten van projecten brengt extra risico’s met betrekking tot releases met zich mee (deze worden in zijn artikel ook beschreven). ‘Agile’­methoden zoals Extreme Programming bieden hulpmiddelen om deze risico’s te beperken: continue integratie bijvoorbeeld smoort integratieproblemen in de kiem. Korte iteraties en het na elke iteratie kunnen opleveren van werkende software zorgen ervoor dat een deel van de releasecriteria continu onder de aandacht blijft. Deze hulpmiddelen zorgen voor kortere feedbacklussen in het ontwikkelingsproces en maken het mogelijk om problemen en fouten eerder te detecteren of zelfs te voorkomen. Het releaseproces wordt dan een stuk eenvoudiger. De problematiek van releasecriteria zoals in het artikel beschreven, is dan overigens nog steeds actueel. AUTEUR: Marc Evers Marc Evers (marc.evers@niwi.knaw.nl) is werkzaam als senior­technisch­wetenschappelijk programmeur bij het Nederlands Instituut voor Wetenschappelijke Informatiediensten (NIWI).Alleen aanpakken vrijgavecriteria is onvoldoende In de praktijk komt vaak pas bij de daadwerkelijke start van de acceptatietest binnen een systeemontwikkelingsproject de vraag naar boven wat de vrijgave­ of acceptatiecriteria zijn. Vrijwel alle betrokkenen zijn het erover eens dat deze veel eerder in het traject al gedefinieerd dienen te zijn. Het pleidooi van Hans Sassenburg in Automatisering Gids (11 april) om tot een aanpak te komen voor het definiëren, detailleren en evalueren van vrijgavecriteria kan daarom rekenen op een warm onthaal binnen de ICT­wereld. Wie droomt immers niet van beheersbare ICT­projecten en een lage cost­of­ownership van de resulterende systemen? Toch leidt een aanpak voor vrijgavecriteria niet zonder meer tot realisatie van deze wens. Dit wordt veroorzaakt door een aantal aspecten van de huidige systeemontwikkelingspraktijk. Er zal rondom ICT­projecten eerst een aantal andere knelpunten opgeruimd dienen te worden alvorens een aanpak voor vrijgavecriteria zijn vruchten af zal werpen. In de eerste plaats de businesscase. Sassenburg merkt terecht op dat deze een noodzakelijke basis is voor systeemontwerp en realisatie. Toch is er in de praktijk meestal niet voldaan aan dit uitgangspunt. Een uitgewerkte businesscase waarin ook nog eens de beheerkosten na oplevering meegenomen zijn, mag gerust een utopie worden genoemd. Dit wordt vaak veroorzaakt door de wijze waarop budgetten worden toegewezen. De ontwikkelingsorganisaties krijgen veelal jaarlijks een budget op basis van een inschatting van de ICT­organisatie zelf. Concrete projecten worden gefinancierd met dat budget. De opdrachtgever hoeft dus geen budget te reserveren voor de start van een ontwikkelingstraject. Als de ICT­organisatie zegt dat het past binnen het budget, is er geen vuiltje aan de lucht. In zo’n situatie is het voor de opdrachtgever zelfs lastig om de ontwikkelingskosten in een businesscase op te nemen. Dat bemoeilijkt het rondkrijgen van de businesscase tenslotte. In de tweede plaats gaat Sassenburg voorbij aan het feit dat vrijgavecriteria niet rechtstreeks afgeleid kunnen worden uit de businesscase. Om vrijgavecriteria te kunnen definiëren zullen eerst de systeemeisen of requirements afgeleid dienen te worden uit de businesscase. Veel organisaties onderkennen momenteel dat het achterhalen en beheren van goede systeemeisen een belangrijk aandachtspunt is. Bij veel ICT­organisaties loopt dan ook een verbeteringsproces om tot betere systeemeisen te komen en deze te beheren. Vrijgave­ of acceptatiecriteria zijn in feite de normering van de systeemeisen. De systeemeisen, de daarop gebaseerde vrijgavecriteria en het daarbij behorende kostenplaatje vormen idealiter de eerste mijlpaal waarop een go/nogo­beslissing genomen dient te worden. Zolang echter de businesscase niet scherp gedefinieerd is en de systeemeisen kwalitatief onvoldoende zijn, is het moeilijk om tot een nuttige set vrijgavecriteria te komen. Geen weg terug Rond de systeemeisen bestaat nog een ander probleem. Systeemeisen zijn vaak erg gevoelig voor voortschrijdend inzicht van de opdrachtgever en gebruikers. Onder invloed van tegenvallende kosten of meer diepgaand inzicht in de problematiek wijzigt volgens de statistieken circa 2 procent van de eisen per maand dat de systeemontwikkeling duurt. Dit gegeven, in combinatie met de reeds aangekaarte budgetteringsproblematiek, zou er wel eens de oorzaak van kunnen zijn dat vooral de opdrachtgever niet zo’n belang hecht aan dichtgetimmerde systeemeisen waarop hij later aangesproken kan worden. Onder die omstandigheden wordt het succesvol definiëren van vrijgave­ en acceptatiecriteria wel erg moeilijk. Los van de wellicht ongemotiveerde opdrachtgever is het belangrijk te realiseren dat onder de beschreven omstandigheden de kosten inzichtelijk gemaakt kunnen worden, maar dat men niet ‘de hand op de knip kan houden’. In het verlengde hiervan dient nog aandacht besteed te worden aan het ‘point of no return’ van een project. Gesteld wordt dat een vrijgavebesluit niets anders is dan het herzien van een investeringsbesluit. Bij vrijgave zijn inderdaad onzekerheden gereduceerd en is er meer inzicht in de kosten/baten van het gerealiseerde systeem. Dit inzicht zal echter zelden leiden tot het niet of nog niet implementeren van het systeem. Vaak worden go/nogo­besluiten genomen op een moment dat er al zoveel geïnvesteerd is dat een weg terug niet meer reëel wordt geacht. Men gaat hierbij ongetwijfeld voorbij aan de grote kosten na implementatie die een dergelijk besluit heeft. Men moet er echter rekening mee houden dat het systeem slechts een van de hulpmiddelen is om een al of niet expliciete businesscase te realiseren. Bij de introductie van een nieuw product is de afdeling Marketing vaak allang een campagne gestart om het product onder de aandacht te brengen. Beslissingen ten aanzien van een informatiesysteem hangen derhalve niet alleen af van de kwaliteit van dit systeem maar veel meer van externe factoren. In de praktijk heeft de besluitvorming in de latere fasen van ontwikkelingsprojecten vaak het karakter van een ritueel omdat het point­of­no­return om externe redenen allang bereikt is. Vaak wordt ervoor gekozen te implementeren met de intentie in de toekomst extra budgetten te reserveren voor het onderhoud. Aan het definiëren van een businesscase wordt in deze fase nooit gedacht. Alvorens een aanpak voor vrijgavecriteria in te voeren, dienen organisaties zich eerst te buigen over de hierboven beschreven situatie. In de eerste plaats zal aandacht besteed moeten worden aan de rolverdeling tussen de afdeling ICT en de opdrachtgever. Vragen die beantwoord dienen te worden zijn: Wie is verantwoordelijk voor de businesscase? Wie bewaakt de businesscase? Wanneer dienen de eisen aan het systeem bekend te zijn en wie stelt deze op? Daarnaast dient aandacht besteed te worden aan het ontwikkelingsproces. Vragen die hierbij centraal staan zijn: Hoe wordt omgegaan met wijzigende systeemeisen? Op welke momenten worden go/nogo­beslissingen genomen? Wie nemen deze beslissingen en op basis van welke criteria? Hoe moet het proces ingericht worden om relevante go/nogo­momenten te hebben? De rolverdeling tussen de afdeling ICT en de opdrachtgever is hierin mede bepalend. Daarnaast speelt het risicomanagementproces een belangrijke rol. Een aanpak voor de definitie, detaillering en evaluatie van vrijgave­ of acceptatiecriteria is een middel om een investeringsbesluit te onderbouwen. Wil dit middel succesvol ingezet kunnen worden dan dient aandacht besteed te worden aan de organisatie en haar processen. Met name de rol van de ICT­organisatie, de specificatie en het beheer van de eisen en het ontwikkelingsproces zodanig inrichten dat werkelijke go/nogo­besluiten genomen kunnen worden, zijn hierbij belangrijke aandachtsgebieden. AUTEUR: Erik van Geel Erik van Geel is als consultant procesverbetering werkzaam bij KZA BV te Baarn (EvanGeel@kza.nl).‘Vrijgavebesluit ritueel’ gevaarlijke uitspraak In zijn reactie op mijn artikel van 11 april pleit Marc Evers voor het beperken van de doorlooptijd en het ontwikkelen in korte iteraties. De door hem beschreven voordelen zijn duidelijk: betere focus, motiverend en eerdere detectie van problemen. Hij geeft echter ook aan, dat de problematiek met betrekking tot vrijgavecriteria op zich niet wijzigt. In een aantal onderzochte organisaties blijkt er in beperkte mate belangstelling te zijn voor het inzetten van ‘agile’­methoden. Er zijn twee complicerende factoren. In de eerste plaats is er veelal sprake van een grootschalige innovatieve ontwikkeling, waarbij een doorlooptijd van enkele jaren onontkoombaar is. Dit speelt met name bij embedded­softwareontwikkeling, waarbij de hardware en mechanica parallel ontwikkeld worden aan de software. In de tweede plaats is de impact van een release vaak te groot om meer dan 1x per jaar een release vrij te geven. Dit kan enerzijds worden veroorzaakt door de hoge vrijgavekosten (test, productie, installatie) en anderzijds door de afnemers, die niet elk half jaar geconfronteerd willen worden met gewijzigde functionaliteit. Geen utopie Erik van Geel zet kritische kanttekeningen bij het hanteren van een businesscase als basis voor een project. Hij stelt dat een uitgewerkte businesscase met beheerkosten een utopie is. De praktijk laat iets anders zien. Er zijn in onderzoek verschillende businesscases gevonden waarbij het opnemen van de verwachte beheerkosten voorgeschreven was. Tevens werd door andere organisaties het weglaten van de verwachte beheerkosten als een tekortkoming ervaren. Verder vormt het toewijzen van jaarlijkse budgetten aan een ICT­organisatie geen enkele belemmering om wel degelijk businesscases te hanteren voor strategische projecten. Sterker nog, het is aan te raden. Van Geel stelt tevens dat vrijgavecriteria niet rechtstreeks afgeleid kunnen worden uit een businesscase. Tevens zijn systeemeisen aan veranderingen onderhevig. Dit zijn open deuren. Natuurlijk is een initiële businesscase nog niet zover uitgewerkt dat alle vrijgavecriteria exact vaststaan en niet meer zullen wijzigen. Er zal echter wel een keuze gemaakt moeten worden voor richting en prioriteiten. Indien men een verre reis onderneemt, zal ook eerst globaal het reisdoel moeten worden vastgesteld met een schatting voor reisduur en reiskosten. Pas later kan dit worden geconcretiseerd en eventueel bijgesteld op basis van de realiteit. Ten slotte wordt gesteld dat er een ‘point of no return’ is, waarna een vrijgavebesluit een ritueel is geworden. Dit is een gevaarlijke uitspraak, maar onderschrijft in feite precies de uitspraak dat een vrijgavebesluit het herzien is van een investeringsbesluit. Wat zijn op dat moment de reeds gemaakte en verwachte kosten en baten? Indien de verwachte netto­opbrengsten negatief zijn, kan er beter gestopt worden, in plaats van domweg door te gaan. Dit ondanks het feit dat de afdeling Marketing wellicht al met campagnes is gestart. Natuurlijk speelt hier het psychologische effect dat het besluit tot stoppen moeilijk is. Men kan echter beter met een goede economische argumentatie besluiten te stoppen, dan krampachtig een potentieel fiasco door te zetten. AUTEUR: Hans Sassenburg Hans Sassenburg (hsassenburg@se­cure.ch) is zelfstandig adviseur. Naast het geven van gastcolleges aan de Universiteit van Bern, doet hij promotieonderzoek naar vrijgavecriteria aan de Rijksuniversiteit Groningen.