Steeds vaker krijg we in onze software-analysepraktijk te maken met de vraag of wij met behulp van onze analyse software kennis uit bestaande systemen naar boven kunnen halen. Veel bedrijven zijn namelijk afhankelijk geworden van slecht gedocumenteerde en zeer lastig te onderhouden softwaresystemen. Men wil de risico’s hiervan mitigeren door het moderniseren of vervangen van deze software. Er zit echter jarenlange belangrijke domeinkennis en ervaring in de software verstopt, die men niet wil verliezen. Hoe zorgt u ervoor dat u deze kennis kunt behouden?

 

Top-down vs. bottom-up benadering

Een manier om de kennis die in software verstopt zit weer boven water te krijgen, is het interviewen van subject matter experts, waarbij door middel van een top-down approach o.a. bedrijfsprocessen/services en bedrijfsregels worden geanalyseerd en beschreven. Dit is een prima manier om ‘met de kennis van nu’ naar de organisatie en de behoefte aan geautomatiseerde ondersteuning te kijken. Een nadeel van deze methode is dat men niet alle kennis die in de loop der jaren in de softwaresystemen is verwerkt, paraat heeft. Het risico is dan ook dat men zeer relevante bedrijfsregels bij de top-down benadering over het hoofd ziet.

Bij Omnext pleiten we dan ook voor een combinatie van een top-down en een bottom-up benadering. Bij de bottom-up benadering wordt kennis uit de bestaande software gedestilleerd en beschreven. Er wordt niet voor niets vaak gezegd dat de enige waarheid verstopt zit in de code.

 

Beperk de scope

Van belang bij het expliciet maken van kennis in de broncode is het bepalen van de juiste scope. Om de bottum-up benadering goed in te kunnen zetten kan het gebruik van de juiste tools de benodigde inspanning drastisch verlagen.

Documentatie moet ‘lean and mean’ zijn. Net voldoende om het systeem goed te kunnen onderhouden. Het heeft geen zin om documentatie te produceren met informatie die eenvoudig al uit de software is te halen. Zo zijn schermbeschrijvingen en screenshots wat ons betreft niet zo interessant. Veel interessanter zijn de validatie- en rekenregels. Ook documentatie over het onderhouden van stamgegevens is niet interessant. Daar zitten over het algemeen weinig interessante bedrijfsregels in. Ook blijkt vaak 30% van de broncode van legacysystemen ‘dood’ te zijn. Ook hiervan wil je geen documentatie opleveren.

Afhankelijk van het doel kan het interessant zijn om je te beperken tot dat gedeelte van de code wat in de afgelopen periode nog actief is onderhouden. Hiermee kan je  de scope ook zomaar tot 10% van het totaal reduceren!

Daarnaast is het niet zinvol om voor de hand liggende te functionaliteit te documenteren. Iedereen weet ondertussen wel hoe je een postcode valideert. Focus je bij de documentatie dan ook op die delen van de software die uniek zijn voor jouw business. Vanuit onze ervaring weten we dat dit vaak maar 20% van het totaal is.

Vragen? Neem contact met ons op.

 

Share This