Skip to main content

Service Level Agreement (SLA)

The SLA process for handling defects refers to all defects that are not handled as Hotfixes (HF) or Quickfixes (QF). Thus all Medium and Low severity defects, and for some High severity defects that are handled by the development teams are provided in the next release.

The following table describes the definitions and resolution guidelines per severity level:

Severity

Severity Level Description

Resolution Time and Guidelines

Critical

The defect affects the entire product or critical functionality or critical data or critical vulnerability. It does not have a workaround. (Examples: Unsuccessful installation, complete failure of a feature).

Resolve all.

  • Work immediately and constantly (at least 16x6) to remediate and provide a workaround (which will lower the severity to High or Medium).

  • If there is no workaround, a HF will be provided within 10 calendar days.

  • Fixes are implemented on top of all affected supported versions and in the next release (for example, 8.9, 9.0 and 9.2 if relevant).

High

The defect affects major functionality or major data. It has a workaround but is not obvious and is difficult. Example: A feature is not functional from one module, but the task is doable if 10 complicated indirect steps are followed in another module/s.

Resolve all.

  • Cloud-based offering - 4 weeks.

  • On-Prem offering - 8 weeks.

  • Delivery in the next release when applicable or as a Hotfix over the most current release, if there is no new release in the next 4 to 8 weeks.

Medium

The defect affects minor functionality or non-critical data. It has an easy workaround. Example: A minor feature that is not functional in one module, but the same task is easily doable from another module.

Resolve 50% of the bugs.

  • Cloud based offering - 3 months.

  • On-Prem offering - 6 months.

  • Delivery in the next released version.

  • The defects to be fixed are prioritized by support to ensure they are fixed.

Low

The defect does not affect functionality or data. It does not even need a workaround. It does not impact productivity or efficiency. It is merely an inconvenience. Example: small layout discrepancies, spelling/grammatical errors.

Backlog.

Following flow chart describes the process of handling defects opened by the Software Engineering Group (SEG):

SLA_CHART.png

For all defects, email notification is sent to Support, Product Managers (PMs), QA and Project Managers (PgMs). Distribution lists are created for each Product Unit.

High Bugs Prioritization process

All the high severity defects must be handled and a fix must be provided within 4 weeks for cloud-based products and within 8 weeks for On-Prem products.

For On-Prem applications, if no version is planned to be released within the next 8 weeks, a HF is required. To allow for the delivery of the HF (including testing, packaging, and documentation) within the committed time-frame, development must complete the fix within 6 weeks.

The SEG team will duplicate the defects in all the affected versions (as required by the support team) and the Dev Owner of the defect is responsible for merging the fix to these versions.

Medium Bugs Prioritization process

  1. Triage meeting will convene once a week to review the open medium defects from the last 6 months (defects under Area Path “Customer Bugs Backlog”).

  2. The selected defects to be handled are moved to CxSAST to be allocated and handled by a development team.

  3. SAST Development should handle all the defects under CxSAST. The defects under Customer Bugs Backlog are only candidates for prioritization.

  4. Development commits (add to the plan with target sprint) to 50% of the defects that were opened since the last triage meeting (usually, 1 week before).

Defects older than 6 months are not considered and will be Rejected in TFS. In practice, only half of the defects need to be prioritized.

Specific defects from previous year that need to be fixed or added to the prioritization, will be moved to “Customer Bugs Backlog” and add a tag “Need Prioritization”.

Notice

The priority of a defect does not affect it severity. These are two separate attributes of a defect.