RRC the right Project Area set up?
Hi We are currently rolling out RRC (and DM, RQM and RTC) in your organization. And as a part of this I'm trying to frame the best usage of RRC to fit our engineering principals and ways of working. Set up:
Questions:
Comments, ideas, experience from related challenges, resources, recommendation etc. Is well received :)
|
Accepted answer
>>> (1) How many project areas should we have?
In general you should organize a RM project area so that your team delivers multiple releases over time from these artifacts. The project area provides the authorization boundaries: who can see the artifacts and who can create and change them. Within a project area you can use team areas to provide finer-grained permissions. Here are some additional considerations:
>>>(2) How do I ensure that we can handover Project documentation to System owner as permanent documentation in a way where I do not loose all my traceability.
You could use module baselines (aka snapshots) to reflect the state of the module at a particular time. Since the scope is the module, the system does not guarantee that the artifact at the other end of the link (design, test case) is the same as when the module baseline was created. You need to create baselines/snapshots in those tools too. Some people create PDF docs for archival purpose to simplify future use of this information. If you haven't already done so, you might want to customize the document generation templates with the "studio" included in Rational Publishing Engine (RPE).
>>>(3) How do I in a project link to an artifact in the permanent doc base. e.g. a Uses relation to existing functionality?
You could store the archival PDFs in your RRC project and define your own link type to express the relationship to them.
>>>(4) How do I check out permanent documentation to at project when I need to extend existing functionality?
You can consider the latest artifacts in the system as the "head" of a stream, so these are the ones you would modify. Alternatively you could create a copy (emulating a branch) for a new project.
Note that we have work underway that will significantly simplify your use cases. You might find this post informative: https://jazz.net/forum/questions/135495/the-basic-concept-of-rrc
Kristian Broe selected this answer as the correct answer
Comments
Kristian Broe
commented Apr 29 '14, 4:53 a.m.
Hi Daniel This was what I was hoping for, and some :). It very positive for us to learn that you address these challenges, that are crucial for a successful adoption of CLM in our organization. I will share your input with my team and might get back with a follow up question.
Thanks! |
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.