Warning: Undefined array key "bio" in /home/techwatch/domains/test.bits-chips.nl/public_html/wp-content/plugins/wpcodebox2/src/Runner/QueryRunner.php(126) : eval()'d code on line 13
Warning: Undefined array key "bio" in /home/techwatch/domains/test.bits-chips.nl/public_html/wp-content/plugins/wpcodebox2/src/Runner/QueryRunner.php(126) : eval()'d code on line 13
Author:
Reading time: 5 minutes
In opdracht van een klant heeft Alten een stuk software van een derde partij geanalyseerd op de kwaliteit van de code en de documentatie, de testdekking en het ontwikkelproces. Johan van den Muijsenberg en Coen Schaap beschrijven de aanpak en de uitkomst.
Er zijn veel redenen om als hightechbedrijf te willen focussen op softwarekwaliteit. Belangrijke motieven zijn het streven naar onderhoudbaarheid van (legacy) code en het behoud van de snelheid om nieuwe features toe te voegen aan een bestaand softwarearchief. Wanneer het beheer of de doorontwikkeling bij een andere partij komt te liggen, is het echter vooral belangrijk om de kwaliteit snel te kunnen analyseren. Dan is het wenselijk ook andere aspecten mee te nemen, zoals de testbaarheid van de code en de documentatie.
Bij Alten hebben wij onlangs een dergelijk geval aan de hand gehad. Een klant kreeg de mogelijkheid een stuk software van een derde partij in eigen beheer te nemen en deed daartoe een beroep op onze expertise. Alvorens te starten met de analyse zelf hebben we eerst samen bepaald welke kwaliteitsaspecten van belang waren. Hier ging het voornamelijk om de Iso 25001-attributen onderhoudbaarheid, betrouwbaarheid en uitbreidbaarheid.
Analyse
Tijdens de korte maar intensieve softwarekwaliteitsanalyse hebben we onderzoek gedaan naar verschillende vormen van debts die kunnen ontstaan. Daarbij hebben we niet alleen gekeken naar de code maar ook naar bijbehorende zaken zoals ondersteunende documentatie. Om de schuld in kaart te brengen, hebben we een diversiteit aan analysetechnieken, codevisualisatietechnieken, metrieken en tools ingezet.
Een eerste vorm van debt die we hebben onderzocht, is een tekort aan kennisborging, ook wel knowledge debt genoemd. Dit leidt tot een verlies aan productiviteit. Tijdens de documentatiescan die onderdeel is van de analyse ligt de nadruk op de aanwezigheid en kwaliteit van gedocumenteerde producteisen, omdat ontbrekende eisen validatie onmogelijk maken. Ook afdoende architectuurdocumentatie is essentieel om het ontwerp te kunnen toetsen aan de gestelde doelen en randvoorwaarden. Zo kunnen we richting geven aan toekomstige ontwikkelingen.
In de onderhavige case was deze vorm van debt een kritische. De designdocumentatie matchte met het daadwerkelijke geïmplementeerde ontwerp, maar was slechts beperkt aanwezig. Requirementsdocumentatie was er niet tot nauwelijks, wat interpretatie van de gewenste functionaliteit van de code erg lastig maakt.
Een tweede vorm is architectural debt. Volgens onderzoek hebben modules met veel in- en uitgaande afhankelijkheden tot acht keer meer defecten en is werken eraan de helft minder productief. Modules betrokken in cyclische relaties hebben gemiddeld zestig procent meer kans op defecten. Evenzo is het problematisch als modules te veel verantwoordelijkheden hebben. In deze gevallen spreken we van architectural debt.
Over het algemeen gaat de voorkeur uit naar kleine modules met beperkte verantwoordelijkheden en afhankelijkheden. Er zijn verschillende tools op de markt die kunnen bepalen in hoeverre de software hieraan voldoet (Figuur 1). Sommige laten ook toe om de architectuur vast te leggen in een architectuurdiagram (Figuur 2) of design structure matrix (Figuur 3). Door validatie van de architectuur via dergelijke gereedschappen te integreren in de build kunnen we overtredingen vroegtijdig signaleren en architectuurdegradatie voorkomen. Als de architectuur niet voldoet, kunnen we een impactanalyse uitvoeren van grootschalige softwareaanpassingen. Zonder tooling is dat bijna niet te doen.
In deze case hebben we onderzocht in hoeverre de modules en hun afhankelijkheden conform de beschreven architectuur zijn. Daar waar een deel van de architectuurinformatie ontbrak, hebben we de tools ingezet om de architectuur vanuit de code in kaart te brengen. Ook hebben we het gebruik van third-party library’s geïnventariseerd.
Een derde vorm is coding debt. Deze schuld wordt veroorzaakt door gebrekkig moduleontwerp of overtreding van programmeerregels en kan leiden tot gereduceerde onderhoudbaarheid en meer defecten. In deze case hebben we gekeken naar lines of code, codeduplicatie, technical debt-ratio, cyclomatische complexiteit en nog een beperkt aantal andere metrieken.
Een vierde vorm van schuld die we hebben onderzocht, is testing debt. Deze wordt veroorzaakt door een gebrek aan (automatische) tests. Over het algemeen geldt: hoe meer test coverage, hoe beter. Een goede richtlijn is één regel testcode voor elke regel productiecode. In dit geval hebben we een inschatting van de dekking gemaakt op basis van de verhouding test- versus productiecode, omdat op het moment van assessment geen werkende ontwikkelomgeving aanwezig was. Daarnaast hebben we gekeken naar de beschikbare testscenario’s.
Een vijfde vorm is ten slotte technological debt. Dit is schuld veroorzaakt door de technologieën die de software toepast. Bij gebruik van bijvoorbeeld verouderde ontwikkelomgevingen, platforms, programmeertalen of third-party library’s zal er ooit een inspanning nodig zijn om deze up-to-date te brengen. In deze case was er technologische schuld door de inzet van een breed scala aan technologieën.
Uitkomsten
Voor het uitvoeren van een volledige softwarekwaliteitsanalyse hebben we keuze uit een heleboel, veelal commerciële tools. Het verschilt van gereedschap tot gereedschap welke aspecten van de code ermee te onderzoeken zijn. Ook de licentiekosten lopen sterk uiteen. Daarom is het goed om een overzicht te hebben van de mogelijkheden en de tekortkomingen van de verschillende tools.
Het gebruik van meerdere gereedschappen om inzicht te krijgen in de softwarestructuur draagt zeker bij aan een snelle kwaliteitsanalyse, maar door de complexiteit en diversiteit van de tooling is er een specialist nodig om het onderzoek uit voeren. De gegenereerde output bestaat uit grote hoeveelheden metrieken, die ook nog eens per gereedschap kunnen verschillen. Dit vereist een gerichte selectie en goede interpretatie van de uitkomsten. Ten slotte presenteren tools de codestructuur in een overzichtelijke vorm en bieden ze inzicht in afhankelijkheden tussen modules (zoals externe bibliotheken) en hun grootte. Het is zaak om de interpretatie van deze structuren en hun invloed op codekwaliteit correct te beargumenteren.
Het analysetraject heeft enerzijds een kwaliteitsoordeel opgeleverd over de software die de klant in beheer wilde nemen. Per onderdeel hebben we inzichtelijk gemaakt wat de huidige kwaliteit is. Daarnaast hebben we toegelicht wat het effect is op de organisatie.
Anderzijds hebben we aanbevelingen en suggesties gedaan om de onderzochte onderdelen op een hoger niveau te krijgen. Onze adviezen richten zich zowel op de korte als op de lange termijn. Die voor de korte termijn adresseren heel herkenbare problematiek zoals fouten in de bestaande codebase, ontevredenheid van klanten of bijvoorbeeld een te grote benodigde inspanning voor updates; die voor de lange termijn focussen vooral op preventie van onder meer additioneel werk.
Uiteindelijk is het aan de klant welke punten hij aanpakt in welke projectvorm. Hij kan er ook voor kiezen om een uitgebreid assessment te laten doen, bijvoorbeeld een architecture rediscovery of een compliancy check. Alles met als doel: less debt is less disturbance.
