Project support and warranties are an integral part of our IT solutions. For projects with duration more than 4 months we provide 1 month support period free of charge for bug fixing after completion of the project. All expected works and implied warranties for the dQuality projects include, but are not limited to, the warranties of quality and fitness for a particular purpose, are limited in duration to the above period. For projects smaller than 4 month support period is negotiable.

The warranty becomes effective from the date of final delivery of any project. In the event that there is a delay in the response and the return of feedback after finishing of the warranty period provided by the dQuality Team, we cannot guaranty immediate bug fixes and would consider all feedbacks as change requests. Any change requests (that are not the bugs) have to be estimated separately and they are considered as changing the scope of a project.

Feedback processing:
Please take into consideration rules which apply during the review of customer feedback on issues and new change requests. The software requirements for almost all the projects are changed during the development process. Usually this happens after reviewing the first versions of the product.

The feedback can be of varying nature and could include:

• Defects
• Change requests for the already implemented functionality.
• Change requests for not yet implemented functionality (New feature requests)

Defects - behavior or look-and-feel of the product which does not correspond to the functional/non-functional requirements and interface specifications (usually UI mockups/design but can be also API or other types of interface) defined for the project. If a defect exists in the product then regardless of its origin it is dQuality’s responsibility to fix it in scope of the project during the project time-frame or warranty period.

Change request for the already implemented functionality occurs when a customer wants to change something in the functionality implemented at the previous iterations of the project. If the functionality was implemented according to the requirements/interface specifications, and a requested change differs from them, then the change request is considered as out of scope. In the case that the project team has already started the development of the requirement to be changed, this requirement is considered as a change request.

Change request for not yet implemented functionality occurs when a customer wants to change the requirements which have not yet been implemented. In this case the requirements for this particular change are re-estimated. If the implementation is going to take the same amount of time as the previous version it can be done in scope of the project. If the new requirement takes more time then the difference considered as an out of scope development and will be charged separately. If it takes less time the difference is put into a special “feedback budget” and can be used to implement other out of scope items.

At the same time some small changes (which take up to 0.25 h of development) like moving the UI items around, changing the colors or even small changes in the behavior can be done in scope of the project if they do not influence the development time-frame and deadline. The decision of including or not including a particular small change request in the scope of a project is made based on the status of the project at that time (ahead of schedule, on schedule or out of schedule) by the a Project Lead/Manager. For instance, if the project is ahead of schedule, the project team can implement small change requests within the current project scope. The additional unplanned development takes time and it is possible that at some point the team cannot afford to make such changes because these would compromise the schedule and budget of the project. In this case any changes (even the above mentioned small one) could be considered as out of scope items.

New feature request is a request to add new functional or non-functional attributes into a current application that were not mentioned in the requirements/interface specifications prior to development. The development is based on the customer requirements and interface specifications. If something is not included into the requirements it is not considered as part of the project. New features might be a completely new functionality within the project or, for example, just an additional UI button on the existing page/window which will fulfill a new essential task. All the new features are considered to be out of scope.

All the out of scope items which arise during development are carefully recorded for future phases of development. These items can then be implemented during a phase/project if one of the following conditions is met:

1. Time and resource required for the development are estimated with the appropriate increasing of the project budget and agreed. Deadlines of the project are moved forward so that the project team has sufficient time to implement the new items.
2. Time and resource required for the development are estimated and some old requirements within the same or similar scope are moved out of the current scope and replaced by the new items.
3. The initial estimate and scope of the project contains a special scope (i.e. budget) for covering the possible out of scope items. In this case all the out of scope items are estimated and customer decides which items will be implemented in scope of this special scope. All the items which exceed this budget can be implemented via the first two approaches.