Política de resolución de defectos informados por los clientes

ccppmop1591
HID_release_info_resolution_policy
La política de resolución de defectos estándar de Broadcom se aplica a todas las versiones admitidas de Clarity, incluidas las ediciones On-Premise o SaaS, así como las aplicaciones secundarias como CA Open Workbench y la aplicación móvil de CA.
Este documento proporciona una política de resolución estándar para los defectos notificados por el cliente. Las resoluciones se hacen siguiendo un orden asignando una severidad y prioridad relativas a cada defecto. En este documento se describen criterios para la asignación de la severidad, métodos de entrega de correcciones y objetivos de nivel de servicio (los SLO).
2
Criterios utilizados para asignar la severidad técnica a los defectos
Una vez que Soporte de Broadcom verifica una incidencia, se envía al equipo de desarrollo de software de Clarity para determinar si el comportamiento es un defecto del producto. Si se determina que la incidencia es un defecto del producto, se le asignará una severidad técnica y se revisará para determinar si se entregará una corrección y cuándo se hará. Si un defecto se va a resolver, la corrección se entrega en un paquete definido según el nivel de severidad técnico y su complejidad. Los niveles de severidad técnica se definen de la siguiente manera:
S1: Crítico
Un defecto de severidad 1 (S1) hace referencia a lo siguiente: bloqueo del sistema, pérdida de memoria importante, corrupción o pérdida de datos irrecuperables, deficiencia funcional grave sin solución alternativa, error en la instalación de la aplicación o impedimento de la actualización para realizar otras pruebas funcionales dentro de la misma área o elementos considerados ofensivos en el software, la interfaz de usuario o la documentación.
S2: Alto
Un defecto de severidad 2 (S2) pertenece a una deficiencia funcional importante, a la pérdida o corrupción de datos recuperables, a la documentación o a los mensajes de error que pueden provocar que los usuarios realicen acciones incorrectas, a la degradación significativa del rendimiento, a una incidencia de localización o globalización que hace que los hablantes de otros idiomas diferentes del inglés puedan utilizar las funciones, y las vulnerabilidades de seguridad de las aplicaciones web a través de las cuales los hackers pueden afectar a los datos de la aplicación. Las incidencias de severidad 2 pueden o no tener una solución alternativa.
S3: Medio
Un defecto de severidad 3 (S3) se refiere a la deficiencia de las funciones con una solución alternativa razonable, a los errores de la documentación leves, a los problemas de uso o accesibilidad que causan una leve molestia, a una degradación del rendimiento no significativa, a una desinstalación incompleta o incorrecta de la aplicación o a los mensajes de error incorrectos.
S4: Bajo
Un defecto de severidad 4 (S4) pertenece a una incidencia que no afecta al uso cotidiano de la aplicación como, por ejemplo, los errores leves o las incoherencias de visibilidad baja.
Métodos de entrega estándar para la resolución de defectos
El método de entrega para un defecto resuelto depende de su severidad técnica y de la viabilidad de obtener una corrección. La determinación se basa en la complejidad, el riesgo y la severidad técnica. Hay tres métodos disponibles para la entrega de correcciones para los defectos notificados por el cliente. Una corrección para un defecto resuelto se entrega:
  • en la siguiente versión o
  • en el siguiente Service Pack o
  • en el siguiente parche de mantenimiento (para incidencias críticas).
