Sunday 6 December 2015

Think how big the box is before you build a wedding cake

The waterfall (fixed features) vs agile (fixed time) question is not new one but it's one that affects all levels of an organisation and hence buy-in at the top is important. I was recently trying to explain to someone in automotive that while the principle of applying systems engineering is the right one, the process proposed needs careful consideration.

Firstly, consider the project management triangle of time, cost and features. This tells us that if we have more time we can have more features. If we have more cost then it will take us less time. We can't have more features for less time. There are caveats, of course, but the model makes sense. We can only control two of the sides.

In aerospace, features (i.e. quality/scope) is often a greater driver. We can't incrementally get the plane flying and add the wings later. Whereas in automotive the time is often fixed as an OEM doesn't want ship a vehicle to fit a software development life-cycle, it has a regular model-year cycle.

What this tells us is that there is no value in coming up with the most brilliant wedding cake of desire if it won't fit into the box that we need to send it in. Fundamentally we need to design a series of cakes that do fit into boxes or, in other words, a spiral or iterative method is needed. Invariably this means that it's best to consider time as fixed from the outset, and define features that are possible with the available resource.

Sunday 27 September 2015

Bi-directional synchronization with Rhapsody Gateway

More progress this week on how to configure IBM Rational DOORS with IBM Rational Rhapsody to successfully bidirectionally synchronize requirements from Rhapsody into DOORS. This approach uses the Rhapsody Gateway (part of the Rhapsody Tools and Utilities Add On).

Why is this important?

We see Rhapsody/SysML as a valuable requirements definition environment. It's not just that we can create requirement quickly, we can trace model elements to requirements at the same time. DOORS is a great requirements management tool, ensuring that IDs are never re-allocated and enabling exchange of requirements across the enterprise and test teams. Capturing traceability in SysML ensures completeness and mitigates the risk of gold plating but it also enables us to easily cope with the inevitable requirement changes for formal review. We want a pragmatic combination that squeezes productivity from both of these worlds.

Capturing traceability in the model

The first stage is to capture the requirements and traceability in the model. In the following model we're using a simple activity diagram to capture textual use case steps. We're then using these use case steps to create our first iteration of functional requirements, a systematic method that results in a set of functional requirements fully traced to the steps of the use case that gave birth to them.

How do we do it?

To get the requirements into DOORS we first need to get the DOORS module we want to import the requirements into ready. We use the DOORS Wizard functionality in the Rhapsody Gateway to set up a corresponding Gateway Type of Analysis.

The Add high-level requirements of the currently blank set of requirements into the model creates a "fromX" stereotype in the model where X is the name you gave to the type of analysis. It also creates a Package where the requirements will be synchronized to.

At this stage the requirements are in Rhapsody but not yet in DOORS so the package is empty. We move the requirements that we want in DOORS into this package and stereotype them using the "fromX" stereotype.

With the Rhapsody requirement stereotyped we choose the Rational Rhapsody Gateway > Synchronize menu to launch the Gateway's Rhapsody/DOORS Synchronization dialog.

To move the requirements in Rhapsody into our DOORS module we deselect both "Add high level requirements to Rhapsody" and "Export model to DOORS" and choose "Update high level requirements from Rhapsody" and "Reload high level documents after modifications" instead and then Perform Sync.

The requirements are moved into the DOORS module, allocated a unique ID by DOORS, and then updated in Rhapsody. At this point Rhapsody and DOORS are fully synchronized and the names updated to the DOORS unique ID. If I want to, we can use Rhapsody to modify the text or add new requirements and then repeat the process to update DOORS. Seems to work well so far.

How do we improved it?

The step of moving the requirements into the Gateway "fromX" package and stereotyping them is manual. To improve this, I wrote a script that adds a new menu command to the Rhapsody context menu to "Move and stereotype unclaimed requirements". This automates the manual steps making the process much quicker.


This process works because we make the assumption that only one person does the synchronization and that the model being synchronized is always the latest.