Today I’d like to continue on the theme started in Finding suspect links and requirements to reconcile in Collaborative Lifecycle Management (CLM) 6.0 configuration management enabled projects by addressing another consideration from Enabling configuration management in CLM 6.0 applications.
Do you need to filter views based on lifecycle traceability links?
In CLM 6.0 for those projects with configuration management enabled, you can view artifacts with their lifecycle traceability links, but cannot filter by those relationships. There are three key areas this impacts:
- Limit by lifecycle status in DOORS Next Generation (DNG)
- Traceability views for RQM test artifacts
- Linking RTC plans to artifact collections
I’ll explore some alternative workarounds to these in this blog.
Limit by lifecycle status in DOORS Next Generation (DNG)
In CLM 5.x, views of requirements artifacts can be filtered by the status of lifecycle artifacts linked to them. The same is true in CLM 6.0 but only for projects that don’t have configuration management enabled. This limitation should be addressed in a future release by work item 97071. Below is an example showing all feature requirements with failed test case runs.
Similarly, the following shows all feature requirements whose linked development items have been resolved.
In CLM 6.0, for configuration management enabled projects, the lifecycle status filter option doesn’t even appear.
It is still possible to show a view of requirements with their lifecycle traceability links shown; it’s only the filtering that isn’t possible (at present).
Here you could scroll through the Validated By column, for instance, and manually scan for test cases whose icon indicated a failure occurred. This wouldn’t be viable for more than a short list of requirements.
What’s needed then is to display a view/query of the linked artifacts, filtered appropriately, and display, if possible, their linked requirements.
For example, show all failed test case runs in Rational Quality Manager (RQM) and their associated requirements. When displaying all test cases, you can see visually by their associated icon, whether the test case has been run successfully or not. This isn’t ideal given you aren’t able to filter by the test case status and must instead visually pick out the failed runs. It does, however, show the linked requirement being validated.
Alternatively, show a view of test case results and filter by their status. Below is a list of test case results that are Failed or Blocked and their associated test case.
Unfortunately, it doesn’t also show the related requirement. Instead you would need to drill down into the test case from the failed run and see its linked requirements.
Use of the Jazz Reporting Service Report Builder may be an option in limited cases. First, it’s use for configuration management aware reporting is Technology Preview in 6.0 and only really contains configuration data for RQM. For DNG, only the default configuration data is included for configuration management enabled DNG projects. If your requirements configuration management needs are basic, where a single configuration/stream is sufficient, this may be an option.
For example, the following report shows all requirements with failed/blocked test case runs.
Now you’ll likely have multiple DNG projects. DNG doesn’t publish project area data to the Lifecycle Query Engine (LQE) using Configurations data source so you can’t choose only those requirements artifacts from a given project, limit scope by that project nor set a condition to query by some DNG project area attribute. You can, however, choose test artifacts for a given project area (and configuration) so if there’s a 1:1 relationship between DNG and RQM projects, you can produce a report that just shows the requirements from failed test case runs in the desired RQM project belonging to the desired global configuration (this is what is shown in the previous screenshot).
I tried looking at this from the opposite direction, that is, show all failed/blocked test case runs and their associated requirements. You get the right list of failed runs, but it shows all their associated requirements, not all of which were tested and failed in that run.
For the other example I gave earlier, show all requirements whose linked development items were resolved, you could go to Rational Team Concert (RTC) and run a lifecycle query such as Plan Items implementing Requirements, but you’d need to visually look for plan items whose status met your criteria as the query isn’t editable and thus you couldn’t add a filter.
Traceability views for RQM test artifacts
In CLM 5.x, views of test artifacts can be filtered by the presence (or not) of a linked development item.
The same is true in CLM 6.0 but only for projects that don’t have configuration management enabled. RQM projects that have configuration management enabled, don’t include that filter option. This limitation should be addressed in a future release by work item 134672.
From this view, you would then need to visually scan the Test Development Item column for whichever condition you needed.
RTC has some lifecycle queries, such as Plan Items with no Test Case or Plan Items with failing Tests that could help.
Here again, Report Builder could help as you could construct a report that shows test cases with or without associated work items. For example, the report below shows test cases without any work item associated.
Linking RTC plans to artifact collections
In CLM 5.x, it is possible to link an RTC plan to a DNG requirements collection and/or a RQM test plan. Use of these grouped artifacts allows for shared scope and constraints across these lifecycle plans and are useful in auto filling gaps in plans or reconciling changes.
In CLM 6.0, links to collections and test plans from an RTC plan only resolve to the default configuration in the project they reside in. In other words, you cannot link an RTC plan to a versioned requirements collection or test plan. This limitation should be addressed in a future release by work item 355613. The primary limitation that translates to is you are unable to auto generate workitems for requirements in a collection when working with projects that have configuration management enabled.
Missing that capability then the only work around is to manually create the workitems so that every requirement in the collection is linked to a corresponding work item.
A traceability plan view in RTC that includes a color filter will help identify those plan items without requirements links.
Such a view will highlight cases where a work item may need to be removed as the scope has changed, e.g. the collection has had requirements removed.
In DNG, view the collection with the Implemented By column included and scan for requirements with no corresponding work item.
If your requirements set is too large to view manually, export the collection view to a CSV file then open the exported file and filter or sort by the Implemented By column to more easily see those requirements without work items.
Conclusion
Of the limitations discussed, I find the first one, inability to filter by lifecycle status, will be more problematic for customers though I’ve found it’s usage to be mixed. I’m also not particularly enamored with the workarounds described because they too are limited and involve some manual steps. I would be interested in hearing how significant these limitations are in your environment or if you have additional ideas on workarounds for them.