Kenniskring Noord-Holland

Onvoldoende besef van het belang van Functioneel Beheer tijdens de ontwerp- en bouwfase van software leidt tot slechte onderhoudbaarheid.

In de levenscyclus van software is de periode van Functioneel Beheer de langste.
Bij de eerste release van software zien we vaak al dat er aanpassingen zijn met betrekking tot de functionaliteit. De fase van functioneel beheer (FB) is op dit moment dus al ingegaan. Ook zien we vaak dat na de beslissing om software uit te faseren nog functionaliteiten worden aangepast, in afwachting van de (meestal vertraagde) oplevering van het nieuwe systeem. Dit betekent dat de fase van FB de langste is in de levenscyclus van software.

Het ontwerpen van software en het opzetten van een goede architectuur vereist creativiteit en gedegen vakkennis. Er is een grote keuze aan talen, frameworks, basis-tools en bestaande software met API's.
Voor een gewone sterveling is er teveel om te kennen, beheersen en te gebruiken. Toch wordt er niet gedacht aan die arme functioneel beheerder die geacht wordt meerdere applicaties van verschillende architecturen te beheren/beheersen.
Geheel anders ligt dit voor de ontwikkelaar die op basis van een mooi ontwerp en duidelijke specificaties zijn of haar software mag gaan schrijven.
Hij - voor de eenvoud en leesbaarheid lees vanaf hier voor hij: hij of zij - werpt zich op een misschien nieuwe technologie, bespreekt met de architect eventuele keuzen en bouwt een mooie applicatie.
Hierbij gebruikt hij ontwikkelmethodieken als Test-driven development of eXtreme programming en komt met een mooi werkend resultaat dat vervolgens een test-traject ingaat.

In deze laatste fase is de tijdsdruk inmiddels opgelopen en het adagium "Als het volgens de architectuur is" wordt langzaam vervangen door "Als het maar werkt"
De goede voornemens over Documentatie en Unit-testen zijn inmiddels weer goede voornemens geworden.

Na de in-productie-name blijken er nog enkele performance-issues te zijn. Met enkele aanpassingen in de software (daar valt immers bij performance-problemen de meeste winst te halen) kunnen de problemen worden opgelost en wordt de software overgedragen aan FB.
Omdat er nieuwe technologien gebruikt worden, krijgen enkele FB'ders  een cursus of instructie en de applicatie draait.

Dan komt na twee jaar de vraag om een eenvoudige aanpassing. Paniek! Wie had de uitleg over de applicatie gekregen? Wie weet hoe de applicatie in elkaar steekt?

Scenario 1:
Degene die de applicatie in beheer heeft gekregen is aanwezig en beschikbaar. Hij zoekt en vindt de aantekeningen die hij twee jaar geleden heeft gemaakt.  Hij weet daardoor waar in de code de uitbreiding gedaan moet worden en volgens de documentatie van de architectuur en het heldere commentaar in de code kan hij eenvoudig binnen de oorspronkelijke architectuur zijn aanpassingen doen. De bijbehorende Unit-test wordt gemaakt en vervolgens wordt de code voor testen aangeboden en enige tijd later in productie genomen.
En die draaide nog lang en probleemloos...

Scenario 2:
Na lang zoeken blijken de FB'ders inmiddels op de ontwikkel-afdeling te zitten. Van een concurrerend bedrijf dat niet genegen is zijn mensen te verhuren.
Dus blijft niets anders over dan iemand te zoeken met kennis van framework X.
Helaas blijkt dat framework X voorbijgestreefd is door framework Y en er bestaat in de markt niet veel kennis meer over framework X.
Als eindelijk iemand gevonden is blijkt:

• De manier waarop het framework gebruikt is is niet standaard. Documentatie ontbreekt op welke punten is afgeweken en waarom.
• Delen van de code omzeilen het framework:  Documentatie ontbreekt op welke punten is afgeweken en waarom.
• Sommige stukken code bevatten het commentaar "Next line is a work-around for bug 123, don't know why" en "This code acellerates response. You are not supposed to understand this"
• Op sommige plaatsen wordt de database direct aangeroepen, op andere wordt via het framework gewerkt. Documentatie ontbreekt waarom.

Dit tweede scenario is misschien wel erg pessimistisch, maar het geeft wel aan waar tijden de ontwerp- en ontwikkelfase rekening mee moet worden gehouden.
Tot nu toe zie ik dat helaas niet vaak en komen de geschetste problemen wel degelijk en helaas niet zelden voor.

Scenario 3:

Na vier jaar moeten een aanal aanpassingen gedaan worden. Inmiddels is de technologie verbeterd, er is een opvolger voor Framework X: Framewrok Y. De gewenste aanpassingen zijn binnen dit framework een fluitje van een cent, maar vergen voor Framework X een grote hoeveelheid custom code. Op de markt zijn tools die op eenvoudige manier laten migreren van Framework X naar Framework Y. In de loop der tijd zijn vele aanpassingen gedaan, maar hoewel deze tot tevredenheid werken vallen ze buiten het framework. Dit was deels te verklaren door het gebrek aan kennis van de ontwikkelaar van het framework. Ook ontbrak code-review door iemand met voldoende kennis ervan. Het migreren van X naar Y is daardoor niet mogelijk zonder veel handmatige acties. Migreren kost daardoor meer dan het doen van de aanpassingen in Framework X. Helaas verergert dit toekomstige problemen.

Het wordt hoog tijd om meer aandacht te besteden aan goede methodieken voor Functioneel Beheer. Zeker bij de opstelling van de requirements wordt FB onderbedeeld, terwijl juist daar veel geld te verdienen is als aanpassingen eenvoudig gedaan kunnen worden, zonder inbreuk te maken op de architectuur.

Code-vervuiling (afwijken van Architectuur) is een van de grootste kostenveroorzakers is bij Software Development.