| Nombre |
Rol |
| Raymundo |
Dueño de la guía |
| Charlie |
Autor |
- Asegurar la preparación del entorno de verificación.
| Atributo |
Descripción |
| Petición |
Programada. |
| Input |
Sesión de inspección de código. |
| Precondiciones |
El código debe estar terminado y funcionando. |
| Los inspectores deben tener acceso al repositorio del proyecto. |
| Los inspectores deben tener acceso a la matriz de trazabilidad. |
| Herramienta |
Reporte de inspección de código. |
| Actividades |
Revisar el código siguiendo la Checklist de Inspección. |
| Documentar los defectos encontrados en el código. |
| Output |
Resumen de la inspección |
| Historial de defectos |
| Postcondiciones |
Los defectos deben documentarse en el Backlog de defectos. |
| Roles |
Autor del código = Atiende las dudas de los inspectores. |
|
Moderador = Dirige el curso de la inspección. |
|
Asistente = Cronometra el tiempo de la inspección. |
|
Inspector = Rellena el Reporte de inspección. |
| Atributo |
Descripción |
| Petición |
A demanda. |
| Input |
Pull Request en repositorio del equipo |
| Precondiciones |
El código debe estar terminado y funcionando. |
| La pareja verificadora debe tener acceso al repositorio del proyecto. |
| La pareja verificadora debe tener acceso a la matriz de trazabilidad. |
| Herramienta |
Reporte de Pair Review. |
| Actividades |
Revisar el código siguiendo la Checklist de Frontend y Backend. |
| Documentar los defectos encontrados en el código. |
| Output |
Reporte de Pair Review rellenado |
| Pull Request aprobado/rechazado |
| Postcondiciones |
Los defectos deben documentarse en el Backlog de defectos. |
| Roles |
La pareja decide si revisar y documentar a la vez o asignarse roles para realizar cada una. |
NO SE RECOMIENDA verificar código de diferentes historias de usuario porque puede generar confusión y un desarrollo en cascada que va en contra de los principios del desarrollo ágil.
versión 2.0