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: Any white paper for using DOORS in incremental development project
Topic Summary:
Created On: 8-Mar-2007 07: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.
 8-Mar-2007 07:42
User is offline View Users Profile Print this message


rajavel subramanian

Posts: 13
Joined: 6-Mar-2007

Hi,
I am looking for white papers on using DOORS for incremental development project.
I have framed an approach for the same.  I want to compare my approach if there are any documents already available on it.
Report this to a Moderator Report this to a Moderator
 8-Mar-2007 22:21
User is offline View Users Profile Print this message


Paul Miller

Posts: 376
Joined: 2-Oct-2002

Hi Rajavel,

I don't have any papers to offer you but this topic interests me as well and have been investigating whether DOORS can handle truly incremental developments. I would be very interested to read what you have if you can email it to me at pmiller@eurocyber.biz

One of the problems with managing incremental developments is the overlapping nature of each increment and how to manage the documentation that must support each increment to their conclusion.

Each increment has dependencies on a previous increment that may still be active. Any problems or major changes to requirements and design in one increment will most likely have been inherited by and have an impact on other subsequent increments that have already started. This requires very tight configuration management practices to be in place so that impacts can be handled before problems start repeating themselves over and over and getting worse as each increment moves further into their life-cycle.

When it comes to managing requirements and design in incremental developments, this essentially requires a Branch, Merge and Rebase configuration management model similiar to what software developers use to manage their source code. Each Branch is essentially an increment where changes\fixes in one increment can be merged or rebased into others. Sounds simple but this in itself is compliacted and requires a lot of humanware as well as tools to help.

DOORS unfortunately does not have any Branch, Merge or Rebase type functions so this has to be simulated somehow. From my investigations, it requires a lot of data modelling, schema development with a lot of DXL, discipline and close management. It's a customisation development in itself which will require testing and bug fixing to get it right.

-------------------------
Paul Miller
Specification Practices Specialist,
EuroCyber,
Melbourne, Australia.
Mobile: +61 (0)418 135 103
Web Site: http://www.eurocyber.biz
E-mail: miller@eurocyber.biz">pmiller@eurocyber.biz
Report this to a Moderator Report this to a Moderator
 19-Mar-2007 13:37
User is offline View Users Profile Print this message


Andrew Tagg

Posts: 151
Joined: 26-Oct-2004

This is also an area that intrerests me a lot. As Paul says, DOORS was never really designed to do this so it will need some heavy programming to get anything like good results. I have recently had some success with a branch and merge model, but it is far from ideal. I basically 'branch' by doing a copy paste of a whole DOORS Project, and then on top of this run some highly intrusive trigger based DXL that prevents users from modifying anything in a module unless they have selected a change request from a drop down menu. The change request in this case is just a module full of objects, where each object represents a change request. Since I know the selected change request, more triggers make a link from any changed object to the chosen CR. At the same time, I drop the name of the change request into the object history before and after that change. I now have a situation where by following the links from the change request object, and parsing the history for the linked object, I can pull out the before and after text for that change. (....still with me?) This allows me to 'export' a package of changes from one branch to another. Well, at least it exports about 60-80% of the changes, the rest are listed as 'too difficult'. It is all rather clunky at the present time, but I am still polishing at the moment, but the basic idea is as outlined above. Regarding white papers, there are some good ones here: http://galactic-solutions.com/GalacticWhitePapers.htm Rgds Andrew.

-------------------------
Andrew Tagg
Thales Air Systems, Melbourne
Australia.
andrew.tagg@thalesatm.com
Report this to a Moderator Report this to a Moderator
 19-Mar-2007 13:37
User is offline View Users Profile Print this message


Andrew Tagg

Posts: 151
Joined: 26-Oct-2004

BTW, anyone know how to get the line breaks to appear in posts on this site. grrrrrrrr.!!!###@!!

-------------------------
Andrew Tagg
Thales Air Systems, Melbourne
Australia.
andrew.tagg@thalesatm.com
Report this to a Moderator Report this to a Moderator
 19-Mar-2007 13:47
User is offline View Users Profile Print this message


Paul Tiplady

Posts: 176
Joined: 28-Oct-2003

Two things:

Use the 'Reply' tag in text, not the 'Quick Reply' icon.
Use the HTML editor, not the WYSIWYG one, in your personal options.

That should do it...

-------------------------


Paul dot Tiplady at TRW dot com
TRW Automotive
Report this to a Moderator Report this to a Moderator
 19-Mar-2007 16:08
User is offline View Users Profile Print this message


Dan Hopping

Posts: 75
Joined: 21-Nov-2002

I am also in the same pickle. In fact, I am also being requested to keep a record of EVERY deleted requirement starting at feasibility. Please don't ask, it will only serve to get me going off on a tangent here.
Anyway,

My thoughts so far....
It seems to me if you create an Enumerated type attribute (let's call it 'RELEASE VER') that has a multi-select for every version of the document released, then you could accomplish (in a fashion) accounting for branch and merge if:
1) you never actually delete any true requirements.
2) 'edits' to any requirement require it to become a new requirement with the old requirement marked for deletion in this version. Any requirement could be 'reinstated' in following versions (or branched versions) by maintaining the proper versioning in the 'RELEASE VER' attribute.

so... For any version of a document, the inclusion of requirements would be based on the RELEASE VER attribute only. With this in place, your document releases could appear as if a true 'branch and merge' process were in place AND you can show references to DELETED requirements.

