Onderhoudbaarheid van applicaties: een onderschatte kostenpost. Zeven tips

Door Victor van der Hulst In Smart@Vantage

Nog steeds worden de kosten van het onderhoud van maatwerk applicaties en het belang van onderhoudbaarheid onderschat. Uit vele onderzoeken, onder andere van Gartner, blijkt dat de onderhouds- en beheerkosten van maatwerk software de bouwkosten ruimschoots overtreffen tijdens de lifecycle van de applicatie. De onderhoudsfase is veelal de langste fase in de levensduur van een applicatie, soms zelfs langer dan de technologielevensduur. Om de Total Costs of Ownership (TCO) te verlagen, is de mate van onderhoudbaarheid zeer bepalend. In deze reeks een zevental tips die de onderhoudbaarheid verhogen.

Wat is onderhoudbaarheid en waarom is het belangrijk?

Onderhoudbaarheid van software ((ISO 25010: 

https://nl.wikipedia.org/wiki/ISO_25010) wordt vaak onderverdeeld in:
* Modulariteit: de mate waarin een systeem of computerprogramma opgebouwd is in losstaande componenten zodat wijzigingen van een component minimale impact heeft op andere componenten.
* Herbruikbaarheid: de mate waarin een bestaand onderdeel gebruikt kan worden in meer dan één systeem of bij het bouwen van een nieuw onderdeel.
* Analyseerbaarheid: de mate waarin het mogelijk is om effectief en efficiënt de impact, van een geplande verandering van één of meer onderdelen, op een product of systeem te beoordelen, om afwijkingen en/of foutoorzaken van een product vast te stellen of om onderdelen te identificeren die gewijzigd moeten worden.
* Wijzigbaarheid: de mate waarin een product of systeem effectief en efficiënt gewijzigd kan worden zonder fouten of kwaliteitsvermindering tot gevolg.
* Testbaarheid: de mate waarin effectief en efficiënt testcriteria vastgesteld kunnen worden voor een systeem, product of component en waarin tests uitgevoerd kunnen worden om vast te stellen of aan die criteria is voldaan. Kort gezegd wordt de mate van onderhoudbaarheid van software bepaald door de 

modulariteitherbruikbaarheidanalyseerbaarheidwijzigbaarheid en testbaarheid van de code. Dit lijkt een open deur, en toch zien we vaak dat onderhoudbaarheid uit het oog wordt verloren bij het (door)ontwikkelen van (bestaande of nieuwe) software. Tegelijkertijd kent onderhoudbaarheid een optimum; doorslaan werkt averechts. Na de eerste gemaakte functionaliteit begint al het onderhoud. Elke functionaliteit die wordt bijgebouwd, beïnvloedt de reeds bestaande code en wordt vooral ook beïnvloed door de bestaande code. Slecht opgezette code wordt steeds meer een last en verlaagt gaandeweg de productiviteit. Naar mate de hoeveelheid code groeit en de tijd verstrijkt, kan de productiviteit (en/of de kwaliteit) enorm dalen door de last van niet goed opgezette code. Dit wordt technical debt genoemd: schuld die nog uitstaat aan de techniek en die voor een goede werking en onderhoudbaarheid nog ingelost moet worden. In de volksmond spreken we dan snel over legacy. Technical debt is the invisible parts of your code that adds negative value to your system.

onderhoudbaarheid-van-applicaties-een-onderschatte-kostenpost-zeven-tips-techn-dept-blog-victor

Technical debt

Matige onderhoudbaarheid wordt dus vaak veroorzaakt door technical debt. Hoewel geen fijn woord, wordt het wel eens 

code cancer genoemd. Technical debt ontstaat doordat tijdens het ontwikkelen short cuts worden genomen om snelheid te maken: code die werkt maar moeilijk is te onderhouden. Er wordt op voortgeborduurd en beetje bij beetje wordt de code besmet. De snelheid van veranderingen die de business najaagt, wakkert dit alleen maar aan. Vroeg of laat wordt deze code onbeheersbaar en verliest de business alle snelheid. Het inlossen van deze schuld (technical debt) wordt *refactoring** *genoemd. *Preventing technical debt is what allows development to be agile in the long run. *(https://www.atlassian.com/agile/technical-debt) In de komende weken staan we stil bij een zevental tips om de onderhoudbaarheid, en daarmee de productiviteit en wendbaarheid, van maatwerk applicaties op het gewenste niveau te brengen en te houden.
* Tip 1: Werk met een AGILE ontwikkelaanpak
* Tip 2: Maak analyseerbaarheid en complexiteit zichtbaar
* Tip 3: Refactor met korte termijn doelen
* Tip 4: Automatiseer testen

onderhoudbaarheid-van-applicaties-een-onderschatte-kostenpost-zeven-tips-blog-victor

 

Meer informatie

victor-van-der-hulst

Victor van der Hulst

Managing Consultant

+31 6 22 98 68 76 Stuur Victor een e-mail

Reacties

Er zijn nog geen reacties op dit bericht.

Plaats een reactie

Dit veld is verplicht.

Vul een geldig e-mailadres in.

Dit veld is verplicht.