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: alternative to baseline
Topic Summary:
Created On: 25-May-2004 20:37
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.
 25-May-2004 20:37
User is offline View Users Profile Print this message


Catherine Yan

Posts: 43
Joined: 4-Aug-2003

Hi there,

We need to do baseline to get the content of modules at a certain time for our traceability. But we don't want to do too many of them. It will be really hard to go check the history before baselines. We need an alternative to get a frozen view.

What could be the alternative?

Thanks!
Catherine
Report this to a Moderator Report this to a Moderator
 26-May-2004 08:03
User is offline View Users Profile Print this message


Pieter DE WAARD

Posts: 73
Joined: 11-Jul-2003

Catherine,

I have no clear answer for you, but some thoughts. We have a policy to baseline whenever we deliver, either to partners or to the customer. In this way there is never a question on database contents delivered. It is frozen with a given reference. Yes, this cause the BL index to grow more rapidly than would otherwise be the case. In the beginning we had to decide how to manage contract versions vs. baseline reference. Maybe this is your problem, there exists formal documents referring to baselines, which necessitates updating these documents when baselines change? Our solution was to de-couple the two. The contract gets a version number, which is generated from baseline X.

Moreover, baselining is the tool in DOORS to freeze the status. Why invent another method? I would suggest to adapt your process to fit the tool, and not vice-versa, if possible.

-------------------------
Pieter de Waard
www.nhindustries.com
Report this to a Moderator Report this to a Moderator
 29-Jun-2004 14:37
User is offline View Users Profile Print this message


Hazel Woodcock

Posts: 38
Joined: 4-Oct-2002

You could archive the module and place the resulting file in the change management tool of your choice. This way, you can restore the module if you want to return to that position.

I understand the reluctance to baseline because of the history issue, but don't forget that you can compare any two baselines (or any old baseline with the current version) to see what has changed over a longer period.

For one particular project I had a dxl script running to trigger a dialog box with change information including a 'Last Changed' Attribute - this was a reference to the published version number, this would help tie down the timing of the change to a particular baseline if you need more detail on the changes.

-------------------------
Hazel Woodcock
Report this to a Moderator Report this to a Moderator
 29-Jun-2004 15:45
User is offline View Users Profile Print this message


Roy Bond

Posts: 39
Joined: 25-Mar-2003

Catherine,

If you don't want to use baselining, but want to be able to periodically freeze a module (without changing user access rights), you could try applying a form of config control.

We looked into methods of controlling access to modules so that we could link access to a formal change management system. One method was to use a trigger to look for the existance of a file (like a looking for a Key) or at the value of a Module level attribute (or switch).

Here is an example of the sort of thing we considered :


// Control_Edit_Mode.dxl

/*

DXL called by Trigger activated when opening a Formal Module to control access to
the Module Objects based on the issued state of the Formal Module.


Trigger Definition :

trigger( "Control_Edit", module, post, open, 1, "#include <Triggers/Control_Edit_Mode.dxl>" )

*/


// **********************************************************************************
// Constant and Variable declarations


Module m = current

Object o = first m



// **********************************************************************************
// Main Body of DXL Script



bool dbase_admin = false
User user


// Check to see if Module is has been placed into PVCS

if (exists attribute "Edit Module") {

bool SwEnabled = m."Edit Module"


if (!SwEnabled) {


// Loop around Database Admin Group and compare current user to list of group members

Group Admin_Group = find("Database Administrator")

for user in Admin_Group do {

string uName = user.name

if (uName == doorsname) {

dbase_admin = true

}
}



// If current user is a member of the Database Admin Group then Bypass Downgrade

if (!dbase_admin) {

downgrade (m)
}
}
}



As I said above, we looked at this, then went for a very complicated, but very effective integration of DOORS with our configuration management tool PVCS Dimensions.



Regards,

Roy Bond
MTU Aero Engines
Munich

roy-david.bond@muc.mtu.de
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 0 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 0 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.