Beheer

IT beheer

Schijnzekerheid van metrieken

2 september 2011

Een opdrachtgever van een ICT-intensief project heeft het niet gemakkelijk – of het nu gaat om een nieuwbouw-, verbouw-, herbouw-, migratie- of consolidatietraject. Dat geldt zeker bij de overheid, waar de roep om verantwoording en transparantie steeds luider klinkt.

Veel van deze projecten worden gekenmerkt door bestuurlijke onduidelijkheden en territoriumtwisten, maar zeker ook door technische complexiteit. Zowel nieuwe als bestaande systemen moeten zich conformeren aan vaak snel evoluerende wetgeving. Daarbij moeten ze gebruikmaken van standaardvoorzieningen die deels nog in ontwikkeling zijn. En er moet gekoppeld worden met allerlei systemen van uiteenlopende origine en diverse eigenaren.

De opdrachtgever maakt zich dus (terecht) al snel zorgen en zoekt zekerheid en grip. De eerste reflex is dan om de aansturing van het project en de controle daarop goed in te richten. Dit onder het motto: als we zorgen dat de goede dingen gebeuren zijn we ‘in control’.

Ondanks dergelijke maatregelen gaat het toch vaak mis, want de ICT-inhoud blijkt complexer dan gedacht. De opdrachtgever wordt vervolgens geconfronteerd met veel uiteenlopende beelden en meningen, maar helaas met weinig feitelijkheid.

Het wordt dan tijd om op een objectieve, inhoudelijke manier inzicht te krijgen in de ‘werkelijke kwaliteit’ van het systeem in kwestie. Is het goed (genoeg) om de geplande ambities mee te realiseren? Is het flexibel en toekomstvast genoeg? Moeten we wellicht stoppen met de dingen die we van plan zijn?

Hoe krijgt de opdrachtgever – typisch niet een ICT-expert – inzicht in die werkelijke kwaliteit?

Metrieken

De laatste tijd is een groeiende belangstelling zichtbaar voor het gebruik van softwaremetrieken om ‘de kwaliteitsvraag’ te beantwoorden. Het idee is dat uit metingen aan software, getallen zijn af te leiden die kwaliteit expliciet maken en eenduidig weergeven. Er zijn inmiddels zelfs certificeringsschema’s rond onderhoudbaarheid geïntroduceerd waarbij systemen worden gekeurd op basis van een beperkt aantal metrieken die vergeleken worden met een benchmark (zie: www.tuvit.de/english/maintainability.asp).

Het beeld dat ontstaat is: als de metrieken goed zijn, is alles onder controle. Helaas, de werkelijkheid is anders. Softwaremetrieken zijn nuttig, maar te beperkt voor een integraal kwaliteitsoordeel. Een systeem met ‘slechte cijfers’ kan door goede documentatie toch inzichtelijk en onderhoudbaar zijn. En een systeem met goede cijfers kan door de gekozen opzet zodanig rigide zijn dat uitbreidingen of aanpassingen zeer moeilijk te realiseren zijn.

Inzicht in de werkelijke kwaliteit van een systeem vergt een gerichte vraagstelling en een breed analyseperspectief: gericht op concrete kwaliteitsvragen die de brug slaan tussen de zorgen van de opdrachtgever en de werkelijkheid in de techniek, ‘breed’ in de zin dat alle relevante objecten en aspecten worden beschouwd in de context van het systeem, de organisatie eromheen en de vraag van de opdrachtgever.

Zo’n analyse met aandacht voor context wordt gekenmerkt door twee hoofdzaken.

De eerste is het scherp krijgen van de echte kwaliteitsvraag. Opdrachtgevers gebruiken vaak algemene termen, zoals ‘flexibel’ of ‘toekomstvast’, om hun zorgen uit te drukken. Voor een adequaat onderzoek met een bruikbaar antwoord moet dit specifieker zijn. Op welke vlakken is flexibiliteit nodig: functionaliteit, aantallen gebruikers of transacties, aansluiting bij andere systemen? En wat toekomstvastheid betreft: hoe ziet die toekomst er dan (mogelijk) uit? Gaat het systeem worden overgenomen voor eigen onderhoud? Of wordt het juist overgedragen aan een andere partij? Moet het samengevoegd worden met een ander systeem? Wordt het straks ingezet op totaal andere vlakken?

De gezamenlijke formulering van de belangrijkste onderzoeksvragen vormt de basis voor de vertaling van de technische analyse naar het begrippenkader van de opdrachtgever. En naar een onderbouwd besluit over ‘hoe verder’.

Objecten en criteria

De tweede hoofdzaak is het richten van het onderzoek op basis van de vraagstelling. Nadat helder is wat de vraagstelling is, kan bepaald worden welke objecten of thema’s beschouwd moeten worden en welke criteria (op hoofdlijnen) zullen worden gebruikt in de beoordeling. Naast de code kan het daarbij gaan om (onder andere):

  • een algemene architectuurbeschrijving;
  • eisen en functionele specificaties;
  • specifieke documentatie voor complexe functionele zaken (zoals afleidingen, beslissingen) of technische zaken (zoals specifieke uitwisselingsprotocollen of persistentieaanpakken);
  • geautomatiseerde tests;
  • inrichting van gebruikte platforms, middleware en tools;
  • documentatie en toolinrichting voor het bouwen, testen en deployen;
  • technische en functionele beheerdocumentatie;
  • beschikbare kennis – qua omvang, diepgang en kwaliteit;
  • wijzigingshistorie;
  • en misschien een draaiend systeem.

Voor diverse soorten objecten kunnen specifieke criteria worden geformuleerd, bijvoorbeeld actualiteit, consistentie en leesbaarheid van documentatie, de dekkingsgraad van geautomatiseerde tests of de actualiteit van de gebruikte hulpmiddelen. Ook kunnen publieke (of eigen) beoordelingskaders, bijvoorbeeld rond codering, worden vastgesteld.

De analyse verloopt iteratief waarbij het inzicht in de stand van zaken en de risicogebieden gaandeweg groeit. Beginnend met overzichtsdocumentatie wordt steeds meer ingezoomd op (andere) relevante objecten en nader onderzoek gedaan naar aspecten waarover zorgen en onduidelijkheden bestaan. Alleen al vanwege de enorme hoeveelheid informatie die onderzocht wordt, is inzet van hulpmiddelen (onder andere voor code-analyse) vaak noodzakelijk. Niet alleen om extreem afwijkende waardes voor metrieken te vinden, maar ook voor het visualiseren van structuren en afhankelijkheden. Indien nodig wordt ook de impact van toekomstscenario’s bepaald en uitgewerkt. Uiteindelijk worden de bevindingen gevalideerd met de betrokkenen – ze moeten immers kloppen.

Na de analyse is er voldoende inzicht verkregen om de oorspronkelijk vastgestelde vragen te beantwoorden. Op basis van de bevindingen kan een reëel en onderbouwd besluit worden genomen om – bijvoorbeeld – een systeem in onderhoud te nemen danwel te bepalen wat daarvoor nog moet gebeuren. Ook geeft dit ruimte om te discussiëren over de toekomstplannen voor een systeem en de haalbaarheid ervan. Niet op basis van gevoelens, niet op basis van een beperkte blik, maar op basis van een integrale analyse van alle relevante aspecten.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Laat de klantenservice je terugbellen!