imunnic · 50b3d502
Hide whitespace changes
Inline Side-by-side

Showing with 8 additions and 113 deletions

1.-Especificación-del-problema.md 1.-Especificación-del-problema.md +8 -113

No files found.
--- a/1.-Especificación-del-problema.md
+++ b/1.-Especificación-del-problema.md
-## Índice
- [Índice](#índice)
- [Introducción](#introducción)
- [1. Descripción del proceso actual](#1-descripción-del-proceso-actual)
- [2. Identifiación de actores implicados.](#2-identifiación-de-actores-implicados)
- [3. Planteamiento inicial](#3-planteamiento-inicial)
- [4. Alcance](#4-alcance)
- [5. Posibles restricciones al proyecto](#5-posibles-restricciones-al-proyecto)
- [6. Planificación inicial](#6-planificación-inicial)
 ## Introducción
 Los ejercicios tipo CPX permiten a las unidades adiestrar sus puestos de mando. Como todos los ejercicios, tienen unos objetivos de adiestramiento concretos que se pretenden alcanzar durante el ejercicio, una audiencia principal, que serían los puestos de mando y una audiencia secundaria, que serían las unidades subordinadas a la audiencia principal. Para poder verificar que se han alcanzado los objetivos de adiestramiento, se necesita plantear una serie de incidentes o sucesos que ocuran durante la ejecución de la OPORD. Estos incidentes se definen en unas jornadas expresas para que sean acordes a los objetivos que se plantean y a los cometidos que tienen las unidadades. El principal producto de estas jornadas es una lista de todos los incidentes posibles de la operación, denominada MEL/MIL (Main Event List/Main Incident List). 
-## 1. Descripción del proceso actual
+## 1.1. Descripción del proceso actual
 La definición de las MEL/MIL es un proceso que se realiza durante unas jornadas donde el DIREX del ejercicio junto con el equipo MEL/MIL, reforzado con personal de las unidades de LOWCON, redacta un listado de incidentes que pueden ocurrir durante la operación. Ese listado, normalmente, se basa en listados de otros ejercicios parecidos y se adaptan las distintas incidencias, pero en todos los casos, hay que revisar incidencia a incidencia comprobando sobre qué cometido actúa y así saber si sirve para alcanzar el objetivo de adiestramiento o debe desecharse.
@@ -24,7 +12,7 @@ El listado final debe adaptarse en un documento ".xslx" para que el DIREX pueda
 Lo ideal sería reducir al máximo este tiempo y el personal utilizado de forma que la definición de este listado implique únicamente al equipo MEL/MIL y no más tiempo de una jornada laboral. De esta forma podrían aprovecharse mejor el tiempo y los recursos.
-## 2. Identifiación de actores implicados.
+## 1.2. Identifiación de actores implicados.
 Se consideran los siguientes actores implicados:
 - **_DIREX_:**  Es quien debe aprobar aprobar las MEL/MIL revisando un informe/borrador de incidencias que se vayan a producir durante el ejercicio.
@@ -35,17 +23,17 @@ Se consideran los siguientes actores implicados:
    - Cap. Ignacio Ovidio Muñoz Nicolás
    - Cte. Justo Javier Clemente Hermoso
-## 3. Planteamiento inicial
+## 1.3. Planteamiento inicial
 Debe facilitarse una solución que conecte los cometidos a las unidades subordinadas en la operación con los distintos incidentes que puedan existir. Una vez hecho esto, la definición de las incidencias no consistirá más que en coger la OPORD, seleccionar los cometidos que se van a ejecutar tal como indica en la misma y con ello se generará un informe que permita al DIREX conocer todas las incidencias que pueden tener lugar para comprobar que se puedan alcanzar los objetivos de adiestramiento.
-## 4. Alcance
+## 1.4. Alcance
 El alcance abarca a todos los equipos DIREX que tengan el cometido de organizar un ejercicio CPX donde se deban evaluar objetivos de adiestramiento que requieran de incidencias para verificar que se han alcanzado.
 De la misma forma abarca a cualquier tipo de ejercicio CPX o no que se quiera utilizar, puesto que la simulación de incidencias se realiza también en ejercicios tipo LIVEX.
-## 5. Posibles restricciones al proyecto
+## 1.5. Posibles restricciones al proyecto
 **Tiempo:** El tiempo disponible es de dos meses para el desarrollo del MVP, hasta la primera semana de junio de 2024.
@@ -55,105 +43,12 @@ De la misma forma abarca a cualquier tipo de ejercicio CPX o no que se quiera ut
 **Entorno:** Hay herramientas para el desarrollo que todavía no se han estudiado, y aunque se estudiarán durante el proceso, pueden presentar una restricción.
-## 6. Planificación inicial
+## 1.6. Planificación inicial
 |       **Plazos**       |             **Etapa**              |
 |:----------------------:|:----------------------------------:|
 |12-13 de marzo | Exposición EVS, ERS y definición MVP        |
-|2-26 abril  | Sprint 1|
+<!-- |2-26 abril  | Sprint 1|
 |29-30 abril|Exposición Sprint 1|                         
 |6-31 mayo  | Sprint 2|
-|5-6 junio|Exposición Sprint 2 - Entrega final|   
+|5-6 junio|Exposición Sprint 2 - Entrega final|    -->
-<!-- 
-## 1. Descripción del proceso actual
-Actualmente la gestión de recursos materiales en la Guardia Civil se lleva a cabo a través de la herramienta ALFIL (Aplicación Logística y Financiera Integral), desarrollada a partir de la integración de dos módulos SAP ERP. Esta herramienta presenta varias ventajas entre las que cabría destacar su flexibilidad, ya que permite inventariar y gestionar el mantenimiento de un equipamiento tan dispar como puede ser la hélice de una aeronave, una pistola o un teléfono móvil, pudiendo ser configurado para incorporar prácticamente cualquier tipo de activo a su inventario.
-En general, aunque costoso en términos económicos, el nivel de satisfacción obtenido de ALFIL ha sido el esperado, cubriendo la mayor parte de las necesidades de la Guardia Civil en lo que respecta a la gestión logística de los recursos. Sin embargo, en los últimos años, producto de la ejecución del Contrato Global de Comunicaciones, se han incrementado considerablemente el volumen de equipamiento tecnológico, en muchos casos de dotación individual, que demanda una gestión más ágil, dinámica y descentralizada que no puede satisfacerse a través de la solución actual.
-Como se ha comentado anteriormente, ALFIL es una herramienta potente y flexible que, sin embargo, no está exenta de inconvenientes. Es precisamente su flexibilidad (sirve para todo tipo de material o equipamiento), lo que ha provocado que sea compleja en su uso, contando con un elevado número de opciones y menús, haciéndola accesible solamente a usuarios con un adecuado nivel de formación. No obstante, el mayor problema se encuentra en su elevado coste por licencia (de carácter unipersonales), suponiendo un factor limitante en cuanto al número de usuarios que pueden utilizarla.
-Hasta la fecha, el uso de ALFIL ha estado limitado a un reducido número de usuarios dentro de unidades de entidad Comandancia o similar, sobre los que se concentra la gestión del inventario y mantenimiento del volumen importante de equipamiento asignado a las unidades y personal dependientes de ella, lo que consume una parte importante de su labor diaria. Esta situación se ha visto agravada por la incorporación de un nuevo equipamiento tecnológico que demanda, en muchos casos, actividades de mantenimiento y soporte más ágiles e inmediatas, a las que el esquema actual no puede hacer frente.
-Con la solución actual, cualquier incidencia (cambio de configuración, avería o extravío) de un dispositivo debe ser comunicada, por correo oficial, además de a sus escalones superiores, al GATI de la Comandancia o Unidad competente, quien la da de alta en ALFIL y, en función del tipo, decide y selecciona el órgano resolutor de la misma. Esto sopone una sobrecarga de trabajo para el GATI y una ralentización en la prestación de soporte que, en ciertos casos, debe prestarse con la mayor celeridad posible, como en el caso de la pérdida de un teléfono móvil, tablet u ordenador portátil, donde es crítico preservar la seguiridad de la información mediante un bloqueo y, en su caso, un borrado remoto del dispositivo.
-![Tratamiento actual de incidencias](img/esquema_actual.png)
-Por último, también cabe destacar como un inconveniente de ALFIL que está implementada para que la titularidad de los recursos materiales se asocien a entidades de tipo Unidad. Esto supone un problema a la hora de hacer un seguimiento del equipamiento de dotación individual, ya que no es posible acceder directamente a la información sobre el titular de un equipo.
-[Volver arriba](#índice)
-## 2. Identificación de actores implicados
-Se consideran los siguientes actores con relevancia:
- **_Scrum Master_:** Cap. Juan Jesús Díaz Gómez.
- **_Product Owner_:** Tte. Alejandro González Escobar.  
- **_Developers_:** 
-    - Cte. Carlos Andrés Moreno Pérez (@camope)
-    - Cap. Tomás Carrasco del Rey (@samotcarrasco). 
- **_Tutores_:**
-    - Tcol. José Antonio Porta Canales
-    - Tte. Alejandro González Escobar
- **_Stakeholders_:**
-    - Administrador Central (Cte. J. Gutiérrez)
-    - Administradores de Unidad (Sto. Torremocha)
-    - Usuarios finales de equipos
-[Volver arriba](#índice)
-## 3. Planteamiento inicial
-En el [documento de solicitud de prácticas](docs/Solicitud_practica_TELECO_Curso_DIM_45.pdf), se recogen como objetivos generales que debe cumplir la aplicación los siguientes:
-+ Se pretende llevar a cabo el análisis, diseño e implementación de una herramienta que permita controlar en todo momento saber a quién se ha entregado cada equipo.
-+ Dicha herramienta podrá gestionar problemas y requerimientos del equipamiento.
-+ Tendrá al menos una vista para el Servicio de Telecomunicaciones y otra vista diferente para los encargados del equipamiento de las unidades periféricas.
-Tras las reuniones con el Product Owner también se han incorporado como objetivos del sistema los siguientes:
-+ Dispondrá de una vista para los usuarios finales a través de la que podrán consultar el equipamiento que tienen asignado, así como gestionar las incidencias del mismo.
-+ Existirá una vista para personal externo mediante la que podrán realizar funciones de soporte, atendiendo aquellas incidencias que se determinen de acuerdo a un perfil.
-[Volver arriba](#índice)
-## 4. Alcance del sistema
-El alcance abarca a todos las unidades y usuarios finales que tengan asignados alguno de estos dispositivos. En el caso de los usuarios, pueden estar o no encuadrados dentro de cualquier unidad dentro o fuera del territorio español.
-Por otra parte, el Servicio de Telecomunicaciones, como Unidad Central, también forma parte del sistema.
-[Volver arriba](#índice)
-## 5. Posibles restricciones del proyecto
-**Tiempo:** Se dispone de plazo para la elaboración de un MVP de aproximadamente dos meses, hasta finales de noviembre de 2023.  
-**Recursos:** Al componerse el _Scrum Team_ solamente de dos _developers_, esto puede suponer una restricción, ya que acometer este proyecto con más garantías supondría disponer de más personas
-**Entorno:** Se tiene previsto su despliegue en preproducción en servicios Cloud, tales como [Back4pp](https://www.back4app.com/) y [Netlify](https://www.netlify.com/). Esto no supondría una restricción más allá de las consideraciones a tener en cuenta respecto de los datos de prueba a utilizar.
-**Legislación:** Debe tomarse en cuenta la necesidad de mantenerse dentro del margen legal en cuanto a [Ley de Protección de Datos Personales](https://www.boe.es/buscar/pdf/2018/BOE-A-2018-16673-consolidado.pdf). 
-[Volver arriba](#índice)
-## 6. Planificación inicial de las etapas del proyecto
-Se marcan los siguientes plazos para la captura de requisitos y elaboración del EVS y ERS:
-|       **Plazos**       |             **Etapa**              |
-|:----------------------:|:----------------------------------:|
-|21 de septiembre | Exposición Fase de Concepto y definición MVP        |
-|23 de octubre  | Sprint 1                           
-|20 de noviembre  | Sprint 2. Finalización del MVP   -->