3.7 Softwareonderhoud

Overzicht en motivatie

De meeste software besteedt het overgrote deel van haar leven niet aan gebouwd worden maar aan onderhouden worden. Zodra een systeem in productie gaat, betreedt het een fase (vaak jaren of decennia durend) van defecten herstellen, zich aanpassen aan een veranderende omgeving, verbeteren wat al werkt en toekomstige problemen voorkomen. In grote ondernemingen, en vooral bij de overheid, domineert deze fase. Belastingengines, uitkeringssystemen, defensieplatforms en financiële kerngrootboeken worden routinematig veel langer onderhouden dan iemand die ze opdroeg verwachtte. Softwareonderhoud is de discipline van opgeleverde software correct, actueel en waardevol houden over haar hele operationele leven.

Onderhoud wordt chronisch onderschat en ondergewaardeerd, en die fout is duur. Studie na studie, over decennia, plaatst onderhoud op ruim meer dan de helft van de totale levensduurkosten van software, gewoonlijk aangehaald in een bereik van 60 tot 90 procent voor langlevende systemen. Toch plannen, begroten, bemannen en vieren organisaties de eerste bouw alsof dat de hele onderneming was. Dan behandelen ze alles daarna als een bijgedachte, gefinancierd uit een krimpende pot en toegewezen aan wie beschikbaar is. Het resultaat is voorspelbaar: brosse systemen, gedemoraliseerde onderhouders, oplopende kosten van verandering en uiteindelijk een crisis die wordt geformuleerd als een “legacyprobleem” (hoofdstuk 3.6) terwijl het al die tijd een onbeheerd-onderhoudsprobleem was.

Dit hoofdstuk volgt het kennisgebied Software Maintenance van SWEBOK (Software Engineering Body of Knowledge) en ISO/IEC 14764. Het behandelt de fundamenten van onderhoud en de vier erkende categorieën, de kernkwesties die onderhoud moeilijk maken, inclusief kosten, bezetting en moreel, het onderhoudsproces, de kerntechnieken van programmabegrip, reengineering en refactoring, hoe je onderhoudskosten schat en (het idee met de hoogste hefboom in het hoofdstuk) hoe je vanaf het begin ontwerpt voor onderhoudbaarheid. De centrale overtuiging is dat onderhoud geen mindere activiteit is die na engineering komt. Het is het grootste deel van software engineering, en het moet als zodanig worden gepland, van middelen voorzien en gerespecteerd.

Kernprincipes

Onderhoud is het merendeel van de levenscyclus, geen epiloog. Plan en begroot het vanaf dag één. Het zal meer kosten dan de bouw.
De vier categorieën zijn verschillend werk. Correctief, adaptief, perfectief en preventief onderhoud hebben verschillende drijfveren en ritmes. De meeste inspanning is geen bugfixen.
Je kunt niet wijzigen wat je niet begrijpt. Programmabegrip is de grootste afzonderlijke activiteit in onderhoud. Maak code en haar geschiedenis leesbaar.
Onderhoudbaarheid is een ontwerpeigenschap. De kosten van toekomstige verandering worden grotendeels bepaald door beslissingen tijdens constructie. Ontwerp er bewust voor.
Kleine, veilige, continue verandering verslaat uitgestelde grote verandering. Refactor en moderniseer incrementeel onder een vangnet van tests in plaats van wijzigingsschuld op te hopen.
Software veroudert zelfs als ze stilstaat. De omgeving beweegt (afhankelijkheden, platforms, regelgeving), dus een statisch systeem rot stilletjes. Preventief onderhoud is echt werk.
Onderhouders verdienen eersteklas status. Moreel, kennisbehoud en bezetting van onderhoudsteams bepalen direct de langetermijnkosten en het risico.

Aanbevelingen

Onderscheid de vier categorieën onderhoud en bemand voor alle vier

