Producto de trabajo: Solicitud de cambio
Estos artefactos se utilizan para documentar y realizar un seguimiento de las solicitudes de cambio en el producto. Se ofrece así un registro de decisiones y, con un proceso de valoración adecuado, se garantiza la consideración del impacto de la solicitud del cambio.
Objetivo
  • Para formular y realizar un seguimiento de los cambios y los defectos
Relaciones
RolesResponsable: Modificado por:
Salida de
Descripción
Esquematización breve

Formulario de ejemplo de solicitud de cambios

  1. Identificación

  • Proyecto:
  • Número de la solicitud de cambio:
  • Tipo de solicitud de cambio: (problema o mejora)
  • Título:
  • Fecha de envío:
  • Originador:
  • Prioridad de la solicitud de cambio:
  1. Problema actual

  • Descripción del problema actual:
  • Anomalía grave:
  • Molestia:
  • Mejora:
  • Solicitud nueva:
  • Condiciones en las que se da el problema:
  • Entorno actual: hardware
  • Compilador del sistema operativo:
  • Origen del problema actual:
  • Impacto del costo o ahorro del problema actual:
  1. Cambio propuesto (originador)

  • Descripción del cambio propuesto:
  • Costo estimado de la implementación del cambio propuesto:
  1. Cambio propuesto (equipo de revisión de cambios)

  • Acción:
  • Aprobado:
  • No aprobado:
  • Diferido:
  • Descripción del cambio propuesto:
  • Elementos de configuración afectados:
  • Categoría:
  • Arreglo del error:
  • Mejora:
  • Característica nueva:
  • Otros:

  1. Resolución

  • Costo estimado de la implementación del cambio propuesto:
  • Implementador:
  • Tiempo real de la implementación del cambio:
  • Análisis:
  • Implementación:
  • Prueba:
  • Documentación:
  • Número afectado de líneas de código:
  1. Valoración

  • Métodos de prueba
  • Inspección
  • Análisis
  • Demostración
  • Prueba
  • Plataformas de prueba
  • Guiones de prueba
  1. Disposición del equipo de la revisión de cambios

  • Cambios aprobados y aceptados
Descripción principal

La necesidad de cambio es inherente al proceso de desarrollo de un sistema de software desde su creación inicial y según se va utilizando y conservando en el funcionamiento diario de un entorno activo. Las solicitudes de cambio ofrecen un registro de decisiones y, con un proceso de valoración adecuado, se garantiza la consideración del impacto de los cambios.

 Las solicitudes de cambio también se conocen como CR, defectos, errores, incidentes,solicitudes de mejora. La captura y gestión de estas solicitudes garantiza que los cambios en un sistema se realicen de un modo controlado de manera que su efecto en el sistema pueda predecirse. Algunos tipos de solicitud de cambio son:

Solicitudes de mejora: usadas por diversos interesados para solicitar características futuras que desean haber incluido en el producto. Son un tipo de solicitud del interesado que captura y elabora los conceptos básicos de las necesidades de los interesados.

Defectos: son informes de anomalías en un producto de trabajo entregado. Los defectos incluyen omisiones e imperfecciones encontradas durante las primeras fases del ciclo vital, o síntomas de errores que deben aislarse y corregirse dentro del software. Los defectos también pueden incluir desvíos del comportamiento esperado del software (como por ejemplo, problemas de uso).

El objetivo de un defecto es comunicar los detalles del problema, lo que permite una acción correctiva, una resolución y un seguimiento. Las personas siguientes utilizan la solicitud de cambios (CR):

  • Conjunto de roles: analistas, utilizan las CR para definir cambios significativos de los requisitos de nivel superior, y para determinar requisitos, especialmente de las CR identificadas como solicitudes de mejora.
  • Conjunto de roles: gestores, utilizan las CR para gestionar y controlar la asignación de trabajo.
  • Conjunto de roles: verificadores, utilizan las CR para describir anomalías (defectos), omisiones y problemas de calidad que se encuentran durante la verificación del software.
  • Conjunto de roles: desarrolladores, utilizan las CR para analizar las anomalías y buscar los errores o causas subyacentes con el fin de resolver la CR.
  • Rol: analista de pruebas, utiliza las CR para planificar las pruebas que verificarán las CR resueltas y para evaluar el esfuerzo de la prueba mediante el análisis de conjuntos de defectos con el fin de medir las tendencias de la calidad del software y el proceso de ingeniería de software.
Propiedades
Opcional
PlaneadoYes
Personalización
Opciones de representación

Los campos reales y los datos necesarios para identificar, describir y realizar un seguimiento adecuado de los defectos varían y dependen de los estándares, las directrices y del sistema de control de cambios implementado.

Suele ser más eficiente almacenar solicitudes de cambio en una base de datos o cambiar el sistema de gestión de solicitudes, de modo que las solicitudes de cambio puedan gestionarse más fácilmente (por ejemplo, ordenándolas por prioridad, realizando un seguimiento de asignaciones y estado de terminación). En proyectos pequeños, una hoja de cálculo puede ser suficiente.

En un proyecto pequeño puede gestionar los defectos en una simple lista. También puede utilizar una hoja de cálculo con una columna independiente para cada atributo de la solicitud de cambio. Esto sólo es gestionable en el caso de sistemas pequeños. Cuando el número de personas implicadas y el número de defectos crecen más allá de un punto determinado, deberá utilizar un sistema más flexible de seguimiento de defectos.



Más información