Bureau ICT-toetsing

Ministerie van BinnenlandseZaken en
Koninkrijksrelaries

Ministerie van Binnenlandse Zaken en Koninkrijksrelaties
De staatssecretaris, drs. R.W. Knops
Postbus 20011
2500 EA Den Haag

Bureau ICT-toetsing
Turfmarkt 147
Den Haag
Postbus 20011
2500 EA Den Haag
www.bureauicttoetsing.nI
Contactpersoon

Kenmerk
Uw kenmerk
2018-000019407

Datum
Betreft

18 mei 2018
Reactie BIT op advies commissie BRP

Bijlage(n)
1

Geachte heer Knops,
De commissie BRP heeft in uw opdracht een onderzoeksrapport “Niet te stoppen”
opgesteld over de aansturing en besluitvorming van de operatie Basisregistratie
Personen (BRP). Als een van de lessen in dat onderzoeksrapport adviseert de
commissie BRP om aandacht te besteden aan het verder versterken van de
robuustheid van BIT-adviezen. De commissie wijst hierbij op het belang van een
hoge kwaliteit en een transparante onderbouwing van de BIT-adviezen. U heeft mij,
in mijn hoedanigheid als hoofd BIT, gevraagd om een reactie op dit advies van de
commissie BRP.
In algemene zin onderschrijft het BIT deze aanbeveling van harte. Versterking van
de robuustheid van de BIT-adviezen is een continue proces, waar het BIT al sinds
zijn oprichting in 2015 aan werkt. Ook de Toezichtsraad van het BIT deelt en
ondersteunt deze ambitie.
Het BIT heeft bij voorbeeld geïnvesteerd in kennis en methoden om kwalitatieve en
kwantitatieve conclusies te trekken op basis van primaire bronnen, zoals door
projecten zelf bijgehouden ontwikkeladministraties, documentatie, ontwerpen en
broncode. Deze technieken geven een op feiten gebaseerde aanvullende
onderbouwing aan de BIT-adviezen, naast de meer gebruikelijke technieken van
interviews, expertopinie en documentenonderzoek.
Bijvoorbeeld, de commissie geeft in zijn advies aan dat het BIT een 30% ratio voor
testwerk hanteert, die door het projectteam en betrokken deskundigen niet
worden herkend. De gebruikte technieken en onderbouwing zijn zowel gebaseerd
op gepubliceerde resultaten van empirisch wetenschappelijk onderzoek als op
eigen technische analyses van de broncode en versiebeheersystemen van het BRP
project. Gebruikmakend van verschillende analysemethodes zijn wij tot
gelijkluidende conclusies gekomen en deze zijn dan ook in het BRP advies
opgenomen. In de bijlage treft u meer detail over de analyses.
De commissie BRP merkt in zijn advies verder op dat ten aanzien van de kosten van
inbeheername het BIT een hoge taxatie van één partij accepteerde zonder hiernaar
verder onderzoek te doen.
Pagina 1 van 4

Bureau ICT-toetsing
Datum
18 mei 2018
Kenmerk

In ons concept BIT-advies vermeldden wij als kosten voor inbeheername BRP €52
miljoen, waarvan nog €40 miljoen resteerden als te maken kosten. Aan zijn reactie
op het conceptadvies voegde de minister van BZK een door de toekomstige
beheerder, de Rijksdienst voor ldentiteitsgegevens (RvIG), opgestelde herijking toe
waarin de schatting van deze kosten werd verhoogd tot €134 miljoen, waarvan nog
€116 miljoen resteerden. Aangezien deze (veel) hogere taxatie de conclusie van ons
conceptadvies op geen enkele wijze veranderde, en deze afkomstig was van de
minister van BZK zelf hebben wij besloten deze meest recente schatting in ons
definitieve advies op te nemen. Wij hebben daarbij wel expliciet aangegeven dat de
begroting voor inbeheername door het programma IBN BRP ‘zeer recent’ was
aangepast. Ook hebben we de minister van BZK als bron vermeld met daarbij de
datum van ontvangst van deze taxatie (24 mei 2017).
Echter, de minister van BZK gaf in zijn brief ook aan dat deze hogere
kostenschatting voor inbeheername BRP “nog niet besproken is in de relatie
opdrachtgever en opdrachtnemer”. Met de kennis van nu was het wellicht
verstandig geweest om dit voorbehoud expliciet te vermelden, en daarom ook de
eerdere lagere cijfers uit ons conceptadvies te noemen, naast de nieuwe hogere
cijfers van de minister van BZK.
Het doel van BIT-adviezen is om de Tweede Kamer en de verantwoordelijk minister
te informeren. Omwille van de leesbaarheid werken we in onze schriftelijke
adviezen aan de betrokken bewindspersoon technische onderbouwingen niet
volledig uit. De les die wij trekken uit het advies van de commissie BRP is dat we in
de toekomst waar mogelijk meer aandacht besteden aan de transparantie van de
onderbouwing.
Wij danken u voor uw verzoek en de gelegenheid om te reageren op het advies van
de commissie BRP.
Hoogachtend,
namens het Bureau ICT-toetsing,

Hans Wanders

Pagina 2 van 4

Bureau ICT-toetsing
Datum
18 mei 2018

Bijlage. Onderbouwing ratio testwerk

Kenmerk

