Bij nieuwe ontwikkelingen passen ingenieurs vaak bewezen ontwerpen toe, al dan niet met kleine aanpassingen. Waarom slagen ze er dan nog steeds niet in om oplossingen te leveren waar klanten om vragen? Meestal is communicatie het grootste struikelblok. High Tech Institute trainer Eric Burgers legt uit hoe SysML helpt om ontwerpideeën voor complexe systemen succesvol te communiceren. Eric Burgers geeft de cursus Inleiding tot SysML en Systeemmodellering met SysML.
In een ideale situatie begint een project met perfecte requirements: ondubbelzinnig, specifiek en precies, en precies genoeg om het op te lossen probleem te beschrijven, met voldoende ruimte voor creativiteit en innovatie. De ontwerpen die aan deze eisen voldoen zijn compleet, specificeren decompositie, gedrag en samenwerking volledig en zijn 100 procent consistent en testbaar in alle opzichten. Uiteindelijk wordt een systeem opgeleverd dat voldoet aan de eisen en het beoogde gebruik.
In een nachtmerrieversie vertrekt een project van inconsistente of tegenstrijdige eisen, met zinnen als “het systeem zal … vergemakkelijken” of “bijdragen aan …”. De systeemgrens is moeilijk te definiëren. Het geheel wordt ontleed in vage componenten, zoals (categorieën van) apparaten of zelfs willekeurige groepen van “dingen”. Gewenst gedrag, indien gespecificeerd, lijkt los te staan van het ontwerp of is feitelijk onvolledig en laat veel ruimte voor interpretatie. In de ultieme nachtmerrieversie van een project wordt een systeem gebouwd dat niet gebaseerd is op het werkelijke ontwerp. Defecten worden gerepareerd door notitie op notitie te stapelen, waardoor het ontwerpdossier een absolute puinhoop wordt. Pas als alles in de juiste volgorde is gelezen, kan het werkelijke ontwerp worden afgeleid.
Boehm’s tweede wet van engineering: tijdens een softwareproject worden de kosten voor het vinden en oplossen van bugs hoger naarmate de tijd verstrijkt.
De meeste projecten zijn geen complete nachtmerries, maar ze zijn ook niet ideaal. Ontwerpen voldoen niet altijd aan alle vereisten en kunnen inconsistenties, weglatingen of andere defecten bevatten. Deze defecten zijn een potentiële bron van faalkosten: defecten die tijdens de analyse van de vereisten of het ontwerp worden geïntroduceerd, worden duurder om te herstellen naarmate ze later worden opgelost. En dat terwijl ze voorkomen hadden kunnen worden.
Dit roept een conflictpunt op: ontwerpen zijn bedoeld om het risico op het bouwen van verkeerde of defecte systemen te beperken, maar toch worden er in projecten heel vaak ontwerpen gemaakt die de eisen van de klant niet weerspiegelen, waardoor het hele doel van een ontwerp teniet wordt gedaan. Hoe komt dit en wat kan hieraan worden gedaan?
''Only when everything is read in the correct order can the actual design be derived.''
Bottom-up benadering
Projecten zijn er in alle soorten en maten en lossen eenvoudige tot uitdagende problemen op. Relatief eenvoudige, kleine projecten zijn niet al te moeilijk om te voltooien. De kans op mislukking neemt toe naarmate een project complexer wordt. De complexiteit van een project is gerelateerd aan de complexiteit (in termen van grootte of moeilijkheidsgraad) van het product dat gemaakt wordt en de grootte van de organisatie die het maakt.
Grote(re) projecten zijn vaak georganiseerd in discipline-specifieke ontwikkelgroepen. Deze groepen bespreken hun interfaces wel met elkaar, maar er is meestal geen overkoepelende aanpak om te beschrijven hoe alle componenten geïntegreerd moeten worden tot één werkend geheel. Soms lijkt het er zelfs op dat interfaces ad hoc worden gecreëerd.
Dit heeft alle kenmerken van een bottom-up benadering, waarbij discipline-specifieke onderdelen eerst worden ontworpen en geproduceerd en vervolgens samengevoegd in de hoop een werkend product te krijgen. Zo’n aanpak kan werken voor minder ingewikkelde projecten waar ingenieurs het hele product met al zijn details kunnen begrijpen. Wanneer onderdelen elkaar echter kunnen beïnvloeden door hun gedrag of eigenschappen, kan het moeilijk zijn om in te schatten hoe het geheel zich zal gedragen, vooral als de bouwstenen uit verschillende disciplines komen.
De risico’s van toenemende complexiteit
Tekeningen
Een manier om met grote, complexe projecten om te gaan is het creëren van uitgebreide documentatie om ontwerpideeën te verspreiden onder alle betrokken ingenieurs. In technische vakgebieden zoals werktuigbouwkunde, software engineering, industriële automatisering en civiele techniek zijn er vaak gestandaardiseerde manieren om dit te doen. In de praktijk wordt documentatie aangevuld met tekeningen gemaakt in populaire tools zoals Powerpoint of Visio (Windows) of Omnigraffle (Mac OS). Daarnaast wordt Excel gebruikt om grote hoeveelheden informatie uit te wisselen.
Bij multidisciplinaire projecten neemt het gebruik van aanvullende tekeningen en andere projectspecifieke hulpmiddelen toe om de kloof tussen de disciplines te overbruggen. In principe is hier niets mis mee; de overdracht van ontwerpideeën en informatie tussen disciplines is hard nodig. Zonder het overbruggen van de interdisciplinaire kloven zal een project op ernstige integratieproblemen stuiten. Projectspecifiek” betekent echter ook steeds opnieuw het wiel uitvinden, vooral wanneer het werk wordt gedaan door consortia die van project tot project wisselen.
Een ander probleem met deze tekeningen is dat er geen algemene overeenstemming is over wat ze moeten voorstellen. Bovendien is er geen garantie dat ze volledig en consistent zijn. Als gevolg daarvan is er een reëel risico dat de tekeningen, hoewel duidelijk voor de auteur, verkeerd geïnterpreteerd kunnen worden door de lezers, wat op zijn beurt leidt tot defecten in het product die pas in een later stadium van het project ontdekt worden.
Heel vaak worden deze manier van werken en de bijbehorende integratieproblemen gewoon geaccepteerd. Naarmate het project de voltooiingsdatum nadert, worden de problemen opgelost door rework of patching, of ze worden gewoon in het project gelaten als “toekomstig werk”. Een alternatieve aanpak is om de communicatie van ontwerpideeën te standaardiseren op project- of zelfs bedrijfsbasis. Dit heeft als nadeel dat de conventies ‘lokaal’ zijn voor het project dat wordt uitgevoerd – elke deelnemer zal ze moeten leren.
Het is zinvoller om een industriestandaard te adopteren, inclusief ondersteunende tools. Dan hoeven de conventies maar één keer geleerd te worden om vele keren toegepast te worden, ongeacht het project of de organisatie. Des te beter als de standaard het mogelijk maakt om documenten en tekeningen te vervangen door één enkele bron van waarheid die altijd up-to-date is.
Modelleringstaal
De complexiteit van projecten, of technologie in het algemeen, neemt alleen maar toe. Denk aan het verschil tussen de eerste telefoons en de smartphones van vandaag. Of vergelijk de eerste auto’s met de voertuigen die vandaag de dag op de weg rijden. Hoewel de hoofdfunctie hetzelfde is gebleven (communiceren, rijden), worden de systemen van tegenwoordig steeds meer geïntegreerd in een groter geheel om gebruikers extra diensten te bieden die niet door de systemen zelf geleverd kunnen worden. Deze trend is geïdentificeerd en beschreven in vele bronnen, waaronder de visiedocumenten van Incose – Visie 2025 en meer recentelijk Visie 2035.
Om de toenemende mate van integratie het hoofd te bieden, stimuleert Incose de overgang naar model-based systems engineering (MBSE). Hierbij worden modellen gebruikt om complexe systemen te ontwerpen en te verifiëren. Een van de eerste stappen in de richting van MBSE is de adoptie van een taal die geschikt is om dergelijke modellen te bouwen. SysML is zo’n taal.
''The complexity of projects, or technology in general, is only increasing.''
Met SysML kunnen verschillende soorten systemen en hun gedrag worden gerepresenteerd, evenals hun interacties met de omgeving.
De Systems Modeling Language (SysML) is een universele modelleertaal die is ontworpen om ingenieurs te helpen bij het ontwikkelen en documenteren van complexe systemen met een groot aantal componenten. De taal wordt veel gebruikt in industrieën zoals luchtvaart, auto-industrie, infrastructuur en defensie. De grafische notatie maakt het mogelijk om verschillende soorten systemen en hun gedrag te representeren, evenals hun interacties met de omgeving. Dit stelt ingenieurs in staat om hun ideeën effectief en efficiënt te communiceren en ervoor te zorgen dat alle betrokkenen in het ontwikkelproces hetzelfde begrip hebben van het te bouwen product. Omdat de taal niet discipline-specifiek is, kunnen systemen op een overkoepelend niveau worden beschreven.
De vier pijlers van SysML
- Structuur: een systeem kan worden onderverdeeld in kleinere onderdelen, die onderling interfaces hebben.
- Gedrag: drie soorten gedrag – flow-gebaseerd, event-gebaseerd en message-gebaseerd – kunnen worden gespecificeerd en aan elkaar gerelateerd.
- Vereisten: systeemvereisten en hun tests kunnen worden gedefinieerd.
- Parametrie: als een systeem eenmaal beschreven is, kan het ook gesimuleerd worden.
Verhoogde precisie
Bij het gebruik van SysML is het eerste wat opvalt dat de ontwerpen nauwkeuriger zijn en dus extra werk vergen. Die precisie zorgt er echter ook voor dat alle betrokkenen de ontwerpen op dezelfde manier kunnen interpreteren als de auteur en dat defecten en omissies veel gemakkelijker te identificeren en te voorkomen zijn. Omdat het bijna onmogelijk is om een inconsistent ontwerp te maken, worden faalkosten vermeden. Als deze kosten hoger zijn dan de initiële investering, is er een business case voor het gebruik van SysML.
Het implementeren van SysML kan overkomen als een ontmoedigende taak. Op het eerste gezicht kan het een behoorlijke uitdaging lijken om een compleet complex systeem om te vormen tot een model dat geschikt is voor analyse en simulatie. In de praktijk verloopt de overgang vaak stapsgewijs en passen organisaties geleidelijk steeds meer SysML toe om ontwerpen te beschrijven. Langzaam maar zeker worden documenten vervangen door modellen of worden ze weergaven op het model, totdat er op de hogere volwassenheidsniveaus helemaal geen documenten meer zijn omdat alle informatie is ingekapseld in modellen.
Omdat SysML een uitgebreide taal is, kost het tijd om alle details onder de knie te krijgen. Een goede training zal de adoptie aanzienlijk versnellen. Engineers zullen zeker ook moeten wennen aan de grotere precisie waarmee ontwerpen vanaf het begin worden gemaakt. Als SysML eenmaal succesvol is ingevoerd, zal het de communicatie en kwaliteit van ontwerpen verbeteren.
Voor specificaties met veel geometrische informatie, zoals vaak wordt gemaakt in de civiele techniek, is SysML minder effectief. De taal leent zich vooral goed voor cyberfysische, software-intensieve systemen. Een goed voorbeeld is een infrastructuurproject in Amsterdam-Zuid, waar de ontwerpen werden gemaakt door de leverancier en beoordeeld door de overnemende partij. Hier resulteerde het gebruik van SysML in een aanzienlijke verhoging van de ontwikkelsnelheid, waarbij het aantal gevonden defecten aanzienlijk lager was dan gemiddeld. Ook elders bewijst SysML dat het nachtmerries kan voorkomen en projecten dichter bij het ideaal kan brengen.
Dit artikel is geschreven door Nieke Roos, techredacteur voor Bits&Chips.
Recommendation by former participants
By the end of the training participants are asked to fill out an evaluation form. To the question: 'Would you recommend this training to others?' they responded with a 7.6 out of 10.
Bekijk de SysML trainingen:
Blijf op de hoogte
Ontvang onze maandelijkse updates
