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

Last edited by Xavier Guerrero Mar 03, 2024
Page history
This is an old version of this page. You can view the most recent version or browse the history.

Análisis del problema

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

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

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