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

ccppmop1581
HID_release_info_resolution_policy
BlueOfficial-Richtlinie für
Clarity
20190125-POLICY.png
Diese Standardrichtlinien für die Fehlerbehebung gelten für alle aktiven unterstützten Versionen von
Clarity
, einschließlich On-Premise- oder SaaS-Editionen und sekundären Anwendungen wie CA Open Workbench und der CA Mobile Time Manager-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 die Kriterien für die Zuweisung des Schweregrads, die Methoden für die Bereitstellung von Fixes und die Service Level-Ziele (SLOs) beschrieben.
2
Kriterien für die Zuweisung eines technischen Schweregrads zu Fehlern
Nachdem der CA 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. Der 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 Verbesserungen am Produkt nicht in Patches bereitgestellt und stattdessen für Versionen und Service Packs reserviert.
Produktversionen
Qualität ist uns sehr wichtig. Produktversionen werden normalerweise alle sechs (6) 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 enthalten neben der Behebung von Fehlern, die von Kunden gemeldetet wurden, auch Verbesserungen und Leistungsmerkmale. Durch die Bereitstellung von Fixes zusammen mit diesen 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. CA 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, und CA unternimmt angemessene wirtschaftliche Bemühungen, 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 für
Classic PPM
benachrichtigt.
Service Packs
Im Rahmen unserer Bemühungen,
Classic PPM
kontinuierlich zu verbessern, werden Service Packs etwa drei Monate nach einer Hauptversion veröffentlicht. Service Packs beinhalten in der Regel Verbesserungen für vorhandene Funktionen und Fixes für gemeldete Fehler. 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 zu 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.
Wir werden nur Probleme für GA- (
15.8.1
) und GA-1-Versionen aktiv mithilfe von Patches beheben und zwar ungefähr alle zwei Monate, z. B. GA im Januar, GA-1 im Februar, GA im März usw. Auf diese Weise können wir uns darauf konzentrieren, die bestmöglichen Patches bereitzustellen, damit Kundenimplementierungen erfolgreich sind.
In Patches bereitgestellte Fehlerbehebungen werden in die Produktversion aufgenommen, das sich derzeit in der Entwicklung befindet (nicht-GA/nächste X.X.0-Version oder X.X.1 Service Pack). Nicht-GA-Versionen haben als Teil des Lebenszyklus ein Datum für den Code-Freeze. Sollte ein Patch nach dem Datum für den Code-Freeze für die sich derzeit in der Entwicklung befindliche Version veröffentlicht werden, werden diese Fixes in den ersten Patch aufgenommen, der als Nächster nach der neuen GA-Version geplant ist. Ein Patch 15.8.1.1 beinhaltet beispielsweise Fehlerbehebungen, die nach dem Datum für den Code-Freeze für Produktversion 15.8.1 bereitgestellt wurden.
Entsprechend unseren Richtlinien für End-of-Service (EOS) und End-of-Life (EOL) werden keine weiteren Fixes erstellt, nachdem der EOL-Status für eine bestimmte Produktversion angekündigt worden ist.
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 nur in Versionen oder Service Packs behoben:
  • Fehler, für die eine Schemaänderung erforderlich ist
  • Aktualisierungen von Client-Anwendungen, wie OWB, MSP oder Mobile Time Manager
  • 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
Wenn das SaaS-Team einen Patch auf eine Instanz in SaaS anwendet, wird die neueste Patch-Ebene für diese Version angewendet.
Häufigkeit
Patches werden in einem kurzen Zeitrahmen veröffentlicht, und es werden weniger Tests als bei einer Version durchgeführt. Patches, die für die GA- und GA-1-Versionen erstellt wurden, werden ungefähr alle zwei Monate veröffentlicht, z. B. GA im Januar, GA-1 im Februar, GA im März usw., um kritische Probleme schnell zu lösen.
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
Es werden keine vollständigen Regressions- und Leistungstests für jeden Patch durchgeführt. Da Patches kumulativ sind, führen wir die entsprechenden Tests durch, wenn genügend Inhalte vorhanden sind, um vollständige Regressions- und Leistungstests zu rechtfertigen, oder wenn ein bestimmter Fehler vorliegt, der spezielle Tests rechtfertigt. 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 diese 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 dem Ergebnis dieser Tests kann es vorkommen, dass eine bestimmte Aktualisierung für die Verwendung mit
Classic PPM
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
Clarity
-Produkt weder empfehlen noch unterstützen. Wir werden eine aktualisierte Liste der unterstützten MSP-Aktualisierungen auf der CA 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.
Andere CA-Anwendungen
Andere CA-Anwendungen, die mit
Classic PPM
funktionieren, z. B. Mobile Time Manager, der erstmals mit
Classic PPM
13.3 veröffentlicht wurde, oder
Classic PPM
Mobile 3.0, das erstmals mit
Classic PPM
15.5 veröffentlicht wurde, folgen hinsichtlich Umfang/Inhalt und Priorität denselben Verfahren wie oben beschrieben. Fixes für diese Produkte können auf der Serverseite oder auf der Client-Seite der Funktion der CA-Anwendung vorgenommen werden.
  • Wenn sich ein Problem nur auf die serverseitigen Funktionen auswirkt, wird ein Fix entweder in der Hauptversion, die sich zu dem Zeitpunkt in der Entwicklung befindet, oder einem GA- oder GA-1-Patch für
    Classic PPM
    bereitgestellt. Es kann auch die Entscheidung gefällt werden, dass das Problem nicht behoben wird.
  • Wenn ein Problem sich nur auf die anwendungsseitigen Funktionen auswirkt, kann der Fix in die Hauptversion der Anwendung aufgenommen werden, die sich zu diesem Zeitpunkt in der Entwicklung befindet. Es kann auch die Entscheidung gefällt werden, dass das Problem nicht behoben wird.
  • Wenn ein Problem sowohl den Server als auch die Anwendung betrifft, wird der Fix nur in der Hauptversion bereitgestellt. Es kann auch die Entscheidung gefällt werden, dass das Problem nicht behoben wird.
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 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