Technical Audit Program
Control Objective - sourcaab
Controls are in place to ensure that the source equivalent of the
production source code is used for program development
1) Determine which library the source code is retrieved from
in order to initiate program changes through discussions
with the application programmer.
o production source library
o intermediary library which is refreshed from the production
Perform this step an intermediary library is used
2) Ensure that the code within the intermediary library is
refreshed each time that a migration to production occurs.
2.1) Ensure that there is a process in place to refresh the
intermediary library whenever a change is migrated to
2.2) Determine the dates in which migrations to production
occurred and compare it to the last changed date of the
intermediary library to ensure that the modules are
refreshed based on documentation that is available.
In almost all cases when a program change is required, the
programmer should be retrieving the source module which is of the
same version that is executing in production.
There may be times when the programmer should be making changes
to the most current version of the code which is of a later
version than what is running in production. This is because
another programmer might have made changes to a specific module
which has not yet been migrated to production. The concern here
is to ensure that two programmers are not working on the same
source module which could potentially cause one programmer to
overlay another programmer's changes. This control concern is
handled in a separate control point
When an automated change migration system is not used, there is
no automated control to force the users to use the production
source code as the basis for making a program change. Therefore,
a programmer may have previously copied the code to their
personal library thinking that they have the most current version
without realizing that an updated module was just migrated to
production. An automated change migration system has a source
management module which prevents code from being migrated to
production if it was not previously "checked out" the module.
The controls to ensure that the production source libraries are
updated is reviewed in another control point.
Audit Step Info
It may be difficult to prove that the intermediary library is
being refreshed after program changes are migrated to production.
In order to prove it systematically, an audit trail would need to
be available to identify when this occurs. Checking the last
change date of a module that is tracked by TSO which can be
displayed when browsing the library will provide no relevant
information since the module would not have been changed when it
is moved to production versus moved to the intermediary library.
Control Objective - sourcaac
Controls are in place to prevent programmers from overlaying each
others program changes
1) Determine if there is a process or tracking system (i.e.,
module assignment log) which enables programmers to identify
when other programmers are using the program module that a
programmer is planning to change to meet the requirements of
a software request.
1.1) Ensure that the process is consistently being used by
obtaining a listing of each programmer's library and
comparing the module names to the module assignment log to
determine whether they were recorded.
2) Determine whether there is a management review process in
place to ensure that changes to the same module by different
programmers is appropriate.
2.1) Ensure that the process is consistently being used by
reviewing the module assignment log and determine whether
there are instances where a module is being by two
different programmer and verify that the program manager was
aware of it. In addition, compare the listing of the
modules contained in programmers libraries and determine
whether the same module exists in multiple programmer's
personal libraries and determine if they are in the process
of being changed. If yes, then verify that the program
manager was aware of the fact that two programmers are
changing the same module.
3) Determine if there is a process in place for management to
retrofit the changes of modules that are being altered by
two different programmers prior to their migration to the
acceptance testing libraries.
During the course of development for most applications, there are
times when two different software requests require the same
module to be changed. The number of instances in which two
software requests require the same module to be changed depends
on how modularized the system is. If various application
components are consolidated into one module there is a strong
likelihood that most maintenance changes would require a change
to the same module.
In order to prevent programmers from using the same module, a
process should be in place to assign one programmer the software
requests which use the same module.
The process for identifying the modules that programmers are
using is a common component of most change management systems.
However, since your installation is not using the change
management system a manual process must be used to perform this
task. The module assignment log is used to manually log the
program modules that each programmer is currently changing. The
log is used as a central source of information used by all
programmers to ensure that no other programers are using the
module that they intend to change in order to avoid the
overlaying of code. The program manager should be the
responsible party for maintaining the log and reviewing it to
ensure that the sharing of program modules by multiple
programmers are authorized and is a coordinated effort.
Audit Step Info
Identifying the programmer's development libraries is an
important part of the compliance test that is described in this
control point. Instead of asking the program manager for the
names of the libraries, another method is to identify all of the
programmer's TSO IDs and using TSO 3.4 option, enter the TSO ID
in the DSNAME field (DSNAME==> <TSOid>) and leave the option
field blank. This step will identify all of the dataset names
associated with the TSOids high level prefix. Since all users
are granted update access to their TSOids high level prefix,
these are the libraries where the programmer can define their own
personal development libraries in addition to any specific
development libraries that the programmer has been assigned.
Copyright 1991 - 2006, Audit Serve, Inc. All rights reserved. All Audit Programs are copyrighted and may not be posted electronically or redistributed unless written permission is granted by Audit Serve, Inc. The Audit Programs may be used for internal use within organizations. Audit Programs may not be resold.