Multiple products in a Project Area

Are you referring to project areas managed by RTC where components are source files under source control? Or components of requirements managed by DOORS NG? Or something else?

From my point of view, components are not very project area bound. So you can have all products (one component per product) in one project area and just controll access by build product development teams in team areas.

Hi Muhammad,

Multiple component, is to divide your huge set of files into coherent and logical subsets, more identifiable and manageable.

Note: in RTC, you can reuse a component (defined in one project area) in another project area.

You can put it all in one component and leave the directory structure.

Note: One of the reasons for different access control.

Streams are largely about allowing for parallel development, so is largely independent of your component layout.

Please refer the below blog it might help you.

https://www.ibm.com/developerworks/community/blogs/32f9d388-7f35-4598-a08a-7cd6c0bd3841/entry/how_to_decide_on_rtc_components_during_a_migration17?lang=en

Regards,
Arun.

I agree with Guido's answer, but would phrase it more strongly ... think of a component as being completely independent of any project area.   A stream in any project area of a given repository can use any component in that repository.   The main connection between a component and a project area is that if the "owner" of a component is a project area, then that project area defines what users have read access to that component, and what permissions and operation behavior apply to modifications of the metadata for that component (such as the "owner" of that component).   A "product" is best thought of as being defined by a stream, where that stream identifies the set of components that make up that product.   A "team area" is primarily designed to represent a planning area for a given team.   A given team can work on an arbitrary number of products, so you do not need a separate team area for each product, unless you want to have a separate plan for each product.

Cite:
Q. If I want to use multiple products in one Project area then how can we manage it? would each product will be managed in each component or there is any other practice ?

Assuming you talk about RTC, which I have to assume due to the lack of tagging, how should one answer this question, if you don't provide any details at all? What is a product? What do you want to do with it?

Making a host of assumptions, my answer would be.......

SCM: Components usually map to some partition to the code i.e. architecture such as common, repository, ui, build

So unless your products are all isolated and don't share any code between them, components are not the level of organization you want.

If your products share code, you can organize a products code in a stream. You would have different streams for different products and also streams for different versions of them.

Change management - work items and planning

If you want to be able to plan for and report work items against products, you need to be able to distinguish them somehow. In RTC you can have multiple project areas as one option. Another option is to create categories in a RTC project area that reflect the products somehow. e.g. Product1, Product2, Product2.

Categories can be mapped to team areas, so you can manage different teams working on their products. e.g.
Project Area/Product 1 Team
Project Area/Product 2 Team
Project Area/Product 3 Team

Planning involves also development timelines. Each area (project or team) can only be associated with one timeline. If the teams have different rhythms, you need different timelines for each team.

Finally, when to use project areas vs team areas: This really depends on
1. Complexity. If you have very complex products you will likely end up with multiple project areas. If they are simpler Team areas may do.

2. Flexibility and administrative overhead. In a project area, all teams have to follow pretty much the same process. If you have completely different processes and want more flexibility, you would need more project areas. Project areas add a lot more possible administrative cost compared to team areas, but have more process flexibility.

3. Organization: In some organization it is not possible to map people to products, the people are pooled and work in their area for the projects (department). In this case the team areas often reflect that structure, sometimes even broken up in project areas. In cases like that, there is often one or more additional project areas where the products are planned and the work tracked down to the team/project ares where the developers are located.

This is not always the case and you can also have users associated to multiple project and team areas and assign their availability there, which also has tradeoffs.


Please see: https://jazz.net/wiki/bin/view/Deployment/SetupProjects for a bit more information. Unfortunately there is no one size fits all approach, but fortunately you can start with one approach and evolve from there.