The Squiggle of Design

I really love this.

I was recently in discussion with a colleague about the importance of the cone of uncertainly in systems engineering. This aligns a bit with Robert Spinrad's, VP-Xerox, quote “In architecting a new software program, all the serious mistakes are made on the first day.” 1988.

Something my colleague mentioned was that he really likes The Design Squiggle. It's pretty cool, isn't?

The Process of Design Squiggle by Damien Newman, Central Office of Design is licensed under a Creative Commons Attribution-No Derivative Works 3.0 United States License.

A more elaborated example is here.

The real thing here, I think, is this: Iterate and get feedback. Try something, improve quality of experience, try something else, make sure it works, look for simple things, look for elegant things. You'll make more mistakes at the beginning but keep going and keep soliciting feedback and changing things and an elegant design will emergent that revolutionizes the user experience.

Rhapsody Tip #15 - Changing the default project directory (Intermediate)

This is a lesser known tip. When you create a project in Rhapsody, the New Project dialog will, by default, choose an installed folder as the default root for new projects. This is not usually a desired location, and may not be read/write, requiring you to browse to a new root. Doing this every time you create a project can be annoying especially in training or when demoing. Fortunately, you can tailor the default folder by adding a line ProjectsDirectory= to the rhapsody.ini file. This short video illustrates:

Note: Rhapsody also writes to this file, hence when editing the rhapsody.ini try to have Rhapsody closed.

MBSE Rhapsody SysML Method #1 - Requirements Analysis with Use Cases and Activity Diagrams

One thing I hear a lot from people new to MBSE is where to start? It’s a valid question because SysML and tools like Rhapsody can be used in many different ways. They provide the mechanisms to express systems models, not a method. In this video I show some extended tool support I’ve developed to accelerate a method that I know works. It's for a very simple SysML method that goes back to UML basics.

I've also decided to open source this code in order to support my training and consulting work. The repository is: https://github.com/fchadburn/mbsetraining/releases/tag/v1.2. You are free to download, use it, or try it out providing you accept the GPL v3.0 license.

This is an initiating method used to perform requirements definition work from analysis of use case steps using an activity model. It can be used regardless of whether you want to go on to model execution; as it aims to squeeze the best out of two worlds; DOORS for Requirements Management and Rhapsody using the SysML graphical notation. The premise is that SysML offers a brilliant landscape for the requirements definition work, and DOORS provides a scaffolding for connecting and managing the resulting requirements with the wider world.

Rhapsody Tip #14 - Using make default and drawing interruptible edges (Simple)

This video shows a couple of simple tips when working with Rhapsody's drawing surface. The first is the ability to choose a new default size for things by right-clicking and choosing Make Default... The second tip is a workaround for drawing a jagged edge coming out of an interruptible region by adding user points. Both are things I actually use quite often, hence I thought I'd bottle them into a video.

p.s. The Helper profile I use in the video is something I've made available as an open source helper (more info to come on this).

Rhapsody Tip #13 - Managing Unresolved elements/units (Intermediate)

This video gives some housekeeping tips for IBM Rational Rhapsody. A model, by definition, differs from drawing pictures because you have the ability to view the same artifacts in many different ways. A common data dictionary means we can keep things consistent as information and ideas are evolved by the team developing it.

But what if someone sends you a model that references a profile or units in a different model that you don't have, or your CM strategy fails to ensure related files are propagated together? This video hopefully helps to explain. It also shows how you can use the File > Add to model dialog in Rhapsody to reference other profiles and Edit > Advanced Search and Replace dialog to check a model for unresolved elements.

p.s. I've expanded my domain names. Can you guess which ones I've gone for? ;=)

Integrating Rhapsody with Configuration Management (CM) tools

Following on from my short video on Units (Tip #12)...

If anybody is configuring Rhapsody with their Software Configuration Management (SCM) tool then this IBM dW article by Patrick Schnieder, Patrick Weber and Martin Stockl is quite interesting:
http://www.ibm.com/developerworks/rational/tutorials/integration-guide-for-rhapsody-and-clearcase-on-windows/

The command line part is very CC tool specific but some of the principles such as units and the need to configure properties run across all SCM tools. The MS-SCCI mode setup for Rhapsody is also more generically useful for a range of other CM tools but the actual CM tool and related API does make a difference. Eclipse has its own way of integrating with SCM and is a option some people use for Rhapsody with RTC or SVN. For some tools such as RTC, however, more than one option exists (Eclipse or MSSCI) hence it's important to understand the general tool landscape/product versions and what you want to achieve. 

If you google well enough then you can find the Team Collaboration Guide from the 'list of books' days before IBM. The first bit, at least, is worth a read just to get a basic grounding. It's been superseded by IBM's online help but I like the intro. 

Considering MBSE methods as model-to-model (MDA) transformations

During a recent discussion at the INCOSE Working Group there was a comparison between Model Driven Architecture (MDA) and Model-based Systems Engineering (MBSE). It promoted an old friend to raise a point that he felt that his organization does apply MDA techniques in MBSE because they transform models from one form to another. They may not call it MDA - and it may be semi-automated or manual - but fundamentally there is an underlying concept of a model-driven transformation that exists. I really liked this idea.

One method is to transform use cases into functional requirements via actions in an activity diagram. With the right tool customization, I can explain and show an engineer who knows nothing about SysML how to do this in 10 minutes. It's a very simple method and very simple to explain. It's amazing what they can come up with. Simple methods can be used to embody and analyze very complex behaviors and “model driven transformation” is a neat way of thinking about it.

Ultimately teams use Model-based Systems Engineering methods to transform ideas into other ideas. The transform may be model-to-model (M2M), model-to-text (M2T), or text-to-model (T2M). The adage that you don’t need something complex to explain something complex applies. Using a set of simple transformations we can assemble an end-to-end process that flows information across teams and achieves astounding results. We can move from static pools of silo'd knowledge:

To business level transformation of ideas (notice the use of the «block» notation at the bottom ;-):

 (if we can get all the teams to all agree that is, ha ha).