‘Ontwikkel in dienst van productie’ (Computable 2005 nr. 4): de titel van het stuk doet je de haren ten berge rijzen. Het klinkt als ‘rijd meer auto want daar wordt Shell beter van’. Dit vindt quality consultant Sybren Brouwer.
Waarom moet de aandacht zo sterk op productie gericht worden? Volgens de auteur van het artikel in Computable 4 ligt dat met name in de aard van het productieproces, in de continue stroom van activiteiten. Natuurlijk heeft hij daar gelijk in: het grootste deel van de kosten zit in de productiefase. Fouten in de software die pas in die fase omhoog komen, zijn ook vijf tot honderd keer duurder om op te lossen.
De benadering van Ferdinand Geuther begint echter tekort te schieten wanneer we bij het eind van het artikel aankomen.
Het artikel wil benadrukken dat er te weinig aandacht is voor het productieproces, maar in wezen beschrijft het hoeveel van de projecten te lijden hebben onder matig tot slecht projectmanagement, onder het maken van keuzes zonder daarvan de gevolgen volledig op een rijtje te hebben. Door professioneel projectmanagement (bijvoorbeeld door het toepassen van de Prince2-methoden) beschik je over een business case die voor een fors deel Geuthers adviezen bestrijkt. Voor de auto is de business case: waarom zou je zo’n ding kopen en hoe draagt hij bij aan wat ik wil doen? Heldere doelstellingen, het omvatten van het volledige proces en een gedegen change management vallen hier onder.
Risicoanalyse
Een ander nadeel van slecht projectmanagement is dat het niet bijdraagt aan een goed testproces. Een testproces moet gebaseerd zijn op een analyse van de risico’s van het project en op de risico’s van het product (zie ook het artikel dat Maurice Groeneveld schreef in Computable van 19-11-2004). De risicoanalyse is nodig om een prioriteitstelling te kunnen maken, alles testen kun je nooit. Basis voor de product-risicoanalyse zijn de kwaliteitskenmerken van software, zoals onder meer beschreven in de norm ISO 9126. Hiervan uitgaande wordt alles bestreken. Niet alleen wordt de functionaliteit, maar ook de gebruiksvriendelijkheid en de performance getest, en is er aandacht voor de betrouwbaarheid en het onderhoudsgemak van de software. In het opstellen van die risicoanalyse zullen ook alle relevante partijen betrokken zijn, inclusief de productiebeheerders en de gebruikers. Het opzetten van de tests is gebaseerd op de risicoanalyse. De tests zullen niet ophouden bij de software; het toepassen van beproefde technieken als de procescylustest zorgt voor een volledige dekking van de betreffende bedrijfsprocessen.
Goed projectmanagement houdt immers ook in dat je weet dat het in productie nemen van software een proces is dat vaak problemen oplevert, want veel is nieuw en er kan maar beperkt op bestaande ervaring gebouwd worden. Ook hier helpt de vooraf uitgevoerde risicoanalyse; op de meest risicovolle momenten kan men dan over de juiste kennis beschikken. Het aantal wijzigingen dat de productiebeheerders voor hun kiezen krijgen wordt op basis van de risicoanalyses zo klein mogelijk gehouden. Elke wijziging van productie impliceert immers het introduceren van risico’s. Wijzigingen worden echter gedreven door de business case en dus positief beoordeeld voor de gebruiker en de risico’s worden als aanvaardbaar geschat.
Kortom, goed projectmanagement, creatieve softwareontwikkeling en gestructureerd testen zorgen ervoor dat het ontwerp en de ontwikkeling gericht zijn op flexibiliteit, onderhoudsgemak en efficiency: dus niet alleen op het halen van de deadline. Bovenal zorgen ze er ook voor dat de toekomstige gebruiker van de software betrokken is bij het ontwikkelen, zodat hij zelf kan bepalen of en zo ja, hoe het ontwikkelde product hem helpt in zijn dagelijkse werkzaamheden. Oftewel, dat hij niet in zijn auto rijdt om benzine te verbruiken, maar om eerder bij zijn doel aan te komen.< BR>
Sybren Brouwer, Quality consultant bij een grote financi�le instelling