It's all about the answers!

Ask a question

RRC the right Project Area set up?


Kristian Broe (71914) | asked Apr 28 '14, 9:38 a.m.
edited Apr 28 '14, 10:02 a.m.

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:

  • 100+ running projects
  • 80+ system/application owning areas
  • We do not use RAM

Questions:

  • How many project areas should we have?
  • How do I ensure that we can handover Project documentation to System owner as permanent documentation in a way where I do not loos all my traceability.
  • How do I in a project link to an artifact in the permanent doc base. e.g. a Uses relation to existing functionality?
  • How do I check out permanent documentation to at project when I need to extend existing functionality?
     

Comments, ideas, experience from related challenges, resources, recommendation etc. Is well received :) 


Accepted answer


permanent link
Daniel Moul (4.4k1115) | answered Apr 28 '14, 11:36 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
>>> (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:
  • fewer project areas == less administration. Visibility of artifacts to a wider group of people (which could be good or bad depending on your organizational culture and corporate requirements).
  • If you expect to grow to many millions of artifacts you need to start thinking about issues of scale (and perhaps partition into multiple project areas)
  • Within RM project areas you have more expressive options for link types -- you can define your own link types.  At this point, across projects you have pre-defined link types available.


>>>(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


Register or to post your answer.