In de maakindustrie is product lifecycle management (plm) vanzelfsprekend en het hierbij horende configuratie management essentieel. Een plm-systeem bevat alle onderdelen en de samenhang hiertussen, voor bijvoorbeeld een te bouwen vliegtuig of auto. Zonder deze productinformatie backbone is productie en onderhoud niet mogelijk.
Zonder goed werkende plm-processen en -systemen is het onmogelijk om te herleiden welk van de duizenden componenten gebruikt moet worden bij onderhoud of reparatie. De monteur moet weten welke vervangende onderdelen hij moet gebruiken bij een bepaald type auto of vliegtuig en waar dit onderdeel relaties mee heeft. Daarom heeft bijvoorbeeld iedere auto een uniek serienummer, waarbij een lijst met voorgeschreven onderdelen hoort. Het is ondenkbaar, zelf onmogelijk, complexe producten zoals auto’s en vliegtuigen zonder de inzet van plm te maken en te onderhouden. Herleidbaarheid is hier het keyword.
Het ontwikkelen van grote it-systemen is een complexe aangelegenheid. In plaats van duizenden fysieke onderdelen worden honderdduizenden of miljoenen regels programmacode geschreven die gezamenlijk het product, het it-systeem vormen. Deze regels code moeten weer, via ontwerpen, terug te herleiden zijn naar de oorspronkelijke eisen. Het in de greep krijgen en houden hiervan op basis van de inzet van plm zou een vanzelfsprekendheid moeten zijn, maar is dat vandaag de dag nog steeds niet. Dit terwijl de complexiteit niet onder doet voor die van de maakindustrie en de maatschappelijke gevolgen van het niet herleiden verder toenemen. Bijvoorbeeld de Toyota Prius die stopt door software fouten, Pinautomaten die niet werken en medische apparatuur die op hol slaat.
Een belangrijk aspect van de productkwaliteit van applicaties is wederom herleidbaarheid of tracebility. Het gaat bij deze herleidbaarheid om het vermogen gerelateerde onderdelen in documentatie en software, zoals functionele en technische eisen, ontwerpen, broncode, documentatie en tests, te identificeren, aan elkaar te relateren en de wijzigingen ervan bij te houden. Bijvoorbeeld; per testsoort moeten de eisen kunnen worden gekoppeld aan de testdocumentatie, zoals het testplan, de specificatie van testontwerp, het testgeval, de testprocedure of het testscript. Traceerbaarheid vertaalt zich door naar alle aspecten van de ontwikkeling, van de manier waarop eisen opgezet worden, de documentatiestandaarden tot en met de installatiescripts en het release management. Vanaf de start van het software-ontwikkeltraject moet daarom met herleidbaarheid planmatig omgegaan worden.
Laten we leren van de maakindustrie en plm ook bij software ontwikkeling structureel inzetten om betere kwaliteit te bereiken.
Bij de Universiteit Utrecht is een model ontwikkeld voor Software Product Management (zie: http://www.cs.uu.nl/wiki/bin/view/Spm/SpmCompetenceModel).
Dat model omvat 4 hoofdprocessen: portfolio management, product planning, requirement management en release planning. Binnen deze 4 hoofdprocessen vallen dan een aantal van de hierboven genoemde processen.
De combinatie van deze processen maakt de kwaliteit van een product uit, niet de afzonderlijke processen zelf. Hoewel die processen natuurlijk per proces ook goed moeten worden uitgevoerd.
Bij mijn werkgever zijn we nu een aantal jaren bezig met de inrichting van deze processen volgens het genoemde model. Door processen en de uitvoering daarvan beter te documenteren is herleidbaarheid inmiddels geborgd, althans intern. Naar buiten toe hanteren we releasenummering met allerlei aanduidingen voor minor release en patches. Dat is vooralsnog voldoende gebleken voor herleidbaarheid buiten de organisatie.
Nog even ter aanvulling op mijn reactie: zie ook https://www.computable.nl/artikel/nieuws/erp/4687183/1276992/nederlandse-software-staat-centraal-op-congres.html
@Eric: je slaat (wellicht onbedoeld) de spijker op z’n kop
Doordat men CM niet (volledig) gebruikt in software systemen kan men vaak niet meer terug naar een vorige werkende versie.
Als de software in mijn organisatie niet meer werkt (ik zit ook in de maakindustrie, en we maken software volgens dezelfde principes als hardware) kunnen we ten alle tijden terug naar de vorige versie.
Mocht er dus iets omvallen door de software, kunnen we binnen enkele uren terug.
Kijk je naar de grote ICT storingen afgelopen jaren, duurde het in het ergeste geval dagen eer men het probleem opgelost had. Heb je een mechanisme dat je altijd terug kunt naar de vorige versie, kun je de schade in ieder geval beperken door binnen korte tijd weer operationeel te zijn.
Op dat vlak kan de pure softwarewereld denk ik nog wel iets leren van de “maak-industrie”
Door de parallellen van hardware met software te trekken mis je een belangrijke denkstap. Hardware is een fysiek iets en software is een uitgebreid vaak abstract bedenksel.
Bij de software die je op een scherm zet zit nog een of meerdere interpretatieslag(en) overheen en zal een uitvoerende computer hier een eigen interpretatie op loslaten.
Ook is het combineren van software heel anders dan hardware. OO structuren, parallele vs synchrone verwerking en exponentieel aantal mogelijkheden door relatief eenvoudige combinaties.
Wat dat betreft is de software nog relatief jong, blijkt in de praktijk nog zat mankementen te hebben en zal het nog verder moeten evolueren om dichter bij de menselijke realiteit te komen zodat we er op een voor ons meer eenvoudige manier mee kunnen omgaan.