Chapter 19: Difference between revisions
Line 20: | Line 20: | ||
===Bug Reporting Procedure=== | ===Bug Reporting Procedure=== | ||
The goal of the Bug Reporting Procedure is to support customers as quick and effective as possible | 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 [http://www.dare.eu/instruments/emc-test-software/radimation-issue-report?|'''RadiMation Issue Report'''] on the DARE!! website. | |||
Your issue will be addressed as soon as possible. | |||
==Appendix B: Sample Problem Report Form== | ==Appendix B: Sample Problem Report Form== |
Revision as of 13:08, 27 October 2015
Appendices[edit]
Appendix A: RadiMation® Support Procedure[edit]
Definitions[edit]
Malfunctions are divided in eight categories and prioritized on their severity:
- Incorrect Measurement: RadiMation® is performing a measurement (and it is not crashing), but the measured or shown data is incorrect.
- Issue with Data Loss: Data has been lost due to a problem in RadiMation®.
- Crash/Issue - No Data Loss: RadiMation® has aborted during operation (for no specific reason or known issue). After a restart, no data was lost.
- Mandatory New Functionality: RadiMation® requires a functionality - that is currently not (completely) supported or implemented - to support a new standard or measurement. This includes the development of new device drivers.
- Unexpected Functionality: Other possible cases of malfunction where the RadiMation® software is doing something differently then expected.
- Cosmetic: Possible cosmetic malfunctions where RadiMation® 'in itself' is functioning correctly but the visual representation (in the form of screens, tables and or graphs) is not. 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.
- Questions: An issue is not caused by a malfunction of RadiMation®, but by the user's knowledge of RadiMation®. A situation where the customer does not understand (part of) the functioning of RadiMation® can be solved by informing the customer about the proper use of the software.
- Wish: There is no software malfunction or knowlegde issue. However the customer wishes (or even requires) RadiMation® to function in a different way, or contain additional functionalities, to support their use of the software. This can even mean the situation is unworkable for the customer, for example in situations where a certain functionality or part of a test is not supported.
Bug Reporting Procedure[edit]
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: Sample Problem Report Form[edit]
Please find below a sample problem report form. Use this template to report your problems, wishes or questions. You can sent a fully completed form by email to your local reseller or print it and sent it by fax or regular mail.
| ||||||||||||
| ||||||||||||
| ||||||||||||
|
Appendix C: Maintenance[edit]
Under the maintenance contract "bugs" in the software will be solved. As the compositions of the used equipment will be different at each customer it may be necessary for the 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 of the respective software module which are desired by the customer and which are assessed by DARE!! as functional and commonly applicable, will be implemented in a future release of the software. It is important to bear in mind that improvements and/or changes for one customer may not lead to disadvantages for other customers.
RadiMation Support/Upgrade contract is mandatory and should be ordered with each RadiMation® order. Minimum duration of contract is 2 years. First year is free of charge, second and each subsequent years costs is 10% of the software order value. In case customer has/orders no support/upgrade contact, DARE!! Instruments will not provide any software support/upgrade service Starting date of the support/upgrade contract is the original delivery and/or installation date.
Example: A customer purchase RadiMation® on 2007 April 1st. Based on this purchase he automatically has a service contract till 2008 March 31st. If he decides not to continue the service contract at this time and he wishes to do so in 2010 he will be charged two times 10% plus 10% for the year 2010. Effectively this is an additional 10% compared with the situation in which he would have continued the service contract.
Releases[edit]
Releases are subdivided in major and minor releases indicated by a release number in the format xx.yy.zz where xx is the major release version and yy.zz is the minor release version. Releases are shipped to the Reseller who is responsible for shipment and installation support at the customer.
Major release[edit]
A major release comprises new functionality and all fixes of bugs and problems of the previous minor release. As such the major release is a base line release. As a rule Major releases are push releases e.g. are automatically send to all customers under a support contract.
Minor release[edit]
A minor release comprises a remedy to a specific bug or problem. Where yy is new functionality and zz are bugfixes. As a rule Minor releases are pull releases e.g. are to a customers under a support contract that needs or requests the release.
Release Planning[edit]
There will be four main releases each year. Two of these will be push or so called major releases two of them will be pull or so called minor releases. In between there will be bug fix releases for specific customers.
The scheme will be as follows:
Minor 1: The first Thursday after February 15h
Major 1: The first Thursday after May 15th
Minor 2: The first Thursday after Augustus 15th
Major 2: The first Thursday after November 15th