Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • P PANACEA
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • 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
  • dgutlop
  • PANACEA
  • Wiki
  • 1.5. Alcance y limitaciones

1.5. Alcance y limitaciones · Changes

Page history
ACTUALIZACIÓN DOC 08OCT authored Oct 08, 2026 by Agustin Martin Arranz's avatar Agustin Martin Arranz
Hide whitespace changes
Inline Side-by-side
Showing with 4 additions and 38 deletions
+4 -38
  • 1.5.-Alcance-y-limitaciones.md 1.5.-Alcance-y-limitaciones.md +4 -38
  • No files found.
1.5.-Alcance-y-limitaciones.md
View page @ 97f81c35
El alcance del sistema abarca la cadena completa de gestión del apoyo sanitario El alcance del sistema abarca la cadena funcional de gestión de los apoyos sanitarios en el Ejército de Tierra. Esta cadena se articula desde las **Unidades, Centros y Organismos (UCO)**, como origen de las actividades y propietarias orgánicas de los recursos sanitarios, pasando por los **Servicios Médicos de Referencia (SMR)**, los **Núcleos de Apoyo Sanitario (NAS)** y la **Brigada Logística (BRILOG)**, hasta alcanzar, cuando resulte necesario, a la **Dirección de Sanidad (DISAN)**.
en el ET. El elemento superior es la **DISAN**, desde la cual, pasando por la
**BRILOG**, los **NAS**, los **SMR** y las **unidades dependientes** de los mismos,
se articula toda la estructura de gestión de recursos sanitarios. Adicionalmente,
**FUTER** queda incluida en el sistema en calidad de observador, dado su interés
en la visualización global de los recursos para la planificación de las actividades.
En lo relativo a los **recursos**, el sistema aborda tanto los recursos humanos En lo relativo a los **recursos**, el sistema aborda tanto los recursos humanos como los materiales. En cuanto a los recursos humanos, se contemplan los **médicos** y **enfermeros** destinados en las unidades con recursos sanitarios orgánicos. En lo referente a los recursos materiales, el alcance queda limitado a las ambulancias de tipo *Soporte Vital Básico* (**SVB**) y *Soporte Vital Avanzado* (**SVA**).
como los materiales. En cuanto a los recursos humanos, se contemplan los
**médicos** y **enfermeros** destinados en las unidades con recursos sanitarios
orgánicos. En lo referente a los recursos materiales, el alcance queda limitado
a las ambulancias de tipo *Soporte Vital Básico* (**SVB**) y *Soporte Vital
Avanzado* (**SVA**).
En lo que respecta a la **gestión de la información de los recursos**, se estudió La gestión de la información de los recursos contempla la integración con sistemas corporativos existentes. **SIPERDEF** se considera la fuente de los datos orgánicos y de personal que correspondan, mientras que **SIGLE** proporcionará los datos relativos a los recursos materiales que se determinen.
la posibilidad de conectar el sistema con las plataformas de gestión superiores
del ET: **SIGLE** para los recursos materiales y **SIPERDEF** para los recursos
humanos. Sin embargo, tras el análisis conjunto con el usuario final de la
aplicación, se determinó que dicha integración no es apropiada por las
siguientes razones:
En cuanto a **SIPERDEF**, la estructura orgánica que refleja no se corresponde Quedan fuera del **alcance del MVP** aquellas funcionalidades cuya definición o implantación requiera información todavía no disponible o desarrollos adicionales no necesarios para validar el núcleo funcional del sistema. Entre ellas se encuentran, entre otras, la automatización de criterios geográficos o de tiempos de desplazamiento, determinadas capacidades asociadas a niveles jerárquicos superiores y otras funcionalidades expresamente identificadas como evoluciones posteriores.
con la de las unidades sanitarias. Una UCO de tipo batallón puede tener \ No newline at end of file
destinados enfermeros pero no médicos, lo que impediría asignar un médico a
una actividad aun cuando el escalón superior —la brigada— sí disponga de
ellos destinados en su CG. Además, SIPERDEF únicamente recoge situaciones
de baja médica, vacaciones, asuntos propios, licencias y excedencias, sin
contemplar otras circunstancias que impidan la disponibilidad real del personal,
como comisiones de servicio, guardias, salientes de guardia, enfermedad
puntual u otros cometidos de mayor prioridad.
En cuanto a **SIGLE**, se presenta una problemática análoga con los recursos
materiales: si la información no se actualiza correctamente y en tiempo real, se
corre el riesgo de contabilizar como disponible una ambulancia que no se
encuentra operativa.
Por todo ello, y teniendo en cuenta que el volumen de personal y material
sanitario a registrar por cada unidad no es elevado, se determina que el alta
de los recursos se realizará directamente en la aplicación por parte del actor
**Unidad**, quedando este como responsable del mantenimiento y actualización
de la información en el sistema.
\ No newline at end of file
Clone repository

Logo PANACEA

PANACEA

🏠 Inicio

📑 Índice


  1. Especificación y formulación del problema

    • 1.1.- Introducción
    • 1.2.- Definición del problema
    • 1.3.- Descripción del proceso actual
    • 1.4.- Actores
    • 1.5.- Alcance y limitaciones
    • 1.6.- Analistas
  2. Estudio de viabilidad del sistema (EVS)

    • 2.1.- Mind Map
    • 2.2.- Impact Map
    • 2.3.- Historias de usuario
    • 2.4.- Estudio de Alternativas
      • 2.4.1.- HESTIA
      • 2.4.2.- SUMMA112
      • 2.4.3.- PANACEA
    • 2.5.- Cumplimiento de impactos
    • 2.6.- Decisión
    • 2.7.- Exposición EVS
  3. Especificación de Requisitos Software (ERS)

    • 3.1.- Planificación
    • 3.2.- Requisitos
    • 3.3.- Diagramas
    • 3.4.- Modelos
    • 3.5.- BPMN
    • 3.6.- Exposición ERS
  4. Producto Mínimo Viable

    • 4.1.- Product Backlog
    • 4.2.- Producto Mínimo Viable
    • 4.3.- Exposición MVP