![]() |
Telelogic DOORS (steve huntington) | ![]() |
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 |
![]() |
![]()
|
![]() |
|
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. |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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.... |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
Many thanks, Tony, for an interesting tip.
|
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.