Wat is controle op de toepassing van ontwerptechnieken?
Controle op de toepassing van ontwerptechnieken verwijst naar het beoordelen of gekozen technieken en modellen correct, volledig, consistent en doelgericht zijn toegepast binnen het ontwerp. Het doel is om zeker te stellen dat het ontwerp valide is, goed aansluit op de eisen en bruikbaar is voor implementatie, testen en onderhoud.
Casus
Een team gebruikt UML-diagrammen en wireframes om een nieuw portaal te ontwerpen. Tijdens een review constateert een tester dat de wireframes bepaalde foutmeldingen tonen, terwijl deze niet terugkomen in het sequentiediagram. Na controle blijkt dat er onvolledige afstemming is tussen de modellen. Door deze inconsistente onderdelen te corrigeren en de traceerbaarheid te verbeteren, worden fouten in de implementatie voorkomen.
Hoe zit controle op de toepassing van ontwerptechnieken in elkaar?
De controle vindt meestal plaats tijdens reviews en validatiesessies en omvat meerdere kwaliteitscriteria:
Correctheid
De modellen moeten correct zijn toegepast volgens de regels van de gebruikte techniek (bijv. UML-syntaxis, correcte relaties in ERD’s).
Consistentie
De gebruikte modellen moeten onderling consistent zijn: termen, componenten en gedrag mogen niet tegenstrijdig zijn. Consistentie speelt op meerdere niveaus:
-
Binnen het model zelf: Alle onderdelen van een diagram moeten logisch op elkaar aansluiten. Attributen, methodes en relaties moeten elkaar versterken en niet tegenspreken.
Voorbeeld: Een klasse in een UML-diagram heeft een attribuut
status, maar in de methodes die erbij horen wordt nergens verwezen naar dezestatus. Dit veroorzaakt verwarring over het gebruik van dat attribuut. -
Tussen verschillende modellen: De verschillende diagrammen en modellen die samen het ontwerp vormen moeten dezelfde termen en structuur aanhouden, zodat ze elkaar aanvullen in plaats van tegenspreken.
Voorbeeld: In een klassendiagram wordt een component
LoginServicegenoemd, terwijl in het sequentiediagram dezelfde componentAuthenticationManagerheet. Deze inconsistentie belemmert de traceerbaarheid. -
Tussen model en toelichting: De begeleidende tekst en toelichtingen moeten overeenkomen met wat in de modellen visueel wordt weergegeven.
Voorbeeld: In de tekstuele toelichting staat dat een gebruiker via een formulier meerdere documenten kan uploaden, terwijl het wireframe slechts één uploadveld toont. Dit verschil leidt tot misverstanden bij implementatie of testen.
Volledigheid
Het ontwerp moet alle vereiste aspecten van het systeem dekken, inclusief hoofd- én uitzonderingsstromen, systeemgedrag en interfaces.
Traceerbaarheid
Elke component of stap in het ontwerp moet te herleiden zijn naar een eis of behoefte, bijvoorbeeld via een traceability matrix of links naar use cases.
Hoe gebruik je controle op de toepassing van ontwerptechnieken?
Controle op de toepassing van ontwerptechnieken wordt uitgevoerd tijdens verschillende fasen van het ontwikkelproces. Dit gebeurt meestal iteratief, met aandacht voor correctheid, consistentie, volledigheid en traceerbaarheid. De controle draagt bij aan de kwaliteit van het ontwerp en voorkomt fouten in latere fasen zoals implementatie of testen.
SCRUM
Binnen SCRUM wordt gewerkt in korte sprints, waarbij regelmatig evaluatiemomenten plaatsvinden zoals sprint reviews. Tijdens deze momenten wordt het ontwerp besproken en beoordeeld. Controle gebeurt hier:
- Tijdens de refinement van backlog items (bijvoorbeeld bij technische uitwerking van een story)
- In de sprint review waar opleveringen worden gevalideerd
- Tijdens technische reviews door het team zelf
SCRUM legt de verantwoordelijkheid voor ontwerpcontrole bij het hele team, waarbij feedback cyclisch wordt verwerkt.
SSDLC
Binnen de Secure Software Development Life Cycle (SSDLC) is ontwerpcontrole structureel ingebed. Hier wordt bij elke iteratie van het ontwerpproces gecontroleerd op consistentie met eerdere fasen (zoals requirements), met name vanuit het oogpunt van veiligheid, onderhoudbaarheid en volledigheid. In SSDLC worden bij elke fase validatie- en verificatiemomenten ingebouwd. Denk aan:
- Validatie van architectuur en ontwerpmodellen met stakeholders
- Traceability tussen requirements, ontwerp, testcases en code
- Gebruik van formele reviewtechnieken (zoals checklist-based reviews of pair design).
Checklist-based reviews
Bij een checklist-based review gebruiken reviewers een vooraf opgestelde lijst met controlepunten (checklist) om systematisch een ontwerp (of stuk code) te beoordelen.
Doel: Zorgen dat belangrijke kwaliteitsaspecten niet over het hoofd worden gezien.
Voorbeelden van checklistvragen:
- Zijn alle use cases voorzien van een unieke ID?
- Zijn de UML-diagrammen consistent met de tekstuele beschrijving?
- Zijn alle requirements herleidbaar naar een onderdeel van het ontwerp?
- Is er rekening gehouden met foutafhandeling?
Voordeel:
Consistent, reproduceerbaar, geschikt voor teams met wisselende ervaring.
Pair design
Pair design is een samenwerkingsvorm waarbij twee ontwerpers (vaak een developer en bijvoorbeeld een architect of tester) samen een ontwerp maken of beoordelen.
Doel: Directe feedback en kennisdeling tijdens het ontwerpproces.
Hoe werkt het?
- Eén persoon ontwerpt, de ander denkt kritisch mee.
- Rollen kunnen wisselen (zoals bij pair programming).
- Vaak ingezet in vroege fases van ontwerp, bijvoorbeeld bij het opstellen van een architectuur of bij het modelleren van use cases.
Voordeel:
Stimuleert kwaliteit, discussie en gedeeld begrip. Je ontdekt sneller inconsistenties of ontwerpkeuzes die anders onopgemerkt blijven.
Casus
Stel: je ontwerpt een applicatie voor een boekensysteem. De requirements zijn uitgewerkt in use cases.
Eisen:
- Elke use case moet gekoppeld zijn aan een requirement.
- UML-diagrammen zijn verplicht voor communicatie tussen modules.
- Alle alternatieve scenario’s moeten getest kunnen worden.
Volgende stap: Uitleg ondersteunen bij ontwerpkeuzes