Artikel

Architectuur en testen - deel 3

In het eerste artikel is de relatie gelegd tussen architectuur en testen. In het tweede artikel is de Project Start Architectuur en de bijbehorende rapportage besproken. We zijn geëindigd met de checklist van een businesscase en de vraag welke checklist u gebruikt bij uw architectuurmethode.

In het eerste artikel zijn we uitgegaan van de testbasis bij het ontwikkelen van informatiesystemen. Documenten die tot de testbasis gerekend kunnen worden zijn: de businesscase, het programma van eisen, het functioneel ontwerp en het technisch ontwerp. Het programma van eisen is een onderwerp dat in de praktijk tot veel problemen kan leiden.

Hoe kan architectuur eraan bijdragen goede programma’s van eisen te maken?

Het begint in ons voorbeeld met informatie-architectuur. Wat voor informatiesysteem heeft de organisatie nodig en waar moeten we dan rekening mee houden? We kunnen namelijk niet vrij kiezen. Het nieuwe systeem zal gekoppeld moeten worden aan andere systemen die al in gebruik zijn en die we in een latere fase kunnen krijgen. Dus in het algemeen gezegd moet het passen binnen onze informatie-architectuur.

Uitspraken die in een informatie-architectuur terugkomen zijn: klantgegevens worden altijd en alleen opgeslagen in het centrale relatiebeheersysteem. Andere systemen dienen voor hun klantgegevens altijd het centrale systeem te raadplegen en dienen alleen zelf afgeleide gegevens op te slaan en geen brongegevens. Dit ter voorkoming van gegevensinconsistentie.

Naleving van deze regels wordt afgedwongen via de applicatie-opleveringstoets en de maandelijkse analyse van gegevensbehandeling door applicaties.

Het nieuwe informatiesysteem moet dan dusdanig worden gebouwd of al zijn gebouwd dat het zich hierin kan schikken of op aangepast kan worden. Een dergelijke uitspraak uit de informatie-architectuur is specifiek te maken voor een programma van eisen betreffende een bepaald informatiesysteem. Dit is een praktijkvoorbeeld van hoe informatie-architectuur een bijdrage levert aan het maken van een programma van eisen.

Het nieuwe informatiesysteem moet echter ook beheerd kunnen worden door het huidige en toekomstige technisch beheer. Dat wil zeggen dat we ook moeten voldoen aan de huidige en toekomstige exploitatie van architectuur. Als laatste hebben we te maken met de ontwikkelorganisatie. Dat kan een eigen interne ontwikkelorganisatie zijn maar ook een derde partij. Zij hanteren een applicatiearchitectuur en een ontwikkelarchitectuur. Om het niet al te ingewikkeld te maken laten we de ontwikkelorganisatie even buiten beschouwing.

Door het vaststellen van het informatiebeleid is duidelijk welke eisen een organisatie stelt aan informatiesystemen en het beheer van die informatiesystemen. In de beleidsdocumenten is ook beschreven welke rol architectuur vervult en in welke documenten de eisen vanuit architectuur zijn vastgelegd.

Met zo’n kader van eisen en randvoorwaarden is het stukken eenvoudiger om een programma van eisen op te stellen. Simpel gezegd, neem de eisen en randvoorwaarden en voeg daar de gewenste en vereiste functionaliteit aan toe en klaar is het programma van eisen.

Als later de offertes van de leveranciers binnen zijn is het gemakkelijker om na te gaan of het aanbod voldoet. Ook bij de latere 'Proof of Concept' hebben we een duidelijke richtlijn. Omdat beoordelen niet alleen een zaak is van: het voldoet wel of het voldoet niet, gaat ook daar de architect helpen. Bij twijfel kan een architect uitkomst bieden door aan te geven welke keuze gemaakt dient te worden. Gefundeerd accepteren of afwijzen van een offerte komt dan ook binnen handbereik.

Categorie:   
Auteur(s)
afbeelding van adpaauwe
Ad Paauwe
Dragon1 Academy

Ad Paauwe is werkzaam als management consultant en trainer/coach bij Dragon1 Academy.

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.