DNG - Base artifact links vs module context links
There is a distinction between linking to/from a base artifact vs linking to it in a module context but what are people doing in practice?
If all artifacts are in modules and there is no CM then is it better to use module context links or base artifact context links?
If we have a simple project (no CM) with 2 modules Stakeholder and System and each contains some St and Sys reqs then users can create links by dragging and dropping between the module representations of the respective artifacts and these will be module context links.
They can alternatively open the artifact and create the link in the artifact sidebar in which case the links will be base artifact links.
It seems like it could be quite easy to accidentally end up with a mixture of the 2 types. Is there any way to enforce all link creation as being either module context or base artifact?
|
6 answers
|
Or even if there is a way to tidy up afterwards when users have accidentally created a mixture of base and module link contexts.
Like if we could move any module links to become base artifact links (or vice versa - assuming all artifacts are in modules and appear only once)
|
Sean,
You're asking the question that has other users of the software (like me) scratching their heads. I get the locality of modules. I suppose if users are making comments or want to show dependencies within a specific group of requirements, they'd prefer the locality of making them within the module.
The design decision that Jazz has made is the assumption that link locality is the only reason users would link in the module. Users like myself and those I work with daily do not want to create "local" links by default. They are linking in the module because it is structural and cogent. Lack of context in artifact folders and collections makes linking impossible.
While I'm griping, it's actually funny that there is an explicitly "local" link type called "Parent of" and "Child of." However, you aren't capable of linking by attribute with the parentBinding values you carefully populated. Extracting those values requires you to extract your requirements from every module you've ever created. GL, HF.
Possible Fix: There should be a way to fix this. Here's a general flow:
1. Query your project with OSLC / REST. (View -> Module)
2. GET the XML for the module. Loop over MB artifacts.
3. Extract uri and etag values.
4. Replace "/MB_" with with rrm-core value to get the "base URI"
5. Update base uri artifact with Core etag value.
6. POST artifact back to project.
If there was some easy way to fix this issue, I'm sure they would have done it by now. As it stands, it's been an issue for reporting and user interaction which has no "out of the box" solution to my knowledge.
DNG v6.0.2iFix015
|
|
Thanks for the suggestions David.
|
My perspective after 2 years in the CM environment: The Modules are necessary to provide structure to your requirement Set, I would argue that linking to base artifacts makes little sense but it all depends on how you define your ontology. Trace reports will work independent on which method you are using but you need to be consistent. An improvement would be to be able to configure what the link dialog defaults to, Module or Folder. This is by far the greatest confusion among new and even experienced users.
The great benefit a Module will bring is that you can keep a pool of artifacts that you can add or drop to/from the set making scope adjustments easy. However, a trap here is that when you add an artifact back to the module, from a trace link perspective it is considered a new instance, you have to create new incoming and outgoing link. That behavior makes it possible to link independently to and from multiple instances of the same artifact in the module, which for us makes no sense. Due to this behavior we now never drop requirements from modules just in case we have to add them back. Originally we used the module to define the requirement Set (the scope is not defined by your pool of base artifacts) but we surrendered this approach to instead use an attribute to indicate in our out of scope. Makes it more complicated to report and use links explorer but all in all a better solution for us. I think the tool should allow you to add back individual requirements to the set (module) from a different stream (so the instance identifier is identical) in case you dropped a requirement and want to add it back to the module without loosing at least the incoming links.
|
I hate that we have to do this, but I've had this same issue pop up a couple of times and I IBM keeps giving me the same answer. The steps below will allow you to transfer your base artifact links over to module links.
Open your list of artifacts.
Configure the page so that all your links are displayed
Select all your artifacts
Export your artifacts to CSV
In the CSV file reduce all links down to just the DOORS ID number (Make sure not to change the DOORS ID).
Change the column name for the links.
Save the CSV file
Import the CSV file into DOORS (Assign the new column as "Text")
Open your module
Use "Link by Attribute" to link the module artifact to the original link using the new Text attribute.
It is a royal pain, but it fixes the issues with links.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.