NPR 5326: kwaliteitsborging maatwerksoftwareontwikkeling en -onderhoud

Interview

Wat is een Nederlandse Praktijkrichtlijn (NPR)?

Een Nederlandse Praktijkrichtlijn (NPR) kan een voorloper van een standaard worden genoemd. In tegenstelling tot een norm is een NPR niet normerend, maar adviserend. Een Praktijkrichtlijn is een document dat beschrijft hoe er praktisch gewerkt wordt binnen een bepaalde sector of aandachtsgebied. Een NPR bevat goede ideeën vanuit brede vertegenwoordiging van belanghebbenden en wordt samengesteld op basis van consensus binnen de ontwikkelende normcommissie ([NEN19]). Het is mogelijk om in een aanbesteding een NPR op te nemen, maar een NPR is richtinggevend en dus niet normatief van aard. Uiteraard kan een aanbesteder een onderzoek starten om vast te stellen of een aanbieder zich houdt aan de NPR, of in ieder geval werkt in de geest van de inhoud.

Eigenlijk maakt het ook niet zoveel uit of de inhoud van de NPR 5326 als een norm of een richtlijn wordt bestempeld, zolang er maar goede ideeën in staan. Het is handig om overzichten te hebben met goede ideeën zodat je je alleen bezig hoeft te houden met dingen die je niet doet in plaats van het wiel opnieuw uitvinden. Met deze NPR, waar momenteel de laatste hand aan wordt gelegd, wordt beoogd een handreiking voor toepassers te bieden.

Kun je kort toelichten wat de NPR 5326 beoogt te bereiken?

De NPR 5326 redeneert vanuit de volgende gedachte: softwareontwikkeling is moeilijk, en je loopt vrij veel risico als je maatwerksoftware ontwikkelt, wat ook regelmatig in de krant te lezen is en door direct betrokkenen aan den lijve wordt ondervonden. Gelukkig zijn er voor veel risico’s van maatwerksoftwareontwikkeling bekende tegenmaatregelen (in de NPR: ‘beheersmaatregelen’) die de risico’s verminderen of de impact verlagen.

De NPR dient als een referentiedocument, waarbij voornamelijk aandacht is besteed aan beheersmaatregelen voor risico’s die als weinig discutabel kunnen worden bestempeld. Een wetenschappelijke onderbouwing hiervoor zou mooi zijn, maar goed gecontroleerde experimenten, laat staan dubbelblind onderzoek, zijn nu eenmaal lastig in de IT. In dit perspectief lijkt IT meer op een gammawetenschap: het gaat uiteindelijk om mensen die iets doen met technologie, wat per definitie slecht te voorspellen is.

Daarom is ervoor gekozen om in deze NPR beheersmaatregelen op basis van consensus op te stellen, wat heeft geleid tot een overzicht van risico’s met voor de hand liggende maatregelen, waarvan bewijs of een sterk vermoeden bestaat dat deze helpen.

Maatwerksoftwareontwikkeling goed uitvoeren is vaak ingewikkeld en duur. Er is daarom van uitgegaan dat je als organisatie meerdere van dit soort projecten doet; voor één project ga je immers niet van alles optuigen, maar is uitbesteden wellicht een interessantere optie. De NPR is daarom geschreven vanuit de assumptie dat een organisatie meerdere projecten uitvoert waarin de ontwikkeling van maatwerksoftware een rol speelt, waarbij is voorzien in een ondersteunende afdeling. Dit maakt het de moeite waard om bepaalde zaken structureel te organiseren.

Hoe is het idee ontstaan om de NPR 5326 te schrijven?

