It's all about the answers!

Ask a question

Managing Templates, New Projects, Process Sharing, Type Systems, etc.

Glyn Costello (13635) | asked Sep 11 '19, 2:42 p.m.
edited Sep 11 '19, 2:44 p.m.

 Dear all, 

I'd like to know people's experience with handling and maintaining templates in general across the RM, QM and CCM (RTC)) applications. 

I'm using global config to build complex system projects for requirements, test and planning but the general format and outline of these systems projects is pretty similar. 

At the moment I see many manual steps, but would like to know if there are built in tools to help with the process?

Fundamentally, I want to have all Project Areas, Components, Teams Areas, etc. using the same type system in RM (maintainable with changes to the type system), being populated with the same templates in RM, using the same type system in QM and process, and for every new RTC PA to share the same process configuration including the ability to update the master and for consumers to update. But also, to be able to do this in as few "new project" steps as possible from the Create Lifecycle Project interface in JTS!

- Creating lifecycle projects using process templates I've created
- Creating lifecycle projects that consume a shared process from another PA (from the JTS admin page)
- Creating a default stream in each component ready to import the type system using the type system management tool on GitHub JazzCommunity (this works fine, just need a nice way of creating the first stream in each component to have the correct description tag). 
- Pre-populated timelines, iterations, etc. when creating a new Lifecycle Project (Using Eclipse project initialisation?)
- Pre-populate a new RTC Lifecycle Project with typical project tasks applicable to all projects upon PA creation. 

I can't be the only person who has to regularly create new projects and maintain a type system/templates/processes across these projects? 

Hoping there's someone else out there willing to share their experience with the above. 



3 answers

permanent link
Carol Watson (71015) | answered Sep 11 '19, 3:54 p.m.

 Hi Glyn,

We use DNG only, without Global Configuration, but I think the concept is the same.  If you create a "Project" that has the Properties (Artifact Types, Attributes, Link Types, etc.) you wish to use for all projects, you can create a Project Template from that Project.  You can choose to include all of the below items (or not) in your Template.  Once you have the Project Template, when you create a new Project you can import those properties into the new project. 

Hope this helps.


Geoffrey Clemm commented Sep 12 '19, 10:42 p.m.

Yes, when you create a new component in DNG with GC turned on, it will ask you "which template do you want to use to initialize the new component". 

permanent link
Jean-François CHAPELLE (4412) | answered Sep 13 '19, 2:54 a.m.
Hi Glyn,

we have the same needs ...

Our projects contain a lot of components and their maintenance is very long and expensive because completely manual. The DOORS NG component is a true "false good idea", because implemented anyhow. At the project level, there is no concept of inheritance compared to a master component, which could bear the common characteristics of artifacts, views, permissions ...

The architecture of the "components" is a real calamity! And if you do not need to use them, especially, do not use them at the risk of seeing your administration tasks increase significantly!

The "Template" is also another "false good idea" because the objects created from this template are only obtained by copy. If the template evolves, it is possible to re-apply it on the component, but only the modifications and additions of characteristics are taken into account!

For now, all administrative actions are done manually, with all possible sources of error imaginable. On the other hand, we have not yet found a reporting function that could help us to establish a state of our configuration to, at least, identify gaps.

Jazz is a set of tools with a lot of potential, unfortunately it suffers from important design errors and has not yet been industrialized. Its administration is expensive, its documentation is incomplete and we find it very difficult to find training sessions, in France, to allow us to progress on the subject.

If we consider only DOORS / NG (Requirements Management), we consider that the transition from DOORS 9.x to DOORS NG is a very severe functional regression (at times, we think that the designers of DOORS / NG have learned nothing from DOORS, and it's a shame)

We have issued hundreds of RFEs, without much success today. We hope that versions 6.0.6 and 7.x fill the serious gaps that we have detected (we are now in 6.0.5).


permanent link
Ian Barnard (1.9k613) | answered Feb 03 '20, 12:27 p.m.

Hi Glyn - this article talks about ways to manage DOORS Next Generation type system across projects

Your answer

Register or to post your answer.