The purpose of validation is to verify that source and data improvements applied during other Positioning tasks did not introduce any functional changes to the system. As stated early in this stage, functional changes should not be introduced into a Positioning task. This causes the loss of one's audit trail and will result in endless confusion should a functional anomaly be introduced during the task itself or during the functional change. Functional upgrades to a system should be applied between Positioning tasks and never during a task.
Specific objectives of validation include:
· Run identical data through the original and the positioned code
· Verify that no functional changes were introduced during the Positioning task
· Assess and resolve any differences that were introduced
· Bench mark run time statistics and verify that any run time differences are either acceptable or resolved
· Certify systems, if applicable, as Year 2000 compliant
The entrance criteria for the validation task are listed below.
· Completion of or a directive by a given Positioning task to enter the validation task
· Completion of a technical review for code being validated, including a sign-off on the appropriate Positioning form
· Availability of a suitable test suite (data) to use in executing the validation test
· Identify programs to be tested, compile & execution control language, screen maps and related components in the Original/Input and/or Output/Final libraries as specified in the task being validated
Note: It is advisable to separate systems using a high-level qualifier into different data set groups if a project crosses system boundaries.
· Create source libraries and apply source type abbreviations for data names as follows:
- CBL (COBOL)
- ALC (Assembler)
- CPY (Copy)
- MAC (Macro)
- PLI (PL/I)
- C (CCC)
- Comparable acronyms for related languages
· Create remaining libraries using the following abbreviations:
-A LOAD library for executable load modules (LOD)
-A source library for execution control language (JCL, CLL, ECL, etc.)
-Additional supporting libraries for MFS, BMS, Screen etc., as (MFS), (BMS), (SCR) and so forth
· Assign a name to each original library as follows:
-"Standard high-level name.'Original'.'3 digit qualifier'."
(production freeze copy)
-"Standard high-level name.'Input'.'3 digit qualifier'."
(input to conversion tool copy - with manual changes)
-"Standard high-level name.'Output'.'3 digit qualifier'."
(output from conversion tool)
-"Standard high-level name.'Final'.'3 digit qualifier'."
(output with manual changes - final copy to be tested)
The personnel and skill requirements necessary to meet the validation task objectives are identified below.
· Testing/Validation Expert
- Expertise in executing and measuring system testing and validation
· Current Systems Expert
- Knowledge of existing system source operational requirements and application functionality
· Systems Programmer
- Security access to physical system objects
· User Requirements Analyst
- Knowledge of existing application user requirements and priorities
The system components and related inputs required to initiate and complete the validation task are listed below.
· All application components of interest stored in Original or Output libraries
· Validation data capable of providing 70% or better logic coverage
· Suitable test execution environment
· Performance requirements for system
· Testing standards for the organization
· Positioning control log Form 022 or Data definition standardization control log Form 023 or Physical data upgrade control log Form 024 as required by task
· Positioning work plan Forms 020 as required by task
Technologies supporting the validation task include change integration, comparator, configuration management facility, data migration, interactive program analysis, open systems repository, testing, virtual date utility, compiler/preprocessor, spreadsheet, and word processing tools. These tools are used to represent information as required by this task.
Change integration tool
The main goal of the change integration tool in this task is to detect, consolidate and reconcile multiple versions of applications. The change integration tool should provide robust impact analysis capabilities for identifying versions that contain differences, name patterns for merging different versions of members with different names and an intelligent merge editor that focuses on maintaining an audit trail of all modifications and conflicts.
Change integration tools associated with Year 2000 projects are often used to help companies upgrade their purchased applications by reconciling new vendor releases (i.e. Year 2000-compliant) with local modifications and to help companies combine Year 2000 updates with ongoing application enhancements/maintenance changes.
Comparator
This tool is used to validate changes made to source code or to physical data by comparing the relevant or output files and producing listings of any differences it finds.
Configuration management facility
The main goal of the configuration management facility tool in this task is to provide versioning capabilities necessary to store multiple versions of an element. This allows for creation of working version libraries. Other requirements include controlling access to libraries by defining user access rights and standard change control procedures and providing a wide variety of ways to view change information (current, historical or changes only).
Data migration tool
Within this task, the role of the data migration tool is to automate the process of expanding the number of test records to include a broader set of testing values. This may involve inserting new data values based on some default value or some other user criteria. Data migration tools associated with Year 2000 projects are often used to convert data stores into Year 2000 specific data for accurate and futuristic testing.
Interactive program analysis tool
The main goal of this tool in this task is to provide an interactive, flexible method of analyzing source code to determine all possible logic paths connected with a specific field or fields, paragraph, or function.
Some interactive program analysis tools execute solely on source code logic, building graphical analysis diagrams of various types based on the source code instructions, and allowing the user to navigate from the diagram(s) to the source code and back again. Other interactive program analysis tools actually execute the program with test data, allowing the user to interrupt the process at any point to test data values currently in use and to change them to see what effect new values will have on the program flow.
Open systems repository
A repository provides an important, yet optional, capability to link data definitions to other definitions and to physical objects using a formal model. Use of repository in this task requires that system-wide meta-data was established during early analysis steps. For large expansion efforts, this repository model can be maintained as a sophisticated mechanism for managing project efforts.
Requirements include the ability to reflect system components as objects within the repository model and populate that model from a legacy environment. The objective in this task is to reflect certified systems in a central tracking facility.
Testing tools
Several types of tools fall into the testing tool category. Though different in function, each tool type is primarily used for one or more facets of the testing process. Though comparators are heavily used in the testing process, they are also necessary in many other tasks, and therefore form a tool category of their own.
One type of testing tool used in this task is a dynamic coverage analyzer. A dynamic coverage analyzer is typically used in conjunction with a compiler, or is a feature of a compiler. This analysis capability is set up during the compile, and occurs during execution of the code. The analyzer reports percent of logic statements covered by the utilized data or the actual count of the statements covered. In some cases, the tool can also report on the number of times a line of code is executed.
The purpose of another testing tool, an on-line transaction capture/playback tool, is to collect a series of on-line CALLs so as to provide data for the application to be run later in a batch mode.
Virtual date utility
The main role the virtual date utility tool plays within this task is to provide the capability to intercept the current system date (and time in some cases) to ensure the accuracy of Year 2000 or other date/time modifications. Requirements include executing applications using future system dates. This enables the testing of applications before the turn of the century to help avoid potential problems.
Compiler/preprocessors
A source language compiler/preprocessor is required to parse source code and convert it into machine executable instructions. This compilation process identifies many types of errors, and requires their correction before it will complete successfully.
Spreadsheet
Spreadsheet tools offer a convenient format for recording much of the information gathered throughout this stage. Referenced Comsys-TIM Forms have been pre-loaded into certain spreadsheet tools to facilitate data entry and analysis. While highly desirable, spreadsheets are not essential to this task.
Word processor
In the absence of a spreadsheet tool, this is required to develop tables using QA checkpoints and audit trail reports.
The validation task is comprised of the following task steps:
