MBSE Processes & Methods Compatible with SysML

The following is a selected list of Model-Based Systems Engineering (MBSE) methods and processes that either explicitly refer to SysML diagrams as work artifacts, or are modeling language neutral and can be adapted to SysML usage. The methods and processes listed are subdivided into Rigorous (a.k.a. Robust or Heavyweight) and Agile (a.k.a. Lean or Lightweight) process categories, where the former focus on the scaleablity issues associated with larger teams (e.g., 15+), and the latter emphasize streamlining the efficiency of smaller teams (15 or fewer).
Q: What is the difference between a terrorist and a methodologist? A: You can negotiate with a terrorist.Anonymous
Please contact us regarding any additions or corrections to be made to this page.

Rigorous ("Heavyweight") MBSE Methods/Processes
  • Unified Process variants (Open Source & Commercial)[+]
    The Unified Process (UP) is a popular iterative and incremental software development process framework that has many variations and refinements. UP variations include, but are not limited to the Open Unified Process (Open UP; open source), the Rational Unified Process (RUP; commercial), and the Rational Unified Process-System Engineering (RUP-SE; commercial). Although RUP-SE is the UP variation that purports to be tailored for System Engineering applications, a Google search for RUP-SE work artifacts indicates that it is not undergoing active development and it has not yet been updated to support SysML work artifacts. Consequently, your MBSE team may be better off customizing another UP variant (e.g., OpenUP) for your team and project needs.
  • Harmony-Systems Engineering (Harmony-SE)[+]
    Harmony-Systems Engineering (Harmony-SE or Harmony/SE) is a Model-Based Systems Engineering process that uses work artifacts supported by the UML and SysML modeling languages. Harmony-SE was originally specified by Hans-Peter Hoffman, the Chief Systems Methodologist at Telelogic. IBM Rational Harmony™ for Systems Engineering is a commercial process offered with optional tool support.
  • OOSEM[+]
    The Object-Oriented Systems Engineering Method (OOSEM) was introduced in 1996 and there is an INCOSE OOSEM Working Group to further its progress. However, after over wo decades of "development" with sparse documentation (white papers, academic papers, and a book chapter), no clear specification of the OOSEM is publicly available. So if you are seeking a mature, proven MBSE process you should continue your quest.
Agile ("Lean") MBSE Methods/Processes
  • OpenUP (Open Unified Process)[+]
    The Open Unified Process (OpenUP) is a part of the Eclipse Process Framework, an open source process framework developed within the Eclipse Foundation. Its goals are to make it easy to adopt the core of the Unified Process. OpenUP preserves the essential characteristics of Unified Process, which include incremental development, Use Cases driving development, and an architecture-centric approach. Although OpenUP tends to be software-centric, it is open source it can be customized to address MBSE team and project needs.
  • Agile Modeling Methods[+]
    Agile Modeling methods refer to streamlined approaches for applying visual modeling techniques to software-intensive system development. Agile Modeling methods typically emphasize using a pragmatic subset of UML or SysML diagram types and techniques that are strategically applied to produce critical work artifacts Agile Modeling methods are intended to be compatible with Agile software development methods, such as Scrum, Crystal, etc.

    For example, consider a team of Systems Engineers and Software Engineers applying Agile Modeling methods to a project where the Software Engineers are applying the Scrum method and are working in Sprints (short increments between project checkpoints). In order maintain the speed and flexibility of Scrum Sprints, the Systems Engineers may choose to use only three of the nine SysML diagrams (e.g., SysML Requirement, Block Definition, and Activity diagrams), and the Software Engineers may restrict themselves to only four of the fourteen UML2 diagrams (UML Class, Sequence, Component, and Deployment diagrams), ensuring that traceability mappings between the mixed SysML-UML diagram type usages are defined precisely via Allocation Dependency relationships.

OMG SYSML, UML, and UNIFIED MODELING LANGUAGE are trademarks of the Object Management Group. All other product and service names mentioned are the trademarks of their respective companies.