By paul ~ December 2nd, 2008. Filed under: Industry, Systems Engr..
Over the Thanksgiving break (Merry Christmas, everybody!), I settled down with a warm cup of cocoa and the 70 page Survey of Model-Based Systems Engineering (MBSE) Methodologies (Rev. B) document by the INCOSE MBSE Focus Group. It’s a bit of a slog, but there’s lots of good information in there. I’m still trying to process it all.
The paper discusses Lifecycle Development Models, SE Process Standards and Capability Models, Mathematical Foundation of MBSE (A. Wayne Wymore) and then plunges into the survey of leading MBSE methodologies. These include IBM Telelogic‘s Harmony-SE, INCOSE’s Object-Oriented Systems Engineering Methodology, IBM’s Rational Unified Process for Systems Engineering (RUP SE) for Model-Driven Systems Development (MDSD), Vitech’s Model-Based System Engineering (MBSE) Methodology, JPL’s State Analysis (SA), and Professor Dori’s Object-Process Methodology (OPM). The paper finishes with a sections on the roles of UML/SysML, MDA, and Executable UML in MBSE. Kudos to INCOSE & Jeff Estefan of JPL who put this all together! It’s a great service to the community.
I thought that the defnition of Model-Based Engineering was excellent:
In a nutshell, model-based engineering (MBE) is about elevating models in the engineering process to a central and governing role in the specification, design, integration, validation, and operation of a system. For many organizations, this is a paradigm shift from traditional document-based and acquisition lifecycle model approaches, many of which follow a “pure” waterfall model of system definition, system design, and design qualification. One of the biggest communication barriers that exists between the traditional engineering design disciplines (including the discipline of systems engineering) and MBE is that in a model-based process, activities that support the engineering process are to be accomplished through development of increasing detailed models. Skipper suggests that this communication chasm has existed for years and many managers and practitioners still do not identify with the fact that various MBE process models and supporting methodologies are intended to show emphasis rather than be purely waterfall, and that the entire system model grows over time (see Figure 2-9). (Joseph Skipper, Jet Propulsion Laboratory (private communication), Apr. 6, 2007.)
Over more than ten years of attempting to communicate the value of model driven systems engineering, I’ve observed the same issue. There is still a predominant view among systems engineering teams that modeling is some kind of adjunct activity that is undertaken either for documentation or ad-hoc problem solving purposes. The result is that the systems engineering community, and the systems they design, are realizing only a small fraction of the potential benefit.
I think some of this is due to organizational behavior, as well. I’m reminded of a Dilbert cartoon that showed Dilbert bringing a cost saving proposal to his pointy-haired boss. The proposal showed a $1M savings to the company for a $10,000 cost. The boss asks “Who’s budget is the savings going to?” Somebody else’s. “Who’s budget is the cost coming from?” Yours. The decision? “Can’t do it, too expensive!”
The cost that we’re concerned about isn’t the cost of the tools. That’s peanuts. It’s the cost of doing this “other work” that isn’t perceived to contribute directly to the core “engineering process.” After all, we’re always over budget and behind schedule before we start. How can we change our thinking? Something you’ll continue to hear me emphasize in this forum is the value and necessity of using Model Driven Systems Engineering. Hopefully, you’ll also hear some stories and see some practical examples that take some of the fear out of the whole idea.
Sadly, you won’t find the Foresight methodology in Rev. B. We’ll lobby to get it included in Rev. C but, until then, you can find it summarized in my post Why is Model Driven Systems Engineering So Important?
You’ll find a great deal of commonality in all of the methodologies. Personally, I find this encouraging. It means we truly are talking about the same thing from a fairly common perspective. The terminology used is a little different. Some of the underlying mechanisms and modeling languages are obviously very different. But the goals are the same. I think the future is bright for Model (Driven/Based) Systems Engineering, and I hope you’ll join me in contributing to the growth in practice of this discipline!