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: DOORS Best Practices
Topic Summary: The best way to use/admin DOORS
Created On: 28-Aug-2007 17:13
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.
 28-Aug-2007 17:13
User is offline View Users Profile Print this message


Sarah Moore

Posts: 5
Joined: 24-Apr-2006

We are a relative newcomer to DOORS only having used it for the last year.  As we increase our use of DOORS and look towards integrating it with Synergy Change and Quality Center we are looking to create a set of Best Practices.fficeffice" />>>

>

We already have the linksets determined so that we can regulate the source modules, target modules and direction of linking.  I have also read in another thread, about the use of a naming convention for views with any non-compliant views being deleted as a matter of policy. However there must be many other things that more experienced DOORS users have discovered along the way that are good things to implement or regulate.  In the absence (I read in another thread) of how-to-use books available I was wondering if DOORS users in this forum would be willing to share the things that they feel are essential to keeping things running smoothly.

>

Thanks
>

Sarah Moore
Senior Project Analyst
TRG
sarah.moore@trgc.com

>
Report this to a Moderator Report this to a Moderator
 28-Aug-2007 19:41
User is offline View Users Profile Print this message


Kevin Murphy

Posts: 206
Joined: 15-Jul-2005

Sarah,

I'll plan on having more posts, but just some quick thoughts.

1. DOORS is not Access. DOORS is not Oracle. DOORS is a PUBLIC database. Even if there is one administrator, anything that administrator does can affect everyone else. The admin should help determine naming conventions and schema and then enforce them even when management dictates otherwise. I've seen databases with different modules named the same thing (ex. 5 modules named "SRS" but located within different folders).

2. Along the same lines, make the database as simple to navigate as possible. Make the heirarchy of folders and modules imply the major links. New users should not have to spend a lot of time thinking to themselves, "Where is this type of document?"

3. Keep attribute creep under control. The more attributes, the more management of those attributes and the less likely the attributes are to be updated, which is a lose-lose.

4. Do not bend over backwards for the users--including management. When you hear, "Can you write some DXL to <do some custom function/replace some function that already exists/create a new interface>" stop it in its tracks. What will happen is that you'll have an application running on top of DOORS, a recipe for disaster in most cases.

5. DOORS is not Access!

6. Set expectations. Telelogic's sales people all sell DOORS as a silver bullet. It's not.

7. Ensuring process is followed is more important than ensuring anything else. Have a process for module creation, schema modification, module updates, etc. DOORS does what it does really well, but doesn't do what it doesn't do well at all, even when you try to DXL it.

8. Limit users' write access to the database wherever possible. People should only have write access if they have an ongoing need.

9. Baselines exist, but cannot be reverted to. Don't ever let users assume that because a module was baselined that if they screw something up their butts are covered because the baseline exists.

10. Training for everyone who uses DOORS.

11. DOORS is not Access! It's public and shared! It is not YOUR database.

Those are just off the top of my head....

Kev

-------------------------
Kevin Murphy
http://www.baselinesinc.com
The Requirements Management Experts
Report this to a Moderator Report this to a Moderator
 29-Aug-2007 14:14
User is offline View Users Profile Print this message


Andrew Tagg

Posts: 151
Joined: 26-Oct-2004

Ensure a rock solid plan for enforcing link directions, what can link to what, and which link modules are used to store the links.

-------------------------
Andrew Tagg
Thales Air Systems, Melbourne
Australia.
andrew.tagg@thalesatm.com
Report this to a Moderator Report this to a Moderator
 29-Aug-2007 14:16
User is offline View Users Profile Print this message


Andrew Tagg

Posts: 151
Joined: 26-Oct-2004

