Definition of Terms

Definition of Terms

AFCA - Air Force Communications Agency. Formerly the Air Force Command and Control,
Communications, and Computer Agency. Tasked by HQ USAF to coordinate Y2K resolution
efforts across the Air Force. Located at Scott AFB IL.

AFY2KDB - Air Force Year 2000 Database. A centralized database maintained at Scott
Air Force Base by INET. Designed to aid maintenance organizations in resolution efforts
such as identifying interfaces, developing cost estimates, and reporting system status.
Will also be used as the primary data source for AFCA updates to Air Staff beginning
July 1996. Selected fields are uploaded to the DIST to meet DoD Y2K requirements.

AFY2KWG - Air Force Year 2000 Working Group. Chaired by AFCA. Membership
includes all Air Force MAJCOM and FOA POCs and delegates. POCs from other DoD
services and agencies are also invited to participate.

Awareness Phase - Period in which efforts focus on promoting Y2K awareness at
all levels across the Air Force. Includes identifying points of contact (POCs); gathering
information throughout the DoD, the federal government, and industry; and establishing
communication channels and processes to be used throughout Y2K resolution efforts.

Awareness Strategy - Systematic approach to promote awareness related objectives;
addresses resources to be used and how each will be utilized.

Assessment Phase - Period in which efforts focus on 1). assessing the scope of Y2K
impact and 2). conducting a detailed analysis of systems. Also includes collecting
inventory data for the AFY2KDB and the DIST.

Assessment Strategy - Systematic approach designed to provide 1). a rough order
of magnitude of Y2K impact and 2). detailed analysis information; addresses resources
to be used and how each will be utilized.

Baseline Inventory - Initial inventory of system data using the AFY2KDB. Consists
of 54 of 108 data elements identified by the AFY2KWG. Due to AFCA NLT 5 July 1996.

Command and Control System (C2) - Generally those management information systems
designed to directly aid commanders in monitoring and controlling operations.

Compliance - Year 2000 compliant application systems are capable of correct
identification, manipulation, and calculation using dates outside the 1900-1999 year range
and have been tested as such. The term compliance continues to be a heavily debated issue.
This definition allows for short term compliance using procedural approaches and long term
compliance utilizing data approaches. See also Section 5.1 for Compliance Criteria as
defined by the Software Technology Support Center. NOTE: Definition provided by IBS

Compliance Strategy - The approach to storing, exchanging and processing date
information that a system or group of systems will use to mitigate Y2K impacts. See
Redevelopment, Replacement, and Renovation.

Corporate Approach - Brief, high level outline of an organization’s strategy for
addressing Y2K at the Air Force and MAJCOM/FOA/DRU levels.

CSAD - Computer System Authorization Directory . Maintained and owned by AFCA/XP.

Data Approach - Long term compliance approach in which files, programs, and JCL
using a 2-digit year format (YY) are converted to a 4-digit year format (YYYY). More
time consuming and expensive than Logic Approach. Also referred to as Field Expansion.
NOTE: Field Compression is another Data Approach that can be used but is discouraged
due to complexity. Compression involves modifying two digits to a binary value
(1=1900, 0 = 2000) and either embedding it or using it as a century indicator. According
to Cap Gemini, JCLs don’t have to be changed but files still have to expanded.

Detailed Analysis - Provides detailed information about system exposure to aid in
selecting a renovation approach and establishing system priorities. Requires use of
“analysis” tools designed to identify complexity (use of embedded logic, literals, date
fields within record keys, inconsistent naming, mixed formats, etc.). Analysis includes
source code, files, databases, JCL, sorts, reports, screens, call modules, and copy
members.

DIST - Defense Integrated Support Tools. Originally designed to serve as a decision
support system for evaluating migration candidates across the DoD, the DIST has
recently been selected by the DoD Year 2000 Working Group to serve as the DoD
database for system inventory information for Year 2000 and other purposes. EDS is
the prime contractor for this DISA owned database.

