Difference between revisions of "Chapter 19"
(→Appendix C: Maintenance) |
(→Bug Reporting Procedure) |
||
| Line 21: | Line 21: | ||
===Bug Reporting Procedure=== | ===Bug Reporting Procedure=== | ||
| − | Goal of the Bug Reporting Procedure is to support customers as quick and effective as possible. By means of clear written down procedures, communication problems are prevented and the reseller and | + | Goal of the Bug Reporting Procedure is to support customers as quick and effective as possible. By means of clear written down procedures, communication problems are prevented and the reseller and DARE!! Instruments are informed at the most effective way. This enables an efficient and proper way to solve the problem. At the same time the number of contact instances between you as the customer at one side and the reseller and DARE!! Instruments at the other side can be kept to minimum. |
| − | The minimum information needed to file a bug report to | + | The minimum information needed to file a bug report to DARE!! Instruments in case of a malfunction is: |
# '''Type ''', Which of the categories mentioned above | # '''Type ''', Which of the categories mentioned above | ||
| Line 38: | Line 38: | ||
# Customer reports problem by use of problem report form at the Reseller; | # Customer reports problem by use of problem report form at the Reseller; | ||
# The Reseller registers the problem and records all required information; | # The Reseller registers the problem and records all required information; | ||
| − | # The Reseller communicates the problem by email or fax including the required information to | + | # The Reseller communicates the problem by email or fax including the required information to DARE!! Instruments; |
| − | # | + | # DARE!! Instruments informs the Reseller within one working day who will be responsible for solving the problem and in case DARE!! Instruments will be responsible also communicates a probable time to repair. |
# The Reseller informs the customer about the probable time to repair and who will be handling the problem from that moment on; | # The Reseller informs the customer about the probable time to repair and who will be handling the problem from that moment on; | ||
| − | # Every report is recorded at | + | # Every report is recorded at DARE!! Instruments and a unique problem number is generated. This number is a reference for this specific problem and should be used during all communications concerning this problem; |
# The party responsible for solving the problem will work on the problem till the problem is solved; | # The party responsible for solving the problem will work on the problem till the problem is solved; | ||
# The responsible party informs the customer about the solution of the problem; | # The responsible party informs the customer about the solution of the problem; | ||
Revision as of 07:15, 15 July 2014
Appendices
Appendix A: RadiMation® Support Procedure
Definitions
Malfunctions can be divided in the seven following categories:
- Incorrect Measurement: RadiMation® is performing a measurement (it is not crashing), but the measured or shown data is incorrect.
- Crash with data-loss: RadiMation® is aborted during operation without any specific reason. After a restart it is clear data is lost.
- Crash without data-loss: RadiMation® is aborted during operation without any specific reason. After a restart, no data is lost.
- Unexpected functionality: All other cases of malfunction of RadiMation®, where the software is doing something differently then expected.
- Cosmetic: All problem cases where RadiMation® in itself is functioning in a correct way although screens, tables and or graphs are not represented in a proper way. This category is used in for example the following cases:
- Labels or information do not appear totally or in part.
- Where labels or information are overwritten totally or in part by other labels or other information.
- The screen flashes while writing graphs or other information.
- An error or unclear description in the manual.
- Wish: In this case there in not a real problem however the customer requires RadiMation® to function in a different way or requires additional functionality. This can even mean the situation is unworkable for the customer. This case encompasses situations where certain functionality or part of tests is not supported.
- Questions: The type of problem is not a real problem but a situation where the customer does not understand the functioning of the software in part or total. Informing the customer about the proper use of the software can solve this kind of problems. Problems under category 1 to 5 may sometimes be solved by means of a work-around. At that time the problem is found to be solved and changes to the Questions category.
Among other things the prioritisation of the different problems is based on the category of the problem.
Bug Reporting Procedure
Goal of the Bug Reporting Procedure is to support customers as quick and effective as possible. By means of clear written down procedures, communication problems are prevented and the reseller and DARE!! Instruments are informed at the most effective way. This enables an efficient and proper way to solve the problem. At the same time the number of contact instances between you as the customer at one side and the reseller and DARE!! Instruments at the other side can be kept to minimum.
The minimum information needed to file a bug report to DARE!! Instruments in case of a malfunction is:
- Type , Which of the categories mentioned above
- Customer , Name, Address, City, Phone, fax (email) & contact person for this problem
- Configuration, Which test equipment is used when the problem occurs
- Type PC and OS, What kind of PC and which OS is used
- Which version, Which version of RadiMation® is used
- Which module, In which module or chapter the problem occurs
- Which test, During which test does the problem occur (settings)
- Reproduction , How can the problem be reproduced and can the reseller do this
- Additional information, All additional information that can help to solve the problem
The procedure is divided in the following steps:
- Customer reports problem by use of problem report form at the Reseller;
- The Reseller registers the problem and records all required information;
- The Reseller communicates the problem by email or fax including the required information to DARE!! Instruments;
- DARE!! Instruments informs the Reseller within one working day who will be responsible for solving the problem and in case DARE!! Instruments will be responsible also communicates a probable time to repair.
- The Reseller informs the customer about the probable time to repair and who will be handling the problem from that moment on;
- Every report is recorded at DARE!! Instruments and a unique problem number is generated. This number is a reference for this specific problem and should be used during all communications concerning this problem;
- The party responsible for solving the problem will work on the problem till the problem is solved;
- The responsible party informs the customer about the solution of the problem;
- The problem is closed.
Appendix B: Sample Problem Report Form
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
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 D.A.R.E!! 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 D.A.R.E!! 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, D.A.R.E!! 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
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
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
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
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
