Saturday, 23 February 2019

Rational Rhapsody Tip #54 - Linking models to remote requirements in DOORS NG 6.0.6 (Intermediate)

This second short min video follows on from the previous one (#53) and shows what you can do once you've associated a Rhapsody /am project area with a DOORS NG /rm project area. This is really the core of what OSLC linking is all about. You can connect data to other lifecycle artefacts without leaving the tool that you're in. In my opinion the Rhapsody development team have actually done a good job here with the 6.0.6 implementation of Rhapsody Model Manager (RMM) - its server-side back-end. The good thing for me is that it fully supports the well established mechanisms of an OMG SysML approach with requirements in the model and traceability captured both graphically and in diagrams. It allows you to dovetail requirements in DOORS NG with modeling artifacts in Rhapsody despite them being separate applications. Other good things in the 6.0.6 (Rhapsody 8.3.1) implementation are the ability to navigate from the web-client to the Rhapsody rich client, and the quickness of the linking. It's almost like the requirements are part of the model, despite the fact that they're being provided and linked to by an separate application.


1. In this video I look at how the IBM Jazz platform (6.0.6) allows you to link Rhapsody model elements to requirements in DOORS NG (DNG).

In the first video I created a Jazz lifecycle project which associated my Rhapsody architechure management (/am) project area with Jazz project areas for work items (/ccm), tests (/qm), and requirements (/rm).

2. When I open a Rhapsody project, it will automatically populate the Remote Artifact Packages category with these associated project areas.

3. I can then login if I want to access these 'live' resources from the Rhapsody browser.

4. For linking, rather than show all the artefacts, I can choose to populate a collection.

5. OSLC uses a delegated user interface approach allowing me to select a collection in DOORS NG without leaving Rhapsody.

6. With DNG we can have view of modules. For example, a view filtered to show just the approved stakeholder requirements.

7. What is great about the Rhapsody dev teams approach is that although these requirements are remote resources, I can use them if they were part of the model.

8. For example, we can drag them on to diagrams...

9. ... and add dependency-based traceability (ala SysML).

10. The traceability that is created as actually OSLC-based, hence will be navigable also from DNG.

11. With the new /am application the links are stored in the Rhapsody project. This makes it quick to add and correct them before they are delivered.

12. We could establish review gates also, prior to delivery, as they're stored in the change set.

13. When the change set is delivered, the links will be visible in DOORS NG.

14. DNG is an entirely web-based client built from scratch using the Jazz-platform.

15. Module views allow me to choose which attributes or links to show. For example, a Stakeholder Approved view in which we can see the linked Rhapsody model elements.

16. Hovering over the link, a rich preview is provided by the Rhapsody Jazz/am web application.

17. 6.0.6 has a handy Show in Rhapsody button.

18. This overlay icon is showing that the requirement is linked...

19. ... and we can add relations here also.

20. Again, remember that we have to deliver before these are published to others.

21. In this instance we added a different type of relation.

22. Jazz /rm allows you to show these SysML-based link types, out-of-the-box (there is very little configuration you have to do).

23. The other thing about Jazz /am is that you can also view the Rhapsody model and links without needing Rhapsody installed.

24. For example, in the /am (RMM) application in Jazz, we can see all the DOORS NG (Jazz /rm) requirements linked to the use case.

25. The same traceability is viewable across applications, making it truly collaborative with a highly integrated feel.

No comments:

Post a Comment