Richtlinien für die Behebung von Fehlern, die von Kunden gemeldet wurden

ccppmop159
HID_release_info_resolution_policy
Die Broadcom-Richtlinien für die Fehlerbehebung gelten für alle aktiven unterstützten Clarity-Versionen, einschließlich On-Premise- oder SaaS-Editionen und sekundären Anwendungen wie CA Open Workbench und der CA Mobile-App.
Dieses Dokument enthält Standardrichtlinien für die Behebung von Fehlern, die von Kunden gemeldet wurden. Lösungen werden der Reihenfolge nach vorgenommen. Hierzu werden jedem Fehler ein relativer Schweregrad und eine Priorität zugewiesen. In diesem Dokument werden Kriterien für die Zuweisung des Schweregrads, Methoden für die Bereitstellung von Fixes und Service Level-Ziele (SLOs) beschrieben.
2
Kriterien für die Zuweisung eines technischen Schweregrads zu Fehlern
Nachdem der Broadcom Support ein Problem überprüft hat, wird es an das Softwareentwicklungsteam von Clarity weitergeleitet, um festzustellen, ob es sich bei dem Verhalten um einen Produktfehler handelt. Wenn festgestellt wird, dass es sich bei dem Problem um einen Produktfehler handelt, wird diesem ein technischer Schweregrad zugewiesen, und es wird geprüft, ob und wann ein Fix bereitgestellt wird. Wenn ein Fehler behoben wird, wird der Fix entsprechend dem technischen Schweregrad und der Komplexität in einem definierten Paket bereitgestellt. Die technischen Schweregrade sind folgendermaßen definiert:
S1: Kritisch
Schweregrad 1 (S1) wird bei folgenden Fehlern zugewiesen: Systemabstürzen, schwerwiegenden Speicherverlusten, nicht wiederherstellbaren Datenfehlern oder -verlusten, schwerwiegenden Funktionsmängeln ohne Umgehungslösung, Fehlern bei der Installation oder dem Upgrade von Anwendungen, Vermeidung weiterer Funktionstests innerhalb derselben Bereiche oder bei Elementen in der Software, Benutzeroberfläche oder Dokumentation, die als anstößig betrachtet werden.
S2: Hoch
Schweregrad 2 (S2) wird bei folgenden Fehlern zugewiesen: schwerwiegenden Funktionsmängeln, wiederherstellbaren Datenfehlern oder -verlusten, Dokumentations- oder Fehlermeldungen, die dazu führen können, dass Benutzer falsche Aktionen durchführen, erheblichen Leistungabfällen, Lokalisierungs- oder Globalisierungsproblemen, die dazu führen, dass bestimmte Funktionen von nicht-englischsprachigen Benutzern nicht verwendet werden können, und Sicherheitsschwachstellen in der Webanwendung, über die Hacker an Anwendungsdaten gelangen können. Für Probleme mit Schweregrad 2 kann eine Umgehungslösung vorhanden sein.
S3: Mittel
Schweregrad 3 (S3) wird bei folgenden Fehlern zugewiesen: Funktionsmängeln mit einer angemessenen Umgehungslösung, geringfügigen Dokumentationsfehlern, Problemen mit der Benutzerfreundlichkeit oder Barrierefreiheit, die kleinere Unannehmlichkeiten verursachen, geringen Leistungsabfällen, unvollständiger/falscher Deinstallation der Anwendung oder falschen Fehlermeldungen.
S4: Niedrig
Schweregrad 4 (S4) wird bei folgenden Fehlern zugewiesen: Problemen, die sich nicht auf die tägliche Verwendung der Anwendung auswirken, z. B. kleinere Designfehler oder Inkonsistenzen.
Standardmäßige Bereitstellungsmethoden für die Fehlerbehebung
Die Bereitstellungsmethode für einen behobenen Fehler hängt vom technischen Schweregrad und der Durchführbarkeit eines Fixes ab Die Ermittlung basiert auf der Komplexität, dem Risiko und dem technischen Schweregrad. Für die Bereitstellung von Fixes für Fehler, die von Kunden gemeldet wurden, stehen drei Methoden zur Verfügung. Ein Fix für einen behobenen Fehler wird wie folgt bereitgestellt:
  • in der nächsten Version oder
  • im nächsten Service Pack oder
  • im nächsten Wartungs-Patch (bei kritischen Problemen)
