Coupling and cohesion

An old concept but still going strong, the important cracks in the MBSE wall to fix is what’s in between; in between the different domains, disciplines, methods and ideas.

To the finish line

Actually worked some during both Christmas and Boxing Day, helping out a friend of mine I had to “re-learn” how to setup an Apache-server, use MySQL with PHP and how to make it all run smoothly together with Netbeans. After getting a friendly tip pointing towards XAMPP it all became a lot easier and some nifty “modeling” on a piece of paper later I took off coding. I’m actually a bit surprised with what I achieved in only two days… which is good since I don’t have a surplus of hours stacked away, but I promised my help and that’s that.

But today it’s Monday again and normal work-day. Been digging through a lot of reading material with regards to SysML and MARTE and the combination of the two without getting a real wow-experience… maybe it is experience, maybe it is cynicism… I don’t know. Well I need to stay positive anyhow, to give it a proper chance.

Tiny can make big

Even though annoying, the small problems sometimes help you find the bigger issues. The last week has been a plethora of small breadcrumb sized mishaps, now the loaf has been found and the satisfaction can’t be denied.

March in December

Later this year I will do a short guest appearance, again, in the Vinnova-funded VCC project March/DFEA2020 so today I’m doing a bit of reading, catching up if you will. One of my recurring concerns in the area of MBSE is that there’s really not that much to catch up to. It still seems as if the prevailing ideas are the top-down approach in some form where either method has their solution to achieve traceability and a “Russian doll” situation.

I’m more interested in what aspects of modeling and systems engineering that will benefit your organization and constantly improve performance. To me most of the large MBSE initiatives/methods are very bulky and impose a clear and present risk of putting a lid on engineering and innovation.

Some random questions I find interesting:

How do you move focus from verification to validation? The ability to do trial and error, short prototyping loops etc. are vital, what do you need to support this?

How do you push “decision power” closer to the problem? With an over-weight top-down approach this is impossible. How about creating a more loosely coupled architecture based on patterns and some well-placed poles in the ground designed to keep the solution within acceptable boundaries compared to important attributes?

If you product is multi-faceted you will be using different tools and languages to describe it (don’t try to dig with a fork if you have spoon), how can you provide aid to minimize hand-offs, or at least confusion in hand-offs? Instead of attacking traceability you might need to start in a different end, to really understand the information need and information structure in your organization.

If you are implementing parts of the system in-house you want to give the SW-department the best possible pre-requisites in order to do their job, how can we do the same for those parts developed by suppliers? Can models help us increase transparency where needed in our supplier communication?

Models instead of documents push towards construction and engineering, if our organization has started to lose touch with those disciplines we are in danger of applying Models Based Systems Drawing instead. How can we mitigate that imminent risk?

And why is it that it is so rare to find the notion of a lean or agile mindset in conjunction with MBSE? If we want to run our implementation according to agile principles we need to understand the implications and changes in approach needed when it comes to architecture, integration, systems engineering etc.