本文发表在 rolia.net 枫下论坛2 Business Requirements
There are two possible categories of requirements usually push you into the areas of access control in ClearCase, to maintain the system integrity and to facilitate certain software process. In the first category, we want to prevent normal users from doing anything to harm the system, while in the second category we want to allow certain users to have some special rights to drive a certain workflow.
2.1 Facilitating access controls
2.1.1 Priority users
In this case, only certain users can do certain critical tasks in ClearCase. For example, you would like to allow only ClearCase administrators or experienced integrators to change the basic UCM project and stream configurations.
2.1.2 Restricted areas
Organizations such as banks normally have higher security requirements for the source controls system. It’s common to have such a requirement that some projects don’t want anyone else other than the project team members to peek into their projects. Here we called this situation as zero-visibility. Means other projects even don’t knows there is such a high secured project existing in ClearCase.
2.1.3 Read-only access
For most of other projects, we want to allow the project team members only to have the right to modify their code, but still give read-only right to others. We hereby called this as read-only access. Means you can see what they have but have no right to change anything there.
There is a good reason to give out the read-only to other projects. In today’s software development, component based and architecture oriented design approach are very common in a lot of large organization such as banks. Most of projects are relying on other project teams’ deliveries, components and sub-systems, which represented as components in ClearCase.更多精彩文章及讨论,请光临枫下论坛 rolia.net
There are two possible categories of requirements usually push you into the areas of access control in ClearCase, to maintain the system integrity and to facilitate certain software process. In the first category, we want to prevent normal users from doing anything to harm the system, while in the second category we want to allow certain users to have some special rights to drive a certain workflow.
2.1 Facilitating access controls
2.1.1 Priority users
In this case, only certain users can do certain critical tasks in ClearCase. For example, you would like to allow only ClearCase administrators or experienced integrators to change the basic UCM project and stream configurations.
2.1.2 Restricted areas
Organizations such as banks normally have higher security requirements for the source controls system. It’s common to have such a requirement that some projects don’t want anyone else other than the project team members to peek into their projects. Here we called this situation as zero-visibility. Means other projects even don’t knows there is such a high secured project existing in ClearCase.
2.1.3 Read-only access
For most of other projects, we want to allow the project team members only to have the right to modify their code, but still give read-only right to others. We hereby called this as read-only access. Means you can see what they have but have no right to change anything there.
There is a good reason to give out the read-only to other projects. In today’s software development, component based and architecture oriented design approach are very common in a lot of large organization such as banks. Most of projects are relying on other project teams’ deliveries, components and sub-systems, which represented as components in ClearCase.更多精彩文章及讨论,请光临枫下论坛 rolia.net