RPE Enablement – we need your feedback

We keep getting the following message from you, the RPE users: the RPE documentation/enablement is not sufficient.

This is a constant message and one of the reasons for starting this blog and other initiatives the RPE UA and development team are undertaking, such as preparing videos for the new features in our next RPE releases.

There are many things to write about RPE and the new/less known features of RPE are the obvious targets for the next articles. However what the development team might think is less known is not necessarily what end user does so for a more relevant content we need your direct feedback: for what features of RPE would you like to see more enablement material?

Your requests will have as result one or more of the following: posts on this blog, enhancements in the official RPE documentation, requests to the other Rational teams.

I’m looking forward for your answers here as comments so we can discuss them and see what would be of greater interest.

Author: Dragos Cojocari

Architect for Rational Publishing Engine

7 thoughts on “RPE Enablement – we need your feedback”

  1. When publishing from Rhapsody, the schema mapping is not easily discernable. Rhapsody might use a “flow” in the model, but then RPE sees it as a “link” (might be bad example). RPE tends to have a LOT of attributes associated with each model element when browsing the schema, and it is not always clear which schema item is needed to get the data in question. Sometimes iterating through “related” or “contained in” relations are required, but it not always clear when this needs to happen.

    It would be nice to have a ‘rosetta stone’ that could map the various Rhapsody elements, port, flows, connects, attributes, etc. to the schema that we see in the RPE Studio. We need more than just the top-level object types that appear in each package. It is often desirable to elicit information on a per-diagram basis such that the diagram is the starting point for further queries. Someone might want to list all the elements on an IBD including ports, connectors and attributes associated with those items.

    1. Thanks Dave. Making the connection between the on screen labels and the schema labels is something we are working on with the RHP team to figure out how to do better. I’ll get back to you on the Rosetta stone.

  2. Hey Dragos, I thank you for your great work so far! Your blog is a great resource for my daily work.

    Currently I’m tackling test managment with Rational DOORS and export of results using RPE. The extraction of test run attributes is not yet documented as complete as I would wish. Best practices how to export test results would be highly appreciated. Generally, a better documentation how to set up tests in DOORS and how to extract results in RPE would be great.

    1. Thanks Matthias. So all the information is stored in DOORS, i.e. you use DOORS not just for storing requirements but also for storing QM data? How is this QM data organized in your DOORS module and what part of formatting is not coming right?

      1. DOORS provides basic test tracking support with which formal modules containing test descriptions can be made testable semi automaticly. Each test run, which can also be initiated in DOORS, generate new attributes in the test description’s objects. Now, it is not immediately clear how usable this semi automatic test feature is and how well this attributes can be extracted in RPE. In theory the schemas for the modules in question change with each test run. But possibly the information could also be extracted via scripting and attribute names. I don’t know. That the documentation is not so extensive can have several reasons:
        1) I use the feature for something it was not invented for
        2) The usage is so obvious that it needs no documentation
        3) Nobody else was courageous enough to use the feature together with RPE

      2. I have not used this myself and have not seen examples either. But that does not mean it cannot be done. RPE allows to connect to DOORS both in a “strict” way ( with schemas discovered for specific modules) as well as in a more lax way ( getting all attributes and identifying what’s needed on that).

        I’ll try to get up to speed on this but in the meantime I will create a tutorial on how to process DOORS modules that have varying attribute names with a single template. I hope this will answer at least partially your question.

      3. Thanks Dragos, such a tutorial would help me very much! I think this would solve the problem with the test runs to a great extent.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s