Embedded System - Generally weapons, navigational, security, warning, guidance,
and other “real time”systems. Tend to serve no other function independent of the system
in they are embedded. See Mission Critical Computer Resource (MCCR).

Event Horizon - The year a system is expected to experience Year 2000 problems
due to date projections.

Impact Assessment - Provides a rough order of magnitude to be used as a “wag” for
senior managers.

Implementation Phase - Period in which efforts focus on placing Y2K compliant
systems into production.

Implementation Strategy - Systematic approach designed to place certified Y2K
compliant systems into production; addresses resources to be used and how each will
be utilized.

INET - The organization contracted by AFCA to develop and maintain the AFY2KDB.

Inventory - The process of collecting system data and reporting it to the AFY2KDB.
Used a noun, refers to the data collected, reported and stored in the AFY2KDB and
the DIST for Air Force and DoD use. Inventories are critical to providing cost estimate,
system status, interface, and certification information. See also AFY2KDB and DIST.

Leap Year - There are three factors used to determine leap years. They occur
every four years unless the year is divisible by 100 unless the year is divisible by 400.
As a result, the Year 2000 is a leap year.

Logic Approach - A compliance approach involving retention of a 2-digit year
format (YY) and modification of date processing logic to correctly interpret 00, 01, ...
as being years 2000, 2001, ... Allows up to a 100 year date span to be processed by
a system. Also referred to as Procedural Approach, Field Interpretation, and
Windowing. See also Tools.

Mission Critical Computer Resource (MCCR) - According the Defense Systems
Management College’s MCCR Management Guide, MCCR refers to the totality of
computer hardware and computer software that is integral to a weapons system along
with the associated personnel, documentation, supplies, and services. For procurement
purposes, the Armed Services Procurement Act (10 U.S.C 2315) defines MCCRs as
intelligence systems, cryptologic systems related to national security, command and
control systems, and weapons systems.

Mission Criticality Categories: CAT I - Directly supports operating system, flying
operations, contingencies, national security, or public law; CAT II: - Supports day to
day personnel and financial operations; CAT III: Supports other administrative support
systems

Management Information Systems (MIS) - Generally support related systems such
as payroll, personnel, and inventory control systems. Also referred to as Automated
Information Systems (AIS).

Potential Problems Resulting from Y2K - Ambiguous or erroneous calculations,
erroneous sorts, spurious data selection criteria, archived data problems, data file
corruption, dates as parts of names or security passwords, leap year related problems,
and non-date functions using system date fields for hashing, generating random
numbers, or recycling tapes. (Provided by STSC)

Project Management Plan (PMP) - Defines the organization’s overall strategy
in detail. Addresses Y2K goals and supporting objectives. Essential to Y2K
management efforts at the MAJCOM/FOA/DRU and development/maintenance levels.
Documents acquisition and resolution strategies, certification and accreditation
processes, cost/benefit analyses, performance measures, management approaches,
responsibilities, configuration management, and more.

Redevelopment - Current application/system is reengineered using a new
technology such as client server or an existing technology prior to its event horizon.

Renovation - Modifying an application/system to meet the Year 2000
compliance requirement (usually transparent to the user). Includes short term
“survival” approaches along with long term approaches. (See Data Approach
and Logic Approach)

Renovation Phase - Period in which efforts focus making noncompliant
systems compliant.

Renovation Strategy - Systematic approach designed to ensure Y2K noncompliant
systems are made compliant using either the data approach, procedural approach, or
both; addresses resources to be used and how each will be utilized.

Renovation Approach - Either Data Approach, Logic Approach, or a combination
of both.

Replacement - Current application/system is replaced by another application/
system prior to its event horizon.

System - By necessity, a very general "context sensitive" term. The "IEEE STANDARD
GLOSSARY OF SOFTWARE ENGINEERING TERMINOLOGY defines system as "a collection
of components organized to accomplish a specific function or set of functions. It
also defines a subsystem as "a secondary or subordinate system within a larger system."
MIL-STD-498 (5 December 1994) tries to deal with the potential ambiguity as follows:

