Wat is ondersteunen bij ontwerpkeuzes?
Bij het maken van een softwareontwerp worden regelmatig meerdere oplossingsrichtingen overwogen. Denk aan verschillende structuren, technologieën of interaction designs. Om tot een weloverwogen keuze te komen, is het essentieel om deze opties expliciet vast te leggen en systematisch tegen elkaar af te wegen.
Een goede onderbouwing van ontwerpkeuzes helpt bij:
- Communicatie met belanghebbenden
- Verantwoording van beslissingen
- Toekomstig onderhoud en uitbreiding
- Inzicht in de ontwerpcontext
Casus
Een team staat voor de keuze tussen het opslaan van documenten in een relationele database (PostgreSQL) of een blob store (zoals AWS S3). In een presentatie vergelijken ze de opties op criteria als schaalbaarheid, kosten, toegankelijkheid en beveiliging. Uiteindelijk kiezen ze S3 vanwege de eenvoudige integratie en lagere opslagkosten.
Hoe zit ondersteunen bij ontwerpkeuzes in elkaar?
Het proces van het ondersteunen van ontwerpkeuzes bestaat uit de volgende onderdelen:
-
Inventariseren van alternatieven
Voordat je een keuze maakt, is het belangrijk om verschillende oplossingsrichtingen te verzamelen. Deze alternatieven kunnen voortkomen uit brainstormsessies, referentieprojecten of literatuuronderzoek.Voorbeeld: Bij het ontwerpen van een authenticatiesysteem wordt overwogen om gebruik te maken van OAuth, SAML of een eigen inlogsysteem. Elk alternatief wordt geïnventariseerd om te bepalen welke geschikt is.
-
Bepalen van afwegingscriteria
Criteria helpen om alternatieven objectief te vergelijken. Veelgebruikte criteria zijn: performance, onderhoudbaarheid, schaalbaarheid, gebruiksvriendelijkheid, kosten, integratiegemak en technische haalbaarheid. Het is handig om criteria te wegen op basis van prioriteit.Voorbeeld: Voor een mobiele app wordt veiligheid als belangrijker beschouwd dan performance. Hierdoor krijgt ‘veiligheid’ een zwaardere weging in de keuze tussen verschillende opslagoplossingen.
Let op
Afwegingscriteria en scores moeten altijd onderbouwd zijn met een bron (zoals benchmarks, documentatie of gebruikersfeedback) en/of gevalideerd worden door belanghebbenden. Vermijd subjectieve of ongefundeerde schattingen.
-
Objectieve vergelijking maken
Met behulp van een beslismatrix, tabel of diagram vergelijk je de alternatieven op basis van de gekozen criteria. Deze visualisatie maakt het eenvoudiger om tot een onderbouwde keuze te komen.Voorbeeld: Een beslismatrix wordt ingevuld voor drie UI-bibliotheken (Material UI, Bootstrap, Tailwind) waarbij elke optie wordt gescoord op consistentie, toegankelijkheid en documentatie. Tailwind scoort het hoogst.
-
Motiveren van de keuze
Licht toe waarom een bepaalde optie gekozen is. Benoem ook bewust waarom andere alternatieven zijn verworpen. Deze motivatie moet gebaseerd zijn op de vergelijking en criteria. Dit voorkomt discussie achteraf. Een goede motivatie zorgt ervoor dat de keuze begrijpelijk is voor alle belanghebbenden, ook als zij niet direct betrokken waren bij het afwegingsproces. Stem de uitleg af op het kennisniveau van de doelgroep en gebruik daarbij duidelijke taal en eventueel visuele ondersteuning.Voorbeeld: Er wordt gekozen voor OAuth als authenticatieprotocol, omdat het brede ondersteuning heeft binnen cloudplatforms, terwijl SAML wordt verworpen vanwege de complexiteit en verminderde compatibiliteit met mobiele apps. In de toelichting wordt dit uitgelegd in begrijpelijke taal voor de product owner, met een schematisch overzicht van het authenticatieproces.
-
Vastleggen in presentatievorm
Zet de gemaakte afwegingen en de uiteindelijke keuze om in een overzichtelijke presentatie. Gebruik hierbij visuele elementen zoals grafieken, wireframes of diagrammen. Zorg dat de boodschap aansluit bij de doelgroep (ontwikkelaars, management, eindgebruikers). Houd rekening met de informatiebehoefte van elke stakeholder: technische details voor developers, gebruiksimpact voor eindgebruikers, en kosten of risico’s voor management. Door de presentatie af te stemmen op deze behoeften, wordt het draagvlak voor de gemaakte keuzes vergroot.Voorbeeld: In een PowerPoint-presentatie worden de voor- en nadelen van twee API-ontwerpen getoond met flowcharts en een samenvattende conclusie waarin het gekozen ontwerp gemotiveerd wordt. Voor het management wordt een extra slide toegevoegd met een kostenvergelijking over 3 jaar.
Voorbeeld (keuzematrix)
| Optie | Performance | Kosten | Onderhoud | Totaal (score) |
|---|---|---|---|---|
| PostgreSQL | 3 | 2 | 4 | 9 |
| AWS S3 | 4 | 4 | 3 | 11 |
| Firebase | 2 | 3 | 2 | 7 |
Hoe gebruik je ondersteunen bij ontwerpkeuzes?
Je gebruikt deze werkwijze in situaties waar meerdere technische of functionele oplossingsrichtingen mogelijk zijn. Denk aan het kiezen van een cloudplatform, een architectuurstijl, of een user interface concept.
Alternatieven voor vastlegging kunnen zijn:
- Ontwerpbeslissingen in ADR-vorm (Architectural Decision Records)
- Onderbouwde user stories met acceptatiecriteria
- Wireframes of prototypes met feedback uit gebruikerstesten
Casus
In een onderwijsapp moeten toetsen offline beschikbaar zijn. Twee opties worden vergeleken: cache via service worker of lokaal opgeslagen bestanden in IndexedDB. De gekozen oplossing (service worker) wordt onderbouwd met een presentatie die de offline scenarios visueel uitlegt.
Volgende stap: Uitleg presenteren aanbevelingen