Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GearSolid GearSolid
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 3
    • Issues 3
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • 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
  • GuerreroDIM46
  • GearSolidGearSolid
  • Wiki
    • Documentacion
  • Análisis del problema

Análisis del problema · Changes

Page history
Construccion del esqueleto authored Feb 22, 2024 by GuerreroDIM46's avatar GuerreroDIM46
Show whitespace changes
Inline Side-by-side
Showing with 89 additions and 0 deletions
+89 -0
  • Documentacion/Análisis-del-problema.md Documentacion/Análisis-del-problema.md +89 -0
  • No files found.
Documentacion/Análisis-del-problema.md 0 → 100644
View page @ 5173db56
# Descripción de la situación actual
Nuestro cliente cuenta con un Centro de Procesamiento de Datos (CPD) que recibe un importante número de visitas semanales por parte de personal externo, principalmente de empresas subcontratadas, para la realización de las tareas comunes de mantenimiento de instalaciones y sistemas.
La política de seguridad implantada por la empresa cliente exige que todo personal ajeno a la organización, previo a su acceso al CPD, cuente con la correspondiente autorización.
En la actualidad, el proceso de autorización para el acceso físico a las instalaciones se realiza a través de un rudimentario procedimiento en el que se combinan el correo electrónico y la reproducción en papel de las autorizaciones.
![Procedimiento de autorización de acceso](./images/procedimiento_actual.png)
Con el procedimiento establecido, cuando se planifica una nueva visita, el responsable del sistema o equipo en el que se va a intervenir, debe rellenar un formulario (documento excel) con la información del personal externo, indicando sus datos personales, actividad a realizar, así como la fecha y hora de entrada/salida.
Posteriormente, dicho formulario debe enviarse por correo electrónico a la Jefatura para conocimiento y supervisión, que la reenvía al Área de Seguridad.
Por su parte, el Área de Seguridad imprime una copia en papel del formulario autorizado para cada uno de los puestos de control, quedando registrado en carpetas hasta el momento en que caduca la autorización, tras lo cual se destruye.
 
---
# Actores implicados
En este proyecto intervienen los siguientes actores:
- **Cliente**: JST.
- **Product Owner**: Comandante Carlos A. Moreno Pérez (@Camope).
- **Developer**: Comandante Walid Embeya (@walid-embeya).
- **Scrum Master (Tutores)**: Profesores del departamento SIC.
 
---
# Objetivos y alcance del sistema
El procedimiento actual para el control de visitantes presenta varios inconvenientes.
En primer lugar, es un mecanismo complejo y laborioso que no se adapta al elevado número de visitas. Además, es propenso a sufrir fallos, lo que ha provocado que se impida el paso a personas para las que se había solicitado el acceso, bien porque se ha producido alguna interrupción en algún punto de la cadena de transmisión de la información, o bien porque se han extraviado las copias impresas de la autorización.
Por otro lado, la gestión de los accesos es muy lenta, requiriendo un mínimo de 24 horas de antelación antes de la visita, los que supone un problema para intervenciones de carácter más urgente.
La aplicación, destinada a subsanar las deficiencias actuales, tendrá como objetivos:
- **Simplificar el procedimiento** de gestión de visitas centralizándolo en una única aplicación.
- Permitir la **consulta y verificación** de los visitantes a través de la aplicación, eliminando la necesidad de contar con copias en papel.
- Disponer de un **histórico de visitas** con fines de auditoría.
- Llevar un **registro de visitantes**, que evite tener que completar todos sus datos si ya está dado de alta en el sistema.
- Facilitar la delegación de la responsabilidades mediante la aplicación de **roles de usuario**.
A pesar de que el proyecto nace de la necesidad que el cliente tiene de controlar el acceso físico a su CPD, se contemplará que su alcance incluya el control de acceso físico para cualquier tipo de instalación o recinto.
 
---
# Restricciones
Para este proyecto se han identificado las siguientes restricciones:
- **Tiempo**: La fecha establecida para finalizar el desarrollo del MVP es el 20 de junio de 2023.
- **Recursos**: El Product Owner y el Developer del proyecto serán alumnos del XLV Curso DIM durante su fase de formación.
- **Entorno**: El entorno de desarrollo y pruebas se basa en servicios gratuitos alojados en Internet, sobre los que no existe garantía de disponibilidad.
- **Legislación**: No está previsto el uso de datos personales (reales) durante las fases de concepto y preproducción. No obstante, si en algún momento se utilizasen datos de carácter personal, sería necesario ajustarse a la LOPD y a las normas que la desarrollan.
 
---
# Planificación inicial
La planificación inicial de este proyecto contempla las siguientes entregas:
1. Exposición del EVS, ERS y MVP (11 de abril de 2023)
2. Entrega del Sprint 1 (16 de mayo de 2023)
3. Entrega del Sprint 2 (20 de junio de 2023)
 
---
[Volver arriba](#)
[home](./home)
\ No newline at end of file
Clone repository

Home


Fase de concepto (Presentación)

1. Estudio de Viabilidad del Sistema (EVS)

  • Análisis del problema
  • Mind Map
  • Impact Map
  • Requisitos
  • Alternativas
  • Matriz de Cumplimiento de Requisitos
  • Matriz de decisión

2. Especificación de Requisitos de Software (ERS)

  • Planificación General
  • Diagrama de Casos de Uso y Modelo de Dominio
  • Interfaz de Usuario

3. Producto Mínimo Viable (MVP)

  • Definición del MVP

Preproducción

1. Sprint 1

2. Sprint 2