BIT hanteert in het advies een 33% ratio voor het resterende testwerk (en niet zoals
de commissie BRP aangeeft 30%) die wij hebben ontleend aan de uitgebreide
literatuur die over dit onderwerp bestaat. Deze literatuur geeft
industriegemiddelden voor de hoeveelheid testwerk als ratio van de totale
software-ontwikkelinspanning; naarmate projecten groter worden, neemt de ratio
voor testwerk toe. Een gemiddeld project spendeert volgens deze gemiddelden
52% van de totale effort om 98% van de fouten te vinden bij oplevering (zie: Jones
en Bonsignour, The Economics of Software Quality, 2012, Addison-Wesley, Table
5.10, p.341). Wij denken dat bij het BRP-systeem 98% van de fouten bij oplevering
eruit moet zijn.
Dit percentage van 52% correspondeert overigens met de totale test effort van 53%
in een voorbeeldberekening van een groot project zoals aangegeven in Jones, 2000,
Software Assessments, Benchmarks and Best Practices, Addison-Wesley, p.188-198.
Omdat de unittesten (ratio van 16%) door het programma reeds waren uitgevoerd,
resteren nog uitvoering van de functionele testen (14%), en de volledige systeemen acceptatietesten (23%), wat een totale resterende ratio voor testwerk van 37%
geeft.
Het programma heeft ook tijd besteed aan functionele testen, maar wij
constateerden dat zij in ieder geval sinds 2015 worstelden met het testproces.
Functionele testen moesten nog op het niveau van het totale systeem worden
uitgevoerd. Testaanpak, -afspraken, -verantwoordelijkheden en testtooling stonden
op onderdelen nog steeds ter discussie, zoals ook in ons advies is aangegeven. Nietfunctionele testen waren nog niet ontworpen en uitgewerkt. Dus niet alleen wat
het programma ging testen was nog in beweging maar ook hoe ze dat gingen doen.
De gedane testinspanning heeft ook onvoldoende geleid tot het opsporen van
genoeg defecten (zie hieronder). Daarnaast constateerden wij, zoals ook in ons
advies aangegeven, dat de eisenspecificatie van oBRP gebrekkig was en de
traceerbaarheid van deze eisen naar de broncode meestal niet expliciet. Dit leidt
tot een toename van de testinspanning omdat tijdens het testen uitgezocht moet
worden wat de eisen eigenlijk waren (additionele requirements engineering is dan
nodig).
Omdat het belang van het BIT-advies over de BRP groot was, hebben wij niet alleen
op industriegemiddelden vertrouwd. Aanvullend hebben wij daarom uit een andere
primaire bron van het programma oBRP een tweede analyse uitgevoerd. Op basis
van de door het programma beschikbaar gestelde defectenadministratie is een
softwarebetrouwbaarheidsgroeimodel opgesteld volgens het Handbook of
Software Reliability Engineering (Michael R. Lyu, editor, 1996, McGraw-Hill). Dit
model biedt inzicht in de duur van een project door een analyse van het aantal
defecten over de tijd. Dit kent een bepaald patroon: in het begin veroorzaak je
Pagina 3 van 4

Bureau ICT-toetsing
Datum
18 mei 2018

meer problemen dan je oplost en aan het eind los je meer problemen op dan je
veroorzaakt. Het cumulatieve aantal defecten over de tijd wordt dan een Scurve. Als de curve afvlakt (na het zogeheten inflectiepunt) begint het eind van het
project te naderen, en als de curve bijna horizontaal loopt, is het voldoende
betrouwbaar om in productie te gaan. Het model voorspelt dus wanneer het af is,
en met welke betrouwbaarheid. Het gemaakte model is gebaseerd op meer dan
tienduizend datapunten van het project zelf en voorspelde dat pas na 5 jaar de Scurve voldoende horizontaal ging lopen. Deze berekening leidde daarmee dus tot
een nog langere doorlooptijd dan de doorlooptijd die wij afleidden op basis van de
33% voor het resterende testwerk. Van deze tweede analyse is ook, zij het kort,
melding gemaakt in het BIT-advies.

Kenmerk

Medewerkers van het programma 0BRP gaven aan dat de productiviteit van de
softwareontwikkeling recent was toegenomen. Wij hebben om dit te verifiëren een
derde analyse uitgevoerd op een andere primaire bron, die weer geheel
onafhankelijk is van de eerdere bronnen. De geautomatiseerd bijgehouden
versiebeheeradministratie houdt meerjarig tot op de seconde nauwkeurig bij wie,
wat, wanneer, aan welk bestand iets veranderd heeft, en waarom. Voor broncode
bestanden is ook te zien hoeveel veranderd is in termen van regels code. Daarmee
is onder andere de exacte groei (en snoei) van de Java code van eind 2011 tot en
met 2017 in kaart gebracht. Daarmee kan de productiviteit in termen van
geproduceerde regels Java code worden onderzocht. Het BIT heeft die berekend
door voor elke dag vanaf 13 december 2011, tot en met de laatste dag van meten
(21 maart 2017) de som van het aantal netto regels geproduceerde Java code tot
die dag te delen door het aantal verstreken dagen. Bij dit project beweegt de
gemiddelde dagelijkse netto code productiviteit zich in 75% van de berekende
waardes tussen de 311 en de 576 regels Java code per dag, en dat is ook in de
laatste fase zo gebleven, Op basis van deze metingen leek niet houdbaar dat er
sprake was van de geclaimde productiviteitsverbetering. Het BIT heeft derhalve
met gelijk gebleven productiviteit gerekend.

Pagina 4 van 4