ISO/IEC 14764 en SWEBOK erkennen vier categorieën, en ze verwarren is een veelvoorkomende planningsfout. Correctief onderhoud herstelt defecten gevonden in bedrijf. Adaptief onderhoud houdt de software werkend terwijl haar omgeving verandert: nieuwe besturingssystemen, browsers, afhankelijkheden, hardware, regelgeving of koppelende systemen. Perfectief onderhoud verbetert de software voor gebruikers en onderhouders, via nieuwe functies, betere prestaties, verbeterde bruikbaarheid en verbeterde onderhoudbaarheid. Preventief onderhoud corrigeert latente gebreken en vermindert toekomstig risico voordat het zich manifesteert, via verharding, opruiming en modernisering van fragiele gebieden. Een nuttige verdere splitsing groepeert correctief en preventief als correctie (omgaan met gebreken) en adaptief en perfectief als verbetering (omgaan met nieuwe vereisten). Cruciaal is dat empirische studies consequent vinden dat het merendeel van onderhoud niet correctief is. Verbetering en aanpassing domineren. Begroot en bemand dienovereenkomstig, en volg in welke categorie je inspanning werkelijk valt zodat je haar kunt beheren.

Investeer in programmabegrip

De grootste afzonderlijke activiteit in onderhoud is het bestaande systeem goed genoeg begrijpen om het veilig te wijzigen. Onderhouders besteden routinematig meer tijd aan het lezen van en redeneren over code dan aan het wijzigen ervan. Maak dit met opzet goedkoper. Houd documentatie dicht bij de code en actueel (hoofdstuk 2.7). Bewaar beslissingsgeschiedenis via besluitenlogboeken (hoofdstuk 1.6) en een schone commitgeschiedenis (hoofdstuk 2.6). Gebruik statische analyse, afhankelijkheidsgrafen en codenavigatietooling om onbekend terrein in kaart te brengen. Karakteriseringstests (tests die het huidige gedrag vastpinnen, inclusief eigenaardigheden) zetten impliciet begrip om in uitvoerbare, duurzame kennis. Wanneer begrip duur is, is elke wijziging traag en riskant. Wanneer het goedkoop is, wordt onderhoud routine.

Refactor continu onder een vangnet van tests

Refactoring is gedisciplineerd herstructureren van code dat haar interne kwaliteit verbetert zonder haar extern gedrag te veranderen. Continu en in kleine stappen gedaan, werkt het de natuurlijke afdrijving naar complexiteit tegen en houdt het de kosten van verandering vlak in plaats van stijgend. De niet-onderhandelbare voorwaarde is een betrouwbare geautomatiseerde testsuite (hoofdstuk 2.4). Zonder haar is “refactoring” slechts riskant herschrijven. Vouw refactoring in het dagelijkse werk: laat elke module iets schoner achter dan je haar aantrof, in plaats van het te bewaren voor zeldzame, grote, gevaarlijke opruimingen. Dit is preventief onderhoud in de praktijk, en het is het goedkoopste onderhoud dat er is.

Reengineer wanneer incrementele verandering niet meer genoeg is

Wanneer een component zo is verslechterd dat routineverandering te duur of te riskant is, is reengineering (een systeem onderzoeken en wijzigen om het in een nieuwe vorm te herstellen) het zwaardere gereedschap. Reengineering combineert doorgaans reverse engineering (ontwerp en bedoeling uit de implementatie terugwinnen) met voorwaartse reengineering (herbouwen naar een betere structuur terwijl gedrag behouden blijft). Geef er de voorkeur aan te reengineeren in begrensde, incrementele plakken met patronen als wurgvijg en branch by abstraction (hoofdstuk 3.6), in plaats van als algehele herschrijving. Reengineering zit op het continuüm van onderhoud naar modernisering: refactoring voor het kleine en lokale, reengineering voor het structurele en modernisering voor het platformniveau.

Voer een gedefinieerd onderhoudsproces uit

Onderhoud profiteert van een expliciet, herhaalbaar proces, zoals beschreven in ISO/IEC 14764: procesimplementatie (plannen en procedures vaststellen), probleem- en wijzigingsanalyse (triage, reproduceren, impact en kosten beoordelen), wijzigingsimplementatie, onderhoudsreview en -acceptatie, migratie en uitfasering. Wikkel het in gedisciplineerd wijzigingsbeheer: elk onderhoudsverzoek (of het nu een defectmelding of een verbetering is) moet worden vastgelegd, geclassificeerd naar categorie, beoordeeld op impact, geprioriteerd, geïmplementeerd onder versiebeheer met tests, beoordeeld en opgeleverd via de normale pipeline (hoofdstuk 11.2). Impactanalyse, begrijpen wat een voorgestelde wijziging allemaal kan raken, is centraal en verdient echte inspanning. Uitfasering is ook onderdeel van het proces: een systeem veilig ontmantelen, zijn data en gebruikers migreren en records bewaren is onderhoudswerk dat moet worden gepland, niet geïmproviseerd.

