Artikel

De softwarearchitect als waakhond

Het leven van de softwarearchitect is niet eenvoudig. Naast de verantwoordelijkheid voor het ontwerpen van een goed softwaresysteem bestaat er ook nog de verantwoordelijkheid om te controleren of het softwaresysteem wel ontwikkeld wordt conform het ontwerp. Zijn de verschillende concepten, samenstellingen, structuren, modules, relaties, functionaliteiten en bouwstenen wel gerealiseerd conform het ontwerp?

De visie, eisen en wensen betreffende het softwaresysteem worden vastgelegd in blueprints, architectuurdocumenten en technische ontwerpen, maar betekent dit ook dat de bouwers en testers zich houden aan de afspraken die hierin aangegeven zijn? Soms wel, maar meestal niet. Bewaking van de systeemontwikkeling is daardoor een on-going business geworden die het uiterste vraagt van de bouwers en de architect.

Wat bewaakt de architect?

De volgende lijst is zeker niet uitputtend, maar geeft een goed beeld van de verschillende niveaus waarop controles worden uitgevoerd. Idealiter bewaakt de architect activiteiten en deliverables op verschillende niveaus:

  • Functioneel niveau, waarbij de architect een aantal functionele testen uitvoert om een gevoel te krijgen van de functionele conformiteit tussen eisen en realisatie.
  • Documentatieniveau, waarbij de architect reviews uitvoert van functionele en technische specificaties en interfaces.
  • Modelniveau, waarbij de architect een review uitvoert op de compleetheid, correctheid en begrijpbaarheid van het domeinmodel.
  • Structuurniveau, waarbij de architect controleert of de opdeling en samenstelling van de verschillende onderdelen/bouwstenen van het gerealiseerde overeenkomstig zijn met de intentie.
  • Codeniveau, waarbij de architect reviews uitvoert op de correctheid van de implementatie door de code. Hij checkt hierbij bijvoorbeeld op het correct toepassen van de styleguide, patterns en gebruik van libraries.

Waarom bewaking?

Controles op de diverse niveaus is van belang om ervoor te zorgen dat de visie en de eisen zich zo optimaal mogelijk laten vertalen naar de implementatie. Non-conformiteit zal al snel leiden tot kostenoverschrijdingen, doordat het softwaresysteem minder eenvoudig wordt begrepen en/of te complex gemaakt wordt.

Bewaking in de praktijk

In de praktijk blijkt vaak dat er twee soorten waakhonden zijn. De architect met een softwaretechnische achtergrond zal vaker intensievere controles uitvoeren op model-, structuur- en codeniveau. Een niet-technische architect zal zich meer focussen op functionaliteit, documentatie en structuur. De kans dat alle niveaus voldoende aandacht krijgen, is dan ook niet snel te verwachten.

Hoe kan de bewaking worden verbeterd?

Niet op alle niveaus is het eenvoudig om grote verbeteringen aan te brengen. Toch zijn er mogelijkheden. Er zijn voldoende hulpmiddelen op de markt waarmee op de verschillende niveaus belangrijke verbeteringen kunnen worden doorgevoerd. Helaas is de invoertijd van een hulpmiddel per niveau nogal variabel.

Verbeteren van documentatie kan worden gerealiseerd door het documentatieproces aan te passen en deze bijvoorbeeld onder te brengen in een repository in plaats van Worddocumenten. Eisen en wensen die zijn vastgelegd in een repository zijn eenvoudiger te managen. Eisen kunnen dan bijvoorbeeld gesorteerd, geaccepteerd, geweigerd of uitgesteld worden. Hierdoor is het voor het ontwikkelteam duidelijk in welk stadium het project zich bevindt.

Op modelniveau bestaan tools waarmee het mogelijk is om de consistentie van het model te bewaken. Veelal beschikt de betere modelleertool (bijvoorbeeld UML) over één of meerdere modelcontrole functies. Het is opmerkelijk dat deze functie doorgaans niet gebruikt wordt.

