Vakmanschap is meesterschap
De kwaliteit van software begint met vakmanschap. Het wordt tijd dat we in opleidingen weer leren voorspelbare software te realiseren en dat onzinnige en uiteindelijk dure concessies aan de kwaliteit van die software worden vermeden.
Uit benchmarks van Gartner blijkt dat de initiële ontwikkelkosten van een informatiesysteem met een levensduur van 15 jaar gemiddeld 8 procent van de TCO (total cost of ownership) uitmaken. De hoogte van de TCO wordt bepaald door ontwerpbeslissingen en beslissingen met betrekking tot de levenscyclus van dit systeem. Bijvoorbeeld de ontwerpbeslissing of het systeem 5 × 9 uur of 7 × 24 uur per week beschikbaar moet zijn en de beslissing of het systeem 5, 10 of 15 jaar moet meegaan. Beslissingen in de eerste levensfase (of vaak het ontbreken van deze beslissingen) zijn van doorslaggevende betekenis voor de toekomst en kwaliteit van een informatiesysteem.
Is er daarom een norm nodig om die kwaliteit te bepalen? Niet per definitie, maar zo’n norm is wel een kapstok om kwaliteit objectiveerbaar en bespreekbaar te maken. De ISO 25010-standaard kan die kapstok zijn. Is kwaliteit onderhandelbaar? Ja, mits de opdrachtgever ook de consequenties van zijn beslissingen accepteert. Van de ontwikkelaar mag worden verwacht dat hij de consequenties van die beslissingen transparant en objectief op tafel legt.
Dit vraagt van de ontwikkelaar beheersing van zijn vak. Dan kom je automatisch uit bij vakmanschap. Kwaliteit van software begint met vakmanschap! Ik bedoel dat een ontwikkelaar vanuit zijn vakmanschap niet mag toestaan dat er aan de kwaliteit van software concessies worden gedaan terwijl de vereisten waaraan de software moet gaan voldoen wel om die kwaliteit vragen. Maar al te vaak staat de kwaliteit van software onder druk vanuit het belang van tijd en geld. We vragen tenslotte een autodealer ook niet of de auto iets goedkoper wordt als de airbags en veiligheidsgordels worden weggelaten.
Deze analogie gaat voor software ook op. Dat betekent dat een (internet)applicatie waar persoonlijke gegevens mee zijn gemoeid altijd van de juiste beveiligingsmaatregelen is voorzien, zodat deze gegevens niet zomaar op straat kunnen komen te liggen. Welke maatregelen hiervoor nodig zijn behoor je vanuit je vakmanschap te weten en altijd als automatisme toe te passen. Een simpel voorbeeld van niet onderhandelbare softwarekwaliteit.
Het is een misvatting dat softwarekwaliteit per definitie geld kost. Voorspelbaarheid van de kwaliteit van software is mogelijk als er meer gebruik wordt gemaakt van standaard softwareconstructies of standaard bouwstenen. Het is mijn overtuiging dat het maken van software een vak is. En een vak beheersen is opleiden. In de jaren ’80/’90 zijn veel ontwikkelaars opgeleid in het Volmac Structured Programming. Een opleiding waarin je het ontwikkelvak werd geleerd. En waar je leerde voorspelbare software te realiseren, software die het doet, óók als die het niet doet. En rekening te houden met onbekende omstandigheden. Daarom begint softwarekwaliteit met de kwaliteit van de ontwikkelaar en daarmee met de opleiding van de ontwikkelaar.
Zonder goede software geen succesvolle overheids-ICT. De kwaliteit van software is een onderwerp dat bestuurders aangaat. Software is niet tastbaar, maar je kunt de kwaliteit ervan wel degelijk controleren. Dat inzicht geeft een opdrachtgever houvast om zijn rol goed in te vullen en verkleint daarmee de risico’s op ICT-falen. Maar in de praktijk gaat het vaak anders. ‘Goed geregeld’ is een verzameling artikelen waarin iBestuur een poging doet een vinger achter deze problematiek te krijgen.
Onder redactie van Maarten Hillenaar en Jan Polkerman!Op 23 november organiseert iBestuur een symposium in Nieuwspoort over softwarekwaliteit. Gratis toegang voor deelnemers uit de publieke sector!
De jaren 80/90 met nu vergelijken is niet helemaal eerlijk. Toen was het een tijd waar het in de ICT met name ging om dataverwerking met basale invoer/uitvoer binnen een eigen netwerk. Hoezo security?
Dat is heel iets ander vergeleken met de mogelijkheden anno nu. Veelsoortige devices, permanent hangend aan het internet, de vele ontwikkelomgevingen en frameworks, de slimme clients (web) die men kan maken. Meer mogelijkheden, andere problemen. Zoals die security.
Maar net zoals het voor een ontwikkelaar onmogelijk is om kennis te hebben van alle systemen, talen, tools etc geldt dat ook voor alle aspecten die een rol spelen. Zoals security. Misschien moet je onderdelen van ict als specialistisch beschouwen waar je dan ook specialisten voor nodig hebt. En dan nog. Het realiseren dat security een belangrijk aspect is, is stap één zou ik zeggen.
Als het over kwaliteit gaat geloof ik niet zo in iso standaarden en het meten van software of het weer eens uitvoeren van zoveelste audit en controle. Het BIT vind ik hier ook een voorbeeld van, nog meer controle.
Dan geloof ik meer in de zoektocht naar voorwaarden voor een ICT project waarvan je zou kunnen verwachten dat het de kwaliteit positief beinvloedt. Het ICT boerenverstand.
Ik las hier al eerder, goed testen. Nou dat is er één. Maar ook, houd teams zo klein mogelijk, maak contact tussen belanghebbenden (gebruikers,ontwikkelaar,beheerders) eenvoudig. Neem de tijd.
Als het over ICT cultuur gaat dan is de trend dat projecten topzwaar zijn met veel mensen waarbij de nadruk op de methodes en de processen ligt. Hoeveel mensen lopen er inmiddels niet rond projecten rond te springen? Het overbekende Poolse landdag model. Van de continu verbetercoach, de lean black belt coach, de scrum master, product owners tot de verandermanager. Maar wat dragen ze bij? Misschien moet dat eens ter discussie gesteld worden. Laat het weer ICT vakinhoudelijk worden. In plaats het proces de focus heeft en belangrijker dan de inhoud is geworden. Niet alleen in de ICT overigens….het is een maatschappelijk fenomeen. Wat een geldverspilling!
En tot slot, niet meer tot alles in essentie van een ict project(beslissingen, management, uitvoering, controle, audits) uitbesteden en zelf inhoudelijke en technische verantwoordelijkheid nemen. Al is het maar om de grip weer te krijgen in plaats van overgeleverd te zijn aan de goden.
Hallo Jan,
Zie ook mijn reactie naar aanleiding van de post van Maarten.
Volgens mij is er in het algemeen niets mis met de kwaliteit van de ontwikkelaars. Alleen als de opdrachtgever geen kwaliteit vraagt, krijgt hij het ook niet. Er is immers al zoveel waar de ontwikkelaar/programmeur op afgerekend wordt. Mijn ervaring is dat ontwikkelaars het leuk vinden om kwaliteit te leveren conform de ISO 25010-standaard, maar dan moet het wel in de opdracht zitten en moet de opdrachtgever ook controleren. Ook hier geld dat aandacht nodig is om een resultaat te krijgen.
Immers niets menselijks is een ontwikkelaar vreemd :)
Met vriendelijke groet,
Jos Schreur