Bij ICTU ontstond drie jaar geleden een afdeling die projecten waarin maatwerksoftware wordt ontwikkeld of onderhouden, ondersteunt met allerlei standaarden en diensten rond security, performance, een kwaliteitssysteem, et cetera. Deze afdeling, ICTU Softwarerealisatie (ISR), heeft geïnventariseerd wat er binnen een groot gedeelte van deze projecten het merendeel van de tijd wordt gedaan, en dit vastgelegd in een kwaliteitsaanpak. Deze aanpak beschrijft hoe ICTU projecten aanpakt waarin maatwerksoftware wordt ontwikkeld.

ISR kreeg van de directie de opdracht mee om naast deze werkzaamheden in algemene zin softwareontwikkeling binnen de Nederlandse overheid naar een hoger plan te brengen, iets wat past bij de maatschappelijke doelstelling van ICTU (de overheid helpen bij het realiseren van een betere digitale dienstverlening).

Hieruit ontstond het idee om voor de interne kwaliteitsaanpak een standaard op te stellen. Met dit idee is het NEN (Nederlands Normalisatie-instituut) benaderd en een werkgroep opgezet, waarbij naast ICTU ook experts van KPMG Advisory, Centric, SDB en Philips zijn aangehaakt. Juist deze diversiteit heeft gezorgd voor interessante discussies, waarbij bijvoorbeeld al snel duidelijk werd dat de geïdentificeerde risico’s niet specifiek waren voor de overheid, maar breed toepasbaar zijn.

Hoe heeft de inventarisatie van risico’s en beheersmaatregelen plaatsgevonden?

De inventarisatie had het karakter van een groepsbrainstorm in combinatie met een literatuuronderzoek, waarbij de inhoud van de kwaliteitsaanpak door de diverse commissieleden is ingebracht. Vervolgens is gekozen voor een risicogedreven aanpak, waarbij wordt geredeneerd vanuit de risico’s die je wilt verminderen als je maatwerksoftware ontwikkelt of onderhoudt.

In de literatuur bleek het lastig om recente informatie te vinden over dit onderwerp. Er is zodoende gekozen om de risicotaxonomie uit het Technical Report van het Software Engineering Institute [SEI93] te nemen als basis, en deze te combineren met de input van de werkgroepleden en recentelijk de input van een aanzienlijke groep reviewers, die sinds december 2018 is aangehaakt. Daarmee wordt de NPR het resultaat van een combinatie van literatuuronderzoek en verenigde kennis.

Het inventariseren van de risico’s was echter niet eens de grootste uitdaging. Een grotere uitdaging zat in het opstellen van aanbevelingen voor maatregelen waarmee met voldoende zekerheid gezegd kan worden dat ze helpen bij het wegnemen of verlagen van die risico’s. Dit is echter lastig te onderzoeken; elk project is uniek en kan zodoende niet eenvoudig met andere projecten worden vergeleken. Daarnaast wordt er gewerkt met diverse sets aan maatregelen, waardoor het lastig is te herleiden welke maatregel het meest effectief is geweest.

Hoe verhoudt de NPR 5326 zich tot de ISO/IEC 25010-norm?

De ISO/IEC 25010 biedt een opdeling van het begrip ‘softwarekwaliteit/productkwaliteit’ in allerlei sub-karakteristieken, waarbij beschreven wordt hoe je deze kunt gebruiken om software te evalueren en kwaliteitskarakteristieken kunt meten (zie ook het kader hierover op pagina 52). Het gaat bij deze norm zodoende vooral om het vaststellen van de kwaliteit.

De NPR beoogt juist maatregelen te bieden die gebruikt kunnen worden om te borgen dat er goede kwaliteit wordt geleverd. Dergelijke handreikingen staan niet in de ISO/IEC 25010-norm beschreven.

Men kan zich afvragen of wat er in de NPR staat eigenlijk wel te standaardiseren valt. Het is eigenlijk een soort dieetadvies: waarvan weten we dat het helpt, en waarvan weten we dat het niet helpt? Dat laatste komt overigens niet in de NPR voor: de maatregelen hebben vooral het karakter van aanbevelingen, iets anders dus dan bijvoorbeeld de specificaties van de afmetingen en voltages van stekkers.