In einigen Fällen kann ein Fehler nicht außerhalb einer Version behoben werden.
Normalerweise werden Produktverbesserungen nicht in Patches bereitgestellt, sondern stattdessen für Versionen und Service Packs reserviert.
Produktversionen
Qualität ist uns sehr wichtig. Produktversionen werden normalerweise alle zwölf (12) Monate erstellt. Ein Schwerpunkt wird dabei auf die Behebung von Fehlern gelegt, die von Kunden gemeldet wurden. Unser Hauptmechanismus für Fehler, die von Kunden gemeldet wurden, ist der Produktversionszyklus.
Produktversionen umfassen Leistungsmerkmale, Verbesserungen und Fixes für Fehler, die von Kunden gemeldet wurden. Durch die Bereitstellung von Fixes zusammen mit Verbesserungen stellen wir sicher, dass wir unseren Kunden ein qualitativ hochwertiges, gründlich getestetes Produkt zur Verfügung stellen.
Im Laufe eines Produktversionszyklus wird ein besonderer Schwerpunkt auf Fehler mit den Schweregraden S2 und S3
(mit hoher Auswirkung)
gelegt. Ein S3-Fehler mit hoher Auswirkung wirkt sich auf mehrere Kunden aus oder schließt eine Umgehungslösung ein, die möglicherweise nicht ohne Weiteres verwendet werden kann. Broadcom ist bestrebt, S3-Fehler mit geringer Auswirkung zu beheben, auch wenn eine Umgehungslösung verfügbar ist. In einigen Fällen kann aufgrund einer Überprüfung des Fehlers und der betroffenen Kunden entschieden werden, dass der Fehler nicht behoben wird.
Die Behebung von Produktfehlern mit niedrigem Schweregrad (S4) wird von Fall zu Fall untersucht, sobald das Problem als Fehler bestätigt wurde. Alle Fälle, die mit S4-Fehlern verknüpft sind, werden geschlossen, sobald das Problem bestätigt wurde. S4-Fehler werden nur für Versionen geprüft. Broadcom unternimmt wirtschaftlich angemessene Anstrengungen, um diese in eine bestimmte Produktversion einzubinden. Basierend auf Kundenberichten, Funktionsbereichen und anderen Überlegungen können wir zu der Entscheidung gelangen, dass ein Fehler nicht behoben wird. In diesem Fall wird der Kunde über unseren Standard-Support-Prozess oder die Online-Community-Website benachrichtigt.
Service Packs
Im Rahmen unserer Bemühungen, die Kundenerfahrung kontinuierlich zu verbessern, werden Service Packs quartalsweise bis zur nächsten Hauptversion veröffentlicht. Service Packs beinhalten in der Regel neue Funktionen, Verbesserungen für vorhandene Funktionen und Fixes für Fehler, die von Kunden gemeldet wurden. Die Vorgehensweise für die Aufnahme von Fehlern in Service Packs ist dieselbe wie bei Produktversionen.
Patch-Releases
Patches befassen sich mit bestimmten kritischen Problemen, die Auswirkungen auf unsere Kunden haben und deren Behebung aufgrund ihrer technischen Natur nicht bis zur nächsten Version warten kann.
Umfang/Inhalt
Wenn es sich um ein kritisches Problem handelt (S1 oder S2 mit hoher Auswirkung), kann die Bereitstellung eines Fixes für dieses Problem für einen Patch in Erwägung gezogen werden.
Broadcom wird nur Probleme in GA-Versionen und im aktuellen Service Pack für GA-1-Versionen aktiv beheben und Fixes für diese Probleme in Patches bereitstellen. Mit der Veröffentlichung von Version
15.9.0
werden beispielsweise nur noch Patches für Version 15.8.1 bereitgestellt, da 15.8.1 das aktuelle Service Pack für die GA-1-Version ist. Auf ähnliche Weise werden bei der zukünftigen Veröffentlichung von 16.0.0 nur noch Patches für Version 15.9.3 bereitgestellt, da 15.9.3 in diesem Fall die GA-1-Version wäre. Auf diese Weise können wir uns darauf konzentrieren, die bestmöglichen Patches bereitzustellen, damit Kundenimplementierungen erfolgreich sind.
Fixes, die in Patches bereitgestellt werden, sind automatisch in zukünftigen Service Packs und/oder Hauptversionen enthalten.
Ausschlüsse
Einige Fixes, die andernfalls die Kriterien für die Behebung in einem Patch erfüllen, können möglicherweise aufgrund ihrer Komplexität, Risiken und Auswirkungen auf andere Kunden nicht auf diese Weise bereitgestellt werden. Außerdem sind Fehler in den folgenden Bereichen keine Kandidaten für einen Patch und werden in Versionen oder Service Packs behoben:
  • Fehler, für die eine Schemaänderung erforderlich ist
  • Aktualisierungen von Client-Anwendungen wie OWB, MSP oder der Clarity Mobile Application (CA PPM)
  • Fehler, für die eine wesentliche Änderung der Benutzeroberfläche erforderlich ist
  • Fehler bei Integrationen, z. B. Rally (früher CA Agile Central), und Connectors, z. B. Microsoft Project
  • Product Architecture Stack (Kompatibilitäten) und Lokalisierungsänderungen
  • Benutzerdefinierte Anwendungen, die mithilfe unserer REST-APIs erstellt wurden
  • Fehler für Beta-Funktionen (Beta-Funktionen werden in Produktionsumgebungen nicht unterstützt)
    Andere Bereiche können ebenfalls in diese Kategorie fallen, für die
    keine Patches
    erstellt werden.