En algunos casos, no se puede abordar un defecto fuera de la versión.
Por lo general, las mejoras en el producto no se entregan en los parches, si no que se reservan para las versiones y los Service Pack.
Versiones del producto
La calidad es fundamental para nosotros. Por lo general, las versiones del producto se generan cada doce (12) meses y se hace hincapié en la resolución de defectos notificados por el cliente como parte de esas versiones. Nuestro mecanismo de entrega principal para los defectos notificados por el cliente es a través del ciclo de lanzamiento del producto.
Las versiones del producto incluyen funciones, mejoras y correcciones destacadas para defectos notificados por el cliente. Al proporcionar correcciones junto con mejoras, garantizamos que ofrecemos un producto probado y de alta calidad para nuestros clientes.
Durante un ciclo de lanzamiento de un producto, se proporciona un enfoque concreto a las incidencias S2 y a las S3 de
alto impacto
. Un defecto S3 de alto impacto afecta a varios clientes o incluye una solución alternativa que puede que no sea fácil de implementar. Broadcom realizará un esfuerzo razonable para abordar los defectos S3 de impacto bajo incluso si hay una solución alternativa disponible. En algunos casos, y en función de una revisión del defecto y de los clientes afectados, se puede determinar que no se va a corregir el defecto.
Los defectos del producto de severidad baja (S4) se considerarán para su resolución de forma individual una vez que la incidencia se haya confirmado como defecto. Los casos que estén vinculados a defectos S4 se cerrarán una vez que se haya confirmado la incidencia. Los defectos S4 se revisarán solo para las versiones y Broadcom realizará esfuerzos comerciales razonables para incorporarlos en una versión específica del producto. Según los informes de los clientes, el área de funcionalidad y otras consideraciones, se puede llegar a decidir que no se va a corregir un defecto. En este caso, se notificará al cliente a través de nuestro proceso de soporte técnico estándar o a través del sitio web de la comunidad en línea.
Service Packs
Como parte de nuestro esfuerzo para mejorar la experiencia del cliente de forma continuada, los Service Packs se publicarán trimestralmente hasta la siguiente versión importante del producto. Los Service Packs suelen incluir nuevas funciones, mejoras en las funciones existentes y correcciones para los defectos notificados. Los Service Packs siguen la misma metodología para incluir defectos que las versiones del producto.
Versiones de parches
Los parches abordan un conjunto específico de incidencias críticas que afectan a nuestros clientes y que no pueden esperar técnicamente a ser entregados en la próxima versión.
Alcance
Si una incidencia es crítica (S1 o S2 de alto impacto), se puede considerar la entrega en un parche de la corrección para la incidencia.
Broadcom solo corregirá de forma activa los problemas y entregará correcciones a través de parches para las versiones GA y el Service Pack más reciente para las versiones GA-1. Por ejemplo, con la versión de
15.9.1
, solo se realizará un parche en la versión 15.8.1, que es el último Service Pack que representa GA-1. Del mismo modo, con la futura versión de 16.0.0, solo se realizará un parche en la versión 15.9.3, que constituye GA-1. Esta política nos permite centrar nuestros esfuerzos en la generación de los mejores parches para garantizar que las implementaciones de los clientes se realicen correctamente.
Las correcciones que se entregan en los parches se incluyen automáticamente en futuros Service Packs y en las versiones principales del producto.
Exclusiones
Algunas correcciones que, de otro modo, cumplen los criterios de resolución en un parche pueden no ser factibles para entregarlas de esta manera debido a la complejidad, el riesgo y el impacto en otros clientes. Además, los defectos de las áreas siguientes no son candidatos para formar parte de un parche y se reservan para versiones o Service Packs:
  • Defectos que requieren un cambio de esquema
  • Actualizaciones de aplicaciones de cliente como, por ejemplo, OWB, MSP o la aplicación móvil de Clarity (CA PPM)
  • Defectos que necesitan un cambio importante en la interfaz de usuario
  • Defectos para integraciones como Rally (anteriormente conocido como CA Agile Central) y conectores como Microsoft Project
  • Cambios en la pila de arquitectura del producto (compatibilidades) y en la localización
  • Aplicaciones personalizadas construidas mediante nuestras API de REST
  • Defectos para la funcionalidad beta (la funcionalidad beta no es compatible con los entornos de producción)
    Otras áreas también pueden caer en esta categoría donde
    no se incluyen en parches
    .
Para las versiones GA y GA-1, evaluaremos qué correcciones del cliente se incluyen en los parches una vez al trimestre. Se aplican los criterios de corrección estándares teniendo en cuenta los riesgos y la complejidad.
Software como servicio
Los defectos notificados por el cliente se entregan a través de actualizaciones de las versiones principales del producto y a través de Service Packs siguiendo la planificación de actualización de SaaS publicada aquí.
Cadencia
Broadcom determina la cadencia de publicación de parches.
Calidad
Los parches están diseñados para solucionar una incidencia o incidencias específicas e incluirán correcciones acumuladas de parches anteriores (los parches son acumulativos). Todos los parches pasan por las pruebas de control de calidad, pero el alcance de las pruebas se limita solamente a lo siguiente:
  • Verificación de la corrección específica que se resuelve en el parche
  • Cobertura de pruebas de regresión e integración limitada únicamente a las áreas del producto afectadas
Broadcom no realiza pruebas de rendimiento y regresión completas en cada parche. Los parches son acumulativos, pero cuando hay contenido suficiente para garantizar la realización de pruebas de rendimiento y regresión completas o cuando hay un defecto específico que garantiza una prueba especial, se llevarán a cabo las pruebas adicionales según corresponda. La validación ampliada del control de calidad incluye pruebas de regresión, pruebas de rendimiento y pruebas selectivas de PAS según sea necesario. Cualquier parche del que se hayan llevado a cabo pruebas de rendimiento y regresión se anotará en el archivo Léame del parche.
Los clientes deben ser conscientes de que un parche de software puede tener consecuencias adversas involuntarias con respecto al rendimiento o la funcionalidad del software en el entorno del cliente.
Los clientes no deben aplicar parches de software directamente a los sistemas de producción sin verificarlos primero en un entorno de prueba que sea representativo de su sistema de producción en términos de configuración y volúmenes de datos.
Defectos de productos de terceros
Para productos como Microsoft Project (MSP), realizamos pruebas de alto nivel en actualizaciones publicadas recientemente una vez cada dos meses y con el objetivo de realizar pruebas mensualmente. En función de los resultados de estas pruebas, se puede o no recomendar que se aplique un nivel de actualización concreto para su uso con la aplicación.
Si encontramos un defecto en la actualización de MSP que afecta a nuestra integración y no ofrece una experiencia de calidad a nuestros clientes, no recomendaremos ni admitiremos este nivel de actualización para su uso con la versión publicada del producto. Se proporcionará una lista actualizada de las actualizaciones de MSP compatibles en el sitio web de Soporte de Broadcom.
Para Jaspersoft, las fechas de los parches son más propensas a la variación debido a muchos factores. Sin embargo, generalmente se planifica una cadencia de parche trimestral.
Objetivo de nivel de servicio para la entrega de defectos notificados por el cliente
Los defectos corregidos como parte de un parche también se incluirán en la próxima versión o Service Pack disponible. Los detalles se publicarán como parte de las Notas de la versión de una versión determinada, incluidas las correcciones a nivel del parche que se incluyen. El método de entrega varía en función de la severidad:
  • S1
    : Parche
  • S2
    : Parche o versión del producto
  • S3
    : Versión futura del producto o se cierra
  • S4
    : Posible versión futura del producto o se cierra