Het hoe en wat van modelleren
Bij KienIA maken we steeds meer gebruik van Model Based System Engineering (MBSE). Dit houdt in dat we model based werken in plaats van document based. We werken niet met losse documenten, maar leggen informatie uniform en duurzaam vast in systeemmodellen. Modelleren wordt dus een steeds belangrijker onderdeel van ons werk. Maar, wat is nu precies een model en in welke gevallen is modelleren een must? Collega Herman Battjes neemt je hierin mee.
Herman: “MBSE doe je met een doel, namelijk: het realiseren en/of beheren van een systeem. Een model maak je om jouw doel te bereiken. Zo kon een model die informatie bevatten die noodzakelijk is om het systeem te realiseren en/of te beheren. Zet je meer informatie in een model, dan verlies je jouw doel uit het oog. Vraag je dus goed af welke informatie voor jou noodzakelijk is. Deze noodzakelijke informatie kan overigens nog steeds best omvangrijk zijn. Je kunt hierbij denken aan informatie over systeemonderdelen of -functies, interfaces, maar ook aan verificatie of projectmatige zaken zoals planning, budget of features (Scrum). Als de informatie maar nodig is voor tenminste één stakeholder. Informatie kan ook nodig zijn om zelf overzicht te krijgen. In dit geval heeft de informatie waarde voor jouzelf. Een model heeft hierbij het voordeel dat al deze informatie gecentraliseerd is en één bron van waarheid kent. Dat is hét grote verschil met document based werken.”
De views bepalen
Op basis van de noodzakelijke informatie bepaal je jouw manier om naar een systeem te kijken. Dit wordt een ‘view’ genoemd, als het ware een snapshot van een deel van je systeemmodel. “Dit kan een opdeling van het systeem zijn in eisen, verificatiestatements, enzovoorts”, legt Herman uit. “Een view geeft verschillende modelelementen rondom een thema weer. Bijvoorbeeld een samenstel van systeemdelen, een overzicht van signalen naar een extern systeem, of functies die gerelateerd zijn aan eisen. Je bepaalt jouw view aan de hand van een viewpoint. Een viewpoint geeft aan voor wie (welke stakeholders) en waarom (welke waarde) een view wordt opgesteld. Hieruit volgt dat iedere view waarde moet opleveren voor tenminste één stakeholder. Je wilt bijvoorbeeld voor een contractmanager alle eisen op een rij zetten of laten zien of deze eisen wel of niet geverifieerd zijn.”
Herman maakte bovenstaand schema, gebaseerd op het schema ‘MBSE in a slide (and a bit)’ BRON van professor John Holt. Tot nu toe bespraken we het middelste gedeelte van het schema: het systeem en systeemmodel zelf. Daarbuiten bevinden zich aan de linkerzijde van het schema de aanpak en de compliance, die ook beiden invloed hebben op het systeemmodel. Hierbij kun je denken aan het volgen van een best practice of de benodigde informatie om aan te tonen dat je systeem voldoet aan de machinerichtlijn of cybersecurity-richtlijnen.
Visualiseren om te communiceren
Visualisatie en communicatie zijn aan de rechterzijde weergeven in het schema als factoren die invloed hebben op het model. Een model heeft namelijk geen waarde als het niet gevisualiseerd én gecommuniceerd kan worden aan de stakeholders. Herman: “Een model is leuk, maar het is vooral ook een gigantische database. Dit kan interessant zijn voor andere databases en machines, maar voor mensen is het minder interessant. Wij willen iets kunnen zien: een diagram, plaatje of matrix. En daarmee verbanden kunnen zien tussen functies en systemen, eisen en systemen of een lijst met alle systeemonderdelen. Deze visualisatie moet je bovendien ook anders kunnen presenteren, bijvoorbeeld in een document, tekening of dashboard. Zo kun je gemakkelijker communiceren en kunnen mensen ook buiten het model met de informatie aan de slag.”
Helemaal rechts in het schema is de implementatie het laatste onderdeel dat invloed uitoefent op het uiteindelijke model en systeem: het softwarepakket. “Dit kan een uitgebreid pakket zijn, maar bij een klein project bijvoorbeeld ook Word of Excel.”
Hoe moeten we modelleren?
Bij KienIA zijn we ook uitstekend in staat om het doel van een model, de noodzakelijke informatie en beste view te bepalen. En daarbij ook om het model aan de hand hiervan verder vorm te geven. “Hierbij onderscheiden we ons door onze adviesaanpak, door goed mee te denken met de klant en omdat we onafhankelijk zijn van leveranciers”, vertelt Herman. “Modelleren zit bij KienIA in het DNA. Binnen veel projecten maken we bijvoorbeeld direct een snelle tekening om het systeem te beschrijven. Ook dat is modelleren! Wat mij betreft is de vraag dan ook niet: moeten we modelleren, maar hoe moeten we modelleren? Zolang je maar weet wat voor informatie je nodig hebt!”