Für GA- und GA-1-Versionen wird ausgewertet, welche Client-seitigen Fixes einmal pro Quartal in Patches enthalten sind. Die Standardkriterien für Fixes hinsichtlich Risiko und Komplexität werden angewendet.
SaaS
Fehler, die von Kunden gemeldet werden, werden gemäß dem hier veröffentlichten SaaS-Upgrade-Ablaufplan über Upgrades für Hauptversionen und Service Packs bereitgestellt.
Häufigkeit
Broadcom entscheidet, wie häufig Patches veröffentlicht werden.
Qualität
Patches dienen der Behebung eines bestimmten Problems oder mehrerer Probleme und enthalten Fixes, die aus früheren Patches zusammengefasst werden (Patches sind kumulativ). Alle Patches durchlaufen QA-Tests, der Umfang der Tests ist jedoch auf Folgendes beschränkt:
  • Überprüfung des spezifischen Fixes, der im Patch bereitgestellt wurde
  • Abdeckung der Regressions- und Integrationstests, die auf den betroffenen Produktbereich beschränkt sind
Broadcom führt keine vollständigen Regressions- und Leistungstests für jeden Patch durch. Patches sind kumulativ. Wenn jedoch genügend Inhalte vorhanden sind, die vollständige Regressions- und Leistungstests rechtfertigen, oder wenn ein bestimmter Fehler vorliegt, der spezielle Tests rechtfertigt, führen wir die entsprechenden Tests durch. Die erweiterte QA-Validierung umfasst Regressionstests, Leistungstests und ausgewählte PAS-Tests nach Bedarf. Alle Patches, für die Leistungs- und Regressionstests durchgeführt wurden, werden in der README-Datei entsprechend aufgeführt.
Kunden sollten sich darüber im Klaren sein, dass ein Software-Patch unter Umständen unbeabsichtigte negative Auswirkungen auf die Leistung oder Funktionalität der Software in der Kundenumgebung haben kann.
Kunden sollten Software-Patches nicht direkt auf Produktionssysteme anwenden, ohne sie zuvor in einer Testumgebung zu überprüfen, die für ihr Produktionssystem hinsichtlich Konfiguration und Datenvolumen repräsentativ ist.
Fehler bei Drittanbieter-Produkten
Für Produkte wie Microsoft Project (MSP) führen wir alle zwei Monate allgemeine Tests zu neu veröffentlichten Aktualisierungen durch, mit dem Ziel, diese Tests monatlich durchzuführen. Basierend auf den Ergebnissen dieser Tests kann es vorkommen, dass eine bestimmte Aktualisierung für die Verwendung mit der Anwendung empfohlen wird.
Wenn wir einen Fehler in der MSP-Aktualisierung finden, der sich auf unsere Integration auswirkt und unseren Kunden keine qualitativ hochwertige Erfahrung bietet, werden wir diese Aktualisierung für die Verwendung mit dem veröffentlichten Produkt weder empfehlen noch unterstützen. Wir werden eine aktualisierte Liste der unterstützten MSP-Aktualisierungen auf der Broadcom Support-Website bereitstellen.
Für Jaspersoft weichen Patch-Daten aufgrund vieler Faktoren häufiger ab. Im Allgemeinen planen wir jedoch, alle drei Monate einen Patch zu veröffentlichen.
Service Level-Ziel für die Behebung von Fehlern, die von Kunden gemeldet wurden
Fehler, die im Rahmen eines Patches behoben werden, sind ebenfalls in der nächsten verfügbaren Version oder im nächsten Service Pack enthalten. Details werden als Teil der Versionshinweise für eine bestimmte Version veröffentlicht, einschließlich der enthaltenen Fixes auf Patch-Ebene. Die Bereitstellungsmethode variiert je nach Schweregrad:
  • S1
    : Patch
  • S2
    : Patch oder Produktversion
  • S3
    : Zukünftige Produktversion oder geschlossen
  • S4
    : Mögliche zukünftige Produktversion oder geschlossen