|
|
|
## Í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 todos los incidentes sean acordes a los objetivos que se plantean, en los que se define una lista de todos ellos, denominada MEL/MIL (Main Event List/Main Incident List).
|
|
|
|
|
|
|
|
## 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 para ver sobre qué cometido actúa y saber si sirve para el objetivo de adiestramiento o no.
|
|
|
|
|
|
|
|
Este proceso suele enmarcarse en unas jornadas específicas que consisten en 3 días laborales en las que al final el DIREX debe aprobar el listado de MEL/MIL. Para ello el equipo MEL/MIL se coordina y distribuye todas las incidencias de un listado anterior para ver si son o no válidas, añadir alguna si es necesaria o modificarla. Para ello, normalmente se distribuye por unidades en el ejercicio y se comprueba que en los cometidos que tienen asignados para los distintos saltos, puedan prodcirse las incidencias planteadas. El problema principal es que las incidencias no se definen en base a cometidos estándar, por lo que no se pueden agrupar y seleccionar solo las específicas para los cometidos que se busca.
|
|
|
|
|
|
|
|
El listado final debe adaptarse en un documento ".xslx" para que el DIREX pueda ver el total, y en el caso de que el ejercicio cuente con licencias para el uso de JEMM, el listado debe transcribirse, incidencia por incidencia a JEMM. El resultado son tres días intensos de trabajo donde se invierten muchas horas de trabajo de un personal que también tiene otros cometidos en los que invertir horas de trabajo.
|
|
|
|
|
|
|
|
Lo ideal sería reducir al máximo este tiempo y el personal utilizado de forma que la definición de este listado implique no más personal que el equipo MEL/MIL y no más tiempo que una jornada laboral. De esta forma podrían aprovecharse mejor el tiempo y los recursos.
|
|
|
|
|
|
|
|
## 2. Identifiación de actores implicados.
|
|
|
|
Se consideran los siguientes actores implicados:
|
|
|
|
|
|
|
|
- **_Scrum Master_:** XXXXX XXXXXXX XXXXXXXXXXXXX
|
|
|
|
|
|
|
|
- **_Product Owner_:** Cap. Ignacio Ovidio Muñoz Nicolás
|
|
|
|
|
|
|
|
- **_Developers_:** Cte. Justo Javier Clemente Hermoso
|
|
|
|
|
|
|
|
- **_Stakeholders_:**
|
|
|
|
- TBD
|
|
|
|
- TBD
|
|
|
|
|
|
|
|
## 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 va a ejecutar y con ello se generará un informe que permita al DIREX conocer todas las incidencias van a tener lugar para comprobar que se puedan alcanzar los objetivos de adiestramiento.
|
|
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
|
|
**Poca comunicación con el cliente:** La propuesta de la práctica parte del propio alumno, por lo que no hay un cliente identificado más allá de la experiencia personal sobre el proceso en el mismo.
|
|
|
|
|
|
|
|
**Recursos:** El equipo de desarrollo cuenta de un componente, por lo que, sumado al tiempo y al resto de tareas a las que dedicar tiempo es una limitación en sí misma.
|
|
|
|
|
|
|
|
**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
|
|
|
|
|
|
|
|
| **Plazos** | **Etapa** |
|
|
|
|
|:----------------------:|:----------------------------------:|
|
|
|
|
|12-13 de marzo | Exposición EVS, ERS y definición MVP |
|
|
|
|
|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|
|
|
|
|
<!--
|
|
|
|
## 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 --> |