When we think of "access control," are talking about the privileges and permissions granted to those who might view or update project management software and other artifacts. Access to the software project's repository and its configuration warrants careful thought because it can have an impact on the overall success of the project. Access control in software development is part of the gate keeping function—who should and should not have access to the project project information and repository of source code and documentation.
Here are four points of consideration when approaching access control for your software development and configuration management efforts:
1. Treat Access Control As An Important Part of Your Project.
There are many levels of knowledge and skill used in software development. Orchestrating whose knowledge to use, and when to use it, is effectively implemented by controlling access to the project through the permissions and privileges that you grant.
Too often, careful consideration of access control gets cursory attention. It can and should be an instrumental part in holding back the curtain until the time is right on the project.
Who has access, and who does not, should change as the project milestones change. Granting an end user full access to a project for its whole duration may be unwise. Allowing certain developers access to a part of the project unrelated to them is also unwise.
The concept of least-privileges is one that is embraced by many in the development community. Least privileges user account (LUA) refers to the smallest set of
privileges needed to perform the user's tasks. It is a concept that Microsoft uses in its software development and is a key means of control.
You may establish demos for clients and end-users for them to see your progress along the way. Depending on the client, you may be careful as to how often you offer
these demos and at what duration this access is allowed.
Think of access control as being fluid: it changes according to the needs of the project. Do not keep the privileges the same for the project's lifecycle. Change them according to the flexible review of what you need and insure that your project or configuration management software easily allows such flexibility.
One of the most cited reasons that enterprise-wide IT projects go astray is because they do not match up to the true needs of the end-users. Those who access the project are part of a narrow group.
By bringing end-users into the project to test-drive it early on and often, you strengthen their "buy-in". This enables you to plan and develop a quality product.
Also, bring in the middle managers, the shop floor personnel, and whoever else might have a good idea of what is needed and be able to provide meaningful feedback during the process, so the end result of the software development results in a very quality
Allow them to log in and have a look, and capture their feedback for your own good. Choose project management software that is user-friendly and easy to peek into the project and leave feedback. Feedback at regular milestones can make the project rock!
2. Access Control Is an Effective Means of Controlling the Software Development Process
In fact IEEE-Std-729-1983 tells us that software configuration management entails "controlling the change of these items [in the system] throughout their lifecycle.
Just as a sculptor keeps his masterpiece covered before it is unveiled to the public, so must development teams keep their projects selectively covered. Revealing too
much too soon has its security risks. Controlling how much you reveal is good practice and enables valuable feedback, as discussed earlier. How many passwords to disseminate is a balancing act. Being too liberal with a password or, moreover, or giving it to the wrong person, can create a dangerous false perception of the project.
Often a precocious