4.3.-Sprint-Review.md

 ## Objetivo del sprint
-Sprint Goal: xxxxx
+
\ No newline at end of file
+_Que los usuarios puedan consultar y dar de alta Modelos, Equipos e Incidencias._
+
+## Estimación y tiempo real empleado en cada tarea:
+Como se puede observar en el [Diagrama de BurnDown](./4.5.-Burndown), se ha ido avanzando en la realización de los distintos trabajos del Sprint Backlog, según lo previsto.
+
+## Actividades realizadas durante el Sprint 1
+Las actividades que se han realizado durante el Sprint 1 corresponden a los items seleccionados del _Product Backlog_. Para una mejor visualización de los elementos en el _board_, se han etiquetado estos elementos como _PBI_ estando los _issues (sprint backlog)_ relacionados el _PBI_ correspondiente:
+
+- #5 Desarrollo de la Librería orientada a interfaces
+    - #13 Desarrollo Interfaz Equipo y clases dependientes
+    - #12 Desarrollo Interfaz Modelo y clases dependientes
+    - #15 Creación entorno eclipse
+    - #16 Creación Interfaz Incidencia y clases dependientes
+
+- #6 Desarrollo del CRUD de la entidad Equipo en la API
+    - #21 Modelos y Assembler entidad Equipo
+    - #22 Controller y repositorio entidad Equipo
+
+- #7 Vista de la entidad Equipo en el Frontend
+    - #31 Listar equipos
+    - #32 Formulario nuevo equipo
+    - #33 Formulario nueva incidencia
+    - #38 Store de equipos
+
+- #8 Desarrollo del CRUD de la entidad Modelo en la API
+    - #17 Modelos y Assembler entidad Modelo
+    - #20 Controler y Repositorio entidad Modelo
+
+- #9 Vista de la entidad Modelo en el Frontend
+    - #14 Configuración del entorno de desarrollo Frontend
+    - #18 Implementación base de la aplicación en el frontend
+    - #19 Barra de navegación y pie de página
+    - #23 Vista de listado de modelos
+    - #28 Formulario de Alta de Modelos
+    - #29 Formatear listado de modelos
+    - #30 Mejoras en listado de modelos
+    - #34 Diseño responsive lista de modelos
+    - #35 Store de Modelos
+    - #36 Servicio API
+    - #44 Actualización de stock en vista de Modelos
+
+- #10 Desarrollo del CRUD de la entidad Incidencia en la API
+    - #24 Modelos y Assembler Entidad Incidencia
+    - #25 Controller y Repositorio entidad Incidencia
+    - #27 Visualización de un modelo
+ 
+- #11 Vista de la entidad Incidencia en el Frontend
+    - #40 Listado de Incicencias
+
+Existen otros elementos _spring backlog_ que no están relacionados con _PBIs_ específicos:
+
+    - #45 Correcciones API
+    - #46 Revisión código
+    - #47 Revisión carga de datos
+    - #48 Corrección de la ordenación con valores nulos o indefinidos
+
+## Actividades pendientes
+Se ha conseguido completar al 100% todas las tareas previstas durante el Sprint _Planning_
+
+
+## Resumen de actividades planeadas y ejecutadas durante el Sprint 1
+Dada la frecuencia de realización de reuniones _daily_ entre los _developers_ y atendiendo a la libertad otorgada a los mismos en cuanto al refinamiento y planificación del _Sprint Backlog_ se ha optado por planificar los _issues_ a corto plazo, en el [Sprint Retrospective](./4.4.-Sprint-Retrospective.md) se explicará el resultado con esta planificación. 
+
+## Próximas actividades
+Tras la finalización del _Sprint 1_, se realizará el _Sprint planning_ correspondiente al _Sprint 2_. Durante este proceso, nos enfocaremos en establecer un objetivo claro y conciso para el Sprint 2, con el propósito siempre de agregar valor al producto. 
+
+
+## Incremento
+Con todo lo realizado durante el Sprint1, se ha completado el 60% del los requisitos previstos en el MVP. Hay que tener en cuenta que la separación de roles no se ha implentado en este sprint, por lo que se han marcado como _done_ los requisitos relacionados con funcionalidades que se pueden hacer tanto con separación de roles como sin ella.
+
+| Id  | Prioridad  | Descripción  | MVP | Sprint 1 |
+| --- | ---------- | ------------ | --- | -------  |
+| RF1 | Alta       | Existirán cuatro roles diferenciados: Administrador Central, Administrador de Unidad, MiembroGC no administrador y Personal Externo (Técnico) | ✔️ |         |
+| RF2 | Alta       | Usuarios administradores centrales podrán de alta nuevo material, categorizado dentro de una de las categorías (subtipos) existentes | ✔️ |   ✔️      |
+| RF3 | Alta       | Los administradores centrales podrán dar de baja o modificar material existente | ✔️ |    ✔️     |
+| RF4 | Alta       | El material se podrá asignar a un usuario (MiembroGC) o a una unidad | ✔️ |         |
+| RF5 | Alta       | Los MiembroGC pertenecerán a una unidad determinada, pudiendo los administradores listar el material que tiene la unidad, bien asignado a la propia unidad, o asignado a alguno de sus usuarios. Los MiembroGC no administrador, solo podrán ver sus materiales | ✔️ |         |
+| RF6 | Media      | Todos los MiembroGC (administrador y no administrador) podrán dar de alta nuevas incidencias, que pueden ser relativas a configuración, avería, extravío o solicitud | ✔️ |   ✔️     |
+| RF7 | Media      | Los Administradores y Técnicos podrán marcar las incidencias como resueltas, o cambiarlas al estado que corresponda | ✔️ |         |
+| RF12 | Alta      | Los Administradores de Unidad podrán visualizar los usuarios de su unidad, así como el material que tienen asignado | ✔️ |         |
+
+### Requisitos No Funcionales
+| Id   | Prioridad  | Descripción  | MVP | Sprint 1 |
+| ---- | ---------- | ------------ | --- | -------  |
+| RNF1 | Alta       | La aplicación debe poseer un diseño que garantice la adecuada visualización en PC, tablets y smartphones | ✔️ |     ✔️    |
+| RNF3 | Alta       | El acceso a la aplicación se realizará a través de protocolos que aseguren la confidencialidad de la información | ✔️ |   ✔️      |
+| RNF4 | Alta       | La interfaz de la aplicación se desarrollará siguiendo las pautas de accesibilidad recogidas en la especificación WCAG 2.1, debiendo seguir, al menos, el nivel A de las directrices que guían cada uno de sus principios (Perceptible, Operable, Comprensible y Robusto) | ✔️ |    ✔️     |