![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Module Access (Am I just too strict???) Topic Summary: Created On: 12-May-2008 18:03 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
OK....I adiminister a fairly large database, our project consists of over 800 formal modules, encompasing 75,000 plus requirements (not including non-requirements objects). The project is a multi-LRU project and we have the System Level, High Level, Low Level, Source Code Indices and Test Cases built into a hierarchal structure broken up by LRU.
We have 250+ engineers that connect to this DOORS database. Each group of 10-15 engineers belongs to a DOORS group relating to the LRU they work on. These groups have access to all the requirements modules that fall under their LRU. So a a group of engineers working on LRU A belowng to a DOORS group called LRU A. The LRU A group is given RMCD access to all the LRU A modules (SYSR, HLR, LLR, SCI, Test Cases). Now on occassion (in practice it seems to happen a lot, but we have alot of engineers), an engineer that belongs to LRU B will need to modify a module that belongs to LRU A. Currently, I will get approval from the LRU A team lead, and then give the engineer from LRU B access to only the module they need to modify, removing access when they have completed their work. A suggestion from one of the folks in CM, the only other person other than myself that is allowed to grant access in the situation above, suggested giving access to all modules to all 250+ engineers, because it takes too much time sometimes hunting down the team leads to get access approval. I personally do not agree with this situation and have provided a several examples why this shouldn't happen, i.e. Module A is modified by engineer B without LRU A Team's knowledge and the change was either unneeded or unwanted at the time. I've had my requests for access rejected several times due to these conditions. There were other reasons, besides just the fact that opening the database up to everyone is just pure folly, but I wanted to see if y'all had any other reasons I could bring up or if I really am being too strict on my access policy (I personally think I've been forced to be too lenient). ------------------------- Scott Boisvert Engineering Tools Administrator L-3 Communications - Avionics Systems scott.boisvert@l-3com.com |
|
![]() |
|
![]() |
|
Yes, its folly to open up the database to everyone, yes you've been too lenient, and perhaps you should let the folks who are responsible for deciding access be the same folks who actually provide it.
I'd be tempted to assign access control for various groups of modules to certain individuals, and let them decide who does or does not have access to their modules. I'd also be tempted to provide access, the vast majority of the time, through group access and group membership manipulation. For example, I'd have [1] an "LRUA-Admins" group who have full RMCDA access to all folders, modules, and groups associated with LRUA. [2] LRUA-Sys-Managers group with folks who have RMCDA access to the SYS and who control membership in the LRUA-Sys-Editors group, who have RMCD access to the Sys [3] LRUA-HLR-Managers and LRUA-HLR-Editors, [3] etc. The LRUA HLR specs provide RMCDA access for the Database-Admins (you), LRUA-Admins, and the LRUA-HLR-Managers, and RMCD access for the LRUA-HLR-Editors, and provides R for Everyone else. When someone else needs access to the LRUA HLR they'd request access from one of the LRUA-HLR-Managers who, upon approval, would temporarily either add that user to the Editors group or provide perhaps RMC access directly to the module in question. There may be some merit to having a "LRUA-HLR-Modifiers" who have RMC access to the HRL, notice they cannot delete anything. Your role would be limited to brokering an introduction between the requestor and the appropriate manager(s). That's a lot of groups but strict naming conventions should keep them straight easily enough. - Louie |
|
![]() |
|
![]() |
|
Thanks for the response.
We've tried giving the responsibility to the Team Leads before as you suggested, though we have a strict policy of only on outside member having access to a module at any one time. We have a communication problem here and the left hand doesn't know what the right is doing half the time, which is the reason for this policy. The problem was, when the leads had the access, they would just keep adding people to the access list without removing anyone.....and then we end up with everyone having access to everthing.... At this point I just don't trust my engineers/developers enough to give them any kind of adminstrative powers in the database. Note I have never opened my database up to everyone, nor will I without one hell of fight. Other than the giving the developers Admin, I pretty much have what you described, I've got about 30 - 35 groups that I use to provide access which has cut down on the requests significantly since I implemented them. The complaint that was brought up is due more to a process/response issue. People don't follow the process for requesting access, and then the team leads don't respond to the access requests in a timely manner. Giving them the adminstrative power to grant access, really won't speed anything up, if they're not reading their e-mail or answering their phone (or can't be found). ------------------------- Scott Boisvert Engineering Tools Administrator L-3 Communications - Avionics Systems scott.boisvert@l-3com.com |
|
![]() |
|
![]() |
|
My favourite model for AR's in DOORS is a two level model that does require a level of trust and the adoption of basic best practices in Config Management - if that trust and adherence to basic CM is continually violated, then either the training is poor or the work culture is poor and I'm afraid that this will manifest itself as problems in many other areas as well.
Project Administrators Group. Members of this group have full RMCDA rights right across the project. Members of this group are typically users who are fulfilling a Requirement & Config Management type role and are responsible for managing AR's, co-ordinating the setting of major module baselines & baseline sets and making project schema level changes. No other group is given RMCDA, the maximum they can have is RMCD. Once a module is baselined to a level where formalised change management kicks in (i.e. changes can only be implemented in DOORS by way of approved change requests) then those attributes that are in scope for change management will have their attribute value access rights set to the following via a DXL script (main column is typically the minimum or those attrs that will be published in a formal hard copy): Project Administrators Group-RMCDA Everyone Else-R All other attributes that are not in scope for change management are viewed as being "Live" and do not need to be locked down. These are typically attributes that are used to help categorise, clarify and provide on going commentary on the requirement but have little or no influence at a config management level. All other access Groups From this point forward, no matter who you are, all other access to the module is restricted to either R or RM only. The RM level will allow users to make modifications to "Live" attributes but will trap any inadvertent\mischievous attempts to add or delete objects or to change the value of locked down attributes that form part of configuration managed content. When it comes time to make authorised changes via approved change requests, this is either carried out by a member of the Project Administrators Group or they delegate to a reliable user\group and give them temp access to the locked down attributes (if users can be trusted, it's often easier just to make them a temporary member of the Project Administrators Group - not all users are going to be deliberately mischievous so you do have to start from a level of trust or you'll just create an AR management nightmare). When it comes to Configuration Management of linking, similar AR's are applied to link modules but this requires a highly granular link module schema to be adopted so that you don't lock down more than you need to. ------------------------- Paul Miller Specification Practices Specialist EuroCyber Melbourne, Australia Mobile: + 61 (0) 418 135 103 http://www.eurocyber.biz |
|
![]() |
|
![]() |
|
Thanks Paul,
I agree with the Project Administrators Group idea. I've had that implemented for a few years now. Our Project Admin group is the same as our CM group (our group name is Configuration Management/Services) so we handle all access requests. Our biggest issue is that our documents are formalized too early (an issue I've brought up several times but have been disregarded by project management). So we are left with restricting access, and only performing work per change requests, unfortunately alot of the work done requires our users to create and delete objects as functionality is added and removed from the system or as newer/different versions of the system are designed, so giving the users RM only access would be cause an uproar. We use for Serena's TeamTrack for issue management and tracking. So what I've done (with a little help from one of summer interns last year) to keep unauthorized changes (changes without an approved change request) being entered into the DOORS module is this. - Added a trigger when a module is saved that pops up a little dialog box that asks for the change request number. - Upon clicking OK, the script will interface with TeamTrack and verify that the change request number is valid, in the assigned state and in the same user's name. If all the conditions are valid, the module is saved and the CR# is populated into an attribute called "Change Reason" for the modified objects. If not, then an error is displayed and the user has the opportunity to enter the CR# again. If the user can't provide a valid CR#, then the module is closed and all changes are disgarded. The only caveot to this system is that if an engineer really wanted to they could use a CR# that had nothing to do with the change, as long as its a valid CR# in the assigned state and in their name. But we have to have a little trust in our engineers. ------------------------- Scott Boisvert Engineering Tools Administrator L-3 Communications - Avionics Systems scott.boisvert@l-3com.com |
|
![]() |
Telelogic DOORS
» Administration
»
Module Access (Am I just too strict???)
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.