‘Leg kwaliteit van software vooraf vast!’

“Over kwaliteit lopen de meningen sterk uiteen. Er is ook niet zoiets als ‘een’ kwaliteit, het is een ingewikkeld samenspel van verschillende factoren. Al die kwaliteitsfacetten samen bepalen uiteindelijk hoe de gebruikers over een softwareproduct denken. Ik leun hier vaak aan tegen de uitspraken van de Britse architect Christopher Alexander, die het heeft over ‘Quality without a name’. Met andere woorden een vaag begrip dat je eigenlijk met woorden haast niet kunt omschrijven”, aldus Aksit. Alexander houdt zich niet alleen bezig met ‘design’ in de bouwkunde, zijn ideeën stralen ook uit naar andere vakgebieden. Zij die actief zijn op het terrein van objectgeoriënteerd programmeren lopen doorgaans weg met de denkbeelden van de architect. Daarbij gaat het vooral om zijn publicatie onder de naam Patterns, die gaat over patronen die in de natuur en de techniek voorkomen. Bij het ontwikkelen van programmatuur is het de kunst om de verschillende factoren die samen ‘de kwaliteit’ vormen, met elkaar in balans te brengen. Hoe zo’n balans precies wordt gevormd is afhankelijk van het eindproduct, degene die dat product maakt en degene die het moet gebruiken. “We hebben ook nog geen exacte definitie van zo’n balanssituatie. Je moet op je gevoel afgaan. Als het gevoelsmatig goed zit, dan ben je er”, meent Aksit. Bij het productieproces zijn grofweg twee zaken te onderscheiden. Aan de ene kant zijn dat de eisen die door een afnemer aan een product worden gesteld, anderzijds is er de vraag hoe goed het product aansluit op die eisen. Met andere worden: wat is de kwaliteit ervan? Aksit: “Dat eisenpakket, wij noemen dat de Requirements, wordt gezien als een probleem dat moet worden opgelost. De uitkomst is de ‘kwaliteit’ waarvan de waarde zo goed mogelijk dient te worden. Hoe je dat gaat doen is maar helemaal afhankelijk van je fantasie. Neem als voorbeeld een softwarepakket dat flexibel moet zijn, maar ook goedkoop. Je moet ervoor waken dat de oplossingen die je vindt niet met elkaar in conflict raken. Het is best mogelijk om een zeer flexibel pakket te maken, maar als dat vreselijk duur is, dan voldoe je niet aan de beide randvoorwaarden.” Bij de van oudsher bekende manier van softwareontwikkeling wordt eerst een product gemaakt, waarna pas de kwaliteit wordt gemeten. Voldoet het geheel niet aan de criteria, dan wordt een deel van de ontwikkeling aangepast en opnieuw gedaan. “Wij stellen een andere werkwijze voor, door al van te voren een kwaliteitsplaatje te tekenen. Je ‘meet’dus eigenlijk terwijl er nog helemaal niets te meten valt. Anders gezegd: je bent bezig met virtuele kwaliteitscontrole”, zegt Aksit. Zo’n manier van werken kan ervoor zorgen dat een nieuw softwarepakket in een keer optimaal wordt ontwikkeld. Maar om een en ander te realiseren, zullen wel geheel nieuwe technieken moeten worden ontwikkeld. “Je kunt niet even een stel kwaliteitsgeoriënteerde ontwikkeltools uit de kast trekken, die zijn er gewoon niet”, aldus Aksit. Die tools moeten ontwikkeld worden, een proces dat lange tijd in beslag neemt. “Je moet dan denken in termen van jaren, waarin continu aandacht moet zijn voor problemen die zich in de praktijk voordoen. Op een bepaald moment heb je zoveel inzicht in de dagelijkse praktijk, dat je patronen gaat herkennen. Dat betekent dat een bepaald eisenpakket snel uiteengerafeld kan worden tot een reeks problemen waar je makkelijk een oplossing voor kunt vinden.” Aksit is een voorstander van ‘leren door te doen’. Samen met het bedrijfsleven onderzoek doen zorgt ervoor dat de inzichten snel tot stand komen. Hoewel, snel is misschien te veel gezegd. “We benaderen ons doel stapje voor stapje. Vanuit de praktijkervaringen komen nieuwe technieken naar voren. We worstelen nog steeds met een aantal problemen. Zo is er nog steeds geen expliciete relatie tussen de gevolgde ontwikkelingstechniek en de kwaliteit van het eindproduct. Bij de verschillende definities hebben we ook moeite alles onder woorden te brengen. Bijvoorbeeld: een softwarepakket moet relevantie hebben voor een bepaald toepassingsgebied. Prachtige formulering, maar hoe kun je dat nader preciseren? Of: ‘de software dient aanpasbaar te zijn’. Mooie volzin opnieuw, maar wat wordt hier precies bedoeld?”, vraagt Aksit zich af. Niet alleen de kwaliteit van het eindproduct is van belang, ook de kwaliteit van het proces dat wordt gevolgd om tot dat eindproduct te komen speelt een heel belangrijke rol. Een praktijkvoorbeeld kan veel duidelijk maken. Aksit legt uit: “Stel, je hebt een producent van computerspelletjes, die in 2003 met een nieuw kwalitatief hoogstaande game op de markt wil komen. Voordat er ontwikkeld kan worden, moeten we eerst een vragenlijst afwerken. Belangrijk in dit verband is, of het spel ook via een netwerk moet kunnen worden gespeeld. Via internet, waarbij derden als tegenstander fungeren. Misschien wil die fabrikant dat niet meteen, maar over een aantal maanden wil hij dat juist wel. Zeg je aan het begin dat het niet hoeft, dan snij je eigenlijk de weg naar internet af. In dat geval moet je hele nieuwe spelsoftware laten schrijven.” Dit is een voorbeeld bij uitstek van een aanpasbaar ontwerp. Het spel kan op zichzelf staand gebruikt worden, maar via een simpele ingreep kan ook via het netwerk worden gespeeld. Er hoeft natuurlijk niet alleen gedacht te worden aan internet, je zou ook twee spelconsoles aan elkaar kunnen koppelen, zodat de bezitters tegen elkaar kunnen spelen. “Een voorbeeld van een gedistribueerde spelsituatie”, zegt Aksit, “en ook daar zul je in een vroeg stadium rekening mee moeten houden. Je moet je product ‘futureproof’ maken. Natuurlijk kun je niet alle toekomstige eisen en wensen aan het begin al afdekken, maar je kan wel een heel eind komen. Wil je dan later nog iets aan het spel toevoegen dan kan dat meestal tegen geringe kosten.” Het kan voorkomen dat van te voren niet is te overzien welke richting een project op zal gaan. Of dat een producent het veel te moeilijk vindt om met alle mogelijkheden rekening te houden. Aksit: “In zo’n geval zul je een adaptief ontwikkelingsschema moeten volgen. Dat wil zeggen, dat je het ontwerp opdeelt in kleine stapjes, die je steeds kunt aanpassen aan de geldende eisen. Dit noemen we een adaptieve werkwijze. Het is daarbij de kunst om de stapjes de juiste grootte te geven. Maak je ze te klein, dan verspil je een hoop moeite, bij stappen die te groot zijn kan het financieel bezwaarlijk zijn om halverwege een aanpassing aan te brengen.” Het ontwikkelingsproces kan ook worden bemoeilijkt doordat de vraag uit de markt plotseling heel anders wordt. Als de gebruikers van de software bijvoorbeeld een eis op tafel leggen waar niemand ooit rekening mee heeft kunnen houden. “In zo’n geval kun je veel baat hebben bij het werken met een softwaregenerator. Dat is een module die de software produceert aan de hand van door de ontwikkelaar ingegeven parameters. Het is trouwens in het algemeen aan te raden om gebruik te maken van generatoren, want ze verkleinen de kans op fouten.”