- Software Standards Specification
- Software Requirements Definition
- Software Best Practices
- Input Validation
- Output Validation
- Cookie Requirements
- Access Failure Error Checking
- Buffer Overflow
- Code Structure
- Software Functions
- Software Modules
- Requirements for Variables
- Software Code Comment Requirements
- Quality Code Requirements
- Software Code Review
- Software Code Testing Requirements
- Software Change Control
Security Best Practices
- Secure Functional Requirements
- Account Creation
- Change Password
- Forgot Password
- Personal Question
- Contact Webmaster
- CAPTCHA Tests
- Answer Verification
Software Change Control
- Codeline - Source code required to produce software. It could be a specific product or even a basic set of code that many of your internet applications commonly use. A main codeline should exist in your organization for each type of application that your organization creates. Codelines can be used to help manage software version control and change control. Software codelines should have specific purposes. One codeline of code may be a main codeline which other projects use to provide base functions. Another may be a specific project to be delivered to a customer. Other codelines may be used to enhance or add features to the main codeline.
Codeline policy - Each codeline should have its own policy. One codeline may require more stringent testing that another one. A codeline under development will require a policy that does not require stringent testing when code is checked in. Production codeline should have a policy requiring stringent testing.
Environment - When discussing code use, the environment is either test (development), Quality Assurance (QA) test, or production. The test or development environment is used for developers to test their code. The QA environment is used by customers to verify business functionality. The production environment is where the software runs for the purpose of customer use. Changes to the production environment must be the most stringent.
Branching - The creation of a new codeline based upon a current codeline. Branching should only be done when absolutely necessary.
Software Change Requirements
There are several requirements to provide effective software change control.
A Software Version Control (SVC) system or Source Code Management (SCM) tool should be used to control software changes and versions.
The ability to return to earlier states in the code should be built into the software change control system.
Files should be locked while they are being worked on so only one developer may make changes to specific files at a time. This will prevent overwriting of work.
All files associated with the code must be under version control including software requirements files.
All developers should have home folders where they can place their own experimental code outside the main project. This should only be used for building tools not directly required by the project and will not be allowed to contain project code.
Each software change request should be assigned a unique tracking number.
Identify the person(s) who are essential for authorizing changes to software and have only them approve the changes. This will prevent too much bureaucracy and cost.
Automate the change control process as much as possible and use a version control or code management tool that includes change management if possible.
When the software change is comitted to the system, the description of the change and the reason for it must be meaningful and useful.
Consider the environment and project phase in your change control process. If a project is under development and has never gone to production, the change control process should be simpler. But even in this case some change control is required so the program team is aware of changes to other code which may impact what they are trying to do.
For production changes have someone with specific knowledge about the project and how the application works review the changes before deployment.
Stakeholders must be aware of production changes and/or approve the change. The stakeholder may approve the change before it is made and someone with detailed project knowledge may approve the change (and communicate it to required management and staff) when it is made.
Multiple changes to production software should be bundled into a single change when possible.
When code is in the project development stage, programmers must check their change in often. The team must be aware of all areas of code being changed and must meet at least weekly.
Code change procedures should encourage frequent code check in. Code validation procedures should not be an administrative nightmare. Code changes should be committed in logical sections.
Create a process or tool with contact information about those who should be notified about changes to each specific project. When projects have code changes applied, be sure those people are contacted either manually or automatically using a tool.
Codelines should have policies specific to the reason for their existence. A production codeline that has been released should have policy limiting changes to fixes to specific error types.
Every codeline must have someone in charge of it to make decisions not covered by policies or processes.
New codelines should be created only when necessary which includes when a different codeline policy is required.
Track all changes and track all changes to each branch so code changes may be effectively and efficiently propagated to code branches.
Implement the change control processes based on the Software change Management Policy
Many experts require a change control board to be used for change approval. However, a change control board may or may not be neccessary or efficient. The need for one should depend upon the purpose in having one, the environment (development,QA,production) changes are being made in, the nature of your organization, considerations for efficiency, and value added by the additional control. A change control board should be used when it adds value to the change control process. The objectives of the change control process should be kept in mind when setting up the process and deciding whether to use a change control board. Objectives are:
Be sure changes are tested
Be sure a backout plan exists
There should be many changes of similar type which allows for templates to be used during the approval process. If a change control board improves the above objectives and it does not significantly reduce efficiency, it should be used. The board, if structured correctly, could be used to help users get ready or be aware of the change.