Table of Contents Table of Contents
Previous Page  246 / 499 Next Page
Information
Show Menu
Previous Page 246 / 499 Next Page
Page Background

This report is intended for use by the management of the Variable Annuity Life Insurance Company ("VALIC") and its subsidiaries.

VALIC Retirement Services Company ("VRSCO") and VALIC Financial Advisors, Inc. ("VFA"), its user entities, and the independent

auditors of its user entities, and is not intended and should not be used by anyone other than these specified parties.

Back to TOC

Click

VALIC

.com 39

Quality assurance testing takes place in the system test environment. Mainframe and distributed application

program changes are tested prior to loading into the production environment and testing approvals are

documented

(12.1)

. VALIC uses the CMNA system for documentation of approvals.

Testing must be reviewed and signed off by the appropriate business units before a change can be approved

for production. Appropriate VALIC user management must approve all mainframe and distributed application

program changes before being placed into production

(12.2)

.

Once test results have been reviewed, the QA coordinator, the application manager, and the appropriate user

approve the move to production in the CMNA system. Once approved, the master scheduler approves the

final moves to production stage and to production within PanAPT and CMNA. Moves from production stage

to production scheduled and normally execute each Sunday evening, but may be scheduled at other times

on request. VALIC change management staff and the development programmer verify whether the move to

production was successful by examining the libraries and job run history.

Mainframe Application — Corrections

If a correction is required to a program being tested in the system test environment, the programmer will initiate

a newmove request to check the program out from the system test environment, make the necessary changes

in the development environment, test, and then close the move request for migration back to system test

environment. These move requests follow the normal move process with an early stop at the system test stage.

The approval process is identical to that for normal moves up to those stages. An early stop move may also be

made to the stage testing or production stage environments if necessary.

Mainframe Application — Emergency Change Management Process

The emergency change management process is similar to the standard process described above with the exception

that approvals can be obtained after the change has been implemented into production. The programmer creates an

emergency move request in PanAPT, which checks the members out into a separate emergency library, so that any

normal development changes will not be overlaid. Testing is performed in the development environment. Mainframe

and distributed application program changes are tested prior to loading into the production environment and testing

approvals are documented

(12.1)

. The migration fromdevelopment bypasses the QA testing levels andmoves

straight to production stage. The move request is approved within PanAPT and CMNA, by the QA coordinator

(for migration to production stage) and the master scheduler (for migration to production), upon notification

from the programmer and applicationmanager and review of evidence of test results and user signoff. Mainframe

and distributed application emergency moves and production fixes are approved by applicationmanagers

(12.5)

.

Emergency moves, for batch jobs, are not regularly scheduled. They are completed upon separate request.

Distributed Applications — Change Management

There are four distributed application environments residing on separate servers: development, acceptance test,

production staging, and production. Microsoft Corporation’s Team Foundation Server (TFS) is used for change

management and to protect source code. TFS saves backup versions of the source code and change history.

TFS promotes modules between environments. A team lead promotes changes from the developer’s code

branch to the main test branch. An authorized non-developer staffmember of the appropriate Business Solutions

Development department further promotes from the Main branch to QA environment and then to Production

Staging. A separate authorized non-developer staffmember of the appropriate Group Retirement Application

Support department makes the physical move of executables from the staging server to production.

Distributed Applications — Standard Change Management Process

The programmer checks out the programs that require modification from a project-specific branch in TFS,

which copies the source code from TFS to the programmer’s PC. The programmer then completes the code

modifications, unit tests, and checks the files back in. The Team Lead merges those changes up to the Main library

for developer integration testing in the development environment.

III. Description of the VALIC Defined Contribution Plan Administration System