When I first started working as a programmer, change control implementation was pretty straight forward. If you had an assignment to work on a program, your boss handed you the source code, which was a deck of punched cards along with the latest compile listing, and the program was yours until it was done. Today, with easy access to source code, having a good change control policy in place is mandatory. Let's take a look at things you can do to keep control over the implementation of program changes for your installation.
Any change control process has to start with change requests. Most shops implement a formal program change process that starts with a Program Change Request (PCR) or a System Service Request (SSR) or some such vehicle for change. This form, prepared by the end user, describes the project to be implemented and should include a project title, short description, detailed description and a project justification that shows how the project will dovetail with company objectives. It should also include some economic measurements to show the benefits of implementing the project.
This form is then submitted to your IT group for consideration. A good change control system starts with this submission. These SSR forms (we'll use that reference from here on) get assigned a project control number and get logged into a change control log. Each project must be evaluated and prioritized by IT management. Once a project has been approved for implementation, IT management will determine the resources needed to assign the project. It might involve an individual or a team. Each step in the process must be logged to keep track of where the project is in the implementation process along with an estimated implementation schedule. As the SSR moves through the process, the end-user should be advised as each step is taken towards implementation.
When it comes down to implementation, it is critical that you control your program source code. There are lots of ways to do this, including the purchase and implementation of commercially available tools for this express purpose. For changes to existing systems, this is even more crucial as your current working source code must be preserved while the changes are being made in a separate environment.
The easiest and safest way to do this is to have a separate test system for your programming team. In today's System i world, if you don't have a separate test system, you should be able to set up a separate logical partition on your system for this purpose. This will let you segregate the program source and test files from your production environment and gives your programmers a nearly perfect sand box in which to work on the changes.
To keep your production source code in tact, I recommend that you secure the source physical files to a single user profile. That profile must then be used to make copies of the source code for change purposes. You can implement a procedure that keeps a log in place when source code is distributed for change purposes that identifies who has the copy for change purposes and logs the changed code back in when the project is completed. It is also a good idea to keep prior versions of your code for backwards reference when future questions arise.
When a project reaches completion, you must have a process whereby the end user reviews the testing criteria and testing results and then signs off on the change. Once the end user agrees with the work that has been done, you can then schedule implementation. Part of implementation will include moving the new, changed source code back into your master repository of source code that is secure.
The area of change control and change management is more complex than space permits here. If you have specific questions about this topic, e-mail me at rich@kisco.com. All e-mail messages will be answered.
---------------------------
About the author: Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.
