Good software architecture

½ dag:
Wat is softwarearchitectuur? Wat is de rol van architectuur in het ontwikkelproces? Stap voor stap door de definitie van softwarearchitectuur gaan om te begrijpen wat het is en wat het oplevert.

½ dag:
Het architectuurdomein (IEEE/ISO 42010). De belangrijkste concepten en hun relaties. Deze standaard wordt in de cursus gebruikt als raamwerk.

2 dagen:
Architectuur in context:

• Omgevings- en systeemanalyse: inzicht in de omgeving en de rol van het systeem in zijn omgeving.
• Softwareontwikkeling als een reeks beslissingen: wat te architecten? Hoe weet je of je genoeg architectuur hebt? Relatie met Scrum.
• De dominante decompositie (ook bekend als belangrijkste architectuurstijlen).
• Familiearchitecturen: het proces, de artefacten en softwaremechanismen bij de ontwikkeling van families van softwaresystemen.
• Kwaliteitsattributen: wat zijn het? Waarom zijn ze belangrijk? Hoe vind je ze?

½ dag:
Theorie van goede architectuur en het Architecture Reasoning Model. Deze twee onderwerpen lopen als een rode draad door de hele cursus.
Om een goede software architectuur op te zetten, te beheren en uit te dragen, bepaalt de softwarearchitect hoeveel aandacht te besteden aan bepaalde stakeholders, concerns, modellen en andere architectuuraspecten. Om zinvolle keuzes te kunnen maken, moet de architect eerst bepalen wat een goede softwarearchitectuur is in deze situatie. Als de architect een duidelijk beeld heeft van wanneer de softwarearchitectuur goed is voor een specifiek systeem en zijn omgeving, wordt het eenvoudiger om die goede softwarearchitectuur ook daadwerkelijk te realiseren. Om te controleren of een architectuur goed is en om richting te geven aan de architectuuractiviteiten kan de architect zich richten op het beantwoorden van een gegeven set vragen met betrekking tot correctheid, consistentie en communicatie. Deze vragen en hun antwoorden helpen om verbeterpunten voor de architectuur te identificeren.
Het Architecture Reasoning Model (ARM) ondersteunt het redeneren over een systeem in zijn omgeving langs drie dimensies: toepassing, ontwerp en proces.

• Toepassingsdimensie: redeneren over de betekenis en waarde van het systeem voor de klant.
• Ontwerpdimensie: redeneren over de resources waaruit het systeem is opgebouwd en hoe het die gebruikt.
• Procesdimensie: redeneren over de processen en organisatie voor de ontwikkeling en het onderhoud van het systeem.

½ dag:
In de tweede module bespreken we de resultaten van de huiswerkopdrachten en kunnen de deelnemers reflecteren op de toepassing van de theorie op hun eigen werk en van elkaar leren.

Opmerkingen:

• Kennis van modelleren (bij voorkeur UML, of op zijn minst OO, is vereist).
• Kleine oefeningen gebaseerd op eenvoudige bestaande voorbeelden.
• Grote oefeningen worden bij voorkeur uitgevoerd op casussen die door de deelnemers worden ingebracht.
• Tussen de twee modules door krijg je huiswerkopdrachten die ongeveer een dag in beslag nemen. De huiswerkopdracht is gericht op je eigen casus. Tijdens deze periode krijg je ook online persoonlijke coaching van de trainer gedurende ongeveer 1 uur.
• Reserveer in totaal ook ongeveer een dag voor het lezen van documenten.