The only major issue I see is that you would either have to turn history off for this attribute (not good) or not use impact analysis (also not good).

To that end, I toyed with the idea of creating two attributes "VALID START VERSION" and VALID END VERSION". This would work for history / impact analysis but not the 'branch and merge' functionality... UNLESS... I parse these two attributes during output to determine if the current requirement was reinstated after deletion... Sounds slow but do-able.

I'm not sure there is a development team anywhere in the world that could be 'careful' enough with requirements during feasibility (and maybe development) to keep the final documents from containing MANY references to deleted requirements. With that said, it seems like it should 'functionally' work.

Any thoughts, suggestions, ideas....
Report this to a Moderator Report this to a Moderator
 19-Mar-2007 21:36
User is offline View Users Profile Print this message


Paul Miller

Posts: 376
Joined: 2-Oct-2002

DOORS essentially needs features similiar to what is provided by Telelogics Synergy Change and CM tools - an observation made by some of my Synergy users. DXL was never meant for this sort of thing and the current DOORS DB architecture certainly wasn't cut out for it either. Would like to think that the DOORS XT product might be more conducive to this as it evolves.

Baseline sets has been touted as a means for managing incremental type releases but it assumes that when a new increment starts, the previous one will have no further changes or can somehow be retrospectively added into the current increment which just doesn't work - Baseline sets is more suited for evolutionary type developments. I've looked into using attributes similiar to Dan's approach but it gets messy and clunky as users can, and do, evade filters you may have set to display objects associated with a particular release, and you can't capture specific releases in a baseline as DOORS only supports baselining a whole module and not groups of objects - so now your change tracking\auditing gets a bit screwed up as it can't be tied into a specific release.

I reckon Telelogic needs to get onto this one as the demand for Incremental & Agile type development approaches in Software Intensive domains such as the Finance and Telelcommunications sector is very high.

-------------------------
Paul Miller
Specification Practices Specialist,
EuroCyber,
Melbourne, Australia.
Mobile: +61 (0)418 135 103
Web Site: http://www.eurocyber.biz
E-mail: miller@eurocyber.biz">pmiller@eurocyber.biz
Report this to a Moderator Report this to a Moderator
 20-Mar-2007 08:27
User is offline View Users Profile Print this message


Tony Goodman

Posts: 1098
Joined: 12-Sep-2002

INTEGRATE Systems Engineering provide tool support for incremental development.
If you have never heard of them, then it will be enough to know that Jeremy Dick works for them!

They provide a series of DOORS addon products under the brandname of KEYPAQ. One of these is called KeyChange which is a tool for managing product familiies. Essentially it allows multiple versions of information to be contained within a single module.

My description does not do it justice, so take a look at their website.
Integrate

-------------------------
Tony Goodman
http://www.smartdxl.com
Report this to a Moderator Report this to a Moderator
 20-Mar-2007 13:53
User is offline View Users Profile Print this message


Andrew Tagg

Posts: 151
Joined: 26-Oct-2004

It sure looks good, Im wondering if it essetially caches the doors database ? If not it must surely suffer from the basic speed limitations of the doors database design? Would love to hear form anyone using it.

-------------------------
Andrew Tagg
Thales Air Systems, Melbourne
Australia.
andrew.tagg@thalesatm.com
Report this to a Moderator Report this to a Moderator
 28-Mar-2007 10:16
User is offline View Users Profile Print this message


Anders Falck

Posts: 2
Joined: 11-May-2006

Many thanks, Tony, for an interesting tip.
Report this to a Moderator Report this to a Moderator
 6-Sep-2007 14:29
User is offline View Users Profile Print this message


Scott Boisvert

Posts: 348
Joined: 14-Apr-2006

We had a demo about two weeks ago from the Guys at integrate.  What they have is really cool and solves the incremental development problem.  However, its still in Beta.

Now this whole add on to DOORS is written in DXL, so what worries me is the scalability of the product as we have a huge database.

Basically the way it works is by using the convetions that most people here have all ready been using, but it just automates it. 

Basically you create packages of modules.  A package would be like a version of your product.  Each module gets has a versioning attribute added to it by KeyChange that is used to "filter" the module for the particular version you are working on.  There are two different types of attributes, a change to one type will cause the replication of the object, a change to the other will cause the replication of the attribute.

There is also a change management component to the add on, that will look for conflicts before implementing a change.

Like Tony I'm not doing the product much justice, but I can say that it looks like a really good answer to this issue with DOORS.

We are currently working on getting NDAs in place so that we can get an evaluation version of the software.  I'll post an update after I have a chance to "play" with the product.


-------------------------
Scott Boisvert
Engineering Tools Administrator
L-3 Communications - Avionics Systems
scott.boisvert@l-3com.com
Report this to a Moderator Report this to a Moderator
 10-Dec-2007 16:03
User is offline View Users Profile Print this message


Scott Boisvert

Posts: 348
Joined: 14-Apr-2006

Apparently KeyChange has been put on the back burner for now. Integrate has decided to focus on the KeyPAQ or KeyTrace (I forget which). Never did get a chance to play with the demo/beta version.

-------------------------
Scott Boisvert
Engineering Tools Administrator
L-3 Communications - Avionics Systems
scott.boisvert@l-3com.com
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.