Hoe kan de NPR toegepast worden, en door wie?

Er zijn globaal drie gebruikersgroepen te definiëren:

1. Organisaties die zelf software ontwikkelen en onderhouden. Deze organisaties kunnen de NPR gebruiken om hun eigen processen te verbeteren en risico’s te verminderen. De NPR kan gebruikt worden als inspiratiebron voor nieuwe maatregelen, maar kan ook dienen als meetpunt om vast te stellen welke maatregelen al actief zijn. Met de assessment tool die als onderdeel van de NPR wordt ontwikkeld, is het ook mogelijk om relevante risico’s te selecteren en alleen de bijbehorende maatregelen overzichtelijk weer te geven.
2. Opdrachtgevers kunnen bij een aanbesteding uitvragen of potentiële opdrachtnemers de NPR gebruiken, en in welke mate. De NPR kan het startpunt zijn om uit te vragen hoe een potentiële opdrachtnemer bepaalde onderwerpen heeft aangepakt, of hoe zij denken dit te zullen doen. Dit helpt mogelijk om de opdrachtnemer bewuster te maken van risico’s.
3. Procesverbeterende reviews: met de NPR in de hand kan objectief worden vastgesteld in hoeverre de risico’s bij maatwerksoftwareontwikkeling en -onderhoud zijn afgedekt.

Ook wanneer er sprake is van een hoge mate van samenwerking binnen een ontwikkelproject is er altijd een scheiding tussen een partij die bepaalt wat er moet gebeuren en de requirements opstelt, en een andere partij die bouwt. Waar mogelijk is binnen de NPR deze verhouding in het midden gelaten. Je kunt de NPR zodoende ook toepassen als de rol van opdrachtgever en opdrachtnemer binnen dezelfde organisatie zijn ingevuld.

Waar liggen nu de grootste risico’s in de ontwikkeling van maatwerksoftware?

Binnen de NPR zijn de risico’s niet geordend op omvang, juist omdat deze altijd voor een deel contextafhankelijk zullen zijn. In het algemeen zie ik een exponentiële toename van de risico’s wanneer er meer partijen betrokken zijn bij de realisatie en de omvang sterk stijgt, zeker waar dit het aantal koppelingen betreft. Je zou kunnen zeggen: een twee keer zo groot project loopt vier keer zo veel risico. Binnen de overheid wordt software ontwikkeld waarbij veel partijen betrokken zijn en inspraak hebben, en worden er vooral grote applicaties gebouwd met veel aansluitingen. Dit zorgt ervoor dat de risico’s navenant toenemen.

Dit risico is ook benoemd in de NPR, waarbij maatregelen hiervoor worden beschreven, zoals het opknippen van functionaliteit, iteratief en incrementeel werken, het maken van een product breakdown structure, het prioriteren van wijzigingen en proberen niet alles tegelijk te doen, maar de belangrijkste functionaliteit eerst te realiseren. Als je een applicatie met honderd functies wilt laten bouwen, is het verstandig dat het product met de eerste tien functies al werkt, zodat er vanaf het begin een werkend systeem is dat je incrementeel verder kunt ontwikkelen. We weten namelijk pas zeker dat software werkt wanneer deze in gebruik is genomen. Keer op keer blijkt dat software die alleen in acceptatie draait geen werkende software is, ook niet als het alle acceptatietesten doorloopt. Bij het daadwerkelijk gebruik komen er immers altijd zaken aan het licht waar van tevoren niet aan gedacht is.

