Stratégie de résolution des défauts signalés par les clients

ccppmop1581
HID_release_info_resolution_policy
Stratégie BlueOfficial
Clarity
20190125-POLICY.png
Cette stratégie de résolution des défauts standard s'applique à toutes les versions de
Clarity
prises en charge, notamment les éditions sur site ou SaaS, ainsi qu'aux applications secondaires telles que CA Open Workbench et à l'application CA Mobile Time Manager.
Ce document décrit la stratégie de résolution standard pour les défauts signalés par les clients. Les résolutions sont exécutées par ordre de sévérité relative et de priorité pour chaque défaut. Ce document décrit les critères d'affectation de sévérité, les méthodes de fourniture des correctifs et les objectifs de niveau de service.
2
Critères d'affectation de sévérité technique aux défauts
Lorsque le service de support de CA a vérifié un problème, il est renvoyé vers l'équipe de développement de logiciels
Clarity
pour déterminer si le comportement en question est un défaut de produit. Si le problème est identifié comme un défaut de produit, une sévérité technique lui est affectée pour déterminer si un correctif pourra être fourni ainsi qu'une date de fourniture. Si un défaut est résolu, le correctif est livré avec un package défini en fonction de son niveau de sévérité technique et de sa complexité. Les niveaux de sévérité technique sont définis comme suit :
S1 : Critique
La sévérité 1 (S1) concerne les défauts suivants : arrêt brutal du système, importante fuite de mémoire, endommagement ou perte de données irrécupérable, insuffisance fonctionnelle majeure sans solution, panne d'installation ou de mise à niveau de l'application, impossibilité de réaliser des tests approfondis de fonctionnalités dans la même zone, éléments du logiciel, de l'interface utilisateur ou de la documentation jugés offensants.
S2 : Elevé
La sévérité 2 (S2) concerne les défauts suivants : insuffisance fonctionnelle majeure, endommagement ou perte de données irrécupérable, documentation ou messages d'erreur susceptibles d'inciter les utilisateurs à prendre des mesures inappropriées, dégradation significative des performances, problème de localisation ou de globalisation empêchant les utilisateurs non anglophones d'utiliser correctement les fonctionnalités, vulnérabilités de sécurité des applications Web permettant aux pirates informatiques d'exploiter les données d'application. Une solution n'est pas toujours disponible pour les problèmes de sévérité 2.
S3 : Moyen
La sévérité 3 (S3) concerne les défauts suivants : fonctionnalités défaillantes avec solution raisonnable, erreurs de documentation mineures, problème d'utilisation ou d'accessibilité entraînant une dégradation mineure, dégradation des performances non significative, désinstallation incorrecte ou non terminée de l'application, messages d'erreur incorrects.
S4 : Faible
La sévérité 4 (S4) concerne les défauts suivants : problèmes n'affectant pas l'utilisation quotidienne de l'application, tels que des erreurs mineures de visibilité faible ou des incohérences.
Méthodes de livraison standard pour la résolution des défauts
La méthode de livraison pour un défaut résolu dépend de sa sévérité technique et de la possibilité de créer un correctif. La complexité, le risque et la sévérité technique sont les critères pris en compte pour cela. Trois méthodes sont disponibles pour la fourniture de correctifs des défauts signalés par les clients. Le correctif pour un défaut résolu sera fourni dans :
  • la version suivante, ou
  • le Service Pack suivant, ou
  • le patch de maintenance suivant (pour les problèmes critiques).