Schat onderhoudskosten expliciet en financier ze

Behandel onderhoud niet als gratis, of als ruis in het bouwbudget. Schat het. Gangbare aanpakken omvatten onderhoudsinspanningsverhoudingen (de veelgebruikte vuistregel dat jaarlijks onderhoud grofweg 15 tot 25 procent van de oorspronkelijke ontwikkelkosten bedraagt, hoewel langlevende kritieke systemen over hun leven veel meer opbouwen), parametrische modellen zoals COCOMO II (het Constructive Cost Model) met zijn onderhouds- en hergebruiksuitbreidingen, en op statistieken gebaseerde voorspelling uit je eigen historische data over defectpercentages, wijzigingsvolume en wijzigingskosten. Voed deze schattingen in total-cost-of-ownership-analyse en de economie besproken in hoofdstuk 10.10. De aankoopprijs of bouwkosten van een systeem zijn een aanbetaling. De hypotheek is onderhoud, en ze hoort in elke zakelijke onderbouwing te staan.

Ontwerp vanaf het begin voor onderhoudbaarheid

De meeste hefboom over onderhoudskosten wordt uitgeoefend voordat het onderhoud begint. Onderhoudbaarheid (analyseerbaarheid, wijzigbaarheid, testbaarheid en modulariteit, in het vocabulaire van ISO/IEC 25010) is een ontwerpkwaliteit die een expliciete vereiste moet zijn, geen gelukkig toeval. Geef de voorkeur aan modulaire, los gekoppelde ontwerpen met hoge samenhang (hoofdstuk 2.2), heldere interfaces en scheiding van verantwoordelijkheden, sterke geautomatiseerde tests, leesbare code en actuele documentatie, en rijke observeerbaarheid zodat operators en onderhouders kunnen zien wat het systeem doet (deel 9). Elk van deze beslissingen ruilt nu wat meer inspanning in voor grote, stapelende besparingen over de decennia die een systeem werkelijk zal leven. Bouwen voor onderhoudbaarheid is de investering met het hoogste rendement in de hele levenscyclus.

Afwegingen: voor- en nadelen

Aanpak	Voordelen	Nadelen
Continu refactoren / preventief onderhoud	Houdt kosten van verandering vlak, vermindert risico, hoge ROI	Doorlopende inspanning zonder zichtbare nieuwe functies. Vraagt sterke tests
Onderhoud uitstellen (“het licht aanhouden”)	Goedkoopst dit kwartaal. Maakt capaciteit vrij voor functies	Wijzigingsschuld stapelt zich op. Uiteindelijke crisis en afgedwongen dure actie
Een verslechterd component reengineeren	Herstelt onderhoudbaarheid en verlengt nuttige levensduur	Aanzienlijke inspanning en risico. Gedrag moet zorgvuldig behouden blijven
Vooraf ontwerpen voor onderhoudbaarheid	Stapelende levensduurbesparingen. Elke toekomstige wijziging makkelijker	Hogere initiële kosten en discipline. Voordelen zijn uitgesteld en minder zichtbaar

De terugkerende afweging in onderhoud is huidige kosten tegenover toekomstige kosten, en de verleiding gaat altijd naar uitstel. Refactoring overslaan, afhankelijkheden laten verouderen en het onderhoudsteam uithongeren lijken allemaal gratis dit kwartaal, omdat de rekening later komt: als een trager, riskanter, duurder systeem, en uiteindelijk als een “legacycrisis”. De discipline van goed onderhoud is nu kleine, continue, zichtbare kosten te betalen om grote, plotselinge, loopbaanbepalende kosten later te vermijden. Omdat de besparingen uitgesteld en onzichtbaar zijn, vraagt deze ruil leiderschap dat levenscycluseconomie begrijpt, niet alleen lanceerdata.

Vragen om met je team te bespreken

