Model Denken: Op elk potje past een dekseltje
Hoewel de titel van deze blog ook andere associaties kan opleveren, gaat het hier over modelleren van functionaliteit. In het geval niet precies duidelijk is welke ondersteuning een proces nodig heeft of welke functionaliteit aan de gebruikers moet worden geleverd, of zelfs met welke diepgang een systeem moet worden getest, er is altijd een model dat het beste past bij het betreffende doel. In dit artikel deel ik zes modellen die helpen om bedrijfsprocessen te ondersteunen.
Waarom zou je model denken?
In eerdere blogs is al aan de orde gekomen dat je met model denken veel interpretatiefouten kan voorkomen. En dat vanuit de gemaakte modellen testgevallen of scripts kunnen worden gegenereerd, maar wellicht nog belangrijker: de modellen vormen een gemeenschappelijke taal! Voordat je begint met het genereren van testgevallen of scripts, kan het model zelf en de beoogde testdekking worden afgestemd met de betrokkenen.
Wanneer welk model?
Er bestaat geen supermodel dat alle belangrijk kwaliteitskenmerken in één keer afbeeldt. Zelfs als je alleen naar de gewenste functionaliteit kijkt, is het ondoenlijk om bijvoorbeeld het procesmatige aspect én de betrokken bedrijfsregels tegelijkertijd in één model grafisch weer te geven. Dus (tip!) hou het eenvoudig; maak meerdere modellen van dezelfde functie! Er zijn veel modeltypen beschikbaar. Hieronder licht ik zes modellen met betrekking tot het kwaliteitskenmerk functionaliteit aan de hand van een voorbeeld toe.
Zes veelvoorkomende modellen
Business Process Diagram
BPD is een grafische weergave binnen BPMN (Business Proces Model and Notation) voor het modelleren van bedrijfsprocessen. Dit diagram toont de interactie van (sub)processen; in welke volgorde, welke aansturing, tijdafhankelijkheid, etc.
Praktisch voorbeeld:
Dit model is uitermate geschikt om ketens van systemen/componenten in kaart te brengen. Vooral als er verschillende (agile) teams en/of leveranciers deel uitmaken van het totale informatiesysteem, is het voor de betrokkenen direct duidelijk met wie de interfaces en afhankelijkheden afgestemd dienen te worden. Eenmaal in kaart gebracht is dezelfde plaat prima geschikt om de testdekking te “onderhandelen”.
Process Flow
Een flow chart (stroomdiagram) is één van de meest gebruikte manieren om een proces op eenvoudige wijze te visualiseren. Hierbij stellen blokjes de stappen voor, diamantjes de beslissingen en pijltjes de volgorde. Hoewel er veel symbolen tot je beschikking staan, is het verstandig om je tot de basissymbolen te beperken en als scope "Eenheid van tijd, plaats, en handeling" te hanteren.
Bron afbeelding: wikipedia
Praktisch voorbeeld:
Dit model is geschikt om de interactie van een actor met een systeem te modelleren. Vooral als je dan per flow chart ook nog (tip!) het principe van eenheid van tijd, plaats, en handeling hanteert zullen veel potentiële interpretatiefouten worden voorkomen.
Toestandsdiagram
Een toestandsdiagram (Engels: state transition diagram) is een schematische weergave van een systeem. Het geeft de verschillende toestanden waarin een systeem zich kan bevinden en de mogelijke overgangen vanuit een toestand naar een andere toestand.
Bron afbeelding: wikipedia
Praktisch voorbeeld:
Door het duidelijke onderscheid tussen de acties (de overgangen) en het resultaat van die acties (de toestanden) zijn uit deze toestandsdiagrammen zeer duidelijke testgevallen te genereren.
Equivalentieklassen
Equivalentieklassen is een dataverzameling waarbij op basis van kennis of specificatie wordt aangenomen dat het gedrag van de functionaliteit hetzelfde is.
Bron afbeelding: solver.com
Praktisch voorbeeld:
Als je snel een regressietest moet inrichten, kun je vanuit de data die door de gebruikers van het systeem wordt ingegeven een selectie (en combinatie) maken.
Beslismodel (en bedrijfsregelset)
Een beslismodel is een model voor een specifiek aandachtsgebied dat antwoord geeft op de vraag "Voor welk alternatief moet de beslisser kiezen?".
Bron afbeelding: Overheid.nl
Praktisch voorbeeld:
Een goed beslismodel bestaat uit minimaal drie lagen:
1) een “marketing” laag waarin voor de doelgroep in herkenbare tekst hun situatie wordt beschreven, en de uitkomst/keuze eenvoudig bepaald kan worden (zie hiernaast),
2) een functionele laag waarin voor de bedrijfsregeleigenaren in strakke duidelijke business begrippen de beslissingen en uitkomsten staan uitgeschreven,
3) een technische laag waarin voor de IT teams de vertaling van de businessbegrippen naar de database/bericht gegevens duidelijk is vastgelegd.
Briefmodel
Een specifieke variant van een beslismodel is het briefmodel waar per alinea of tekstelement is vastgelegd onder welke conditie de alinea in de brief verschijnt.
Praktisch voorbeeld:
Bij (regressie) testen van complexe brieven (denk bijvoorbeeld aan de financiële dienstverlening) - en dan vooral bij brief engines die de brieven genereren op basis van berichten (bijvoorbeeld XML) - zijn de briefmodellen en de gegenereerde testgevallen (inclusief voorspelling van de bijbehorende brief) onmisbaar. Aangezien fouten in de betreffende brieven een wanhoop zijn voor de klantenservice.
Hoe beginnen?
Je zal merken dat een model al heel snel heel complex oogt. Laat je daardoor niet ontmoedigen. Bespreek het resultaat met een aantal betrokkenen en je zal zien dat volgende versies al rap beter worden. Let wel op (tip!), confronteer de anderen niet in één keer met een complex, vol model met tientallen beslissingen: zorg ervoor dat je in staat bent om in stappen de opbouw te laten zien:
- begin met de “happy flow” (het primaire doel),
- vervolgens welke delen voor de alternatieven zorgen,
- en pas als laatste welke beslissingen voor de robuustheid (de uitzonderingen).