Een snelweg met rode kruizen, internetbankieren dagen onbereikbaar, onveilige software. Jaarlijks zien en horen we steeds vaker dat software vol fouten zit en toch is deze software getest. Testers hebben onjuistheden gevonden e opgelost, maar na een hertest is er iets anders onjuist en ga zo maar door. Steeds weer opnieuw is deze software opnieuw gecontroleerd. Door drie simpele maatregelen kan dit worden voorkomen.
Zullen we het eens een keertje in een keer goed doen? Zullen we eens een keer software maken in een project die niet constant weer opnieuw een hertest moet krijgen en zelfs met reeds bekende, of erger, onbekende fouten in productie gaat? Zou dat mogelijk zijn?
Software met nul bevindingen in productie laten gaan lijkt onmogelijk en misschien moeten we dat ook niet nastreven. Misschien moeten we juist nastreven dat we de software in één keer zo goed mogelijk maken. Hoezo in één keer goed hoor ik je denken. Het in een keer goed principe gaat er vanuit dat we software produceren waar we alle onjuistheden eruit halen snel na het moment van ontstaan, liefst zelfs op het moment van ontstaan.
Juist nu met de constatering van een nieuwe recessie kijken bedrijven weer waar ze op de kosten kunnen besparen. Zo ook weer op it en it-projecten. Het verleden verteld ons dat de bezuinigingen dan vooral bestaan uit het schrappen van minder belangrijke projecten en zoveel mogelijk besparen op de zogenaamde minder belangrijke zaken als de kwaliteit. Maar hier moet juist in worden geïnvesteerd om te besparen. Als we dingen in een keer goed doen besparen we op de kosten, maar ook op de doorlooptijd als een verhoging van de kwaliteit.
Door de juiste kwaliteitsmaatregelen op de juiste momenten te nemen en het toepassen van een kwaliteitsdenken gedurende het gehele project kan een aanzienlijke besparing ontstaan op de kosten van projecten. Al sinds de jaren 60 en 70 is het bekend dat het oplossen van onjuistheden het duurst is aan het eind van het project. Barry Boehm bracht dit zelfs duidelijk in beeld met zijn berekening. Een fout oplossen in productie is honderd keer zo duur als de oorzaak wegnemen tijdens het opstellen van de software eisen of requirements. Met het juist toepassen van deze maatregelen en dit kwaliteitsdenken is bewezen dat extreme besparingen worden behaald van zestig euro of hoger per geïnvesteerde euro.
Door het toepassen van een driesporen beleid rondom kwaliteitszorg en testen is het mogelijk om betere, goedkopere en snellere business resultaten op te leveren.
Drie te volgen sporen
Door te industrialiseren (Spoor 1) is het mogelijk om goedkoper te testen. Bijvoorbeeld door het gebruik van modellen voor het automatisch genereren van testgevallen wordt de efficiëntie van het specificatieproces van testgevallen verhoogd. En zodoende ook een betere invulling van de bemensing van de projecten.
Het goed toepassen van een kwaliteitsdenken en de juiste samenwerking (Spoor 2) levert hogere kwaliteit op van de software. Denk aan het samenwerken op overdrachtsmomenten in de vorm van ‘Quality Gates'. Door het opzetten van deze momenten van samenwerking wordt iedereen geholpen om onjuistheden te vinden en te rapporteren, zodoende wordt onduidelijke en onvolkomen informatie onderkend voordat er ook maar iets van code is ontwikkeld.
Door slimmer te werken door het gebruik van mogelijke innovaties (Spoor 3) worden resultaten sneller opgeleverd. Denk aan Model-Driven Engineering, maar ook het gebruik van modellen om software te simuleren. Door middel van deze nieuwe ontwikkelingen is het mogelijk om snel goede kwaliteit software op te leveren.
Door productkwaliteit middels dit driesporen beleid is het mogelijk om de business als it nog beter te ondersteunen en verder te gaan naar een hoger niveau van Business Kwaliteit, middels software die in één keer goed is.
Ja maar wat voegt dit artikel nu toe?
ik zou zeggen beste Sogeti: verbeter de wereld begin bij je zelf. Als softwarehuis staan jullie nou niet echt bekend om de succesvolle projecten.
Geweldig idee!
We maken alle software in één keer goed, en omdat het in één keer goed is, hebben we geen testers en kostbare testsystemen en -tijd nodig.
Alle projecten worden ineens opgeleverd binnen tijd en budget, met 100% kwaliteit.
Klein nadeel is wel dat alle testers ineens op straat zijn, maar we hebben nu wel feilloos werkende software en dat levert de maatschappij heel wat meer op tenslotte.
*** ### —- ++++ schrikt wakker uit zijn droom en gaat verder met het lezen van het artikel ++++ —- ### ***
Helaas, eigenlijk niets nieuws onder de zon, zoals Corne al opmerkt.
Testen is een vangnet, wat doorgaans gelukkig heel wat potentiële issues afvangt voordat de eindgebruiker met het product aan de slag gaat.
Maar begin eens aan de bron. Zorg eerst eens voor VAST personeel, dat langer dan 2 jaar in dienst blijft, en die SYSTEEM- EN DOMEIN-KENNIS opdoet. Mensen die snappen hoe eindgebruikers het systeem gebruiken, mensen die weten hoe je de zwakste schakel in je IT keten kunt ontdekken en verbeteren, die snappen dat er een verschil zit tussen storage en storage enz enz enz.
Maar ook mensen die een gedegen impact analyze kunnen doen indien een component vervangen moet worden.Ik zie ze nog voor me, de (zelfbenoemde) deskundigen die klaagden over de performance van hun PC, en zeiden dat een 100Mb netwerk (ze hadden nu 10Mb) het probleem op zou lossen. De gemiddelde networkload op de 10Mb link was minder dan 20%………
@ Corne: Het artikel lijkt me een aansporing om nou eindelijk eens toe te passen wat men weet dat een goede werkwijze is.
@ Tinus Esten: Een teer punt: software houses verkopen manuren, geen systemen. De wens om de zaken nu eens goed aan te pakken moet van de opdrachtgever komen want die wil kosten reduceren.
Maar de dynamiek bij een opdrachtgever die Sogeti inhuurt (grote organisaties, bedoel ik) is pervers: daar zitten mensen die hun positie in de organisatie ontlenen aan het budget dat hun ter beschikking staat. Deze mensen hebben dus ook geen prikkel om te besparen.
Het moet daar dus echt van de hoogste top komen, maar dan gaat het met de botte bijl.
En nu terzake: Ewald Rodenrijs verwijst naar een onderzoek in de jaren ’70 van Barry Boehm. Lastig is dat de wereld erg is veranderd. We hebben het niet meer over programmeurs, systeemanalisten, systeemontwerpers en informatieanalisten, maar over software engineers en business analysts. Dit sloot aan op de opkomst van de PC en de ontwikkeling van allerlei mooie hulpmiddelen.
Ik verwacht dat de conclusies van Boehm in grote lijnen nog steeds opgaan maar wat NU de optimale maatregelen zijn is, lijkt me, nog onduidelijk. Ruimte voor onderzoek. lijkt me.
Als het allemaal zo simpel is, waarom lukt het dan keer op keer niet?
Ik ben van mening dat door te industrialiseren het testen niet per definitie goedkoper wordt. Denk aan al het werk dat noodzakelijk is om dit allemaal in te richten en up-to-date te houden. Het zal vast heel veel andere voordelen met zich meebrengen, maar er zijn weinig projecten waar dit met succes toegepast kan worden. En waar je value for money krijgt met deze opzet.
En dan samenwerken op overdrachtsmomenten. Dat is wel heel procesmatig!
Ik ben van mening dat samenwerken gedurende het gehele project plaats moet vinden en niet alleen tijdens zgn. Quality Gates. De kracht van een goedlopend project zit juist in samenwerking en communicatie.
En jammer genoeg lenen lang niet alle projecten zich tot het inzetten van nieuwe ontwikkelingen om snel goede kwaliteit software op te leveren.
Dus zo simpel ligt het allemaal niet!
Industrialiseren van testen lijkt me geen goed idee. Testen is een activiteit in het wijzigingsproces. Die activiteit moet je goed beschrijven (werkinstructie), vastleggen (documenteren) en faciliteren (fatsoenlijke testomgeving). De industrialisatie zit hem meer in het institutionaliseren ervan (zie ook reactie PaVaKe: zorg voor testers in vaste dienst, of minstens voor testers die kennis hebben van en vertrouwd zijn met de omgeving).
Kwaliteitsdenken is een wat vaag begrip. Iedereen kan kwaliteitsdenken, maar kan iedereen ook kwaliteitsdoen? Kwaliteit kost geld. Waar snel en voor weinig extra functionaliteit ontwikkeld moet worden zal kwaliteit niet hoog op de agenda staan. Een goed samenspel van mensen, afspraken en middelen levert op den duur een hogere kwaliteit terwijl de kosten in de hand blijven. Ook bij softwareontwikkeling geldt dat goedkoop doorgaans duurkoop blijkt.
Innoveren is echt een lastige en ik ben benieuwd wat de auteur precies voor ogen heeft. In mijn beleving is de software de feitelijke innovatie. De wijze van ontwikkelen kun je innoveren (lees bijvoorbeeld eens ‘Getting Real’) waardoor bijvoorbeeld overbodige functionaliteit niet wordt gebouwd en dus ook niet getest hoeft te worden. Maar misschien is het een combinatie van de vorige twee die de ware innovatie op het testv(l)ak in gang zet. Dat je e.e.a. uitvoert met mensen die al vroeg in het traject worden betrokken. Die in samenwerking met de proces/requirements analist en de functioneel ontwerper de inconsistenties ondervangen en een goede basis voor de juiste cases en testgevallen kunnen leggen. Je kunt niet goed testen als je niet weet wat je test.
Misschien wil de auteur hier nog eens wat verder op in gaan?
Dit artikel heeft wel een hoog ‘ze moeten er eens voor zorgen dat …’ zonder te specificeren wie ‘ze’ dan wel moeten zijn gehalte.
Alle oorzaken rondom brakke software zouden inmiddels toch wel bekend moeten zijn, ik ga ze niet eens meer aanhalen.
Het is niet bijster moeilijk om basale fouten achter wege te laten.
Kwestie van serieus, en geordend werken. je personeel behoorlijk betalen maar daar ook serieuze eisen aan verbinden (zelfstandig eigen kennis verrijking om er maar eens een te noemen), en vooral je als verkoopmanager niet bemoeien met de techniek en dus haalbare deadlines af te spreken.
@Petra, het is zeker zo dat er nog wel eens fouten in een project kunnen sluipen. Daarom hebben we testers in het leven geroepen.
Maar de instelling bij sommige colega’s dat het mislukken van icp projecten tegenwoordig facto standaard is zet me toch wel te denken.
Nu ja.. allemaal al bekend lijkt me.
Ik ben het helemaal eens……… met Corne! Het is een verhaal dat deels bekend is en deels niet te doorgronden. Laat ik het dan niet eens hebben over de fouten. Ik denk dat de laatste decennia voldoende is aangetoond dat met de huidige werkwijzes en methodieken het onmogelijk is om software in 1 keer goed te kunnen maken. Misschien is dat ook wel helemaal niet haalbaar of betaalbaar. De genoemde 3 sporen gaan daar zeker ook niet veel aan bijdragen. Zouden we niet beter dit kunnen accepteren en eens gaan kijken naar wat binnen de mogelijkheden ligt en van daaruit gaan werken? Verbeteren kan dan stukje bij beetje doorgevoerd worden en door dat proces steeds tegen het ontwikkelproces aan te houden kun je op geschikte momenten die verbeteringen implementeren. Wat die verbeteringen zijn is dus afhankelijk van wat je huidige mogelijkheden zijn en waar je naartoe wilt/kan…. Dus laat de sporen voor wat ze zijn, ga eens kritisch kijken naar de eigen omgeving en acteer daarop door perceptie aan te passen en kleine stapjes te nemen die haalbaar zijn en echt ten goede komen. Niet omdat het in een boek staat, een goeroe het eens gezegd heeft of het elders werkt. Maar simpel, omdat het past en de perceptie correct is.