fredag 6 november 2009

MBSE. Why?

I've been discussing this question a bit during the week with regards to a presentation in the making. The presentation high-lights a, I would say, successful project we’ve been running at Know IT TM where we push an organization towards model based engineering. However, the presentation will fall quite flat if we can’t agree that a push in that direction is of good and not evil.

So yesterday, during the long Win7 installation, I scribbled a lot of comments on a piece of paper, analog, compiling my own thoughts with the good suggestions I got from my colleagues. The process was quite swift and I haven’t read the paper so not sure if they are good or bad… but hey, if they are stupid ideas I can count on YOU correcting me so I learn the right path, or?

As you know, good ideas are only good until someone finds a flaw.

So let me write down what’s on that paper, I will not edit it, where’s the fun in that?

------------------------------------------------
Why MBSE?

+ Ability to spread knowledge and increase understanding
+ Increased transparency in solutions when they are not hidden in bulky text
+ Simplified handovers
+ A shift in focus from documentation towards design/engineering
+ Simplified communication towards suppliers
+ With MDA added you can use automated transformations to navigate through your solution
+ Executable/Testable models will give you the possibility for earlier verification loops (and if we work with executable models for both design &simulation we will avoid inconsistencies)
+ Ability to structure your information in a better way
+ Improved reusability (reusing a model beats cut/paste text)
+ Decreased lead-time in system design – hopefully

You might increase your quality… but that really depends and is not a given.

- You might remove a lot of freedom from the supplier, compare to build-to-print. This can of course be a good thing but can also be strange if you ask your supplier to dazzle you with innovation and then you handover a finished design. There are a lot of different use cases with this respect and a lot of angles so let’s just agree that when introducing MBSE you have to consider this aspect.
- Initial cost educating everyone in modeling
- Moving focus towards engineering/design will show potential weaknesses in staffing (which is good) and addressing it will be painful
- To move towards MBSE can be costly and difficult depending on how you address it


Some general points with regards to an MBSE introduction…
* Choose where to start and realize that you can build Rome in one day… everything will not fall into place immediately.
* Consider decentralized modeling (conquer the world one island at a time) but use coaches that are controlled centralized (can e.g. be your architects if they are proficient in MBSE).
* Don’t “over model”. You can model in infinity if you want get every last detail perfect.
* Engage everyone in a design team so the model isn’t a product of just one person but a collective effort
* Setup work-shops where different disciplines come together around the design model (e.g. get the early comments from your A&V-team… and at the same time increase the A&V-team’s knowledge about the system)
* The coaches/architects need to “push” themselves out in the organization but prepare for a “pull” mentality when things start to get settled
* Let architects find patterns etc to solve problems that emerge in multiple systems

------------------------------------------------

That was that. Win7 is installed and good to go. There’re a lot of different opinions about Windows but it is quite awesome that you can upgrade your OS in 30 minutes without as much as touching the computer… and it works flawlessly for so many different hardware setups. Compared to the embedded world it is remarkable.

Inga kommentarer:

Skicka en kommentar