It's all about the answers!

Ask a question

Single Project Area constraints/disadvantages?

Norman Dignard (356690170) | asked May 16 '14, 10:38 a.m.
We have multiple systems managed by different groups across our company.   One department is considering using one RTC project area for multiple systems, creating system team areas within it.

One of the issues/concerns we have are the implications that this may have from the sw development/SCM usage of JAZZ .  We can see some of the advantages however the flip side is not so clear.

Has anyone adopted such an approach in their organization and what are the pitfalls? Some of this things I see in this approach is that the entire PA will need to adopt some naming conventions for components, baselines/streams team areas, builds.  My concerns may be unfounded but something on this approach  is just not sitting well with me and hence my request for some feedback.

If there are multiple non-related "systems" being developed by different groups within a department what problems to you foresee ? I don't see the same issues from the RM and QM sides but the SCM side of RTC is a concern.

One answer

permanent link
Karthik Krishnan (8825118163) | answered May 17 '14, 2:20 a.m.
edited May 17 '14, 2:22 a.m.
 We have one PA for all our (internal) software development teams. So far it worked pretty well

- components are owned by respective teams
- One process across the board
- Any process change does not take more effort 
- Easier administration

- It is really not easy to hide components
- More discussion with all stakeholders in order to convince if there was a request for process deviations only for a team or 2
- Didn't find any more in last 3 years :-) 

But we have a new requirement that there are some "External" SW teams who will work for us. Which means that the Single PA wont work due to the fact that way permissions are setup in RTC between PA & Team areas, which I came to know only very recently. Thanks to @gmclemm

So our new approach would be the following 

- Create as many PA as possible for the different combinations which will govern the component access control
- Assign members (internal & External) 
- Make the stream owner as another PA which has both internal and external members

With this approach I see lots of administration work, adding users left & right but I think that can be automated

and yes Overview of the system would be more complex as and when we have more teams & sub contractors  

Your answer

Register or to post 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.