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.