![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: alternative to baseline Topic Summary: Created On: 25-May-2004 20:37 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
Telelogic DOORS
» Change Management
»
alternative to baseline
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.