Política de solución de defectos informados por los clientes de Clarity PPM

ccppmop1561
Política de Clarity PPM de BlueOfficial
HID_release_info_resolution_policy
20190125-POLICY.png
Esta política de resolución de defectos estándar se aplica a todas las versiones admitidas de Clarity activas (anteriormente CA PPM), incluidas las ediciones On-Premise, On-Demand o SaaS, así como a las aplicaciones secundarias como CA Open Workbench y la aplicación Gestor de tiempo móvil de CA Clarity.
Este documento proporciona la 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 los criterios para la asignación de la severidad, los métodos de entrega de correcciones y los objetivos de nivel de servicio (los SLO).
2
Criterios utilizados para asignar la severidad técnica a los defectos
Una vez que Soporte de CA verifica una incidencia, se envía al equipo de desarrollo de software de Clarity PPM 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, fallo en la instalación o actualización de la aplicación, impedimento 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 tiene un impacto en el 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. La 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 y 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 seis (6) 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 mejoras y funciones además de los defectos notificados por el cliente. Al proporcionar correcciones junto con estas 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. CA 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 CA 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 de CA PPM.
Service Packs
Como parte de nuestro esfuerzo por mejorar continuamente CA PPM, los Service Packs se publicarán aproximadamente tres meses después de una versión de producto importante. Los Service Packs suelen incluir 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 corregidos 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.
Solo corregiremos de forma activa los problemas a través del mecanismo de parches para las versiones GA y GA-1, aproximadamente cada dos meses (por ejemplo, GA en enero, GA-1 en febrero, GA en marzo, etc.). Esta política nos permite centrar nuestros esfuerzos en la generación de los mejores parches para contribuir a garantizar que las implementaciones de los clientes se realicen correctamente.
Las correcciones que se entregan en los parches se incluirán en la versión del producto que se encuentra actualmente en desarrollo (no GA, si no la siguiente versión X.X.0 o el siguiente Service Pack X.X.1). Las versiones que no son de disponibilidad general (no GA) tienen, como parte del ciclo de vida, una fecha de bloqueo de código. Si se publica un parche después de la fecha de bloqueo de código para la versión que se encuentra actualmente en desarrollo, esas correcciones se incluirán en el primer parche programado inmediatamente después de que la nueva versión sea GA. Por ejemplo, un parche de la versión 15.6.1.1 incluiría las soluciones de defectos entregadas después de la fecha de bloqueo de código para la versión 15.6.1 del producto.
En consonancia con nuestras políticas de finalización de servicio (EOS) y de final de vida útil (EOL), las correcciones no se generarán después de que se anuncie el estado de EOL de una versión específica 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 están reservados para versiones o Service Packs solamente:
  • Defectos que requieren un cambio de esquema
  • Actualizaciones de aplicaciones cliente como, por ejemplo, OWB, MSP o Mobile Time Manager
  • Defectos que necesitan un cambio importante en la interfaz de usuario
  • Defectos para integraciones como CA Agile central (Rally) y para 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
Al solicitar una aplicación de parches para cualquier instancia de SaaS, se aplicará el nivel de parche más reciente para esa versión.
Cadencia
Los parches se publican en un breve período de tiempo con pruebas más limitadas que las pruebas realizadas para una versión. Los parches producidos para las versiones GA y GA-1 se publican aproximadamente cada dos meses (por ejemplo, GA en enero, GA-1 en febrero, GA en marzo, etc.) para proporcionar una resolución rápida de los problemas críticos.
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
No se ejecutan pruebas de rendimiento y regresión completas en cada parche. Debido a que los parches son acumulativos, 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, entonces se llevarán a cabo las pruebas 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. Según el resultado de estas pruebas, se puede o no recomendar que se aplique un nivel de actualización determinado para su uso con
Clarity PPM
.
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 de PPM. Se proporcionará una lista actualizada de las actualizaciones de MSP compatibles en el sitio web de Soporte de CA.
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.
Otras aplicaciones de CA
Otras aplicaciones de CA que funcionan con
Clarity PPM
como, por ejemplo, Mobile Time Manager, y que se publicaron por primera vez con
Clarity PPM
13.3, siguen el mismo alcance y procedimientos de prioridad que se indican anteriormente. Las correcciones para estos productos pueden llevarse a cabo en el servidor o en el cliente de la aplicación de CA.
  • Si una incidencia afecta solamente a la funcionalidad del servidor, cualquier corrección proporcionada se entregará en la versión principal en desarrollo o en un parche GA o GA-1 de CA PPM. También puede decidirse que la incidencia no se corregirá.
  • Si una incidencia afecta solamente a la funcionalidad de la aplicación, es posible que la corrección se incluya en la versión principal de la aplicación en desarrollo en ese momento. También puede decidirse que la incidencia no se corregirá.
  • Si una incidencia repercute tanto en el servidor como en la aplicación, cualquier corrección determinada solo se entregará en la versión principal. También puede decidirse que la incidencia no se corregirá.
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 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