Model Based Development

Om model based development (mbd) goed uit te kunnen leggen moeten we terug naar de Jaren 80 en 90 van de vorige eeuw. Destijds kwamen de eerste hulpmiddelen voor systeemontwikkeling op de markt die het informatieanalisten (nu business analisten) het makkelijker maakten om o.a. stroomdiagrammen te tekenen en de betekenissen van elke stap vast te leggen. Deze hulpmiddelen heette CASE-tools. CASE staat voor Computer Aided Software Engineering.

startschermDeze zogenaamde case tools had je in twee soorten:

  • • Upper Case tools: de hulpmiddelen voor business analisten
  • • Lower Case tools: de hulpmiddelen voor programmeurs.

In de Upper Case tools legde je schematische werking vast in bijvoorbeeld een programmastructuur diagram of een dataflow diagram en met de lower case tools kun je dan op basis van die diagrammen de code laten genereren in bijv. C++ of Cobol.

Tegenwoordig zijn de Upper- en de Lower Case tools met elkaar geïntegreerd en kunnen ze veel meer vastleggen dan alleen de schema’s, al is dat nog steeds wel een wezenlijk onderdeel van het systeem. Bij MBD leg je dus niet alleen de structuur vast maar ook de interne werking en op basis van die parameters wordt een system gegenereerd.

Een opmerking van tevoren, in dit stuk wordt uitgelegd wat MBD is en welke valkuilen je tegen kunt komen wanneer je kiest voor een MBD-traject, het artikel geeft niet aan welke MBD-oplossing de beste is en welke MBD-oplossingen er zijn.

Tot zover de geschiedenis, nu naar de realiteit. Om uit te leggen hoe MBD werkt gebruik ik vaak de analogie met het bouwen van een huis.

Het ontwerp.

Bij het bouwen van een huis ga je van tevoren het gesprek aan met de architect (lees: business analist) en leg je wast wat voor een soort huis je wil, het aantal kamers, waar de leidingen lopen en de stopkontakten zitten (de interfaces), etc. Dit legt de architect vast in een ontwerp en op basis van dit ontwerp gaat de aannemer aan het werk en levert je een casco huis op.

In de IT gaat het eigenlijk niet anders je praat met een requirements engineer (Business Analist) die legt je eisen en wensen vast in een model en de programmeur genereert op basis van de specificaties de code en daarmee het ontwikkel systeem.

Er zijn diverse manieren van het vastleggen van het systeem in een model:

  1. De flowchart;
  2. Business Rules;
  3. State-Transition Diagram;
  4. Mind Maps;
  5. Use Case Models;
  6. Entity Relationship Diagrams;
  7. Programma Structuur Diagrammen
  8. Pseudo-Code;
  9. Etc.

Het eerste gebruik.

Als je dan als gebruiker het huis nader gaat bekijken kom je erachter dat er geen building-a-house-ideas-building-house1voordeur en achter deur is, er zijn geen ramen, en er is alleen koud water. Als je de aannemer hierop aanspreekt zegt hij, maar die dingen stonden niet in de specificatie en dus volgt er een dure herstel slag.

Zo ook bij het informatiesysteem, je kunt je immers voorstellen dat een systeem dat in meerdere programmeertalen code moet genereren dat niet op de meest effectieve en efficiënte wijze voor iedere afzonderlijke taal doet. Het maakt in de IT nogal uit of je praat tegen een Oracledatabase of tegen Microsoft Database dan wel een IBM-database. Dus ook hier zal je herstel acties uit moeten voeren om het systeem in de modus te krijgen die de gebruikersorganisatie acceptabel vindt.

Valkuilen

Net als bij ieder ander systeem ontwikkel traject zijn er valkuilen:

1. Requirements zijn niet alleen het wat maar ook het hoe en wellicht nog belangrijker wat er niet mag. 

In tegenstelling tot reguliere systeem ontwikkel trajecten moeten de requirements bij MBD-trajecten niet alleen vast leggen wat er met gegevens moet gebeuren maar ook hoe er mee om gegaan moet worden en wat er niet mag gebeuren

Analisten in traditionele trajecten zijn heel goed in het vastleggen van de werking van functies, zij leggen dan met name vast wat een functie moet doen. Bij MBD is niet alleen de wat vraag belangrijk om beantwoord te krijgen, maar moet er ook een antwoord gegeven worden op de vraag:

  • Hoe moet de functie aangeroepen worden;
  • Hoe gaat het systeem om met foute invoer;
  • Hoe vaak per dag, per uur, per minuut wordt een functie aangeroepen;
  • Hoe wordt de functie gebruikt (Batch, online, op een tablet, op een desktop).
  • Etc

Als analist moet je dus ook bewust zijn van de omgeving waar in het systeem gaat werken en welke consequenties dit met zich meebrengt.

2. MBD lijkt te beloven direct een bruikbaar product te realiseren.

MBD lijkt te beloven dat je een direct bruikbaar product krijgt wanneer het gegeneerd wordt, maar wees je bewust van de consequenties die een gegenereerd systeem met zich mee brengt. Een code generator genereert code op basis van zijn input parameters, wanneer deze incorrect blijken te zijn, kun je een systeem krijgen die precies het omgekeerde doet van wat de gebruikersorganisatie verwacht dat het doet. Elk systeem of het nu gegenereerd is of niet moet getest en, geverifieerd en gevalideerd worden om de gebruikersorganisatie ervan te verzekeren dat wat zij verwachten dat het systeem zou moeten doen, dat het systeem dat ook doet.

3. MBD is vaker niet flexibel dan wel

De hele systeem ontwikkel wereld staat bol van adaptiviteit, flexibiliteit, scrum en agile. Allemaal termen die duiden dat we verwachten dat systeem ontwikkel tools om moeten kunnen gaan met voortschrijdende en veranderende inzichten. Een MBD-oplossing zorgt er eigenlijk voor dat de requirements in beton zijn gegoten op het moment dat het systeem wordt gegeneerd.

4. De rollen in het projectteam zijn niet traditioneel

Bij een traditioneel systeem worden de rollen van de programmeur en de tester op een klassieke wijze ingevuld. Dit houdt in dat een programmeur een systeem in elkaar codeert en een tester op basis van de functionele ontwerpen zijn testen realiseert. Je kunt je indenken dat een systeem dat gerealiseerd is op basis van een model, dat die ook werkt zoals in het model is weergegeven. Een tester zal dus veel meer moeten focussen op non-functionele requirements dan op de functionaliteit en een programmeur zal veel meer aan procesoptimalisatie moeten doen dan dat hij feitelijk code aan het kloppen is.

5. Een plaatje zegt niet altijd meer dan 1.000 woorden

Het spreekwoord zegt: een plaat je zegt meer dan 1.000 woorden echter bij het ontwikkelen van informatiesystemen met behulp van MBD moet je je als opdrachtgever niet altijd focussen oflowchartp het gegenereerde plaatje (schema), want niet alles is vast te leggen in een schem

 

a. Je kunt je voorstellen dat sommige requirements beter vast te leggen zijn in een business

 

rules of pseudo code en dat andere requirements juist zich weer wel lenen om in een schema vast gelegd te worden. Focus je dus niet alleen op het plaatje maar ook op de tekst die bij de stappen hoort wordt daar uitgelegd wat een stap inhoud en wanneer je dit ook nog begrijpt dan is de juiste modelleerwijze gekozen anders zal er toch echt een andere gekozen moeten worden.