Wie bezit het onderhoudsgetal in je budget, en is het een eersteklas regel of een residu geschraapt van wat de bouw niet uitgaf? Onderhoud is het merendeel van de levensduurkosten, gewoonlijk 60 tot 90 procent voor langlevende systemen, en toch wordt het routinematig als bijgedachte gefinancierd en bemand met wie vrij is. Wanneer het budget een residu is, is preventief werk het eerste dat wordt geschrapt, stapelt wijzigingsschuld zich op en volgt een voorspelbare glijbaan naar een “legacycrisis”. Neem een echte schatting mee (een onderhoudsinspanningsverhouding, een parametrisch model of je eigen historische data over wijzigingskosten) en noem de persoon die verantwoordelijk is voor het financieren ervan over de levensduur van het systeem. De oplossing is onderhoud expliciet te begroten in elke zakelijke onderbouwing, zoals een hypotheek naast een aankoopprijs staat. Leiderschap dat alleen lanceringen viert zal de fase blijven onderfinancieren waar het meeste geld en risico werkelijk leeft.
Reserveer je capaciteit voor preventief onderhoud, of verliest het altijd van de volgende functie? Preventief werk (refactoren onder een vangnet van tests, afhankelijkheden actueel houden, fragiele gebieden verharden) is het goedkoopste onderhoud dat er is, omdat het de curve van wijzigingskosten vlak houdt in plaats van haar te laten klimmen. Het is ook het makkelijkst uit te stellen, aangezien overslaan dit kwartaal gratis lijkt en de rekening later komt als een trager, riskanter systeem. Een concreet mechanisme helpt: een vaste toewijzing, en veel sterke teams beschermen grofweg een vijfde van de capaciteit, die wordt bewaakt in plaats van elke sprint weggeonderhandeld. Neem je trend in wijzigingskosten mee als bewijs. Als die stijgt, onderinvesteer je al. De discipline is nu kleine, zichtbare kosten te betalen om grote, plotselinge, loopbaanbepalende kosten later te vermijden, en dat vraagt leiderschap dat levenscycluseconomie leest in plaats van lanceerdata.
Wat is je plan om een systeem uit te faseren, en wanneer heb je er voor het laatst daadwerkelijk een ontmanteld? Uitfasering is een expliciet onderdeel van het onderhoudsproces (datamigratie, gebruikersoverschakeling, records bewaren, veilig afsluiten), maar organisaties dragen jarenlang dode en redundante systemen mee omdat ontmantelen onglamoureus en onbegroot is. Elk zombiesysteem verbruikt nog licenties, beveiligingspatching, integratieoppervlak en de aandacht van mensen die elders kunnen zijn. Neem een inventaris mee en markeer systemen zonder actieve gebruikers of met een volledige vervanging al live, en plan hun afsluiting dan zoals elk ander werk: migreer data, bewaar wat de wet vereist en bevestig dat niets er nog van afhangt. Vooral bij de overheid geeft wetgeving over bewaartermijnen van archieven vorm aan hoe je uitfaseert, dus betrek compliance vroeg. Een volwassenheidssignaal om te volgen: wanneer heeft je organisatie voor het laatst bewust iets uitgezet?
Hoeveel van elke wijziging gaat op aan het systeem begrijpen voordat je het aanraakt, en wat is je busfactor op de systemen die het meest tellen? Programmabegrip is de grootste afzonderlijke activiteit in onderhoud, en zijn kosten worden bepaald door hoe leesbaar je de code, haar geschiedenis en haar gedrag hebt gehouden. Wanneer begrip alleen in een paar hoofden van langdurig dienstverband leeft, verhoogt elk vertrek of pensioen de prijs van elke toekomstige wijziging en kan één afwezigheid een kritieke fix stilleggen. Neem bewijs mee: de verhouding tussen lees-en-redeneertijd en bewerktijd bij recente wijzigingen, het aantal mensen dat elke kernmodule veilig kan wijzigen en of bedrijfsregels en beslissingen naast de code zijn gedocumenteerd of elke keer uit het geheugen worden gereconstrueerd. De concurrerende overweging is dat documentatie en karakteriseringstests nu inspanning kosten voor besparingen die pas later zichtbaar worden, dus ze zijn makkelijk over te slaan. In onderneming en overheid, waar systemen hun oorspronkelijke auteurs met decennia overleven en wettelijke regels begraven liggen in een berekeningsengine die niemand volledig onthoudt, behandel je vastgelegd begrip (besluitenlogboeken, karakteriseringstests, actuele documentatie) als bezit dat je bewust financiert, niet als beleefdheid die gebeurt wanneer iemand tijd over heeft.
Wie bemant je onderhoudswerk werkelijk, en komen zijn status en moreel overeen met zijn belang? Onderhoud is het merendeel van de levensduurkosten en de moeilijkste engineering die er is, veilig systemen wijzigen die je niet bouwde en misschien niet volledig begrijpt, maar het wordt routinematig aan de minst ervaren mensen gegeven en geformuleerd als laagstatus “het licht aanhouden”. Dat signaal is corrosief: je beste engineers mijden het werk, kennis concentreert zich en loopt dan de deur uit, en de kosten van verandering stijgen terwijl niemand kijkt. Neem het senioriteitsprofiel mee van wie je langstlevende systemen onderhoudt, je gegevens over verloop en kennisbehoud en een eerlijke lezing of onderhoud in je organisatie een doodlopende loopbaan is of een gerespecteerd specialisme. De spanning is echt, aangezien ambitieuze engineers nieuwe dingen willen bouwen en leiders lanceringen willen vieren, dus onderhoud respecteren vraagt bewuste structuur. Voor een grote onderneming of publiek orgaan dat systemen draait die decennialang regelgevend en financieel risico dragen, is onderhoud bemannen met gerespecteerde senior engineers een risicobeheerbeslissing, en onderhoud een strafplaatsing laten worden is hoe je de volgende legacycrisis fabriceert.
Volg je in welke van de vier categorieën je inspanning werkelijk valt, en meet je de kosten van verandering als voorlopende indicator? Teams plannen onderhoud routinematig alsof het vooral bugfixen is, terwijl empirische studies tonen dat verbetering en aanpassing domineren, dus een portfolio dat alleen voor correctief werk is gefinancierd is vanaf het begin verkeerd afgebakend. Zonder categorievolging kun je niet zien dat een systeem wordt hervormd door een gestage stroom regelgevende aanpassingen, en zonder maat voor wijzigingskosten (doorlooptijd van wijzigingen, faalpercentage van wijzigingen, complexiteitstrends) kun je niet zien of je curve vlak is of stilletjes naar een crisis klimt. Neem je werkelijke categorieverdeling van het afgelopen jaar mee, je trend in wijzigingskosten als je er een hebt en een eerlijke notitie of impactanalyse een echte stap is of een formaliteit die onder deadlinedruk wordt overgeslagen. De concurrerende trek is dat meten zelf inspanning kost en als overhead kan voelen wanneer het systeem nog werkt. In portfolio’s van onderneming en overheid, waar veel teams veel systemen onderhouden en een stijgende kostencurve op een ervan een vroege waarschuwing is die het waard is op te handelen, laten gedeelde categorievolging en indicatoren voor wijzigingskosten het leiderschap een module reengineeren voordat ze verslechtert in plaats van nadat ze publiekelijk faalt.

