Change Control Effectively managing the development process
From "VS Workshop",  Access to Wang, July 1992
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

To date, much VS program development has been performed informally, with programmers taking personal responsibility for completion of tasks, coding standards, library naming, etc. Much of this "culture" of independence is the result of the easy development environment offered by the VS, since it is possible for a single programmer to perform all phases of development, including installation and systems programming.

Increased application complexity and larger programming staffs are complicating this picture. It is often necessary to coordinate the efforts of six or more programmers, and documenting changes to programs can become a major effort in itself. This month let's examine the issues of Change Control, the processes used to control program development, maintenance, and installation.

Change control in VS shops

In many VS shops the programming staff is given full control of all installation aspects of their work. When a program must be changed, it is often edited directly; object files created by this work-in- process version are tested by running the program from the production object library. If this describes your development approach, here are some reasons why you might need to consider changing the process:

• Your staff has grown and you are never sure which programs are in progress between several programmers. Some programming effort has been wasted due to confusion over who is currently working on a program.

• You wish to know more exactly how much maintenance activity takes place over your entire source portfolio.

• Overflow programming work is now handled by contractors, and you need to monitor their efforts.

• You wish to retain old source - possibly off-line - in the event you need to reverse a program change.

• You want to be sure that all programs have been compiled and linked with the same debugging information, link libraries, and other parameters.

Regardless of the programming languages used, all of these desires can best be supported by a Change Control strategy - a formal process for managing source change and installation. There is no routine method for implementing such a process; it can be as rigid or as flexible as your needs demand.

Components of a change control system

Change Control consists of elements of process and policy that enforce consistency of development and installation. Change Control can include procedures that assist in the programming or installation process, utility programs, and tools to assist developers. Policies related to change control include programming standards manuals, library naming conventions, and assignment of access rights among development staff. The process can be summarized in three phases: Source Management, Change Control and Archiving, and Installation.

The Source Management phase includes selection and editing of source files and enforcement of production standards to changes made. The selection process should include an examination of whether the file is presently in work by another programmer; this is typically accomplished by establishing a separate library (referred to here as a source work library) for programs under modification and observing whether the source file is already present in that library.

Once identified, the production version should be copied into the source work library and edited using a agreed format. A simple procedure - such as the one shown below - can be used to ensure that files are edited with similar editor settings, links, and modification codes.

The Change Control and Archiving phase begins when the program is ready to be installed. A major activity of this phase is the cataloging of the changes made to the program. Changes can be recorded through program comments, modification codes, listings comparing the source files, or other methods. Comments are often added at the top of the program describing the changes and dates, with modification codes recording the actual line changes. In some cases, the prior source or object versions are stored off-line in the event they are needed later.

The Installation phase includes moving the working versions of the program source into the production source library and compilation into the production object library. As with the editing process, it is helpful to use a short procedure to standardize this process.

Among the many choices that can be made in the Installation phase is whether to include symbolic debugging information, version numbers, dates, or comments. Version numbers, dates, and comments can be added to the object file during the linking process and extracted using SHOVERZN, a Wang utility formerly known as VERSIONS. These comments are also visible when the object file is displayed, making them a convenient means of identifying the file.

Developing a Change Control process

Figure 2 lists a sample Change Control process suitable for most medium-size development organizations. It relies on simple signals - such as the presence of a file in a given library - and simple tools. The process could be performed manually or automated with a series of small procedures, such as the EDITOR procedure described in Figure 1. The Installation phase could be performed by the operations staff if installation needed to be performed after hours.

Whatever your language or level of development activity, a Change Control strategy can help manage your staff time and provide better documentation of your services.

Figure 1: Standard Procedure to Control The EDITOR

PROCEDURE ED - standard editor procedure DECLARE &DATEIN STRING (06) INITIAL &DATE DECLARE &MC STRING (08) * ASSIGN &DATEIN = &DATEIN (5,2) !! &DATEIN (1,4) ASSIGN &MC = "DB" !! &DATEIN (1,6) * RUN EDITOR DISPLAY INPUT LANGUAGE=COBOL, FILE =' ', LIBRARY =SYSNEW, VOLUME =SYSTEM, PLIBRARY=SYSOBJ, PVOLUME =SYSTEM ENTER DEFAULTS TABS ="08 12 16 20 24 28 32 36 40 48", MODE =UPLOW, CASE =ANY ENTER OPTIONS SCRATCH =YES, REPLACE =YES, RENUMBER=YES, NUMBER =100, INCR =100, MODCODE = &MC ENTER COMPILE XREF =YES, SEQ =NO, COPYLIBS=NO, FLAG =01, LINES =60 DISPLAY LINK LINK =YES, LIBRARY =VSSUBS, VOLUME =SYSTEM ENTER LKPRINT ENTER LKOUTPUT REPLACE =YES RETURN

Figure 2: Prototype Change Control Process

1. Identify the program to be modified and verify that it is not currently in work by checking for its presence in the work source library. If the file exists in the library, contact the file's owner to check on its status. If desired, use the FILEDISP utility to check for other versions of the file in personal libraries.

2. Copy the production version of the source file to the work source library.

3. Edit the work source version of the program using a standard procedure for program editing. Compile test object files into the work object library and test these versions to verify results.

4. When ready to install, record program changes by comparing production and source work library versions of the program. A SRCDIFF listing may be used to record these changes.

5. Archive production source and object files, if desired.

6. Compile work source library program using standard compile procedure. Increment and set object versions, if desired.

7. Move completed source file into production source library, replacing original source file.

8. Scratch source and object work library versions of the program, setting "in work" status off.

Figure 3: Glossary of Change Control Terms

Term	Definition
Change control	A formal process that controls source file changes by identifying differences and controlling implementation.
Work source and object libraries	Location of programs currently in work. Presence of a file in the source library indicates that program is "in work".
Production source and object libraries	Location of source and object files currently in production.
SRCDIFF listing	A report of differences between two source files, listing items as deleted or inserted from the first (older) version. Can be produced using the Wang COMPARE utility or with USERAIDs DIFF, SRCDIFF, or COMPARE.
FILEDISP	A Wang utility used to find files that meet entered name criteria, including "wild card" characters * and ?. Typically used in change control to locate copies of a file in personal libraries throughout the system.
SHOVERZN	A Wang utility that extracts version numbers, release dates, and comments from object files. Replaces earlier program VERSIONS.