PROYECTO FIN DE CARRERA
SISTEMAS DE CONTROL DE ACCESOS
A EDIFICIOS MEDIANTE TARJETAS
CRIPTOGRÁFICAS Y TARJETAS RFID
AUTOR: MARTA VELAYOS SARDIÑA
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
R
1.
Descripción general del Sistema
El proyecto Sistema de Control de Accesos a Edificios tiene como objetivo estudiar y desarrollar dos tecnologías de control de acceso, basadas en la utilización de tarjetas inteligentes y tarjetas de radiofrecuencia (RFID). Se ha desarrollado un sistema destinado al Instituto de Investigación Tecnológico (IIT) de la Universidad Pontificia Comillas, capaz de realizar dos tipos de controles de seguridad: por un lado, un control de acceso del personal de dicho departamento y por otro lado, un control de inventario.
2.
Aplicación de Control de Visitas
La primera aplicación que constituye el sistema final es Control de Visitas, destinada a registrar las visitas que se realicen en el centro. Este subsisema utiliza la tecnología de tarjetas inteligentes, de manera que se comunica con un lector LTCX conectado al ordenador del usuario final a través de un puerto USB. Control de Visitas tiene como finalidad proporcionar una aplicación que permita al responsable del punto de control llevar a cabo la gestión de las visitas que tengan lugar. Esta gestión consiste en:
Identificar al visitante: A partir de la lectura del carnet de alumno de la Universidad.
Determinar la persona que se quiere visitar: Consiste en seleccionar el nombre del empleado a visitar de una lista obtenida de la base de datos del personal del departamento. En esta lista se proporcionan los campos de la extensión y el despacho donde se puede localizar el empleado en cuestión, y así facilitar su localización.
Confirmar el registro de la visita tratada en la base de datos correspondiente.
3.
Aplicación Control de Inventario
Se ha desarrollado la aplicación de Control de Inventario, destinada a llevar a cabo un seguimiento del estado de los recursos prestables (ordenadores portátiles, cámaras digitales) que proporciona el departamento a sus empleados. La gestión de los préstamos y devoluciones de los recursos se ha implantado con la tecnología de radiofrecuencia, de manera que para realizar este control el sistema se comunica con un lector RFID, conectado al ordenador donde se ejecuta la aplicación a través de un puerto USB. La identificación de los recursos se consigue a partir de las tarjetas RFID que se han asignado a cada uno de los equipos. Cuando se desee registrar un movimiento, se procederá a leer el TAG designado al recurso, y el lector RFID transmitirá los datos de la lectura al sistema, el cual es el responsable de llevar a cabo la gestión correspondiente del movimiento asociado. El sistema se encuentra integrado con la aplicación de “Reservas Online” donde cada empleado puede realizar la reserva del equipo que necesite durante un periodo determinado.
4.
Conclusión
Se han desarrollado dos aplicaciones de control de acceso, las cuales se han implantado utilizando dos tecnologías de identificación diferentes. Las ventajas más importantes que se han conseguido son:
Control de Visitas: Tecnología de tarjetas inteligentes
Agilizar el proceso de registro de las visitas, minimizando considerablemente el tiempo de cómputo que supone, al realizar la lectura de las tarjetas con esta tecnología, incluyendo el caso de que no se disponga del carnet de alumno.
Almacenamiento automático de toda la información relativa a la visita: visitante, visitado, hora…
Ayudar al usuario final proporcionando información relativa a los empleados del departamento: extensión, despacho…
Control de Inventario: Tecnología RFID
Llevar a cabo un seguimiento detallado del estado de los recursos del IIT.
Rápida identificación de los recursos a partir de la lectura RFID de los TAGs.
A
1.
General description of the system
The main aim of Buildings Access Control System’s project is to study and develop two different control access technologies which are based on the use of Smart cards and radiofrecuency ID cards. This system has been developed for the Institute for Research in Technology (IIT) of Pontificia Comillas University, and it is able to perform two types of security access: an access control of the department’s visits, and an inventory control.
2.
Access Control Application
The first application, that forms the final system, is Access Control Application, used to register visits to the building. This subsystem uses the intelligent cards technology, so it has to communicate with a LTCX reader connected to the final user’s computer through a USB port. The purpose of Visits Control is to provide an application that allows the person is in charge of security control point for management. This management consists of: identifying the visitor and registering his/her name.
This is done by:
Determining the person which is visited: It consist of selecting the employ’s name from a list generated form database of personnel. In this list, the phone and room number of the employ are also shown to facilitate contacting with the person to announce the visit.
Confirmation the storage of the visit data into database.
3.
Inventory Control
It has been developed the application Inventory Control which is responsible of monitoring the status of shared resources (portable computers, digital cameras) provided by the IIT department to its employees. The loans and returns’ management has been implemented with the radiofrecuency technology, so to do this kind of control the system has to communicate with a RFID reader, which is connected through a USB port to the computer where the application is running. The resources’ identification is performed with RFID cards attached to each equipment. To register good movements, the RFID reader will read the resource’s TAG, and it will send the information to the system which is responsible for managing that movement. The system is synchronized with a database of reservations where the employees can define which equipment they need and which dates.
4.
Conclusion
Two access control applications have been developed and implemented using two different identification technologies. The main features attained are:
Visit Control: Smart Card Technology
Acceleration the registration process reducing typing to a minimum (only in case the visit doesn’t have an ID card) since ID cards is read using this technology.
Automatically storing in a database all the information related to each visit: visitor’s name, employ visited, date-time.
Help the user during the registration process by providing information about the employees: extension and room number.
Inventory Control: RFID Technology
To carry out a detailed and automated monitoring of the departments’ shared resources.
Faster and accurate identification of the resource by applying RFID technology.
To optimize the manual tasks and business process to reduce the management mistakes. Equipments are identified automatically and the system is
Í
Capítulo
Página
1.
Plan de Gestión del Proyecto
1.1.Introducción
1.2.Definición del proyecto
1.3.Diagrama de Actividades
1.4.Descripción detallada de las Actividades
1.5.Organigrama del equipo de trabajo
1.6.Funcionalidad de los integrantes del equipo de trabajo
1.7.Estimación y presupuesto
1.8.Planificación de alto nivel
1
2 2 3 8 12 13 16 232.
Documento de Conceptos del Sistema
2.1. Objetivos del sistema
2.2. Alcance del sistema
2.3. Tipología de los usuarios finales
2.4. Restricciones 2.5. Antecedentes
24
25 25 28 28 303.
Análisis de Requisitos
3.1. Ámbito del proyecto
3.2. Contexto general del sistema
3.3. Evaluación y análisis
3.4. Modelo Físico
3.5. Modelo Lógico
3.6. Modelo Conceptual de datos
31
32 35 36 47 63 674.
Estudio de la Arquitectura
4.1. Especificación de la tecnología hardware
74
75Capítulo
Página
4.1.1.1. ISO 7816
4.1.1.2. Tipos de Tarjetas Inteligentes 4.1.1.3. Sistema de Ficheros 4.1.1.4. Métodos de Acceso a la TI 4.1.1.5. Lector LTCX 4.1.2. Tecnología RFID 4.1.2.1. Funcionamiento 4.1.2.2. Protocolos y Opciones 4.1.2.3. Etiquetas RFID: TAGS 4.1.2.4. Estándar Mifare
4.1.3. Plataforma donde reside el sistema
4.2. Especificación de la tecnología software y de comunicaciones
4.3. Arquitectura final del sistema
4.4. Evaluación Económica
4.5. Elaboración del Plan de Proyecto
75 79 82 82 85 86 88 89 90 92 93 93 94 95 99
5.
Diseño Externo
5.1. Requisitos físicos del nuevo sistema
5.1.1. Entono operativo del sistema
5.1.2. Configuración hardware/software
5.2. Desarrollo del Modelo Físico Final
5.2.1. Fronteras de Mecanización
5.2.2. Especificación de Procesos
5.2.3. Diseño de Entradas
5.2.4. Diseño de Salidas
5.2.5. Estimación de Volúmenes de Información
5.2.6. Procesos de Control y de Seguridad
102
103 103 108 111 113 116 121 123 124 128Capítulo
Página
6.
Diseño Interno
6.1. Técnicas a utilizar
6.2. Subsistema online
6.2.1. El Diagrama de Cuadros Estructurado (STC)
6.2.2. Derivación del DFD al STC
6.2.3. Consideraciones de diseño
6.3. Diagrama del Sistema
6.4. Cuaderno de Carga
132
134 135 136 139 148 149 1507. Programación
7.1. Análisis y diseño orientado a objetos 7.1.1. Introducción
7.1.2. Ciclo de desarrollo orientado a objetos 7.1.3. Técnicas OO en las fases de la metodología 7.2. Manual de Usuario
7.2.1. Manual de Usuario de Control de Visitas 7.2.2. Manual de Usuario de Control de Inventario
159
161 161 162 163 180 182 1828. Pruebas
183
9. Implantación
188
10. Conclusiones
190
11. Glosario de Términos
193
12. Bibliografía
199
Capítulo
Página
Anexo 1
202
Anexo 2
212
1
1
.
.
P
P
l
l
a
a
n
n
d
d
e
e
G
1.1. Introducción
El presente documento define el Plan de Gestión del proyecto Sistema de Control de
Accesos, PSCA, contemplando los objetivos y alcance del proyecto, la estructura
jerárquica de las actividades principales describiendo una de ellas, la organización del equipo de trabajo especificando la funcionalidad de uno de los perfiles, la estimación y presupuesto, y la planificación determinada para la realización de dicho proyecto.
1.2. Definición del Proyecto
Se desea desarrollar un sistema, destinado al Instituto de Investigación Tecnológico (IIT) de la Universidad Pontificia Comillas (UPCO), capaz de realizar dos tipos de controles de seguridad: por un lado, un control de acceso de visitas de dicho departamento, de manera que facilite la gestión y el registro de las vistas que reciben cada uno de los empleados, tanto de alumnos, como de personas ajenas a la Universidad; y por otro lado, un control de inventario que permita llevar a cabo un seguimiento de los ordenadores portátiles que proporciona el IIT a sus empleados, con el objetivo de que éstos puedan utilizarlos en lugares o contextos externos al dominio de la universidad.
El control de visitas se implantará utilizando la tecnología de tarjetas inteligentes, de forma que cuando se atienda la llegada de una persona en el departamento, se solicitará su carnet de identificación personal para proceder a realizar el registro correspondiente.
Por último, el Control de Inventario se realizará a partir de la utilización de un lector de radiofrecuencia (RFID), de manera que cuando se desee registrar un préstamo o una devolución de alguno de los ordenadores portátiles, proporcionados por el IIT, se deberá mostrar al lector el TAG RFID que posee el recurso, para realizar el proceso de identificación del mismo.
1.3. Diagrama de Actividades
En este apartado se muestran las actividades principales que constituyen el desarrollo del proyecto PSCA, clasificadas por nivel de detalle:
A continuación, se completa el diagrama de Actividades del proyecto Sistema de
Control de Accesos a Edificios, desglosando cada uno de los paquetes en las tareas que
se han de llevar a cabo durante su estudio y desarrollo.
•
Actividad PSCA02
•
Actividad PSCA03.2
•
Actividad PSCA03.4
•
Actividad PSCA03.6
1.4. Descripción detallada de las Actividades
En este punto del plan de gestión se proporciona una breve descripción de los paquetes de trabajo de primer y segundo nivel, según corresponda, que constituyen el desarrollo completo del presente proyecto.
PSCA01.1
REUNIÓN DE LANZAMIENTO
Primera reunión del proyecto entre el alumno y el director. Tiene como objetivo determinar el alcance del proyecto inicial y las pautas que se van a seguir para el desarrollo del mismo.
PSCA01.2
PLAN DE GESTIÓN DEL PROYECTO
Se corresponde con la elaboración del Plan de Gestión del proyecto que se va a llevar a cabo. Dicho plan supone una primera aproximación a los objetivos y alcance del proyecto, y proporciona los diferentes paquetes de trabajo que se han de estudiar y analizar para afrontar el proceso de desarrollo del sistema que se quiere obtener.
PSCA02
GESTIÓN DEL PROYECTO
Paquete de trabajo que tiene como principal finalidad la de realizar un seguimiento continuo del proceso de desarrollo, garantizando que se satisfacen los requisitos establecidos y las restricciones impuestas.
Esta Actividad engloba también la elaboración de la documentación correspondiente a cada una de las etapas que se vayan finalizando, y que en conjunto constituyen el documento final.
PSCA03.1
INDETIFICACIÓN DE NECESIDADES
Tarea que se comporta como soporte a la petición que el director del proyecto realiza para determinar las pautas generales de las necesidades determinadas y del contexto del sistema. La información recogida durante esta etapa se especifica en un Documento de Conceptos del Sistema.
PSCA03.2
ANÁLISIS DE REQUISITOS
El objetivo de este paquete de trabajo es alcanzar un conocimiento suficiente del sistema, definiendo las necesidades, los problemas y requisitos del usuario. Todo ello debe ser expresado mediante dos modelos: de procesos y de datos.
Se obtiene un modelo de procesos físico del sistema, y a partir de él se deduce el modelo de procesos lógico el cual recoge las funciones esenciales del negocio
PSCA03.3
ESTUDIO DE LA ARQUITECTURA
El objetivo de esta Actividad es definir la solución de arquitectura técnica que satisface tanto los requisitos como las restricciones del diseño. La arquitectura debe indicar qué componentes software, hardware y de comunicaciones han de adquirirse o desarrollarse.
La solución deberá dar una visión externa del sistema, los requisitos físicos que se tienen que tener en cuenta, así como los aspectos organizativos, operativos, técnicos y económicos asociados.
PSCA03.4
DISEÑO EXTERNO
En esta etapa se completa la definición de las especificaciones del sistema a mecanizar, obteniéndose el modelo físico final de procesos y el modelo lógico de datos, de acuerdo a la plataforma hardware y software definida en la tarea anterior.
Además, esta Actividad elabora la estrategia que se ha de llevar a cabo en las etapas de Pruebas e Implantación, la formación de los usuarios y las conversiones necesarias de hardware y software del sistema actual al nuevo.
PSCA03.5
DISEÑO INTERNO
Esta tarea identifica y diseña los diversos componentes software del sistema, describiendo detalladamente sus características físicas. Dependiendo de la arquitectura escogida para el desarrollo, estos componentes pueden ser muy diversos. Debido a esta heterogeneidad, el sistema se puede dividir en diversos subsistemas dependiendo de la tipología de los procesos, y así especificar y diseñar sus componentes.
PSCA03.6
PROGRAMACIÓN
El objetivo de este paquete de trabajo es alcanzar la transformación del sistema en un conjunto de programas que puedan ser ejecutados satisfactoriamente bajo unos criterios de calidad. La dificultad se encuentra en cómo realizar la transformación de la mejor manera posible ya que depende en gran medida del lenguaje de programación y de las herramientas software disponibles.
PSCA03.7
PRUEBAS
Desarrollados y probados cada uno de los programas y componentes que constituyen el software, deben realizarse una serie de pruebas para conseguir integrar todo el sistema, de acuerdo al Plan de Pruebas establecido en la etapa de Diseño Interno.
El objetivo global de esta tarea es someter al sistema desarrollado y a sus componentes a una serie de verificaciones encaminadas a garantizar un nivel de fiabilidad aceptable.
PSCA03.8
IMPLANTACIÓN
Después de probar la integridad del software del sistema y especificada su instalación y configuración, se debe instalar el software producido en el entorno de trabajo o Centro de Producción para llevar a cabo la explotación del sistema final. De forma que su objetivo es el de implementar el nuevo sistema en la producción real.
PSCA04
CIERRE DEL PROYECTO
Esta actividad engloba tanto la reunión de aceptación con el director y con el coordinador del proyecto, como l elaboración de una copia tanto de la documentación final como del software que se ha producido. A su vez, se debe proporcionar un resumen de todo el proyecto que se almacenará en el sistema de documentación de la universidad.
1.5. Organigrama del equipo de trabajo
El equipo de trabajo del proyecto que se va a realizar, está formado por cuatro participantes claramente diferenciados. Por un lado, se han definido las entidades del director y del coordinador del proyecto, los cuales son las personas responsables de controlar y verificar el correcto desarrollo del proyecto, siendo la figura del director mucho más importante debido a su mayor grado de implicación en el mismo.
La figura del alumno se corresponde con la persona destinada a estudiar, diseñar y desarrollar el proyecto propuesto por el director. Durante todo el proceso de desarrollo, el alumno deberá reunirse con el director, ya sea para las reuniones iniciales, como para verificar todo el trabajo que se haya realizado hasta ese momento, relación muy diferente a la existente con el coordinador, ya que sólo se realizarán dos o tres reuniones a lo largo del ciclo de vida del proyecto.
Por último, el alumno deberá relacionarse con el usuario final de la aplicación para consolidar aspectos de diseño o mejoras del mismo, así como otros aspectos no funcionales.
1.6. Funcionalidad de los integrantes del equipo de trabajo
En el siguiente punto se recoge la funcionalidad que desempeña el perfil del coordinador en el equipo de trabajo definido en el apartado anterior.
Director del Proyecto: DPFC
La labor del Director del proyecto consiste principalmente en conseguir que el alumno desarrolle un PFC de calidad, ayudándole desde el punto de vista técnico y funcional y motivándole para que cumpla los plazos establecidos. El Director podrá ser un Profesor de la Escuela de Ingeniería o un ingeniero (o titulado superior) normalmente en ejercicio de la profesión que haya mostrado interés por un proyecto determinado.
El Director es responsable de:
• Proponer un proyecto con calidad suficiente y establecer los objetivos y el alcance del mismo.
• Facilitar al alumno las orientaciones adecuadas ante los problemas que puedan ir surgiendo en el desarrollo del proyecto. Esto no implica que el director o tutor del proyecto resuelva los problemas ya que se está examinando la capacidad del alumno para hacerles frente.
• Supervisar la realización del proyecto, la calidad de sus contenidos, y verificar que se desarrolla de acuerdo con las normas establecidas, consultando con el Coordinador de Proyectos las posibles dudas que le puedan surgir.
• Dar su opinión sobre el alumno y el trabajo realizado rellenando el formulario elaborado al efecto y entregándoselo al correspondiente Coordinador.
En general ningún director podrá dirigir más de 8 proyectos distintos en el mismo curso académico, las excepciones a esta regla deberán ser autorizadas por el Coordinador General.
Coordinador del Proyecto: CPFC
Cada Coordinador será responsable de la calificación de los proyectos que coordina. A principio de curso cada Coordinador deberá pasar a su correspondiente Jefatura de Estudios, informando al Coordinador General, la lista de los alumnos coordinados por él, para que desde Jefatura se soliciten las correspondientes actas. Cada Coordinador tendrá asignada una hora semanal en el horario para realizar el seguimiento de los alumnos y proyectos.
Las tareas asignadas a cada Coordinador son:
• Buscar proyecto-director a los alumnos que no tengan ningún proyecto asignado.
• Concretar la definición del proyecto.
• Recoger solicitudes de alumnos para cada proyecto.
• Asignar a cada alumno su proyecto.
• Presentar alumno/a al director del proyecto.
• Controlar/supervisar el trabajo de cada alumno, con el director del proyecto (al menos 2 veces por proyecto).
• Comunicarse con el alumno para supervisar ritmo e incidencias (al menos 2 veces por proyecto).
• Recoger y evaluar el proyecto finalizado, rechazando los que no alcancen un determinado nivel o presenten defectos de forma. Finalizado el proyecto, el alumno entregará al Coordinador un ejemplar visado por su director de proyecto, junto con un resumen. (En las titulaciones de informática, para el examen de Reválida, el alumno llevará, junto con el material que considere necesario para realizar la exposición de su proyecto, otros DOS ejemplares de su Proyecto).
• Calificar a los alumnos y firmar las actas, como profesor de esta asignatura. Una vez calificado cada proyecto será devuelto al alumno con el visado del Coordinador y el alumno lo deberá entregar junto con una copia del resumen en Secretaría General en el momento de realizar la matrícula de Reválida.
Alumno del Proyecto: APFC
El alumno ha de realizar las siguientes tareas propuestas y evaluadas por el Coordinador de Proyectos:
• El Coordinador de proyectos debe dar el visto bueno a cada proyecto, incluso cuando sean proyectos propuestos por profesores u otros coordinadores de la Escuela. Con el visto bueno del Coordinador el alumno puede comenzar su proyecto oficialmente y debe proceder a realizar las tareas que le corresponden. Todos los proyectos deberán tener el visto bueno del correspondiente Coordinador, a más tardar en la última semana del mes de Octubre.
• Cada alumno deberá preparar de común acuerdo con su director de proyecto un documento que describa el Proyecto a realizar siguiendo el formato que se adjunta en el Anexo B. La memoria descriptiva se entregará antes de hacer la primera presentación. El Coordinador fijará una fecha para la entrega de la memoria, siendo en la última semana del mes de Noviembre la más tardía.
• El seguimiento del proyecto se realizará a través de la clase semanal planificada. Durante estas sesiones el alumno de acuerdo con la programación establecida por el coordinador deberá presentar los objetivos, el plan de trabajo y los avances realizados en su proyecto.
• Durante el segundo y tercer trimestre del curso el alumno hará dos exposiciones públicas de avance de su proyecto. En general, se realizarán una exposición de avance y otra a la finalización del trabajo.
• El alumno debe asistir al menos al 50% de las clases de la asignatura.
1.7. Estimación y Presupuesto
A partir de la jerarquía de Actividades diseñada en el punto 1.3 se va a realizar un estudio de la asignación de recursos para el desarrollo del proyecto. Dicha asignación permitirá estimar el presupuesto correspondiente al proceso de diseño del sistema final.
Estimación de recursos
La estimación realizada sólo tiene en cuenta los paquetes de trabajo descritos en el apartado 1.4 ya que permiten tener una perspectiva lo suficientemente detallada como para poder estudiar la evolución del proceso de desarrollo y asignar las horas/hombre que se consideren necesarias para cada Actividad.
Antes de realizar la red Pert correspondiente a los niveles considerados de la EDT, se lleva a cabo un estudio de la relación temporal entre las Actividades. Dicha relación permitirá entender la evolución del progreso de desarrollo de los paquetes de trabajo, al igual que la definición de las duraciones de cada uno de ellos.
La relación temporal muestra los requerimientos de inicio de una Actividad, en el sentido de determinar qué Actividad ha de estar finalizada antes de comenzar el desarrollo de la siguiente.
Los requisitos temporales existentes para llevar a cabo las Actividades que constituyen el nivel 1 y 2 de la EDT son los siguientes:
Paquete de Trabajo
Actividad Predecesora
Duración
PSCA01.1 No tiene 1 día (0’033 meses)
PSCA01.2 PSCA01.1 5 días (0’2 meses)
PSCA02 PSCA01.2 270 días (9 meses)
PSCA03.1 PSCA01.2 15 días (0’5 meses)
PSCA03.2 PSCA03.1 15 días (0’5 meses)
PSCA03.3 PSCA03.2 30 días (1 mes)
PSCA03.4 PSCA03.3 15 días (0’5 meses)
PSCA03.5 PSCA03.4 30 días (1 mes)
PSCA03.6 PSCA03.5 75 días (2’5 meses)
PSCA03.7 PSCA03.6 15 días (0’5 meses)
PSCA03.8 PSCA03.7 15 días (0’5 meses)
PSCA04 PSCA02 , PSCA03.8 2 días (0’067 meses)
Se ha considerado que cada semana tiene 7 días laborables, valorándose la duración de cada Actividad tanto en días como en meses.
Con el objetivo de realizar un estudio detallado de la asignación de recursos, se ha diseñado primeramente la Red Pert correspondiente a la EDT del proyecto de gestión, de forma que se pueda calcular cual es el camino crítico y los márgenes de las Actividades que presenten una cierta flexibilidad entre las fechas de inicio y fin del
La Red Pert a su vez permitirá definir las fechas de inicio y finalización de cada uno de los paquetes de trabajo, satisfaciendo la relación temporal entre ellas y la fecha de entrega del proyecto final.
La flexibilidad que presenten determinadas Actividades proporcionará la posibilidad de cambiar su organización inicial de tal forma que se garantice un desarrollo del proyecto uniforme desde el punto de vista de la asignación de recursos, en este caso de las horas/hombre que se han de dedicar en cada una de dichas Actividades.
La Red Pert correspondiente a este proyecto de gestión, valorando la duración en días, es la siguiente:
El camino crítico del proyecto lo constituyen las actividades de gestión: las dos primeras etapas de inicio y elaboración del Plan de Gestión, la propia Actividad de Gestión global del proceso de desarrollo y la tarea de Cierre del Proyecto.
La asignación del número de horas/hombre que se van a trabajar en cada uno de los paquetes de trabajo es la que se adjunta en la siguiente tabla:
1 2 3 4 5 6 7 8 9 TOT PSCA01.1 CPFC 1 1 DPFC 3 3 APFC 3 3 PSCA01.2 CPFC DPFC 2 2 APFC 20 20 PSCA02 CPFC 10 10 DPFC 20 10 10 10 10 10 10 10 90 APFC 10 30 20 20 20 20 20 10 10 160 PSCA03.1 CPFC DPFC 10 10 APFC 30 30 PSCA03.2 CPFC DPFC APFC 30 30 PSCA03.3 CPFC DPFC 10 10 APFC 80 80 TOTAL 109 140 30 30 30 30 30 20 30 449
1 2 3 4 5 6 7 8 9 TOT PSCA03.4 CPFC 1 1 DPFC 10 10 APFC 80 80 PSCA03.5 CPFC DPFC 5 5 10 APFC 20 60 80 PSCA03.6 CPFC DPFC 30 30 APFC 50 80 80 210 PSCA03.7 CPFC DPFC 10 10 APFC 30 30 PSCA03.8 CPFC DPFC 10 10 APFC 30 30 PSCA04 CPFC 25 25 DPFC 25 25 APFC 20 20 TOTAL1 109 140 30 30 30 30 30 20 30 449 TOTAL 109 140 146 95 110 110 110 100 100 1020
El número total de horas/hombre que se ha estimado dedicar en todo el proyecto es de 1020 horas, teniendo en cuenta el trabajo realizado por el director y por el coordinador
Para tener una visión general de la evolución de la dedicación a lo largo del proyecto, se han representado las horas/hombre que se han estimado trabajar por cada uno de los meses que constituyen la duración completa del proyecto:
Se puede observar que entre el primer mes y el tercero hay un incremento constante del número de horas a trabajar debido a que se pretenden finalizar cinco etapas del desarrollo más la documentación correspondiente de cada una de ellas.
Tras el primer trimestre se produce un descenso considerable de la dedicación debido a que se corresponde con el momento de preparación de los exámenes de febrero y de dedicación para terminar las prácticas finales del primer periodo del curso.
La etapa final del proyecto, correspondiente a los últimos cuatro meses, se caracteriza por ser mucho más uniforme el esfuerzo que hay que emplear para realizar las tres últimas etapas del desarrollo.
Calculadas las horas de trabajo a emplear, a continuación se realiza el estudio del presupuesto inicial que se asigna al proyecto.
Estudio del Presupuesto
El coste total del trabajo realizado por los integrantes del equipo de trabajo del proyecto es el que se muestra en la siguiente tabla:
INTEGRANTE HORAS/HOMBRE €/HORA TOTAL
CPFC 37 60 2220
DPFC 210 60 12600
APFC 773 30 23190
TOTAL 38010
Por tanto, si consideramos el coste de los recursos software o hardware que se han adquirido para realiza el proyecto además del coste total del equipo de trabajo, obtenemos el presupuesto inicial estimado para el desarrollo del proyecto:
Recurso
Total €
Subtotal Equipo de trabajo: 38010
Lector Inteligente 200 Lector RFID 300 Tags RFID 50 Desplazamiento 300 Comunicaciones 200 Subtotal recursos: 1050 Total Final 39060
1.8. Planificación de alto nivel
La planificación que determina el desarrollo y evolución del proyecto Sistema de Control de Accesos, se muestra a continuación:
2
2
.
.
D
D
o
o
c
c
u
u
m
m
e
e
n
n
t
t
o
o
d
d
e
e
C
C
o
o
n
n
c
c
e
e
p
p
t
t
o
o
s
s
d
d
e
e
l
l
S
S
i
i
s
s
t
t
e
e
m
m
a
a
2.1. Objetivos del sistema
Se desea desarrollar un sistema, destinado al Instituto de Investigación Tecnológico (IIT) de la Universidad Pontificia Comillas (UPCO), capaz de realizar dos tipos de controles de seguridad: por un lado, un control de acceso del personal de dicho departamento, de manera que facilite la gestión y el registro de las vistas que reciben cada uno de los empleados, tanto de alumnos, como de personas ajenas a la Universidad; y por otro lado, un control de inventario que permita llevar a cabo un seguimiento de los ordenadores portátiles que proporciona el IIT a sus empleados, con el objetivo de que éstos puedan utilizarlos en lugares o contextos externos al dominio de la universidad.
2.2. Alcance del sistema
El Sistema Control de Accesos a Edificios requiere la definición de dos funciones de negocio claramente diferenciadas entre sí:
Control de Visitas
Se requiere de un Control de Visitas que permita consultar en cualquier momento el listado de qué empleados se encuentran en el edificio, y a su vez, identificar a las personas que solicitan ser atendidas por un miembro particular del departamento del IIT.
Todas las visitas deberán ser recogidas en la correspondiente base de datos, facilitando el registro, además de los alumnos que desean ser atendidos por un profesor de dicho departamento, el de aquellas personas que no disponen de la identificación de la Universidad, y que por tanto, son ajenas a la misma.
El Sistema Control de Visitas deberá proporcionar, si es posible, las últimas visitas que haya realizado en otros momentos la persona identificada, de forma que facilite la
Control de Inventario
Paralelamente, se desea realizar un control de los ordenadores portátiles y de otro tipo de recursos, como por ejemplo cámaras fotográficas, que el IIT proporciona a sus empleados para que éstos puedan utilizarlos en ámbitos externos a la Universidad.
Dicho control se realizará a partir de la gestión de las entradas y salidas del material suministrado, así como de la identificación y registro de las personas que deseen utilizar o recoger dicho recurso.
Además, el sistema de Control de Inventario debe estar integrado con un sistema de reservas previamente existente: “Reservas Online”.
Recopilación y carga de datos
El sistema debe tener acceso a las BBDD que recogen todos los datos sobre el personal que trabaja en el departamento IIT, información referente a las visitas que han sido registradas con anterioridad, así como de los recursos informáticos que se encuentran disponibles y la información de reservas para el Control de Inventario.
Cada visitante y personal del IIT quedarán perfectamente definidos mediante una serie de datos personales que definen su perfil, de acuerdo al diseño de las tablas que constituyen las BBDD creadas para la gestión deseada.
Del mismo modo, el control que se realizará sobre los ordenadores portátiles permitirá conocer en cada momento qué recurso está disponible o cuándo ha de ser devuelto y por quién, de manera que todos los movimientos sobre dicho material quede recogido en la base de datos para conseguir un seguimiento eficiente de los mismos.
Acceso a la información
Su misión es, la de dotar al sistema de las herramientas necesarias para proporcionar las diferentes funcionalidades que requiere el usuario final, el vigilante, a la hora de realizar los controles de seguridad. El papel que desempeña el usuario solo adopta especial importancia cuando se realiza el control de acceso de los visitantes. El vigilante es la persona encargada de introducir la tarjeta en el lector y de seleccionar el empleado del departamento a visitar, y cuando se gestiona un movimiento asociado a un recurso que implica la lectura del TAG RFID y su confirmación para poder registrarlo en la correspondiente base de datos para poder actualizar el estado del recurso.
Administración y control del entorno
Tiene como objetivo la gestión de los datos y de los procesos tratados por el sistema. Para ello, se contará con la figura de un administrador que se corresponde con el usuario final, el cual es el responsable de llevar a cabo los controles de acceso a través de la ejecución de las aplicaciones correspondientes y de la manipulación de los lectores utilizados para la lectura de las tarjetas de identificación. Sin embargo, la información almacenada que maneja el sistema no requiere de un control como tal ya que no puede ser manipulada directamente por el usuario final ni por otra persona ajena a la utilización del sistema. Es la propia aplicación la que lleva a cabo las operaciones contra las bases de datos correspondientes y porque éstas residen en un servidor al que sólo se puede acceder, en principio, como administrador del mismo.
El perfil del usuario final se corresponde con una persona que trabaja en la universidad Comillas, y que se encuentra en la recepción del edificio, controlando las llegadas, tanto de personas como de documentos.
2.3. Tipología de los usuarios finales
Los usuarios del sistema, serán exclusivamente las personas que trabajan en Comillas, encargadas de controlar y gestionar los acontecimientos diarios que se produzcan en la universidad, así como de afrontar y comunicar cualquier problema o incidencia que tenga lugar.
En cada uno de los edificios que constituyen la universidad Comillas, se encuentran varias personas que se corresponden con este perfil, y que gracias a ellas se puede llevar a cabo una importante administración y gestión de todo lo que ocurre en cada uno de los edificios referenciados. Sin embargo, sólo vamos a tener en cuenta el edificio donde se encuentra el departamento del IIT, el cual es el destino del sistema que se va a desarrollar, y por tanto, los usuarios de mismo, serán las personas que se adecuen al perfil indicado que tengan que trabajar en el IIT.
2.4. Restricciones
El sistema que se ha de diseñar debe ser capaz de controlar dos tipos de accesos: el de visitas y el de recursos prestables. Para ello, se ha decidido desarrollar dos aplicaciones, bajo el lenguaje de programación Java, que se encarguen de gestionar y registrar los accesos que se realicen en un momento dado en cada uno de los dos contextos determinados.
Ambas aplicaciones deben estar sincronizadas en tiempo real con el servidor de bases de datos, de manera que sea coherente la información del personal que pertenece al departamento con la almacenada en la base de datos, así como la referente al material que se proporciona.
Para llevar a cabo el control de acceso de las visitas es necesario que el sistema este conectado con un lector de tarjetas inteligentes del tipo LTCX, de forma que será necesario implantar las librerías y funciones adecuadas para que la aplicación Java sea
Al mismo tiempo, la aplicación deberá proporcionar dos funciones adicionales:
• Por un lado, la posibilidad de “Introducir datos a mano”, situación que se corresponde con la llegada de un visitante que no posee su tarjeta en el momento de la gestión del acceso, o con una persona que no es un alumno de la universidad. En este caso, el administrador deberá introducir el nombre y los apellidos del visitante por teclado, e indicar a que persona de la plantilla del IIT viene a visitar. El registro de este tipo de visitas se realizará de la misma forma que si se hubiese registrado con una tarjeta inteligente.
• Opción de “Consulta”. Se ofrece la posibilidad de generar un informes de visitas a partir de un volcado de la base de datos a un archivo excel.
El control de inventario se realizará bajo la tecnología RFID, de manera que se asignará un tag RFID a cada uno de los recursos que constituyen el inmovilizado prestable que proporciona el IIT.
Cuando una persona de dicho departamento desee llevarse un recurso, deberá identificarse, y si cumple las condiciones de autentificación, se procederá a determinar el tipo de movimiento que se va a. Si se confirma el préstamo o la devolución, se registrará la entrada o salida del recurso, según corresponda, y se actualizará su estado de disponibilidad.
Adicionalmente, se contempla la escritura en el TAG de incidencias que alteren la utilización de un recurso, bien porque este dañado físicamente, o las condiciones con que se realiza un préstamo del mismo.
Al mismo tiempo, se ha de tener en cuenta una restricción de tipo económico, ya que los recursos del proyecto necesarios para implantar el sistema en el IIT están financiados por la universidad.
2.5. Antecedentes
El departamento del IIT dispone de un proyecto base que contempla la realización del control de acceso del personal al edificio, de forma que se utilizará como punto de partida para el diseño del Control de Visitas, con el objetivo de optimizar y refinar su comportamiento.
Por otro lado, dicho departamento dispone de un lector de tarjetas situado a la entrada del edificio, pero su funcionalidad se limita exclusivamente a la apertura de la puerta principal tras introducir la tarjeta de empleado. Dicho control de acceso no permite llevar a cabo un seguimiento de la presencia del personal en el edificio, ni de los horarios que se cumplen cada día, de manera que no facilita la gestión de las visitas, y mucho menos, el control de las personas que entran y salen del edificio.
3
3
.
.
A
A
n
n
á
á
l
l
i
i
s
s
i
i
s
s
d
3.1. Ámbito del proyecto
Lectura de tarjetas inteligentes
El primer objetivo consiste en conseguir leer información de tarjetas inteligentes para poder implantar una aplicación de ayuda a los vigilantes de un edificio para realizar el registro de las visitas (descrita más adelante). Se trata de una aplicación Java capaz de leer tarjetas inteligentes, de manera que pueda manipular y almacenar los datos recogidos de cada una de ellas.
Se utilizará un lector estándar de tarjetas inteligentes que se corresponden con las tarjetas de identificación que tiene la Universidad. Para alcanzar este objetivo se parte del código desarrollado en un proyecto fin de carrera del año anterior.
Lectura de tarjetas RFID
Debido a la gran aceptación que esta experimentando la tecnología RFID, cada vez es más frecuente la utilización de lectores y tarjetas RFID para realizar diferentes tareas, como por ejemplo la implantación de los controles de acceso.
Las tarjetas RFID se consideran como una alternativa que sustituirá el empleo de códigos de barras debido a las ventajas que proporciona la tecnología RFID, destacando entre ellas la mayor longitud de los códigos de identificación, los cuales permiten que a cada etiqueta se le pueda asignar uno único, mientras que los códigos UPC actuales, se limitan a un código para identificar a todas la unidades de un producto en particular.
En este sentido los códigos RFID equivalen más al número de serie de un equipo que al número de referencia del producto, pero un número de serie que sigue un formato compatible entre todos los fabricantes.
El proyecto Sistema Control de Accesos contempla el diseño de una aplicación, en principio en Java, destinada a interactuar con tarjetas RFID, de manera que por un lado se realice una lectura de las mismas para poder efectuar un seguimiento de los objetos controlados, y por otro su escritura, permitiendo la asignación de identificadores unívocos, así como la introducción de información descriptiva del objeto al cual va a identificar.
Comunicar el sistema con las bases de datos
Se han de diseñar las bases de datos necesarias para realizar el almacenamiento de la información recogida en las lecturas de las tarjetas de identificación. Así mismo, las bases de datos complementarán la funcionalidad de la aplicaciones que se van a diseñar.
Para ello, se dispone de un servidor Solaris/MySQL donde residirán las bases de datos que requiere el sistema. Debido a que cada aplicación maneja un tipo de información, será necesario crear diferentes bases de datos, de manera que se pueda facilitar el mantenimiento de las mismas, así como garantizar la coherencia de los datos almacenados.
De la misma forma, se han de diseñar y crear las tablas que constituyen cada base de datos, estudiando los campos que van a contener cada una de ellas, como las restricciones respecto a los valores que pueden tomar, incluidos los valores por defecto, para así conseguir la coherencia tanto en el diseño como en el significado de cada uno de los registros recogidos.
Desarrollo de las aplicaciones de control de acceso
La primera parte del proyecto consiste en terminar de programar y poner en funcionamiento una aplicación base de control de acceso denominada Control de
Un prototipo de dicha aplicación fue desarrollado en otro proyecto fin de carrera, sin embargo requiere la incorporación de nuevos servicios y la mejora de los ya existentes para proporcionar de forma eficiente su funcionalidad, así como el perfeccionamiento del diseño inicial para proporcionar un interfaz lo suficientemente explicativo e intuitivo. La aplicación se desarrollará bajo el lenguaje de programación Java, y se encargará de gestionar las visitas que recibe el personal del departamento de la universidad IIT.
En el caso de visitas de alumnos, el registro de la visita requiere los datos personales del alumno en particular, los cuales se consiguen mediante la lectura de la tarjeta de la universidad, y los de la persona a la que viene a visitar. De esta forma, los registros de visitas antiguos de un alumno en particular, permitirán agilizar el trámite de la nueva visita que realice ya que lo más probable es que solicite ver a las mismas personas que en ocasiones anteriores.
En la segunda parte del proyecto, se ha optado por el diseño de una aplicación que permita obtener el máximo rendimiento de las diferentes ventajas que proporciona la tecnología RFID. Por ello, se contempla la realización de un Control de Inventario destinado a llevar a cabo un seguimiento de los recursos que proporciona el departamento, así como la gestión de los movimientos asociados que se produzcan.
Para ello, se asignará a cada uno de los recursos del departamento un TAG RFID, de manera que cuando tenga lugar su entrada o salida se podrá llevar a cabo su identificación y la gestión de su movimiento asociado. Cuando se confirme un determinado movimiento se registrará en la bases de datos correspondiente, y se actualizará el estado del recurso con el objetivo de conocer en todo momento su disponibilidad. Los movimientos pueden ser de dos tipos: préstamos y devoluciones. El tratamiento de los préstamos determina la necesidad de que esta aplicación RFID se integre con otro sistema destinado a realizar reservas de recursos con antelación, de manera que se gestionan tanto préstamos reservados con anterioridad como en un momento dado.
3.2. Contexto general del sistema
El contexto general del sistema debe contemplar la interacción del sistema con el usuario, con otros sistemas mecanizados o manuales, o con las posibles bases de datos existentes. El contexto general correspondiente al Sistema de Control de Accesos a
Edificios se recoge en el siguiente diagrama:
El sistema recibirá la información de entrada a través de los lectores que se encontrarán conectados en la estación de trabajo del usuario final, en este caso el bedel del departamento del IIT.
Seguidamente, el sistema determinará la operación a realizar, en función de los parámetros de entrada, y si se requiere, solicitará al servidor los datos de gestión, almacenados con anterioridad, que se proporcionarán como información de salida en el punto de atención. El sistema también interaccionará con el servidor donde residen las BBDD, cuando tenga que realizar un registro, ya sea de una visita como del estado un recurso, generando como flujo de salida la correcta finalización de la operación o lo que se considere más conveniente.
3.3. Evaluación y análisis
Ante la descripción del problema que se ha realizado en los apartados anteriores, el siguiente punto que se ha de abordar es el de evaluar la información recogida y sintetizarla para obtener el modelo de la situación del sistema que se desea alcanzar. Para ello, se han de estudiar tres aspectos claves:
3.3.1. Flujo de la información
En este apartado se definen las entradas y salidas del sistema. Como flujo de entrada, el sistema recibirá los datos correspondientes a las lecturas que se lleven a cabo a través tanto del lector de tarjetas inteligentes, como del lector RFID. También, el sistema recogerá información del servidor de base de datos cuando deba mostrar datos relevantes para continuar con la operación del control de acceso, como por ejemplo proporcionar los datos de toda la plantilla del IIT, o las descripciones y el estado actual de cada uno de los recursos.
Como flujo de salida el sistema proporcionará un código de retorno que informará sobre el resultado de la operación que se haya realizado. Sólo se generará flujo de información de salida como tal, cuando en Control de Inventario se almacenan cada uno de los movimientos que se gestionan tras su confirmación, o cuando se desea escribir en el TAG RFID asociado una breve descripción de algún aspecto que haya que recordar del recurso en futuros préstamos, por ejemplo un deterioro físico de alguno de sus componentes, o si en un préstamo no se han llevado un elemento que forma parte del recurso entregado, por ejemplo un periférico como un ratón
3.3.2. Estructura de la información
Se entiende por estructura al contenido de los flujos de información, con el detalle suficiente como para comprender la actuación del proceso que transforma un flujo en otro u otros.
Estructura de la Información de Control de Visitas
Los flujos de información que se generan durante un proceso de lectura son los siguientes:
Nombre: FLUJO-ENTRADA-LECTOR Identificador: PSCAFD.CV1
* CADENA: String de bits enviados por el lector cuando se introduce una tarjeta inteligente en el mismo. A partir de dicha cadena de caracteres se determinan el código de identificación, el nombre y los apellidos del alumno.
Nombre: FLUJO-LECTURA Identificador: PSCAFD. CV 2
* ID-ALUMNO: Código asignado a cada alumno cuando comienza sus estudios en la Universidad UPCO.
* NOMBRE: Nombre del alumno identificado.
Nombre: FLUJO-PERSONAL Identificador: PSCAFD. CV 3
* ID-EMPLEADO: Identificador asignado a cada uno de los empleados del IIT.
* NOMBRE: Nombre del empleado.
* APELLIDOS: Apellidos del empleado.
* EXTENSIÓN: Extensión telefónica del personal en cuestión.
* PLANTA: Planta del edificio del departamento donde se encuentra el despacho del empleado.
* PUESTO: Número de despacho del personal al que se hace referencia.
Nombre: FLUJO-VISITAS Identificador: PSCAFD. CV 4
Nombre: FLUJO-REGISTRO-VISITANTE Identificador: PSCAFD. CV 5
* FECHA-ACTUAL: Fecha de registro de la visita realizada por ID-ALUMNO a ID-EMPLEADO.
Estructura de la Información de Control de Inventario
Los flujos de información que se generan durante el proceso de gestión de los recursos del departamento son los que se describen a continuación:
Nombre: FLUJO-RFID Identificador: PSCAFD.CI1
* TRAMA: String de bits enviados por el lector al sistema cuando detecta, identifica y lee una tarjeta RFID. La trama queda definida por el identificador RFID del TAG y por el mensaje que se encuentra almacenado en uno de los bloques de la memoria interna de la tarjeta identificada.
Nombre: FLUJO-RECURSO Identificador: PSCAFD.CI2
* ID-ITEM: Identificador asignado a cada uno de los recursos del departamento disponibles para ser utilizados por cualquier empleado del mismo.
* CARACTERISTICAS: Descripción explícita de los atributos más relevantes que definen el recurso.
* DISPOSICIÓN: Estado actual en que se encuentra el recurso, P prestable, o D pendiente de devolución.
* ID-RFID: Identificador de la tarjeta asignada de manera única a cada uno de los recursos que se van a gestionar.
Nombre: FLUJO-RESERVA Identificador: PSCAFD.CI3
* ID: Identificador de la reserva.
Nombre: FLUJO-RESERVA (Cont) Identificador: PSCAFD.CI3
* DESDE-DIA: Día para el cual está previsto realizar la entrega del recurso reservado, es decir, día en que se lleva a cabo el préstamo.
* DESDE-HORA: Representa la hora del día “DESDE-DIA” en que el usuario recogerá el recurso.
* HASTA-DIA: Día para el cual está previsto realizar la devolución del recurso que se ha prestado.
* HASTA-HORA: Representa la hora del día “HASTA-DIA” en que el usuario devolverá el recurso.
* COM: Comentario que describe el motivo de la reserva.
* WHO: Identifica al empleado que realiza la reserva.
* DIA-RESERVA: Representa el día junto con la hora en que el usuario confirmó la reserva del recurso.
Nombre: FLUJO-EMPLEADO Identificador: PSCAFD.CI4
* ID-EMPLEADO: Identificador asignado a cada una de las personas que trabajan en el IIT.
* NOMBRE: Nombre del empleado.
* APELLIDOS: Apellidos del empleado.
Nombre: FLUJO-PRESTAMO Identificador: PSCAFD.CI5
* ID-ITEM: Identificador del recurso sobre el que se esta realizando el préstamo.
* ID-EMPLEADO: Identificador de la persona que realiza el préstamo.
* ESTADO: Identifica el tipo de movimiento del préstamo, si es una entrega o una devolución de un recurso.
Nombre: FLUJO-INST Identificador: PSCAFD.CI6
Flujo generado cuando una persona solicita un recurso no habiendo reservado con anterioridad, de forma que se registra el préstamo en el momento que se realiza la entrega.
3.3.3. Todas las funciones
Las funciones necesarias para llevar a cabo el Control de Visitas son las siguientes:
• Configurar la comunicación con el lector: Cuando se ejecute por primera vez la aplicación, se procederá a asignar un terminal de comunicación con el lector a partir de la asignación de un slot particular del mismo.
• Esperar lectura: La aplicación ha de permanecer en espera activa hasta que se introduzca una tarjeta en el lector para proceder a su identificación.
• Leer tarjetas: Cuando el usuario introduzca una tarjeta en el lector LTCX, éste enviará una cadena de caracteres al sistema, el cual tendrá que realizar la lectura para obtener el identificador del alumno propietario de la tarjeta, así como su nombre y apellidos.
• Identificar personal ajeno a la universidad Comillas: Cuando se presente en el departamento una persona que no dispone de carnet de alumno, se le asignará un identificador especial, de forma que tras haber facilitado sus datos personales, se pueda llevar a cabo el registro de la visita que desea realizar.
• Consultar personal del departamento: Se proporcionan los datos de todas las personas que forman parte del departamento del IIT de Comillas: nombre, despacho y teléfono.
• Consultar visitas anteriores: Tras la identificación del visitante, se proporcionan las últimas diez visitas que han sido registradas y protagonizadas por el mismo. Esto permite obtener una lista de personal reducida que resulta muy útil ya que suelen repetirse las visitas de los alumnos a los mismos profesores.
• Registrar visitante: Se almacena en la tabla LOG_VISITAS el identificador del visitante junto con sus datos personales.
• Registrar visita: Se realiza un registro de la visita en la tabla VISITANTES, definida dicha visita por el identificador del visitante y del empleado, junto con la fecha actual.
• Proporcionar ayuda: En tiempo real, la aplicación proporcionará una opción de ayuda sobre la funcionalidad de la misma.
• Finalizar la aplicación: se suministrarán dos formas de cerrar la aplicación, bien a través de la opción de Archivo
Salir, o pulsando sobre el icono de cierre de la
• Registrar visitas adicional: Opción que se activará cuando, por motivos externos, no se puede ejecutar la aplicación, de manera que se pueda llevar a cabo el seguimiento de las visitas que se vayan a realizar durante el tiempo que perdure el problema.
Los diferentes servicios que definen detalladamente la funcionalidad y finalidad del Control de Inventario son los siguientes:
• Mostrar el estado actual de los recursos del departamento: Se proporciona para cada uno de los recursos información sobre su disponibilidad para ser prestado, o en caso contrario, para ser devuelto, indicando en este caso el usuario del mismo.
• Esperar el registro de un movimiento: La aplicación deberá permanecer en espera hasta que se aproxime un TAG al lector cuando se desee gestionar un movimiento de entrada o de salida del departamento.
• Identificar un recurso: Cuando el lector RFID detecte un TAG le enviará a la aplicación el identificador del mismo, determinando ésta el recurso al que se está haciendo referencia.
• Integrar la aplicación con el sistema de Reservas Online para que Control de Inventario pueda gestionar correctamente, con la información necesaria, aquellos préstamos que hayan sido reservados con antelación.
• Proporcionar la información de las reservas asociadas a un recurso: Cuando un recurso sea identificado se mostrará la reserva más próxima al momento actual del mismo, de forma que si el equipo está libre en ese momento, se podrá realizar una reserva instantánea teniendo en cuenta la fecha del préstamo de la siguiente reserva más cercana.
• Registrar el préstamo de un recurso con reserva: La aplicación permitirá el registro de una entrega tras mostrar la reserva asociada al recurso. En ese caso, el usuario escogerá la opción de “registrar el préstamo” proporcionando toda la información relativa al mismo, sin posibilidad de cambios, finalizando el movimiento en el momento en que el usuario lo confirme.
• Registrar el préstamo de un recurso sin reserva: Cuando un recurso esté disponible para ser prestado en un momento dado, se podrá realizar la entrega siempre que se respete la fecha del préstamo de la siguiente reserva, como se ha comentado con anterioridad. Por ello, cuando el recurso sea identificado se mostrará su reserva más cercana, si existe, en cuyo caso se determinará la fecha mas tardía de devolución de dicho recurso a través de una ventana de diálogo, donde el usuario deberá de confirmar además otros campos que definen el préstamo.
• Registrar la devolución de un recurso: El usuario de un recurso puede devolverlo en la fecha acordada o antes. En el caso de que el recurso se devuelve con antelación, se deberán actualizar los datos de la reserva para marcar el recurso como libre y que puede ser reservado por otro usuario.
• Recoger información adicional sobe el estado del préstamo: Se ofrece la posibilidad de recoger información acerca de las condiciones en que se entrega el recurso, por ejemplo sin ratón, sin maletín…Esta información se registrará en el TAG RFID de forma que cuando se devuelva el recurso se conozcan las condiciones en que se llevó a cabo la entrega.
• Finalizar la aplicación: La terminación de la aplicación requiere la intervención del usuario, de manera que se le ofrece la posibilidad de finalizarla cuando desee o cuando lo considere necesario.
3.4. Modelo Físico
3.4.1 Modelo Físico de Control de Visitas
Contexto del subsistema
El sistema Control de Visitas se encuentra conectado con un lector de tarjetas inteligentes, con el que se comunica inicialmente para realizar la configuración del lector, y a través del cual recibe la información de la tarjeta leída en forma de una cadena de caracteres. El usuario interactúa con el sistema arrancando y cerrando la aplicación, así como confirmando el registro de las visitas. A su vez, el usuario es el responsable de introducir la tarjeta en el lector.
Diagrama de Contexto
El Contexto del sistema se determina mediante un gráfico de presentación, donde aparece el Sistema de Control de Visitas, el usuario y la entidad externa correspondiente al lector de tarjetas inteligentes.
A continuación se proporciona una descripción de cada uno de los objetos presentes en el diagrama anterior (diccionario de datos), de manera que facilite la comprensión del contexto del sistema.
Diagrama de Contexto: PSCADFD0
Objeto: Entidad Lector LTCX
Identificador: PSCADFD0.E1
El lector de tarjetas inteligentes se comunicará con el sistema en dos situaciones claramente diferenciadas: por un lado para el envío de información de configuración, ya sea para establecer el terminal como para apagarlo; y el segundo contexto es para la transmisión de la información leída de las tarjetas
