Y2K Site Map | Terms of Use | Problem | Steps | Certification | Briefings | Compliance | Solutions | BIOS | Test & Evaluation | Cost
The following Y2K material has been kept available by MITRE for historical purposes only and has not been updated unless noted.
![]() | How to Evaluate a Product |
The following two questions need to be answered before a product can be evaluated:
The typical system is composed of many components. If you're lucky and have a well-architected system, as shown below, you may be able to identify all the components between an application and the computer
If you can identify all the components, then you can make some logical choices about how much of the system you are going to evaluate, and, more importantly, you can determine those components whose compliance status you will leave to others.
If your system isn't so cleanly designed, or, worse, if you don't know how it is designed, then you'll have to do some analysis to determine exactly what parts of it you are going to evaluate. In any case, you'll want to include a complete system test (treating the system as a black box) as part of the evaluation. This is particularly important in the case where the design cannot be cleanly determined.
COTS products that are included as part of the system must be evaluated separately and the resulting compliance status factored into the system compliance. The MITRE/DISA COTS Compliance Catalog can be used as a starting point for this evaluation, or if you're working in a PC environment, you can begin with a determination of the Y2K compliance of your computers' clock and BIOS.
What Does It Do?In determining what a product does, it is not sufficient to examine only requirements specifications. One must also look to user expectations (what does the user think the product does or will do?) and to the users' methods of operation (how does she/he use the product?).
If the system being evaluated utilizes a COTS operating system or other COTS component that maintains the date and time, the Y2K transition might cause one or all of them to fail -- and, hence the system to fail, even though the system's function is totally date independent.
| Test & Eval | Testing Basics | Renovation Strategies | Product Evaluation | Critical Dates |
| Resource Allocation | Interface Management | Interface Agreements | Interface Status | Confidence Assessment |
Information is provided by the MITRE Y2K Team Last modified: Thursday, 14-Feb-2008 09:21:03 EST
|