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: CPS_FixAnomalies
Topic Summary:
Created On: 7-Nov-2008 16:42
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.
 7-Nov-2008 16:42
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Back in the v5.2 days I wrote a massive script CPS_FixAnomalies.dxl to address the numerous bugs in the CPS system; where an individual CP was not consistent with itself. Several bugs were introduced by the CPS system, one nasty one introduced when a CP initiated through DOORSNet. Anyway, I figure to update this script for v8.3 and was looking for incite ..err.. insight.

There seem to be two philosophies for CPS: [1] CPS Reports should show exactly what changes the CP will make when its applied [2] CPS Reports should show exactly what the Source object will look like after the CP is applied. That is, will the RCRB approve changes or do they want to approve the final Source Object? Philosphy [1] makes me want to erase usused Proposed values; Philosophy [2] makes me want to set unused Proposed values.

Rejected and Applied CPs are ignored. I wonder if the script should consider making changes to Approved CPs. I wonder if the script should consider making changes to InReview CPs. The script should indeed make changes to New and OnHold CPs.

There are Defaulted-Inherited issues that I won't get into here.

For Deletion CPs, all the Using flags should be false. I wonder if the Proposed values should be null, or if they should be the same as the Source values. I believe the CPS will NOT modify an obj-attr value even if the Using flag is true, for Deletion CPs.

For Insertion CPs, it seems to me that all the Using flags should be true. If the Proposed is not the same as the Source, I think the script should set a null-Proposed value to the Source value, but I'm not sure what to do if the Proposed value is not the same as the Source. If the source changed after CP generation, does the user want the new object to have the old Source value, or the new?

For Modification CPs, things get sticky. If a Using flag is true but the Proposed value is the same as the Source value (that is, the CP proposes making a change that won't change anything), should we set the Using flag False? If the Using flag is false, should the Proposed value be null or should we set it to the Source value? If the Using is false but the Proposed value is not the same as the Source, now what?

Thoughts?

- 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.