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.

So Many Products, So Little Time

When you have many systems or products to evaluate and you don't have enough resources (staff, money, time, whatever), it becomes necessary to implement a prioritization scheme. Priorities (or risks) can be calculated as a weighted sum of a number of parameters:

where W_i is the weight attached to a particular characteristic (the i ^th one) and V_i is the value associated with that same characteristic; n is the number of characteristics. In the case of both weights and values, higher values lead to higher priorities.

The set of characteristics used in prioritizing a particular product or system will depend on the specific application. However, some candidate characteristics are described in the following list.

Mission: If more than one mission is supported at a particular facility or by a particular user, some are probably of greater importance than others. The mission supported by the product being ranked will contribute to its evaluation priority.

Mission Criticality: The importance of the product being ranked will also contribute to its priority. In this case, if the product is critical to the mission, it will rank higher than if it is of only incidental importance.

Product Type: Some types of products may be inherently more important to a particular organization than others. One set of product types that has been used in the past includes:

• Operating System
• Communications
• Database
• Engineering Support
• Operations Support
• Miscellaneous

Upgrade Path: If a product is easily or frequently updated (as is often the case with COTS products), the importance of quick evaluation may be lower than for a product that requires a long upgrade process (frequently the case for custom applications).

Life Cycle: If a system or product is to be retired before the Year 2000, it is unnecessary to evaluate for compliance. If the product is currently in development, its specifications can be altered to include Y2K compliance as a requirement and the evaluation and necessary renovation left to the developers (with the normal test and evaluation ensuring correct implementation). Products that are currently operational will likely require a more immediate evaluation so that, if necessary, a renovation and verification/validation effort can be initiated.

Compliance Status: This characteristic may seem redundant, but it only makes sense to include previous compliance evaluations as part of the current one. A product known to be non-compliant can, all other things being equal, be transferred to a renovation status. A product that is known to be compliant (and if that status is believed) requires no further activity. One whose status is unknown will require evaluation. The validity of the previous status should always be estimated and included in the prioritization.

Test Resources Required: The resources required will contribute to the priority of a product evaluation effort. Whether large resources raise the priority (because we should get started now) or lower it (the resources are better spent doing several products), will depend on the particular situation.

Pervasiveness: This characteristic is more commonly used for COTS products than for custom applications, but should be considered for all. The more copies of a particular product that exist, the more likely (a) some failure will occur and (b) someone will complain, even when the product is considered robust and the environment in which it operates is relatively benign. All other things being equal, a product that is used extensively should have a higher priority than one that is unique.

For each characteristic selected, whether from the above list or not, a range of values should be assigned and a weight selected before the ranking is done.