Sectorperspectief

Startup. Met een handvol engineers en weinig runway kun je je geen zwaar onderhoudsproces veroorloven, maar ook geen codebase die niemand wil aanraken. Reserveer een kleine vaste plak van elke cyclus (grofweg een dag op vijf) voor preventief werk: patch afhankelijkheden, ruim kleine defecten op voordat ze zich opstapelen en refactor de hoeken waar je al tegenop ziet onder welke tests je ook hebt. Het doel is de code goedkoop te wijzigen te houden terwijl je pivoteert, zodat je nooit bij twintig engineers wakker wordt en uitgesteld onderhoud aanziet voor een “legacyprobleem”.

Kleinbedrijf. Zonder aparte onderhoudsspecialist en met een krap budget neig je naar kopen en hosten boven bouwen, zodat adaptief onderhoud (beveiligingspatches, platform- en afhankelijkheidsupdates) grotendeels de taak van iemand anders is. Waar je wel code bezit, houd haar klein, saai en goed gedocumenteerd, en zorg dat minstens twee mensen alles begrijpen waarvan het bedrijf afhangt. Volg de handvol systemen die je je niet kunt veroorloven te verliezen en begroot een bescheiden, expliciete regel om ze actueel te houden in plaats van te doen alsof onderhoud gratis is.

