Een percentage ‘af’ hangen aan software in ontwikkeling zegt helemaal niets. Dit is de discussie-stelling die Computable-lezers vandaag krijgen voorgelegd.
Minister Plasterk beëindigt het omstreden en fors uitgelopen BRP-project (Basisregistratie Personen). Hij wil uitleg van it-onderzoeksbureau Gartner dat in 2013 nog positief wist te melden dat de software voor dit megaproject voor 32 procent af was. Het it-controlerende overheidsorgaan BIT (Bureau ICT Toetsing) stelt echter dat het al zeven jaar in ontwikkeling zijnde BRP niet haalbaar is en heeft stopzetting geadviseerd.
De verantwoordelijke (nu demissionaire) minister volgt dit advies, maar krijgt daarbij kritische vragen van de Kamercommissie. Hoe kan het dat externe adviesbureaus (KPMG, PBLQ, Gartner, Capgemini) de afgelopen jaren andere conclusies hebben getrokken dan het vernietigende oordeel van BIT nu? Zoals dus de Gartner-rapportage in 2013 dat de software voor 32 procent af was. Probleem is echter dat zo’n percentage – of het nu een schatting is of niet – weinig tot niets zegt. Wélk percentage is af? Het is geen huis waarbij het dan wel over het fundament moet gaan, en eventueel de muren. Eerder is al een BRP-skelettransplantie in gang gezet. Een ‘percentage af’ zegt dus niets voor software. Wat vind jij?
voor 48 procent mee eens met de stelling.
Als de software-ontwikkeling zo wordt opgezet dat er snel bruikbare resultaten worden neergezet, dan kun je op basis van de behaalde hoeveelheid functionaliteit een schatting geven hoeveel procent van het geheel af is. Dat is het idee achter agile werken.
Op basis van functiepuntenanalyses en inschattingen van benodigde lines of code per functiepunt voor een bepaalde technologie kun je ook een gooi doen zonder dat er al iets af is. Dat kan, maar geeft grotere onzekerheid omdat pas bij gebruik blijkt of wat is opgeleverd ook werkelijk iets bijdraagt voor de gebruiker. Dat is de ouderwetse en hopelijk steeds iets meer achterhaalde manier van werken.
Methode 2 zal gebruikt zijn, en dat stemt droef.
Dat klopt als het een moving target is, wat deels haast zo moet zijn anders kan het niet zijn dat het na 10 jaar plus niet af is.
Ook is het niet duidelijk 32 % waarvan ? Functiepunten ? Aantal modules ? Etc. Etc.
En wat is de definitie van af ? Code complete ? Getest ? Geaacpteerd ? Of in productie ?
Af in de meeste ruime zin van het woord lijkt me werkende software in productie. Dan was er 0 procent af.
Het percentage van de code die voor 32% af is betekend dat het totale project voor >86% af is…tenminste, wanneer je ervan uitgaat dat alles wat relevant is voor je gaat coderen gedaan is (80% van een project)…
Een andere benadering is de schatting van de nog benodigde tijd. Daarbij is het opmerkelijk dat de tijd voor de laatste 20% van een project meestal “5x zo langzaam gaat” als voor de eerste 50%. (Helaas is de tijd een constante en dus treed er een tijd/capaciteitsoverschrijding op).
De remedie is relatief eenvoudig: zet eerst met alle (ook de gebruikers!) de operationele functies van het te automatiseren proces op. Doe daarna alle procedurele, administratieve, financiële en andere minder belangrijke zaken…
(Voor wie het nog eens wil bekijken: https://www.computable.nl/artikel/opinie/overheid/2998823/1509029/architecten-terug-naar-de-blokkendoos.html)
Het percentage van de code die voor 32% af is betekend dat het totale project voor >86% af is…tenminste, wanneer je ervan uitgaat dat alles wat relevant is voor je gaat coderen gedaan is (80% van een project)…
Een andere benadering is de schatting van de nog benodigde tijd. Daarbij is het opmerkelijk dat de tijd voor de laatste 20% van een project meestal “5x zo langzaam gaat” als voor de eerste 50%. (Helaas is de tijd een constante en dus treed er een tijd/capaciteitsoverschrijding op).
De remedie is relatief eenvoudig: zet eerst met alle (ook de gebruikers!) de operationele functies van het te automatiseren proces op. Doe daarna alle procedurele, administratieve, financiële en andere minder belangrijke zaken…
(Voor wie het nog eens wil bekijken: https://www.computable.nl/artikel/opinie/overheid/2998823/1509029/architecten-terug-naar-de-blokkendoos.html)
Het rapport van Gartner is gewoon te googlen en is kort gezegd nogal een matig stukje proza. De schrijver heeft duidelijk geen kennis van techniek en is kennelijk afgegaan op wat mensen vertelden zonder afdoende verificatie. Als overheden afgaan op wat organisatiedeskundigen vinden van een ICT project….
@jeroenrl : als ik een auto agile bouw, en de functionaliteit “sturen” is af, heb ik misschien wel 32% auto af, maar nog steeds geen bruikbare auto ….
Je weet dan misschien wel welk deel er af is, maar als je het grote geheel niet kent weet je niet of je iets aan die 32% gaat hebben of niet
@PA VA KE: Dankjewel. Je geeft goed aan waar de definitie van ‘bruikbaar’ aan moet voldoen: een geheel van kop tot staart.
Om bij de auto te blijven: je kunt een plat karretje met wielen en een stuur maken, dan de wielen aan gaan drijven met een motor, daarna zorgen dat de passagiers droog zitten, dan stuurbekrachtiging toevoegen, dan zorgen voor een goede manier van het vervoeren van bagage, en uiteindelijk nog eens nadenken over een navigatiesysteem.
‘Bruikbaar’ voor een gebruiker zal zeker niet één volledig ingerichte functie zijn (denk hier aan sturen inclusief stuurbekrachtiging), maar wel degelijk een redelijk te schatten percentage van het geheel.