CLM project setup - recommendations
We are just getting started with the JAZZ toolset (DNG, RTC & RQM). We have multiple systems looking to adopt the tools. the development of these systems are separate in that some plan to use agile, some iterative, etc. They differ by dev platforms, operating systems, coding, dev processes, etc. There are around 100 or so different systems that we develop and maintain.
From the development perspective most are totally independent of each other in that they are managed by different groups and there are some inter-dependancies (interfaces) between some of them.
In going to jazz we would like some insight into best practices on setting up the JAZZ projects. Basically they are wondering what the best/recommended approach would be.
As it is, in their current DOORS db they have requirements for multiple systems defined in various modules within the same database.
Going forward to JAZZ and DNG, JAZZ CLM from my understanding is system centric. That is, CLM projects are created, each with their own RM, RTC, and QM areas, with the premise that each repository contains only those objects applicable to that application/system.
Can DNG house requirements from multiple systems and can this one repository be linked to multiple RTC/QM repositories?
If so, are there any downside/implications of implementing this type of structure?
For example – Change Proposals (CPs) for requirements.
· Can CPs, be linked to different RTC project areas?
· Does it track the from/to conditions?
· On CP approval, do changes automatically get applied/promoted in DNG or are there some additional steps required?
The above is only addressing requirements but similar considerations apply to the RTC and RTM side.
Your feedback would be appreciated.
2 answers
An RTC project area should be thought of as "a place where projects live".
A project area defines a set of process configuration objects, like work item types. Basically, all the information that is in the Project Configuration section of the Process Configuration tab of the Project Area editor.
Within a project area, you have a number of team areas, each corresponding to a team of people working together (a person can belong to more than one team). Each person has a specified set of roles in a given team area. So a project area in RTC does not contain a set of "systems", but rather a set of "projects".
The "systems" are defined as a combination of "components", where a component does not belong to a single project (or team) area, but rather can be worked on (in parallel) by all projects that have read access to that component.
Note that "project areas" are also used to define an access control group. Think of those as "access control areas", rather than "project areas", in order to keep from getting confused.
- Who should have access to view artifacts? Currently everyone with access to a project area can view all artifacts; permissions can be set at a detailed level for other permissions (create, modify, delete) using team areas within the project area.
- What richness in link types do you need when linking artifacts? You can define custom link types within a project area, but across project areas you can use only a subset of the system-defined link types.
- How big is the project area likely to grow: how many artifacts will your team(s) be creating over the next few years? DOORS NG does not yet scale to the same very large scale as DOORS (million+ objects in one project area). See the DOORS NG / RRC 4.0.1 performance report in the jazz.net library for details of current good performance levels (and yes this is an area the dev team continues to focus on -- and continues to make significant improvements release-to-release). Also I should mention that many organizations don't need this extreme scale, or don't need it in the next couple of years -- current performance levels are OK.
>> Going forward to JAZZ and DNG, JAZZ CLM from my understanding is system centric. That is, CLM projects are created, each with their own RM, RTC, and QM areas, with the premise that each repository contains only those objects applicable to that application/system.
See answer above
>> Can DNG house requirements from multiple systems and can this one repository be linked to multiple RTC/QM repositories?
Yes
>> If so, are there any downside/implications of implementing this type of structure?
See answer above. In addition a DOORS NG user has one more step when creating links -- they need to select the right RTC/RQM project area.
>> For example – Change Proposals (CPs) for requirements.
- Can CPs, be linked to different RTC project areas?
- Does it track the from/to conditions?
- On CP approval, do changes automatically get applied/promoted in DNG or are there some additional steps required?
Comments
Thanks for the feedback, in hind sight I should have clarified my question.
First - your statement "across project areas you can use only a subset of the system-defined link types." What link types would you b referring do for cross-project linking?
As for my DNG project question - what I was attempting to get clarification on is using only one DNG project area to store multiple systems reqs. We have many systems which form part of our business apps. If all our various system reqs are stored within one DNG project, can subsets be linked to many CLM-type project areas (RTC, RQM)? Where I see a downfall is in using the CLM setu - where would CP's get tracked if there are many RTC areas.
cheers