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: Database Schema / Information Architecture
Topic Summary: Methods to depict and manage your DOORS database information architecture
Created On: 14-Oct-2008 00:07
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.
 14-Oct-2008 00:07
User is offline View Users Profile Print this message


Matthew Thomas

Posts: 15
Joined: 14-Feb-2008

DOORS is infinitely flexible, and usually needs to be customised to best meet the needs of the organisation and/or project at which it is directed. Yeh?

With such power comes high responsibility. Responsibility for managing the customisation of your DOORS database. Responsibility for specifying it in advance with the input of process stakeholders. Of ensuring its evolving structure continues to meet its requirements. Maintaining the way that access rights are assigned to each user for each database element. Coordinating design updates across like modules. And how do you specify your DXL logic? If you had a process audit today, could you trace back to the reasons why your DOORS information architecture is as it is, and justify that it still meets its requirements?

Specifying and maintaining your DOORS information architecture is an onerous job. Does anyone have any views about best practice, and/or how it can be made much easier?
Report this to a Moderator Report this to a Moderator
 14-Oct-2008 14:11
User is offline View Users Profile Print this message


Andrew Tagg

Posts: 151
Joined: 26-Oct-2004

At the very least, keep all of your dxl under configuration control, with some type of 'rationale' information associated with each and every change to the code baseline. Of course, we all do this anyways, right?

-------------------------
Andrew Tagg
Thales Air Systems, Melbourne
Australia.
andrew.tagg@thalesatm.com
Report this to a Moderator Report this to a Moderator
 21-Oct-2008 11:39
User is offline View Users Profile Print this message


Robert Swan

Posts: 86
Joined: 14-Apr-2005

We have a defined Engineering and Requirements Management processes that DOORS supports (nb not the other way).
From that we have some defined basic models that cover the project work we handle. Projects may tailor the models by adding attributes/modules provided they can justify and document the deviations from the process.
Report this to a Moderator Report this to a Moderator
 21-Oct-2008 12:59
User is offline View Users Profile Print this message


Matthew Thomas

Posts: 15
Joined: 14-Feb-2008

Originally posted by: Robert Swan

We have a defined Engineering and Requirements Management processes that DOORS supports (nb not the other way).

Wise!

From that we have some defined basic models that cover the project work we handle. Projects may tailor the models by adding attributes/modules provided they can justify and document the deviations from the process.


OK, that's a pretty direct approach - like a template project with some accepted and exceptional variations? So how do you define the basic models, and their variations, and do you go as far as recording the justification for variations?
Report this to a Moderator Report this to a Moderator
 21-Oct-2008 13:06
User is offline View Users Profile Print this message


Matthew Thomas

Posts: 15
Joined: 14-Feb-2008

Originally posted by: Andrew Tagg

At the very least, keep all of your dxl under configuration control, with some type of 'rationale' information associated with each and every change to the code baseline. Of course, we all do this anyways, right?


You raise a very interesting point Andrew - configuration control of DXL. Would you like to share the details of your approach - in respect of the issues you've had to come by doing this?

When developing DXL, being able to easily switch the DXL in the DOORS directory to the working copy view of the CM database, and then back to known release points inbetween development stints, requires careful attention. Do you have any neat approaches here?
Report this to a Moderator Report this to a Moderator
 22-Oct-2008 13:23
User is offline View Users Profile Print this message


Andrew Tagg

Posts: 151
Joined: 26-Oct-2004

The approach used in my company is fairly basic but here is the high level view:

* The dxl baseline is stored in a CVS repository.
* Any development work is done in a checked out clone of the repository.
* Finished dev work is checked back in against a Change Request ( we have some in house tools for this, but must be some public domain stuff I would think) The change request number can be used to look up the 'rationale' for the change, again an in house system, but hey, you could use synergy or whatever.
* The working copy of the code is basically another checked out clone.

Like I said simple but the basics are:


* You can always back out a change by reverting to an old baseline.
* You can always tie the history of a change to a particular change request.
* Dev work is offline with respect to the 'working' code base.

-------------------------
Andrew Tagg
Thales Air Systems, Melbourne
Australia.
andrew.tagg@thalesatm.com
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.