Grote onderneming. Op schaal onderhoud je veel langlevende systemen over veel teams, dus de prioriteit is een gedefinieerd, herhaalbaar proces: een gelogde en getrieerde verzoekpipeline, classificatie in de vier categorieën, routinematige impactanalyse en een vaste preventieve toewijzing die wordt bewaakt in plaats van weggeonderhandeld. Financier onderhoud als eersteklas programma, meet indicatoren voor wijzigingskosten over het portfolio en gebruik een stijgende curve als trigger om een module te reengineeren voordat ze een verplichting wordt. Governance- en auditverwachtingen betekenen dat categorievolging en wijzigingsregisters geen overhead zijn, maar het bewijs dat het landschap onder controle is.

Overheid. Aanbestedingsregels, transparantie en publieke verantwoording geven onderhoud net zoveel vorm als engineering. Adaptief onderhoud gedreven door wetgeving komt op harde jaarlijkse deadlines die niet kunnen schuiven, dus begroot onderhoud als onbepaalde operationele kost en bemand een stabiel deskundig team om kennis van regels te behouden waarvan de auteurs al lang met pensioen zijn. Uitfasering wordt beperkt door wetgeving over bewaartermijnen van archieven, dus plan ontmanteling vanaf het begin met compliance en geef de voorkeur aan contracten en architecturen die het systeem onderhoudbaar en overdraagbaar houden in plaats van je decennialang aan één leverancier te binden.

Voorbeelden

Startup. Een startup die zojuist zijn MVP oplevert is in de verleiding elk uur in nieuwe functies te steken, maar de oprichtende engineer reserveert vanaf de allereerste maand een vaste plak van elke sprint (grofweg een dag op vijf) voor onderhoud. Dat budget houdt afhankelijkheden gepatcht, ruimt kleine defecten op voordat ze zich opstapelen en refactort de hoeken waar het team al tegenop ziet, zodat de codebase goedkoop te wijzigen blijft terwijl het product pivoteert. De startups die dit overslaan bereiken twintig engineers met een codebase die niemand wil aanraken en nemen het aan voor een “legacyprobleem” terwijl het al die tijd uitgesteld onderhoud was.

Grote onderneming. Een wereldwijde bank draait een betalingsplatform dat vijftien jaar in productie is. Ze financiert onderhoud als permanent, eersteklas programma in plaats van een residuele budgetregel. Werk wordt getrieerd in de vier categorieën: een gestage stroom adaptieve wijzigingen volgt nieuwe regelgeving en interfaceupdates van partnerbanken, perfectief werk voegt functies toe en verbetert doorvoer, correctief werk ruimt defecten op tegen strikte service-level agreements (SLA’s) en een vaste preventieve toewijzing (grofweg een vijfde van de teamcapaciteit) lost complexiteit af door continu refactoren onder een uitgebreide testsuite. Het team meet doorlooptijd van wijzigingen en faalpercentage van wijzigingen, en behandelt stijgende wijzigingskosten als vroege waarschuwing om een module te reengineeren voordat ze een verplichting wordt. Onderhouders zijn senior, gerespecteerde engineers, geen junioren geparkeerd op “het licht aanhouden”.

Overheid. Een nationale belastingdienst onderhoudt een systeem dat al ruim dertig jaar draait en elk jaar wordt aangepast naarmate de belastingwet verandert. De dominante categorie hier is adaptief onderhoud gedreven door wetgeving, met harde jaarlijkse deadlines die niet kunnen schuiven. De dienst investeert zwaar in programmabegrip: bedrijfsregels worden naast de code gedocumenteerd, karakteriseringstests pinnen het gedrag vast van regels waarvan de oorspronkelijke auteurs allang met pensioen zijn en impactanalyse is een formele stap voor elke wijziging aan de berekeningsengine. Omdat de omgeving (de wet) continu verandert, kan het systeem nooit “af” zijn, dus begroot de dienst onderhoud als onbepaalde operationele kost, bemant ze een stabiel deskundig team om kennis te behouden en moderniseert ze de omringende leveringspraktijken zoals broncodebeheer, continuous integration (CI) en geautomatiseerd testen, zelfs terwijl de kern voortduurt.

Zakelijke onderbouwing: motivatie, ROI en TCO

