I'm trying to figure out a reasonable way to implement our development process optimally in RTC. I don't quite see my way yet and would appreciate it if people can tell me how to do this.

We develop packages consisting of a chip, firwmware and software. The development is organized into a chip, firmware and software project. These projects are only loosely coupled, but, in addition, there is a system project that puts together the results of the other projects and ensures that coherent releases are made that meet the required functional and quality commitments (i.e. the software, firmware and chip work together and deliver the right results to the customer).

Every new chip requires significant development from scratch, and thus is organized as a new project with mostly new components. But the firmware and software projects develop code bases that are used on many chips (i.e. the code is not developed from scratch for each chip). So these projects can be considered long lasting projects that provide one baseline to a number of different system projects.

The four sorts of projects have different processes, including work item workflows and attributes. (Ideally, I would like to define one process in RTC, with one "core" workflow, and then add as few attributes and states as possible for each sort of project.)

I hope this provides enough background for people to give me some help. I think that if I implemented this in a naive way in RTC as follows, I would NOT get optimal results:

1) one FW project area that lives forever
2) one SW project area that lives forever
3) one chip project area per chip that lives until the chip design is finished
4) one system project area per chip that lives as long as FW or SW updates are needed

I can see that the chip, SW and FW projects could handle their own planning and development in RTC projects, but I don't see how to set up the system project. In particular, the scope of many items in RTC - plans, iterations, queries - is the project in which they exist, and there appears to be no idea of relations between projects (i.e. subproject).

Let me describe a few use cases to show that this is a practical, not an academic problem:

1) The system project manager needs to do hierarchical release planning. For example, he might plan a release like this:

systemA-1.0

	chipA-1.0

	sw-4.2

	fw-7.1.4

He needs now to coordinate the release plans of the four projects and track progress towards the goals of the release.

2) In particular, he needs to make reports that list the open work items for systemA-1.0, chipA-1.0, sw-4.2 and fw-7.1.4. He needs dashboards that show planned vs. actual progress in this hierarchy.

3) Users in different roles are submitting work items, but they can't be expected to know the structure of the projects. That is, if a firmware developer discovers a firmware bug, he knows the project to use; but if a system tester discovers a firmware bug, he doesn't know this - he knows only the system project. So there must be a central place where such work items are submitted - e.g. the system project, from where they are delegated to the other projects.

Reading over this and looking again at the RTC doc, it occurs to me that RTC would want to handle this as one big project area that is used for ever. It is split into different team areas:

1) one FW team area
2) one SW team area
3) one chip team area per chip
4) one system team area per chip

Would this structure handle the use cases above? Would the systemA team area allow the system manager to plan hierarchically? Would the chip, software and firmware areas need to be be children of the systemA team area? But how would that fit with the fact that the software and firmware "projects" have a different life span and deliver to different systems at the same time? Or could, say, the SW team area be "linked" into the systemA team area (and other team areas)?