![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Database Schema / Information Architecture Topic Summary: Methods to depict and manage your DOORS database information architecture Created On: 14-Oct-2008 00:07 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
DOORS is infinitely flexible, and usually needs to be customised to best meet the needs of the organisation and/or project at which it is directed. Yeh?
With such power comes high responsibility. Responsibility for managing the customisation of your DOORS database. Responsibility for specifying it in advance with the input of process stakeholders. Of ensuring its evolving structure continues to meet its requirements. Maintaining the way that access rights are assigned to each user for each database element. Coordinating design updates across like modules. And how do you specify your DXL logic? If you had a process audit today, could you trace back to the reasons why your DOORS information architecture is as it is, and justify that it still meets its requirements? Specifying and maintaining your DOORS information architecture is an onerous job. Does anyone have any views about best practice, and/or how it can be made much easier? |
|
![]() |
|
![]() |
|
At the very least, keep all of your dxl under configuration control, with some type of 'rationale' information associated with each and every change to the code baseline. Of course, we all do this anyways, right?
------------------------- Andrew Tagg Thales Air Systems, Melbourne Australia. andrew.tagg@thalesatm.com |
|
![]() |
|
![]() |
|
We have a defined Engineering and Requirements Management processes that DOORS supports (nb not the other way).
From that we have some defined basic models that cover the project work we handle. Projects may tailor the models by adding attributes/modules provided they can justify and document the deviations from the process. |
|
![]() |
|
![]() |
|
We have a defined Engineering and Requirements Management processes that DOORS supports (nb not the other way). Wise! ![]() From that we have some defined basic models that cover the project work we handle. Projects may tailor the models by adding attributes/modules provided they can justify and document the deviations from the process. OK, that's a pretty direct approach - like a template project with some accepted and exceptional variations? So how do you define the basic models, and their variations, and do you go as far as recording the justification for variations? |
|
![]() |
|
![]() |
|
At the very least, keep all of your dxl under configuration control, with some type of 'rationale' information associated with each and every change to the code baseline. Of course, we all do this anyways, right? You raise a very interesting point Andrew - configuration control of DXL. Would you like to share the details of your approach - in respect of the issues you've had to come by doing this? When developing DXL, being able to easily switch the DXL in the DOORS directory to the working copy view of the CM database, and then back to known release points inbetween development stints, requires careful attention. Do you have any neat approaches here? |
|
![]() |
|
![]() |
|
The approach used in my company is fairly basic but here is the high level view:
* The dxl baseline is stored in a CVS repository. * Any development work is done in a checked out clone of the repository. * Finished dev work is checked back in against a Change Request ( we have some in house tools for this, but must be some public domain stuff I would think) The change request number can be used to look up the 'rationale' for the change, again an in house system, but hey, you could use synergy or whatever. * The working copy of the code is basically another checked out clone. Like I said simple but the basics are: * You can always back out a change by reverting to an old baseline. * You can always tie the history of a change to a particular change request. * Dev work is offline with respect to the 'working' code base. ------------------------- Andrew Tagg Thales Air Systems, Melbourne Australia. andrew.tagg@thalesatm.com |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.