GUI-BDT-019 Llenado de log de problemas/retroalimentación

v 3.0

Objetivo

Esta guía tiene como objetivo proporcionar instrucciones para el registro y seguimiento de problemas y retroalimentaciones en el departamento de desarrollo de software. La implementación de esta guía busca mejorar la eficiencia y la calidad del proceso de gestión de problemas, asegurando una respuesta rápida y adecuada a los riesgos que se convierten en problemas y a las retroalimentaciones recibidas.

Notas introductorias

El log de problemas y retroalimentación es una herramienta fundamental para la mejora continua del proyecto. Permite documentar y rastrear los problemas que surjan a lo largo del proyecto, así como las retroalimentaciones de profesores y socios formadores, asegurando que se tomen las acciones correctivas necesarias.

Contenido

Identificación en el log de Problemas/Retro

Una vez que se tiene identificado un problema o se obtiene retroalimentación de algún profesor o socio formador, se debe ingresar el problema o comentario de retroalimentación en el log con los siguientes identificadores:

1. ID Problema: Asigna un identificador único para cada problema registrado. Estos deben de ir en orden ascendente.
2. Fecha de Identificación: Registra la fecha en que se identificó el problema o se obtuvo la retroalimentación.
3. Iteración: Especifica la iteración o fase del proyecto en la que se detectó el problema o retroalimentación.

Descripción del problema

4. Descripción del Problema: Proporciona una descripción clara y concisa del problema identificado.
5. Categoría: Clasifica el problema según su naturaleza**:
   • Architecture: Problemas relacionados con la arquitectura del sistema o del software.
   • Dependency: Problemas que ocurren cuando una tarea, componente o persona depende de otra para avanzar.
   • Legal: Problemas legales o de cumplimiento normativo que pueden afectar el proyecto.
   • Life Cycle: Desafíos que surgen en diferentes etapas del desarrollo del proyecto.
   • Quality & Testing: Problemas relacionados con la calidad del software y el proceso de pruebas.
   • Requirements: Problemas relacionados con la definición, documentación, gestión y cumplimiento de los requisitos del proyecto.
   • Schedule: Problemas relacionados con la planificación y el cronograma del proyecto.
   • Security: Problemas de seguridad que abarcan vulnerabilidades, amenazas y riesgos que pueden comprometer la confidencialidad, integridad y disponibilidad del sistema.
   • Welfare: Problemas relacionados con el bienestar del equipo de desarrollo.
   • Training: Problemas relacionados con la falta de habilidades o conocimientos necesarios para llevar a cabo tareas específicas del proyecto.
   • Motivation and commitment: Problemas relacionados con la motivación y el compromiso del equipo de desarrollo.
   • Stakeholders: Retroalimentación dada por los stakeholders (comentarios de mejora, peticiones de cambio, etc).
   • Planning: Problemas de planificación general del proyecto.
     **Según las necesidades y visión del proyecto, son las etiquetas que se eligen para este.
6. Nombre Stakeholder: En caso de ser un problema relacionado con algún stakeholder, se selecciona el nombre de este, de lo contrario, se selecciona N/A (No aplica).

Evaluación del Problema

7. Severidad: Evalúa y asigna un nivel de severidad al problema:
   • Muy bajo: Riesgo con una puntuación de 1-2 (Verde claro).
   • Bajo: Riesgo con una puntuación de 3-4 (Verde).
   • Medio: Riesgo con una puntuación de 4-9 (Amarillo).
   • Alto: Riesgo con una puntuación de 10-12 (Naranja).
   • Muy Alto: Riesgo con una puntuación de 15-16 (Rojo claro).
   • Severo: Riesgo con una puntuación de 20-25 (Rojo).
     Las puntuaciones y colores se pueden determinar con la tabla de métricas para problemas, ésta es la misma para proyectos de desarrollo. Para el departamento se utiliza la siguiente métrica de problemas.
8. Estado: Actualiza el estado del problema:
   • Nuevo: El problema se acaba de identificar y no se ha trabajado en él para mitigarlo, es decir, no ha sido gestionado.
   • En proceso: Es un problema que ya está siendo trabajado para descartarlo.
   • Resuelto: Es un problema que ya se solucionó.

Plan de Acción

9. Plan de Acción: Describe las acciones que se tomarán para resolver el problema. Puede ser el mismo que el plan de mitigación del riesgo (si es que este problema estaba mapeado como riesgo anteriormente), puede ser este mismo plan de mitigación pero editado o puede ser un plan de mitigación nuevo.
10. Responsable: Asigna las responsabilidades de la resolución del problema a una persona o equipo específico.

Seguimiento y Resolución

11. Fecha de Resolución: Registra la fecha en que el problema fue resuelto.
12. Verificación de Resolución: Documenta el proceso de verificación para asegurar que el problema se ha resuelto adecuadamente.

Retroalimentación

Para las retroalimentaciones, se debe llenar la hoja que se encuentra en el PVG departamental de log de problemas con los siguientes campos:

1. ID Problema
2. Fecha de Identificación
3. Iteración
4. Descripción del Problema
5. Categoría
6. Nombre Stakeholder
7. Severidad
8. Estado
9. Plan de Acción
10. Responsable
11. Fecha de Resolución
12. Verificación de Resolución

La guía nos asegura un seguimiento adecuado a la retroalimentación de los profesores mediante un log estandarizado que documenta detalladamente cada problema, asigna responsabilidades específicas, define planes de acción y verifica la resolución. Esto garantiza una gestión proactiva, responsable y eficiente, promoviendo la mejora continua del proyecto.

Control de cambios

Versión	Cambio realizado	Análisis	Autor	Revisor(es)	Fecha de cambio
v 1.0	Creación de la guía	N/A	Mafer Moreno	Diego Perdomo	11/05/2024
v 2.0	Se actualizan las tablas de métricas para la evaluación del problema	N/A	Olimpia Garcia	Mafer Moreno	16/05/2024
v 3.0	Se añade la sección de retroalimentación asi como la referencia al PVG para el seguimiento.	N/A	Mike Tena		23/05/2024