a. The term "system," as used in this standard, may mean:
(1) a hardware-software system (for example, a radar system)for which this
standard covers only the software portion, or
(2) a software system (for example, a payroll system) for which this standard
governs overall development.

b. If a system consists of subsystems, all requirements in this standard concerning
systems apply to the subsystems as well. If a contract is based on alternatives
to systems and subsystems, such as complex items, the requirements in this
standard concerning the system and its specification apply to these alternatives
and their specifications.

Tools - There are a wide variety of tools that can be used throughout each of the
5 phases of the Year 2000 Resolution Process. The following categories are provided
as examples:

A. Software Inventory Tools - Help determine all code, JCL, databases, etc. that
constitute a system. Essential to complete impact analysis.
B. Configuration Management Tools - Turns software into configurations. This is
important during modification and elimination of bugs in code prior to systematically
recording what software is fixed and what still needs to be fixed.
C. Change Tracking Tools - Logs request for changes and tracks them to
resolution. The change tracking database can be a useful place to look for changes
regarding dates or bugs concerning dates.
D. Cost of Work Estimating Tools - This tool, spreadsheet, or methodology
predicts how much work will be needed to remove Year 2000 problems. Check how
the model you intend to use has been validated. That is, its predictions compared
with actual human performance in removing the Year 2000 problem. Because
carefully measured empirical data on finding and removing Year 2000 problems
is currently hard to find, the cost model may not have been separately
calibrated with the valid data collected from real Year 2000 problem removal
projects.
E. Problem Code Finding Tools (Clock Simulators) - These change system
clocks, unknown to programs. They are an easy way to quickly check if code
has Year 2000 problems.
F. Problem Code Finding Tools (Date Finders) - Help locate date-oriented data,
variables, or information in the code.
G. Problem Code Finding Tools (Browsers) - Scans code and inspects.
Scanning can be speeded by looking at structure charts, selecting code, and
immediately jumping to the code. They can save a lot of time over just using a
text editor. Browsers can include some reverse engineering tools or maintenance
workbenches.
H. Impact Determining Tools (Impact Analyzers) - These essential tools do
the hard work of finding what is related to what. However, just because an item
is estimated to be affected doesn’t mean that item will need to be changed to
fix a specific Year 2000 problem. They tend to overshoot their estimates to be
on the safe side.
I. Impact Determining Tools (Cross-references) - Identify variables,
procedures, or other items are in the code. Provide a limited form of impact
analysis.
J. Impact Determining Tools (Program Slicers) - Help identify all the code
affecting a given variable or statement. These tools don’t replace the need for
regression testing.
K. Change Makers (Data Cleanup) - Extract and convert data from a non-
relational to a relational DBMS.
L. Change Makers (Field Expansion) - Expand 2-digit year fields to 4-digit
year fields.
M. Change Makers (Data Name Rationalization) - Introduce standard or
more uniform names to date-oriented fields.
N. Change Makers (Code Modularization) - Help identify chunks of code
and may wrap an interface around them, making them into procedures or
modules. Fall-throughs into this code are replaced by calls to it. This is
helpful because certain changes in the module can be hidden without fear
that other parts will be affected.
O. Change Makers (Date Subroutines) - Reusable code modules that
have correctly implemented the handling of dates.
P. Testing and Regression Testing Tools - Essential for checking
whether software changes introduced unwanted problems.
Since automatic impact analyzers don’t check impacts in all possible
inter-code relationships (e.g. timing), testing is nearly always a necessary
part of the software change.

Validation Phase - Period in which efforts are focused on testing,
certification, and accreditation of systems for Y2K compliance.

Validation Strategy - Systematic approach designed to ensure all systems
have been tested, certified, and accredited for Y2K compliance; addresses
resources to be used and how each will be utilized.