Addressing Year 2000 Implications
Testing Methodologies and Guidelines
Tackling Embedded Systems
conclusions and recommendations

 

SESSION 5: WORKING GROUPS SESSION

The workshop rapporteur, Tim Eyre, ran this session. The output from the group work was used as an input to the conclusions and recommendations in Session 6 (see below).

 

SESSION 6: TACKLING THE PROBLEM

Addressing Year 2000 Implications: Best Practice Approach, Michael Ganado, Management Consultant, PricewaterhouseCoopers (PwC

Michael Ganado began his talk by scoping out the main steps needed to develop best practice.

Firstly, clarify the objectives and:

Determine the initial scope of the problem;

Assess the potential business impact;

Secure organisational support;

Identify critical projects;

Determine high-level programme estimates;

And mobilise the full programme.

Secondly, identify the issues and:

Define and control the scope;

Decide on the method of assessment;

Estimate the process;

Plan the resource;

Choose the tools and their use;

Institute financial control;

Manage the relationship with external organisations;

Manage the value-added opportunities;

And encompass the legal issues.

In the assessment take a detailed inventory and really establish which systems are affected both within the IT domain and outside.

In defining compliance re-run every likely date, contact suppliers, use code analysis, and assess the risk/costs of misjudgement or overlooking systems.

In determining solutions Mr Zammit said it was useful to draw up the matrix of compliant/non-compliant systems against planned replacement, planned re-working and no replacement but, most important, it was necessary to focus on realistic estimates for timescales, financial and human resource requirements, and the risks involved and the likely quality impairment if these are not met.

 

Testing Methodologies and Guidelines, Joseph Zammit, Year 2000 Project Manager, MITTS

Joseph Zammit opened his presentation by restating the Y2K problem and the likely dates that may result in misinterpretation and malfunction, and then went into some detail on the testing methodology for both software and hardware infrastructure.

Under software, he included office automation packages using dates, application software, and software development tools and operating systems. The software testing methodology comprised a Year 2000 compliance test, a benchmark test, a post-fix Y2K test, and a user acceptance test.

Under hardware infrastructure, he included PCs, servers, communications equipment, and peripherals such as printers, uninterruptable power supplies and tape streamers etc. The hardware testing tools performed DOS real time transition, manual transition, and automatic transition and leap year transition tests. For the embedded control systems, which were the most difficult to find, the testing tools included PC testing tools, test data creation tools, test execution tools, system date simulators and test management tools.

Mr Zammit closed by saying that the main concerns were with the embedded control systems where the users may be unable to test and may not even have a date-interface; in addition, compliance may depend on the supplier's certification and some suppliers may not still be in existence.

 

Tackling Embedded Systems and their Suppliers, Richard Wilson, BT Laboratories

Richard Wilson built on his previous presentation by pointing out the various stages in moving to a solution of the problem - assessing the inventory, identifying the embedded systems, assessing the risk, contacting suppliers, and undertaking testing and validation.

He went into some detail on the inventory database and said it was often important to walk the floor with a "local" engineer, who knew where everything was located. He said that it was also important to methodically identify, tag and record all embedded systems for future examination.

Under risk assessment all the "what if" questions should be asked such as:

What would happen to this part of the business if this piece of equipment fails?

Does the unit connect to safety critical equipment?

Is it just a minor convenience if the date fails and can it be wound back?

Is the unit to be replaced/upgraded under a normal maintenance cycle?

Can the original supplier provide compliance data?

Richard's guidelines were that all units should be considered at risk until proved otherwise.

Mr Wilson finished his presentation on a realistic, if slightly pessimistic, note that no one testing procedure will cover everything as every embedded system is different. In testing use every generic date possible and document what tests have been performed. Some software can scan for the code for date calls and some hardware can "sniff out" timing/date hardware. To return to a previous presentation and analogy, he said that with a well documented methodology and thorough testing and validation, there would be many lifeboats available and few would be drowned.

 

Presentation of conclusions and recommendations, Tim Eyre, Workshop Rapporteur, CTO

Following on from the group work and presentations in Session 5, Tim Eyre, with the help of the delegates, drew up a statement of conclusions from the workshop which served as input to a document presented at the Commonwealth Finance Ministers' Meeting held in Ottawa, Canada, later in September.

The document is appended.

The meeting closed with a vote of thanks by the delegates to COMNET-IT, the Commonwealth Secretariat and the CTO, and for the professional input of MITTS.