Het kernfeit van software voor het bedrijf is dat onderhoud, niet constructie, is waar het geld heen gaat. Over de industrie en over decennia van onderzoek is onderhoud goed voor het duidelijke merendeel van de levensduurkosten, vaak aangehaald op 60 tot 90 procent voor systemen die lang leven, wat in onderneming en overheid de meeste zijn. Elke total-cost-of-ownership-analyse die bij go-live stopt zit er een factor meerdere naast. De primaire zakelijke onderbouwing om onderhoud serieus te nemen is simpelweg nauwkeurigheid: begroot voor het hele leven van het systeem, of word herhaaldelijk verrast door de rekening.

Het rendement komt uit het buigen van de kostencurve. In een verwaarloosd systeem stijgen de kosten van elke wijziging in de tijd naarmate complexiteit zich ophoopt en begrip vervalt, tot verandering onbetaalbaar traag en riskant wordt. In een goed onderhouden systeem houdt continu preventief werk (refactoren, actuele afhankelijkheden, testdekking, documentatie) die curve vlak, zodat de duizendste wijziging ongeveer kost wat de tiende deed. Investeren in onderhoudbaarheid en preventief onderhoud is dus geen kost om te minimaliseren. Het is de hefboom die bepaalt of een systeem betaalbaar te wijzigen blijft of afdrijft naar de oplopende kosten en het risico van een legacylandschap (hoofdstuk 3.6) en de blijvende uitdagingen van hoofdstuk 10.4. Financier onderhoud bewust, meet de kosten van verandering als voorlopende indicator en behandel een stijgende curve als signaal om te handelen, niet als natuurwet. De economie wordt verder behandeld in hoofdstuk 10.10.

Antipatronen en valkuilen

Onderhoud als bijgedachte behandelen. Alleen de bouw begroten en vieren, en de veel grotere en langere onderhoudsfase uithongeren.
Onderhoud bemannen met de minst ervaren mensen. Het moeilijkste werk (veilig systemen wijzigen die je niet volledig begrijpt) toewijzen aan wie er het minst voor is toegerust, en signaleren dat onderhoud laagstatus is.
Onderhoud verwarren met bugfixen. Alleen plannen voor correctief werk terwijl aanpassing en verbetering de inspanning werkelijk domineren.
Preventief onderhoud eindeloos uitstellen. Nooit refactoren, nooit afhankelijkheden bijwerken, tot wijzigingsschuld een dure crisis afdwingt.
Code wijzigen zonder impactanalyse. Een “kleine fix” maken die uitwaaiert in onvoorziene falen elders.
Refactoren zonder vangnet van tests. Code herstructureren zonder manier om te bewijzen dat gedrag behouden bleef: dat is gewoon riskant herschrijven.
Kennis de deur uit laten lopen. Bedrijfsregels en beslissingen niet documenteren, zodat elk pensioen of vertrek de kosten van elke toekomstige wijziging verhoogt.
Nooit iets uitfaseren. Dode en redundante systemen eeuwig meedragen omdat ontmantelen onglamoureus en ongepland is.

Volwassenheidsmodel

