estudio de viabilidad y prototipo del control de...
TRANSCRIPT
1
ESTUDIO DE VIABILIDAD Y PROTOTIPO DEL CONTROL DE ACCESO DE LA UNIVERSIDAD CATÓLICA DE PEREIRA CON TECNOLOGIA RFID
ANDRÉS FELIPE VALLEJO PIEDRAHITA
JUAN SEBASTIÁN RIVERA HENAO
INFORME FINAL
INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍAS
UNIVERSIDAD CATÓLICA DE PEREIRA PEREIRA
2016-1
2
ESTUDIO DE VIABILIDAD Y PROTOTIPO DEL CONTROL DE ACCESO DE LA UNIVERSIDAD CATÓLICA DE PEREIRA CON TECNOLOGIA RFID
ANDRÉS FELIPE VALLEJO PIEDRAHITA JUAN SEBASTIAN RIVERA HENAO
DIRECTOR DE PROYECTO
JUAN SEBASTÍAN SANTACRUZ PAREJA Ingeniero de Sistemas y Telecomunicaciones
INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES
FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍAS UNIVERSIDAD CATÓLICA DE PEREIRA
PEREIRA 2016-1
3
Tabla de contenido
INTRODUCCION ........................................................................................................ 0
1 Propuesta ............................................................................................................ 1
1.1 Objetivo general ..................................................................................... 2
1.2 Objetivos específicos ............................................................................. 2
1.3 Planteamiento del problema .................................................................. 2
1.4 Justificación ........................................................................................... 2
1.5 Viabilidad ............................................................................................... 3
1.6 Consecuencias ...................................................................................... 3
2 Marco teórico ...................................................................................................... 5
2.1 Marco conceptual .................................................................................. 5
2.1.1 Sistemas de información ................................................................. 5
2.1.1.1 Definición de información: ........................................................ 5
2.1.1.2 Concepto de Sistema de Información: ...................................... 5
2.1.1.3 Componentes estructurales de los sistemas de información: ... 5
2.1.2 RFID (Radio Frecuency IDentification) ............................................ 7
2.1.2.1 Componentes de un sistema RFID ........................................... 8
2.1.2.2 Frecuencias de operación RFID ............................................... 8
2.1.2.3 Código EPC ............................................................................ 10
2.1.2.4 Seguridad y privacidad sistemas RFID ................................... 11
2.1.2.5 Estandarización de RFID ........................................................ 13
2.1.3 Ingeniería del software .................................................................. 16
2.1.3.1 Lenguaje Unificado de Modelado (UML) ................................ 16
2.1.3.2 Requerimientos ....................................................................... 18
2.1.3.3 Casos de uso .......................................................................... 19
2.1.4 Scrum ............................................................................................ 20
2.1.4.1 Equipo Scrum (Scrum Team) ................................................. 20
2.1.4.2 Eventos de Scrum .................................................................. 23
2.1.4.3 Pruebas .................................................................................. 26
2.1.5 Software ........................................................................................ 27
2.1.5.1 Aplicaciones de software: ....................................................... 28
4
2.1.6 Inteligencia artificial ....................................................................... 29
2.1.7 Telecomunicaciones ...................................................................... 30
2.2 Marco contextual ................................................................................. 31
2.2.1 Risaralda ....................................................................................... 31
2.2.1.1 Localización: ........................................................................... 31
2.2.2 Pereira ........................................................................................... 31
2.2.3 Universidad Católica de Pereira .................................................... 31
2.2.3.1 Historia: .................................................................................. 31
2.2.3.2 La UCP hoy ............................................................................ 32
2.3 Antecedentes ....................................................................................... 32
2.3.1 Ondas de radiofrecuencia para localizar libros. ............................ 33
2.3.2 Disney World sustituye las entradas por pulseras RFID ............... 34
2.3.3 Diseño de guías para prácticas para el control de inventarios por
medio de tecnologías RFID, CB, GPS, sensores. ...................................... 35
2.3.4 La mayonesa Helmann’s utiliza RFID para fidelizar a sus clientes.
35
2.3.5 La tecnología de RFID obtiene buenos resultados en el Abierto de
Australia ..................................................................................................... 36
2.3.6 Gran hospital español adopta RFID para la gestión de pacientes y
bienes 37
3 Propuesta metodológica .................................................................................. 39
3.1 Metodología y presupuesto .................................................................. 39
3.2 Cronograma ......................................................................................... 41
4 Presentación y Análisis de resultados ........................................................... 42
4.1 Propuestas de soluciones para el control de acceso ........................... 42
4.1.1 Opción 1 de entrada principal. ...................................................... 42
4.1.1.1 Costos .................................................................................... 43
4.1.2 Opción 2 de entrada principal ....................................................... 43
4.1.2.1 Costos .................................................................................... 44
4.1.3 Opción 3 de la entrada principal .................................................... 44
4.1.3.1 Costos .................................................................................... 45
4.1.4 Opción 1 para la puesta trasera. ................................................... 45
4.1.4.1 Costos .................................................................................... 46
5
4.2 Propuesta para código EPC del proyecto ............................................ 46
4.3 Ingeniería de software para el proyecto ............................................... 49
4.3.1 Requerimientos ............................................................................. 50
4.3.2 Diagrama de casos de uso. ........................................................... 60
4.3.3 Diagrama de actividades ............................................................... 71
4.3.4 Diagramas de secuencias ............................................................. 72
4.4 Pruebas ............................................................................................... 75
4.5 Conclusiones ....................................................................................... 87
4.6 Problemas ............................................................................................ 87
BIBLIOGRAFIA ........................................................................................................ 88
ANEXO ..................................................................................................................... 92
Manual de usuario. ........................................................................................ 92
6
Lista de ilustraciones
Imagen 1: Componentes de un sistema de información ............................................. 6
Imagen 2: Esquema de funcionamiento de un sistema RFID ..................................... 8
Imagen 3: Formato EPC ........................................................................................... 11
Imagen 4: Logo UML ................................................................................................ 17
Imagen 5: Actores y casos de uso ............................................................................ 20
Imagen 6: Universidad Católica de Pereira ............................................................... 32
Imagen 7: Logo de universidad politécnica de Madrid .............................................. 33
Imagen 8: Logo de Disney World .............................................................................. 34
Imagen 9: Logo de la marca de mayonesa Hellman's .............................................. 36
Imagen 10: Logo Australian Open ............................................................................ 37
Imagen 11: Primera propuesta de portal principal del control de acceso .................. 42
Imagen 12: Segunda propuesta de portal principal del control de acceso ................ 43
Imagen 13: Tercera propuesta de portal principal del control de acceso .................. 44
Imagen 14: Primera propuesta de portal trasero....................................................... 45
Imagen 15: Construcción de código del proyecto ..................................................... 46
Imagen 16: Esquema organizacional UCP ............................................................... 49
Imagen 17: Diagrama de casos de uso .................................................................... 60
Imagen 18: Diagrama de actividades general ........................................................... 72
Imagen 19: Diagrama de secuencias, entrada de personas ..................................... 73
Imagen 20: Diagrama de secuencias, gestionar personas ....................................... 74
Imagen 21: Diagrama de secuencias, iniciar sesión ................................................. 75
7
Lista de tablas
Tabla 1: Metodología y presupuesto ......................................................................... 40
Tabla 2: Cronograma ................................................................................................ 41
Tabla 3: Estimación de costos de la primera propuesta ........................................... 43
Tabla 4: Estimación de costos de la segunda propuesta .......................................... 44
Tabla 5: Estimación de costos de la segunda propuesta .......................................... 45
Tabla 6: Estimación de costos de la segunda propuesta .......................................... 46
Tabla 7: Códigos del segundo hexteto ...................................................................... 47
Tabla 8: Códigos del tercer Hexteto .......................................................................... 49
Tabla 9: Requerimiento 001 ...................................................................................... 50
Tabla 10: Requerimiento 002 .................................................................................... 51
Tabla 11: Requerimiento 003 .................................................................................... 52
Tabla 12: Requerimiento 004 .................................................................................... 53
Tabla 13: Requerimiento 005 .................................................................................... 54
Tabla 14: Requerimiento 006 .................................................................................... 55
Tabla 15: Requerimiento numero 007 ....................................................................... 56
Tabla 16: Requerimiento 008 .................................................................................... 57
Tabla 17: Requerimiento 009 .................................................................................... 58
Tabla 18: Requerimiento 010 .................................................................................... 59
Tabla 19: Diccionario de datos CU001 ..................................................................... 61
Tabla 20: Diccionario de datos CU002 ..................................................................... 62
Tabla 21: Diccionario de datos CU003 ..................................................................... 63
Tabla 22: Diccionario de datos CU004 ..................................................................... 64
Tabla 23: Diccionario de datos CU005 ..................................................................... 65
Tabla 24: Diccionario de datos CU006 ..................................................................... 66
Tabla 25: Diccionario de datos CU007 ..................................................................... 67
Tabla 26: Diccionario de datos CU008 ..................................................................... 68
Tabla 27: Diccionario de datos CU009 ..................................................................... 69
Tabla 28: Diccionario de datos CU010 ..................................................................... 70
Tabla 29: Diccionario de datos CU011 ..................................................................... 71
0
Resumen
El propósito principal de este proyecto
es identificar los puntos críticos en la
seguridad de la universidad católica de
Pereira y las vulnerabilidades que
sufre la comunidad del plantel
educativo y presentar una posible
solución a este problema.
Para llevar a cabo este proyecto, se
realizarán actividades de recolección
de información en la universidad, se
analizarán los sistemas de ingreso y la
rigurosidad que se tiene para el
ingreso de personal a la institución;
también se propondrá la implantación
de un sistema con tecnología RFID
conectado a la base de datos de la
universidad para validar el acceso y
evitar el paso de personas ajenas a la
universidad sin previa autorización.
Se cumplirá con labores de análisis y
diseño de software que haga posible la
conexión de la base de datos de la
universidad con el sistema de ingreso
RFID; se diseñará de un sistema de
entrada basado en dicha tecnología y
se evaluará su posible implantación,
tanto en el ingreso de personal como
de vehículos.
Palabras clave: RFID, seguridad,
acceso, software, automatización
Abtract
The main purpose of this project is to
identify the critical points in the safety
of the Catholic University of Pereira
and vulnerabilities experienced by the
campus community and present a
possible solution to this problem.
To carry out this project, data collection
activities will be held at the university,
entry systems and thoroughness that
has personal income for the institution
will be analyzed; the implementation of
an RFID system connected to the
database to validate college access
and prevent the passage of people
from outside the university without prior
authorization is also proposed.
The project will fulfill tasks of analysis
and design software that enables the
connection to the database from
college with income RFID system; It
will design entry system based on this
technology and its possible
implementation will be assessed in
both personal income and vehicles.
Keywords: RFID, security, access,
software, automation
INTRODUCCION
1
Actualmente en los centros educativos universitarios del eje cafetero, hay disponibles varias jornadas académicas, el manejo de diferentes horarios genera un gran flujo de entrada y salida de personas; por lo tanto se debe contar con un sistema de ingreso confiable y que brinde seguridad a los integrantes de dichas instituciones, evitando que ingresen personas ajenas o no autorizadas. No en todas las instituciones manejan un buen control de acceso, lo que hace que no sea tan confiable la seguridad y los datos que se manejan con respecto a las estadísticas de entrada y salida; la Universidad Católica de Pereira no es ajena a este inconveniente, pues el actual control de acceso es muy fácil de evadir por lo tanto cualquier persona podría ingresar y cometer hurtos o fraudes a la comunidad universitaria. Otro inconveniente que se presenta es que en horas de mayor flujo se presenta lentitud en el ingreso debido a que solo se cuenta con un solo chequeo disponible y este es manual y presenta diferentes fallas. De allí surge la idea de cambiar la tecnología y la metodología del acceso a la Universidad Católica de Pereira usando la tecnología RFID la cual es muy sencilla y muy práctico para utilizar; este con el fin de que cada estudiante tenga almacenados sus datos en la tarjeta y que el sistema solo permita ingresar a las personas que están registrados para mejorar la seguridad. Además se tendrá mayor agilidad por ser automatizado y no habrá tanta lentitud en las horas de más flujo como se mencionaba anteriormente. Se busca también tener una buena base de información estadística de las entradas y salidas de las personas de la comunidad universitaria y estará integrada directamente con toda la base de datos de la universidad y así se tendrá mejor control en diferentes aspectos dentro de la institución.
1 Propuesta
2
1.1 Objetivo general
Diseñar y poner en prueba un prototipo de un software para el control de acceso a la Universidad Católica de Pereira, basado en la tecnología RFID. El sistema permitirá controlar el acceso del personal administrativo, académico y estudiantes. Además este nutrirá el sistema integrado de información de la universidad manejando una base de datos que almacena los registros de ingreso y salida de la comunidad universitaria.
1.2 Objetivos específicos
Identificar las debilidades que se deben corregir en el sistema actual de ingreso de la comunidad universitaria de la UCP.
Plantear posibles soluciones aplicables al nuevo sistema de control de acceso, a través de la tecnología RFID y evaluar los costos de la implementación de las nuevas tecnologías.
Crear un sistema de información para llevar un control de los horarios de entrada y salida, almacenando los ingresos en una base de datos
Aplicar las metodologías de la ingeniería del software para la elaboración del
proyecto
1.3 Planteamiento del problema
El actual sistema de registro de ingreso y salida de la comunidad universitaria de la UCP, se realiza a través de un software en el que se lee el código de barras del carné, lo que hace que el sistema sea muy demorado por su necesidad de que el código siempre tenga línea directa con el lector, porque en muchas ocasiones la lectura del código de barra es muy lento, además no es automatizado pues requiere siempre de personal en la entrada verificando la información. Además este sistema no aporta mucha información más allá de los datos personales de cada persona, pero no lleva ningún otro control ni tipo de información que puedan ser útiles en la universidad.
1.4 Justificación
3
La implementación del nuevo sistema de acceso en la entrada de la Universidad Católica de Pereira, se pretende realizar mediante el uso de la tecnología RFID (Radio Frecuency Identification) y la asignación de una etiqueta única a cada miembro de la comunidad, agilizar el ingreso, teniendo en cuenta que el nuevo sistema reducirá el tiempo que se tarda en ingresar a las instalaciones de la universidad y capturar diferentes datos de la comunidad. Esto implicaría a largo plazo, llevar un control de asistencia a la universidad, horario de entrada y salida de estudiantes y con ello poder planificar mejor los horarios, ocupación de salones y días de mayor flujo de estudiantes. Los beneficios que tendrá este proyecto será la automatización para el ingreso, por medio de la tecnología RFID, la cual brindará más comodidad, agilidad y confiabilidad, por su capacidad de leer los carnets por medio de ondas electromagnéticas. Además la universidad tendrá la ventaja de manejar dicha base de datos para analizar distintos escenarios y tomar ciertas decisiones según los datos que allí se almacenen. En cuestiones de seguridad también tendrá grandes beneficios ya que a la universidad no podrá ingresar personal no autorizado o ajeno a la misma. 1.5 Viabilidad
Las siguientes son las razones por las cuales se demuestran que el proyecto es viable:
1. Se ha evidenciado el éxito de esta implementación en otras universidades lo que demuestra que el uso de esta tecnología se adapta bien a las necesidades de la universidad y a la cultura de la universidad.
2. La seguridad en la universidad aumentará de manera considerable, ya que se tendría mayor rigurosidad para el ingreso de personas ajenas a la comunidad universitaria.
3. El proyecto se ha analizado tanto con docentes como con profesionales del área de la tecnologías dela información y telecomunicaciones quienes consideran que el proyecto es viable y que la universidad está en la capacidad de implementarlo.
1.6 Consecuencias
Las consecuencias que traerá la implementación de este proyecto serán:
1. La seguridad en la universidad mejoraría, ya que, disminuirá la entrada de personas que no estén registradas en la universidad.
4
2. Se llevará una estadística de la comunidad universitaria que asiste y se almacenará la información de ingreso de dichas personas.
3. Se incrementará el consumo de energía, debido a la operación de los equipos.
4. Se podría eliminar puestos de trabajo y reubicar dichas personas en otras labores.
5. Se mejorara la agilidad de entrada y salida en las horas más recurridas.
6. Habrá una alta inversión inicial para la instalación e implementación del nuevo sistema.
5
2 Marco teórico
2.1 Marco conceptual
2.1.1 Sistemas de información
2.1.1.1 Definición de información:
Burch & Grudnitski en 1994 afirman que:
La información la componen datos que se han colocado en un contexto significativo y útil y se ha comunicado a un receptor, quien la utiliza para tomar decisiones. La información implica la comunicación y recepción de inteligencia o conocimiento. Evalúa y notifica, sorprende y estimula, reduce la incertidumbre, revela alternativas adicionales o ayuda a eliminar las irrelevantes o pobres, e influye sobre otros individuos y los estimula a la acción.
“La información está compuesta de datos, imágenes, texto, documentos y voz, a menudo entrelazados en forma inextricable, pero siempre organizados en un contexto significativo.” (Burch & Grudnitski, 1994)
2.1.1.2 Concepto de Sistema de Información:
“Un sistema de información se puede definir técnicamente como un conjunto de componentes relacionados que recolectan (o recuperan), procesan, almacenan y distribuyen información para apoyar la toma de decisiones y el control en una organización.” (Acosta & Diaz, s.f.)
2.1.1.3 Componentes estructurales de los sistemas de información:
“Sin importar las organizaciones a las que sirven o la forma en que se desarrollan y diseñan, todos los sistemas de información están compuestos de los siguientes seis componentes estructurales: entrada, salida, tecnología base de datos y controles. Como se ilustra en la figura 1.” (Burch & Grudnitski, 1994)
6
Imagen 1: Componentes de un sistema de información Fuente: Elaboración propia
Bloque de entrada: la entrada representa a todos los datos, texto, voz e imágenes que entran al sistema de la información y los métodos y medios por los cuales se capturan e introducen.
Bloque de modelos: esta componente consta de modelos lógico-matemáticos que manipulan de diversas formas la entrada y los datos almacenados, para producirlos resultados deseados o salida.
Bloque de salida: el producto del sistema de información es la salida de información de calidad y documentos para todos los niveles de la gerencia y para todos los usuarios dentro y fuera de la organización.
Bloque tecnología: la tecnología es la “caja de herramientas” del trabajo en sistemas de información. Captura la entrada, activa los modelos, almacena e ingresa datos, produce y transmite salida, y ayuda a controlar todo el sistema.
Bloque de base de datos: es el lugar donde se almacenan todos los datos necesarios para atender a las necesidades de todos los usuarios.
Bloque de controles: todos los sistemas de información están sujetos a una diversidad de peligros y amenazas, como desastres naturales, incendios, fraude, fallas de los sistemas, errores y omisiones, intercepción secreta, deficiencias, sabotajes, y mutilaciones maliciosas. Algunos de los controles que necesitan diseñarse el sistema para asegurar su protección son la instalación de un sistema de administración de registros, la aplicación de controles contables tradicionales, el desarrollo de un plan maestro de sistemas de información, etc. (Burch & Grudnitski, 1994)
El proyecto propuesto debe contar con un sistema de información, el cual almacene ciertos datos de la comunidad académica de la Universidad Católica de Pereira, estos datos serán capturados en el momento en que las personas intentan ingresar a las instalaciones de la universidad y también en el momento en que salen de la misma, la información que se obtendrá es la siguiente: nombres y apellidos, código de identificación, hora de entrada y salida, entre otros. Toda esta información
7
quedará plasmada en una base de datos que estará directamente relacionada con el sistema integrado de información de la universidad, lo cual permitirá en distintas áreas utilizar la información según lo requerido.
2.1.2 RFID (Radio Frecuency IDentification)
Burch & Grudnitski, 1994 definen que:
Es una técnica de almacenamiento y recuperación de datos basada en la radiofrecuencia que no necesita visión directa. En otras palabras, se trata de una tecnología de transmisión de datos automática que emplea radiofrecuencia para comunicar información entre un lector y una etiqueta electrónica (e-tag); o lo que es lo mismo, utiliza ondas electromagnéticas para enviar la información desde la etiqueta al lector. Este sistema permite la captura y/o grabación de datos sin contacto entre lector y etiqueta, eliminando así la necesidad de un contacto visual directo.
“Un sistema RFID básicamente se compone de una etiqueta RFID que contiene una información y un lector RFID (también puede ser grabador) comunicado con un sistema informático que procesa la información recibida de la etiqueta o tag.” ( Observatorio Regional de la Sociedad de la Información. (ORSI), 2007)
Esta es la tecnología que se utilizará para la solución del proyecto planteado, ya que la idea es contar con un sistema que permita controlar el ingreso y salida, tanto de personas como vehículos. En la entrada se pondrá un lector (RFID) al cual se le acercara una tarjeta que contiene la etiqueta(o transponedor) que lleva toda la información de la persona titular o propietaria, quien al momento del ingreso será identificada por el sistema y se le permitirá ingresar a las instalaciones de la institución; a la vez la información de la persona o vehículo será almacenada en la base de datos.
El funcionamiento de los sistemas RFID se puede visualizar en la figura 2:
8
Imagen 2: Esquema de funcionamiento de un sistema RFID
Fuente: Elaboración propia
2.1.2.1 Componentes de un sistema RFID
Un sistema RFID básico consta de dos elementos fundamentales:
Una etiqueta, tag o transpondedor RFID. Es el elemento en el que se incorpora el chip electrónico que contiene la información necesaria para identificar al producto. Contiene también una microantena que le permite recibir y transmitir la información a través de radiofrecuencia.
Un lector RFID. Se trata de un equipo capaz de recibir y procesar la información procedente de los tags RFID. Este equipo cuenta con una antena que le permite recibir y transmitir peticiones de información a través de radiofrecuencia.
2.1.2.2 Frecuencias de operación RFID
En la tecnología RFID se puede trabajar a diferentes frecuencias, la utilización de una frecuencia u otra depende de la necesidad que se tenga en la aplicación que se le valla a dar, teniendo en cuenta las distancias que se vallan a emplear y las condiciones de los objetos que se quieran identificar. A continuación se explicaran las diferentes frecuencias que existen, así como sus características y posibles campos en los que se puedan utilizar.
2.1.2.2.1 Baja Frecuencia (LF).
Según Comunidad de RFID en Latinoamérica, 2009:
9
Los tags de baja frecuencia (LF) utilizan la frecuencia de 120 a 140
KHz y operan por acoplamiento inductivo para obtener energía de un
lector. Los tags LF tienen una bobina de inducción en lugar de una
antena. Son adecuados para aplicaciones que requieren lectura de
pequeñas cantidades de datos a baja velocidad. Los tags pasivos LF
pueden ser leídos desde una distancia inferior a 0,5 metros.
Estos tags LF se utilizan principalmente en materiales como agua, madera,
aluminio, tejidos, metal u objetos que contengan líquidos tales como frutas y
verduras. Los tags de baja frecuencias se utilizan en algunas aplicaciones de
identificación de animales, seguridad de vehículos, acceso a transporte
público, entre otros.
2.1.2.2.2 Alta frecuencia (HF).
La Comunidad de RFID en Latinoamérica, 2009 indica que:
Los tags de alta frecuencia (HF) utilizan 13,56 MHz y operan por
acoplamiento inductivo. Los tags HF tienen una bobina de inducción en
lugar de una antena. Al igual que ocurre con los tags LF, los tags de
alta frecuencia son también adecuados para aplicaciones que
requieren lectura de pequeñas cantidades de datos a baja velocidad,
siendo leídos a cortas distancias. La distancia de lectura por lo general
se encuentra por debajo de un metro.
Estas ondas de alta frecuencia también pueden funcionar en entornos líquidos
o húmedos pero su funcionamiento no va a ser tan óptimo como las de LF.
Las aplicaciones más comunes para esta frecuencia es el control de acceso
de personas.
2.1.2.2.3 Ultra alta frecuencia (UHF).
La Comunidad de RFID en Latinoamérica en 2009 los definen como:
Los tags UHF funcionan en un rango de 860 a 960 MHz de frecuencia,
se acoplan con el campo del lector de forma capacitiva utilizando el
campo eléctrico. En algunos casos los tags pueden utilizar el campo
magnético de inducción cuando están cerca del transmisor. Estos
10
diseños de tags poseen antenas en lugar de bobinas de inducción.
Algunos tags UHF tienen un rango de lectura de hasta 15 metros.
Esta frecuencia a diferencia de las dos anteriormente mencionadas no
funciona en entornos líquidos o húmedos, se aplican para materiales sólidos,
la gran ventaja de UHF es su gran velocidad de lectura. Las aplicaciones más
comunes en esta frecuencia es la identificación de cadenas de suministro.
Además de las distancias y características mencionadas anteriormente, estas
frecuencias también se diferencian por la manera en la que se intercambian los
datos entre las etiquetas y el lector.
En las frecuencias LF y HF actúan con acoplamiento inductivo, esto quiere decir que
el lector le envía una orden a la etiqueta de que tiene que generar una onda
electromagnética con la información que tenga almacenada.
Mientras que las frecuencias UHF intercambian la información por una técnica
llamada backscattering, lo que hace esta técnica es que la etiqueta refleja la onda
que recibe del lector añadiendo en ella (en la onda) la información que tiene
almacenada.
2.1.2.3 Código EPC
EPC por sus siglas en inglés Electronic Product Code (Código electrónico de Producto), es una clave de identificación única, la cual permite detallar la información completa de cierto producto o persona. El principal objetivo de EPC es crear un camino para que las empresas puedan migrar del código de barras a la tecnología RFID.
2.1.2.3.1 Formato EPC
En la página web de la comunidad de RFID en Latinoamérica se expone un formato general para los datos de la etiqueta EPC que incluyen las siguientes secciones: Encabezado (Header): El encabezado identifica la versión numérica del
código por sí mismo.
Administrador EPC: Identifica una empresa que es responsable de mantener
la Categoría de objeto y Número serial. EPC Global asigna el Administrador
General a una entidad, asegurando que cada uno de estos números sea
único.
11
Categoría de Objeto: Se refiere al tipo exacto de producto, similar a un SKU
(unidad mínima de producto). La Categoría de Objeto es usado por una
entidad de gestión EPC para identificar ítems de mercado. Estos números de
categoría de Objeto, por supuesto, deben ser únicos dentro de cada dominio
del Número de Administrador General. El ejemplo más común de Categoría
de Objeto seria el SKU de bienes de consumo.
Número Serial: Representa un único identificador para el ítem dentro de cada
categoría de objeto. La entidad administradora es responsable por la
asignación unívoca de números seriales no repetitivos para cada instancia
dentro de cada categoría de objeto.
El Código EPC Clase 1, con 96 bits de longitud, puede almacenar hasta 268
millones de compañías, cada una teniendo 16 millones de categorías, con 68
billones de números seriales en cada categoría. En las etiquetas de Clase 1,
un adicional de 32 bits del EPC es reservado para la información de un único
ítem (descripción del ítem, destino final, instrucciones especiales de
manipulación, etc.) que puede ser reutilizado en cualquier punto de la cadena
de abastecimiento.
Imagen 3: Formato EPC
Fuente: (Comunidad de RFID en Latinoamérica, 2009)
2.1.2.4 Seguridad y privacidad sistemas RFID
A lo largo de este documento se han manifestado las diversas características y
ventajas que se tienen al aplicar la tecnología RFID, pero como todo lo que respecta
al ambiente tecnológico se debe tener especial cuidado con todo lo relacionado con
la seguridad y privacidad, estos dos puntos son los más críticos para la tecnología
RFID. Al aplicar RFID se deben tener en cuenta algunas recomendaciones
importantes para evitar tener inconvenientes dentro de la organización o negocio en
el que se vaya a trabajar.
12
Peris López, 2008 afirman que:
La tecnología RFID es una tecnología inalámbrica. Algunos de los ataques
encontrados en esta tecnología son similares a los que suceden en otras tales
como wireless, bluetooth, etc. Además, las etiquetas RFID tienen similitudes
con las smart-cards debido a las limitaciones del chip. Por lo tanto, no todos
los ataques asociados con esta tecnología son nuevos.
Un sistema de este tipo debe ser protegido ante situaciones como:
Lecturas o escrituras no autorizadas que obtengan o modifiquen la
información de las etiquetas.
Uso de etiquetas falsas que violen las condiciones de seguridad del sistema
accediendo a sitios o a servicios fraudulentamente.
Interceptaciones con el fin de clonar etiquetas y/o datos del sistema.
A continuación se describirán algunos de los ataques que se le pueden realizar a un sistema RFID según Torres Gómez, 2011:
Spoofing: Transmisión de información falsa que es interpretada como válida
y puede inducir a errores en el sistema de información.
Inserción: Ingresa información al sistema cuando se esperan señales de
control o viceversa.
Replay: La señal transmitida se intercepta grabando la información existente
la cual es luego reenviada al receptor.
Denegación de servicio: Existen dos variantes: una donde la señal de RF se
bloquea mediante ruido y otra donde se envía al sistema más información de
la que éste puede manejar.
Man in the middle: En este caso se suplanta la identidad de uno de los
elementos que interactúa en la comunicación RF (lector, etiqueta).
Modificación de información: La información contenida en el tag se modifica
para obtener por ejemplo precios menores en la compra de productos.
13
Bloqueo de etiquetas: La etiqueta se deja fuera de servicio mediante la
aplicación de un campo electromagnético fuerte permitiendo así la extracción
del producto sin que se genere la respectiva señal de advertencia
Con respecto a la privacidad, se ha expresado que los sistemas RFID pueden
acceder a datos personales sin previa autorización y ser utilizada para diversas
intenciones, ya que las personas que llevan una etiqueta transmiten frecuentemente
la información a los lectores más cercanos por medio de su número de serie fijos.
2.1.2.5 Estandarización de RFID
Existen diversos estándares para la aplicación de sistemas RFID según de la forma y el campo en el que se vaya a utilizar. Hay principalmente dos organizaciones de estandarización de la tecnología tales como ISO y EPC global. A continuación se mostrara un resumen de los estándares más importantes y utilizados.
2.1.2.5.1 ISO/IEC 18000
Es una norma para la identificación de artículos, este consta de 7 partes:
Parte 1: Referencia parámetros generales para la estandarización de la arquitectura RFID.
Parte 2: Define los parámetros para la comunicación en frecuencias por debajo de 135 KHz.
Parte 3: Define los parámetros para la comunicación en frecuencias de 13,56 GHz.
Parte 4: Define los parámetros para la comunicación en frecuencias de 2,45 KHz.
Parte 5: Define los parámetros para la comunicación en frecuencias de 5,8 GHz.
Parte 6: Define los parámetros para la comunicación en frecuencias entre 860 y 960 MHz.
Parte 7: Define los parámetros para la comunicación en frecuencias de 433 MHz.
14
2.1.2.5.2 ISO/IEC 10536
Estándar diseñado para etiquetas de identificación. En ella describe todas sus características físicas, sus señales electrónicas, dimensiones y localización.
2.1.2.5.3 ISO/IEC 14443
Estándar para las tarjetas de proximidad. Describe sus características físicas, la potencia de radio frecuencia, la interfaz de señal y su inicialización y anticolisión.
2.1.2.5.4 ISO/IEC 15961
Se centra en la interfaz entre la aplicación y el procesador de protocolo de datos, e incluye la especificación de la sintaxis de transferencia y definición de comandos de la aplicación y las respuestas.
2.1.2.5.5 ISO/IEC 15962
Esta norma se centra en la codificación de la sintaxis de transferencia de datos y funciones de memoria lógica.
2.1.2.5.6 ISO/IEC 15963
Norma que describe la numeración disponible para la identificación de etiquetas de radiofrecuencia.
2.1.2.5.7 ISO/IEC 19762
Define términos y condiciones para la captura e identificación automática de datos.
15
2.1.2.5.8 ISO/IEC 18001
Analiza los requisitos de identificación y uso de RFID. Clasifica los tipos de tags según su clasificación.
2.1.2.5.9 ISO 11784, ISO 11785 e ISO 14223
Estas tres normas especifican como se debe manejar la identificación por radio frecuencia para los animales, estos incluyen los códigos de estructura, conceptos técnicos y avances de transpondedores.
2.1.2.5.10 EPC Global
EPC Glogal Inc. Es la organización que regula este estándar, “es una organización independiente, sin fines de lucro y con estándares globales encomendados por la industria para el manejo de la adopción e implementación de la Red EPC Global y la tecnología EPC.” (Comunidad de RFID en Latinoamérica, 2009)
2.1.2.5.11 EPC™ Radio-Frequency Identity Protocols Class-1
Generation-2 UHF RFID
Es un protocolo para comunicaciones en 860 MHz – 960 MHz y especifica las interacciones físicas entre los lectores y las etiquetas.
2.1.2.6 Diferencias entre l tecnología RFID y el código de barras
Código de barras RFID
Los lectores requieren una verificación directa con el código.
No requiere línea de visión directa con los tag.
El lector no tiene la capacidad de viajar a través de diferentes materiales.
La señal de la frecuencia de radio es capaz de viajar a través de la mayoría de los materiales.
Con el código de barras se obtiene la ubicación absoluta de un objeto en un punto específico.
No provee la ubicación física absoluta de un ítem
La velocidad de lectura es menor en el Tiene mayor velocidad de lectura que el
16
código de barras. código de barras.
La durabilidad de las etiquetas de papel de código de barra depende del adhesivo que las mantiene pegada a su objeto.
La durabilidad de los tag RFID depende del adhesivo que las mantiene pegada al objeto.
El código UPC identifica la clasificación de un ítem genérico.
El código EPC permite identificar un ítem en forma individual a través de un número serial asignado.
El costo de implementación es más bajo que el RFID.
RFID requiere inversiones en capital. Los principales costos están representados por el equipamiento y por los servicios profesionales
Tabla 1 Diferencias entre código de barras y RFID
2.1.3 Ingeniería del software
“La ingeniería del software es todo lo referente a producir lo que el cliente desea dentro del tiempo y costos requeridos. Un producto de calidad necesita una combinación de habilidades técnicas y organizacionales.” (Norris & Rigby, 1994)
“Ingeniería del software es la aplicación práctica del conocimiento científico en el diseño y construcción de programas de computadores y la documentación asociada requerida para desarrollar, operar (funcionar) y mantenerlos. Se conoce también como desarrollo de software o producción software.” (Pressman & Roger, 2002)
Programar resulta muy divertido, pero desarrollar un software de calidad en la mayoría de ocasiones difícil y más si no se tiene una buena planificación. A lo largo del desarrollo de este proyecto, la ingeniería del software se aplica como una estrategia para el análisis previo de la situación, el diseño y posterior elaboración del producto, desarrollo de software; también define hasta dónde y cómo se va a llevar a cabo, el posible costo, los riesgos que conlleva la puesta en marcha de dicho desarrollo y las pruebas necesarias para asegurar al cliente que se hace entrega de un sistema que funciona de forma correcta y posteriormente llevarlo a la implementación, teniendo en cuenta si es necesario algún mantenimiento luego de cierto tiempo.
2.1.3.1 Lenguaje Unificado de Modelado (UML)
Entre los años 70 y 80 empezaron a aparecer los lenguajes de modelados
experimentando con enfoques al análisis y diseño. Entre finales de los 80 y
17
principios de los 90 se tenía un gran conflicto llamado “guerra de los métodos” que
se daba debido a que a pesar de que había muchos lenguajes de modelado,
ninguno cubría completamente sus necesidades. Teniendo en cuenta estas
experiencias, empezaron a aparecer nuevos métodos con mejoras en donde se
destacaron principalmente tres: el método Booch, creado por Grady Booch, el
método OOSE (Ingeniería del software orientada a objetos), creado por Ivar
Jacobson y el método OMT, creado por James Rumbaugh. Cada uno de estos
métodos tenía sus puntos fuertes y débiles por lo cual a finales de los 90 los tres
creadores de estos métodos decidieron unificarlos para así complementarse entre sí
y así dejar un único lenguaje unificado modelado.
Según Booch, Rumbaugh, & Jacobson, 1999:
El lenguaje Unificado de Modelado (UML, Unifed Modeling Language) es un
lenguaje grafico para visualizar, especificar, construir y documentar los artefactos de
un sistema con gran cantidad de software. UML proporciona una forma estándar de
escribir los planos de un sistema, cubriendo tanto las cosas conceptuales, tales
como procesos de negocio y funciones del sistema, como las cosas concretas, tales
como las clases escritas en un lenguaje de programación especifico, esquemas de
bases de datos y componentes reutilizables.
Imagen 4: Logo UML
Fuente: (UML, 2015)
18
2.1.3.2 Requerimientos
“Los requerimientos son declaraciones que identifican atributos, capacidades,
características y/o cualidades que necesita cumplir un sistema (o un sistema de
software) para que tenga valor y utilidad para el usuario. En otras palabras, los
requerimientos muestran qué elementos y funciones son necesarias para un
proyecto.” (Alegsa, 2009).
“Los requerimientos son el mecanismo más apropiado para comprender lo que
quiere el cliente, analizando necesidades, confirmando su viabilidad, negociando
una solución razonable, especificando la solución sin ambigüedad, validando la
especificación y gestionando los requerimientos para que se transformen en un
sistema operacional.” (Pressman, 2002)
Es de suma importancia tener bien especificados los requerimientos para que el
software sea exitoso y cumpla con todas las características que se deben, para esto
hay establecidas algunas características para un buen requerimiento:
Necesario
Conciso
Entendible
Completo
No ambiguo
Verificable
Los requerimientos se pueden clasificar en:
2.1.3.2.1 Requerimientos funcionales
En el sitio web de la Metodología Gestion de requerimientos, se menciona
que los requerimientos funcionales:
Se utilizan para determinar que hará el Software, definiendo las
relaciones de su operación y su implementación, sin olvidar que deben
ser explícitos también en lo que el sistema no debe hacer y que
validaciones se deben realizar, teniendo en cuenta cual será el
comportamiento del sistema. Los Requerimientos funcionales se
pueden dividir en dos puntos de vista: El primero tiene relación con el
19
usuario, donde se identifica la relación del usuario con el sistema desde
el punto de vista del mismo; El segundo tiene relación con el sistema
dando respuesta al usuario, es decir desde el punto de vista de lo que
realiza el sistema.
2.1.3.2.2 Requerimientos no funcionales
Según Metodología Gestion de requerimientos
Estos requerimientos se basan en las restricciones de los servicios o
funciones ofrecidos por el sistema. Incluyen restricciones de tiempo,
sobre el proceso de desarrollo, estándares, usabilidad, portabilidad,
entre otros. Los Requerimientos funcionales son los requerimientos que
no se refieren directamente a las funciones específicas que entrega el
sistema, sino a las propiedades emergentes de éste como la fiabilidad,
la respuesta en el tiempo y la capacidad de almacenamiento. Los
requerimientos no funcionales surgen de la necesidad del usuario,
debido a las restricciones en el presupuesto, a las herramientas
utilizadas, a las políticas de la organización, a la necesidad de
interoperabilidad con otros sistemas de software o hardware o a
factores externos como los reglamentos de seguridad, las políticas de
privacidad, etcétera.
2.1.3.3 Casos de uso
Una vez se tengan identificados los requerimientos, se deben crear un conjunto de escenarios en la que se describen como se usara el sistema y su interacción con el mundo exterior. Este conjunto de escenarios se llama casos de uso.
Para realizar los casos de uso, en primera instancia se deben identificar los diferentes tipos de personas o dispositivos que van a interactuar con el sistema, los cuales se les llama actores. Un actor es algo o alguien que se comunica con el sistema y es externo al sistema en sí mismo.
“Es importante indicar que un actor y un usuario no es lo mismo. Un usuario normal puede jugar un número de papeles diferentes cuando utiliza un sistema, por lo tanto un actor representa una clase de entidades externas (a veces, pero no siempre personas) que lleva a cabo un papel.” (Pressman, 2002)
20
Imagen 5: Actores y casos de uso
Fuente: (Booch, Rumbaugh, & Jacobson, 1999)
2.1.4 Scrum
Schwaber & Sutherland, 2013 indican que:
Scrum es un proceso en el que se aplican de manera regular un conjunto de
buenas prácticas para trabajar colaborativamente, en equipo, y obtener el
mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a
otras y su selección tiene origen en un estudio de la manera de trabajar de
equipos altamente productivos.
Scrum se basa en la teoría de control de procesos empírica o empirismo. El
empirismo asegura que el conocimiento procede de la experiencia y de tomar
decisiones basándose en lo que se conoce. Scrum emplea un enfoque
iterativo e incremental para optimizar la predictibilidad y el control del riesgo.
A continuación se muestran todos los elementos que componen la metodología ágil
Scrum.
2.1.4.1 Equipo Scrum (Scrum Team)
Schwaber & Sutherland, 2013 dicen que:
21
El Equipo Scrum consiste en un Dueño de Producto (Product Owner), el
Equipo de Desarrollo (Development Team) y un Scrum Master. Los Equipos
Scrum son auto-organizados y multifuncionales. Los equipos auto
organizados eligen la mejor forma de llevar a cabo su trabajo y no son
dirigidos por personas externas al equipo. Los equipos multifuncionales tienen
todas las competencias necesarias para llevar a cabo el trabajo sin depender
de otras personas que no son parte del equipo. El modelo de equipo en
Scrum está diseñado para optimizar la flexibilidad, la creatividad y la
productividad.
2.1.4.1.1 El Dueño de Producto (Product Owner)
El Dueño de Producto es el responsable de maximizar el valor del producto y del
trabajo del Equipo de Desarrollo. El cómo se lleva a cabo esto podría variar
ampliamente entre distintas organizaciones, Equipos Scrum e individuos. El Dueño
de Producto es la única persona responsable de gestionar la Lista del Producto
(Product Backlog). La gestión de la Lista del Producto incluye:
Expresar claramente los elementos de la Lista del Producto;
Ordenar los elementos en la Lista del Producto para alcanzar los objetivos y
misiones de la mejor manera posible;
Optimizar el valor del trabajo desempeñado por el Equipo de Desarrollo;
Asegurar que la Lista del Producto es visible, transparente y clara para todos,
y que muestra aquello en lo que el equipo trabajará a continuación; y,
Asegurar que el Equipo de Desarrollo entiende los elementos de la Lista del
Producto al nivel necesario.
El Dueño de Producto es una única persona, no un comité. El Dueño de Producto podría representar los deseos de un comité en la Lista del Producto, pero aquellos que quieran cambiar la prioridad de un elemento de la Lista deben hacerlo a través del Dueño de Producto.
22
2.1.4.1.2 El Equipo de Desarrollo (Development Team)
“El Equipo de Desarrollo consiste en los profesionales que desempeñan el trabajo de
entregar un Incremento de producto “Terminado”, que potencialmente se pueda
poner en producción, al final de cada Sprint. Solo los miembros del Equipo de
Desarrollo participan en la creación del Incremento.” (Schwaber & Sutherland, 2013)
“Los Equipos de Desarrollo son estructurados y empoderados por la organización
para organizar y gestionar su propio trabajo. La sinergia resultante optimiza la
eficiencia y efectividad del Equipo de Desarrollo.” (Schwaber & Sutherland, 2013)
Según Schwaber & Sutherland, 2013
El tamaño óptimo del Equipo de Desarrollo es lo suficientemente pequeño
como para permanecer ágil y lo suficientemente grande como para completar
una cantidad de trabajo significativa. Tener menos de tres miembros en el
Equipo de Desarrollo reduce la interacción y resulta en ganancias de
productividad más pequeñas. Los Equipos de Desarrollo más pequeños
podrían encontrar limitaciones en cuanto a las habilidades necesarias durante
un Sprint, haciendo que el Equipo de Desarrollo no pudiese entregar un
Incremento que potencialmente se pueda poner en producción. Tener más de
nueve miembros en el equipo requiere demasiada coordinación. Los Equipos
de Desarrollo grandes generan demasiada complejidad como para que pueda
gestionarse mediante un proceso empírico. Los roles de Dueño de Producto y
Scrum Master no cuentan en el cálculo del tamaño del equipo a menos que
también estén contribuyendo a trabajar en la Lista de Pendientes de Sprint
(Sprint Backlog).
2.1.4.1.3 El Scrum Master
“El Scrum Master es el responsable de asegurar que Scrum es entendido y
adoptado. Los Scrum Masters hacen esto asegurándose de que el Equipo Scrum
trabaja ajustándose a la teoría, prácticas y reglas de Scrum.” (Schwaber &
Sutherland, 2013)
El Scrum Master es un líder que está al servicio del Equipo Scrum. El Scrum Master
ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el
Equipo Scrum pueden ser de ayuda y cuáles no. El Scrum Master ayuda a todos a
modificar estas interacciones para maximizar el valor creado por el Equipo Scrum.
23
El Scrum Master da servicio al Equipo de Desarrollo de varias formas, incluyendo:
Guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional;
Ayudar al Equipo de Desarrollo a crear productos de alto valor;
Eliminar impedimentos para el progreso del Equipo de Desarrollo;
Facilitar los eventos de Scrum según se requiera o necesite; y,
Guiar al Equipo de Desarrollo en el entorno de organizaciones en las que Scrum aún no ha sido adoptado y entendido por completo.
2.1.4.2 Eventos de Scrum
Schwaber & Sutherland en 2013 en:
En Scrum existen eventos predefinidos con el fin de crear regularidad y
minimizar la necesidad de reuniones no definidas en Scrum. Todos los
eventos son bloques de tiempo (time-boxes), de tal modo que todos tienen
una duración máxima. Una vez que comienza un Sprint, su duración es fija y
no puede acortarse o alargarse. Los demás eventos pueden terminar siempre
que se alcance el objetivo del evento, asegurando que se emplee una
cantidad apropiada de tiempo sin permitir desperdicio en el proceso.
2.1.4.2.1 El Sprint
“El corazón de Scrum es el Sprint, es un bloque de tiempo (time-box) de un mes o
menos durante el cual se crea un incremento de producto “Terminado”, utilizable y
potencialmente desplegable. Es más conveniente si la duración de los Sprints es
consistente a lo largo del esfuerzo de desarrollo. Cada nuevo Sprint comienza
inmediatamente después de la finalización del Sprint previo.” (Schwaber &
Sutherland, 2013)
24
Cada Sprint puede considerarse un proyecto con un horizonte no mayor de un mes.
Al igual que los proyectos, los Sprints se usan para lograr algo. Cada Sprint tiene
una definición de qué se va a construir, un diseño y un plan flexible que guiará la
construcción y el trabajo y el producto resultante.
2.1.4.2.2 Reunión de Planificación de Sprint (Sprint Planning Meeting)
Schwaber & Sutherland en 2013 dicen que:
El trabajo a realizar durante el Sprint se planifica en la Reunión de
Planificación de Sprint. Este plan se crea mediante el trabajo colaborativo del
Equipo Scrum completo. La Reunión de Planificación de Sprint tiene un
máximo de duración de ocho horas para un Sprint de un mes. Para Sprints
más cortos, el evento es usualmente más corto. El Scrum Master se asegura
de que el evento se lleve a cabo y que los asistentes entiendan su propósito.
El Scrum Master enseña al Equipo Scrum a mantenerse dentro del bloque de
tiempo.
La Reunión de Planificación de Sprint responde a las siguientes preguntas:
¿Qué puede entregarse en el Incremento resultante del Sprint que comienza?
¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento?
2.1.4.2.3 Scrum Diario (Daily Scrum)
“El Scrum Diario es una reunión con un bloque de tiempo de 15 minutos para que el
Equipo de Desarrollo sincronice sus actividades y cree un plan para las siguientes
24 horas. Esto se lleva a cabo inspeccionando el trabajo avanzado desde el último
Scrum Diario y haciendo una proyección acerca del trabajo que podría completarse
antes del siguiente.” (Schwaber & Sutherland, 2013)
El Scrum Diario se realiza a la misma hora y en el mismo lugar todos los días para
reducir la complejidad. Durante la reunión, cada miembro del Equipo de Desarrollo
explica:
25
¿Qué hice ayer que ayudó al Equipo de Desarrollo a lograr el Objetivo del
Sprint?
¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del
Sprint?
¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo logremos
el Objetivo del Sprint?
Indicaban Schwaber & Sutherland en 2013 que:
El Equipo de Desarrollo usa el Scrum Diario para evaluar el progreso hacia el
Objetivo del Sprint y para evaluar qué tendencia sigue este progreso hacia la
finalización del trabajo contenido en la Lista del Sprint. El Scrum Diario
optimiza las posibilidades de que el Equipo de Desarrollo cumpla el Objetivo
del Sprint.
2.1.4.2.4 Revisión de Sprint (Sprint Review)
Schwaber & Sutherland, 2013 lo
Al final del Sprint se lleva a cabo una Revisión de Sprint para inspeccionar el
Incremento y adaptar la Lista de Producto si fuese necesario. Durante la
Revisión de Sprint, el Equipo Scrum y los interesados colaboran acerca de lo
que se hizo durante el Sprint. Basándose en esto, y en cualquier cambio a la
Lista de Producto durante el Sprint, los asistentes colaboran para determinar
las siguientes cosas que podrían hacerse para optimizar el valor. Se trata de
una reunión informal, no una reunión de seguimiento, y la presentación del
Incremento tiene como objetivo facilitar la retroalimentación de información y
fomentar la colaboración.
2.1.4.2.5 Retrospectiva de Sprint (Sprint Retrospective)
Schwaber & Sutherland, 2013 la definen como:
26
La Retrospectiva de Sprint es una oportunidad para el Equipo Scrum de
inspeccionarse a sí mismo y crear un plan de mejoras que sean abordadas
durante el siguiente Sprint.
La Retrospectiva de Sprint tiene lugar después de la Revisión de Sprint y
antes de la siguiente Reunión de Planificación de Sprint. Se trata de una
reunión restringida a un bloque de tiempo de tres horas para Sprints de un
mes. Para Sprints más cortos se reserva un tiempo proporcionalmente menor.
El Scrum Master se asegura de que el evento se lleve a cabo y que los
asistentes entiendan su propósito. El Scrum Master enseña a todos a
mantener el evento dentro del bloque de tiempo fijado. El Scrum Master
participa en la reunión como un miembro del equipo ya que la responsabilidad
del proceso Scrum recae sobre él.
2.1.4.3 Pruebas
Kniberg, 2007 indica que:
Las pruebas son quizás la parte más complicada dentro de un desarrollo de
software. Si la calidad tiene algún valor para quien este desarrollando el
software es necesario algún tipo de fase de pruebas de aceptación manuales
Se trata de que encargados de pruebas dedicados que no son parte del
equipo de desarrollo intenten encontrarle fallas al sistema por todos los lados,
que los desarrolladores no se hayan imaginado. Los encargados de pruebas
acceden al sistema en la forma exacta en la que los usuarios finales lo harán,
lo que significa que debe hacerse manualmente.
El equipo de pruebas encontrará errores, el equipo Scrum tendrá que hacer las
correcciones necesarias, y tarde o temprano será posible lanzar la versión correcta
para el usuario final.
Minimiza la fase de pruebas
La fase de pruebas es dura. La sensación es distintivamente no-Ágil. Aunque no
podemos librarnos de ella, sí que podemos minimizarla. Más específicamente,
minimizamos la cantidad de tiempo necesario para la fase de pruebas. Esto lo
conseguimos:
27
Maximizando la calidad del código desarrollado por el equipo.
Maximizando la eficiencia del trabajo manual de pruebas (es decir, encontrar
los beta-testers, darles las mejores herramientas y asegurarnos de que
informan de las tareas que pueden automatizarse).
Así que ¿cómo maximizamos la calidad del código desarrollado por el equipo
Scrum? Bueno, hay muchas maneras. He aquí dos que nos funcionan muy bien:
Incluir encargados de pruebas en el equipo Scrum.
Hacer menos cosas en cada Sprint.
2.1.4.3.1 El encargado de pruebas
Kniberg en 2007 indicó que:
Además de ser “solo” un miembro del equipo, el encargado de pruebas tiene
una labor importante. Es el que da el visto bueno. Nada se considera
terminado hasta que él dice que está terminado. He encontrado a muchos
desarrolladores que dicen que algo está terminado cuando en realidad no lo
estaba. Incluso si tienes una definición muy clara de lo que significa
“terminado”, los desarrolladores frecuentemente la olvidarán. Los
programadores somos gente impaciente y queremos dedicarnos al próximo
elemento lo antes posible.
2.1.5 Software
“Programas de ordenador y la documentación asociada. Los productos software se pueden desarrollar para un cliente en particular o para un mercado general.” (Sommerville, 2005)
“Por lo general un sistema de software consiste en diversos programas independientes, archivos de configuración que se utilizan para ejecutar estos programas, un sistema de documentación que describe la estructura del sistema, la documentación para el usuario que explica cómo utilizar el sistema.” (Sommerville, 2005)
28
2.1.5.1 Aplicaciones de software:
“El software puede aplicarse en cualquier situación en la que se haya definido previamente un conjunto específico de pasos procedimentales. El contenido y el determinismo de la información son factores importantes a considerar para determinar la naturaleza de una aplicación de software.” (Sommerville, 2005)
Algunas veces es difícil establecer categorías genéricas para las aplicaciones del software que sean significativas. Las siguientes áreas del software que expone Sommerville (2005) implican la amplitud de las aplicaciones potenciales:
Software de sistemas: es un conjunto de programas que han sido escritos para servir a otros programas. Algunos programas de sistemas procesan estructuras de información compleja pero determinada. Otras procesan datos en gran medida indeterminados.
Software de tiempo real: es el software que coordina/analiza/controla sucesos del mundo real conforme ocurren. Entre los elementos del software de tiempo real se incluye: un componente de adquisición de datos, un componente de análisis, un componente de control/salida y un componente de monitorización.
Software de gestión: el proceso de la información comercial constituye la mayor de las áreas de aplicación del software. Los sistemas discretos han evolucionado hacia el software de sistemas de información de gestión que accede a una o más bases de datos que contienen información comercial.
Software de ingeniera y científico: está caracterizado por los algoritmos de manejo de números. Las aplicaciones van desde la astronomía a la vulcanología, desde el análisis de la presión de los automotores a la dinámica orbital de las lanzaderas especiales y desde la biología molecular a la fabricación automática.
Software empotrado: los productos inteligentes se han convertido en algo común en casi todos los mercados de consumo e industriales. El software empotrado reside en memoria de solo lectura y se utiliza para controlar productos y sistemas de los mercados industriales y de consumo. El software empotrado puede ejecutar funciones muy limitadas y curiosas (por ejemplo: en el control de las teclas de un horno microondas).
Software de computadoras personales: el mercado de software de computadoras personales ha germinado en las pasadas dos décadas. El
29
procesamiento de textos, las hojas de cálculo, los gráficos por computadora, multimedia, entretenimientos, gestión de bases de datos, aplicaciones financieras, de negocios, personales y redes o acceso a bases de datos externas son algunas de los cientos de aplicaciones.
Software basados en web: las páginas web buscadas por un explorador son software que incorporan instrucciones ejecutables (por ejemplo: CGI, HTML, PERL o java), y datos (por ejemplo: hipertexto y una variedad de formatos de audio y visuales).
Software de inteligencia artificial: el software de inteligencia artificial (IA) hace uso de algoritmos no numéricos para resolver problemas complejos para los que no son adecuados el cálculo o el análisis directo. Los sistemas expertos, también llamados sistemas basados en el conocimiento, reconocimiento de patrones (imágenes y voz), redes neuronales artificiales, prueba de teoremas, y los juegos son representativos de las aplicaciones de esta categoría.
En el proyecto será fundamental el desarrollo de un software cuya funcionalidad es capturar todos los datos que registraran las tarjetas en los lectores RFID, que posteriormente almacene dicha información y esta se pueda mostrar en forma de registros y este estará integrado al sistema de información de la universidad.
2.1.6 Inteligencia artificial
El contenido de inteligencia artificial es de suma importancia en el contexto de este proyecto, debido a que los elementos involucrados en la implementación de RFID, bases de datos y software utilizan en gran parte estas teorías de la IA para lograr que los sistemas sustituyan a las personas en diferentes tareas; algunos ejemplos de los usos de inteligencia artificial se pueden observar en la ejecución de un sistema al enviar las órdenes para capturas de datos, permitir el acceso del personal universitario, almacenar y corroborar datos.
Leija en 2009 afirmó que:
Actualmente, cuando se investiga en el campo de la inteligencia artificial se persiguen dos objetos complementarios, que ponen su énfasis, respectivamente, en aspectos teóricos o aplicados. Por un lado se estudian los procesos cognitivos en general considerando la inteligencia como computación; cómo los ordenadores pueden ser útiles para la comprensión de los principios que hacen posible la inteligencia. De aquí nacen múltiples puntos de contacto de la inteligencia artificial con ciencias como, por ejemplo, neurofisiología, la lógica formal y la lingüística. Por otro lado, la inteligencia artificial intenta obtener sistemas automáticos que puedan realizar tareas reservadas a los humanos. Aquí la inteligencia artificial aparece como una
30
disciplina eminentemente tecnológica que persigue la construcción de máquinas y programas capaces de llevar a cabo tareas complejas con una competencia y eficiencia iguales o superior a la de los humanos.
2.1.7 Telecomunicaciones
Según Martinez, 2011:
Las telecomunicaciones actualmente son de vital importancia, por medio de estas es posible enviar información a lugares cercanos y lejanos en fracciones de segundos y minutos respectivamente. Hoy en día muchos de nosotros sabemos usar estos servicios, y lo vemos relativamente fácil de usar ya se ha convertido en algo cotidiano; es importante tener en cuenta que cuando los utilizamos por primera vez se dificulto un poco, sin embargo al paso de estar empleando estos servicios nos hemos familiarizado lo suficiente de manera que ahora los manejamos con facilidad.
Martinez en 2011 afirmabá que:
Las telecomunicaciones se han convertido en una de las actividades más utilizadas alrededor del mundo. Huber las denomina el tele cosmos pues, en su opinión, las mismas se están expandiendo más rápidamente que cualquier otro cosmos, Esto se debe a que, en la última década, los medios que se utilizaban para llevar a cabo las comunicaciones han aumentado la capacidad para enviar información por más de un millón de veces.
El proyecto en su gran mayoría tiene que ver con las telecomunicaciones, pues la tecnología que aplica es un campo de las telecomunicaciones que es la radiofrecuencia. Las tarjetas RFID envían señales a los lectores y estos envían los datos que se van a almacenar tanto en el software como en la base de datos de la universidad.
31
2.2 Marco contextual
2.2.1 Risaralda
“Se encuentra en el centro del llamado eje cafetero, forma parte de la región paisa de Colombia y se caracteriza por ser productor de café, caña de azúcar, plátano, yuca y cacao, entre otros.” (Ministerio de Educacion Nacional, Colombia, s.f.)
2.2.1.1 Localización:
“El departamento de Risaralda es una entidad territorial ubicada en el sector central de la región andina, centro occidente de Colombia. Su exposición geográfica está determinada por las coordenadas de sus límites extremos: entre los 5º32´ y 4º39´ de latitud norte y entre 75º23´y 76º18´ de longitud al oeste del meridiano 0º de Greenwich.” (Gobernacion, Risaralda, s.f.)
2.2.2 Pereira
Expone la Alcaldía de Pereira en su página web que:
El Municipio de Pereira está localizado a 4 grados 49 minutos de latitud norte, 75 grados 42 minutos de longitud y 1.411 metros sobre el nivel del mar; en el centro de la región occidental del territorio colombiano, en un pequeño valle formado por la terminación de un contra fuerte que se desprende de la cordillera central. Su estratégica localización central dentro de la región cafetera, lo ubica en el panorama económico nacional e internacional, estando unido vialmente con los tres centros urbanos más importantes del territorio nacional y con los medios tanto marítimos como aéreos de comunicación internacionales.
2.2.3 Universidad Católica de Pereira
2.2.3.1 Historia:
“La Universidad Católica de Pereira (antes Universidad Católica Popular del Risaralda) nació gracias a la iniciativa, la capacidad emprendedora y decisión de un grupo de estudiantes que deseaban una alternativa académica diferente a las existentes en la ciudad de Pereira, para su formación profesional. En medio de
32
grandes limitaciones financieras y académicas lograron crear un centro de estudios que llamaron "Fundación Autónoma Popular del Risaralda", en el cual se ofrecían los programas de Derecho y Economía Industrial.” (Universidad Católica de Pereira, s.f.)
2.2.3.2 La UCP hoy
“Actualmente la Universidad Católica de Pereira está ubicada en un área construida de 13.181 m2 y cuenta con una población cercana a los 3.000 estudiantes, 180 profesores y 100 colaboradores entre directivos, administrativos y servicios generales, todos trabajando al servicio de una misma causa: "SER APOYO PARA LLEGAR A SER GENTE, GENTE DE BIEN Y PROFESIONALMENTE CAPAZ". ”(Universidad Católica de Pereira, s.f.)
En la Universidad Católica en promedio ingresan unas 1.100 personas por día y semanalmente unas 6.000 personas. A ciencia cierta no se tiene un dato exacto, debido a que el actual sistema es muy fácil de evadir ya que no se cuenta con un estricto control en la entrada, entonces muchas personas no se registran. La idea del sistema propuesto es tener una estadística actualizada y fiable de que la información es exacta.
Imagen 6: Universidad Católica de Pereira Fuente: Página web de la Universidad Católica de Pereira
2.3 Antecedentes
En el contexto de control de acceso basado en tecnología RFID se encuentran varias empresas y proyectos en los cuales se puede evidenciar la importancia y lo útil que puede resultar manejar esta tecnología.
33
También se encuentran diversos proyectos distintos a control de acceso en los cuales se aprovechan al máximo los beneficios de la identificación por radio frecuencia.
2.3.1 Ondas de radiofrecuencia para localizar libros.
Este es un proyecto universitario realizado en la ciudad de Madrid, en la Universidad Politécnica de Madrid, en el cual implementaron un sistema de RFID para la mejora en los diferentes procesos que se manejan en la biblioteca de dicha universidad tales como: inventarios, préstamos, devoluciones, consultas y movimientos de los libros, etc.
RFID en las instalaciones de la Biblioteca Universitaria de la UPM
“La Biblioteca Universitaria ha dotado y financiado el equipamiento de radiofrecuencia completo para la Biblioteca de la ETSI Telecomunicaciones, como proyecto piloto para la implantación de esta tecnología en el resto de las bibliotecas de la UPM a medio-largo plazo, según la disponibilidad presupuestaria. Se espera contar con esta tecnología también en la nueva Biblioteca del Campus Sur, que está en fase de construcción actualmente.” (Universidad Politecnica de Madrid, s.f.)
Imagen 7: Logo de Universidad Politécnica de Madrid Fuente: Página web Universidad Politécnica de Madrid
34
2.3.2 Disney World sustituye las entradas por pulseras RFID
Disney ha implementado la tecnología RFID para el acceso de los visitantes del parque, esto fue diseñado en una pulsera en la cual están incluidas dos etiquetas pasivas RFID. Esta idea se ejecuta a raíz de la necesidad del parque de mejorar la agilidad en las entradas de las atracciones sustituyendo los pagos de tarjetas y efectivo, también para conocer más a sus clientes, ya que en las etiquetas son incluidos los datos del cliente que porte la pulsera. Con esta misma pulsera los usuarios pueden acceder a las diferentes opciones de entretenimiento que brinda el parque.
En Panda ID soluciones, 2012 describen:
La pulsera está completamente sellada para evitar que los niños puedan extraer los componentes. Además es resistente al agua, para que los visitantes puedan llevarla siempre puesta durante todo el día, incluso mientras están disfrutando de las atracciones acuáticas, como la Splash Mountain. Se puede personalizar con el nombre del usuario, para que resulte más fácil de identificar, especialmente en los viajes en grupo. En la fotografía aportada para la solicitud ante la FCC, figura una advertencia: la pulsera no es transferible y la misma persona debe usarla cada vez que visite el parque. Además puede verse estampado el nuevo logotipo de Mickey, el de nueva generación.
El servicio es capaz de manejar de forma personalizada cada experiencia gracias al almacenamiento del nombre, fecha de nacimiento, recorrido por los parques y preferencias durante la visita. También es posible controlar estos valores por parte del usuario si se desea proteger algunos detalles de identidad. En cuanto al control de consumo, se podrá indicar un PIN para determinar límites de pago o restricciones.
Imagen 8: Logo de Disney World
35
Fuente: http://purpleroofs.com/gay-travel-blog/2014/02/visiting-walt-disney-world-without-kids.html
2.3.3 Diseño de guías para prácticas para el control de inventarios por medio
de tecnologías RFID, CB, GPS, sensores.
En la universidad ICESI de Cali se creó un proyecto pedagógico, el cual enseña y hace prácticas para el manejo logístico para los controles de inventarios, campo de la ingeniería industrial, innovando con nuevas herramientas tecnológicas, como lo son RFID, CB, GPS y sensores. Los autores expresan en su documento la necesidad de que los ingenieros industriales se adapten cada día mas a los beneficios que ofrecen diferentes tecnologías.
Collazos & Lopez en 2011 explicabán que:
La necesidad de tecnologías para lograr un seguimiento en tiempo real de los inventarios de una organización y una cadena de abastecimiento inteligente, conduce a pensar que es necesario que los egresados de Ingeniería Industrial de la Universidad ICESI tengan competencias que les permitan enfrenarse a estas tecnologías en ambientes reales. Encontrar como lograr que los nuevos profesionales lleguen preparados para enfrentar esta situación es el problema del proyecto .Para ello se llevará a cabo el diseño de prácticas de control de inventarios por medio de dichas tecnologías, que permitan el acercamiento del estudiante a situaciones reales que contribuyan más tarde a un mejor desempeño laboral.
2.3.4 La mayonesa Helmann’s utiliza RFID para fidelizar a sus clientes.
En un supermercado de São Paulo – Brasil, los clientes reciben información sobre
recetas en pantallas que tienen incluidos los carros de compra por medio de la
tecnología RFID.
36
Imagen 9: Logo de la marca de mayonesa Hellman's Fuente: http://www.marketing4food.com/marketing-de-salsas-el-ticket-del-
supermercado-ensena-a-combinar-los-alimentos-con-la-mayonesa-
hellmann%C2%B4s/
La marca de mayonesas Hellman’s en una estrategia de mercadeo implemento la
tecnología para promocionar su marca. Se instalaron tabletas de UHF en los carritos
de compra y antenas y lectores RFID en las estanterías del supermercado. Cuando
pasan por el lado de algún producto, en las tabletas muestra una receta o
recomendación para combinar la mayonesa con dicho producto, asi el consumidor
encuentra gran atracción por el producto. Esta aplicación también permite interactuar
con el usuario para encontrar los ingredientes necesarios para dicha receta dentro
de la tienda y hasta permite compartir la receta en redes sociales.
Gran idea publicitaria para atraer clientes aprovechando las ventajas de la
tecnología.
2.3.5 La tecnología de RFID obtiene buenos resultados en el Abierto de
Australia
La Comunidad de RFID en Latinoamérica en 2009 evidenciaban que:
Más de veinte mil aficionados presentes en el torneo de tenis del Abierto de
Australia, celebrado en el Melbourne Park en enero, usaron la identificación
por radiofrecuencia para hacerse unas fotos y para ganar premios,
37
comunicarse con amigos a través de Facebook o recibir un viaje de cortesía
para volver al centro de la ciudad.
Tennis Australia —que organizó el Abierto de Australia y es el órgano rector
del tenis en el país— adoptó la tecnología como parte de su experiencia para
aficionados Open Interactive, que permite que los visitantes se inscriban para
obtener un cordón habilitado con RFID, con el que pueden tocar los lectores
de RFID que se encuentran en los stands de los patrocinadores y, así, recibir
beneficios y ganar premios.
Imagen 10: Logo Australian Open Fuente: http://www.rfidpoint.com/casos-de-exito/la-tecnologia-de-rfid-obtiene-
buenos-resultados-en-el-abierto-de-australia/
2.3.6 Gran hospital español adopta RFID para la gestión de pacientes y bienes
Comunidad de RFID en Latinoamérica, 2009 expone que:
El Hospital Universitario de Valencia (La Fe) está utilizando un sistema de
localización en tiempo real (RTLS) para hacer un seguimiento de los pacientes y
los bienes en sus instalaciones de 260.000 metros cuadrados (2,8 millones de
pies cuadrados), y para permitir que los empleados identifiquen a los pacientes a
través de carros móviles con lectores de RFID incorporados. La tecnología fue
suministrada por MySphera, una división de TSB Group. La solución ofrece al
hospital poder ver el lugar donde se encuentran los pacientes y los bienes, a fin
de mejorar la calidad de la atención brindada, acelerando y facilitando la
38
búsqueda de los equipos, los pacientes y el personal, y para hacerlo de manera
más segura, ya que también sirve para garantizar que cada paciente reciba el
medicamento adecuado o la atención que corresponda; así, se reduce el riesgo
de cometer errores.
39
3 Propuesta metodológica
3.1 Metodología y presupuesto
OBJETIVO ACTIVIDAD TÉCNICA INSTRUMENTOS COSTOS
MENSUALES
Identificar las debilidades que
se deben corregir en el
sistema actual de ingreso de la
comunidad universitaria de
la UCP
Indagar sobre la necesidad de la UCP de un sistema de ingreso más seguro
Realizar encuestas a la comunidad de la UCP y entrevistas con personal del área administrativa
Imprimir cuestionarios
$ 640.000
Comparar el ingreso a la UCP con el de otras universidades de la ciudad
Observar la entrada de otras universidades y hacer fotos para compararlas con la entrada de la UCP
Cámara fotográfica
$ 800.000
Software para edición
Plantear posibles
soluciones aplicables al
nuevo sistema de control de
acceso, a través de la
tecnología RFID y evaluar los costos de la
implementación de las nuevas tecnologías
Recolectar requisitos del nuevo sistema
Realizar entrevistas con personas de gestión tecnológica, área administrativa y de seguridad
Lluvia de ideas
$3.000.000
Estadísticas
Reuniones
Buscar información acerca de la nueva tecnología que se quiere implantar
Utilizar información disponible en internet y medios físicos como libros y personas expertas
Internet
Libros
Consulta de expertos
Evaluar los recursos humanos, equipos que se necesitan,
Realizar cotizaciones con diferentes proveedores de tecnología,
Software para evaluar costos (COCOMO)
Internet
40
buscar diferentes marcas y referencias para encontrar un punto de equilibrio en los costos
evaluar el costo para el proyecto de cada empleado según la base de datos de salarios del estado
Entrevistas
Implementar un sistema de información
para llevar un control de los horarios de entrada y
salida, almacenando
los ingresos en una base de
datos
Levantar requerimientos
Elaborar el producto software ceñido a metodologías (a definir) y haciendo uso de buenas prácticas a lo largo del proyecto y utilizando software especializado en el tema
IDEs de programación
$ 3.000.000
Análisis y diseño del sistema (incluyendo la conexión a la base de datos de la universidad)
Computadores
Elaborar prototipo
Documentación
Testing Metodologías
Instalar el sistema
diseñado en la planta física de la universidad
Hacer una prueba piloto con el prototipo software y hardware elaborado
Instalar el software en las máquinas de la UCP, conectar la base de datos y conectar el hardware RFID
Hardware adquirido y software elaborado en el proyecto
$ 5.475.054
TOTAL $12.915.054
Tabla 2: Metodología y presupuesto
41
3.2 Cronograma
CRONOGRAMA
ID MAYO JUNIO JULIO AGOSTO SEPTIEMBRE OCTUBRE NOVIEMBRE DICIEMBRE ENERO FEBRERO MARZO ABRIL
A
B
C
D
E
F
G
H
I
J
Tabla 3: Cronograma
A = Indagar sobre la necesidad de la UCP de un sistema de ingreso más seguro. B = Comparar el ingreso a la UCP con el de otras universidades de la ciudad. C = Recolectar requisitos del nuevo sistema. D = Buscar información acerca de la nueva tecnología que se quiere implantar. E = Evaluar los recursos humanos, equipos que se necesitan, buscar diferentes marcas y referencias para encontrar un punto de equilibrio en los costos. F = Levantar requerimientos. G = Análisis y diseño del sistema (incluyendo la conexión a la base de datos de la universidad). H = Elaborar prototipo. I = Testing. J = Hacer una prueba con el prototipo software y hardware elaborado.
42
4 Presentación y Análisis de resultados
4.1 Propuestas de soluciones para el control de acceso
En esta sección se presentaran algunas propuestas para la optimización de los
portales de control de acceso a la universidad, se describirá cada una de ellas
expresando las posibles ventajas y desventajas que se podrían dar en cada
escenario.
4.1.1 Opción 1 de entrada principal.
Imagen 11: Primera propuesta de portal principal del control de acceso Fuente: Elaboración propia
Esta propuesta implica la instalación de dos talanqueras, ambas funcionarían para la
entrada y salida de los estudiantes; además de contar con un computador que
contenga el software de control de acceso conectado a la base de datos en tiempo
real de la universidad para validar la entrada de las personas a la universidad. Las
ventajas de este modelo están en el hecho que agilizaría la entrada de varias
personas al tiempo. Las desventajas vienen en el momento en que una persona
quiera salir y otra entrar por la misma talanquera al mismo tiempo, también cuando
varios usuarios se registren en ambas talanqueras será más complicado llevar
control de cada uno.
43
4.1.1.1 Costos
Cantidad Elemento Valor unidad Valor total
2 Lector RFID USB SL040A $2.220.168 $4.440.336
1 Software $2.619.441 $2.619.441
2 Talanquera $4.225.000 $8.450.000
3000 Etiquetas $1.291 $3.874.200
Total $19.383.977
Tabla 4: Estimación de costos de la primera propuesta
4.1.2 Opción 2 de entrada principal
Imagen 12: Segunda propuesta de portal principal del control de acceso Fuente: Elaboración propia
Un solo acceso para entrada y salida de personas a la universidad, un computador
con el software de validación de acceso y conexión a la base de datos. Este modelo
es similar al que existe actualmente, la ventaja es que este sistema sí obliga a la
persona a registrarse antes de entrar y antes de salir, pero al momento de llegar
varias personas a la vez generaría retraso
44
4.1.2.1 Costos
Cantidad Elemento Valor unidad Valor total
1 Lector RFID USB SL040A $2.220.168 $2.220.168
1 Software $2.619.441 $2.619.441
1 Talanquera $4.225.000 $4.225.000
3000 Etiquetas $1.291 $3.874.200
Total $12.938.809
Tabla 5: Estimación de costos de la segunda propuesta
4.1.3 Opción 3 de la entrada principal
Imagen 13: Tercera propuesta de portal principal del control de acceso Fuente: Elaboración propia
En esta se utilizan dos talanqueras, una que funciona como entrada y otra como salida de personas, ambas ligadas a la base datos de la universidad y conectadas al software de control de acceso. Las ventajas de este modelo son que las personas ingresan por una talanquera y hacen su registro mientras por la otra talanquera las personas que van a salir generan su registro y salen sin retraso, este modelo de portal que se acomoda mejor a las necesidades de la universidad.
45
4.1.3.1 Costos
Cantidad Elemento Valor unidad Valor total
2 Lector RFID USB SL040A $2.220.168 $4.440.336
1 Software $2.619.441 $2.619.441
2 Talanquera $4.225.000 $8.450.000
3000 Etiquetas $1.291 $3.874.200
Total $19.383.977
Tabla 6: Estimación de costos de la segunda propuesta
4.1.4 Opción 1 para la puesta trasera.
Imagen 14: Primera propuesta de portal trasero Fuente: Elaboración propia
En esta se utilizan dos lectores RFID uno a cada lado de la puerta, ambos ligados a
la base datos de la universidad y conectadas al software de control de acceso. La
desventaja de este modelo es que si una persona ingresa en un vehículo con
acompañantes estos no se registran.
46
4.1.4.1 Costos
Cantidad Elemento Valor unidad Valor total
2 Lector RFID USB SL040A $2.220.168 $4.440.336
1 Software $2.619.441 $2.619.441
1 Puerta corrediza $1.250.000 $1.250.000
3000 Etiquetas $1.291 $3.874.200
Total $12.193.977
Tabla 7: Estimación de costos de la segunda propuesta
4.2 Propuesta para código EPC del proyecto
Para la organización y control de las etiquetas que serán asignadas a las personas
de la comunidad universitaria, basados en los estándares de EPC global, se ha
diseñado un modelo propio para la asignación y distribución de dichas tarjetas
teniendo en cuenta el esquema organizacional de la Universidad Católica de Pereira
como se observa en la Imagen 16. Teniendo en cuenta dicho esquema, se
asignaron códigos a cada programa, departamento, facultad o dependencia,
clasificándolos de manera jerárquica como se mostrará a continuación:
Imagen 15: Construcción de código del proyecto Fuente: Elaboración propia
Cada Hexteto tiene un grupo determinado tomando como base la estructura
organizacional anteriormente mencionada y toman su propio código de la siguiente
manera:
47
Primer Hexteto:
Esta primera parte tiene un código único que identifica a la persona como
perteneciente a la Universidad Católica de Pereira. El código que lo identificara será
el 1000.
Segundo Hexteto:
Este segundo hexteto tiene cuatro posibles códigos, dependiendo de si la persona
pertenece a la rama de la rectoría, de vicerrectoría académica, vicerrectoría de
proyecto de vida o a la dirección administrativa y financiera. Los códigos asignados
son los siguientes:
Nombre Código
Rectoría 1100
Vicerrectoría académica 1200
Vicerrectoría de proyecto de vida 1300
Dirección administrativa y financiera 1400
Tabla 8: Códigos del segundo hexteto Fuente: Elaboración propia
Tercer hexteto: En esta dispuesta para cada uno de los componentes de las ramas
mencionadas en el segundo hexteto y estarán clasificadas de la siguiente forma:
Nombre Codigo
Secretaria general 1110
Dirección de planeación y calidad 1120
Internacionalización y relaciones institucionales 1130
Comunicaciones 1140
Dirección de proyecto social 1210
Dirección de investigaciones e innovación 1220
Admisiones y registro 1230
Biblioteca Cardenal Darío Castrillón 1240
Prácticas Académicas 1250
Idiomas 1260
Graduados 1270
48
Virtualización 1280
Emprendimiento 1290
Facultad de Ciencias Económicas y Administrativas 12A0
Administración de Empresas 12A1
Negocios Internacionales 12A2
Economía 12A3
Mercadeo (programa) 12A4
Tecnología en mercadeo 12A5
Tecnología en Gestión de Empresas Agroindustriales 12A6
Técnica Profesional en Operaciones y Logística en Empresas Agroindustriales
12A7
Maestría en Gestión del Desarrollo Regional 12A8
Especialización en Finanzas 12A9
Especialización en Economía Pública y Gestión Territorial 12AA
Facultad de Ciencias Humanas, Sociales y de la Educación 12B0
Sicología 12B1
Comunicación Social – Periodismo 12B2
Licenciatura en Educación Religiosa 12B3
Maestría en Pedagogía y Desarrollo Humano 12B4
Maestría en Estudios Culturales 12B5
Especialización en Pedagogía y Desarrollo Humano 12B6
Especialización en Edumática Innovación de los procesos educativos a través de herramientas multimediales
12B7
Especialización en Gerencia de la Comunicación Corporativa 12B8
Especialización en Psicología Clínica con énfasis en Psicoterapia con niños y adolescentes
12B9
Especialización en Intervenciones Psicosociales para la Reducción del Consumo de Sustancias Psicoactivas
12BA
Especialización en Psicología Social Comunitaria y Acción Psicosocial 12BB
Especialización en Gestión Humana en las Organizaciones 12BC
Facultad de Arquitectura y Diseño 12C0
Arquitectura 12C1
Diseño Industrial 12C2
Especialización en Arquitectura y Urbanismo Bioclimatico 12C3
Especialización en Gestión de Proyectos de Diseño e Innovación 12C4
Facultad de Ciencias Básicas e Ingeniería 12D0
Ingeniería de Sistemas y Telecomunicaciones 12D1
Ingeniería Industrial 12D2
Tecnología en Sistemas 12D3
Especialización en Desarrollo del Software 12D4
Contable y Financiera 1310
Gestión de Tecnología 1320
Gestión del Talento Humano 1330
Mercadeo (departamento) 1340
Servicios Generales y Logística 1350
Desarrollo Humano 1410
49
Pastoral Universitaria 1420
Acompañamiento Académico 1430
Bienestar Social 1440
Recreación y Deportes 1450
Expresión Cultural 1460
Centro de Familia 1470
Tabla 9: Códigos del tercer Hexteto Fuente: Elaboración propia
Cuarto Hexteto: En este último hexteto se representa la identificación de cada
persona, el cual incrementara secuencialmente con el ingreso en el sistema.
Imagen 16: Esquema organizacional UCP Fuente: Dirección de Planeación y Calidad. Universidad Católica de Pereira
4.3 Ingeniería de software para el proyecto
Anteriormente se mencionó de la importancia de la ingeniería del software durante
un proyecto, pues este nos da una mejor orientación para desarrollar todo lo que el
sistema nos exige. A continuación se exponen los diferentes elementos e
instrumento que se han utilizado para la planeación y el diseño del proyecto.
50
4.3.1 Requerimientos
Se han analizado todos los escenarios y posibles formas para el desarrollo del
software que se implementara. Después de una profunda indagación desde varios
puntos de vista de personas que posiblemente utilizarían el sistema de control de
acceso se dictaminaron los siguientes requerimientos:
UNIVERSIDAD CATÓLICA DE PEREIRA (UCP)
ESPECIFICACIÓN DE REQUERIMIENTOS
Andrés Felipe Vallejo Piedrahita Juan Sebastián Rivera Henao
Proyecto: Control de acceso de la universidad católica de Pereira con tecnología RFID
Información del requerimiento
Nombre: Mostrar información
# de requerimiento:
001 Tipo de requerimiento:
Funcional Fecha: 1/09/2015
Descripción: El sistema deberá mostrar la información de cada persona que ingrese a la universidad (nombre, código, carrera, hora de entrada, foto, cargo)
Responsable: Andrés Vallejo – Sebastián Rivera
Estado:
Observaciones
Versión: 1
Prioridad: Alta
Tabla 10: Requerimiento 001 Fuente: Elaboración propia
51
UNIVERSIDAD CATÓLICA DE PEREIRA (UCP)
ESPECIFICACIÓN DE REQUERIMIENTOS
Andrés Felipe Vallejo Piedrahita Juan Sebastián Rivera Henao
Proyecto: Control de acceso de la universidad católica de Pereira con tecnología RFID
Información del requerimiento
Nombre: Tipo de personal
# de requerimiento:
002 Tipo de requerimiento:
Funcional Fecha: 1/09/2015
Descripción: El sistema debe reconocer los siguientes tipos de personal: Estudiante, Administrativo, docente, visitante, oficios varios, egresado
Responsable: Andrés Vallejo – Sebastián Rivera
Estado:
Observaciones
Versión: 1
Prioridad: Baja
Tabla 11: Requerimiento 002 Fuente: Elaboración propia
52
UNIVERSIDAD CATÓLICA DE PEREIRA (UCP)
ESPECIFICACIÓN DE REQUERIMIENTOS
Andrés Felipe Vallejo Piedrahita Juan Sebastián Rivera Henao
Proyecto: Control de acceso de la universidad católica de Pereira con tecnología RFID
Información del requerimiento
Nombre: Reportes
# de requerimiento:
003 Tipo de requerimiento:
Funcional Fecha: 1/09/2015
Descripción: El sistema debe permitir la generación de reportes diarios, semanales y mensuales de registro de ingreso de personas.
Responsable: Andrés Vallejo – Sebastián Rivera
Estado:
Observaciones
Versión: 1
Prioridad: Alta
Tabla 12: Requerimiento 003 Fuente: Elaboración propia
53
UNIVERSIDAD CATÓLICA DE PEREIRA (UCP)
ESPECIFICACIÓN DE REQUERIMIENTOS
Andrés Felipe Vallejo Piedrahita Juan Sebastián Rivera Henao
Proyecto: Control de acceso de la universidad católica de Pereira con tecnología RFID
Información del requerimiento
Nombre: Validación de etiquetas
# de requerimiento:
004 Tipo de requerimiento:
Funcional Fecha: 1/09/2015
Descripción: Cada persona tendrá en su carné universitario una etiqueta RFID asociada que contendrá los datos de identificación, los cuales serán validados por el sistema.
Responsable: Andrés Vallejo – Sebastián Rivera
Estado:
Observaciones
Versión: 1
Prioridad: Alta
Tabla 13: Requerimiento 004 Fuente: Elaboración propia
54
UNIVERSIDAD CATÓLICA DE PEREIRA (UCP)
ESPECIFICACIÓN DE REQUERIMIENTOS
Andrés Felipe Vallejo Piedrahita Juan Sebastián Rivera Henao
Proyecto: Control de acceso de la universidad católica de Pereira con tecnología RFID
Información del requerimiento
Nombre: Seguridad
# de requerimiento:
005 Tipo de requerimiento:
No Funcional
Fecha: 1/09/2015
Descripción: Quien vaya a manipular el sistema debe tener un usuario y contraseña para acceder.
Responsable: Andrés Vallejo – Sebastián Rivera
Estado:
Observaciones
Versión: 1
Prioridad: Media
Tabla 14: Requerimiento 005 Fuente: Elaboración propia
55
UNIVERSIDAD CATÓLICA DE PEREIRA (UCP)
ESPECIFICACIÓN DE REQUERIMIENTOS
Andrés Felipe Vallejo Piedrahita Juan Sebastián Rivera Henao
Proyecto: Control de acceso de la universidad católica de Pereira con tecnología RFID
Información del requerimiento
Nombre: Lenguaje
# de requerimiento:
006 Tipo de requerimiento:
No Funcional
Fecha: 1/09/2015
Descripción: El software será desarrollado en el lenguaje Java y la base de datos en MySQL
Responsable: Andrés Vallejo – Sebastián Rivera
Estado:
Observaciones
Versión: 1
Prioridad: Baja
Tabla 15: Requerimiento 006 Fuente: Elaboración propia
56
UNIVERSIDAD CATÓLICA DE PEREIRA (UCP)
ESPECIFICACIÓN DE REQUERIMIENTOS
Andrés Felipe Vallejo Piedrahita Juan Sebastián Rivera Henao
Proyecto: Control de acceso de la universidad católica de Pereira con tecnología RFID
Información del requerimiento
Nombre: Base de datos
# de requerimiento:
007 Tipo de requerimiento:
Funcional Fecha: 15/09/2015
Descripción: El sistema deberá contar con una base de datos en la cual almacenara la información de todo el personal de la universidad, además de generar reportes de entrada con fecha y hora.
Responsable: Andrés Vallejo – Sebastián Rivera
Estado:
Observaciones
Versión: 1
Prioridad: Alta
Tabla 16: Requerimiento numero 007 Fuente: Elaboración propia
57
UNIVERSIDAD CATÓLICA DE PEREIRA (UCP)
ESPECIFICACIÓN DE REQUERIMIENTOS
Andrés Felipe Vallejo Piedrahita Juan Sebastián Rivera Henao
Proyecto: Control de acceso de la universidad católica de Pereira con tecnología RFID
Información del requerimiento
Nombre: Módulo administrador
# de requerimiento:
008 Tipo de requerimiento:
Funcional Fecha: 20/09/2015
Descripción: El software tendrá un módulo tipo administrador, el cual podrá controlar la información de las personas registrando, modificando o eliminando los datos.
Responsable: Andrés Vallejo – Sebastián Rivera
Estado:
Observaciones
Versión: 1
Prioridad: Alta
Tabla 17: Requerimiento 008 Fuente: Elaboración propia
58
UNIVERSIDAD CATÓLICA DE PEREIRA (UCP)
ESPECIFICACIÓN DE REQUERIMIENTOS
Andrés Felipe Vallejo Piedrahita Juan Sebastián Rivera Henao
Proyecto: Control de acceso de la universidad católica de Pereira con tecnología RFID
Información del requerimiento
Nombre: Módulo usuario
# de requerimiento:
009 Tipo de requerimiento:
Funcional Fecha: 20/09/2015
Descripción: El software tendrá un módulo tipo usuario, el cual solo podrá consultar la información de las personas, pero no podrá hacer ningún tipo de modificación sobre los mismos.
Responsable: Andrés Vallejo – Sebastián Rivera
Estado:
Observaciones
Versión: 1
Prioridad: Alta
Tabla 18: Requerimiento 009 Fuente: Elaboración propia
59
UNIVERSIDAD CATÓLICA DE PEREIRA (UCP)
ESPECIFICACIÓN DE REQUERIMIENTOS
Andrés Felipe Vallejo Piedrahita Juan Sebastián Rivera Henao
Proyecto: Control de acceso de la universidad católica de Pereira con tecnología RFID
Información del requerimiento
Nombre: Módulo de reportes
# de requerimiento:
010 Tipo de requerimiento:
Funcional Fecha: 20/09/2015
Descripción: Este módulo deberá tener la funcionalidad de que el software permita generar reportes de información relevante y que estos se puedan imprimir en papel.
Responsable: Andrés Vallejo – Sebastián Rivera
Estado:
Observaciones
Versión: 1
Prioridad: Alta
Tabla 19: Requerimiento 010 Fuente: Elaboración propia
60
4.3.2 Diagrama de casos de uso.
Imagen 17: Diagrama de casos de uso Fuente: Elaboración propia
61
ID CU001
Nombre Registrar entrada
Descripción Permite registrar cuando una persona ingresa a la Universidad
Autor Andrés Vallejo
Fecha creación 2/10/2015 Fecha última
modificación
Actores Persona
Precondiciones Una persona llega para ingresar a la universidad
La persona debe portar su carné universitario
Poscondiciones Se ha registrado el ingreso de la persona
Si la persona no se encuentra en la base de datos se ha
informado la invalidez del ingreso
Flujo normal de eventos
1. El actor saca su carné y lo acerca al lector RFID 2. El sistema valida si la persona se encuentra en la base de datos 3. El sistema habilita la entrada 4. El actor ingresa a la universidad
Flujos alternos
o Persona no se encuentra en la base de datos En el paso 2 la persona no se encuentra registrada en la base de datos.
1. El sistema muestra el mensaje de persona no encontrada
2. El sistema no habilita la entrada
Excepciones
o Error de lectura En el paso 1 del flujo normal de eventos el lector RFID no hace una correcta
lectura.
1. El sistema debe generar una alerta de error de lectura
2. El actor debe volver a acercar su carné
Tabla 20: Diccionario de datos CU001 Fuente: Elaboración propia
62
ID CU002
Nombre Buscar persona
Descripción Permite buscar determinada persona en la base de datos
Autor Sebastián Rivera
Fecha creación 2/10/2015 Fecha última
modificación
Actores Administrador, usuario de consulta
Precondiciones Se busca persona por código o por etiqueta
Poscondiciones Se ha informado la existencia de la persona
Flujo normal de eventos
1. El actor realiza la consulta por medio del sistema 2. El sistema valida dicha consulta 3. El sistema muestra información de persona
Flujos alternos
o Persona no es validada por el sistema En el paso 2 la persona no se encuentra registrada en la base de datos.
1. El sistema muestra el mensaje de persona de que la persona no fue
encontrada
Tabla 21: Diccionario de datos CU002 Fuente: Elaboración propia
63
ID CU003
Nombre Iniciar sesión
Descripción Permite a los usuarios iniciar sesión en el sistema
Autor Andrés Vallejo
Fecha creación 2/10/2015 Fecha última
modificación
Actores Administrador, usuario de consulta
Precondiciones El actor ingresa al sistema para iniciar sesión
Poscondiciones El actor a ingresado al sistema
Flujo normal de eventos
1. El actor ingresa a la aplicación 2. El sistema muestra la interfaz de acceso 3. El actor digita su usuario y contraseña 4. El sistema valida el tipo de usuario (administrador o usuario de consulta) 5. El sistema habilita la interfaz permitida según el tipo de usuario
Flujos alternos
o Usuario o contraseña incorrecta En el paso 3 el usuario o contraseña no coincide con los registrados
1. El sistema envía un mensaje de usuario o contraseña incorrecta
2. El actor debe volver a digitar sus credenciales
Tabla 22: Diccionario de datos CU003 Fuente: Elaboración propia
ID CU004
64
Nombre Gestionar persona
Descripción Permite al actor administrador gestionar personas (agregar,
modificar o eliminar)
Autor Sebastián Rivera
Fecha creación 2/10/2015 Fecha última
modificación
Actores Administrador
Precondiciones Administrador solicita gestionar datos de alguna persona
Poscondiciones Se muestra la interfaz correspondiente, según la
elección de administrador
Flujo normal de eventos
1. El actor ingresa a la opción de gestionar personas 2. El sistema muestra las tres opciones para gestionar personas 3. El actor elije la opción que desee en el momento 4. El sistema muestra la interfaz correspondiente
Tabla 23: Diccionario de datos CU004 Fuente: Elaboración propia
ID CU005
65
Nombre Agregar persona
Descripción Permite agregar una nueva persona a la base de datos
Autor Andrés Vallejo
Fecha creación 2/10/2015 Fecha última
modificación
Actores Administrador
Precondiciones En el CU004 el actor eligió la opción de agregar persona
Poscondiciones Se ha agregado una persona a la base de datos
Flujo normal de eventos
1. El actor elige la opción de agregar persona 2. El sistema habilita la interfaz de agregar persona 3. El actor ingresa los datos de la nueva persona 4. El actor confirma el ingreso de la persona 5. El sistema agrega la nueva persona
Flujos alternos
o Ingreso invalido de datos En el paso 3 el actor no ingresa correctamente los datos
1. El sistema informa el error en el ingreso de los datos
2. El actor debe ingresar correctamente los datos
Tabla 24: Diccionario de datos CU005 Fuente: Elaboración propia
ID CU006
66
Nombre Modificar persona
Descripción Permite modificar una persona existente en la base de datos
Autor Andrés Vallejo
Fecha creación 2/10/2015 Fecha última
modificación
Actores Administrador
Precondiciones En el CU004 el actor eligió la opción de modificar
persona
Poscondiciones Se ha modificado una persona en la base de datos
Flujo normal de eventos
1. El actor elige la opción de modificar persona 2. El sistema habilita la interfaz de modificar persona 3. El actor elige la persona que desea modificar 4. El sistema muestra los datos de la persona elegida 5. El actor ingresa los datos que va a modificar de la persona 6. El actor confirma la modificación de los datos de la persona 7. El sistema modifica los datos de la persona
Flujos alternos
o No elije ninguna persona En el paso 3 el actor no selecciona ninguna persona
1. El sistema informa que no se eligió ninguna persona 2. El actor debe elegir correctamente una persona
o Ingreso invalido de datos
En el paso 5 el actor no ingresa correctamente los datos
1. El sistema informa el error en el ingreso de los datos
2. El actor debe ingresar correctamente los datos
Tabla 25: Diccionario de datos CU006 Fuente: Elaboración propia
ID CU007
67
Nombre Eliminar persona
Descripción Permite eliminar una persona de la base de datos
Autor Andrés Vallejo
Fecha creación 2/10/2015 Fecha última
modificación
Actores Administrador
Precondiciones En el CU004 el actor eligió la opción de eliminar persona
Poscondiciones Se ha eliminado una persona de la base de datos
Flujo normal de eventos
1. El actor elige la opción de eliminar persona 2. El sistema habilita la interfaz de eliminar persona 3. El actor elige la persona que desea eliminar 4. El sistema muestra los datos de la persona elegida 5. El actor confirma la eliminación de la persona 6. El sistema elimina la persona de la base de datos
Flujos alternos
o No elije ninguna persona En el paso 3 el actor no selecciona ninguna persona
1. El sistema informa que no se eligió ninguna persona 2. El actor debe elegir correctamente una persona
Tabla 26: Diccionario de datos CU007 Fuente: Elaboración propia
ID CU008
68
Nombre Gestionar usuarios
Descripción Permite al actor administrador gestionar usuarios (agregar,
modificar o eliminar)
Autor Sebastián Rivera
Fecha creación 2/10/2015 Fecha última
modificación
Actores Administrador
Precondiciones Administrador solicita gestionar datos de algún usuario
Poscondiciones Se muestra la interfaz correspondiente, según la
elección de administrador
Flujo normal de eventos
1. El actor ingresa a la opción de gestionar usuarios 2. El sistema muestra las tres opciones para gestionar usuarios 3. El actor elije la opción que desee en el momento 4. El sistema muestra la interfaz correspondiente
Tabla 27: Diccionario de datos CU008 Fuente: Elaboración propia
ID CU009
69
Nombre Agregar usuario
Descripción Permite agregar un nuevo usuario para el acceso al sistema
Autor Andrés Vallejo
Fecha creación 2/10/2015 Fecha última
modificación
Actores Administrador
Precondiciones En el CU008 el actor eligió la opción de agregar usuario
Poscondiciones Se ha agregado un usuario a la base de datos
Flujo normal de eventos
1. El actor elige la opción de agregar usuario 2. El sistema habilita la interfaz de agregar usuario 3. El actor ingresa los datos del nuevo usuario 4. El actor confirma el ingreso del nuevo usuario 5. El sistema agrega el usuario
Flujos alternos
o Ingreso invalido de datos En el paso 3 del flujo normal de eventos el actor no ingresa correctamente los
datos
1. El sistema informa el error en el ingreso de los datos
2. El actor debe ingresar correctamente los datos
o El nombre de usuario ya existe
En el paso 3 del flujo normal de eventos el nombre de usuario ya existe
1. El sistema informa que el nombre de usuario ya existe
2. El actor debe digitar un nombre de usuario disferente
Tabla 28: Diccionario de datos CU009 Fuente: Elaboración propia
ID CU010
70
Nombre Modificar usuario
Descripción Permite modificar la contraseña de un usuario registrado en la
base de datos
Autor Sebastián Rivera
Fecha creación 2/10/2015 Fecha última
modificación
Actores Administrador
Precondiciones En el CU008 el actor eligió la opción de modificar
usuario
Poscondiciones Se ha modificado la contraseña de un usuario en la base
de datos
Flujo normal de eventos
1. El actor elige la opción de modificar usuario 2. El sistema habilita la interfaz de modificar usuario 3. El actor elige el usuario que desea modificar 4. El sistema muestra los datos del usuario elegido 5. El actor ingresa la contraseña que va a modificar 6. El actor confirma la modificación de la contraseña dl usuario 7. El sistema modifica los datos del usuario
Flujos alternos
o No elije ninguna persona En el paso 3 el actor no selecciona ningún usuario
1. El sistema informa que no se eligió ningún usuario 2. El actor debe elegir correctamente un usuario
o Ingreso invalido de datos
En el paso 5 el actor no ingresa correctamente los datos
1. El sistema informa el error en el ingreso de los datos
2. El actor debe ingresar correctamente los datos
Tabla 29: Diccionario de datos CU010 Fuente: Elaboración propia
71
ID CU011
Nombre Eliminar persona
Descripción Permite eliminar un usuario de la base de datos
Autor Sebastián Rivera
Fecha creación 2/10/2015 Fecha última
modificación
Actores Administrador
Precondiciones En el CU008 el actor eligió la opción de eliminar usuario
Poscondiciones Se ha eliminado una persona de la base de datos
Flujo normal de eventos
1. El actor elige la opción de eliminar usuario 2. El sistema habilita la interfaz de eliminar usuario 3. El actor elige el usuario que desea eliminar 4. El sistema muestra los datos del usuario elegido 5. El actor confirma la eliminación del usuario 6. El sistema elimina el usuario de la base de datos
Flujos alternos
o No elije ningún usuario En el paso 3 el actor no selecciona ninguna persona
1. El sistema informa que no se eligió ningún usuario 2. El actor debe elegir correctamente un usuario
Tabla 30: Diccionario de datos CU011 Fuente: Elaboración propia
4.3.3 Diagrama de actividades
72
Imagen 18: Diagrama de actividades general Fuente: Elaboración propia
4.3.4 Diagramas de secuencias
73
Imagen 19: Diagrama de secuencias, entrada de personas Fuente: Elaboración propia
74
Imagen 20: Diagrama de secuencias, gestionar personas Fuente: Elaboración propia
75
Imagen 21: Diagrama de secuencias, iniciar sesión Fuente: Elaboración propia
4.4 Pruebas
Tras todo el montaje y el desarrollo de todas las etapas que se requerían durante el proyecto, se pusieron en marcha diferentes pruebas para garantizar el correcto funcionamiento de todo el sistema. En dicho proceso se realizar 2 tipos de pruebas: pruebas unitarias, las cuales se llevan a cabo por los desarrolladores, quienes prueban la funcionalidad de cada módulo finalizado, confirmando de que todo esté correcto; y las pruebas de usuario, estas son realizadas por una persona ajena al equipo de trabajo de desarrollo de software, con la misión encontrar posibles fallos en el sistema, para así poder realizar las correcciones correspondientes. A continuación se presentan los registros de las pruebas que se realizaron en el proceso.
sd Diagrama de secuencias iniciar sesion
Usuario
Interfaz de
usuario
Sistema
Base de datos
Ingresar (usuario, contraseña)
Validar registro de usuario()
Validar registro de usuario()
Ok()
Ok()
Ofrecer servicios()
76
ID Prueba 001
Nombre Conexión de equipos
Descripción
Prueba de conectividad de los lectores RFID con los computadores, para confirmar la comunicación entre sí.
Procedimiento
Se realiza la conexión física de los lectores por medio del puerto Ethernet, posteriormente se configura la conexión de la red, asignándole al computador la dirección IP 192.168.1.100. Posteriormente se confirma desde el Símbolo del Sistema (cmd) que la conexión esté correcta, haciéndole ping a la dirección del lector.
Resultado
Después de realizar el procedimiento mencionado anteriormente, se obtiene que el ping se envía correctamente y los paquetes están llegando sin problemas.
Tabla 31 Prueba 001
77
ID Prueba 002
Nombre Ingreso a la aplicación
Descripción
Ingresar a la aplicación, digitando el usuario y contraseña.
Procedimiento
Se abre el programa y en la ventana de control de acceso de usuarios se digitan los datos correspondientes al usuario. También se prueba ingresando datos erróneos, para comprobar que se esté validando correctamente la información
Resultado
El sistema valida correctamente la información ingresada y anuncia al usuario cuando ingresa datos incorrectos.
Tabla 32 Prueba 002
78
ID Prueba 003
Nombre Agregar persona
Descripción
Realizar todo el procedimiento correspondiente para agregar una persona nueva al sistema, para confirmar que se hace correctamente el procedimiento.
Procedimiento
Se ingresa al programa con un usuario tipo administrador para elegir la opción de agregar persona, se ingresa al formulario y se digitan todos los campos requeridos de la información de la persona.
Resultados
Cuando se presiona el botón de leer tag se genera un mensaje de error y no ingresa el código EPC correctamente.
El campo de código permite ingresar letras y caracteres especiales.
La opción de cargar foto, después de tomar una foto desde la cámara, no carga la imagen correcta.
El resto de funciones actúan correctamente.
Una vez informados los resultados de las pruebas, se realizan las investigaciones correspondientes, se distribuyen las correcciones y se solucionan satisfactoriamente todos los inconvenientes obtenidos.
Tabla 33 Prueba 003
79
ID Prueba 004
Nombre Buscar persona
Descripción
Confirmar el procedimiento para hacer una búsqueda de cierta persona, en el módulo de administrador.
Procedimiento
Se ingresa a la opción de buscar persona, en este formulario se encuentra una lista con todas las personas que hay almacenadas en el programa. En la parte inferior se encuentra un campo en el cual se puede realizar un filtro por el código de la persona.
Resultado
El sistema filtra correctamente con el código de la persona y muestra toda la información de dicha persona.
Tabla 34 Prueba 004
80
ID Prueba 005
Nombre Modificar-Eliminar persona
Descripción
Comprobar que se esté funcionando debidamente el funcionamiento de modificar los datos de una persona o eliminarla del sistema.
Procedimiento
Se selecciona la opción de Modificar-Eliminar Persona, se selecciona la persona a la que se desee hacer el procedimiento y se elige la acción a realizar (modificar o eliminar).
Resultados
Al elegir la opción de modificar, no carga los datos completos de la persona.
En ninguna de las dos opciones muestra el mensaje de confirmación de la acción.
Al modificar, en el campo de código permite digitar letras y caracteres especiales.
No se recarga la lista de las personas con la nueva información.
Se muestra mensaje de error al eliminar a una persona.
Se verifican los problemas reportados y se realizan las correcciones, en el segundo ciclo de pruebas quedan aprobadas satisfactoriamente.
Tabla 35 Prueba 005
81
ID Prueba 006
Nombre Tomar foto
Descripción
Realizar procedimiento para tomar una foto.
Procedimiento
Cargar la cámara instalada en el computador, por medio del botón Tomar Foto y tomar la foto deseada.
Resultado
Al presionar la X para salir de la cámara cierra todo el programa.
La imagen capturada no queda con el tamaño correcto al mostrarse en el formulario.
Se solucionan correctamente los inconvenientes detectados.
Tabla 36 Prueba 006
82
ID Prueba 007
Nombre Reporte por programa
Descripción
Verificar si se realiza correctamente el proceso de generación de informes filtrándolos por programa.
Procedimiento
Se ingresa al módulo de los reportes y se elige la opción de reportes por programa, allí se filtra la búsqueda eligiendo un programa o departamento.
Resultado
En la tabla del resultado de informes, no muestra si la persona entró o salió.
Se corrige el inconveniente reportado.
Tabla 37 Prueba 007
83
ID Prueba 008
Nombre Reporte por persona
Descripción
Verificar si se realiza correctamente el proceso de generación de informes filtrándolos por persona.
Procedimiento
Se ingresa al módulo de los reportes y se elige la opción de reportes por persona, allí se digita el código de la persona que se desee saber el reporte de sus movimientos.
Resultados
El campo para digitar el código, permite digitar letras y caracteres especiales.
En la tabla del resultado de informes, no muestra si la persona entró o salió.
Se analizan y corrigen los errores reportados.
Tabla 38 Prueba 008
84
ID Prueba 009
Nombre Reporte por cargo
Descripción
Verificar si se realiza correctamente el proceso de generación de informes filtrándolos por cargo.
Procedimiento
Se ingresa al módulo de los reportes y se elige la opción de reportes por cargo, allí se filtra el tipo de cargo que se desee saber la información.
Resultado
En la tabla del resultado de informes, no muestra si la persona entró o salió.
No aparecen todos los cargos definidos por la universidad.
Después de las correcciones, se aprueba el funcionamiento.
Tabla 39 Prueba 009
85
ID Prueba 010
Nombre Reporte por fecha
Descripción
Verificar si se realiza correctamente el proceso de generación de informes filtrándolos por fecha.
Procedimiento
Se ingresa al módulo de los reportes y se elige la opción de reportes por fecha, allí se elige la opción de fecha que se quiera visualizar.
Resultado
En el filtro de rango de días, no se valida que la fecha inicial no sea menos que la fecha final.
En la tabla del resultado de informes, no muestra si la persona entró o salió.
Se realizan las correcciones que se requieres para los resultados reportados.
Tabla 40 Prueba 010
86
ID Prueba 011
Nombre Impresión de informes
Descripción
Imprimir los reportes de entrada y salida obtenidos con los filtros.
Procedimiento
Después de realizar algún filtro de los que se mencionaron anteriormente, se debe presionar el botón de imprimir, esto debe arrojar una impresión de la lista de las personas con toda la información requerida.
Resultado
El documento se imprime correctamente y con toda la información completa.
Tabla 41 Prueba 011
ID Prueba 012
Nombre Validación de ingreso de persona
Descripción
Verificar el procedimiento de validación de ingreso de las personas con su carnet con RFID.
Procedimiento
Se acerca un carnet al lector y el sistema realiza la búsqueda de la persona asociada a esa etiqueta, de esta manera si la persona esta registrada correctamente se mostrara toda la información.
Resultado
En ocasiones no el lector no reacciona al acercarle una etiqueta.
El campo de código aparece modificable.
No muestra mensaje cuando la persona no está registrada.
Se analizan y corrigen los errores reportados en la validación de ingreso.
Tabla 42 Prueba 012
87
4.5 Conclusiones
Al llevar a cabo este proyecto se concluye que la seguridad en la Universidad Católica de Pereira es un tema crítico del cual toda la comunidad se debe apropiar, es un tema de interés en el cual es necesario que se inviertan recursos en la implementación de un sistema que funcione como filtro en las entradas de la universidad, que sea automatizado y esté disponible en cualquier momento, para que se evite el ingreso de personas ajenas a esta comunidad sin previa autorización, se concluye que debe existir un filtro debido a que el sistema actual es vulnerado con facilidad y no es lo suficientemente riguroso.
Con el fin de velar por el bienestar de la comunidad de la Universidad Católica de
Pereira, es necesario almacenar la información de las personas que ingresan
diariamente y mantener esta información disponible para posibilitar el control
estadístico para diversas tareas, tales como: control de asistencia, flujo de personal,
ocupación de espacios en diferentes horas del día, entre otros.
El costo/beneficio de implementar un sistema automático en la Universidad Católica
de Pereira demuestra ser rentable a largo plazo, debido a que, reduce la cantidad de
personal de seguridad, es fiable debido a que obliga a las personas a registrarse, es
un sistema de larga duración, entre otros.
El proyecto impactó de manera positiva a las personas de la comunidad universitaria
que tuvieron la oportunidad de conocerlo, ya que, la gran mayoría reconocen que
existen grandes falencias en los protocolos de seguridad que se tienen en las
entradas de la institución, sienten que esto es algo que se debe mejorar y ven la
tecnología expuesta en este proyecto como viable para ser implementada.
El hardware cumple un rol fundamental en el desarrollo de software, sin este
difícilmente se pueden realizar las pruebas adecuadas y entregar al cliente un
producto funcional y libre de errores; estas herramientas, al igual que la codificación
son un complemento necesario para realizar un software de calidad.
4.6 Problemas
Debido al funcionamiento del sistema RFID, existieron inconvenientes de
compatibilidad con el IDE utilizado (NetBeans), pero se lograron solucionar
con la descarga de algunas librerías y adaptaciones al código.
El alto costo de algunos equipos no permitió realizar algunas pruebas físicas
del sistema, al no tener disponibles las talanqueras propuestas en el modelo,
no se logró probar el prototipo completamente.
88
La puesta a punto del funcionamiento de la cámara digital para la captura de
imágenes fue un proceso con algunos inconvenientes, ya que se realizaron
pruebas con varias librerías que generaban problemas de compatibilidad en
nuevas versiones de Windows.
El almacenamiento de imágenes en la base de datos fue un tema complicado,
debido a que, para ser almacenados correctamente los datos de imágenes,
estos debían ser transformados a un formato compatible.
BIBLIOGRAFIA
89
Kniberg, H. (2007). SCRUM Y XP DESDE LAS TRINCHERAS. Estados Unidos:
InfoQ.
Observatorio Regional de la Sociedad de la Información. (ORSI). (2007). Tecnologia
de identificación por Radiofrecuencia y sus principales aplicaciones.
Recuperado el 24 de 04 de 2015, de Junta de Castilla y Leon:
http://www.jcyl.es/web/jcyl/binarios/211/716/RFID.pdf?blobheader=application
%2Fpdf%3Bcharset%3DUTF-8
Acosta, C., & Diaz, A. (s.f.). Introduccion a los sistemas de informacion. Recuperado
el 24 de 04 de 2015, de Biblioteca Itson:
http://biblioteca.itson.mx/oa/dip_ago/introduccion_sistemas/index.htm
Alcaldía, Pereira. (s.f.). Alcaldia de Pereira. Recuperado el 28 de 04 de 2015, de
http://www.pereira.gov.co/es/ipaginas/ver/G432/102/asi_somos/
Alegsa, L. (20 de 03 de 2009). Alegsa. Recuperado el 13 de 08 de 2015, de
http://www.alegsa.com.ar/Dic/requerimientos.php
Booch, G., Rumbaugh, J., & Jacobson, I. (1999). El lenguaje Unificado de Modelado.
Madrid: Addison Wesley Iberoamericana.
Burch, J., & Grudnitski, G. (1994). Diseño de sistemas de informacion. Limusa.
Collazos, A. M., & Lopez, E. P. (25 de 11 de 2011). diseño_guias_practicas Diseño
de guias para practicas para el contol de inventarios por medio de tecnologias
RFID, CB, GPS, sensores. Recuperado el 08 de 05 de 2015, de Biblioteca
digital Icesi:
http://bibliotecadigital.icesi.edu.co/biblioteca_digital/bitstream/10906/68612/1/d
ise%C3%B1o_guias_practicas.pdf
Comunidad de RFID en Latinoamérica. (15 de 07 de 2009). La comunicad de RFID
en Latinoamerica. Recuperado el 28 de 10 de 2015, de
http://www.rfidpoint.com/preguntas-frecuentes/frecuencias-de-operacion-2/
Gobernacion, Risaralda. (s.f.). Gobernacion de Risaralda. Recuperado el 28 de 04
de 2015, de http://www.risaralda.gov.co/site/main/web/es/generalidades-del-
departamento_10#generalidades
ISO. (s.f.). ISO. Recuperado el 29 de 10 de 2015, de ISO:
http://www.iso.org/iso/home.html
Leija, L. (2009). Métodos de procesamiento avanzado e inteligencia artificial en
sistemas sensores y biosensores. Mexico: Reverté.
90
Martinez, A. (04 de 08 de 2011). Tecnologico de estudios superiores del oriente del
estado de Mexico. Recuperado el 09 de 05 de 2015, de Tecnologico de
estudios superiores del oriente del estado de Mexico:
http://www.tesoem.edu.mx/alumnos/cuadernillos/2011.040.pdf
Metodología Gestion de requerimientos. (s.f.). Metodología Gestion de
requerimientos. Recuperado el 18 de 08 de 2015, de
https://sites.google.com/site/metodologiareq/capitulo-iii
Ministerio de Educacion Nacional, Colombia. (s.f.). Colombia aprende. Recuperado
el 28 de 04 de 2015, de
http://www.colombiaaprende.edu.co/html/productos/1685/article-140770.html
Norris, M., & Rigby, P. (1994). Ingeniería del software explicada. BT, Gran Bretaña:
Noriega editores.
Panda ID soluciones. (11 de 10 de 2012). DISNEY WORLD SUSTITUYE LAS
ENTRADAS POR PULSERAS RFID. Recuperado el 07 de 05 de 2015, de
Panda ID soluciones: http://www.pandaid.com/disney-world-sustituye-las-
entradas-por-pulseras-rfid/
Panda ID soluciones. (16 de 01 de 2013). DISNEY WOLD RENUEVA LA
EXPERIENCIA EN SUS PARQUES CON RFID. Recuperado el 07 de 05 de
2015, de Panda ID soluciones: http://www.pandaid.com/disney-wold-renueva-
la-experiencia-en-sus-parques-con-rfid/
Peris López, P. (10 de 2008). LIGHTWEIGHT CRYPTOGRAPHY IN RADIO
FREQUENCY IDENTIFICATION (RFID) SYSTEMS. Recuperado el 29 de 10
de 2015, de Universidad Carlos III de Madrid:
http://orff.uc3m.es/bitstream/handle/10016/5093/Tesis_Pedro_Peris_Lopez.pd
f?sequence=1
Pressman, R. (2002). Ingeniería del software, un enfoque práctico. Madrid: Mc Graw
Hill.
Schwaber, K., & Sutherland, J. (07 de 2013). SCRUM GUIDES. Recuperado el 30 de
03 de 2016, de http://www.scrumguides.org/docs/scrumguide/v1/Scrum-
Guide-ES.pdf
Sommerville, I. (2005). Ingenieria del software. Madrid: Pearson educacion S.A.
Torres Gómez, A. R. (08 de 2011). CARACTERIZACIÓN DE TECNOLOGÍAS RF-ID.
Recuperado el 17 de 08 de 2015, de Universidad Nacional de Colombia:
http://www.bdigital.unal.edu.co/9021/1/Andr%C3%A9srodolfotorresg%C3%B3
mez.2011.pdf
91
UML. (22 de 05 de 2015). UML. Recuperado el 23 de 10 de 2015, de
http://www.uml.org/
Universidad Católica de Pereira. (s.f.). Universidad Católica de Pereira. Recuperado
el 28 de 04 de 2015, de http://www.ucp.edu.co/historia.php
Universidad Politecnica de Madrid. (s.f.). Ondas de radiofrecuencia para localizar
libros. Recuperado el 07 de 05 de 2015, de Universidad Politecnica de
Madrid:
http://www.upm.es/institucional/UPM/CanalUPM/Noticias/ci.5ae5086f9be5e11
0VgnVCM10000009c7648aRCRD.ext2
92
ANEXO
Manual de usuario.
1. Ingreso a la aplicación
Al abrir la aplicación se desplegará esta interfaz de control, en la cual se debe
ingresar un nombre de usuario y contraseña válidos para tener acceso a los datos
del programa.
Ingresar nombre de usuario y contraseña y dar clic en Conectar, si los datos son
correctos se tendrá acceso al programa.
El programa cuenta con dos tipos de usuario, un usuario estándar con algunos
permisos para trabajar en el programa y un usuario administrativo con acceso total.
93
2. Usuario Administrador:
Con el usuario administrador se tiene la posibilidad de gestionar las personas
(agregar, modificar, eliminar y buscar); también se cuenta con la gestión de reportes.
94
2.1 Gestión de Personas. Agregar persona:
Para agregar una nueva persona al sistema damos clic en agregar persona, a
continuación se desplegará una nueva ventana.
Dar clic en nuevo registro para ingresar los datos de la nueva persona que se va a agregar al sistema.
95
1. Al dar clic en Leer Tag, se cargará la etiqueta RFID que se acerque al
lector.
2. En el campo Código, irá la identificación de la persona a registrar.
3. En este campo, se asigna el nombre de la persona.
4. En este campo, se asigna el apellido de la persona.
5. En el campo Programa, se asigna a la persona el área de la institución al
que pertenece.
6. En el campo Cargo, se asigna la actividad que desempeña la persona.
7. En el apartado Imagen, se puede seleccionar una imagen guardada en el
equipo dando clic en Seleccionar Imagen o tomar una fotografía de la
persona que se va a registrar dando clic en Tomar Foto.
7.1 Tomar foto:
96
Dar clic en tomar foto.
Para ver la fotografía que se acaba de tomar, dar clic en Mostrar Foto, a continuación se mostrará la foto en pantalla.
97
7.2 Seleccionar Imagen:
Dar clic en Seleccionar imagen.
Buscar imagen, seleccionarla y dar clic en abrir.
98
Al terminar el registro de una persona se debe dar clic en el botón Registrar, para cancelar un registro dar clic en el botón Cancelar. Buscar persona:
Dar clic en Buscar Persona.
Escribir el código de la persona y dar clic en buscar, de esta manera filtrara la persona que se quiere encontrar. Modificar y eliminar personas: En esta parte se pueden modificar los datos de cierta persona o simplemente eliminarla. Primero se debe situar en la fila de la tabla de la persona que se requiera modificar o eliminar, pulsar el clic derecho y elegir cuál de las dos acciones se van a realizar, como se muestra en la siguiente imagen.
99
Una vez se realice este procedimiento se cargaran los datos de la persona seleccionada, allí se deben hacer las modificaciones correspondientes y posteriormente presionar el botón “Modificar” o “Eliminar”.
Al momento de realizar dicha acción, se mostrara un mensaje de confirmación de si se está seguro de realizar la modificación.
100
Cuando se confirme la acción se muestra un mensaje de confirmación en la acción, si el proceso se realizó correctamente.
2.2 Gestión de Reportes
Los reportes se pueden realizar por Programa, Persona, Cargo o Fecha:
Reporte por Programa:
101
Para realizar un reporte por programa, dar clic en Reportes, Por programa y luego seleccionar el programa del que se requiere el reporte. Reporte por Persona:
Para realizar un Reporte por persona, dar clic en Reportes, Por persona, y luego digitar el código de la persona; luego dar clic en buscar. Reporte por cargo:
Para realizar un reporte por cargo, dar clic en Reportes, Por cargo, seleccionar el cargo de la persona. Reporte por Fecha:
102
Para realizar un reporte por fecha, dar clic en Reportes, Por Fecha, seleccionar uno de los filtros (Por día, Por mes, Por Año, Por rango de días). 3. Usuario Estándar El usuario estándar solo tiene acceso a una interfaz, donde es posible verificar las
personas que están registrándose en el sistema.
Acercando el carnet al lector RFID y presionando el botón “Buscar”, se mostrara toda la información almacenada de la persona.