Chapter 19

Appendices

Appendix A: RadiMation^® Support Procedure

Definitions

Malfunctions are divided in nine categories and prioritized on their severity:

• 1 - Incorrect Measurement: RadiMation^® software produces incorrect measurement results.
• 2 - Issue with Data Loss: RadiMation^® software contains a problem that resulted in a situation that data is lost.
• 3 - Crash/Issue - No Data Loss: RadiMation^® is aborted during operation without any specific reason or another issue occurred. After a restart, no data is lost.
• 9 - Required device driver: A device driver for a measurement instrument must be created.
• 4 - Mandatory New Functionality: Functionality that is currently not implemented, but that is required to provide support for a new standard or measurement method.
• 5 - Unexpected Functionality: All other cases of malfunction of RadiMation^®, where the software functionality is responding differently than expected.
• 6 - Cosmetic: RadiMation^® software functions normal but the lay-out of the tables, graphs or screens are not represented in a proper way. For example when:
  • (Parts of) labels or information are not displayed.
  • (Parts of) labels or information are overwritten by other labels or other information.
  • The screen 'flashes' while writing graphs or other information.
  • The manual contains an error or unclear description.
• 7 - Questions: End-user has a question about the operation of the RadiMation^® software.
• 8 - Wish: RadiMation^® software is missing specific functionality which should be evaluated for possible implementation in the future. In this category, there is not a real problem however the end-user requests RadiMation^® to function in a different way or requests additional functionality. This can even mean that the actual situation is unworkable for the end-user. This case encompasses situations where certain functionality or part of tests is not supported.

Bug Reporting Procedure

The goal of the 'Bug Reporting Procedure' is to support customers as quick and effective as possible.

If you experience an issue with your RadiMation^® test software, or you simply have a request or question, please fill in the RadiMation Issue Report on the DARE!! website.

Your issue will be addressed as soon as possible.

Appendix B: Maintenance

The service of solving 'bugs' in the software is covered by the maintenance contract. Depending on the situation it might be necessary for an engineer from DARE!! Instruments to supply on-site support. These costs are covered as well, excluding travel and lodging. The service contract entitles the customer to all new push releases for the respective module(s).

Functionality improvements and/or changes to the respective software module(s) that are desired by the customer (and are assessed by DARE!! as functional and commonly applicable), will be implemented in a future release of the software. It is important to keep in mind that improvements and/or changes for one customer shoud not lead to disadvantages for other customers.

The RadiMation^® Support/Upgrade contract is mandatory and should be ordered with each RadiMation^® order.

• The minimum duration of this contract is 2 years.
• The first year is free of charge, each subsequent year costs 10% of the software order value.
• the starting date of the support/upgrade contract is the original delivery and/or installation date.
• If a customer does not accept a support/upgrade contact, DARE!! Instruments will not provide any software support/upgrade service.

Releases

Releases are divided in major and minor releases, indicated by a release number in the xx.yy.zz format. In this format, xx stands for the major release version and yy.zz for the minor release version.

Releases are shipped to the Reseller who is responsible for shipment and installation support at the customer.

Major release

A major release consists of any and all new functionalities and bug fixes since the previous minor release. As such the major release is a base line release.

As a rule Major releases are push releases and are automatically send to all customers with a support contract.

Minor release

A minor release consists of a specific new functionality or bug fix(es). Where yy is the new functionality and zz the bugfix(es).

As a rule Minor releases are pull releases and are send to the customer(s) with a support contract that needs or request the release.

Release Planning

There will be four main releases each year; two major/push releases and two minor/pull releases. Bug fix releases for specific customers are done in between.

The planning is as followed:

• 1st minor: The first Thursday after February 15h
• 1st major: The first Thursday after May 15th
• 2nd minor: The first Thursday after Augustus 15th
• 2nd major: The first Thursday after November 15th