| Microsoft Year 2000 Readiness Disclosure
& Resource Center |
|
|
|
| Preparing Office Solutions for the Year
2000 |
|
Year 2000
Compliance: A Definition and Roadmap
So if
you can't rely on the default behavior of desktop applications to
work in the Year 2000, how do you solve the problem? Although the
answer is simple, the implementation of the solution can be complex
and time-consuming. This section outlines a strategy for dealing
with the Year 2000 problem on a step by step basis.
How Does Microsoft Define Year 2000 Compliance?
Many
definitions for Year 2000 compliance exist and the interpretation of
compliance varies widely depending on the source. This paper uses
MicrosoftÆs definition Year 2000 compliance.
The term
"Year 2000 compliant"-as used in Microsoft materials concerning the
Year 2000, means that a product has all of the following internal
capabilities that allow it to handle dates within and between the
20th and 21st centuries:
- The product stores and calculates dates consistent with a
4-digit format throughout its operational range.
- If the product allows the user to enter a 2-digit short cut
for the year, the product recognizes the year consistent with a
4-digit year.
- The product will correctly execute leap year calculations.
- The product does not use special values for dates within its
operational range for data.
- The product will function into the 21st century, through the
end of the year 2035.
Note all references to "dates" refer
to using either 4 digits or 2 digits for the YEAR portion of the
date.
Saying
that the product "handles" dates correctly means that dates in the
21st century are calculated as occurring after dates in the 20th
century and that date calculations across the century boundary are
performed correctly for the purposes for which they were intended.
We
encourage customers to review all elements of their information
technology systems as a single system to determine any specific
issues you may face after the year 2000. Furthermore,
user-customizable features of a Year 2000 compliant product, such as
macros, custom programming and formatting features, may produce
results that do not comply with the criteria described above. In
addition, due to the lack of industry standards concerning the
import, export and exchange of date data among both the hardware,
firmware and software components of information systems, you may
experience results that do not comply with the criteria described
above. This definition of compliance does not constitute a warranty,
commitment or certification, expressed or implied, of any kind.
Your Definition of Year 2000 Compliance
Your
definition of Year 2000 compliance depends entirely on what your
application is supposed to do. If your application is mission
critical, Year 2000 compliance means that every area of your
application that deals with dates has been examined, tested and
certified as Year 2000 ready. On the other hand, if your desktop
application simply stores personal information that is not used
within an organization, or deals with no date data, Year 2000
compliance has a less rigorous meaning. In a nutshell, you should
strive for 100% compliance meaning that every aspect of your
application will function correctly when year data beyond 1999 is
used.
As you
go through the certification process, budget and time constraints
may force you to address only high-risk issues in your application.
The end result of such a process would not be 100% Year 2000
compliance, but the realities of life sometimes dictate a less than
perfect solution.
The Certification Process
To
ensure that your desktop application is Year 2000 compliant, follow
a process that allows you to accurately detect and fix all potential
issues. While the exact details of the process you use depend on
your budget and application complexity, this section outlines a
generic certification strategy that can help.
Step 1: Cataloging Objects
Before
you can identify risks and fix objects, you need a catalog of all
objects that make up the application. For example, in Microsoft
Excel solutions, include all workbooks, spreadsheets, and macro and
module code. Microsoft Access applications typically store all
program objects in one or more MDB files, but you still need to
consider library databases and ActiveX controls. Within these
objects, catalog each of the constituent parts. This information can
be kept in a variety of formats, including paper logs. Consider
using a database to manage the process, especially for complex
projects.
Step 2: Analyzing Objects
The next
step involves examining each object identified in the catalog for
possible Year 2000 issues. This can be the most time-consuming step
of the entire process because it requires a good understanding of
how dates work within your chosen environment, and how your
application itself is suppose to work.
Step 3: Assign A Risk
In this
step, you assign a risk to each object identified as having Year
2000 issues. The granularity of your risk categorization scheme
depends on the level of effort you plan for the certification
process. In general, three categories suffice:
- High Risk: The object identified will
absolutely cause the application to fail in the Year 2000.
- Medium Risk: The object identified may cause
the application to fail under certain circumstances.
- Low Risk: The issue identified may cause the
application to fail, but most likely not.
Step 4: Schedule Corrective Action Based on the Identified
Risk Level
Once you
have defined the risk level of each issue, you must prioritize what
needs to be fixed in what order. Common sense dictates that
high-risk issues are addressed first, but the dynamics of
application-object interaction and multi-member development teams
may make such strict coordination impossible. If your goal is 100%
compliance, then all risk issues need to be eliminated, so the
scheduling by risk becomes less important.
Step 5: Develop Corrective Action for the Issue
For each
issue detected, you need to develop a corrective action. In some
cases, this may be as simple as changing the InputMask on an Access
form, or changing the format of a date displayed in a spreadsheet.
In other cases, major data restructuring or complete overhauls of
large amounts of procedural code may be needed.
Step 6: Apply the Correction and Test the Results
Once the
corrective action has been determined, apply it to the object and
test the results. Test by using dates in both the 20th and 21st
century, and if necessary, with the computer's system clock set in
each century.
Step 7: Certify the Object as Year 2000 Compliant
Once the
test has passed, certify that the object is Year 2000 compliant. Do
this by updating the catalog your created in the first step to
record the fact that object has been examined, fixed, and tested. It
is also a good idea to record details about:
- What corrective action was taken.
- The names of the developers who fixed and tested the object.
- The date the object was tested and certified.
Step 8: Test the Entire Application
This
step ensures that corrective actions applied to individual objects
do not destabilize the application as a whole. The level of testing
required in this step correlates directly with the number of
corrective actions that were applied in the previous steps. In other
words, if only one issue was detected and fixed in an entire
application, the testing carried out in this step could be less
rigorous than an application that had 1000 issues detected and
fixed.
Step 9: Certify the Application as Being Year 2000 Compliant
Once all
previous steps have been completed, and no issues have been left
uncorrected, and all testing indicates that the corrective actions
work, you can certify that your application is Year 2000 compliant.
Note
that the use of terms like "compliant" may involve legal issues and
guarantees that you are not willing to make. In general, software is
never licensed with any type of warranty. If you are working in a
commercial or licensed environment, consult the proper legal sources
before making any claims about your software.
|
