imunnicProduct Goal
El Product Goal para este proyecto es tener un portal que permita la gestión de las MEL/MIL de un ejercicio tipo CPX.
Product Backlog
La pila de trabajo es el conjunto de hitos que se deben alcanzar para completar el desarrollo. Es un documento vivo que se actualiza y se modifica en función de la retroalimentación del cliente y las observaciones del equipo Scrum. Dentro del product backlog los elementos del mismo se encuentran priorizados de forma que se pueda alcanzar el lo más rápido posible el objetivo de negocio. Para extraer los elementos del product backlog se han utilizado las historias de usuario anteriormente definidas.
| Item | Descripción | Valor que aporta | Criterio de aceptación | Historia de usuario |
|---|---|---|---|---|
| PBI-01 | Ver incidencias | Poder redactar más rápido las MEL/MIL | Según Historia de usuario | UH-3 |
| PBI-02 | Ver cometidos | Poder redactar más rápido las MEL/MIL | Según Historia de usuario | UH-3 |
| PBI-03 | Gestionar incidencias | Poder redactar más rápido las MEL/MIL | Según Historia de usuario | UH-3 |
| PBI-04 | Gestionar cometidos | Poder redactar más rápido las MEL/MIL | Según Historia de usuario | UH-3 |
| PBI-05 | Poder seleccionar los cometidos para la operación de manera sencilla | Poder redactar más rápido las MEL/MIL | Según Historia de usuario | UH-3 |
| PBI-06 | Poder seleccionar incidencias dentro de las que pueden ocurrir en cada cometido | Poder redactar más rápido las MEL/MIL | Según Historia de usuario | UH-3 |
| PBI-07 | Poder ver la selección de cometidos e incidencias | Poder validar más rápido las MEL/MIL | Según Historia de usuario | UH-2 |
| PBI-08 | Facilitar el acceso a los datos de las MEL/MIL de distintos ejercicios | Poder disponer de acceso centralizado a los ejercicios | Según Historia de usuario | UH-1 |
| PBI-09 | Organizar los cometidos según saltos | Poder validar más rápido las MEL/MIL | Según Historia de usuario | UH-2 |
| PBI-10 | Mostrar los cometidos con la unidad que ejecuta | Poder validar más rápido las MEL/MIL | Según Historia de usuario | UH-2 |
| PBI-11 | Mostrar un resumen de las incidencias que tiene cada unidad | Poder validar más rápido las MEL/MIL | Según Historia de usuario | UH-2 |
| PBI-12 | Generar un archivo que pueda ser importado desde JEMM | Poder realizar más rápido la carga de incidencias en el sistema JEMM | Según Historia de usuario | UH-4 |
Calidad - DoD
Para el primer Sprint y siguientes (salvo que se observe necesaria su revisión en la Srpint Retrospective) se considerará que el software generado cumple la Definición de Hecho y, por lo tanto, se convierta en un incremento, cuando:
- El código está documentado.
- El código sigue la guía de estilo de google.
- El código esté limpio (sin código muerto ni de depuración).
- El código se encuentra ordenado según el siguiente esquema:
- Directorio raiz del código
- frontend
- gradle
- src
- build.gradle
- Otros archivos en raiz
- Directorio raiz del código
- El código haya sido revisado por un desarrollador distinto al que lo generó.
- Se haya comprobado el correcto funcionamiento de la aplicación en los tres principales navegadores(Firefox, Chrome y Edge).
- Se haya comprobado la correcta visualización en pantallas de formato pequeño, mediano y grande.
- Al usuario se le sugiere el contenido de los campos a rellenar
- Se avisa al usuario de los errores de conexión con datos externos(por ejemplo la api)
- Deben estar previstas las restricciones de la base de datos
- La aplicación debe ser compatible con varios sistemas operativos, incluyendo Windows, macOS, Linux.