Change Management - Best Practices


The following sections contain best practices for change management from industry that the Standards Committee endorses and recommends for implementation for any group that is involved in development of administration applications at the University.



Version Control      An auditable history of all changes to the application code and data objects.
Review by Peers      Reading of code changes by other developers.
Departmental Approval      Secondary approval of changes by a party with ownership of the application.
Documentation      Written record of requirements, assumptions, and expectations of the applications.
Testing      Attempt to make use of the changes in a non-production environment.
Resource Impact      Analyze how programs or processes might impact the hardware resources of the system.
Security      Conscientious attention to application upgrades and account maintenance.
Archiving Code and Data      Code and data should be archived to avoid data loss.
Centralization of Resources      Make use of existing supported resources and processes.


Version Control

Versioning refers to the practice of preserving older, "milestone" copies of a given document so you can "fall back" to a certain version of a document without backing out current changes. The minimum amount of information that should be kept is the ID of the person who made the changes from the last copy, the date/time they were last changed, and a short description of the changes made.

Benefits of versioning:

  • An auditable trail of changes can be kept for each source code file or document.
  • Previous iterations of a file can be retrieved if needed (for example, to back out functionality or fix versions in a previous release).
  • A history of all changes to the application code and data objects should be kept. This history should include the difference between versions, the date of change in production, the user who made the change, and a functional description of the change.
  • Provides an audit of revisions, a view of the code at a given point in time, a history of the changes that were made, a record of who made the changes, and a source repository. This allows the developer to return to a previous iteration of the code.


Review by Peers

Peer review is defined as a meeting of the developer and at least one other developer and/or customer to discuss the code and the performance of a given program, form or report. As a minimum, all source code should be scanned for obvious errors and tested by the customer.

Benefits of peer review:

  • Another developer can catch obvious or common errors they have experienced much faster.
  • Developers share tips and techniques among themselves, educating other developers.
  • Simple solutions to complex problems overlooked by the code writer have often already been discovered by one or more of the peers.
  • Standards are applied.
  • Code, in general, improves as developer reputation is at stake with peer scrutiny.
  • As a new developer to UI or a developer new to given language, this review adds valuable, real-world examples and develops consistency.
  • Provides an opportunity to catch errors and improve performance. This also provides an educational opportunity for the peers on the application, and programming language.


Departmental Approval

As a minimum, at least one knowledgeable second party should approve changes to each program or document before it is moved into a production environment. This person should be an end-user, data owner, or power user who has a legitimate vested interest in the correct functioning of the application.

Benefits of departmental approval:

  • An auditable trail is kept of the changes, including the reasons behind them and the problems they are meant to solve.
  • Appropriateness of code is ensured to be in the best interests of the deparment.
  • Should problems with a program appear, the appropriate end user can be consulted to assist in fixing the problem.


Documentation

As a minimum, approval of changes, documentation of the code, and test plan documents should be developed for each project (process, program, form, etc) and kept in an area that is accessible to developers, auditors, and the owner of the application.


Testing

Testing is the process of running code through a realistic simulation of the production system to find errors or enhancements to the code before implementation. As a minimum, all code should be run successfully at least once against a set of test data. Testing should include all processes associated with the change, analysis of potential performance impacts due to the change, and assessment of the correctness of the solution. It is also beneficial to test existing and revised documentation that is related to the change, to ensure its continued correctness. Include end-users in testing the change.

Benefit of testing:

  • Adequate testing can prevent errors from going to production.
  • Users can officially approve the code or system and be a part in the project.


Resource Impact

An analysis of potential performance impacts due to the change should be conducted. Sharing of hardware and software resources should be considered. Document and schedule intensive operations. Communicate significant impact to system administrators and owners of other applications that share resources. Document significant resource usage and file this document with other process documents.


Security

Thoroughly secure access to the application and data. The following aspects of security should be addressed:
  • Secure passwords by:
    • Changing passwords regularly
    • Forcing password complexity with a minimum password length and inclusion of special characters
    • Controlling password sharing
    • Locking accounts when access is not required
    • Expiring passwords on a regular basis
  • Controlling access to data, applications, and servers
  • Controlling physical access to data and servers
  • Encrypt stored passwords
  • Encrypt sensitive data over the network


Archiving Code and Data

Ensure the availability and recoverability of application data and source code by adhering to the following best practices on file archives:
  • Archive data and source, at a schedule depending on the frequency of changes.
  • Archive to a different device than that upon which the production data exists.
  • Store archive files in an alternate physical location.
  • Check the success of the backup through the following methods:
  • Verify file existence on the alternate medium.
  • Compare file size of the archived files with the production files.
  • Practice restoring the archived files to an alternate location.
  • Document archival procedures and schedules. Make this documentation available to system administrators, developers, auditors, and application owners.
  • Document steps for restoration, preferably including alternate scenarios.
  • Archive files during hours of low usage.
  • Perform regular full backups, with incremental backups in the interim. Balance the amount of time required to restore a full cycle of incremental backups against the time required to perform full backups.
  • Develop processes and scripts for archiving files before putting a system into production.
  • Use a standard file format for archived files.


Centralization of Resources

A centralized infrastructure of servers, file storage systems and software installations should be used whenever possible. This includes hardware platforms, programming tools, file formats, file storage systems, and executable programs. Security considerations should be taken into account, as well as ease of access and redundancy. Care should also be taken to use industry standard formats and languages.

Benefits of centralization:

  • Using existing resources is often less expensive than buying new hardware or using more personnel to administer a separate system.
  • Files stored on central servers can be accessed by many people from many different machines, and are less likely to be lost due to hardware failures than files stored on desktop machines. Backup strategies and hardware configurations with warranties ensure data avaliability.
  • Programs written in common languages or with common tools can be modified by more developers than programs written in obscure languages or proprietary formats. The training of developers in a given language is also streamlined.
  • Duplication of code or code variance is minimized by using centralized repositories of work.
  • Support code, such as programming libraries or interfaces, can be used by a larger community of developers, saving development time.
  • Following common industry standards increases the number of resources available to leverage against encountered problems.