Create the default DOORS links module in every folder and project. Then delete (but don't purge) it. Ensure only administrators can undelete it. This will help to minimise stray linking.

-------------------------
Andrew Tagg
Thales Air Systems, Melbourne
Australia.
andrew.tagg@thalesatm.com
Report this to a Moderator Report this to a Moderator
 29-Aug-2007 14:17
User is offline View Users Profile Print this message


Andrew Tagg

Posts: 151
Joined: 26-Oct-2004

Create groups for users and ensure every user is allocated to a group. Only ever assign user rights to groups, never to individuals.

-------------------------
Andrew Tagg
Thales Air Systems, Melbourne
Australia.
andrew.tagg@thalesatm.com
Report this to a Moderator Report this to a Moderator
 29-Aug-2007 14:23
User is offline View Users Profile Print this message


Andrew Tagg

Posts: 151
Joined: 26-Oct-2004

If you create your own dxl tools, keep them under configuration control. CVS or whatever you have to hand.

-------------------------
Andrew Tagg
Thales Air Systems, Melbourne
Australia.
andrew.tagg@thalesatm.com
Report this to a Moderator Report this to a Moderator
 29-Aug-2007 14:28
User is offline View Users Profile Print this message


Andrew Tagg

Posts: 151
Joined: 26-Oct-2004

Organise a Change Control Board (CCB) with your stakeholders. No creation of any new Projects, Folders, Modules, Attributes, Link Paths, until it has been discussed (and minuted) by the CCB.

-------------------------
Andrew Tagg
Thales Air Systems, Melbourne
Australia.
andrew.tagg@thalesatm.com
Report this to a Moderator Report this to a Moderator
 31-Aug-2007 14:26
User is offline View Users Profile Print this message


Sarah Moore

Posts: 5
Joined: 24-Apr-2006

Kevin, Andrew, thanks for the great tips. Some of them we are already doing - I have the way links are created locked down for users as much as I can. Attributes are also heavily controlled, especially the enumerated values so that we don't have 12 different versions of the same list across the database. My job for this week has been to 'clean up' the user base to make sure everyone in DOORS is assigned to a group and that rights are given to the group. There are times though that I have given rights to the user themselves. These are times when the group needs read access to a module but only one or two members of the group are actually allowed to write in the module. Mostly my 'sheep' are all in their flocks; I just have a few stray ones that seem to have wandered off on their own and need to be brought back. Sarah
Report this to a Moderator Report this to a Moderator
 31-Aug-2007 15:13
User is offline View Users Profile Print this message


Kevin Murphy

Posts: 206
Joined: 15-Jul-2005

Sarah,

Don't assign users to modules. If you have to create a new group for the module, do that instead.

Users come and users go, but groups stay forever. There are implications in module sharing and sharable edit setup when you just assign users to modules.

No problem on the advice. And if you can, learn some DXL, to at least report on where the attribute cleanup should be focused. Some basic DXL and VBA can save you days of work.

Kev

-------------------------
Kevin Murphy
http://www.baselinesinc.com
The Requirements Management Experts
Report this to a Moderator Report this to a Moderator
 7-Feb-2008 22:28
User is offline View Users Profile Print this message


Brenda Cornell

Posts: 29
Joined: 7-Jul-2005

With regard to using groups. Do you utilize LDAP and maintain your groups that way, or do you create your groups in DOORS? We have 8.1 DOORS and were going to switch to LDAP, but I did NOT like the fact that we would have to go to our LDAP admins to control groups. I had heard a newer version of DOORS utilizes LDAP more efficiently and can deal with groups better. Anyone have any best practices with LDAP??

-------------------------
Brenda Heiss Cornell
Report this to a Moderator Report this to a Moderator
 13-Feb-2008 17:59
User is offline View Users Profile Print this message


Joseph Dubin

Posts: 26
Joined: 1-Mar-2006

If you manage users in DOORS using LDAP, you also have to manage groups using LDAP. We use LDAP and maintain our groups in LDAP. At my company, our LDAP admins provide a self-service intranet website where we can create and maintain the LDAP groups we need, which makes it easy.

-------------------------
Joseph DUBIN
joseph.dubinNOSPAM@freescale.com
Freescale Semiconductor, Inc.
Report this to a Moderator Report this to a Moderator
 5-Mar-2008 20:58
User is offline View Users Profile Print this message


Karrin Gordon

Posts: 4
Joined: 3-Jan-2006

We have DOORS 8.1 configured to use our corporate ldap, using both Group of Users and Group of Groups. As the DOORS DBM, I work with the team to determine how many groups they need to adequately control access to their project, and the privileges required by each group. I then request the creation of the ldap groups by our ldap admins, but the teams are then responsible for requesting the addition/removal of users to those groups (also executed by the ldap admins). This shifts the accountability of controlling DOORS access to the teams. We are also able to leverage our corporate policies and infrastructure for password resets, and audit items like employee termination, removing these types of maintenance tasks from the DOORS DBMs. A cautionary note: currently, Telelogic has no plans to support Dynamic Groups for corporate ldaps, so your ldap must be configured for Static Groups if you want to use ldap groups in DOORS.
Report this to a Moderator Report this to a Moderator
 20-Mar-2008 18:18
User is offline View Users Profile Print this message


Gordon Woods

Posts: 35
Joined: 2-Mar-2007

Back to the original thread:

Define a Data model
Draw out a data model.
Identify each type of module according to its function.
Name the links according to the function they perform ( ie "satisfies", "verifies") rather than "SRD to URD Links"
the direction of the links is important - have the links flowing in one overall direction - usually detailed specs as source and high level specs as target.
Do not have multiple routes.
Publish it so all users are aware (this can be done using DOORS itself and some dxl )

Implement in DOORS
Identify all modules along the same lines as in the data model
use the same name for the link modules as in the data model
enforce the data model using mandatory links, purged DOORS Links etc
co-locate all the link modules in a common area and control access
use linksets for multiple occurrences of the same type of link, rather than multiple link modules.
Apply access controls according to what the user groups should do - not what they would like to do

- and if you want a product that controls all this then there is one available
see www.integrate.biz


--------------------
Gordon Woods
BAE Systems (Operations) Ltd
gordon.woods@incose.org
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.