![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Two separate DOORS databases: Integration Topic Summary: Created On: 9-Oct-2007 06:42 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
I'm in a situation where two companies using DOORS for a single project have come together where we (the systems integrators) have just started using DOORS for this particular project. One of our subcontractors have been using DOORS for a while, however, how is it possible to integrate several of their modules and links between the two?
As far as I am aware its impossible to export a module from them so that we can import it. Any ideas? |
|
![]() |
|
![]() |
|
Sounds like you need to use the dreaded partitions.
Take a look in the help under partitions. I am afraid I cannot comment on how useful these are because I have never used them in anger. ------------------------- Tony Goodman http://www.smartdxl.com |
|
![]() |
|
![]() |
|
Jonathan,
Partitions are not necessarily needed here, though they can help. Here's an approach I would try to take... Have the other company send you a .dpa (exported DOORS project) file. You import this into your DOORS. You create a new project, OUTSIDE of the imported project. Modules in your project link to the other project. You create an attribute, either a DXL attribute or an attribute populated via DXL that records traceability to the other company's modules. When other company updates their modules, you delete and purge the project, and reimport. You then write a script to relink everything, and then set up a view to see when the target requirement last changed. It's not entirely straightforward, but once you iron out the kinks, it can be smooth. And also, instead of resending an entire project, maybe the other company can send whatever modules have changed.... Good luck. ------------------------- Kevin Murphy http://www.baselinesinc.com The Requirements Management Experts |
|
![]() |
|
![]() |
|
Jonathan, The best way for integration is to use a common database. This can be done with direct connect by remote clients or by citrix server.
Anything else is problematic. Telelogic tried to address this problem with a web based product but this product is currently not available. It remains to be seen if Telelogic will solve the problem and bring the product back to market. Edited: 9-Oct-2007 at 18:52 by ron lewis |
|
![]() |
|
![]() |
|
Jonathan,
What Ron says is right, but it's not always a good choice. Remote connectivity without Citrix is really not good remote connectivity. It can take a long time just to navigate a remote database, and if you open a huge module, you may be in for upwards of a 10-minute wait. Also, Ron's suggestion doesn't always adequately account for everything..if your company and their company has DOORS Administrators, then is their company going to let you Administer your own modules? In cases like this, there is always an issue of trust, and of ownership, and while you may not do anything out of the rules, companies have data security policies about this sort of thing. Sharing modules when direct connections aren't available has always been a problem in DOORS. If you can't use one database, then you need to ensure that links are recorded before pulling in new modules. That really is the key to using two separate databases. ------------------------- Kevin Murphy http://www.baselinesinc.com The Requirements Management Experts Edited: 9-Oct-2007 at 19:07 by Kevin Murphy |
|
![]() |
|
![]() |
|
The major problem you'll get exporting project (or module) archives from one database and importing them into another is access. You stand a pretty good chance of no-one having access to the imported project or modules, which means there's only the Administrator can do anything (like delete) the imported project or modules.
The simple solution is to get the exorter to give RMCDA access to everyone before exporting the modules or project, then set it right after import. There is almost zero chance of the user ids being the same across two databases, unless both are using Telelogic's version of LDAP. A simpler option is to talk to Telelogic about their (unsupported!) eXchange product, written (in DXL) by their German support guys for the automotive industry. It supports export/import across databases and across database versions (V7 & V8 currently), it works in both directions, it supports partial export (selected attributes), and it can prevent update of some of the attributes in the partial export. The down-side is that Telelogic only supply it in exchange for consultancy services. ------------------------- Paul dot Tiplady at TRW dot com TRW Automotive |
|
![]() |
|
![]() |
|
Wasn't the archive problem fixed in DOORS 8 or 8.1?
I worked on a Project where we had to transfer modules via dma files using DOORS 7.1. We made a copy of each module to be transferred and stripped all access rights from the module, views, attributes and objects. The assumption was, though, that a module was only writable in one database at a time, as there would be no way to merge changes from multiple databases into one module. Anyhow, Jonathan, you should know this can be done and has been done before. ------------------------- Kevin Murphy http://www.baselinesinc.com The Requirements Management Experts |
|
![]() |
|
![]() |
|
I may be misunderstanding something here. But we had a simlar situation where one of our subcontractors was working on a part of our project in their own DOORS database. At some point about a year or so ago we decided we wanted all the requirements housed on our database. Our subcontractor archived everything by project and sent us the projects which we then restored into our database. Doing this on a continual basis would be a pain, but as a one time cutover it wasn't too bad.
They now connect to our DOORS database via Citrix and we control what modules they can see via group access rights. My database server is actually in another state and connecting via a DOORS client on my computer is very slow. I've gotten around the lagginess, by initiating a remote desktop connection to a terminal server with DOORS installed on it. The TS sits right next to the DOORS server and it is soooo...much faster, I dread the day when we run out of liceneses and I have to use my node locked license on my computer..lol. ------------------------- Scott Boisvert Engineering Tools Administrator L-3 Communications - Avionics Systems scott.boisvert@l-3com.com |
|
![]() |
|
![]() |
|
Scott,
I believe the original question in this thread was not about using one central database, but how to integrate two databases and sync periodically. Certainly one database, if feasible, is the way to go. However, company policies, contracts, data security risks, etc. routinely prevent this from being able to occur. And then if it does occur, do we really trust another company enough to give their DOORS Admin "A" access to the database? Technically you can share modules by recording and then restoring links. If one database is to be used, importing can be relatively painless. A one-time deal. But using one database for two companies leads to other problems (multiple DOORS admins, remote connectivity not being fast enough, etc.). That's all I was trying to say. ------------------------- Kevin Murphy http://www.baselinesinc.com The Requirements Management Experts |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.