Dans certains cas, les défauts ne peuvent pas être résolus hors d'une version.
En règle générale, les améliorations apportées au produit ne sont pas fournies dans les patchs et sont réservées aux versions et aux Service Packs.
Versions de produit
La qualité nous importe. Les versions de produit sont généralement produites tous les 6 mois et la résolution des défauts signalés par les clients y est mise en exergue. La livraison d'une résolution pour les défauts signalés par les clients est principalement s'effectue dans le cadre de notre cycle de versions de produit.
Les versions de produit incluent des améliorations et fonctionnalités importantes, en plus des défauts signalés par les clients. En apportant des correctifs avec ces améliorations, nous nous assurons de fournir un produit de haute qualité et testé pour nos clients.
Au cours d'un cycle de version de produit, l'accent est notamment mis sur les problèmes S2 et S3
à impact élevé
. Les défauts S3 à impact élevé affectent plusieurs clients ou présentent une solution qui n'est peut-être pas facilement consommable. CA déploiera les efforts raisonnables pour traiter les défauts S3 à impact faible, même si une solution est disponible. Dans certains cas, après examen du défaut et en fonction des clients affectés, il peut être décidé de ne pas corriger le défaut.
Les problèmes que notre équipe considère comme des défauts de produit de sévérité faible (S4) seront traités au cas par cas. Tout défaut lié à la sévérité S4 sera clôturé une fois confirmé. Les défauts S4 seront examinés uniquement dans le cadre de la publication de versions et CA déploiera des efforts commerciaux raisonnables pour les intégrer à une version de produit donnée. En fonction des rapports client, du domaine de la fonctionnalité et d'autres points, il peut être décidé de ne pas résoudre un défaut. Dans ce cas, le client sera informé via notre processus de support standard ou le site Web de la communauté en ligne de
PPM classique
.
Service Packs
Dans le cadre de nos efforts d'amélioration continue de
PPM classique
, les Service Packs seront publiés environ trois mois après la publication d'une version majeure du produit. Les Service Packs incluent généralement des améliorations apportées à des fonctionnalités existantes et des correctifs aux défauts signalés. Les Service Packs suivent la même méthodologie que les versions de produit pour inclure les défauts.
Versions de patch
Les patchs répondent à un ensemble spécifique de problèmes critiques qui affectent nos clients et ne peuvent pas être techniquement résolus dans la version suivante.
Portée
Si un problème est critique (S1 ou S2 à impact élevé), la livraison d'un correctif pour ce problème peut être envisagée dans le cadre d'un patch.
Nous résolvons uniquement les problèmes et livrons des patchs pour les versions GA (
15.8.1
) et GA-1, environ tous les deux mois (par exemple, GA en janvier, GA-1 en février, GA en mars, etc.). Cette stratégie permet de centrer nos efforts sur la production des patchs de meilleure qualité pour assurer une implémentation correcte par les clients.
Les correctifs fournis dans les patchs seront inclus dans la version du produit en cours de développement (version non-GA/X. X.0 suivante ou Service Pack X. X.1). Dans le cadre du cycle de vie, les versions non-GA présentent une date de gel du code. Si un patch est publié après la date de gel du code pour la version en cours de développement, ces correctifs seront inclus dans le premier patch planifié immédiatement après la disponibilité de la nouvelle version. Par exemple, le patch 15.8.1.1 inclut les résolutions de défaut livrées après la date de gel du code pour la version 15.8.1.
Conformément aux stratégies de fin de service (EOS) et de fin de vie (EOL), les correctifs ne seront pas générés après l'annonce du statut de fin de vie d'une version spécifique.
Exclusions
Certains correctifs répondant aux critères de résolution dans un patch peuvent ne pas être livrables en raison de leur complexité, des risques et de l'impact sur d'autres clients. De plus, les défauts dans les domaines suivants ne peuvent pas être résolus dans un patch et sont réservés aux versions ou Service Packs uniquement :
  • Défauts requérant un changement de schéma
  • Mises à jour d'applications clientes telles que OWB, MSP ou Mobile Time Manager
  • Défauts nécessitant une modification importante de l'interface utilisateur
  • Défauts d'intégration tels que Rally (précédemment appelé CA Agile Central) et de connecteurs tels que Microsoft Project
  • Modifications apportées à la pile d'architecture du produit (compatibilités) et à la localisation
  • Applications personnalisées créées à l'aide de nos API REST
  • Défauts pour les fonctionnalités bêta (non prises en charge dans les environnements de production)
    D'autres domaines peuvent également être inclus dans cette catégorie
    Aucun patch
    .