Niveau 1: Initiëren. Onderhoud is ongepland en ongefinancierd, reactief afgehandeld door wie vrij is. Het wordt gezien als bugfixen en als laagstatus werk. Er is geen categorievolging, geen kostenschatting en kennis leeft in een paar hoofden. De kosten van verandering stijgen ongemerkt tot een fix stagneert of een crisis aandacht afdwingt.
Niveau 2: Ontwikkelen. Sommige teams zijn begonnen onderhoudsverzoeken te loggen en te trieren en een budgetregel te dragen, maar de praktijk is inconsistent over de organisatie en het budget is meestal een residu. Correctief werk wordt gevolgd terwijl adaptieve en perfectieve inspanning niet duidelijk onderscheiden wordt. Wat tests en documentatie bestaan in zakken, dus verandering is deels beheerst maar begrip blijft duur en ongelijk van team tot team.
Niveau 3: Standaardiseren. Een gedefinieerd onderhoudsproces (volgens ISO/IEC 14764) is gedocumenteerd en organisatiebreed gehandhaafd: werk wordt geclassificeerd in de vier categorieën, impactanalyse en wijzigingsbeheer zijn routine en onderhoud wordt geschat en expliciet gefinancierd in elke zakelijke onderbouwing. Preventief onderhoud en refactoring zijn standaardpraktijk onder een solide testsuite, en onderhoudbaarheid (analyseerbaarheid, wijzigbaarheid, testbaarheid, modulariteit) is een expliciete ontwerpvereiste in plaats van een lokale gewoonte.
Niveau 4: Beheersen. Onderhoud wordt gemeten en gestuurd met data aan de hand van uitgangswaarden. Indicatoren voor wijzigingskosten (doorlooptijd van wijzigingen, faalpercentage van wijzigingen, complexiteits- en defecttrends) worden per systeem gevolgd, de inspanningsmix over de vier categorieën wordt gekwantificeerd tegen verwachtingen en onderhoudsinspanningsverhoudingen en parametrische schattingen worden gecontroleerd tegen werkelijke historische wijzigingskosten. Een stijgende kostencurve wordt gedetecteerd als voorlopende indicator en triggert actie, en preventieve toewijzing wordt op bewijs gedimensioneerd in plaats van gegokt. Beslissingen om te refactoren, reengineeren of uit te faseren worden op gemeten drempels genomen, niet op intuïtie.
Niveau 5: Orkestreren. Onderhoud wordt continu verbeterd en is geïntegreerd over de organisatie en haar levenscycluseconomie. Levenscyclus-TCO stuurt portfolio-investering, reengineering wordt bewust toegepast voordat componenten verslechteren, kennis wordt actief behouden en uitfasering wordt gepland en routinematig uitgevoerd. De organisatie herbalanceert onderhoudsinspanning naarmate de omgeving verschuift (regelgeving, platforms, afhankelijkheden), onderhouders zijn gerespecteerde senior engineers en het hele landschap past zich aan zodat de kosten van verandering vlak blijven over systemen die decennialang leven.

Ideeën voor discussie

Welk deel van je engineeringinspanning gaat werkelijk naar onderhoud, en weerspiegelen je budget en bezetting die werkelijkheid?
Kun je je onderhoudswerk opsplitsen in de vier categorieën, en komt de mix overeen met je aannames?
Hoeveel van een typische wijziging gaat op aan het systeem begrijpen tegenover wijzigen, en wat zou begrip goedkoper maken?
Stijgen, blijven vlak of dalen je kosten van verandering in de tijd, en meet je ze überhaupt?
Hebben je teams een betrouwbaar vangnet van tests dat continu refactoren veilig maakt, of is herstructureren te riskant om te proberen?
Wie onderhoudt je langstlevende systemen, hoe wordt hun kennis vastgelegd en wat is de status en het moreel van dat werk?

Belangrijkste inzichten

Onderhoud is het merendeel van de levensduurkosten van software (gewoonlijk 60 tot 90 procent voor langlevende systemen) en moet worden gepland, begroot en bemand als eersteklas activiteit.
De vier categorieën (correctief, adaptief, perfectief, preventief) zijn verschillend werk, en verbetering en aanpassing, niet bugfixen, domineren meestal.
Programmabegrip is de grootste afzonderlijke onderhoudsactiviteit. Maak code, geschiedenis en gedrag leesbaar om elke wijziging goedkoop te houden.
Refactor continu onder een vangnet van tests en reengineer verslechterde componenten incrementeel om de kosten van verandering vlak te houden.
Schat onderhoudskosten expliciet en voed ze in total-cost-of-ownership- en economische beslissingen.
Ontwerp vanaf het begin voor onderhoudbaarheid (het is de investering met het hoogste rendement in de hele levenscyclus) en behandel onderhouders als de senior professionals die ze moeten zijn.

Referenties en verder lezen

IEEE Computer Society, SWEBOK Guide (Software Engineering Body of Knowledge), Software Maintenance knowledge area
ISO/IEC 14764 / IEEE 14764, Software Engineering: Software Life Cycle Processes, Maintenance
ISO/IEC 25010, Systems and software Quality Requirements and Evaluation (SQuaRE): maintainability quality characteristics
Martin Fowler, Refactoring: Improving the Design of Existing Code
Michael Feathers, Working Effectively with Legacy Code
Thomas M. Pigoski, Practical Software Maintenance
Penny Grubb and Armstrong A. Takang, Software Maintenance: Concepts and Practice
Barry Boehm et al., Software Cost Estimation with COCOMO II (maintenance and reuse models)
Meir M. Lehman, “Laws of Software Evolution” (on why software must continually change or become less useful)
Robert C. Seacord, Daniel Plakosh, and Grace A. Lewis, Modernising Legacy Systems