Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic DOORS (steve huntington)
Decrease font size
Increase font size
Topic Title: Why should I NOT use default link sets
Topic Summary:
Created On: 4-Jan-2006 14:40
Status: Post and Reply
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
Quick Reply Quick Reply
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
 4-Jan-2006 14:40
User is offline View Users Profile Print this message


Robert Fritz

Posts: 7
Joined: 22-Dec-2005

Someone has recommended that I not use default link sets. He's quite adamant about it. But I can't see any advantage to it. Of course, there's little downside either. So I guess I'll avoid default link sets.

Can anyone enlighten me about why I shouldn't use default link sets?
Report this to a Moderator Report this to a Moderator
 5-Jan-2006 08:42
User is offline View Users Profile Print this message


Robert Swan

Posts: 86
Joined: 14-Apr-2005

If he means 'don't use the DOORS default linkset' then I would agree with him. All links would go through one link module, which restricts the clever things you can do with them.

You should aim to define your own default linksets between modules so you can control the target of the link, provide traceability, and prevent users inadvertantly creating incorrect links.
( example:- User requirements are linked to system design via a 'satisfies' linkset.
                 User requirements are linked to acceptance plan via a 'acceptance' linkset.
   DOORS user is prevented from accidently linking acceptance and requirement with 'satisfies'. )
Report this to a Moderator Report this to a Moderator
 5-Jan-2006 08:47
User is offline View Users Profile Print this message


Tony Goodman

Posts: 1098
Joined: 12-Sep-2002

Not sure if you mean the default link module, or linkset pairings, but the answer is the same.

Once you have set up your modules and decided on the relationships between them, you need a way to ensure that users can only create links that make sense within your project schema.

This is achieved by setting up Link Module Descriptors or Linkset Pairings between modules. This enforces the schema and prevents spurious links.

If you do not set up your linkset pairings then users are free to create links between modules that should not be linked. Worse, they are free to create links between two modules using the wrong link module. This really messes up your traceability and is very hard to fix.

If you have not setup your linkset pairings and you create a link, then doors will use the default link module, usually DOORS Links. You can prevents this by creating and soft deleting a link module called "DOORS Links" in EVERY folder of your project.

It is also a good idea to avoid putting all your links through the same link module - this will give you greater control over your traceability analysis.

-------------------------
Tony Goodman
http://www.smartdxl.com
Report this to a Moderator Report this to a Moderator
 10-Feb-2006 00:07
User is offline View Users Profile Print this message


Thomas Young

Posts: 20
Joined: 12-Apr-2005

I agree -- with exceptions -- with Tony G that using LSPs (Linkset Pairings) is the best way to enforce correct linking. We use them extensively here. TOO extensively. Here's the situation: A project contains 30 reqmt modules, each of which has 30 LSPs defined, (allowing for vertical and horizontal parent-child linking). That's a total of 900 LSPs defined in the project, and you may know that LSPs are stored at the project level, so one database file contains the 900 LSPs.

Our linking performance is terrible! To manually create ONE link takes a minute and 40 seconds on average. Running the Link-by-Attribute tool takes 5-7 hours (to create on the order of 500-1000 links).

What revealed that LSPs were to blame? Testing with and without the 900 LSPs, in a test database, revealed they were the cause of the linking latency. After removing all of the 900 LSPs, it took a fraction of a second to create a link.

We are probably going to remove almost all of the LSPs, and use the deleted "DOORS Links" link module, education, and other means to maintain legitimate linking.

Good luck!
Report this to a Moderator Report this to a Moderator
 10-Feb-2006 09:00
User is offline View Users Profile Print this message


Anton Drexler

Posts: 25
Joined: 9-Dec-2003

Hi Thomas,

I'm not quite sure why there are 30 LSPs defined for each module. It seems your project model is designed more like a spider web instead of a straightforward development process.

What are the respective roles of the 30 (!) modules to which one of your modules may be linked to, and what ist the semantics of the links then?

In general, there is no performance problem if you only define the LSPs which are really needed to map your development process (also if complex) to DOORS.

I'm quite interested in a further discussion of your situation; and I'm sure there will be a sensible solution to your problem.

Kind Regards
Toni

Report this to a Moderator Report this to a Moderator
 10-Feb-2006 17:12
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Our users don't make links. Instead they insert their desired target IDs in a variety of attributes. We've got a script that runs at night that actually creates all the links. There are other project policies required to support this, including unique (and short) module names and Module Prefixes that unambiguously identifies the target module.

- Louie
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 1 users logged in.
The most users ever online was 15 on 15-Jan-2009 at 16:36.
There are currently 0 guests browsing this forum, which makes a total of 1 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.