1. Software Standards Specification
  2. Software Requirements Definition
  3. Software Best Practices
  4. Input Validation
  5. Output Validation
  6. Cookie Requirements
  7. Access Failure Error Checking
  8. Buffer Overflow
  9. Code Structure
  10. Software Functions
  11. Software Modules
  12. Requirements for Variables
  13. Software Code Comment Requirements
  14. Quality Code Requirements
  15. Software Code Review
  16. Software Code Testing Requirements
  17. Software Change Control

    Security Best Practices

  18. Secure Functional Requirements
  19. Account Creation
  20. Change Password
  21. Forgot Password
  22. Personal Question
  23. Contact Webmaster
  24. CAPTCHA Tests
  25. 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:
    • Track changes
    • Ensure quality
    • Be sure changes are tested
    • Be sure a backout plan exists
    • Inform users
    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.