All posts by steven

IBM Doors Next Generation: Are diagrams a gateway for new modelers?

Sometimes engineering methods fail because they are not understood or too hard to try and integrate into established habits.   In my experience, Model Based Engineering approaches sometimes never take off because of these types of ‘barrier to entry’ problems.    In this post I want to share how IBM’s Doors Next Generation may be onto something with their integrated support for ‘diagrams.’

Typical Scenario

A scenario I have experienced multiple times is a team or group already has their established tool chain, and there is little time, room, expertise or interest in adding yet another tool to the mix.

Now, if one of these tools already supports a Model Based Engineering approach, then you are done.  Start modeling.

Which leaves you with two typical routes:

  1. Use another tool for modeling, or
  2. Use another tool for diagraming (e.g. Visio, PowerPoint)

And the majority of my experiences involve an optional, diagraming approach.

Doors Next Generation & Diagrams

So why not just bring the diagram into the Lifecycle Management web client?  Aside: And I am using Lifecycle Management to represent Product Lifecycle, Collaboration Lifecycle or Application Lifecycle Management.

This is what IBM Rational DOORS Next Generation (DNG) did. Take a look.

A colleague recently gave me a DNG demo, which showed the diagramming approach has aspects of the UML notation and may support having a model library of sorts.  But I suspect this is more of a ‘diagram’ than a ‘model.’

But, does it matter?  If many times people turn to an additional hoop to jump through only to model something that is disconnected from the rest of the Lifecycle Management, why not work with a diagram that is integrated with the Lifecycle Management tool chain?

Beyond Diagrams

As I understand it, IBM has an offering to those who want to take a Model-Based-Engineering or Model-Driven-Engineering approach.  So in some ways DNG with Diagrams can be a stepping stone towards a true model based approach.

I have yet to get some hands on with the tool chain, but IBM Rational Software Architect is the UML based modeling solution.  And there is a way for this to integrate with DNG.

Implication: Start with IBM’s RTC Platform

Basically this means you are using at least IBM’s DNG offering.  Just wanted to be clear, there is no real magic.

The potentially naturally is that you could (1) transition to the suite of offerings from IBM or (2) take an OSLC based approach and link or sync your Lifecycle Management tool with IBM’s via its jazz.net OSLC compliant framework.

Concept: From Microsoft Office to IBM Rationale

What came to mind is exactly what IBM uses to advertise & advocate for DNG being superior to office applications for Lifecycle Management and Requirements Management.

Summary

A primer to IBM’s Lifecycle Management offerings of a lightweight and integrated diagramming approach and its heavier weight modeling offering.

 

Tried any of these?   What are your experiences?

Moving from document to model based engineering

Are you modeling?  Are the models you design more than diagrams?  Perhaps the models are visual aids, the specifications, the interfaces or, via a click of a button, the production software used in your system.  This mode of work falls under the umbrella of Model Based Systems Engineering (MBSE) and is something  I  recently dove into.  In this blog entry I want to share a survey of MBSE as I see it based on my research and reading the past several months.

What is Model Based Systems Engineering? (MBSE)

The MBSE initiative project site provides the following citation and definition:

The INCOSE SE Vision 2020 ( INCOSE-TP-2004-004-02 September, 2007) defines Model-based systems engineering (MBSE) as “the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases. MBSE is part of a long-term trend toward model-centric approaches adopted by other engineering disciplines, including mechanical, electrical and software. In particular, MBSE is expected to replace the document-centric approach that has been practiced by systems engineers in the past and to influence the future practice of systems engineering by being fully integrated into the definition of systems engineering processes.”Applying MBSE is expected to provide significant benefits over the document centric approach by enhancing productivity and quality, reducing risk, and providing improved communications among the system development team.

Source: MBSE Initiative project site

Examples of what an MBSE approach may look like are below.  The important points include (1) models are intrinsic steps in the process, (2) may take different forms based on the domain and lifecycle stage, and (3) models relate to other models.

Source: Systems Engineering - An Overview, Lennart Bergstrom, INCOSE WASATCH 2010
Source: Systems Engineering – An Overview, Lennart Bergstrom, INCOSE WASATCH 2010
Source: Perspectives on the Product and System Lifecycle, Prof. Dr.Ing. Margin Eigner, OSLC ALM-PLM Interoperability Community WG June 8 2015
Source: Perspectives on the Product and System Lifecycle, Prof. Dr.Ing. Margin Eigner, OSLC ALM-PLM Interoperability Community WG June 8 2015
Source: Model Management & OSLC for MBSE, Axel Reichwein, INCOSE IW 2014
Source: Model Management & OSLC for MBSE, Axel Reichwein, INCOSE IW 2014

All I need is a tool, right?

A tool will get you started, but a modeling tool is really only part of a model based approach.

It is comparable to thinking “all I need to make an App is Visual Studio, right?”  While Visual Studio provides a means to build an application it does not provide a holistic software engineering solution covering topics such as version control, bug tracking and continuous integration.  Clarifying up front why you want to make an app along with what it needs to do, who will use, test, and maintain it, are all decisions to clarify up front to ensure there is rationale to choose Visual Studio as the IDE.

At one point I was investigating tools that supported SysML, a particular modeling notation, and came across a page with a quote I think is appropriate here from Systems Engineering  MBSE’ler Tim Weilkiens:

“There is no “best sysml modeling tool”. The best tool for project A is another than the best tool for project B. It depends on the different requirements of the projects.”

Source: Popular SysML Modeling Tools, Weilkiens, list.ly

Along my MBSE journey I created a modeling mind-map showing topics in the domain of modeling.  Tools are just a part of the mind-map.  Other topics include techniques, standards, simulation, transformation and notations.  There is more, these are just the topics I made time to jot down.

So, a tool will get you started.  But its not really about the tool, its about knowing what goals you want to achieve and if a modeling tool/solution has the capabilities to get you there.

No more documents?

Documentation typically still has value and the question is more about how is the model incorporated into stakeholder valued documentation with low cost (i.e. push of a button).

Figure 5: Source: The Challenge of Managing Enterprise-Scale Models in MBSE, Mitchell, INCOSE 2015 MBSE Workshop
Figure 5: Source: The Challenge of Managing Enterprise-Scale Models in MBSE, Mitchell, INCOSE 2015 MBSE Workshop

Summary

There you have it.  A survey of MBSE with visual aids to highlight what it may look like and references from organizations and people doing it.

Enjoy.