This phase deals with those activities required to define the scope of the problem and set up the infrastructure necessary to solve it. The primary deliverable from this phase is the Project Plan. _____________________________________________________
"...The
first problem is the inventory. Only three percent
of
organizations even know what’s in their application
portfolio.
And they can’t test something if they don’t know
it’s
there..."
-
Eliot Weinman, President, Software Productivity Group
The primary purpose of the Assessment Phase is to gather and analyze the information in order to determine the size and scope of the problem. Only after the size and scope of this problem have been determined, can an estimate of the cost in terms of dollars and work years be made. The major issues encountered during this phase will be concerned with either source code or budgeting and scheduling. The primary deliverable from this phase is the Project Plan.
Almost every industry consultant addressing the Year 2000 recommends that businesses first size the impact of Year 2000 throughout their organization and follow-up with a detailed analysis of each system to further identify Year 2000 costs and exposure. Most recommend the first step in assessing the problem correctly is to inventory every system in the organization.
The Code Inventory involves locating all of the code which must be modified for the Year 2000. The volume and type of code will determine the magnitude of the problem. Source code may be housed in a single repository, or the ownership and responsibility for maintenance may be decentralized and spread over the work force. Having the code in a centralized repository of some type, whether it's an elaborate vendor library package or a simple partitioned data set, is a big help in solving the Year 2000 problem. If such a structure does not exist, valuable time will be spent in trying to locate code. Determining which version of a copy member or COBOL program matches the code currently running in production will consume resources that could be better employed elsewhere.
All code must be inventoried and tracked and its relationship to other code determined. A total count of the lines of code (LOC) will assist in determining how many and what type of resources will be required in order to make the changes. Organizing code by application will assist in the preparation of the detail plan. This will help in the identification of applications which exchange data so that changes to these applications can be scheduled for the same time. In addition, knowing where the source code is will enable that code to be matched to production load modules to determine whether there is any missing source.
Knowing what Language code is written in will help in the following areas:
If you decide to buy a Year 2000 tool to help with this effort, the tool must work with the language(s) you have.
In order to modify code for the Year 2000, you must have programmers skilled in the language the code is written in. Knowing what percentage of your code is written in each language aids you in determining if you have the correct skill mix. For example, if 50% of your code is written in ALC, but 100% of your programmers code only in Cobol, you have a problem.
Ownership of code is important in order to determine who is responsible for making the Year 2000 changes and certifying that each piece of code is Year 2000 compliant.
Select CODE INVENTORY BEST PRACTICE for information on how SSA maintains its source code.
An assessment survey can be used to gather the necessary information about source code which is not contained in a central repository. In addition, it will aid in the identification of COTS products which may be imbedded within other products. The survey process seeks to collect system data in a standard format. Once the information is collected, it can be stored in a central database or spreadsheet. Collecting data such as system IDs, descriptions, components (language, platform, etc.), interfaces, owners/users/maintainers, and other relevant information is critical to any future efforts such as prioritizing and scheduling systems for renovation. EVERY system, even those currently selected for migration or retirement, must be inventoried.
The assessment survey should be distributed to all Agency departments. It will yield several important results:
It provides the first indication of the level of effort which must be accomplished. When the results of the surveys are summarized, a very rough cost estimate can be applied using Gartner Group estimates of $1.10 per Line of Code. Although this is a "ballpark" estimate it nevertheless provides a common basis for comparison across government and industry.
Secondly, the survey may also identify that common components exist which can be managed from the central project team. For example, the collection and distribution of information regarding in-house and vendor tools and services. Knowing which platforms and languages are most common will allow the central project team to focus their efforts, such as in the evaluation of tools for analyzing systems written in specific languages.
Finally, even if a central repository is in existence for the bulk of an Agency's code, it is not uncommon, due to the proliferation of personal computers and local area networks, for individual departments to develop their own computer systems. The survey will help to identify these systems so that awareness, assessment and renovation can be extended to them. Not only that, a survey which is properly worded will also generate input from those infrastructure systems (environmental such as heating, security, and elevators) which must also be date tested.
Select YEAR 2000 SURVEY to see a sample survey used by DOD.
Most companies will discover, as they inventory their code, that there are some number of programs that are running in production for which the source code is no longer available. In some cases these programs have been running for years, needing no modifications and causing no problems. Unfortunately the Year 2000 issue requires that every piece of code be examined to determine if any two digit date handling is involved. This will require the re-creation of all programs that have no source code. Missing Source Code increases both the scope and cost of the project because it requires time and resources to develop both the functional specifications and program specifications in order to rewrite the missing modules.
There are two ways to address this issue. The first option is to assign the task to in-house programmers to have them either rewrite the code from the original specifications (if available) or disassemble the object code and try to re-create the source from that.
The second option is to send the object code to a vendor who has the ability to re-create source through a combination of existing software tools and proprietary products. In both cases the final result should be source code that can be examined for Year 2000 compliance and is easily maintainable.
The LIST OF YEAR 2000 VENDORS contains information on those vendors who are able to re-create source code.
A one-to-one mapping of source code to executables code must be made in order to determine that the source code in the inventory actually corresponds to the executable code running in production. There are several products on the market which allow you to map your source code to your executables. In general, they each produce a report that breaks all the load modules in a particular load library into the component CSECT'S and display pertinent information about the source code.
Not only does application code need to be changed, but so do all the operating system software and program products which surround the application software. The first step in this process is compiling a comprehensive list of vendor software used by your organization. The survey process should help in this effort. Once a list of vendor products used by your organization has been developed, it should be checked against a VENDOR COMPLIANCY LIST (1/2). This list should specify by product whether the product is currently Year 2000 compliant, when and in what release it WILL be made compliant, or whether it will NOT be made compliant. Once you have matched your vendor software against a vendor compliancy list, you can begin to estimate the work effort involved in bringing your vendor products (including operating system software) up to a Year 2000 compliant release.
CONTRACTOR MAINTAINED SOFTWARE
Some agencies will also have to deal with the issue of contractor maintained software. Software in this category will need to be modified for the Year 2000 and may be done by the contractors. The issue here will not be workyears but money. Most third party contractors will not regard the Year 2000 changes as a part of routine maintenance because of the work effort involved. Funds to cover these costs must be allocated in agency budgets.
When the source code issues have been resolved and an inventory established, it is time to consider the budget and scheduling issues. System owners, users, designers and developers can not assume any system is Year 2000 compliant until it has been examined. Estimating the amount of time required to actually make a module/program Year 2000 compliant is not an exact science. It will depend upon the complexity of the program, whether documentation exists, the skill level of the programmer and the familiarity of the programmer with the program in question. One process which has been used extensively is to conduct a pilot, maintaining careful records of the time required to modify the code for Year 2000 compliancy. The code selected should be representative of the bulk of the inventory. The time spent can then be extrapolated over the total inventory, to produce a work year estimate. If more than one pilot is conducted, using modules of varying complexity, the work year estimate gained can then be weighted across the inventory, depending upon the percentage of code by complexity.
Another reason for conducting a pilot is to determine if a Year 2000 tool would be beneficial. Piloting an application without the aid of a tool and comparing the results against the same or similar code modified with the assistance of one or more of the tools available will show whether savings can be achieved. Yet another reason for conducting a pilot would be to determine which approach should be used when changing the code. Several applications could be piloted using different approaches and the results compared to see which approach works best.
One drawback to the use of pilots is the fact that they can consume a considerable amount of time and resources and the end date, January 1, 2000, is rapidly approaching. For that reason any application selected as a pilot should be large enough to have meaning but small enough to be concluded in a reasonable time frame. Select PILOT BEST PRACTICE for details of the pilots at SSA.
This is the point in the assessment phase when all other technical issues which could affect the project need to be identified. Examples of these issues follow and will affect the cost of solving the Year 2000 problem.
Forms
- pre-printed and computer generated
On-site
vs. off-site contractor resources (off-site adds
communication
costs)
Screen
issues (2 or 4 position years)
Library
clean-up
Format
of dates on inputs and outputs
Standardized
date routines
Once a rough work year estimate has been obtained, it is time to begin an indepth analysis of the costs associated with solving the Year 2000 problem. For many companies, there will be a single opportunity to request funding. It becomes very important, therefore, to make the cost estimation as accurate as possible.
There are a number of factors which will influence the cost of making code Year 2000 compliant in addition to modifying software. They include building the test environment, buying tools and services, adding hardware, upgrading operating system software and commercial products, etc. The Department of Defense has developed a checklist for ESTIMATING SYSTEM COSTS FOR THE YEAR 2000, which includes those additional items which must be considered. The checklist will indicate those areas where costs should be adjusted because of your specific environment.
There are a variety of types of tools that are available to assist with the Year 2000 issue. Testing tools, re-engineering tools and other types will all be necessary at various times.
There are two types of tools that are being marketed to deal specifically with the Year 2000 problem. The first type consists of those tools that change the system date for an individual batch job or CICS region. This allows you to determine how specific programs or systems will handle processing for any chosen future date.
Tools that help locate dates and related fields and in some cases change those dates in the source code comprise the second category of tools. These tools usually provide a pre-defined set of fields such as "century", "year", "yy", etc. to which fields known to be dates in specific systems can be added. The tools then examine the code for occurrences of these fields and also track the flow of dates as they move from field to field. The output produced by these tools helps pinpoint those areas in the code that must be examined most closely.
It is important to note in any discussion of Year 2000 tools that there is no "silver bullet", i.e., a tool that will find all date fields in the code and make the necessary changes. No one has developed such a product and most experienced programmers do not believe one is possible given the nearly infinite possibilities for storing and manipulating dates.
The LIST OF YEAR 2000 VENDORS and TOOLS at the HQ AFCA, DISA and Peter de Jager homepages will provide more information on those vendors who have tools that fall into the two categories described here.
Specific tools can also provide additional information that will be useful for prioritization efforts. For example, a system that is originally projected for 6 work-months might require 9 work-months according to a Year 2000 analysis tool. The increase in workload may move this system up in the conversion schedule. It may even be possible that such a system would be considered for retirement, replacement, redevelopment, or a different renovation approach. In short, a detailed analysis is critical to the scheduling process.
Procurements may be required at any point during the Year 2000 project, but the need for them will most often surface during the assessment phase. An overall procurement strategy should be developed during this phase and refined in later phases. Tools to be used during the renovation phase should be bought here. This includes tools which help with the analysis, tools which allow system date manipulation, and common date routines. In addition, once the assessment has been completed, it will be possible to determine whether additional manpower will be needed, or whether the project can be completed with existing resources.
This is also the time to begin an inventory of vendor products and tools and to determine whether there will be costs associated with upgrades to Year 2000 compliant releases, as well as to assess whether the data center will have sufficient hardware capacity (including both CPU and DASD) to complete the Year 2000 conversion.
It is during the Assessment phase that the schedule to be followed in the Renovation and Validation phases will start to take shape. Each agency must conduct a risk analysis and prioritize systems based on the results. The right approach must then be determined for each system. Only after the renovation schedule has been developed can the validation schedule be put together. The sections following will explain each of these pieces in greater detail.
Only after an inventory of source code has been completed and a rough estimate of the size and scope of the problem at your agency been obtained, can decisions regarding priorities be made. Most agencies will begin this project by assuming that all systems will be completely converted and tested in a timely manner. When the data gathering portion of the assessment phase has been completed and resource estimates are available, some agencies will realize that it is impossible to do everything.
Where all work cannot be completed, agencies will need to undertake a risk analysis of their systems. Each system will need to be assigned a priority based on its purpose and end products. Special consideration must be given to those systems that produce output for other federal or state agencies. Failure to convert and thoroughly test those systems will have serious ramifications outside the originating agency. Those agencies that get a late start on the problem and/or don't have the necessary infrastructure in place may find themselves with not enough time to convert and test even mission critical systems.
The challenge facing every agency is enormous but there is too much at stake for it to be ignored. The American public and the economy of the country depend on a steady, predictable flow of government dollars and services.
Federal agencies, because they impact the lives of every American citizen and play such a huge role in the nation's economy, need to be in the forefront on this issue. Any agency that conducts an analysis and determines that the conversions of mission critical systems are in jeopardy must take whatever steps are necessary to secure the additional resources needed to ensure timely completion. This may include the reprogramming of existing funds from currently scheduled work into the Year 2000 projects. While this may not be a desireable course of action, at some point between now and the Year 2000, it may become the only course of action yet remaining.
There are a number of decision alternatives which can be applied singly or in combination which will affect the Year 2000 solution selected. Each agency must examine every system and determine which of the alternatives apply. Alternatives include: code modification, re-engineering, replacement and retirement. When first confronted with the year 2000 issue, code modification seems the most likely candidate. With the remaining time to the year 2000 shrinking, agencies will need to seriously consider the other options.
Code modification involves making all necessary changes to the system to handle century processing without restructuring the code. As few changes as possible are made so that coding and testing time are kept to a minimum. The drawback to this approach is that the code is not enhanced in any way and the year 2000 project becomes viewed as an expensive maintenance effort.
Re-engineering offers the greatest rewards and risks. The rewards are great because instead of simply modifying an aging legacy system, the system is redeveloped, perhaps by employing new technology such as client-server. Major changes and enhancements can be made and there is a perception that money is not being spent on an old system that might not be around much longer. The risks associated with this option are also greater because this option may take longer to implement than any other. If agencies had started working on this problem ten years ago this option would have been more viable. With time running out and downsizing a fact of life it is doubtful that many agencies will be in a position to implement this option for many of their systems.
Replacement involves purchasing commercial off-the-shelf software from a vendor to use in place of an existing system written by agency programmers. However, as many federal systems are unique, there are often no commercial alternatives available. In some areas such as payroll, accounting and financial systems alternatives exist and should be explored. / Often, however, these systems will require some modification, which should be evaluated when considering this alternative. It is also very important that any purchased system be year 2000 compliant.
The last option is retirement of existing systems. There may be some systems that have outlived their usefulness and others where the cost to modify them is far greater than the benefit provided by the system. Rather than wasting valuable resources making changes to systems in this category these systems should be removed in their entirety with those resources applied to other tasks.
When the renovation schedule has been established and decisions have been made regarding how each system will be handled, attention can be focused on the Validation phase and what approach will be adopted. The Assessment phase should include the development of both a validation schedule and a validation strategy. The schedule should indicate the general timeframes for the validation of all systems and should consider hardware concerns such as availability of processing cycles and storage, along with human resource issues.
The validation strategy also needs to be considered at this point. Many experts are in agreement that future date testing should be done in isolation with no possibility of corrupting or destroying production files. Many agencies will need to establish such a test environment, which may require procurements for additional mainframes, PC's, LAN's, DASD, etc. If the resources need to be available in late 1997 or 1998 the procurements need to start as soon as possible.
There are also numerous technical issues to be considered in developing a validation strategy, such as how files will be aged, how tape compares will be done, and how testing can be conducted if critical vendor products are not yet Year 2000 compliant. Each agency needs to begin to address these issues, now.
Data Exchanges (Bridges/Filters/Interfaces) involve the sending and receiving of data between two organizations outside of the home organization such as between federal agencies, states, counties, and private companies. The National Institute of Standards and Technology issued a FIPS Publication Change notice on March 25, 1996 which said "For Purposes of electronic data interchange in any recorded form among U.S. Government agencies, NIST highly recommends that four-digit year elements be used. The year should encompass a two-digit century that precedes, and is contiguous with, a two-digit year-of-century. In addition, optional two-digit year time elements specified in ANSI x3.30-1985(R1991) should not be used for the purposes of any data interchange among U.S. Government agencies."
Data Exchanges are critical in the Year 2000 effort because they have the potential to introduce/propagate errors from one organization to another. Trading partners can help mitigate this potential pitfall by agreeing early on to schedules, changed record formats, and by providing one another with test files. Where this cannot be coordinated in a timely fashion, bridges can be written to accommodate the transition period. Bridges receive information in one format, modify it, and put it out in another format, such as receiving the year in a 2 digit format, adding century information through the use of an algorithm, and writing the output with a 4 digit year. Where the bridge must accommodate data from a number of sources, it can be table driven, to accept the input in either format, based upon an entry in the table, but output the data in a fixed 4 digit year format.
When bridges are written as separate modules/steps, they can be more easily removed when the sending/receiving programs become fully compliant. Existing documentation should be updated to reflect the insertion of bridges/filters or the use of sliding windows and algorithms.
The project plan that was started during the Awareness phase should be completed as the last step in the assessment phase. The plan should show, at a minimum, the start date and production release date for each system, the major steps to be taken in converting and testing the code and establishing the necessary infrastructure, and the resources required to accomplish these tasks. Beyond these basics, the project plan can be developed to whatever degree of detail is necessary at each agency.
The most challenging aspect of the project plan will probably be the scheduling of each system. This will require tremendous coordination within the agency and also with all data exchange partners. Whenever possible, the goal should be to convert related systems simultaneously to reduce the number of bridge programs that must be written and maintained.
Select PROJECT PLAN to see an example of a Year 2000 project plan.
The Social Security Administration maintains all of its 30 million lines of programmatic and administrative software in a single source code repository called ENDEVOR. The tool was originally purchased as a means of introducing configuration management techniques into the production release process.
ENDEVOR has helped SSA in several ways with the Year 2000 work effort. The ENDEVOR reporting feature allowed SSA to easily determine the number of lines of code at the agency, the number of systems the code was divided into and the percentage of code in each language.
The product produces a footprint which maps the source code to the load module running in production, allowing the programmer to know exactly which pieces of source code comprise each load module. This gives the programmer the ability to recreate each load module if necessary. ENDEVOR footprint reports were run for each production load library. Any load module running in production which contained one or more non-footprinted pieces of source code was then examined further to determine if that source code was missing. All code which was identified as missing was then scheduled for re-creation.
The Social Security Administration was faced with the issues described above and used pilots to determine the scope of the Year 2000 problem at the agency. Two representative legacy systems were selected to serve as pilots. Both systems were on the small side (15,000 and 50,000 lines of code). The programmers were asked to track the time spent making the Year 2000 changes and were instructed to visually examine every line. No Year 2000 tools were used. The only automated assistance was provided by the scan capability of the ENDEVOR package which was used to scan for selected literals such as "date", "year", "mmddyy", etc. The entire process was concluded within 90 days.
The results were extrapolated across the entire source code inventory and showed that it would take from 200 - 450 work years to make the necessary changes to the 30 million lines of code at SSA. The two variables which contribute most heavily to this variation are the complexity of the code and the skill and experience of the programmers making the change. These figures were then checked against a larger system consisting of 300,000 lines of code which had actually been converted several years prior. The results of that effort also produced a figure in the 450 work year range.
Instructions: While we understand that many responses will be best guesses, please take the time to be as accurate as possible. Most items are self explanatory and request information you should already have available. Please circle appropriate responses (more than one answer may be given - feel free to write in additional information if you feel it will be helpful) and answer all items. Should you have a question, please contact: John Doe at (410) 555-1212.
1. System: _______________________________
2. System Manager: _______________________________
3. System Manager's Telephone No: _______________________________
4. System Manger's EMAIL: _______________________________
5. Software maintenance responsibilities for this system belong to:
a. Organizational unit: _______________________________
b. Contractor unit: _______________________________
Include name of person responsible and telephone number if different from system manager.
c. Name: _______________________________
d. Telephone: _______________________________
6. Hardware/Platform
a. IBM
b. UNISYS
c. Honeywell
d. DEC
e. Xerox
f. Cray
g. Personal Computer
h. Other:
__________________________________________________
7. Software Languages(s)
a. COBOL
b. SAS
c. ALC
d. Fortran
e. ADA
f. Mapper
g. C
h. DBASE
i. Lotus
j. Algol
k. GMAP
l. Other(s):
______________________________________________
8. Current date formats being used:
a. yyddd
b. yyyyddd
c. yymmdd
d. yyyymmdd
e. qqyy
f. qqyyyy
g. cyymmdd (c contains '1' or '0'
to denote '19')
h. Julian - number of days since 1
Jan 4713 B.C.
i. Lilian - number of days since 15
Oct 1582 A.D.
j. Other ______________
9. How many source lines of code (SLOC) does your system have by language type. Include procs/reusable code once.
Language LOC
_____________________ _________________
_____________________ _________________
_____________________ _________________
_____________________ _________________
_____________________ _________________
10. What percentage of your LOC do you estimate to be affected
by Year 2000?
(Consider data record layouts, on-line screens, reports, batch
processing jobs, data acceptance routines, date
comparison/derivation logic, and physical date data values)
a.
0-5% b. 6-10%
c.
11-15% d. 16-20%
e.
21-25% f. 26-30%
g.
31-35% h. Greater than 35%
11. Which category does the system fall under.
a. Year 2000 compliant*
b. Requires conversion to be Year
2000 Compliant
c. Scheduled for Year 2000
compliant redevelopment prior to century change.
d. Scheduled for retirement prior
to century change.
* The definition of compliant is a heavily debated issue. For our purposes, consider compliant to mean your system has either 4-digit years in the date fields OR it has subroutines and bridges that ensure the Year 2000 won't adversely affect the system's inputting, processing, outputting, storing, or exchanging of data.
12. When will your system be affected by Year 2000? (Consider systems that project dates, etc.)
a.
1996 b. 1997
c.
1998 d. 1999
e. 2000
13. Does the system interface with other systems?
a. Yes b. No
14. Have you encountered a problem related to the transcentury change already?
a. Yes b. No.
15. If you answered yes to question 14, how did you resolve the problem?
a. Logic placed into program to
generate century
b. Compressed dates through
packing, binary...
c. Expanded the year - CCYY
d. Replaced the system
e. Retired the system
f. Other
__________________________________
16. Do you currently have a Year 2000 project office/program established?
a. Yes b. No.
17. If so, how long has it been active?
a. <3 months
b. 3-6 months
c. 6-12 months
d. > 12 months
18. At what stage is your organization in addressing the Year 2000 issue?
a. Promoting awareness
b. Strategy formulation
c. Preliminary Inventory/assessment
d. Detailed Inventory/assessment
e. Conversion
f. Testing/validation
g. Other
________________________________
19. Does your system use COTS products?
a. Yes b. No
20. If you answered yes to question 19, please attach a list of your COTS products using the format below. Note: If you have contacted the developer and inquired about Year 2000 compliance, enter it in the column headed "Year 2000 Compliant?". If you haven't please write NA in the space provided. If you've been informed the product is going to be compliant, please answer NO and place the month and year in the "Estimated Timeframe for Compliance" column. Examples follow:
Product
Name Company Year
2000 Est. Date for
Compliant? Compliance<
/p>
____________ _____________ ___________ __________
____________ _____________ ___________ __________
____________ _____________ ___________ __________
____________ _____________ ___________ __________
____________ _____________ ___________ __________
____________ _____________ ___________ __________
____________ _____________ ___________ __________
____________ _____________ ___________ __________
____________ _____________ ___________ __________
____________ _____________ ___________ __________
____________ _____________ ___________ __________
____________ _____________ ___________ __________
____________ _____________ ___________ __________
____________ _____________ ___________ __________
____________ _____________ ___________ __________
__________________________________________________________
The following estimate formulas were developed by the Gartner Group, an independent advisor to business professionals making information technology (IT) decisions. Applying these formulas requires an accurate system inventory which includes source lines of code (SLOC).
"...Estimates include project management, labor costs, locating and identifying affected code/data, parsing and analyzing for affected code data; determination of options, implementation of solutions, unit and integration testing, and implementation..."
"...Note that integration testing can be half of the overall cost estimate due to the nature of the solution and the need to develop and/or update current regression test beds to exercise modified date routines..."
- Gartner Group, Key Issue Analysis, KA-210-1262, B.Hall & K.Schick
1. A 2-step process can be used to produce a rough order of magnitude for system applications.
Step 1: Multiply SLOC times .80. This will determine your executable lines of code (LOC).
Step 2: Multiply your LOC times $1.70.*
2. The Gartner Group also proposes application complexity can also be estimated, further refining your cost estimate, provided you have other information such as:
-- Function of
component
-- Type of component
(create, read, delete, update)
-- Number of physical
transaction paths in the component and which ones involve dates
or date-based operations
-- Amount and type of
actions in which dates are used (e.g., sort, compute and
"if" statements)
-- Age and size of
application (an indicator of applied methods and technology)
-- Date field count
-- Date/LOC ratio
Examples of complexity classifications include:
Simple - 5 - 15
hours
Moderate - 15 - 30
hours and
Complex - 30 - 45 hours
The formula is (hours x rate) x ( percent x total components). Here is a quick example:
For 8,000 components (20% difficult, 50 percent moderate, and 30 percent simple), the estimate range would be $7.2M to $13.7M.
3. The Gartner Group also provides a date field expansion estimate based on $3.00 to $4.50 per data record. This includes programming modifications required for accommodation of the new date format. Date field expansion is likely to affect a greater percentage of programs than a programmatic solution, and represents increased logistical and project management costs due to the need to replicate and modify databases, and due to interface requirements.
*The Gartner Group recently increased this figure from a $1.10 to $1.70. How other estimates included in this Appendix have changed is unknown.
NOTE: The MITRE Corp. recently released the following costs estimates in an effort to help DoD services and agencies develop rough orders of magnitude.
Ground and Airborne
Radar Systems: $2.02 - $8.52 per LOC
Communications
Processing Systems: $1.23 - $5.54 per LOC
C2 Planning
Systems: $1.22
- $1.84 per LOC
Logistics Support
Systems: $1.02
- $1.39 per LOC
MIS
Systems:
$0.75 - $1.70 per LOC
_____________________________________________________
Provided by Mr. Bob Molter, ASD/C3I
NOTE: Year 2000 "compliancy" includes proper processing of Leap Years [The Year 2000 is a Leap Year]
Application Software:
___ Size: Number of executable lines of code
(LOC)
___ Age: Older code tends to be less structured
and thus harder to understand
___ Complexity: Relative
intricateness/understandability of the business rules
___ Documentation: Degree of documentation
available and its understandability
___ Programmer: Familiarity with the program
code. Level of skill/competency/expertise
___ Source Code: Availability
___ Date- "Intensiveness": Relative
number of date related calculations/comparisons
___ Embedded Dates: Frequency of date use as
part of data element or in data element codes
___ Date Formats Used: Consistency within the
system of a standard date format
___ Year 2000 Strategy (Field
expansion/procedural code/sliding window): Different strategies
to achieve Year 2000 "compliancy" have different costs
___ Language: Some languages (e.g., COBOL 68)
are unable to properly process the Year 2000 so the software will
have to be upgraded/changed. Additionally, the language relates
to the availability of the Year 2000 COTS tools, programmers to
work on the system, and availability of Year 2000 compliant COTS]
Hardware/System Software: Year 2000 compliancy of each of the components of the technical environment is required. [Often only a current version of a product will be Year 2000 compliant.]
___ Operating System
___ Major Subsystems: Sometimes subsystems have
different technical environment components
___ Database Management System (DBMS)
___ Compilers/cross-assemblers (available --
sometimes they don’t exist)
___ Teleprocessing (TP) monitors
___ Homegrown/locally developed software that
is used in conjunction with the system
___ Workstation Software: Consider the quantity
needed
___ Workstation BIOS (handles the "system
clock function"): 60-80% of PC BIOSs are not Year 2000
compliant -- most are soldered to the motherboard, some are
reprogrammable, some are "socketed" and some can be
replaced
___ Programmer: Familiarity with the hardware
and operating system. Level of skill/competency/expertise
___ Programmer System Software (utilities and
development tools): To support making changes to the software
___ Capacity/Usage Level: Making a system Year
2000 compliant may increase storage (DASD) requirements or even
CPU requirements and cause a need to purchase a larger computer
or more DASD
___ Embedded Software (microchips/circuit
cards; e.g., PABXs, security system (access control), cash
registers): They may be directly or indirectly related to a
system, and may not be Year 2000 compliant. The availability of
compliant hardware or the cost of developing, and the quantity
required must be considered
___ Communications: Telecommunications hardware
and software upon which the system depends must be considered
___ Network Timestamps (LAN/WAN network clock
time): Upon which the system is dependent
Database/Files:
___ Number of date-related data elements
___ Amount of available DASD
Year 2000 Tool Support:
___ Availability: Many languages and/or
technical environments do not have Year 2000 COTS tools so tools
must be developed in-house or specifically contracted for
development
___ Quality
External Interfaces/Middleware:
___ Data Sources: Must be evaluated and
"bridges" planned as required
___ Data Outputs: Must be evaluated and
"bridges" planned as required
___ EDI Transaction Sets: System may generate
some EDI transactions or get input from EDI transactions which
require "bridges"
___ Reports: Systems may generate paper reports
which need to be modified
___ Screens: Systems may have screens used by
users which require modification
System Plans:
___ Planned Major Upgrade: May be used to do
Year 2000 compliance work at the same time to reduce costs
___ Termination: System may be eliminated
before a Year 2000 problem occurs
___ Replacement: System is planned for COTS
replacement or re-engineering before impacted by the Year 2000
Miscellaneous System-Related Information:
___ Sort Routine Year 2000 compliancy
___ Backup Routine Year 2000 compliancy
___ Archival Routine Year 2000 compliancy
___ System Criticality/Priority: Really not
required for cost estimate, but a good time to record this
critical planning information
___ Risk Analysis (if system fails): Really not
required for cost estimate, but a good time to record this
critical planning information. Consequences of system failure
must be considered
___ Risk Analysis (if system is not made Year
2000 compliant ): Many systems only have a small "window of
vulnerability" during which not being able to process Year
2000 properly occurs. Consideration must be given to whether or
not this "window" is acceptable; i.e., the system
won’t be used during that period, or a
"workaround" will be established for that period; e.g.,
manual processing.
___ Contingency and Continuity of Operations
Planning
Year 2000 Management:
___ Project Management
___ Configuration Management
___ Change Management
___ Contract(or) Management
___ Year 2000 Emergency Reaction Team
Year 2000 Testing:
___ Establishing Test Environment
___ Unit Testing
___ Integrated Testing
___ Year 2000 Simulation Testing: Can sometimes
require mirror of production environment. Might not be possible
until technical environment is made Year 2000 compliant.
Awareness Phase
Define the problem
Establish the project team
Obtain high level management support
Make a business case
Decide upon an overall approach
Make oral and written presentations
Publish articles in agency technical
newsletters
Prepare articles for corporate publications
Brief each application area
Identify technical and management representatives for each
department
Move beyond the IT community
Brief non systems departments
Determine exposures in infrastructure:
Access/environmental/elevators/security/fire
Define Terms (Glossary)
Establish compliance standards for new systems
Start preparation of project plan
Assessment Phase
Code Inventory
Develop methodology for conducting inventory
Select inventory team
Conduct inventory of
source code
Determine LOC
Identify languages
Collect survey information
Missing Source Code
Identify tasks related to missing
source code
Map source to executables
Prepare a list of no source modules
Determine which modules must be
re-created
Assign responsibility for
re-creating lost code
Rewrite needed missing modules
Identify source recovery vendor
Vendor software
Contractor maintained software
Pilots
Determine need for pilots
Conduct pilots
Submit pilot code to vendors for
comparison
Make decision on manual vs automated method
Make decision on in house resources vs
contractors
Identify technical issues requiring resolution
Form technical team
Screen input issues
Determine strategy for screen dates
(2 or 4 position)
Print and distribute decision paper
Forms
Form subgroup to handle issues
relating to forms
Resolve issues with pre-printed
forms
Resolve issues with
computer-generated forms
Estimating system cost for the year 2000
Survey available tools
Conduct procurement for tools and/or services
if necessary
Determine costs using survey results and
industry standards
Prepare master schedule for Renovation and Validation Phases
Conduct risk analysis
Prioritize systems for future phases
Make decisions on modification, re-engineering
and retirement of systems/programs
Decide on validation approach
Identify data exchanges handled by operations,
application areas, and non systems departments
Resolve date formats
Establish schedule for conversion
of data exchanges
Determine need for bridges/filters
Complete preparation of project plan
Renovation Phase
Implement standardized date routines
Re-Engineer selected systems/programs
Retire selected systems/programs
Determine strategy for code modification by
system (expand/algorithm/sliding scale/bridge)
Install and utilize selected year 2000 tools
Develop bridges/filters
Re-create missing source code
Change files and databases
Validation Phase
Create isolated future testing environment
Determine resources needed
Storage
Processing capacity
Resolve technical capacity
Determine how files will be aged
Volume testing vs individual case
testing
Establish validation databases
Coordinate future validation
efforts with ongoing development
Utilize existing tools
Regression test all changed sysetms
Future date test all changed systems
Implementation Phase
Schedule implementation of all changed
systems, vendor software and hardware
Make decision on parallel processing
Resolve data exchange issues
No Data Received
Bad Data Received
Consider use of hot sites for file conversion
Decide on handling of archive files
Develop backup/recovery plans
Project Management
Form Systems Project Team
Form Non-Systems Project Team
Conduct status meetings
Track progress to plan
Develop funding requirements and develop
strategies for funding
Brief senior management on status
BACK TO TOP OF PAGE