Systems Thinking

What is systems modelling? At what level of thinking is MBSE done? Let’s take the analogy of the Game of Chess.

As a Pawn, I may think that I understand the game. I can see all the other players on the board (well most of them but sometimes I have to stretch). I know the moves each can make. But, as the Pawn, do I understand everything that is in the Chess players head? Well, I’m not sure. There’s the whole bigger picture about the current game-plan, the strategies like Fool’s Mate and the Fortress Endgame, the tactics for countering the opposition, and fooling the opposition.

As the Chess Master in a game I see the bigger picture, the tactics and the plan, I’m at a different level of abstraction. Both levels of viewpoints are abstraction, of course, and both valid. However, I can do things and see things at the system level that are not possible at subsystem level. Then there’s the question about why the Chess board is like it is? Does every Chess Master understand why Chess is like it is? Well, probably, but imagine they don’t. Imagine Chess was not invented and were trying to come up with a game. What characteristics do we want the game to have? Perhaps we want a game between two players, a game that mimics the tactics of battlefield, a game of cunning, a game that has evolved from other games...

All these levels of abstraction are valid. They are all about the same system. However, they are at different levels of abstraction. This is one view of what successful modelling can provide, if you embrace systems thinking. Of course, there are other views of MBSE but for me the trick is to have multiple views that are all valid and all useful with no duplication. That's an art not a given.

Rhapsody Tip #4 - Applying format using a stereotype (Simple)

This basic-level technique I use all the time. I've seen many engineers make great use of it. The most recent example was a requirements engineers who wanted to differentiate 'User Interface' requirements from other requirements on the same diagram so that the guy from the HMI team could pick them out with ease. Another example is for «abstract»  use cases. By making the text Italic and shading them I can place more focus on the concrete use cases.

Interesting Automotive MBSE paper related to Ford

I really like hearing about real-world usage and lessons learnt. Christopher Davey's paper from an INCOSE 2013 (USA) MBSE Workshop on Jan 26-28th is interesting. It talks about Automotive MBSE at Ford (EE Systems). The PDF is on the OMG Wiki.

"These forcing functions lead to the need to support a HYBRID MBSE environment that consists of a set of modelling tools with associated style guides, maturity levels, completeness levels" (p33) is what I took away; particularly when it comes to reconciling the different worlds of PLM BOM-centric vs SysML/UML/Software is-the-future ;-)

Rhapsody Tip #3 - Deleting Events and usages in one step (Advanced)

This super short video shows how it's possible to use a custom Helper written in Java to automate the deletion of Events and related EventReceptions and diagram references. Helpers like this can simplify usage in increase a team's productivity by removing repetitive tasks.

This helper is part of the toolkit delivered with the training we offer.

How soon do I need tool-specific vs non-tool training/consulting?

The adage that “tool-training is not necessary” is sometimes aligned to the propensity to believe that "the production of diagrams is more important than the engineering content behind them". The reality is that the sooner you get you engineers focused on the latter, the better. It's my experience that this naturally happens if you remove questions about how to use the language and the tools by delivering tool-specific SysML training.

It’s not uncommon to go into companies who have been trying to use Rhapsody and SysML for 1-2 years without training. They think they don’t need it. They believe they are doing OK but you see immediately that they are exploiting only a fraction of the tool and languages’ capability.

Contrast this with those who do the training at the start of their journey. If you do training at the start, you start with relative expertise and understanding of what can be achieved. Empowered with knowledge you make better choices sooner. By unlocking the potential from the start this helps to show to everybody what can be achieved with a few clever choices. People will bow to your superior knowledge. Everybody will want to be part of it. Because you’ve done the training, you now understand that training is valuable. You ensure that training is included in tool deployment. People naturally end up focusing on the engineering issues and problems, not on how to use the tool or exploit the language, and the circle is complete. Well, at least, that's the hope ;-)

Rhapsody Tip #2 - Allowing spaces in names (Intermediate)

This quick tip video shows how you can use the NamesRegExp property in IBM® Rational® Rhapsody® to relax or change the naming rules. For example, to allow spaces or special characters in element names of things that it would not normally allow.

This can also be useful for action names; particularly when we sync them into Rational DOORS® using the Rhapsody Gateway add-on.

Rhapsody Tip #1 - Using the Alt key when resizing (Simple)

Here's a simple Rhapsody usage tip for you: If you want to re-size a container without re-sizing the elements inside it, then just hold down the Alt key first.