Het belang van ISO 5055 als uitbreiding op ISO 25010 voor het geautomatiseerd meten van software code voor overheidsorganisaties.
De digitale weerbaarheid van de overheid moet sterker. Maar hoe krijgt u dat voor elkaar? Veel overheidsorganisaties geven op dit moment aandacht aan het beter inrichten van Lifecycle Management (LCM). Inzicht in de technische staat van applicaties is een goed startpunt om de kwaliteit en de security te verbeteren en plannen te maken voor de toekomst. Het inventariseren van de omvang en de technische staat van de applicaties in het portfolio is een belangrijke stap, want deze factoren bepalen voor een groot deel de onderhoudskosten. Om goede toekomstplannen te kunnen maken is deze informatie van groot belang.
Hoe maakt de overheid de technische staat van een applicatie inzichtelijk?
Binnen de overheid wordt er vaak gesproken over de International Standardization Organization (ISO) 25010 standaard als het gaat om het inzichtelijk maken van de technische staat van een applicatie. Deze ISO standaard heeft in 2011 de oude standaard 9126 vervangen en kijkt naar 2 aspecten: de productkwaliteit en de geschiktheid voor gebruik. Onder ISO 25010 worden kenmerken als functionele geschiktheid, prestatie-efficiëntie, uitwisselbaarheid, bruikbaarheid, betrouwbaarheid beveiligbaarheid, onderhoudbaarheid en overdraagbaarheid beschreven. Er zijn verschillende technologieën beschikbaar op de markt die deze kenmerken geautomatiseerd kunnen meten en die kunnen beoordelen in welke mate een applicatie voldoet aan deze kenmerken. Deze technologieën meten de applicatie source code geautomatiseerd door en produceren dan een of meerdere dashboards waarop scores op de ISO 25010 kenmerken getoond worden. Dat klinkt prima, maar het is geen garantie voor succes.
Hoe zit het met de ontwikkeling en het onderhoud van moderne applicaties?
Een nadeel van veel technologieën is dat de analyse op code niveau wordt uitgevoerd. Bestand na bestand wordt gekeken naar zaken als complexiteit en security. Moderne applicaties bestaan echter uit vele verschillende componenten, lagen, files, frameworks, etc. Als we naar applicaties kijken vanuit een architectuur oogpunt, dan ziet dat eruit als het voorbeeld in de volgende figuur.
Figuur 1: voorbeeld architectuur overzicht van een applicatie
Zoals u waarschijnlijk al doorhad, is de complexiteit groot, mede door de vele aanroepen tussen de verschillende onderdelen. Uit onderzoek blijkt dat veel (tot wel 60%) van de productieincidenten van applicaties worden veroorzaakt door foutieve aanroepen tussen componenten. Deze incidenten zijn moeilijk te reproduceren en op te lossen en leveren mede daarom de meeste downtime op. Het is daarom belangrijk om de kwaliteit van applicaties te meten op codeniveau en op systeemniveau. Een voorbeeld van goede code, maar een matig systeem, staat in de volgende figuur.
Figuur 2: voorbeeld van goede code, maar een slecht systeem
De man in de figuur wil de pinautomaat gebruiken. Hoewel op codeniveau alles in orde lijkt, is het toch niet mogelijk de pinautomaat te gebruiken, omdat er bijvoorbeeld een incident is opgetreden in een van de slechte aanroepen in het systeem.
Om dit probleem te tackelen is er in 2021 een uitbreiding gekomen op de ISO 25010 standaard. Dit is de ISO/IEC 5055 standaard voor het geautomatiseerd meten van software code kwaliteit. Deze standaard schrijft voor dat er heel specifiek moet worden gekeken naar overtredingen van goede codeerstandaarden en architectuur standaarden. Er zijn duizenden regels vastgelegd in vele verschillende standaarden en best practices, zoals bijvoorbeeld van OWASP, CWE, NIST, CISQ en OMG. Deze regels zijn dingen die je moet doen, of juist niet moet doen bij het ontwikkelen en onderhouden van de applicatie. Een voorbeeld van een van de duizenden regels: „Avoid SQL injection through API requests“. Dit is een van de belangrijke regels op security gebied en een overtreding van deze en vergelijkbare regels levert een groot risico op voor de applicatie, en mogelijk voor de hele organisatie. Uiteindelijk zijn er altijd mensen betrokken bij applicatie ontwikkeling en onderhoud en dus kunnen er altijd issues zijn, ook als de mensen heel goed zijn.
Figuur 3: software development is mensenwerk, en niemand kent alle duizenden regels uit z’n hoofd, ook Dave niet! (Bron: https://www.jklossner.com/)
Wat is het voordeel van het geautomatiseerd meten van software code kwaliteit?
Het voordeel van de ISO 5055 manier van het onderzoeken van software kwaliteit is dat het ook mogelijk wordt om heel specifiek in de code aan te tonen waar een regel is overtreden, waarom dat een mogelijk kritiek issue is en hoe dit eventueel opgelost kan worden. Dit zorgt ervoor dat het maken van aanpassingen een stuk gemakkelijker wordt. De ISO 5055 standaard maakt het dus mogelijk om de software kwaliteit vast te stellen op codeniveau en op systeemniveau. Door vervolgens de gevonden issues gericht te verbeteren, worden de risico’s in de applicatie snel verminderd en wordt de technische kwaliteit snel verbeterd. Dit kan er in het kader van Lifecycle management weer toe leiden dat toekomstplannen worden aangepast omdat de technische staat van de applicaties wordt verbeterd en de onderhoudskosten omlaag gaan.
Hoe doen we dit bij IDC Metri?
Bij IDC Metri voeren we regelmatig codekwaliteit onderzoeken uit waarbij we CAST technologie inzetten die de code op zowel ISO 25010 als ISO 5055 meten. Het ontwikkelteam krijgt heel specifiek inzicht in de gevonden issues en we geven onze klanten een concreet verbeterplan waarbij het doel is met zo weinig mogelijk inspanning zoveel mogelijk kwaliteitswinst te halen.
Het management kan vervolgens de voortgang monitoren op het management dashboard, waar de trends staan in de scores per applicatie, zodat er een duidelijk beeld is wat de technische staat is van de applicaties en de trends hierin, o.a. als basis om keuzes te kunnen maken in het kader van Lifecycle management. Dit ziet u terug in onderstaande figuur. Het voordeel van de CAST technologie is dat we ook geautomatiseerd de omvang meten in Automatische functiepunten (AFP). Dit stelt ons in staat om ook financiële benchmarks en adviezen te geven op basis van de meer dan 15000 data punten van applicaties en projecten in onze database.
Figuur 4: voorbeeld van het developer dashboard: waar zit de fout, waarom is het een fout en hoe kan deze worden opgelost
Meer weten? Kom dan naar onze webinar voor overheidsinstellingen
Op donderdag 26 januari om 16.00 uur organiseren we een webinar waar we ingaan op hoe we dit doen en waarbij we Frans Struijk, directeur IV Facilitair Bedrijf bij het UWV, hebben gevraagd om te laten zien hoe wij het UWV geholpen hebben in een specifieke case, waarbij ook een bekende system integrator betrokken was. Inschrijven kan hieronder.
