To Download our full Service Level Agreement, please click the link below to download our PDF.
tmWare Service Level Agreement
Interpretation
Acceptable Use Of Notifications: the number of notifications will be monitored over a period of time, system issues will be excluded from this review. Excessive utilisation may incur additional fees.
Agreement: the provision of a service in exchange for a monetary fee.
Application: the standard web based management software system application produced by Tmware.
Company: Tmware Limited (registered number 1803258) whose registered office is One Pebble Close Business Village, Amington, Tamworth, B77 4RD
Customer: the customer who has entered into this agreement.
Customer Revision: a change to the specified system requested by the Customer.
Bug: a function or process in the software that does not perform to specification.
Database: the part of the system that is the repository for the information.
Inconvenience or Query: the system is not performing to the Customer’s need but is not preventing the Customer from using the system.
Issue(s): an Issue arising in connection with the System which falls within one or more of the Priority Categories.
Key User: representatives of the Customer who have received Training and who has in-depth knowledge of the operation of the System.
New version: a changed set of all or part of the system.
Normal Working Hours: the hours 9:00 am to 5.30 pm GMT, Monday to Friday, except English Bank Holidays.
Notification: a request for technical assistance on the Tmware software system application.
Operating System: means the software that acts as the interface to the hardware.
Patch: an amendment to an existing item of software to rectify a fault.
Priority Categories: Priority 1 Issue, Priority 2 Issue, Priority 3 Issue and Priority 4 Issue.
Priority 1 Issue: an error in the System (or part thereof) that causes it to completely fail to operate for use by the Business and is such that there are no manual processes that can be implemented in the interim.
Priority 2 Issue: an error in the System (or part thereof) that causes a serious impact on its operation but the Customer is able to implement manual processes in the interim.
Priority 3 Issue: all other matters or Issue not classed as a Priority 1 Issue, Priority 2 Issue or a Priority 4 Issue.
Priority 4 Issue: a low priority circumstance or issue with the System (or part thereof) which the Customer wishes to raise with Tmware and which does not affect the operation of the System (or part thereof).
Priority Level: categorisation by Tmware as to which of the Priority Categories the Issue falls within.
Reference Number: a unique number allocated to each notification.
Recovery: assistance by Tmware to prevent and recover from the complete loss of the servers or of Tmware through disaster recovery.
Services: the services to be provided by Tmware under this agreement, including the provision of the System, the Support Services, any agreed Training and any data migration referred to in the Customer Specification.
Service Fee: the service fee as specified in the Proposal for the Standard Support, the Licence and where applicable any relevant Transaction Charges.
Specification: detailed description covering all aspects of a requirement and what it should do.
Support Desk: the repository for managing support notifications.
Support Team: suitably trained technicians with an understanding of the Tmware software system application.
System Administrator: a key user who has received in depth training and understands the system and operation of the customer and will collect and channel communication between Customer and Company.
Working Day: any day which is not a Saturday, a Sunday, a bank holiday or a public holiday in the UK.
Introduction
This Service Agreement is between the Customer and Tmware for the provision of the services contained herein.
The provision of services defined within this agreement may be subcontracted to a third party, although the responsibility for the service will remain with Tmware.
The Service will be provided in return for the Service Fee.
Tmware shall use reasonable endeavours to correct Issues notified to it by the Customer in a timely manner appropriate to the Priority Level.
Duration
This Support Service will remain valid for the duration of the contracts between all parties concerned unless superseded by a revised Support Service Agreement, mutually endorsed by authorised signatories.
The Support Service will terminate in conjunction with contract termination or breach of contract.
Change Control
Changes to the agreement, in respect of existing services, must be notified in advance and agreed by Tmware and the Customer.
Any changes will result in a revised Support Service, incorporating the changes, being produced and being signed by all parties.
Version control of the Support Service Agreement will be maintained at all times.
Additions to the Support Service, as a result of new services, will follow the same procedure for changes to existing services.
At least 30 days notice is required for such additions or amendments, unless agreed otherwise by all the parties concerned.
Temporary changes to the Support Service will be a document agreed by all concerned parties, subject to a suitable period of notice being given.
Customer Obligations
Up to date payment for the service.
Appropriate information relating to the support request.
Reasonable commitment from the Customer in relation to the support request.
Maintain good communication with Tmware.
Minimum Client Specification
To enable connection to the tmWare system there is a minimum requirement
- Hardware with 4 GB Ram
- Resolution 1376 x 768
- Bandwidth recommended 8 MB
Browser Recommendation
Recommended browser is Firefox or Chrome.
Internet Explorer may not comply with the W3 standards and browser version running on different Operating Systems (eg Windows 8 and 10) will behave differently and therefore inherently a difficult browser to support.
Tmware will always endeavour to ensure compatibility with browsers and associated plugins supported by their supplier. However, it has to be accepted that as new versions are released, any bugs found in the browsers are outside of Tmware’s control and can only be responded to piecemeal.
For this reason, it is recommended that automated updates are turned off.
Tmware will endeavour to turnaround a fix within a reasonable timescale.
Mobile Device Specification
Tmware has made best endeavours to enable performance of the application.
The specification will be to the agreed platform evaluated by Tmware. Any Customer specific reported observations and risks will have been identified to the customer and will be shown separately in an addendum at the end of this agreement.
The Customer will be responsible for active SIM/Memory cards and any accounts linked to the device for application download / upgrade.
Automated System Update
It is recommended that automated operating system updates are turned off. These may affect the software application.
Where this has taken place Tmware will endeavour to turnaround a fix within a reasonable timescale.
Tmware will not be held responsible where system updates have been made and are causing an application problem unless prior consultancy has taken place.
Memory/SD Cards
The Customer is responsible for supply and frequency of replacement.
It is recommended that branded cards are procured from reputable suppliers.
Bar Code Reader Set-Up
The customer is responsible for the set-up of the barcode reader. Barcode reading from device 1 to 8 must be enabled.
To insert characters at the end of the barcode carriage, return must be inserted as a suffix.
Appropriate/Authorised Terms of Use
The Customer shall be responsible for any content, information or images or documentation that it uploads to the System.
Passwords
Recommended secure passwords consist of at least 8 characters with a mix of upper and lower case, !?* and numerics.
User Permission Level
User level- A unique access pin code is created which is an authorisation code which authorises the workstation to be connected to the system.
Password – It is the Customer responsibility to create a secure password and change this at desired frequencies.
Confidentiality Policy
All Company team members have signed Tmware Company Confidentiality and Non Disclosure Agreement.
New Change Requirement
Detailed specification will be approved by the Customer and Tmware.
Once a release is authorised as accepted by the Customer there is no liability by Tmware to make ongoing changes. This will be deemed as a new change requirement and will require a detailed specification of required changes.
A new requirement without a documented specification will not be accepted by Tmware.
Release of the new development will fall under the standard support and maintenance service.
Increase in Users
Where the system contract is based upon user numbers these will be monitored on an average monthly user basis and additional fees notified as appropriate.
Any notification of additional users not required will be adjusted on the next invoice release.
New Change Requirement Fees
Company quotes are prepared taking into account the cost of time, complexity and expertise required to complete the job as a whole including all testing, user acceptance fallout and release notes. It has been found not to be commercially viable to the Customer to apply a ‘time and materials’ approach to Tmware’s style of working.
When Tmware quote for a job it has clearly defined parameters as set out in the agreed technical specification with regards to time frame, resource and tasks. It is felt that this allows customers to know exactly what they are getting and for how much. This method make the most sense for jobs involving creative or intellectual property.
Preferential bundle rates can be applied to to several new change requirements or bundles purchased in advance.
Training
Tmware are happy to discuss additional training requirements in depth and work with the Customer to produce a comprehensive training plan. At initial system implementation Tmware will have carried out Key User training. In turn the Key User will have carried out training with other Customer users. Continuation of of this approach will enable knowledge retention within the Customer operation.
Additional training requirements shall be quoted as required.
The Customer Services Agreement provides the following included services:
- Tmware application support and maintenance within the specification and scope of the system purchased.
- Standard Support Service, within an acceptable volume of support requests, during Normal Working days.
- Out of Hours Support Service, when contracted.
- Software upgrades, excluding set up.
- Disaster Recovery
Excluded Services:
- Customer Hardware or Hardware Maintenance
- Customer Printers and Printer Drivers
- Third Party PDF Viewers
- Customer written reports
- Notifications, in excess of an acceptable volume of support requests
- Any works outside of the scope of the agreed services as set out in the proposal
- Customer written reports
- Costs of new development
- Unapproved operating system for mobile devices
- Unapproved browser updates
- Unapproved plug-ins that may affect the software application
- The Customer’s Network
- Visits to the Customer site
- Corporate fonts
- Bar Code fonts
- Pictures
- Logos
Upload of in-appropriate material
Issues arising due to the Customer changing one or more of: EDI, a pre-defined specification, change to file format, change of key static data in live, performing a task out of process.
Standard Service
This service is available Monday to Friday 9am to 5.30 pm GMT except UK bank holidays.
Support requests are monitored during these times on Normal Working days. Support requests placed after 4.30 GMT may roll over to the next working day unless identified as Priority 1.
Tmware will notify the Customer when there is a New Release.
For the avoidance of doubt, nothing in this agreement shall oblige the Customer to take any New Release.
Upgrades will be carried out by agreement with the Customer and Company.
Tmware shall not supply the Excluded Services.
Tmware shall ensure that Standard Support is available by telephone or e-mail during Normal Working Hours to provide assistance to the Customer in respect of addressing any Issues and providing advice on the use of the system which would be classed as a Priority 4 Issue.
Tmware shall use reasonable endeavours to correct Issues notified to it by the Customer in a timely manner appropriate to the Priority Category.
Standard Support Desk Process for placing a Support Request
The Customer shall first ensure that a Key User is notified of the Issue to see if the Issue can be resolved internally.
The Key User shall having assessed the nature of the Issue promptly send to Tmware a Notification via the Support Email or the Support Contact Number and shall supply full details so far as possible as to the nature of the Issue.
Where the Customer utilises their own central help desk facility communications shall take place through this.
To enable timely investigation to take place as much information as possible should be presented with the support request.
Insufficient information to enable investigation to commence may result in a support request not being accepted.
Where the Notification is made using the Support Contact Number Tmware will log it on to the system and issue a Reference Number by email.
If an Issue has been notified via the Support Email Tmware will issue a Reference Number by return email within 15 minutes. If this is not the case the Customer shall contact Tmware by telephone using the Support Contact Number.
Support Notification by email – supportdesk@tmware.com
Emails to supportdesk@tmware.com will auto generate a response confirming the ticket reference and will automatically placed in a queue system.
The reference number is a very important part of the system and should always be noted and quoted with any communication relating to the request.
Emails to an address other than su*********@tm****.com do not automatically join the Notification queue. They are not constantly monitored resulting in a delay in the support request being passed through to the database, thus increasing response times.
Support Telephone Contact 01827 304123
Telephone support requests are manually logged onto the database to join the queue system, an automated email response will confirm the ticket reference.
The Reference Number must be quoted by the Customer in any communication regarding the Notification.
All Notifications are placed in a support queue.
Within two hours of the Notification Tmware shall allocate a Priority Level to the Notification but if the Customer is of the view that the Notification falls within Priority 1 Issue or Priority 2 Issue this must be communicated as part of the Notification and must be followed up by a call to the Support Contact Number by the Customer to notify us of this Priority Level.
If the Priority Level is a Priority 1 Issue the Tmware support team will contact the customer within 15 minutes of the Reference Number being issued to confirm the Priority Level.
If a Priority 1 Issue relates to an issue with access to the System the support team will use all reasonable efforts to rectify the Issue within 1 hour. If the Issue is not rectified within that time period then with the Customer’s consent Tmware will look to consider secondary server options and Tmware will use all reasonable endeavours to return to the Customer’s main servers as soon as is reasonably possible.
If the Priority Level is a Priority 2 Issue the Tmware support team will contact the customer within 30 minutes of the Reference Number being issued.
If the Priority Level is Priority Issue 1 or Priority Issue 2 Tmware shall use all reasonable endeavours to resolve the Issue as soon as reasonably possible having regard to the complexity of the problem and shall keep the Customer informed of progress towards correction of the Issue .
If the Priority Level is a Priority 3 Issue the Tmware support team will contact the customer within 4 hours of the Reference Number being issued and Tmware will use reasonable endeavours to resolve the Issue within 1 Working Day.
If the Priority Level is a Priority 4 Issue the Tmware support team will contact the customer within 1 Working Day of the Reference Number being issued and Tmware will use reasonable endeavours to resolve the Issue within 7 Working Days.
Tmware shall use reasonable efforts to ensure the accurate migration of any data, but gives no warranties as to the completeness or accuracy of such migration. The Customer shall be responsible for checking the accuracy and completeness of the migrated data and shall promptly give sufficient details to Tmware of any inaccuracies or omissions in order to permit Tmware to correct them. If such data includes Personal Data, Tmware shall return all copies of such Personal Data to the Customer on completion of the data migration process.
Tmware reserves the right to allocate and reallocate the Priority Levels as they see fit.
Notifications will be dealt in in order of the Priority Level and for Notifications falling within the same Priority Level in the order in which they are notified.
Tmware may use various methods to resolve the Issue which in its opinion is deemed appropriate. Such methods may require the involvement and availability of the Key User and the Customer shall ensure full cooperation in this regard.
Except in respect of Out of Hours Support, Notifications received after 4:30pm may not be dealt with until the next Working Day.
Priority 1 to 3 logged prior to 4.30 pm GMT will have one of the following actions taken before the end of the Working Day:
- Completed.
- Carried over to the next Working Day
- Further investigation required
- Awaiting further information from the customer
- Unable to replicate problem, Monitor status
- Unable to reach the customer contact, therefore, unable to progress the call further until the next day
Response Times
The initial response time to a support requests is dependant upon its Priority, exceptions would be an unusually high number of support requests received or an extreme high priority support request.
The response times given serve as guidelines and bear no monetary penalty.
Resolution Times
Outstanding support requests, are reviewed throughout the day.
Tmware shall endeavour to resolve problems as swiftly as possible. It recognises that the Customer’s operation is key to its business.
However, Tmware is unable to provide guaranteed resolution times. This is because the nature and causes of problems can vary enormously.
In all cases Tmware will make its best efforts to resolve problems as quickly as possible. It will also provide progress status updates.
Tmware has chosen preferred third party suppliers based upon their ability and track record in order to provide a good quality service.
Call Progression
The requests are monitored by their age and status.
It is the responsibility of the Support Desk to progress the call through the stages to completion.
New – Initial status assigned for visibility on the Call Logging System.
In Progress – The request is being actioned.
Awaiting Response – Additional information may be required from the Customer to replicate the problem or information to assist with further investigation. It is the Customer responsibility to respond with information to assist.
Unless the Customer responds to the ticket within a reasonable time the ticket will be closed.
The ticket may be re-opened at any time by responding with the ticket reference in the subject line.
Monitor – Where a problem is investigated but no reason is apparent for the problem and it cannot be replicated either at Tmware’s site or at the Customer’s site (e.g. an intermittent fault) the call is assigned a monitor status and if the problem is not reported again after a period of 30 days the request will be closed.
Replied to – Customer has provided further information to help with the progress of a ticket.
Re-opened – Customer has responded to a ticket that was previously closed.
Closed – When the request is resolved the Customer is informed.
Fix on fail or patch will be applied to enable users to continue using the system.
Root cause and bug fix will be passed for further investigation.
Workarounds applied to the system pending full resolution will be recorded and monitored until a resolution is applied.
No requests to be outstanding longer than 7 days unless passed to monitor, further investigation required, awaiting further information from the Customer or a query, suggested enhancement or change request.
New change requirements, system enhancements and queries will be routed through to the Tmware Project Team or by direct contact to pr*****@tm****.com
Fixes and Workarounds
Workarounds applied to the system pending full resolution will be recorded and monitored until a resolution is applied.
Enhancements
Tasks categorised as a future enhancement will either be assessed when a new software released version is being reviewed or if it cannot wait it will be deemed a chargeable change request.
Customer Visibility of Notification Status
Access to the Support Desk portal, by login and password, is available to Customers who wish to view their ticket status at any time.
Support Request Reporting
The report displays a pie chart of support requests during a given date range by number and type. This is then further broken down into closing details.
Report frequency is available weekly or monthly.
Reports will be set to be automatically emailed to the desired frequency and recipient group.
Acceptable Utilisation of Notifications
Utilisation will be monitored over a period of time. Unacceptable utilisation will be subject to a review meeting to discuss any trends or training requirements. System software issues will be excluded from this review. Persistent user error may be subject to additional fees.
Escalation Process
At all times, best endeavours are made to resolve a problem in a timely manner. However, there are certain issues that are not easily identifiable and this may cause concern to the user if a status update is not given in a timely manner.
In the first instance the Notification shall able escalated to the support desk administrator giving the reason for escalation. This may be that the problem has become more urgent or that an unreasonable amount of time has lapsed to fix the issue. Upon meeting acceptable criteria, for example all meaningful information has been received to determine the actual issue, priority classification and time duration, the ticket will be allocated a higher priority.
This will be noted in the ticket and an additional specialist will become involved in fixing the problem.
If the response time to this escalation is still not acceptable then a further escalation shall be made giving the reasons for the escalation.
The Senior Technical Support, or nominee, will respond giving a further update and explanation of any difficulties that are being encountered whilst the problem is in progress and an expected time of completion.
Where it is felt there is reason for complaint then a formal complaint should be communicated to the Project Team.
The incident will be investigated and a formal response given within 7 days.
Recording of Phone Calls
As part of our ongoing process improvement, telephone calls are recorded for the purpose of;
- to provide evidence of a business transaction,
- to ensure the business complies with regulatory procedures,
- to see that quality standards or targets are being met.
Out of Hours Support Support Services
This service is available by contract only
If the Customer has selected Out of Hours Support the following shall apply:
Out of Hours Support is accessible during Out of Hours.
Out of Hours Support shall only be used in connection with a Priority 1 Issue.
Tmware reserves the right to charge additional Service Fees in the event the Customer uses the Out of Hours Support for other Priority Levels other than a Priority 1 Issue.
The Customer shall be issued the Out of Hours Number.
The Customer shall only use the Out of Hours Number if the Out of Hours Support is selected and only in the event that such support is needed.
The Normal Hours Support Contact Number and the Support Email should not be used as they are not monitored during Out of Hours;
The Customer shall first ensure that a Key User is notified of the Issue to assess the urgency and see if the problem can be resolved internally before using Out of Hours Support.
A Key User shall having assessed the nature of the Issue contact Tmware via the Out of Hours Number and shall provide to the operator their contact details, Key User details, their contact number and a brief description of the Issue.
Following receipt of a Notification as above, the operator will page or otherwise contact a member of the on duty Support Staff.
The on duty Support Staff will then within 1 hour contact the Customer and may request further details of the Issue.
Tmware shall use reasonable endeavours to correct Issues notified to it by the Customer in a timely manner appropriate to the Priority Level.
Tmware may use various methods to resolve the Issue which in its opinion is deemed appropriate. Such methods may require the involvement and availability of the Key User and the Customer shall ensure full cooperation in this regard.
Online monitoring of the progress of a Notification will not be available until the next Working Day.
The Customer acknowledges that response times for the Support Services will be affected if:
- the Customer fails to comply with their obligations
- if the Issue has arisen due to an act or omission of the Customer as opposed to a problem with the System itself
- if monitoring is required to establish the nature of the Issue
- if Tmware is awaiting further information from the Customer
- the Customer fails to use the out of hours Contact Number provided.
Disaster Recovery
Data held on Tmware servers is mirrored in real time to servers in a different location.
Data backup is instant, however, some data may be lost.
It is the Customer responsibility to check any transaction performed immediately prior to server failure.
Where the Priority 1 Issue relates to an issue with access to the system Tmware, with the Customer’s agreement, will move to a secondary server.
The Customer will be issued with a new URL to connect to the System and will need to change their IP address for FTP EDI uploads.
The main server will be returned to as soon as is reasonably possible and with agreement by the Customer.
Preparatory Actions to bring the back up server on line to become the primary server.
The Customer will have pre-identifed their IT provider.
The customer will have identified FTP connections.
Agreement confirmed between the Customer and Tmware to move to the backup server.
Tmware shall initiate a script to start the processes on the backup server.
Confirmation to the Customer that the backup server is in place to become the new primary server.
Actions for users when the backup server becomes the new primary server.
System users shall log out.
Any FTP users will need to re-direct their FTP connection to a new IP with their user name and password credentials.
Users shall check last actions have completed, prior to server failure, before continuing.
Original Primary Server Fixed and ready the reason for escalation. This may b to bring on line.
The Customer and Tmware shall agree the move date and time.
System users shall log out at the agreed time.
Tmware shall confirm that users can log back in using their normal URL. Usually after a period of 5 minutes.
FTP users shall revert their connection to the primary IP address.
Tmware shall stop processes on the backup server.
Project Team Services
email pr*****@tm****.com
Telephone contact 01827 304100
The project team facilitate and track new development changes from initial enquiry through to end delivery.
For example detailed specifications, commercial quotations and status updates.
In the case of new requirements this will include detailed specification, quotations where applicable, scheduling resources to carry out the work, communicating status updates, resourcing testing and final release to live and sign off.
The Project Team shall maintain good communication with the customer.
One of the team will log and progress requests directed to the project team. This prevents ad-hoc conversations and requests directed to individuals being overlooked.
Forward notification of Customer new or up and coming projects can be planned in advance. The Customer may have reviewed what is required and then this will be further discussed with the Tmware team.
Where further investigation relating to a Notification placed with the Support Desk is required the project team will take responsibility of this task and manage it through to resolve.
A summary of task or project status report can be provided as required.
New Change Development tasks are allocated a unique reference number which should be used in all communications relating to that individual task.
Pre- Development Process and Development and Testing Cycles Process
The Customer will provide Tmware with a detailed specification of the new change requirement. This will include exactly what the change is for, why it is required, what it is expected to do and what is to be tested.
It is recommended that operational users are included in initial discussions to ensure that all operational scenarios are included in the specification.
Tmware will review feasibility and may enter into discussions to agree the best way to proceed. Detailed discussion will enable the wider scope of the change to be revealed. This will incorporate all aspects of the change to eliminate changes post release.
The specification will be agreed and authorised by the Customer and Tmware.
Where it is deemed to be a chargeable development a formal quotation will be raised as appropriate. This will be based upon complexity, a one off job, or usefulness to the wider product and the urgency of the change. Where the new requirement is complex and or non standard an ongoing monthly charge may apply to cover on-going support and maintenance.
Timescales will be confirmed upon receipt of an approved purchase order.
Notice of commencement of the work will be confirmed. Upon completion of QA testing the Customer will be advised of the release. Release to the Customer Pre Production environment will be confirmed and testing timescales agreed to enable availability of resources to be scheduled.
Availability of Customer testing resource may affect the end milestone completion.
Upon Customer acceptance and sign off agreement, release to the live Production Environment will take place.
The quotation will include further investigation and discussions to clarify and understand the change, time to carry out the work, functionality testing by the developer and QA testing by a different person. Once approval to release to Pre Production has taken place, a backup will be taken, should the change need to be rolled back.
Full operational scenario testing will take place by the Customer to complete user acceptance testing. Upon approval to release to Production, Pre Production will be moved to Production. The Customer will carry out a final test in Production. Once confirmation is made to accept sign off to the release will take place and the latest Production will be copied to Pre Production.
It has been found to be more efficient to release changes one at time. In the event of any adverse effect on the system back out can take place and it is easily identifiable that that the single change is causing an issue.
In the event of any post Production release failure at a later date then fix on fail would take place.
New change requirement will be subject to a new contract.
The specification will detail, where applicable:-
| Description | Responsibility |
| Full detailed specification of the new change, examples / screen shots. what testing is to be carried out what will be tested. | Customer |
| Reason for change | Customer |
| Why is it required | Customer |
| What Customer expects to see | Customer |
| What is going to be tested | Customer |
| What are the expected results | Customer |
| Determine feasibility of change | Company |
| Integrity checks, Impact of Change on any other part of system | Company |
| Risk | Company |
| Specification and Quotation | Company |
| Approve Specification and P/O | Customer |
| Develop software | Company Developer |
| Functionality Testing | Company Developer |
| QA Testing, Plan Internal Testing Scenarios / Expected Results | Company QA |
| Approve release to Production | Customer |
| Move to Pre Production | Company |
| QA test Pre Production | Company |
| Testing Plan Customer Acceptance Testing Operational Scenarios/Volume Testing End to End / Expected Results Minimum 5 days in test | Customer |
| Fail / Snagging’s, example screen shots to be supplied | Customer |
| Re-work, re-test, re-release | Company |
| Pass UAT | Customer |
| Approve release to Production | Customer |
| Copy current Production as Backup | Company |
| Move Pre Production to Production | Company |
| User Test in Production | Customer |
| Fail – Rollback and re-work, re-test | Company |
| Pass – Sign off acceptance | Customer |
| Pass – Copy latest Production to Pre Production | Company |
| Post Production Failure | Customer |
| Fix on Fail | Company |
Development and Testing Cycles
The software will be developed in the Tmware development environment. On completion by the developer of the change, testing by the developer will be carried out to match functionality of the software developed to the specification.
Internal scenario testing to expected results will be carried out by a different person other than the original developer.
QA test will test against Customer provided data and scenarios, what to test and expected results.
Customer will approve release to Pre Production.
Release to customer Pre Production environment will be accompanied by instructions to use.
A copy of current Production will be taken for back up purposes.
Customer User Acceptance Testing will be carried out and provide details of any scenarios and screen scrapes to identify any specification defects. These will be re-worked, re-tested and re-released until pass achieved.
User Acceptance testing pass will be followed by authorisation to release to Production.
Final Customer testing in Production will take place.
Fail will instigate rollback, re-work, re-test and re-release.
Pass will generate sign off acceptance by the Customer.
The latest Production will be copied to production.
Any post production failures will be dealt with as Fix on Fail.
Any major additional new requirements identified during this period will be subject to an additional quotation and extended time-frames for completion.
Requirements and or changes after acceptance may be subject to an additional quotation.
Pre Production Environment
Best practice is for the pre production environment to be as close to live as possible. This is maintained by new testing release being there for a minimum 5 day period before being refreshed with the latest production environment.
Release to production on a minimum level of changes enables faster identification of the change causing an issue should rollback need to take place.
Infrastructure:
Tmware provide business critical software and understand the importance of reliability and uptime for our customers. The hardware, infrastructure and 3rd party services used to host tmWare, have been carefully selected and are under constant review. If we feel there is a weak link, we look to revise the strategy to ensure maximum uptime and performance for our customers.
We are passionate about developing leading edge software and know the user experience extends down to performance speed as much as on screen aesthetics and processes. Our primary and secondary server hardware are to an extremely high specification, installed with powerful Oracle databases to meet the demand of the system and users.
The data centre hosting the primary servers is based at Milton Keynes. The high level of security and resilience were key to our selection process, together with level of on site hardware support and connectivity speed.
Secondary back up servers reside in our own premises in Tamworth and a second data centre in Wales.
We have a Disaster Recovery policy and procedure in place in the event of an issue with a primary server.