Dat is ook het interessante aan softwareontwikkeling, je hebt altijd ‘onbekende onbekendes’. Dit zijn dingen waarvan je niet weet dat je ze niet weet. Als je dit weet, kun je gericht actie ondernemen. Als je bijvoorbeeld het getal pi tot twintig cijfers achter de komma nodig hebt, weet je dit hoogstwaarschijnlijk niet uit je hoofd, maar je weet wel hoe je erachter kunt komen, wat dus eigenlijk geen probleem is. Het kan echter zo zijn dat je niet eens weet dat je pi tot twintig cijfers achter de komma nodig hebt. Een goede manier om achter de ‘onbekende onbekendes’ te komen, is om de software zo snel mogelijk in gebruik te nemen, want dan ontdek je ze vanzelf. Daarnaast zijn er, zeker bij grotere applicaties met veel gebruikers, methodes om dit te versnellen. Hierbij kan bijvoorbeeld gedacht worden aan het faciliteren, zodat een deel van de gebruikers een nieuwere versie gebruikt (a/b-testing), zonder dat de gehele populatie er last van heeft.

Is de NPR al af? Wat moet er nog gebeuren?

De NPR is nog niet af. Eind vorig jaar is het ontwerp gemaakt en dit is in november 2018 ter review gepresenteerd aan belangstellenden. Hiervoor is veel interesse getoond, zowel vanuit de publieke als private sector. De belangstellenden hadden tot half januari de tijd voor een review. Op dit moment wordt in een aantal groepen het reviewcommentaar verwerkt, waarbij een aantal reviewers ook tot de werkgroep is toegetreden.

Na het verwerken van het reviewcommentaar volgt nog een tweede, interne reviewronde in mei 2019. De ambitie van de commissie is om de NPR voor de zomer inhoudelijk te hebben afgerond, en deze voor een laatste redactieslag aan te bieden bij het NEN.

De publicatie zou dan na de zomer kunnen plaatsvinden, waarmee het traject, gerekend vanaf de officiële kick-off, dan ruim twee jaar heeft geduurd. Dit is zeker een prestatie, aangezien alle commissieleden het werk aan de NPR naast het reguliere werk bij hun werkgevers hebben vormgegeven.

Welke volgende stappen verwacht je na de afronding van de NPR?

Veel van de vervolgstappen liggen bij het NEN. Er zijn initiatieven voor diverse publicaties, waarna moet blijken of organisaties de NPR ook daadwerkelijk zullen toepassen.

ICTU heeft haar kwaliteitsaanpak ingebracht en deze is in de NPR mede als basis gebruikt. Wanneer de NPR is afgerond, zal ICTU natuurlijk zelf ook haar kwaliteitsaanpak weer met het eindresultaat vergelijken. We zullen dan bekijken in hoeverre deze aansluit, en wat er gedaan kan worden met de overige risico’s en bijbehorende maatregelen. De kwaliteitsaanpak van ICTU verwijst al naar diverse standaarden, zoals de ISO/IEC 25010. De verwachting is dan ook dat de NPR wordt overgenomen als onderbouwende standaard, en ICTU ook volgens deze nieuwe NPR zal werken.

De hoop is dat de partijen die softwareontwikkeling in de markt zetten de NPR zullen gebruiken en wellicht zelfs laten meewegen in het aanbod van de aanbieders. Andersom hopen we ook te zien dat aanbieders de NPR zullen toepassen om concurrentievoordeel te bereiken, waarbij ze bijvoorbeeld aangeven deze NPR in te zetten om het risico voor de opdrachtgever actief te verminderen.

Hoe kijk je terug op het gehele proces?

Binnen het traject vond ik het erg leuk en verrijkend om samen te werken met verschillende mensen van organisaties met deels een andere manier van kijken naar de (software)wereld. Het traject vereist geduld, zeker als je gewend bent elke drie weken een nieuwe versie van software op te leveren. Daarnaast moet je flexibel genoeg zijn om soms ook een denkbeeld weer los te laten, zoals de initiële gedachte dat de NPR overheid-specifiek zou moeten worden. Dit maakt het een leuk proces, waar we met veel plezier aan gewerkt hebben en waarvan er na de zomer hopelijk een resultaat ligt dat veel organisaties nuttig kunnen toepassen.