Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • PEGASO PEGASO
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 13
    • Issues 13
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • imunnic
  • PEGASOPEGASO
  • Wiki
  • 1. Especificación del problema

Last edited by imunnic Mar 03, 2024
Page history

1. Especificación del problema

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.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.

Este proceso suele enmarcarse en unas jornadas específicas que consisten en 3 días laborales(aunque varía según la entidad del ejercicio) 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 de otro ejercicio validando las mismas, eliminándolas o añadiendo algunas en su caso. 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 ni están asociadas a ningún cometido, por lo que no hay forma de relacionar unas con otras de una forma rápida, solamente por el contexto.

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 y personal, detrayéndolo de otros puestos.

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.

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.

  • Equipo MEL/MIL:: Son los encargados de definir, redactar y de que se ejecuten durante el ejercicio las incidencias previstas.

  • Analistas del sistema:

    • Cap. Ignacio Ovidio Muñoz Nicolás
    • Cte. Justo Javier Clemente Hermoso

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.

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.

Debe ser adaptable a cualquier tipo de operación y a cualquier tipo de incidencia.

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.

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 y los contactos posibles partes interesadas sobre el proyecto.

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.

1.6. Planificación inicial

Plazos Etapa
12-13 de marzo Exposición del Estudio de Viabilidad del sistema y de la propuesta de proyecto
Clone repository

Home

  1. Especificación y formulación del problema
  2. Estudio de viabilidad del sistema
    2.1 Mind Map
    2.2 Impact Map
    2.3 Estudio de Alternativas
    2.4 Matriz de Cumplimento de funcionalidades
    2.5 Matriz de decisión
  3. Propuesta de desarrollo
    3.1 Planificación general
    3.2 Diagramas
    3.3 Funcionalidades
    3.4 Interfaz de usuario
    3.5 Producto Mínimo Viable
  4. Desarrollo
    4.1. Marco de trabajo
    4.2. Metodología
    4.3. Historias de usuario
    4.4. Producto
    4.5. Sprint 1
         4.5.1. Sprint Planning
        4.5.2. Sprint Backlog
        4.5.3. Sprint Review
        4.5.4. Sprint Retrospective
    4.6 Sprint 2
        4.6.1 Sprint Planning
        4.6.2 Sprint Backlog
        4.6.3 Sprint Review
        4.6.4 Sprint Retrospective
    Anexo I
    Anexo II