System Development Life Cycle Audit Program
AUDIT PROGRAM OVERVIEW
A system development life cycle (SDLC) is a methodology that can
be used to develop or modify application systems. Each organization
should establish a SDLC methodology and assign responsibility
for each phase of the cycle so that system design, development,
and maintenance may progress smoothly and accurately. This cycle
starts with a perceived need and extends through feasibility study,
design and development, testing, implementation, system acceptance
and approval, post-implementation review, and maintenance of the
application and systems software. Following each phase of this
cycle ensures that the new or revised software meets the organization's
needs, that adequate internal controls are consistent with management's
objectives, and that the application is properly implemented.
This audit program assumes that an application system is developed
by an in-house programming staff. However, application systems
in use by many state agencies were not developed in-house but
instead were purchased. In these instances, all the steps performed
during in-house development of an application are not applicable
for purchased software. Specifically, systems and programming
standards, and file and programming specifications are not needed.
In these cases, document in the Summary Memo how the scope of
this audit program will be modified and answer Not Applicable
(N/A) to any questions on the ICQ that do not apply.
Suggested interviewees for ICQ:
A. System Programming Manager
B. Director of Data Processing
A. Control Objective #1 - SDLC Methodology
- Determine the extent of the responsibilities of management,
internal audit, users, quality assurance, and data processing
during the system design, development, and maintenance.
- Review SDLC workpapers to determine if the appropriate levels
of authorization were obtained for each phase.
- Obtain and review requests for DP services. Determine if the
University's procedures are being followed.
B. Control Objective #2 - Needs Analysis
- Review and evaluate the procedures for performing a needs
analysis.
- Review a needs analysis for a recent project and determine
if it conforms to standards.
C. Control Objective #3 - Systems Design and Development
- Review and evaluate the procedures for systems design and
development.
- Review design specifications schedules, look for written evidence
of approval, and determine if the design specifications comply
with the standards.
- Determine if an audit trail and programmed controls are incorporated
in the design specifications of a recent project.
- Review samples of source documents used for data entry which
are included in SDLC workpapers of a recently developed application.
Determine if they are designed to facilitate accurate gathering
and entry of information.
- Obtain and review programs to determine if they comply with
the University's programming standards.
D. Control Objective #4 - Testing Procedures
- Review and evaluate the procedures for system and program
testing.
- Review documented testing procedures, test data, and resulting
output to determine if they appear to be comprehensive and if
they follow University standards.
- Review the adequacy of testing performed on the manual phases
of an application.
E. Control Objective #5 - Implementation Procedures
- Review and evaluate procedures for program promotion and implementation.
- Review documentation of the program promotion procedure. Determine
if the standards are followed and if documentation of compliance
with the standards is available. Trace selected program and system
software changes to the appropriate supporting records to determine
if the changes have been properly approved.
- Review documentation of the conversion/implementation of a
newly developed application. Determine if the University's implementation
procedures were followed.
F. Control Objective #6 - Post-implementation Review
- Review and evaluate the procedures for performing post-implementation
reviews.
- Review program modifications, testing procedures, and the
preparation of supporting documentation to determine if the University's
standards are being followed.
G. Control Objective #7 - Maintenance of Applications
- Review and evaluate the procedures for the maintenance of
existing applications.
- Review program modifications, testing procedures, and the
preparation of supporting documentation to determine if the University's
standards are being followed.
H. Control Objective #8 - Control over Systems Software
- Review and evaluate the procedures for modifying systems software.
- Review systems software modifications, testing procedures,
and the preparation of supporting documentation to determine if
the University's standards are being followed.
- Review and evaluate documentation of in-house developed systems
software and the features/options of proprietary systems software
in use.
I. Control Objective #9 - Documentation Standards
- Obtain and review the documentation standards to determine
if they are complete.
EFFECT OF WEAKNESSES
Because it has been estimated that a major portion of the cost
of an application over its useful life is incurred for maintenance
after the application becomes operational, if little attention
is given to the SDLC in the creation of a system, excessive maintenance
costs can be incurred, especially if it is necessary to put controls
in after the application is already in production. Redesign is
not only expensive, but difficult to accomplish.
If accurate and comprehensive documentation is not maintained,
the auditor will have difficulty assessing controls without expending
substantial effort to obtain an accurate description of significant
applications and their relationships to one another.
If modifications to application and system software are not adequately
controlled, the integrity of the software may be compromised by
unauthorized changes in programs, procedures, or data.
When an application is properly designed, systems development
and documentation controls can prevent or disclose the following
types of errors:
- implementation of applications that do not have adequate application
controls;
- development of applications that either do not meet management
objectives or do not operate in accordance with original specifications;
- implementation of applications that have not been adequately
tested, and;
- implementation of applications that are susceptible to unauthorized
modification.