Dans le cadre des versions GA et GA-1, nous évaluerons les correctifs côté client inclus dans les patchs une fois par trimestre. Les critères de correction standard pour les risques et la complexité sont appliqués.
Logiciel à la demande
Lorsque l'équipe SaaS applique un patch à une instance SaaS, le dernier niveau de patch pour cette version sera appliqué.
Intervalle
Les patchs sont publiés dans un laps de temps très court et font l'objet de tests plus limités que ceux effectués pour une version. Les patchs produits pour les versions GA et GA-1 sont publiés environ tous les deux mois (par exemple, GA en janvier, GA-1 en février, GA en mars, etc.) afin de résoudre rapidement les problèmes critiques.
Qualité
Les patchs doivent résoudre un ou plusieurs problèmes spécifiques et incluent des correctifs cumulés à partir de patchs antérieurs (Les patchs sont cumulatifs.). Tous les patchs subissent des tests d’assurance qualité, mais leur portée est limitée aux points suivants :
  • Vérification du correctif spécifique fourni dans le patch
  • Tests de régression et d'intégration limités aux domaines du produit concernés
Nous n'effectuons pas des tests de régression et de performances complets sur chaque patch. Les patchs étant cumulatifs, lorsque le contenu est suffisant pour garantir des tests de régression et de performances complets, ou qu'il existe un défaut spécifique nécessitant des tests spéciaux, nous procédons aux tests appropriés. La validation de l'assurance qualité étendue inclut des tests de régression, des tests de performances et des tests sélectifs de pile d'architecture du produit, le cas échéant. Le fichier Readme du patch indique s'il a fait l'objet de tests de performances et de régression.
Les clients doivent être conscients du fait qu'un patch peut entraîner des conséquences néfastes imprévues sur les performances ou les fonctionnalités du logiciel dans leur environnement.
Les clients ne doivent pas appliquer les patchs logiciels directement aux systèmes de production, sans effectuer une vérification préalable dans un environnement de test qui soit représentatif de leur système de production en termes de configuration et de volumes de données.
Défauts de produits tiers
Dans le cas de produits tels que Microsoft Project (MSP), nous effectuons tous les deux mois des tests de haut niveau sur les mises à jour récemment publiées et un test mensuel dans un objectif d'effort optimal. En fonction du résultat de ces tests, nous pouvons recommander ou déconseiller l'application d'un certain niveau de mise à jour à utiliser avec
PPM classique
.
Dans le cas d'un défaut dans la mise à jour de MSP qui affecte notre intégration et nous empêche de fournir une expérience de qualité à nos clients, nous ne recommandons pas d'utiliser le niveau de mise à jour pour la version de
Clarity
publiée ni ne le prenons en charge. Nous fournirons une liste actualisée des mises à jour de MSP prises en charge sur le site Web du support de CA.
Pour Jaspersoft, les dates des patchs sont plus susceptibles de varier en raison de nombreux facteurs. Toutefois, nous planifions généralement une publication trimestrielle pour les patchs.
Autres applications CA
D'autres applications CA fonctionnant avec
PPM classique
(par ex. : Mobile Time Manager, d'abord publiée avec
PPM classique
13.3,
PPM classique
Mobile 3.0, d'abord publiée avec
PPM classique
15.5) suivent les mêmes procédures de portée et de priorité que celles indiquées ci-dessus. Les correctifs de fonctionnalités de ces produits peuvent être appliqués côté serveur ou côté client de l'application CA.
  • Si un problème affecte uniquement une fonctionnalité côté serveur, un correctif est fourni dans la version principale en cours de développement ou dans le cadre d'un patch
    PPM classique
    GA ou GA-1. Il peut également être décidé de ne pas résoudre le problème.
  • Si un problème affecte uniquement une fonctionnalité côté application, le correctif peut être intégré à la version principale de l'application en cours de développement à ce stade. Il peut également être décidé de ne pas résoudre le problème.
  • Si un problème affecte à la fois le serveur et l'application, un correctif spécifique est fourni uniquement dans la version principale. Il peut également être décidé de ne pas résoudre le problème.
Objectif de niveau de service pour la fourniture de correctifs pour les défauts signalés par les clients
Les correctifs de défaut fournis dans le cadre d'un patch seront également inclus dans la prochaine version disponible. Les détails seront publiés dans les Notes de parution d'une version spécifique, y compris les correctifs de niveau de patch inclus. La méthode de fourniture varie en fonction de la sévérité :
  • S1
    : patch
  • S2
    : patch ou version de produit
  • S3
    : version de produit suivante ou clôture
  • S4
    : possibilité de version de produit suivante ou clôture