De structuur van een softwaresysteem is eenvoudig in kaart te brengen door de onderlinge afhankelijkheden binnen het softwaresysteem te visualiseren en te bewaken. Verschillende tools bieden de mogelijkheid om bestaande softwaresystemen te analyseren en weer te geven in dependency graphs of matrices. Het voordeel van matrices is de eenvoud en schaalbaarheid.

Op codeniveau zijn een veelvoud aan tools beschikbaar waarmee een statische en dynamische analyse kan worden uitgevoerd. Naast verificatie van de styleguide zijn geavanceerdere tools ook in staat om foutieve programmeerconstructies te detecteren. Hierdoor kunnen fouten die normaliter pas tijdens de operationele fase worden gevonden al in een vroegtijdig stadium worden gevonden. Dit bespaart kosten en verhoogt de klanttevredenheid.

Door de systeemontwikkeling op bepaalde punten te automatiseren, kunnen gedurende de ontwikkeling en het onderhoud automatisch statusrapportages worden verkregen. Veelal gevisualiseerd in een web-based dashboard. Hierdoor komt managementinformatie voor iedereen beschikbaar. Door deze vorm van openheid, met name naar de klant toe, wordt het begrip versterkt en het verbetert onderling vertrouwen.

Stel dat de architect dagelijks inzicht krijgt in:

  • De status van de requirements, afgezet tegen de resultaten van automatisch testen per requirement.
  • De meest up-to-date documentatie waarin gezocht en geïnventariseerd kan worden.
  • Inzicht in de conformiteit tussen gewenste en gerealiseerde structuur.
  • Een overzicht van de belangrijkste programmeerbugs.
  • Een historisch overzicht van de belangrijkste statusindicators.

Dan betekent dit dat de architect meer inzicht en toezicht heeft op de ontwikkeling van het softwaresysteem en daardoor veel adequater kan bijsturen indien afwijkingen gaan ontstaan. Discussies worden niet gevoerd op basis van gevoel, maar op tastbare resultaten.

Bewaken van structuur van het softwaresysteem

Gebrek aan inzicht in de structuur is de belangrijkste beperkende factor bij de ontwikkeling van een softwaresysteem. Inzicht in de afwijking tussen de gewenste en gerealiseerde structuur levert de grootste bijdrage aan het succes van een project. Iedere architect moet het belangrijk vinden om de afwijkingen te kennen en een plan op te stellen om deze terug te dringen. Hoe beter de structuur, des te eenvoudiger zal onderhoud nu en in de toekomst zijn.

Conclusie

De waakhond in de softwarearchitect vervult een aanzienlijke taak. Als de waakhond alles handmatig moet doen, dan heeft hij zelfs bij relatief kleine softwaresystemen alleen al zijn handen vol aan het uitvoeren van controles. Het is daarom van belang dat ervoor gezorgd wordt dat een deel van deze activiteiten geautomatiseerd worden en regelmatig als managementinformatie aangeboden worden. Historische data verzameld tijdens de ontwikkeling, biedt een schat aan stuurinformatie. Om de taak als waakhond goed te kunnen vervullen is managementinformatie met betrekking tot de systeemstructuur nog wel het meest effectief.

Categorie:   
Auteur(s)
afbeelding van hanvanroosmalen
Han van Roosmalen
Han van Roosmalen Softwarediensten - Softwarearchitect

Han van Roosmalen is zelfstandig softwarearchitect. Sinds 1986 werkt hij aan grote en kleine innovatieve softwareprojecten in de embedded en de back-office omgeving. Als architect is hij met name geïnteresseerd in de realisatie van systemen conform de juiste structuur, waarbij inzicht, toezicht en overzicht een essentiële rol spelen. Sinds vier jaar werkt hij samen met Lattix, één van de leveranciers van Dependency Structure Matrix tools om snel inzicht te krijgen in de structuur van bestaande applicaties. Han levert verschillende diensten om de toepassing van DSMs snel en effectief te implementeren. Han van Roosmalen is te bereiken via: han@hanvanroosmalen.nl.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.