Setting URIs for Artifact Types and Artifact Attributes when using project to develop a template?
![]() Good day,
I am considering setting up a project template for a small team of people to make things easier when they have to setup a project. Given the number of things that need to be set up, it is very easy to accidentally introduce inconsistencies.
One of the things that I have consistently impressed upon them is ensuring all Artifact Types, Artifact Attributes, and Attribute Data Types have a URI.
We have a naming convention that starts with the url example: https://<our RMS site>/<Project Name>_<attribute name>
However, the problem with this naming convention is that they would have to ensure the URI would be altered for every Artifact Type, Artifact Attribute, Attribute Data Type, and each of the values associated with the Attribute Data Type. This would also be prone to inconsistencies as well (we are all human). It would also be very tedious and repetitive. NOTE: I do not have access to scripting this. I would prefer to have something set up to minimize the inconsistencies.
What naming convention do other people use for their URIs that can be used as part of a Project Template?
Sincerely,
Mary
|
Accepted answer
![]()
The approach i have always used with my clients when defining URIs is:
https://<organisations web URL>/rm/<prefix>/<name of element in CamelCase>
where prefix is:
types = Artefacts
attrs = Attributes
dataTypes = Data Types
links = Links
and then for each enumeration I use:
https://<organisations web URL>/rm/dataTypes/<name of element in CamelCase>#<value name in CamelCase>
The key thing about using URIs is that if you don't explicitly add one, then a unique internal one is generated. This means that artefacts or attributes that are the same across project areas will be treated as unique when you try to copy artefacts between projects, in the Data warehouse, and in the LQE warehouse. It is also critical to have URIs when you export and import via ReqIF.
The implications for the latter are that DW reporting sometimes gives you strange results because you can't select the correct attribute, and in LQE reports the same attributes from different project areas won't end up in the same column by default.
When you are trying to manage a global RM schema for your organisation, adding a URI lets you establish that across your world.
Mary Miller selected this answer as the correct answer
|
3 other answers
![]() Hi Mary,
|
![]()
Okay, that makes sense. This brings up another question.
First, it sounds like it would be better to use the naming convention of https://<DOORS NG URL>/<Artifact Attribute Name>
Let's say I have the following scenario:
So, if I have a Project A that has the minimum attributes (where all URIs are set), and Project B that has the same minimum attributes (where all URIs are set).
However, Project A has a significant number of attributes that I want to use in Project B. From Project B, I decide to Import Project Properties from Project A.
How would this impact this impact the URIs where the Artifact Types, Artifact Attributes, and Data Types are the same?
Also, for linking between projects or developing Reports across projects, how does DOORS NG know the difference between the URIs in the common, say, Artifact Attributes used in Project A and Project B?
I think there is a piece I am missing, and I want to make sure the URIs would not "clobber" each other.
Sincerely,
Mary Comments
Hi Mary
> it would be better to use the naming convention of https://<DOORS NG URL>/<Artifact Attribute Name>
For 6.0.6.1 (and earlier AFAIK) there are restrictions on URIs, see https://www.ibm.com/support/knowledgecenter/en/SSYMRC_6.0.6.1/com.ibm.rational.rrm.help.doc/topics/t_create_attribute.html
Note in particular that these say that you must not use the actual hostname of your server in your URIs.
The 7.0 version of that page shows that these limitations are being largely removed.
HTH Ian
And on the topic of managing your type system across many projects, there is an article here: https://jazz.net/library/article/92352
Many of the principles in that article still apply when Configuration Management isn't being used.
Okay, cool. I think I am good to go now. Thank you for the clarification!!
|
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.