Hi Bruce,
Full disclosure, I am a systems engineer and like the top-down approach to developing systems. Therefore I am intrigued by MBSE using whatever methodology.
As you know, I started studying the Harmony/SE process and have also studied the Harmony/ESW process. I thought it would be simple to connect the system world with the software world via SysML/UML models in Rhapsody.
However I have seen a pattern with my fellow "embedded software developers". They really don't like Rhapsody and they really don't like UML modeling tools. They think they are clunky, bug-ridden, old and nasty. Many quit their jobs just to avoid it. Software modeling seems to have a bad rep, why is that?
They seem to prefer to document their software requirements and software architecture in tools like JIRA and Confluence or using any combination of office tools drawing UML like pictures, but I know that maintaining consistency an traceability using those concepts will be lost.
Why don't they want to do proper UML modeling in a tool like Rhapsody? Is it because they are fostered in an "Agile" environment that detests "documentation"? Why is this a struggle? What can be done about it?
Maybe. I view myself more as an architect than a carpenter, but if you really just want to be a carpenter, an architect may seem superfluous.
That's a good question, but not one that I face. Mostly, I consult in aerospace, transportation, and medical but only those people interested in modeling seek my help. I see a lot of questionable judgements by software developers from not wanting to include error checking code, to not wanting to actually do design work, not wanting to test their work thoroughly, not documenting what they did, and not tracing back to requirements. In the environments where I work, getting wrong means - quite literally - blood in the streets, so doing a good and thorough job is critically important. "Move fast and break things" isn't a mantra you want for safety critical systems development.