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: Delta to an old baseline
Topic Summary:
Created On: 28-Jul-2006 15:49
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-Jul-2006 15:49
User is offline View Users Profile Print this message


Mike Ramsey

Posts: 2
Joined: 20-Jul-2006

I am a new DOORS user.  My question has to do with getting DOORS to handle delta's to old baselines.  Consider the following scenario.

Software requirements are frozen for Build "d".
Work begins on Build "e" requirements changes.
During the run up to Build "d" testing, a defect is found.
The CCB decides to fix the Build "d" requirements baseline.

If the Build "d" requirements baseline was frozen using a Major baseline and if "current" contains incompatible changes then I am between a rock and a hard place.  I know that if I archived the Build "d" baseline I can recover it to a new project and make the change there.  However the new project would be a complete copy; that is, an independent baseline.  If the baseline is large then this solution is uncomfortable.

I suppose that what I am looking for is support for a dependent delta baseline.  Since the delta is to an old baseline the change can never be directly applied and must be repeated in current if it is to survive. The CR/Defect that spawned the change would have to stay open until that change was either made to current or deemed incompatible to (and hence unneeded in) current.

How do others handle this scenario?

--Thank you,
--Mike

Report this to a Moderator Report this to a Moderator
 31-Jul-2006 08:39
User is offline View Users Profile Print this message


Robert Swan

Posts: 86
Joined: 14-Apr-2005

It sounds as if you have a process problem rather than a DOORS problem. If build d has been declared as part of the projects baseline then the testing should proceed against that baseline. Faults should be acknowledged and accepted by raising a concession on the built system. An alternative is to undo all the changes made for the next baseline (or at least those that are incompatible), make the correctiion, issue that at 'e', then reintroduce the changes.
Report this to a Moderator Report this to a Moderator
 31-Jul-2006 17:20
User is offline View Users Profile Print this message


Mike Ramsey

Posts: 2
Joined: 20-Jul-2006

Robert,fficeffice" />>>

 Thank you for your reply. 
>It sounds as if you have a process problem rather than a DOORS problem.

As has often been said before, "change happens".  The baselining of 'd' could have been driven by the need to both freeze 'd' for development and to allow pent up work on 'e' to begin.  But situations occur where the best option for the program is to reopen 'd' and make an emergency change.  As much as we would like the world to conform to our theories it sometimes doesn't.

A key to good CM is to always maintain a single successor-predecessor relationship between baselines.  Sometimes you need a delta to a predecessor baseline.  When I diagram such things I use a diode symbol since the flow is one way (down but never back).  A manual effort is required to merge such changes back into the current baseline.

>An alternative is to undo all the changes made for the next baseline (or at least those that are
>incompatible), make the correction, issue that at 'e', then reintroduce the changes.

Sounds painful but thank you for the thought.

 

Report this to a Moderator Report this to a Moderator
 3-Aug-2006 12:46
User is offline View Users Profile Print this message


Anthony Brown

Posts: 6
Joined: 8-Apr-2006

Hi Mike,

I discussed this at great length with my colleagues in a previous job. We thought of two ways of dealing with it. Unfortunately I never got chance to put either of them into practice but I'm sure somebody else here will have.

1. As you suggest, maintain a separate copy of the module/project for each release of your product. Yes the magnitude of data can become unwieldy. You could consider later releases just containing delta's to earlier releases to reduce duplication. Use a link module to link modified (and unmodified if applicable) requirements to their predecessors.

2. Use attributes to identify which releases of the product the requirement applies to. Could be done using a 'tick box' multi-valued enumerated type or by 'Introduced at' and 'Removed at' attributes.

Hope this helps. If you come up with a better solution I would be interested to hear it!

Tony

P.S. Sorry this post appears twice - don't know why!



Edited: 3-Aug-2006 at 12:48 by Anthony Brown
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.