PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO ...repository.udistrital.edu.co/bitstream/11349/8319/2...estos sistemas de control de acceso se usa la huella digital, u otra cualidad diferencial,

PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES

Javier Ricardo Alfonso Alba

Alvaro Iván Ronderos Acevedo

Jurado:

M.I. Luis Felipe Wanumen Silva

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD TECNOLÓGICA

INGENIERÍA TELEMÁTICA

Bogotá 2016

PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 2

Contenido

Introducción ........................................................................................................................................ 7

1. FASE INICIAL ................................................................................................................................ 9

1.1. Titulo ................................................................................................................................... 9

1.2. Tema .................................................................................................................................... 9

1.3. Descripción del Problema ................................................................................................... 9

1.4. Formulación del Problema ................................................................................................ 10

1.5. Objetivo General ............................................................................................................... 10

1.6. Objetivos Específicos ........................................................................................................ 10

1.7. Justificación ....................................................................................................................... 10

1.8. Alcances y Delimitaciones ................................................................................................. 12

1.8.1. Delimitación Temática .............................................................................................. 12

1.8.2. Delimitación Geográfica ............................................................................................ 13

1.8.3. Delimitación Temporal .............................................................................................. 13

1.8.4. Alcances..................................................................................................................... 13

1.9. Marco Teórico ................................................................................................................... 14

1.9.1. Desarrollo de aplicaciones MVC ................................................................................ 14

1.9.2. Arquitectura de un sistema bajo el patrón MVC ...................................................... 16

1.9.3. Ventajas de la arquitectura MVC .............................................................................. 19

1.9.4. Desventajas de la arquitectura MVC ................................................................ 19

1.9.5. JAVA ......................................................................................................................... 20

1.9.6. Netbeans IDE . ........................................................................................................ 21

1.9.7. MongoDB. ................................................................................................................. 21

1.10. Marco Conceptual ......................................................................................................... 23

1.10.1. Sensor .................................................................................................................... 23

1.10.2. Telemetría ................................................................................................................. 23

1.10.3. Raspberry Pi .............................................................................................................. 23

1.10.4. Gestor de Bases de Datos ..................................................................................... 24

1.10.5. Aplicación .................................................................................................................. 24


1.10.6. TCP/IP ....................................................................................................................... 24

1.10.7. Equipo Servidor ....................................................................................................... 25

1.10.8. Equipo Cliente ......................................................................................................... 25

1.10.9. Sistema Distribuido ................................................................................................ 25

1.10.10. Lightweight Directory Access Protocol ................................................................. 25

1.11. Estado del Arte .............................................................................................................. 26

1.12. Marco Metodológico ..................................................................................................... 29

1.13. Factibilidad .................................................................................................................... 30

1.13.1. Factibilidad Técnica ................................................................................................... 30

1.13.2. Factibilidad Operativa ............................................................................................... 31

1.13.3. Factibilidad Legal ....................................................................................................... 31

1.13.4. Factibilidad Económica.............................................................................................. 32

1.14. Riesgos del Proyecto ..................................................................................................... 33

1.14.1. Estrategias del riesgo pre activo. .............................................................................. 33

1.14.2. Consecuencias del riesgo .......................................................................................... 34

1.14.3. Probabilidad e impacto de riesgo ............................................................................. 35

2. FASE DE DEFINCIÓN .................................................................................................................. 37

2.1. Requerimientos ................................................................................................................. 37

2.1.1. Requerimientos Funcionales ..................................................................................... 37

2.1.2. Requerimientos No funcionales ................................................................................ 37

2.2. Historias de Usuario. ......................................................................................................... 38

2.2.1. Definiciones ............................................................................................................... 38

Directorio LDAP ......................................................................................................................... 38

2.2.2. IDH-1 Fallas en la conexión de red ............................................................................ 38

2.2.3. IDH-2 Almacenamiento de Eventos .......................................................................... 41

2.2.4. IDH-3 Reglas de Acceso ............................................................................................. 43

2.2.5. IDH-4 Interfaz Gráfica De Administración ................................................................. 44

2.3. Cronograma....................................................................................................................... 46

3. FASE DE DESARROLLO ............................................................................................................... 49

3.1. Diagramas de Flujo Funcional ........................................................................................... 49

3.1.1. Solicitud de Acceso .................................................................................................... 49

3.1.2. Generar Evento ......................................................................................................... 50


3.1.3. Modificar Regla de Acceso ........................................................................................ 50

3.1.4. Agregar Una Unidad Al Sistema ................................................................................ 51

3.2. BackLog de Actividades ..................................................................................................... 52

3.3. Sprints ............................................................................................................................... 52

3.3.1. Sprint 1 Desarrollo del Core del sistema ................................................................... 53

3.3.2. Sprint 2 Desarrollo de los Eventos de acceso al sistema .......................................... 54

3.3.3. Sprint 3 Administración del Sistema ......................................................................... 55

3.4. Resumen de Esfuerzos ...................................................................................................... 57

3.4.1. Esfuerzo primera versión estable .............................................................................. 58

3.4.2. Esfuerzo total del proyecto ....................................................................................... 58

3.5. Diagramas de Clases .......................................................................................................... 59

3.5.1. Capa de Persistencia ................................................................................................. 59

3.5.2. Capa de Servicios ....................................................................................................... 60

3.5.3. Capa de Control ......................................................................................................... 62

3.6. Diseño de Interfaces ......................................................................................................... 63

3.7. Diccionario de Datos ......................................................................................................... 66

4. FASE DE IMPLEMENTACIÓN ...................................................................................................... 69

4.1. Diagrama de Paquetes ...................................................................................................... 69

4.2. Diagramas de Despliegue .................................................................................................. 70

4.3. Esquema Telemático del sistema ...................................................................................... 71

5. FASE DE CIERRE ......................................................................................................................... 73

5.1. Pruebas del Sistema .......................................................................................................... 73

5.1 Pruebas Sprint 1 ............................................................................................................ 73

5.1.1 Pruebas Sprint 2 ........................................................................................................ 75

5.1.2 Pruebas Sprint 3 ........................................................................................................ 78

5.2. Cierre del proyecto............................................................................................................ 82

5.3. Mejoras propuestas .......................................................................................................... 84

Conclusiones ..................................................................................................................................... 85

Recomendaciones ............................................................................................................................. 87

Bibliografía ........................................................................................................................................ 88


Índice de Ilustraciones

Ilustración 1 Arquitectura MVC......................................................................................................... 15

Ilustración 2 Arquitectura de un Sistema Bajo el patrón MVC. ........................................................ 17

Ilustración 3 MVC del lado del servidor (Desacoplado) .................................................................... 18

Ilustración 4 Montaje de un sistema de control de acceso .............................................................. 28

Ilustración 5 Ciclo de vida de un proyecto con Scrum. ..................................................................... 29

Ilustración 6 Cronograma de actividades. ......................................................................................... 48

Ilustración 7 Flujo Funcional Solicitud de Acceso. ............................................................................ 49

Ilustración 8 Flujo funcional Generar Evento. ................................................................................... 50

Ilustración 9 Flujo funcional Modificar Regla de Acceso. ................................................................. 50

Ilustración 10 Flujo funcional Agregar Una Unidad Al Sistema......................................................... 51

Ilustración 11 Grafica de esfuerzo vs días del Sprint 1. .................................................................... 54



Ilustración 14 Esfuerzo en horas antes de la versión estable. .......................................................... 58

Ilustración 15 Esfuerzo total del proyecto. ....................................................................................... 59

Ilustración 16 Diagrama de clases de la capa de persistencia. ......................................................... 60

Ilustración 17 Diagrama de clases Capa de Servicios - parte 1. ....................................................... 61

Ilustración 18 Diagrama de clases Capa de Servicios - parte 2. ....................................................... 61

Ilustración 19 Diagrama de clases Capa de Control. ......................................................................... 62

Ilustración 20 Diagrama de clases utilitarias. .................................................................................... 63

Ilustración 21 Interfaz de Administración de unidades. ................................................................... 64

Ilustración 22 Interfaz de administración para las reglas de acceso. ............................................... 64

Ilustración 23 Interfaz de consulta de eventos. ................................................................................ 65

Ilustración 24 Interfaz de administración de las zonas. .................................................................... 65

Ilustración 25 Diagrama de paquetes core del sistema. ................................................................... 69

Ilustración 26 Diagrama de paquetes punto de inicio del sistema. ................................................. 70

Ilustración 27 Diagrama de despliegue, componentes de software. ............................................... 70

Ilustración 28 Diagrama Telemático del sistema. ............................................................................. 71

Ilustración 29 Esfuerzo Total Vs Esfuerzo en la resolución de los errores ........................................ 83


Índice de Tablas

Tabla 1 Riesgos pre activos ............................................................................................................... 33

Tabla 2 Consecuencias del riesgo ..................................................................................................... 34

Tabla 3 Probabilidad e impacto de riesgo ......................................................................................... 35

Tabla 4 BackLog general del proyecto. ............................................................................................. 52

Tabla 5 Esfuerzos Sprint 1. ................................................................................................................ 53



Tabla 8 BackLog general del proyecto con Esfuerzos. ...................................................................... 57

Tabla 9 Diccionario de datos colección ZoneDTO. ............................................................................ 67

Tabla 10 Diccionario de datos colección UserDTO. .......................................................................... 67

Tabla 11 Diccionario de datos colección UnitDTO. ........................................................................... 67

Tabla 12 Diccionario de datos colección UnitDTO. ........................................................................... 67

Tabla 13 diccionario de datos colección ConfigurationDTO. ............................................................ 68

Tabla 14 Diccionario de datos colección AccessRuleDTO. ................................................................ 68

Tabla 15 Diccionario de datos colección EventDTO. ......................................................................... 68

Tabla 16 Tiempo desarrollo Vs Errores de desarrollo. ...................................................................... 82


Introducción

La seguridad de los activos es uno de los ítems más importantes dentro de los planes de

seguridad implantados por cada organización, en la actualidad las empresas y

organizaciones comúnmente delegan la función de seguridad en terceros, generalmente

una empresa de seguridad privada, estas empresas de seguridad se encargan de

salvaguardar las instalaciones de las organizaciones y en algunos casos un cierto control

en el acceso a las instalaciones por parte de extraños. sin embargo el nivel de acceso

privilegiado sobre ciertas áreas, recursos o activos de la empresa es tratado de forma

trivial en muchos casos y en otros hace parte del plan general de la organización

enfocado a la seguridad de los activos de información con que cuenta la empresa, la

forma de control es mediante sistemas como el RFID (Radio Frequency IDentification,

en español identificación por radiofrecuencia) que es un sistema de almacenamiento y

recuperación de datos remoto que usa dispositivos denominados etiquetas, tarjetas,

transpondedores o tags RFID. El propósito fundamental de la tecnología RFID es

transmitir la identidad de un objeto (similar a un número de serie único) mediante ondas

de radio. Las tecnologías RFID se agrupan dentro de las denominadas Auto ID

(automatic identification, o identificación automática). Esta clase de tecnología permite

garantizar el acceso, sin embargo no garantiza la identidad de quien accede, lo que

representa una gran falencia, en el otro extremo se tienen los sistemas de control de

acceso, con lectores biométricos, que cuyos esquemas de seguridad permiten controlar

que a determinadas áreas de la organización solo ingresen las personas autorizadas. En

estos sistemas de control de acceso se usa la huella digital, u otra cualidad diferencial, a

manera de llave o pase de entrada por lo cual es plenamente identificable la identidad de

las persona que intenta obtener acceso.

Los sistemas de identificación biométrica son esencialmente software que corre sobre un

equipo que permite la identificación inequívoca de personas, previamente registradas por

otra parte del sistema en una base de datos. Estas características físicas individuales no

pueden ser falsificadas fácilmente. Habitualmente estas lecturas biométricas se basan en

las características de las huellas digitales o cualquier otro identificador biométrico.


Para proveer movilidad al sistema de identificación de forma que permita ser transportado e

instalado fácilmente, este debe cumplir con ciertas características como: ser liviano,

permitir conectarse por diversos medios, poseer respaldo de datos externo, permitir

guardar registros de transacciones, sincronizar las transacciones cuando se encuentre de

nuevo en línea, permitir adicionar nuevo hardware de control, y las demás características

de un sistema distribuido.

El presente proyecto de grado hace uso de los conocimientos adquiridos durante la

formación académica en la ingeniería en telemática para desarrollar un prototipo de

sistema de control de acceso, que sea distribuido y utilice las tecnologías libres que

existen en el mercado; El desarrollo de dicho prototipo se hace bajo la metodología ágil

de desarrollo Scrum y pretende demostrar la viabilidad de construir y mantener un

sistema de este tipo en las organizaciones.


1. FASE INICIAL

1.1. Titulo Prototipo de Sistema de Control de Acceso Distribuido con Tecnologías Libres.

1.2. Tema Los temas tratados en este proyecto son: El control de Acceso, desarrollo de software libre, la

tecnología Java, los sistemas distribuidos, la seguridad física de las organizaciones y las Bases

de datos.

1.3. Descripción del Problema

Las empresas se ven abocadas en la actualidad a proteger activos de gran valor para sus

organizaciones, los controles establecidos para salvaguardar dichos activos no suelen ser muy

efectivos ya que en gran parte se ven limitados por los proveedores de soluciones de seguridad,

quienes en muchos casos no cuentan con productos adaptables a la necesidad de cada cliente, o

en otros casos son muy costosas para ser implementadas, lo que limita a las empresas para

establecer un esquema de seguridad adecuado y a su vez contribuye a que no puedan tener

controles adecuados eficientes que se traduce en pérdidas de activos, como perdidas de

información o fugas de información.

Las soluciones que ofrecen los proveedores de tecnología del área de la seguridad presentan costos

elevados para ser implementadas porque dependen de una inversión económica para la

adecuación de la infraestructura física, contratos de servicio por periodos de tiempo prefijados,

cobros asociados a licencias de tecnologías propietarias con periodos de expiración y costos

ocultos en la actualización de los esquemas de seguridad como lo menciona John LaFond en su

artículo ‘Counting Up the Hidden Costs of Security Licensing’1:

“Al ampliar o actualizar los sistemas, todos los clientes son susceptibles a una amplia gama de

honorarios por licencia (además de cualquier costo laboral o de hardware) que puede aumentar

significativamente la cantidad que usted está pagando por las mejoras o actualizaciones de

tecnología que su empresa quiere y necesita. Los costos ocultos pueden provenir de tarifas de

servicios cloud, cliente o cobros de licencias de base de datos, comisiones por licencias de

hardware, o cualquier combinación de éstos. Esto significa que cualquier momento que desee

1 LaFond, John. (2010). Counting Up the Hidden Cost of Security Licensing. [versión Electrónica], Security

Magazine. Recuperado el Junio 10 de 2014, de http://www.securitymagazine.com/articles/85588-counting-up-the-hidden-cost-of-security-licensing


ampliar el número de puntos de acceso, implementar la integración de vídeo o tal vez actualizar

su sistema con control de acceso al ascensor, le podría costar en múltiples niveles.”

1.4. Formulación del Problema ¿Cómo construir una solución tecnológica que sea una alternativa a las soluciones actuales del

mercado, que sea económica, confiable y adaptable a las empresas interesadas en proteger la

integridad y confidencialidad de sus activos por medio de control de acceso?

1.5. Objetivo General

Desarrollar un prototipo de sistema de control de acceso distribuido de software libre, adaptable y

de bajo costo de implementación.

1.6. Objetivos Específicos

Analizar los requerimientos para el desarrollo del sistema de control de acceso.

Diseñar una solución tecnológica que cumpla con los requerimientos identificados.

Desarrollar un prototipo de solución tecnológica para el control del acceso que

permita ser usada con propósito general, que sea adaptable a diferentes contextos

dentro de las organizaciones, permita escalabilidad y adaptación a diversos

componentes de hardware como lectores biométricos, teclados numéricos, tarjetas

RFID o etiquetas NFC.

Implementar una solución Tecnológica que no tenga costos asociados al

licenciamiento de las tecnologías utilizadas.

Probar el prototipo en la empresa A & G Tecnología para comprobar que el sistema

desarrollado cumpla con los objetivos planteados.

1.7. Justificación

Un estudio del mercado de la tecnología en américa latina sugiere que “El mercado de la

Seguridad Electrónica” es un mercado de cambios tecnológicos constantes, lo que

hace que las empresas usuarias de un sistema de seguridad quieran estar siempre a

la par con la tecnología de países desarrollados como Estados Unidos.


Actualmente y desde hace ya un par de años, en Seguridad Electrónica se vive en la era de

la tecnología IP y la convergencia de las tecnologías, por lo cual las empresas

buscan que sus sistemas de seguridad cuenten con estas características.

Igualmente los sistemas de control de acceso buscan el uso más

eficiente y seguro de la biometría para la identificación de las personas,

para ello se han experimentado diferentes ideas como la de usar la

saliva como elemento identificador y proporcionador de datos de

pacientes como son los de las enfermedades que padecen, su historia

patológica, entre otras. También cada vez está siendo más usado la

biometría en los gobiernos de países para la identificación de los

extranjeros que ingresan al país, como es el caso del gobierno de

Canadá, o la identificación de los estudiantes mediante dispositivos

biométricos faciales, como lo está realizando un colegio Británico. En

Control de Acceso, la competencia está planteada entre el uso de la

biometría o las tarjetas inteligentes o Smart Cards. Estas últimas

pretenden que bajo una misma y única tarjeta se pueda manejar mucha

información para ser utilizada en diferentes aplicaciones. Por ejemplo,

que sea usada una única tarjeta para el ingreso a la empresa o centro

educativo, el pago en un centro comercial, etc.2

Después de analizar las soluciones tecnológicas para el control de acceso que se

encuentran en la actualidad para el mercado colombiano, se puede identificar que

estas soluciones incluyen generalmente un hardware y software propietario, lo que

se ve reflejado en el costo para el usuario final quien debe pagar una subscripción o

licencia de uso por periodos de tiempos establecidos para que la empresa que

proporciona los sistemas de control de acceso le presten el servicio, estos contratos

de servicio por lo general son de periodos no menores a un año. Si el usuario final

desea modificar o ampliar el esquema de seguridad debe adquirir otra licencia o

subscripción con la empresa contratante lo que impacta económicamente sus

2 Garcia, M., Alex. (2009). Estudio de Mercado De La Seguridad Electrónica en Colombia. Recuperado el 10

de marzo de 2015, de https://docs.google.com/file/d/0B1Hnm-wBJAJCNDE2NGNiNTItMzI5OS00NGQyLWIzODMtMGM1ZDU3YmY5M2Zl/edit?hl=en_US

https://docs.google.com/file/d/0B1Hnm-wBJAJCNDE2NGNiNTItMzI5OS00NGQyLWIzODMtMGM1ZDU3YmY5M2Zl/edit?hl=en_US

https://docs.google.com/file/d/0B1Hnm-wBJAJCNDE2NGNiNTItMzI5OS00NGQyLWIzODMtMGM1ZDU3YmY5M2Zl/edit?hl=en_US


finanzas. Esto genera que las organizaciones no vean las soluciones de control de

acceso como sistemas más allá del ingreso del personal a el lugar del trabajo, y

aunque la protección de los activos con que cuentan las organizaciones siempre son

importantes, las empresas no cuentan con una opción completa, confiable y

económica para mantener un manejo efectivo sobre la protección y el acceso sobre

dichos activos que hacen parte de la organización. Teniendo en cuenta lo anterior se

debe considerar que las empresas colombianas interesadas en implementar un

sistema de control, fácilmente optarían por un sistema de control de acceso con la

seguridad que ofrecen las variables biométricas, que pueda ser utilizado no

solamente como control de acceso a áreas, que pueda ser fácilmente adaptable a

otros contextos dentro de las organizaciones, que sea altamente escalable y cuya

implantación, mantenimiento y gestión sea más económica que las soluciones que

se pueden conseguir en el mercado actualmente.

El Prototipo de Sistema de control de acceso con tecnologías libres busca presentarse como

una opción económica y simple para implementar el control de acceso en diversos

escenarios dentro de las organizaciones, al hacer uso de las tecnologías existentes tanto

en software y hardware libre, es posible desarrollar mediante el diseño de interacción

un prototipo de sistema de control de acceso con la posibilidad de usar una gran variedad

de módulos y sensores, la principal ventaja de esta aproximación es la economía y la

posibilidad de usar y modificar su configuración para ser adaptado a las necesidades de

cada organización.

1.8. Alcances y Delimitaciones

1.8.1. Delimitación Temática

El presente proyecto pretende usar los conocimientos adquiridos durante la carrera de

Ingeniería en Telemática, por lo cual solo se abordarán los temas técnicos necesarios

para poder desarrollar un prototipo de sistema de control de acceso distribuido.

Por lo anterior los sensores, lectores o cualquier otro medio de lectura de información serán

considerados en el proyecto pero no serán implementados en el prototipo.


El proyecto se centra en el sistema distribuido, todas las adaptaciones, adecuaciones de los

dispositivos de reconocimiento, interfaz de potencia, motores, compuertas y demás

elementos físicos no se encuentran dentro de la finalidad del proyecto.

1.8.2. Delimitación Geográfica

La solución tecnológica será desarrollada en la ciudad de Santa Fe De Bogotá, distrito

capital del estado colombiano.

1.8.3. Delimitación Temporal

El proyecto se desarrollará entre los meses de Mayo y Agosto de 2015 para un total de 4

meses.

1.8.4. Alcances

El sistema desarrollado cumplirá la función básica de los sistemas de control de

acceso de permitir o denegar el acceso a un usuario, por tal motivo para modo de

ilustración el prototipo contará con un mecanismo básico de autenticación simulado.

La solución tecnológica al ser un prototipo solo contará con una unidad de acceso y

el servidor de control.

La solución tecnológica dentro de las labores de administración solo contará con los

flujos funcionales de Creación y Modificación, no el de eliminación.

El sistema desarrollado contará con un canal de comunicación encriptado.

El prototipo del sistema de control de acceso tendrá una apartado para la

visualización histórica de eventos, para poder evidenciar el funcionamiento, contará

con un filtro dentro del cual se podrá seleccionar el periodo de tiempo a consultar.

El sistema será desarrollado usando Raspberry Pi, por lo que el sistema asume las

limitaciones inherentes a este hardware.


1.9. Marco Teórico Los siguientes son las técnicas y tecnologías escogidas para el desarrollo del proyecto,

teniendo en cuenta que son software libre y patrones de diseño disponibles para su

uso.

1.9.1. Desarrollo de aplicaciones MVC

Arquitectura MVC (Modelo vista Controlador). Fue descrita por primera vez en

1979 en el documento “Applications Programming in Smalltalk-80(TM): How to

use Model-View-Controller (MVC)”3. Dirigido al lenguaje de programación

Smalltalk. Usada como el patrón clásico para aplicaciones donde el usuario

interactúa constantemente con el sistema, “La arquitectura de diseño MVC

(iniciales en inglés de “Model View Controller” o “Modelo Vista Controlador”)

provee un mecanismo que posibilita separar los datos (el modelo) de la forma en

que estos serán visualizados (la vista) Usando un puente entre los dos (El

controlador)”4, lo anterior se puede observar en la figura 1.

3 Burbeck, Steve. (2012) Applications Programming in Smalltalk-80(TM):

How to use Model-View-Controller (MVC). Recuperado el 08 de septiembre de 2014, Disponible en: < http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html> 4 SZNAJDLEDER, Pablo. Java a fondo: estudio del lenguaje y desarrollo de aplicaciones 1ª ed. Buenos Aires,

Alfaomega, 2010,528p.

http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html


Ilustración 1 Arquitectura MVC

Fuente: Bullet, Cristhoper. Model-View-Controller frameworks. [En línea] [Consulta: 08 de septiembre de 2013]

Disponible en: <http://www.adobe.com/newsletters/inspire/october2008/articles/article2/index.html>

Lo que se consigue con la arquitectura MVC es un mantenimiento más sencillo de

las aplicaciones. Si por ejemplo una misma aplicación Web debe ejecutarse tanto en

un navegador estándar como un navegador de un dispositivo móvil, solamente es

necesario crear una vista nueva para cada dispositivo; manteniendo el controlador y

el modelo original.

Según Rigada, Aitor5. Los componentes MVC se pueden definir como:

El Modelo. Incorpora la capa del dominio y persistencia, es la encargada de guardar

los datos en un medio persistente (ya sea una base de datos, un archivo de texto,

XML, registro, etc.). En el modelo es donde se hace el levantamiento de todos los

objetos que el sistema debe de utilizar, es el proveedor de recursos. Es muy típico

que las clases del modelo incorporen otro patrón de diseño ya que así es más fácil

manejar la información usada por el motor de la base de datos, como el caso de

motor MySQL, aunque pueden ser también un conjunto de archivos formateados o

5 Rigada, Aitor. (2008). Model View Controller. Recuperado el 15 de septiembre de 2014. de

< http://blogdeaitor.wordpress.com/2008/10/20/model-view-controller/>

http://blogdeaitor.wordpress.com/2008/10/20/model-view-controller/


incluso archivos planos. Lo importante es que esta parte debe ser la más oculta del

sistema, para proporcionar la menor cantidad de información a los usuarios o en

general a cualquier persona (incluso aquellas malintencionadas). De esta forma, se

crea una capa de Software para abstraer la información concreta del modelo. Un

ejemplo de esto es la abstracción de Java para conexión a las bases de datos

(JDBC).

La Vista. Se concentra en la presentación de los datos al cliente o usuario. Por

ejemplo en el caso de las aplicaciones de escritorio, la vista serían las diferentes

ventanas que componen la aplicación, en el caso que la aplicación fuera Web, la

vista serían las páginas HTML, JSP o ASP que se cargan en el navegador, dándole

al usuario la información que le corresponde. La construcción de la vista puede estar

a cargo de diseñadores gráficos (para la imagen de la empresa, uniformidad de

conceptos). Al ser completamente independiente del resto del sistema, puede

cambiarse fácilmente sin afectar las capas inferiores.

En la vista solo se deben de hacer operaciones simples que estén orientadas a forma en que

se mostraran los datos, como ciclos, formateo, etc.

El Controlador. Crea un puente entre las dos capas anteriores (Modelo y Vista). Se

encarga de obtener las peticiones hechas por el cliente desde la vista, formatearlas

para que sean entendibles para el sistema, y acceder al módulo correspondiente que

a su vez consultará al modelo en el momento que se necesite. De igual manera, al

obtener una respuesta del sistema, el controlador se encarga de generar una vista de

retroalimentación para el usuario y así cerrar el ciclo para quedarse a la espera de un

nuevo evento que inicie un nuevo ciclo, dicho evento por lo general lo genera el

usuario del sistema.

1.9.2. Arquitectura de un sistema bajo el patrón MVC

En la figura 2 Se marca la disposición común con el cual se desarrolla un sistema bajo la

arquitectura o patrón MVC, se muestra la forma en que interactúan las tres capas


de información, se debe denotar que el usuario del sistema no debe tener acceso a la

capa del Modelo (donde están los datos) por seguridad y dado que así lo dispone el

patrón de diseño, el usuario solo debe interactuar con la capa de vista o

presentación a través del Controlador y es este último quien se comunica con todas

las capas que componen la aplicación.

Ilustración 2 Arquitectura de un Sistema Bajo el patrón MVC.

Fuente: ADOBE INC. The MVC Architecture. [En línea]. [Consulta: 12 de septiembre de 2013] Disponible en

<http://www.symfony-project.org/jobeet/1_2/Doctrine/en/04.>

Flujo de un sistema MVC de escritorio.6 Junto al usuario, los componentes de MVC forman

dos ciclos de información y flujo de control:

Ciclo de la Vista: Usuario → Controlador → Vista → Usuario. El usuario manipula

un dispositivo de entrada - por ejemplo, con un clic, mientras el cursor del ratón en

6 Steele, Oliver. (2004). LANGUAGES OF THE REAL AND ARTIFICIAL. Web MVC. Recuperado el 12 de

septiembre de 201], de <http://osteele.com/archives/2004/08/web-mvc>

http://osteele.com/archives/2004/08/web-mvc


la parte inferior de una barra de desplazamiento. El controlador responde enviando

un mensaje a La Vista que actualiza su estado, y actualiza la información que se

presenta al usuario.

Ciclo del Modelo: Usuario → Controlador → Modelo → Vista → Usuario. El

usuario manipula un dispositivo de entrada de una forma y en un contexto

diferente. El controlador actualiza el estado del Modelo, la vista se actualiza para

reflejar el cambio en el modelo, y al usuario se le presenta la nueva vista.

Flujo de un sistema MVC en un servidor7. Cuando un sistema MVC se emplea en un Servidor este

debe compartir el esquema de desarrollo con el cliente, debido a que este último a través

de su capa de control se comunica con la capa controlador del servidor. En la figura 3 se

instruye sobre este hecho. Para el caso de Java se usa un JDK para el desarrollo del

servidor y un Java ME SDK, para el desarrollo de la aplicación en el dispositivo móvil,

gracias a un IDE (entorno de desarrollo integrado) como NetBeans se logra usar un mismo

entorno de desarrollo para las tres capas donde solo cambia la forma visual de la Vista.

Ilustración 3 MVC del lado del servidor (Desacoplado)

Fuente: Iriarte, Leandro. Web MVC. [En línea] [Consulta: 12 de septiembre de 2013] Disponible en:

<http://www.leandroiriarte.com.ar/spanish/web_mvc.php.>

7 Ibíd.


1.9.3. Ventajas de la arquitectura MVC

Según Aguilar, José M.8 Al tener un amplio recorrido histórico y al ser la base de desarrollo

de muchas aplicaciones Web esta arquitectura presente varias ventajas, entre las que se

cuentan:

fácil y flexible estructuración del código.

Si se desarrolla respetando los lineamientos, seguridad y ayuda para el

programador.

Clara separación entre interfaz, lógica de negocio y de presentación, que además

provoca parte de las ventajas siguientes.

Sencillez para crear distintas representaciones de los mismos datos.

Reutilización de los componentes.

Simplicidad en el mantenimiento de los sistemas.

Facilidad para desarrollar prototipos rápidos.

Los desarrollos suelen ser más escalables.

las piezas de un programa se pueden construir por separado.

1.9.4. Desventajas de la arquitectura MVC9

Al igual que las restantes arquitecturas utilizadas para construir sistemas informáticos,

entre las principales se encuentran:

Tener que ceñirse a una estructura predefinida, lo que a veces puede incrementar la

complejidad del sistema. Hay problemas que son más difíciles de resolver

respetando el patrón MVC.

La curva de aprendizaje para los nuevos desarrolladores se estima mayor que la de

modelos más simples.

La distribución de componentes obliga a crear y mantener un mayor número de

ficheros.

8 Aguilar, José M. (2012) ASP.NET MVC 2: Quince cuestiones que deberías conocer. Recuperado el 12 de

septiembre de 2014, de <http://www.variablenotfound.com/2010/05/aspnet-mvc-2-quince-cuestiones-que.html> 9 Ibíd.

http://www.variablenotfound.com/2010/05/aspnet-mvc-2-quince-cuestiones-que.html

http://www.variablenotfound.com/2010/05/aspnet-mvc-2-quince-cuestiones-que.html


El tiempo de desarrollo de una aplicación que implementa el patrón de diseño

MVC es mayor, al menos en la primera etapa, que el tiempo de desarrollo de una

aplicación que no lo implementa.

1.9.5. JAVA 10

Es una plataforma virtual de software desarrollada por Sun Microsystems, orientada a que

los programas creados en ella puedan ejecutarse sin cambios en diferentes tipos de

arquitecturas y dispositivos computacionales (“diferentes Plataformas”).

La plataforma Java consta de las siguientes partes:

El lenguaje de programación, mismo.

La máquina virtual de java o JRE, que permite la portabilidad en ejecución.

El API (del inglés Application Programming Interface), una biblioteca estándar

para el lenguaje.

En un principio fue diseñado para correr en computadoras incrustadas. Sin embargo, en

1995, dada la atención que se estaba produciendo en la Web, Sun Microsystems la

distribuyo para sistemas operativos tales como Microsoft Windows.

Con la evolución de las diferentes versiones, no solo se han producido cambios en el

lenguaje, sino que también se han producido cambios mucho más importantes en

sus bibliotecas asociadas y dando la posibilidad de expandirse al terreno de los

dispositivos móviles mediante la plataforma J2ME (Java 2 Micro Edition).

Java Development Kit (JDK). También conocido como J2SE (Java Standard

Edition), es un software que provee herramientas de desarrollo para la creación de

programas en java orientados a ordenadores de sobremesa, en donde se han

incorporado clases adicionales para facilitar el desarrollo de aplicaciones y donde la

interfaz de usuario tiene una importancia muy especial. Los programadores de

software que en la actualidad programen soluciones orientadas a la Web suelen

recurrir a este conjunto de APIS para realizar su desarrollo. Entre sus componentes

se encuentran:

10

FROUFE QUINTAS, Agustín. Java 2 Manual de Usuario y Tutorial. 5 Edi. México. Alfaomega, 2008, 696 p.


Intérprete en tiempo de ejecución (JRE). Permite la ejecución de los programas

Java (*.class) no gráficos (aplicaciones).

Compilador. Se utiliza para compilar archivos de código fuente Java

(habitualmente *.java), en archivos de clases Java ejecutables (*.class).

Visualizador de applets. Es una herramienta que sirve como campo de pruebas de

applets, visualizando cómo se mostrarían en un navegador, en lugar de tener que

esperar.

Depurador. Es una utilidad de línea de comandos que permite depurar aplicaciones

Java. No es un entorno de características visuales, pero permite encontrar y

eliminar los errores de los programas Java con mucha exactitud.

Desensamblador de archivo de clase. Se utiliza para desensamblar un archivo de

clase. Su salida por defecto, muestra los atributos y métodos públicos de la clase

desensamblada, es útil cuando no se tiene el código fuente de una clase de la que se

quisiera saber cómo fue codificada.

1.9.6. Netbeans IDE. 11

Es un entorno de desarrollo integrado (IDE),una herramienta de código libre, gratuita, que

sirve para que los programadores puedan escribir, compilar, depurar y ejecutar

programas, tiene soporte para crear interfaces gráficas de forma visual, crear

aplicaciones para móviles, Web, etc. Está escrito en Java, pero puede servir para

cualquier otro lenguaje de programación. Las funcionalidades son ampliables

mediante instalación de paquetes adicionales. NetBeans IDE se conoce como la

solución más completa para programar en Java.

1.9.7. MongoDB. 12

Es un sistema de bases de datos no relacionales (NoSQL), multiplataforma e inspirada en el

tipo de bases de datos documental y clave/valor, su nombre proviene del término en

11

Bienvenido a NetBeans y www.netbeans.org. Recuperado el 05 de septiembre de 2014, del sitio oficial de netbeans, Disponible en < http://netbeans.org/index_es.html> 12

Graterol, Yohan D.(2014) MongoDB en español – Tomo 1 “El principio”. Recuperado el 22 de marzo de 2015. Disponible en: < http://www.etnassoft.com/biblioteca/mongodb-en-espanol-t1-el-principio/ >

http://www.etnassoft.com/biblioteca/mongodb-en-espanol-t1-el-principio/


inglés "humongous". Está liberada bajo licencia de software libre, específicamente

GNU AGPL 3.0. MongoDB usa el formato BSON (JSON Compilado) para guardar

la información, dando la libertad de manejar un esquema libre. Este motor de bases

de datos es uno de los más conocidos y usados, pudiéndolo comparar en

popularidad con MySQL en el caso de las bases de datos relacionales.

MongoDB ha ganado popularidad por una serie de atractivas características:

Uso de documentos en formato JSON.

Los registros son almacenados como documentos.

Permite asociar los documentos sobre estructuras de tipo colección similares a las

tablas en los sistemas relacionales.

Está optimizado para equipos de múltiples procesadores.

Es muy destacable su velocidad de respuesta.

Soporta modelos de datos embebidos lo que reduce la actividad de lectura y

escritura en el sistema de base de datos.

Suporta indexación sobre documentos para realizar búsquedas rápidas.

Su administración permite la fácil escalabilidad.

Posee un alto grado de disponibilidad.


1.10. Marco Conceptual

Los siguientes son los conceptos a tener en cuenta para el desarrollo del proyecto.

1.10.1. Sensor13

Es un dispositivo capaz de detectar magnitudes físicas o químicas, llamadas variables de

instrumentación, y transformarlas en variables eléctricas. Las variables de

instrumentación pueden ser por ejemplo: temperatura, intensidad lumínica,

distancia, aceleración, inclinación, desplazamiento, presión, fuerza, torsión,

humedad, pH, etc. Una magnitud eléctrica puede ser una resistencia eléctrica (como

en una RTD), una capacidad eléctrica (como en un sensor de humedad), una

Tensión eléctrica (como en un termopar), una corriente eléctrica (como en un

fototransistor), etc.

1.10.2. Telemetría14

La telemetría es una tecnología que permite la medición remota de magnitudes físicas y el

posterior envío de la información hacia el operador del sistema. La palabra

telemetría procede de las palabras griegas tele ("lejos") y metron ("medida").

El envío de información hacia el operador en un sistema de telemetría se realiza

típicamente mediante comunicación inalámbrica, aunque también se puede realizar

por otros medios (teléfono, redes de ordenadores, enlace de fibra óptica, etcétera).

1.10.3. Raspberry Pi15

Es una placa computadora (SBC) de bajo costo desarrollada en Reino Unido por la

Fundación Raspberry Pi, con el objetivo de estimular la enseñanza de ciencias de la

computación en las escuelas.

El diseño de la Raspberry Pi incluye un System-on-a-chip Broadcom BCM2835, que

contiene un procesador central (CPU) ARM1176JZF-S a 700 MHz (el firmware

incluye unos modos Turbo para que el usuario pueda hacerle overclock de hasta 1

13

Vargas, Aldo. Sensores. Centro de formación profesional automotriz. Mexico.2009.20p. 14

TELEMETRIA. (sin fecha). Recuperado el 10 de septiembre de 2014. Del sitio oficial de IOCOM <http://iocom.com.co/telemetria> 15Página oficial de Raspberrypi. (Sin Fecha). Recuperado el 10 de septiembre de 2014. Disponible

en <http://www.raspberrypi.es/ >

http://www.raspberrypi.es/



GHz sin perder la garantía), un procesador gráfico (GPU) VideoCore IV, y 512 MB

de memoria RAM aunque originalmente al ser lanzado eran 256 MB. El diseño no

incluye un disco duro o una unidad de estado sólido, ya que usa una tarjeta SD para

el almacenamiento permanente; tampoco incluye fuente de alimentación o carcasa.

El modelo B se vende a 35$ y el modelo A a 25$. El 29 de febrero de 2012 la

fundación Raspberry Pi empezó a aceptar órdenes de compra del modelo B, y el 4

de febrero de 2013 del modelo A.

1.10.4. Gestor de Bases de Datos16

Un gestor de base de datos o sistema de gestión de base de datos (SGBD o DBMS) es un

software que permite introducir, organizar y recuperar la información de las bases

de datos; en definitiva, administrarlas.

1.10.5. Aplicación17

También llamados Aplicativos, forman parte del software ya que son una serie de

programas que han sido desarrollados para facilitarle al usuario la utilización de la

máquina para una acción o fin determinados. Una aplicación está diseñada y

optimizada como una herramienta para un propósito específico, como respuesta

ante una necesidad del usuario.

1.10.6. TCP/IP18

“Protocolo de control de transmisión/Protocolo de Internet", Es una familia de protocolos

desarrollados para permitir la comunicación entre cualquier par de ordenadores de

cualquier red o fabricante, respetando los protocolos de cada red individual. En

algunos aspectos, TCP/IP representa todas las reglas de comunicación para Internet

y se basa en la noción de dirección IP, es decir, en la idea de brindar una dirección

IP a cada equipo de la red para poder enrutar paquetes de datos. Originalmente se

creó con fines militares.

16

Barranco, Manuel J. (2013). GESTORES DE BASES DE DATOS. Recuperado el 10 de septiembre de 2014, de <http://wwwdi.ujaen.es/~barranco/publico/ofimatica/tema7.pdf> 17

Lanzillotta, Analía. (2013). Definición de Aplicación. Recuperado el 22 de septiembre de 2014, de <http://www.mastermagazine.info/termino/3874.php> 18

García, Jesús. Ferrando, Santiago y Piattini, Mario. Redes Para Procesos Distribuidos. México, Alfaomega, 1997, P267.


http://wwwdi.ujaen.es/~barranco/publico/ofimatica/tema7.pdf


1.10.7. Equipo Servidor19

Cuando en una red cliente/servidor existe una gran cantidad de recursos, es normal que

existan varios equipos servidores, pudiendo estar cada uno de ellos dedicado a

ofrecer un solo tipo de servicio o información. Así, un servidor dedicado puede ser

exclusivamente de archivos, de impresoras, de bases de datos, de correo electrónico,

de páginas web, etc.

1.10.8. Equipo Cliente

Si un servidor se encarga de prestar un servicio, su contra parte, el cliente, se encarga de

hacer uso de este servicio, es así como un a través de un equipo cliente se encarga

de interactuar con un sistema informático.

1.10.9. Sistema Distribuido

Un sistema distribuido es una colección de computadoras independientes, conectadas en

red, comunican y coordinan sus acciones únicamente mediante el paso de mensajes,

que aparecen ante los usuarios del sistema como una única computadora o servicio.

1.10.10. Lightweight Directory Access Protocol 20

Conocido como LDAP por sus siglas en inglés, es un protocolo para los servicios de

directorios basados en el estándar x.500 donde se almacenan atributos basados en

datos, utiliza un modelo cliente servidor que se basa en entradas con colecciones de

atributos almacenados en un árbol lógico bajo un nombre de domino.

19

Ibíd.,p226. 20

Marshall, Brand.(sin fecha) Introduction to LDAP. Recuperado el 28 de septiembre de 2014, Disponible en: <http://quark.humbug.org.au/publications/ldap/ldap_tut_v2.pdf>

http://quark.humbug.org.au/publications/ldap/ldap_tut_v2.pdf


1.11. Estado del Arte

Los sistemas de Control de Acceso son tan antiguos como la sociedad misma, puesto que

dichos sistemas consisten en la restricción selectiva de acceso a un lugar u otro

recurso, comúnmente el permiso de acceso al recurso, objeto o lugar se denomina

autorización.

Los primeros controles de acceso se basaron en el reconocimiento individual y el uso de

personal de seguridad para la conmutación del elemento de bloqueo (puerta), o el

uso de otro tipo de barrera para el acceso que comúnmente incluye candado y

llave.

En la seguridad física y control de acceso es importante conocer quien, donde y cuando. El

sistema debe determinar quién está autorizado para ingresar o salir, dónde está

autorizado para ingresar o salir y cuando está autorizado para ingresar o salir.

Históricamente se ha relacionado con el uso de cerraduras y llaves. Cuando la

puerta está cerrada, únicamente una persona con la llave puede abrirla,

dependiendo de cómo esté adecuada la cerradura. Los mecanismos de cerradura y

llave no tienen restricciones de tipo temporal, no tienen registros de los accesos

sobre las cerraduras, y pueden ser copiadas con relativa facilidad, de manera que el

responsable puede trasferir la llave a alguien sin autorización.

Los sistemas de control de acceso electrónico usan equipos de cómputo para solventar las

limitaciones de los sistemas mecánicos como cerraduras y llaves, un amplio rango

de credenciales puede suplantar los sistemas mecánicos. Los sistemas de control de

acceso electrónicos garantizan el acceso basados en la credencial que se presente.

Cuando el acceso se ha garantizado, la puerta se desbloquea y el sistema deja un

registro con la hora del suceso y el usuario. Cuando el acceso no es permitido, la

puerta permanece cerrada y el sistema deja un registro de la hora, y si es necesario

dispara una alerta. Si el sistema detecta que la puerta es forzada se debe generar

una alarma.

La Identificación Biométrica, consiste en el estudio de métodos automáticos para el

reconocimiento único de seres humanos basado en una o más características físicas.

En las tecnologías de la información la “autenticación biométrica” o “biometría


informática” es la aplicación de algoritmos sobre los rasgos físicos del individuo

para verificar su identidad.

Los sistemas de control de acceso con identificación biométrica son relativamente nuevos,

en 1883 Alphonse Bertillon desarrolló un sistema antropométrico para la

identificación de criminales.A finales del siglo XIX el científico Sir Francis Galton

demostró que el patrón de huellas dactilares es exclusivo de cada individuo. En

1936 el oftalmólogo Frank Burch propuso usar patrones de iris como método de

identificación. Para la década de 1980 las películas de ciencia ficción mostraban

modernos sistemas que identificaban el usuario por sus características físicas. En

1994 la compañía Iridian Technologies presentó los primeros algoritmos para el

reconocimiento del iris.

Existen muchas soluciones tecnológicas en el mercado actual, estas soluciones tecnológicas

no usan tecnologías libres, debido que los temas de soporte y el licenciamiento de

los componentes del Sistema, sin embargo son numerosas las iniciativas

académicas y de entusiastas de la tecnología, las cuales abordan el tema de control

de acceso haciendo uso de componentes como el Raspberry Pi, algunos de estos

proyectos son:

Monitor Your Home With the Raspberry Pi B+21

: Este proyecto de domótica hace uso

de tecnologías libres para programar un sistema que permita el monitoreo remoto a

través de una cámara de video. Dentro de las mejoras futuras mencionan la

capacidad de completar el sistema con sensores y por ende con métodos de control

de acceso.

RFPiD – Raspberry Pi RFID door access system22

: Desarrollado por la organización

NESIT, es un proyecto para remplazar su sistema de control de acceso a base

de tarjetas RFID, este sistema de acceso puede ser controlado vía remota a

21

Schwartz, Marco. (2014) Monitor Your Home With the Raspberry Pi B+. publicado el 26 de septiembre de 2014.Recuperado el 31 de julio de 2015, de https://www.openhomeautomation.net/monitor-your-home-raspberry-pi-b/ 22

RFPiD – Raspberry Pi RFID door access system. (Sin fecha). Recuperado el 31 de julio de 2015, de http://nesit.org/rfpid-raspberry-pi-rfid-door-access-system/


través de Google Talk, utiliza un base SQLite la cual almacena la información

del sistema.

Raspberry Pi Access Control System (RPAC)23: Este proyecto también utiliza

Raspberry Pi como herramienta para habilitar o denegar el acceso a través de

un lector de tarjetas RFID que se conecta a una puerta física. Esta desarrollado

bajo el lenguaje de Phyton y utiliza el protocolo I2C para intercomunicar el

hardware del sistema.

También existen artículos científicos publicados sobre el tema de las tecnologías libres y

los sistema de control de acceso, es el caso del articulo ‘Access Control of Door

and Home Security by Raspberry Pi Through Internet’24

, el cual menciona los

aspectos técnicos para crear un proyecto de control de acceso usando un Raspberry

Pi como elemento central. La figura 4 ilustra el montaje general del proyecto.

Ilustración 4 Montaje de un sistema de control de acceso

Fuente: Chowdhury, Nasimuzzaman. Nooman, Shiblee, Sarker, Srijon. Access Control of Door and Home Security

by Raspberry Pi Through Internet. [En línea] [consulta: 31 de Julio de 2015] Disponible en: <

http://www.researchgate.net/publication/258337862_Access_Control_of_Door_and_Home_Security_by_Ras

pberry_Pi_Through_Internet.>

23

Pearson, Oskar. (2014). Raspberry Pi Access Control System (RPAC), recuperado el 31 de julio de 2015, disponible en https://github.com/oskarpearson/raspberry-pi-access-control-system 24

Chowdhury, Nasimuzzaman. Nooman, Shiblee, Sarker, Srijon. (2013). Access Control of Door and Home Security by Raspberry Pi Through Internet. International Journal of Scientific & Engineering Research, Volume 4, Issue 1ŗ. Recuperado el 31 de julio de 2015, de http://www.researchgate.net/publication/258337862_Access_Control_of_Door_and_Home_Security_by_Raspberry_Pi_Through_Internet


1.12. Marco Metodológico La metodología seleccionada para ejecutar el proyecto es Scrum por la agilidad y

adaptabilidad que tiene para un este tipo de desarrollos, las fases de esta

metodología son:

Planificación: corresponde al análisis, diseño de arquitectura, selección de

tecnologías, equipo de trabajo y alcances de la solución tecnológica.

Sprint: Corresponde al desarrollo de una cantidad de elementos identificados en la

primera fase, ejecución de las tareas, pruebas de los componentes y revisión de los

entregables

Implementación: Ensamblar los componentes entregados y aprobados en el Sprint.

Revisión del Sprint: Analizar las falencias y aciertos en el Sprint, así como los

impactos en los Sprits subsiguientes, preparar el equipo de trabajo para el siguiente

Sprint.

Ilustración 5 Ciclo de vida de un proyecto con Scrum.

Fuente: Trigas, Manuel . Metodología Scrum. [En línea] [Consulta: 08 de septiembre de 2014]

Disponible en: < http://openaccess.uoc.edu/webapps/o2/bitstream/10609/17885/1/mtrigasTFC0612memoria.pdf>


1.13. Factibilidad

1.13.1. Factibilidad Técnica

El proyecto es viable ya que se cuentan con las herramientas técnicas necesarias para poder

desarrollar el prototipo de sistema de control de acceso como lo son el hardware,

software y los sistemas de interconexión que hacen posible su funcionamiento, a

continuación el detalle de cada uno de estos aspectos técnicos:

Hardware

Las herramientas de trabajo para el desarrollo del proyecto son las apropiadas para

implementar un sistema tecnológico como el propuesto, ya que se cuenta con los

siguientes equipos de cómputo y hardware

1 computadores Dell Inspiron R14 con:

Procesador Intel Core i3-M370.

Linux Ubuntu 14.04 LTS de 64Bit.

Pantalla 14.0" High Definition (720p) LED.

Disco duro SATA de 320 GB (5400 rpm).

Unidad combo DVD+/-RW.

Memoria 3 GB Dos canales SDRAM DDR3 a 1333 MHz.

1 computador Dell Inspiron 1420 con:

Linux Ubuntu 12.0 LTS 32 bits.

Procesador Intel core 2 Duo de 2.4 GHz.

Disco duro SATA de 160 GB.

Memoria 2 GB Dos canales SDRAM DDR3.

Unidad combo DVD+/-RW.

1 tarjeta RASPBERRY PI modelo B

512 MB of RAM.

Dos puertos USB.

Un puerto 100mb Ethernet.

Procesador 700 MHz (Familia ARM11 con set de instrucciones ARMv6).

GPU Broadcom VideoCore IV de 250 MHz.

Dos puertos USB 2.0.

Dos salidas de video Compuesta por una RCA (PAL and NTSC) y un puerto HDMI .

Salida de audio con Jack de 3.5 mm.


Interconexión

Para la conexión de red se cuenta con un Switch de 8 puertos marca Encore de referencias

ENH908-NWY, con conectividad de 10/100 Mbps, detección automática de

velocidad y soporte full-duplex. Los equipos de cómputo y hardware que

componen el sistema tienen puertos de conexión Ethernet lo que permite una

adecuada conexión de red para realizar la transmisión de información.

Software

Se cuenta con el software que logra una dualidad de tipo lógico y gráfico que permite

cumplir con todos los requerimientos de diseño e implementación que el proyecto

exige. Dicho Software está compuesto por el IDE NetBeans 7.3, para el desarrollo

de las interfaces y lógica del sistema, El motor de Base de datos No SQL donde se

almacena la información requerida por el Sistema para su funcionamiento el

Sistema operativo Ubuntu 14.04 LTS donde se ejecutara la aplicación.

1.13.2. Factibilidad Operativa

El Prototipo de Sistema de Control de Acceso con Tecnologías Libres, requiere para su

operación de un administrador del sistema y un directorio activo además requiere

que los usuarios de la organización estén registrados en el directorio activo. Los

anteriores requisitos se pueden cumplir lo que hace factible el proyecto en su parte

operativa.

1.13.3. Factibilidad Legal

Se cuenta con el completo licenciamiento del software requerido para el proyecto

(compuesto por Equipos con sistema operativo Linux , Netbeans IDE 7.0 y Mongo

DB 3.0) y se trabajará teniendo en cuenta las leyes que rigen la normatividad y

ética profesional inherente a la Ingeniería en Telemática, lo anterior permite

establecer que el proyecto cuenta con un marco legal el cual lo hace factible.

http://www.alinx.ca/encore-port-10100mbps-nway-switch-p-11927.html


1.13.4. Factibilidad Económica

Gastos de Software.

Licencia Netbeans IDE 7.3 $ 0

Licencia MongoDB 3.0 $ 0

Licencia Ubuntu 14.04 LTS $ 0

Licencia Ubuntu 12.04 LTS $ 0

Licencia Centos OS $ 0

Licencia OpenLDAP $ 0

Gastos de Hardware

Dell Inspiron R14 $ 1.050.000

Dell Inspiron 1420 $ 980.000

Raspberry Pi Model B $ 140.000

Recurso Humano (por hora)

Desarrolladores x 2 recursos $ 30.000

Asesor Técnico $ 50.000

Servicios Públicos (por 4 meses)

Teléfono $ 150.000

Energía Eléctrica $ 200.000

Otros gastos

2 Resmas de Papel: $ 26.000

5 DVD: $ 15.000

Fotocopias: $ 20.000


Transporte: $ 200.000

Internet: $ 300.000

Los gastos operativos del proyecto evidencian que no hay costos asociados al

licenciamiento, lo que permite establecer que el sistema no va a poseer ningún

costo asociado al licenciamiento del software o hardware que lo componen. Por lo

anterior el proyecto es factible económicamente.

1.14. Riesgos del Proyecto

1.14.1.Estrategias del riesgo pre activo. A continuación se encuentra la tabla que contiene los riesgos pre activos.

Tabla 1 Riesgos pre activos

CATEGORÍA PREGUNTAS RIESGO

Requerimientos ¿Los requerimientos identificados al

iniciar el proyecto han sido los mismos a

lo largo de su desarrollo?

Cambiar los requerimientos a

mitad del proyecto puede

causar pérdida de tiempo y de

trabajo.

Equipo de trabajo

¿Los integrantes del equipo de trabajo

presentan problemas que los obligue a

salir temporal o permanentemente del

proyecto?

- Retraso en el tiempo

estimado para la finalización

del proyecto.

Tecnología ¿Se han tenido en cuenta las herramientas

de software con que cuenta la entidad?

- Desarrollar un producto que

no se pueda ajustar a las

herramientas con las que

cuenta el cliente.

Usuarios

¿Se han identificado completamente a los

usuarios finales del sistema?

- Podrían aparecer al finalizar

el proyecto nuevas tareas que

no estaban estipuladas que

obliguen a la modificación del

trabajo realizado.


¿El resultado del proyecto es familiar y

fácil de comprender para los usuarios

finales del sistema?

¿Tienen los usuarios finales alguna

herramienta en donde apoyarse en caso de

dudas o inquietudes?

- Los Usuarios finales no

podrían entender el manejo y

acceso al sistema, lo que

produciría un rechazo a este.

- El no proporcionar a los

usuarios las ayudas necesarias

para operar el sistema puede

provocar rechazo hacia él o

bien no aprovecharlo al

máximo.

Fuente: Adaptado de: Varas, Marcela. Gestión de Proyectos de Desarrollo de Software.

Departamento de Ingeniería Informática y Ciencias de la Computación Facultad de Ingeniería

Universidad de Concepción. Chile 2000. 81p.

1.14.2. Consecuencias del riesgo

Tabla 2 Consecuencias del riesgo

RIESGO CONSECUENCIA

Cambiar los requerimientos a mitad

del proyecto puede causar pérdida de

tiempo y de trabajo.

Además de significar pérdida de tiempo, el trabajo realizado

podría quedar desechado, y además se requerirá más tiempo

para volver a identificar las necesidades e implementarlas,

por consiguiente el retraso en la entrega del proyecto.

Retraso en el tiempo estimado para

la finalización del proyecto.

Descontento por parte del cliente, quien podría perder el

interés en el proyecto y dejar de apoyarlo.

Desarrollar un producto que no se

pueda ajustar a las herramientas con

las que cuenta el cliente.

Descontento por parte del cliente, quien podría perder el

interés hacia el sistema.

Podrían aparecer al finalizar el

proyecto nuevas tareas que no

estaban estipuladas que obliguen a la

modificación del trabajo realizado.

Requerir más tiempo para identificar las nuevas necesidades

e implementarlas en el trabajo ya hecho, retrasando la

entrega del proyecto.


Los Usuarios finales no podrían

entender el manejo y acceso al

sistema, lo que produciría un rechazo

a este.

Descontento por parte del cliente, quien podría rechazar

totalmente el sistema y volver a su antigua forma de trabajo.




1.14.3. Probabilidad e impacto de riesgo

Tabla 3 Probabilidad e impacto de riesgo

RIESGO PROBABILIDAD DE QUE

OCURRA (100%)

IMPACTO

(1 - 5)

Cambiar los requerimientos a mitad del

proyecto puede causar pérdida de tiempo y de

trabajo.

10% 4

Retraso en el tiempo estimado para la

finalización del proyecto.

40%

4

Desarrollar un producto que no se pueda

ajustar a las herramientas con las que cuenta

el cliente.

10% 3

Podrían aparecer al finalizar el proyecto

nuevas tareas que no estaban estipuladas y

obligar la modificación del trabajo realizado.

25% 3

Los Usuarios finales no podrían entender el

manejo y acceso al sistema, lo que produciría

un rechazo a este.

10%

2

El no proporcionar ayudas al usuario sobre 10% 3


como operar el producto puede provocar

rechazo hacia él o bien no aprovecharlo al

máximo.

TOTAL 17.5% 3.16%





2. FASE DE DEFINCIÓN

2.1. Requerimientos

2.1.1. Requerimientos Funcionales

• El sistema debe poder gestionar las zonas de acceso según usuarios.

• El sistema debe contar una interfaz gráfica para su administración.

• Se requiere que el sistema funcione de forma distribuido, soportando la falta de conexión de la

red.

• El sistema debe permitir la consultar de información de los usuarios registrados en un directorio

LDAP.

• Se requiere que el sistema permita administrar dispositivos.

• Se requiere que el sistema registre eventos relacionados con el acceso de los usuarios.

• Se requiere que el sistema permita generar reglas de acceso de los usuarios o grupos sobre los

dispositivos o zonas.

• Se requiere que el sistema registre los cambios en las reglas de acceso de los usuarios.

• Se requiere que el sistema permita consultar la información de los grupos de usuarios en un

directorio LDAP.

• Se requiere que el sistema implemente un protocolo de comunicación seguro.

2.1.2. Requerimientos No funcionales

• Se requiere que el sistema funcione sobre Raspberry Pi.

• Se requiere que no tenga ninguna licencia propietaria para la operación.

• Se requiere que el sistema haga uso de las tecnologías libres que existen en el mercado.


2.2. Historias de Usuario. A continuación se presentan las historias de Usuarios que componen el Prototipo de Sistema de

control de Acceso, estas Historias de usuarios son el insumo para el desarrollo de la solución

tecnológica.

2.2.1. Definiciones

Unidad: Dispositivo Raspberry Pi configurado para funcionar dentro del sistema.

Sistema Central: Aplicativo el cual se encarga de comunicarse con las unidades del sistema a

modo de fuente de información para el sistema, también se encarga de hacer las consultas al

directorio LDAP.

Directorio LDAP: servicio que implemente un árbol LDAP donde se almacenen los datos de los

usuarios que hacen parte del sistema.

Regla de Acceso: Conjunto de información que identifica una política de acceso o denegación del

mismo y que se encuentra guardada en el sistema central.

Evento: Todo acción efectuada sobre la unidad que modifica su estado inicial sea por interacción

de con los usuarios del sistema o por un cambio interno en su funcionamiento.

2.2.2. IDH-1 Fallas en la conexión de red

Funcionamiento: Cuando por algún motivo se pierde conexión con el sistema central, cada unidad

debe estar en la capacidad de funcionar de forma individual de tal manera que permita ser

utilizadas por los usuarios del sistema:

Resultado: La unidad que se encuentre fuera de línea permitirá acceso a los usuarios que tengan los

permisos correspondientes para dicho punto de acceso. En caso que el usuario no tenga los

permisos necesarios la unidad negara el acceso y procederá a generar un evento de alerta que

será guardado de forma local, Cuando el sistema se encuentre de nuevo en línea, los datos

locales de los eventos se sincronizarán con el sistema central.

Escenarios:

Número de Escenario: R1-1.

Criterio de Aceptación Usuario con permisos logra acceder.

Contexto: Unidad sin conexión de red.

Evento: El usuario procede a realizar el proceso de


acceso usando el método de identificación

determinado para la unidad.

Funcionamiento La unidad válida en sus reglas de acceso local

que el usuario tiene los permisos requeridos y

procede a dar acceso.


Criterio de Aceptación Usuario sin permisos no logra acceder.

Contexto: Unidad sin conexión de red.

Evento:

El usuario procede a realizar el proceso de

acceso usando el método de identificación


Funcionamiento

La unidad válida en sus reglas de acceso

local que el usuario no tiene los permisos

requeridos y procede a negar el acceso.


Criterio de Aceptación La unidad sincroniza su información con el

sistema central.

Contexto: Unidad retoma la conexión con el sistema

central y vuelve estar en línea.

Evento:

La unidad retoma la conexión con el sistema

central, procede a sincronizar la información

que guardo de forma local mientras se

encontraba fuera de línea.

Funcionamiento

El sistema central y la unidad comparten la

misma información actualizada sobre los

eventos de acceso.


Criterio de Aceptación La unidad se encuentra fuera de línea.

Contexto: La unidad pierde conexión con el sistema


central

Evento:

La unidad identifica que se encuentra sin

conexión al sistema central y procede a

registrar de forma local eventos de acceso.

Funcionamiento

La unidad entra a funcionar en el modo fuera

de línea, utiliza su base de datos local para

registrar los eventos


Criterio de Aceptación La unidad procede a denegar el acceso a

todos los usuarios.

Contexto: La unidad excede el tiempo máximo que

puede estar fuera de línea.

Evento:

La unidad supera el tiempo máximo

establecido para funcionar fuera de línea,

procede a entrar en modo “suspendido”

donde solo le permite acceso a los usuarios

que se encuentren cobijados bajo la regla de

acceso que permite el acceso a todas las

zonas del sistema.

Funcionamiento

La unidad no permitirá el acceso a ningún

usuario que se encuentre por fuera de la regla

de acceso a todas las zonas del sistema hasta

que se encuentre de nuevo en línea.


Criterio de Aceptación

El sistema central informa que una unidad ha

superado el tiempo máximo en que puede

encontrarse fuera de línea

Contexto: La unidad excede el tiempo máximo en que


puede estar fuera de línea.

Evento:

La unidad supera el tiempo máximo

establecido para funcionar fuera de línea, el

sistema central procede a generar un evento

indicando la situación actual de la unidad.

Funcionamiento El sistema cuenta con el registro de la falla en

la conexión con la unidad

2.2.3. IDH-2 Almacenamiento de Eventos

Funcionamiento: Cuando el usuario o el sistema interactúan con la unidad, esta debe generar

eventos que serán persistidos por el sistema central

Resultado: La unidad debe generar un evento por cada acceso garantizado o denegado a los

usuarios, errores de conexión con el sistema central, actualización de su copia local de

información y registro de uso de la unidad por parte de los usuarios.

Escenarios:


Criterio de Aceptación La unidad genera un evento cuando se

garantiza el acceso al usuario que lo solicita

Contexto: Usuario con permisos solicita acceso.


acceso.

Funcionamiento

La unidad valida que el usuario tenga

permiso de acceso con sus reglas de acceso

locales, guarda el registro localmente.



Criterio de Aceptación La unidad genera un evento cuando se niega

el acceso al usuario que lo solicita.

Contexto: Usuario sin permisos solicita acceso


ingreso.

Funcionamiento

La unidad valida que el usuario tenga

permiso de acceso con sus reglas de acceso

locales, guarda el registro localmente.


Criterio de Aceptación La unidad genera un evento de acceso.

Contexto: Unidad en línea con el sistema central.

Evento:

La unidad otorga o niega el acceso a un

usuario y genera un evento de acceso que se

envía al sistema central para que sea

persistido.

Funcionamiento

La unidad envía la información del evento al

sistema central quien almacenará la

información del evento generado.


Criterio de Aceptación La unidad genera un evento de acceso.

Contexto: Unidad en fuera de línea con el sistema

central.

Evento:

La unidad pierde la conexión con el sistema

central, a su vez se genera un evento cuando

otorga o niega el acceso a un usuario.

Funcionamiento

La unidad guarda la información en su base

de datos loca, una vez vuelva a estar en línea

con el sistema envía la información de los


eventos generados durante el tiempo en que

se encontró fuera de línea al sistema central

,quien almacenará la información del evento

generado.

2.2.4. IDH-3 Reglas de Acceso

Funcionamiento: Cuando el usuario administrador realiza cambios en el sistema, este debe guardar

registro en el almacenamiento central

Resultado: El sistema debe guardar un registro por cada cambio en la configuración por cada uno

de los dispositivos, zonas o reglas. Las reglas serán definidas en modo descendente, donde se

aplica la regla que primero se encuentre. Las reglas identifican quién (usuario o grupo) participa

en la regla, a dónde se dirige la regla (dispositivo o zona), cuando actúa la regla (siempre o por

horario) y qué se quiere lograr (permitir o denegar) a modo de configuración de políticas de

firewall.

Escenarios:


Criterio de Aceptación El sistema guarda el registro del cambio

realizado.

Contexto: El usuario administrador modifica una regla

de acceso.

Evento: El usuario administrador procede a realizar

un cambio en una regla de acceso.

Funcionamiento

En el momento en que la unidad esté en línea

el sistema procede a enviar las reglas

actualizadas de acceso a la unidad


Criterio de Aceptación El sistema guarda el registro de la regla

creada.


Contexto: El usuario administrador crea una regla de

acceso.

Evento: El usuario administrador procede a crear una

regla de acceso

Funcionamiento


el sistema procede a enviar las nuevas reglas

de acceso a la unidad


Criterio de Aceptación El sistema elimina la regla y guarda el

registro.

Contexto: El usuario administrador elimina una regla de

acceso.

Evento: El usuario administrador procede a eliminar

una regla de acceso.

Funcionamiento


el sistema procede a enviar las reglas

actualizadas de acceso a la unidad.

2.2.5. IDH-4 Interfaz Gráfica De Administración

Funcionamiento: El administrador del sistema debe contar con una herramienta de gestión del

sistema con una interfaz gráfica que le permita realizar las operaciones de administración sobre

las unidades, las zonas y reglas de acceso.

Resultado: El sistema tendrá la capacidad de ser monitoreado y administrado por un usuario

administrador mediante una interfaz gráfica en un entorno Web.

Escenarios:


Criterio de Aceptación El Usuario Administrador podrá consultar las


unidades en el sistema.

Contexto: Usuario con permisos administra las unidades

del sistema

Evento:

El usuario procede a ingresar al apartado de

la administración de las unidades y procede a

consultar las unidades

Funcionamiento La unidad procede a generar una vista con las

unidades configuradas y su estado actual.


Criterio de Aceptación El Usuario Administrador podrá agregar una

nueva unidad al sistema.

Contexto: Usuario con permisos administra las unidades

del sistema.

Evento:


la administración de las unidades y procede a

configurar una nueva unidad.

Funcionamiento

La unidad procede a generar un evento de

configuración inicial informando el estado de

la configuración


Criterio de Aceptación El Usuario Administrador podrá administrar

las reglas de acceso

Contexto: Usuario con permisos administra las reglas

de acceso.

Evento:


la administración de las reglas de acceso,

consulta, crea, modifica o elimina una regla

de acceso.

Funcionamiento El sistema realiza la consulta, creación,

modificación o eliminación de la regla de


acceso informando de los cambios a las

unidades afectadas.


Criterio de Aceptación El Usuario Administrador podrá Administrar

las zonas de acceso.

Contexto: Usuario con permisos administra las zonas de

acceso

Evento:


la administración de las zonas de acceso y

consulta, crea, modifica o elimina las zonas

de acceso.

Funcionamiento

El sistema realiza la consulta, creación,

modificación o eliminación de la zona de

acceso informando de los cambios a las

unidades afectadas.

2.3. Cronograma El Prototipo de Sistema de Control de Acceso Tiene un cronograma estimado de 86 días

comenzando el lunes 13 de abril del 2015 y terminando el 13 de agosto de 2015, para un total de

4 meses calendario. Las actividades que componen el proyecto se detallan a continuación:

Nombre de tarea Duración Comienzo Fin

Análisis 15 días lun 13/04/15 vie 01/05/15

Identificación de Tareas 1 día lun 13/04/15 lun 13/04/15

Determinación de la fecha de entrega y la funcionalidad de una o más versiones

1 día mar 14/04/15 mar 14/04/15

Selección de la versión más adecuada para desarrollo inmediato

2 días mié 15/04/15 jue 16/04/15

Trazado de los “paquetes del producto” (objetos) sobre los elementos del backlog de la versión elegida.

3 días vie 17/04/15 mar 21/04/15

Selección del equipo o equipos para desarrollar la nueva versión.

2 días mié 22/04/15 jue 23/04/15

Evaluación y control adecuado de los riesgos 2 días vie 24/04/15 lun 27/04/15


Estimación del coste de la versión, incluyendo desarrollo, material, marketing, formación y despliegue

3 días mar 28/04/15 jue 30/04/15

Conformidad de la dirección y financiación del proyecto

1 día vie 01/05/15 vie 01/05/15

Diseño y Arquitectura 10 días lun 04/05/15 vie 15/05/15

Revisión de los elementos de las tareas incluidos en la versión

1 día lun 04/05/15 lun 04/05/15

Identificación de los cambios necesarios para implementar el backlog

2 días mar 05/05/15 mié 06/05/15

Análisis del dominio para incluir los requisitos que incluye el desarrollo mejora o actualización.

1 día jue 07/05/15 jue 07/05/15

Acotar la arquitectura del sistema para apoyar el nuevo contexto y necesidades

1 día vie 08/05/15 vie 08/05/15

Identificar problemas del desarrollo o modificaciones.

3 días lun 11/05/15 mié 13/05/15

Reunión de revisión de diseño. Cada equipo presenta los cambios para implementar los elementos del backlog, e identificar posibles reasignaciones

2 días jue 14/05/15 vie 15/05/15

Desarrollo 57 días lun 18/05/15 mar 04/08/15

Sprint 1 25 días lun 18/05/15 vie 19/06/15

Planeación 1 2 días lun 18/05/15 mar 19/05/15

Desarrollo 1 15 días mié 20/05/15 mar 09/06/15

Envoltura 1 2 días mié 10/06/15 jue 11/06/15

Revisión 1 4 días vie 12/06/15 mié 17/06/15

Ajuste 1 2 días jue 18/06/15 vie 19/06/15

Sprint 2 18 días lun 22/06/15 mié 15/07/15

Planeación 2 2 días lun 22/06/15 mar 23/06/15

Desarrollo 2 10 días mié 24/06/15 mar 07/07/15

Envoltura 2 1 día mié 08/07/15 mié 08/07/15

Revisión 2 3 días jue 09/07/15 lun 13/07/15

Ajuste 2 2 días mar 14/07/15 mié 15/07/15

Sprint 3 14 días jue 16/07/15 mar 04/08/15

Planeación 3 2 días jue 16/07/15 vie 17/07/15

Desarrollo 3 6 días lun 20/07/15 lun 27/07/15

Envoltura 3 1 día mar 28/07/15 mar 28/07/15

Revisión 3 3 días mié 29/07/15 vie 31/07/15

Ajuste 3 2 días lun 03/08/15 mar 04/08/15

Cierre 4 días mié 05/08/15 lun 10/08/15

Implementación 3 días mié 05/08/15 lun 08/08/15

Retrospectiva 1 día mié 09/08/15 lun 10/08/15

Total Tiempo Del Proyecto 86 días lun 13/04/15 lun 10/08/15


Ilustración 6 Cronograma de actividades.

Fuente: Los autores


3. FASE DE DESARROLLO

3.1. Diagramas de Flujo Funcional Los diagramas de Flujo Funcional permiten visualizar el flujo lógico del sistema, la forma en que el

usuario interactúa con las unidades y a su vez, la forma en que la unidad se comunica con el

sistema central.

3.1.1. Solicitud de Acceso

Ilustración 7 Flujo Funcional Solicitud de Acceso.

Fuente: Los autores.


3.1.2. Generar Evento

Ilustración 8 Flujo funcional Generar Evento.


3.1.3. Modificar Regla de Acceso

Ilustración 9 Flujo funcional Modificar Regla de Acceso.



3.1.4. Agregar Una Unidad Al Sistema

Ilustración 10 Flujo funcional Agregar Una Unidad Al Sistema.



3.2. BackLog de Actividades Dentro de las actividades de desarrollo de un proyecto bajo la metodología Scrum se hace necesario

priorizar las tareas con los tiempos utilizados para cada uno de ellas. Es por eso que en la fase de

desarrollo del presente proyecto se acordaron 3 Sprints con 2 recursos de desarrollo, la

priorización de las tareas se detallan en la siguiente tabla:

ID Descripción

1 Configurar entorno de integración

2 Crear versión del ejecutable

3 Revisar comunicación entre dispositivos

4 Configurar servidor central Y Directorio LDAP

5 Revisar Escenarios

Sprint 1 Desarrollo del core del sistema

20 R4-2 Agregar unidad al Sistema

19 R4-1 Consultar unidades del Sistema

17 R3-2 Creación de reglas de acceso

6 R1-1 Usuario con permisos accede (unidad fuera de línea)

7 R1-2 Usuario sin permisos no accede (unidad fuera de línea)

8 R1-3 Unidad Sincroniza información con el servidor central

Sprint 2 Desarrollo de los Eventos de acceso al sistema

15 R2-4 Unidad genera evento (fuera de línea)

12 R2-1 Unidad genera evento al garantizar acceso (fuera de línea)

13 R2-2 Unidad genera evento al denegar acceso (fuera de línea)

9 R1-4 Unidad almacena eventos localmente

14 R2-3 Unidad genera un evento de acceso (en línea)

Release 1 Versión Estable

Sprint 3 Administración del Sistema

22 R4-4 Administración de zonas de acceso

21 R4-3 Administrar Reglas de Acceso

16 R3-1 Edición de una regla de acceso

18 R3-3 Eliminación de una regla de acceso

11 R1-6 Sistema genera evento de alarma (unidad excede tiempo fuera de línea)

10 R1-5 Unidad niega acceso a todos usuarios (unidad excede tiempo fuera de línea)

Release 2 Versión Funcional del Sistema

Tabla 4 BackLog general del proyecto.


3.3. Sprints El desarrollo del sistema se dividió en 3 fases o Sprints como se puede observar en el backlog

general, cada Sprint tiene una lista de actividades y unos esfuerzos en horas comprometidos, el


resultado de cada Sprint es una iteración en el ciclo de desarrollo, a continuación se detallan los

esfuerzos para cada uno de los Sprints del proyecto.

3.3.1. Sprint 1 Desarrollo del Core del sistema

El primer Sprint pretendió dar inicio al desarrollo de los componentes que conforman el Core del

sistema, dentro de este sprint se incurrieron es sobre esfuerzos de tiempo por parte de los

recursos, lo que se consideró anormal al comenzar esta etapa del proyecto, la siguiente tabla

demuestra los esfuerzos en horas de este Sprint:

Tabla 5 Esfuerzos Sprint 1.


Los sobre esfuerzos de este primer sprint se agruparon en los primeros días fueron de 56 horas lo

que genera una alarma en cuanto a la programación de los esfuerzos, en los siguientes Sprints

puede observarse como fue corregido este error.

ID Historia/Tarea

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Total Esfuerzos 27 19 15 17 26 17 13 11 14 10 4 6 10 11 4 4

Configurar entorno de integración 2 0 0 1 1 4

Crear versión del ejecutable 2

Revisar comunicación entre dispositivos 4 8 6 4 0 4 0 0 2 2 0 0 6

Configurar servidor central Y Directorio

LDAP8 8 4 3 4 5 5 6 6 4 0 0 5

Revisar Escenarios 2 2

IDH-1 Fallas en la conexión de red

R1-1Usuario con permisos accede (unidad

fuera de línea) 6 2 0 0 2

R1-2 Usuario sin permisos no accede (unidad

fuera de línea) 6 4

R1-3Unidad Sincroniza información con el

servidor central5 0 2 0 1

IDH-2 Almacenamiento de Eventos

R2-3 Unidad genera un evento de acceso (en

línea)4 0 2

IDH-3 Reglas de Acceso

R3-2 Creación de reglas de acceso 10 3 2 4 1

IDH-4 Interfaz Gráfica De Administración

R4-1 Consultar unidades del Sistema 8 2

R4-2 Agregar unidad al Sistema 5 0 3 6 5 4 2 0 0 0 0 6 0 5

Dias del Sprint/Esfuerzo en horas


Ilustración 11 Grafica de esfuerzo vs días del Sprint 1.


3.3.2. Sprint 2 Desarrollo de los Eventos de acceso al sistema

El sprint 2 se planeó para ser ejecutado en 10 días. Durante ese tiempo se pudo observar como la

carga de desarrollo decreció, y los esfuerzos a través de los días llevaron a que estabilizar el

proceso de desarrollo, en la siguiente tabla se puede observar los esfuerzos diarios del sprint.



27

19

15 17

26

17

13 11

14

10

4 6

10 11

4 4

0

5

10

15

20

25

30

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Esfu

erz

o(h

ora

s)

Días

Esfuerzo en el Sprint

ID Historia/Tarea

0 1 2 3 4 5 6 7 8 9 10

Total Esfuerzos 15 16 14 14 13 11 12 10 11 10 9

Configurar entorno de integración 2 0 1


Revisar comunicación entre dispositivos 2 2 1 1 0 0 0 1 0 0 3


LDAP3 1

Revisar Escenarios 2 2 0 0 0 2 0 2 2 0


R1-1Usuario con permisos accede (unidad


R1-2 Usuario sin permisos no accede (unidad


R1-4 Unidad almacena eventos localmente 6 8 2 2 0 0 4 8 4

R1-5 Unidad niega acceso a todos usuarios

(unidad excede tiempo fuera de línea)2 1

IDH-2 Almacenamiento de Eventos

R2-1 Unidad genera evento al garantizar

acceso (fuera de línea)8 5 0 0 1

R2-2 Unidad genera evento al denegar acceso

(fuera de línea)2 2

R2-3 Unidad genera un evento de acceso (en

línea)3 0 3 4 1 0 0 4

R2-4 Unidad genera evento (fuera de línea) 3 6 6 8


R3-2 Creación de reglas de acceso 3 2



En la siguiente figura se puede observar como los esfuerzos diarios tuvieron una tendencia a

estabilizarse al pasar los días, esto se encuentra acorde a las premisas de las metodologías agiles

de desarrollo, las cuales buscan que las cargas de desarrollo sean repartidas equitativamente a

través de los Sprints.



3.3.3. Sprint 3 Administración del Sistema

Durante el último Sprint se puede observar como la tendencia del esfuerzo en el desarrollo se

mantuvo con la misma tendencia que en el Sprint anterior, lo que indica que el proyecto entro en

una fase de estabilización, se cumplieron los objetivos de esta fase, y se produjo los

componentes de software necesarios para el funcionamiento del sistema. En la siguiente tabla se

muestran los esfuerzos del Sprint

15 16

14 14 13

11

12

10 11

10 9

0

2

4

6

8

10

12

14

16

18

0 1 2 3 4 5 6 7 8 9 10

Esfu

erz

o(h

ora

s)

Días

Esfuerzos en el Sprint



Fuente: Los Autores

Para el último sprint de la fase de desarrollo se puede observar como no hay cambios abruptos en

los esfuerzos a través de los seis días del sprint, la siguiente figura ilustra como al final del

Sprint los esfuerzos van disminuyendo una vez las tareas presentes en la anterior tabla son

completadas.



ID Historia/Tarea

0 1 2 3 4 5 6

Total Esfuerzos 16 14 13 13 12 10 8

Configurar entorno de integración 1


Revisar comunicación entre dispositivos 2 0 0 0 2


LDAP2

Revisar Escenarios 2 4 8 4


R1-5 Unidad niega acceso a todos usuarios

(unidad excede tiempo fuera de línea)2

R1-6 Sistema genera evento de alarma

(unidad excede tiempo fuera de línea)3 0 0 2


R3-1 Edición de una regla de acceso 5 2 3 2 2

R3-3 Eliminación de una regla de acceso 4

IDH-4 Interfaz Gráfica De Administración

R4-3 Administrar Reglas de Acceso 4 6 4 2

R4-4 Administración de zonas de acceso 8 6 4


16

14 13 13

12

10

8

0

2

4

6

8

10

12

14

16

18

0 1 2 3 4 5 6

Esfu

erz

o(h

ora

s)

Días

Esfuerzos en el Sprint


3.4. Resumen de Esfuerzos Una vez concluidos los Sprints se cuenta con información suficiente para ser consolidada, los

tiempos gastados en cada una de los Sprints permite evidenciar el comportamiento y la eficiencia

de los recursos para llevar a cabo las tareas asignadas. En la siguiente tabla contiene los tiempos

utilizados durante cada sprint, también se puede ver el consolidado de esfuerzo (horas) para

llegar a la primera versión del producto.

ID Descripción Sprint # 1 2 3

1 Configurar entorno de integración 8 3 1

2 Crear versión del ejecutable 2 2 2

3 Revisar comunicación entre dispositivos 36 10 4

4 Configurar servidor central Y Directorio LDAP 58 4 2

5 Revisar Escenarios 4 10 18

Sprint 1 Desarrollo del core del sistema

20 R4-2 Agregar unidad al Sistema 36 0 0

19 R4-1 Consultar unidades del Sistema 10 0 0

17 R3-2 Creación de reglas de acceso 20 5 0

6 R1-1 Usuario con permisos accede (unidad fuera de línea) 10 4 0

7 R1-2 Usuario sin permisos no accede (unidad fuera de línea) 10 4 0

8 R1-3 Unidad Sincroniza información con el servidor central 8 0 2

Sprint 2 Desarrollo de los Eventos de acceso al sistema

15 R2-4 Unidad genera evento (fuera de línea) 0 23 0

12 R2-1 Unidad genera evento al garantizar acceso (fuera de línea) 0 14 0

13 R2-2 Unidad genera evento al denegar acceso (fuera de línea) 0 4 0

9 R1-4 Unidad almacena eventos localmente 0 34 0

14 R2-3 Unidad genera un evento de acceso (en línea) 6 15 0

Release 1 Versión Estable

Esfuerzo versión estable 208 132 29

Sprint 3 Administración del Sistema

22 R4-4 Administración de zonas de acceso 0 0 16

21 R4-3 Administrar Reglas de Acceso 0 0 18

16 R3-1 Edición de una regla de acceso 0 0 12

18 R3-3 Eliminación de una regla de acceso 0 0 4

11 R1-6 Sistema genera evento de alarma (unidad excede tiempo fuera de línea)

0 0 5

10 R1-5 Unidad niega acceso a todos usuarios (unidad excede tiempo fuera de línea) 0 3 2

Release 2 Versión Funcional del Sistema

Esfuerzo backlog completo 208 135 86

Tabla 8 BackLog general del proyecto con Esfuerzos.



3.4.1. Esfuerzo primera versión estable

En la tabla anterior también existe un hito importante en el desarrollo de las actividades, el esfuerzo

requerido para tener una primera versión estable del “producto”, en siguiente figura se puede

observar cómo se cumple la premisa de la metodología ágil que fue seleccionada, la cuela

establece que el esfuerzo necesario para el desarrollo de los componentes decrece con el paso de

cada sprint.

Ilustración 14 Esfuerzo en horas antes de la versión estable.


3.4.2. Esfuerzo total del proyecto

A continuación se puede ver el esfuerzo general que se requirió para poder llevar a cabo la fase de

desarrollo del proyecto. La figura nos indica como a través de las iteraciones de la fase de

desarrollo, los tiempos tienden a estabilizarse y eliminar los sobreesfuerzos que se presentaron

en la primera fase de desarrollo.

208

132

29

0

50

100

150

200

250

1 2 3

Esfu

erz

o (

ho

ras)

Sprint #

Esfuerzo versión Estable


Ilustración 15 Esfuerzo total del proyecto.


3.5. Diagramas de Clases Dentro de la documentación necesaria para entender el desarrollo del prototipo de sistema de

control de acceso se encuentra los diagramas de clase, estos diagramas permiten ver la

implementación lógica de los componentes del software programado a nivel de cada clase

funcional. A continuación se encuentran los diagramas de clases según las capas del sistema.

3.5.1. Capa de Persistencia

Dentro de la capa de persistencia se encuentran todas las clases que representan los datos

almacenados en la Base de datos Mongo DB, estas clases representa la información del sistema

que viaja entre las diferentes capas que componen el proyecto, los diagramas de las clases de

esta capa se presentan a continuación.

208

135

86

0

50

100

150

200

250

1 2 3

Esfu

erz

o (

ho

ras)

Sprint #

Esfuerzo en todo el Backlog


Ilustración 16 Diagrama de clases de la capa de persistencia.


3.5.2. Capa de Servicios

La capa de servicios permite que la capa de persistencia interactúe con las demás capas del sistema,

es el mediador de la información desde y hacia la base de datos, son accesibles desde cualquier

punto de la aplicación lo que permite tener una alta cohesión de las clases encargadas de las

operaciones en la Base de Datos, por esta razón fueron desarrolladas bajo el patrón Singleton el

cual asegura una sola instancia de la clase invocada sea cargada en la máquina virtual java y a su

vez pueda ser invocada desde cualquier punto del sistema, la siguientes figuras demuestran el

diagrama de clases para las clases que conforman la capa de servicio del sistema.


Ilustración 17 Diagrama de clases Capa de Servicios - parte 1.


Ilustración 18 Diagrama de clases Capa de Servicios - parte 2.



3.5.3. Capa de Control

En esta capa se encuentran las clases que controlan la lógica del sistema, por esta razón se

comunican con las clases de la capa de persistencia a través de las operaciones expuestas por la

capa de servicio, las clases que componen esta capa se observan a continuación.

Ilustración 19 Diagrama de clases Capa de Control.


Existe un conjunto de clases que se encuentran en la capa de control cuya función se basas en

proveer varias operaciones de ayuda al sistema propiamente a interactuar con otros sistemas

como lo son el directorio LDAP y el Motor de Bases de Datos, el conjunto de clases está

compuesto por las siguientes clases.


Ilustración 20 Diagrama de clases utilitarias.


3.6. Diseño de Interfaces Dentro del diseño del proyecto se encuentra un apartado de suma importancia, el diseño de las

interfaces con las que los usuarios van a interactuar, en este caso el usuario administrador será el

encargado de administrar los componentes del sistema, a continuación se encuentran los diseños

preliminares de las interfaces con las que el usuario administrador podrá modificar las

asociaciones entre unidades y usuarios, administrar las reglas de acceso, las zonas que

comprenden el sistema y el apartado de consulta de eventos generados.


Ilustración 21 Interfaz de Administración de unidades.


Ilustración 22 Interfaz de administración para las reglas de acceso.



Ilustración 23 Interfaz de consulta de eventos.

Fuente: Los autores

Ilustración 24 Interfaz de administración de las zonas.

Fuente: Los autores


3.7. Diccionario de Datos La tecnología seleccionada para almacenar los datos que conforman el aplicativo fue MongoDB,

debido a que es un motor de base de datos NoSql no existe una arquitectura relacional en los

datos almacenados, estos son almacenados en objetos con formato Json lo que permitió que los

objetos que componen la capa de persistencia en el sistema se puedan almacenar directamente en

la base datos. Un ejemplo de cómo MongoDB almacena un registro en su sistema se presenta a

continuación:

{

“_id” : “4da2c0e2e999fb56bf000002”

“title” : “Publicación sobre los efectos del cambio climatico”,

“body” : “Lorem ipsum dolor sit amet…”,

“ranking” : 108,

“tags” : [“MongoDB”, “NoSQL”, “Bases de datos”],

“published_at” : “2011-05-09T18:17:07-07:00”,

“author_info” : {

“_id” : “4dc8919331c0c00001000002”

“name” : “Carlos Paramio”

},

“liked_by” : [“4d7cf768e999fb67c0000001”, “4da34c62ba875a19d4000001”]

}

En el anterior ejemplo existe un campo identificador “_id” que es único y por defecto es adicionado

a todos los registros almacenados en MongoDB; Como se puede observar en el campo “tags”, un

registro también puede llevar un arreglo de datos, incluso estar compuesto por más objetos de

tipo Json como el caso del campo “author_info” que representa otra estructura, y es almacenada

como parte de una estructura mayor.

A continuación se encuentran los diccionarios de datos de las colecciones utilizadas en MongoDB

para almacenar la información del sistema.

ZoneDTO

Campo Tipo Descripción

zoneId String ID de la zona de acceso

unit_ids Array[String] Lista de los id de las

unidades que conforman la zona


Tabla 9 Diccionario de datos colección ZoneDTO.


UserDTO


userId String ID del usuario en el

directorio LDAP

accessToken AccessToken Valor que identifica

al usuario.

userName String Nombre del usuario

como está registrado en el LDAP

Tabla 10 Diccionario de datos colección UserDTO.


UnitDTO


Id String ID de la unidad de acceso

IP String IP de la unidad

name String Nombre de la unidad en el

sistema

status String estado actual de al unidad

lastCheck long Ultima fecha de

comunicación de la unidad

Tabla 11 Diccionario de datos colección UnitDTO.

Fuente: Los Autores

UnitDTO


Id String ID de la unidad de acceso

IP String IP de la unidad

name String Nombre de la unidad en el

sistema

status String estado actual de la unidad

lastCheck long Ultima fecha de

comunicación de la unidad

Tabla 12 Diccionario de datos colección UnitDTO.



ConfigurationDTO


unitId String ID de la unidad de

acceso

confs Mapa<String,String>

Mapa de datos que contiene el nombre de la propiedad y el

valor de la configuración

Tabla 13 diccionario de datos colección ConfigurationDTO.


AccessRuleDTO


idRule String Identificador de la regla de acceso

unit_ids Array[String] Lista de los id de las unidades que

conforman la zona

zone_ids Array[String] lista de los id de las zonas a las

que aplica la regla.

tokens Array[AccessToken]

Valor que identifica los

tokens habilitados para acceder.

description String Descripción de la regla de acceso

Tabla 14 Diccionario de datos colección AccessRuleDTO.


EventDTO


type String Tipo de evento

time long fecha del evento

unit_id String ID de la unidad de acceso donde ocurrió el evento

user_id String ID del usuario que genero

el evento

description long Descripción adicional del

evento

Tabla 15 Diccionario de datos colección EventDTO.



4. FASE DE IMPLEMENTACIÓN

4.1. Diagrama de Paquetes Dentro de los paquetes que componen el sistema se pueden destacar los paquetes que contienen el

core del sistema y los paquetes que conforman el punto de inicio del sistema, a continuación se

presentan los paquetes que conforman el sistema.

Ilustración 25 Diagrama de paquetes core del sistema.



Ilustración 26 Diagrama de paquetes punto de inicio del sistema.


4.2. Diagramas de Despliegue El diagrama de despliegue identifica los componentes de software necesarios para obtener la

funcionalidad del sistema, y las relaciones de dependencia de dichos componentes.

Ilustración 27 Diagrama de despliegue, componentes de software.



4.3. Esquema Telemático del sistema El sistema al ser distribuido, tiene las características inherentes de los sistemas distribuidos, como

son:

débilmente acoplado: El sistema servidor puede ser instalado en un entorno de software

propietario y el sistema cliente puede ser adaptado a cualquier dispositivo con procesador ARM.

No existe reloj común: el sistema servidor y los dispositivos al funcionar en equipos

independientes no poseen reloj global.

Los elementos de Entrada y Salida están asociados a cada procesador por sistema.

Las fallas en los dispositivos o en la red no provoca una falla en el sistema central, y se puede

crear un sistema de alta disponibilidad del software servidor.

Ilustración 28 Diagrama Telemático del sistema.


Adicionalmente, el sistema exhibe los siguientes componentes de los sistemas distribuidos: En

Comunicación el sistema implementa sokets, y utiliza la arquitectura SOA. En distribución de

nombres, el sistema puede usar DNS, e implementa el directorio LDAP para autenticación de

usuarios. Para el uso de memoria el sistema utiliza el esquema de variables compartidas. Los

Servicios de Sincronización se realizan usando sincronización de relojes por NTP, manejo de

transacciones por mensajes, identificación por certificado SSL y seguridad en comunicaciones

con SSL/TLS. Para los Servicios de Tolerancia a falla se implementó un esquema de replicación


de datos, actualización de las réplicas, autenticación de dispositivos, negación de servicios a

dispositivos o usuarios no autorizados, e implementación de firewall por iptables.

Ya que el sistema se comunica enteramente por TCP/IP, la implementación de la capa SSL muestra

el aspecto de aseguramiento de la comunicación con protocolo seguro que hace parte de la

seguridad en redes y del sistema de gestión de seguridad de la información.

La creación del protocolo de comunicaciones requiere conceptos específicos de teoría de la

información, y su diseño es resultado de la aplicación de las técnicas de la Ingeniería de

software.


5. FASE DE CIERRE

5.1. Pruebas del Sistema Durante cada uno de los Sprints del proyecto se encontraba un segmento de tiempo dedicado a la

revisión de los escenarios propios de las historias de usuario designadas para ser desarrolladas en

un sprint determinado, de encontrarse fallidas, las historias de usuarios eran prolongadas como

tareas en el siguiente Sprint, a continuación se encuentran las pruebas realizadas dentro de cada

Sprint.

5.1 Pruebas Sprint 1

Número de Escenario: R1-1. Resultado de la Prueba

Criterio de Aceptación Usuario con permisos logra

acceder. Fallida

Contexto: Unidad sin conexión de red. Observaciones

Evento:

El usuario procede a realizar

el proceso de acceso usando

el método de identificación


EL usuario logra acceder la primera vez, pero las siguientes ocasiones el sistema le niega el acceso

Funcionamiento

La unidad válida en sus reglas

de acceso local que el usuario

tiene los permisos requeridos

y procede a dar acceso.

Se prolonga el desarrollo al sprint 2.


Criterio de Aceptación Usuario sin permisos no logra

acceder. Fallida


Evento:





EL usuario logra acceder la primera vez, pero las siguientes ocasiones el sistema le niega el acceso

Funcionamiento



no tiene los permisos

requeridos y procede a negar

el acceso.





La unidad sincroniza su

información con el sistema

central.

Fallida

Contexto:

Unidad retoma la conexión

con el sistema central y

vuelve estar en línea.

Observaciones

Evento:

La unidad retoma la conexión

con el sistema central,

procede a sincronizar la

información que guardo de

forma local mientras se


Se presentan errores de comunicación entre las unidades y el servidor

Funcionamiento

El sistema central y la unidad

comparten la misma

información actualizada sobre

los eventos de acceso.



Criterio de Aceptación El sistema guarda el registro

de la regla creada. Fallida

Contexto: El usuario administrador crea

una regla de acceso. Observaciones

Evento:

El usuario administrador

procede a crear una regla de

acceso

El sistema central no sincroniza las nuevas reglas de acceso con las unidades

Funcionamiento

En el momento en que la

unidad esté en línea el

sistema procede a enviar las

nuevas reglas de acceso a la

unidad

Se prolonga el desarrollo al sprint 2



El Usuario Administrador

podrá consultar las unidades

en el sistema.

Exitosa


Contexto:

Usuario con permisos

administra las unidades del

sistema

Observaciones

Evento:

El usuario procede a ingresar

al apartado de la

administración de las

unidades y procede a

consultar las unidades

Funcionamiento

La unidad procede a generar

una vista con las unidades

configuradas y su estado

actual.




podrá agregar una nueva

unidad al sistema.

Exitosa

Contexto:


administra las unidades del

sistema.

Observaciones

Evento:


al apartado de la

administración de las

unidades y procede a

configurar una nueva unidad.

Funcionamiento

La unidad procede a generar

un evento de configuración

inicial informando el estado

de la configuración

5.1.1 Pruebas Sprint 2


Criterio de Aceptación Usuario con permisos logra

acceder. Exitosa


Evento:






Funcionamiento



tiene los permisos requeridos

y procede a dar acceso.


Criterio de Aceptación Usuario sin permisos no logra

acceder. Exitosa


Evento:





Funcionamiento



no tiene los permisos

requeridos y procede a negar

el acceso.


Criterio de Aceptación La unidad se encuentra fuera

de línea. Exitosa

Contexto: La unidad pierde conexión

con el sistema central Observaciones

Evento:

La unidad identifica que se

encuentra sin conexión al

sistema central y procede a

registrar de forma local

eventos de acceso.

Funcionamiento

La unidad entra a funcionar

en el modo fuera de línea,

utiliza su base de datos local

para registrar los eventos




La unidad genera un evento

cuando se garantiza el acceso

al usuario que lo solicita

Exitosa

Contexto: Usuario con permisos solicita

acceso. Observaciones

Evento: El usuario procede a realizar

el proceso de acceso.

Funcionamiento

La unidad valida que el

usuario tenga permiso de

acceso con sus reglas de

acceso locales, guarda el

registro localmente.



La unidad genera un evento

cuando se niega el acceso al

usuario que lo solicita.

Fallida

Contexto: Usuario sin permisos solicita

acceso Observaciones

Evento: El usuario procede a realizar

el proceso de ingreso.

La unidad genera el evento pero no almacena de forma local.

Funcionamiento

La unidad valida que el

usuario tenga permiso de

acceso con sus reglas de

acceso locales, guarda el

registro localmente.


Criterio de Aceptación La unidad genera un evento

de acceso. Fallida

Contexto: Unidad en línea con el

sistema central. Observaciones


Evento:

La unidad otorga o niega el

acceso a un usuario y genera

un evento de acceso que se

envía al sistema central para

que sea persistido.

Por problemas de comunicación la unidad no sincronía la información con la unidad

Funcionamiento

La unidad envía la

información del evento al

sistema central quien

almacenará la información

del evento generado.

El problema de comunicación se aborda en el sprint 3


Criterio de Aceptación La unidad genera un evento

de acceso. Exitosa

Contexto: Unidad en fuera de línea con

el sistema central. Observaciones

Evento:

La unidad pierde la conexión

con el sistema central, a su

vez se genera un evento

cuando otorga o niega el

acceso a un usuario.

Funcionamiento

La unidad guarda la

información en su base de

datos loca, una vez vuelva a

estar en línea con el sistema

envía la información de los

eventos generados durante el

tiempo en que se encontró

fuera de línea al sistema

central ,quien almacenará la

información del evento

generado.

5.1.2 Pruebas Sprint 3



La unidad sincroniza su

información con el sistema

central.

Exitosa

Contexto:

Unidad retoma la conexión

con el sistema central y

vuelve estar en línea.

Observaciones


Evento:

La unidad retoma la conexión

con el sistema central,

procede a sincronizar la

información que guardo de

forma local mientras se


Funcionamiento

El sistema central y la unidad

comparten la misma

información actualizada sobre

los eventos de acceso.

Número de Escenario: R1-5 Resultado de la Prueba

Criterio de Aceptación La unidad procede a denegar

el acceso a todos los usuarios. Exitosa

Contexto:

La unidad excede el tiempo

máximo que puede estar fuera

de línea.

Observaciones

Evento:

La unidad supera el tiempo

máximo establecido para

funcionar fuera de línea,

procede a entrar en modo

“suspendido” donde solo le

permite acceso a los usuarios

que se encuentren cobijados

bajo la regla de acceso que

permite el acceso a todas las

zonas del sistema.

Funcionamiento

La unidad no permitirá el

acceso a ningún usuario que

se encuentre por fuera de la

regla de acceso a todas las

zonas del sistema hasta que se

encuentre de nuevo en línea.



El sistema central informa

que una unidad ha superado

el tiempo máximo en que

puede encontrarse fuera de

línea

Exitosa


Contexto:

La unidad excede el tiempo

máximo en que puede estar

fuera de línea.

Observaciones

Evento:

La unidad supera el tiempo

máximo establecido para

funcionar fuera de línea, el

sistema central procede a

generar un evento indicando

la situación actual de la

unidad.

Funcionamiento

El sistema cuenta con el

registro de la falla en la

conexión con la unidad


Criterio de Aceptación El sistema guarda el registro

del cambio realizado. Exitosa

Contexto: El usuario administrador

modifica una regla de acceso. Observaciones

Evento:


procede a realizar un cambio

en una regla de acceso.

Funcionamiento




reglas actualizadas de acceso

a la unidad


Criterio de Aceptación El sistema elimina la regla y

guarda el registro. Fallida

Contexto: El usuario administrador

elimina una regla de acceso. Observaciones

Evento:


procede a eliminar una regla

de acceso.

El sistema no elimina la regla de la base de datos


Funcionamiento




reglas actualizadas de acceso

a la unidad.

Se procede con el ajuste de la funcionalidad en los dos últimos días del sprint




podrá administrar las reglas

de acceso

Exitosa

Contexto:


administra las reglas de

acceso.

Observaciones

Evento:


al apartado de la

administración de las reglas

de acceso, consulta, crea,

modifica o elimina una regla

de acceso.

Funcionamiento

El sistema realiza la consulta,

creación, modificación o

eliminación de la regla de

acceso informando de los

cambios a las unidades

afectadas.




podrá Administrar las zonas

de acceso.

Fallida

Contexto:


administra las zonas de

acceso

Observaciones

Evento:


al apartado de la

administración de las zonas

de acceso y consulta, crea,

modifica o elimina las zonas

de acceso.

Se presenta error cuando la unidad esta tiene otra regla de acceso que entra en conflicto con las zonas del sistema, el error se corrige en el 4 día del sprint.


Funcionamiento

El sistema realiza la consulta,

creación, modificación o

eliminación de la zona de

acceso informando de los

cambios a las unidades

afectadas.

Se procede a ajustar la lógica de la unidad para que las reglas que denieguen acceso tengan precedencia sobre las demás reglas.

5.2. Cierre del proyecto Para el cierre del proyecto los integrantes del grupo se reunieron y definieron los aciertos y fallas

durante el desarrollo del proyecto. Se evaluaron los tiempos requeridos en los esfuerzos para el

desarrollo del producto versus el esfuerzo re querido para solucionar los imperfectos dentro de

cada uno de los Sprints la siguiente tabla contiene el compilado de los datos obtenidos.

sprint Errores Esfuerzo para solucionar

errores (Horas) Esfuerzo Total

(Horas) % Esfuerzo para

solucionar errores

1 12 60 208 29

2 6 28 135 21

3 2 13 86 15 Tabla 16 Tiempo desarrollo Vs Errores de desarrollo.


Se puede ver como el primer Sprint requirió de un mayor esfuerzo en la resolución de los errores

que se presentaron durante ese tiempo, esto responde al sobreesfuerzo que se presentó al inicio

del proyecto. En los siguientes Sprints el esfuerzo requerido para solucionar los imperfectos

decreció, lo que indica que se pudieron sobreponer las falencias iniciales en cuanto a carga y

esfuerzos requeridos para el desarrollo del producto.

La siguiente Figura presenta un gráfico del esfuerzo total medido en horas, requerido para el

desarrollo del proyecto versus el tiempo requerido para solucionar los errores de desarrollo que

se presentaban a medida que pasaba el tiempo.


Ilustración 29 Esfuerzo Total Vs Esfuerzo en la resolución de los errores

Fuente: Los Autores.

Dentro del análisis las fallas en la construcción del producto se encuentran:

Falta de comunicación de los integrantes del grupo en cuanto a las tareas de desarrollo.

Deficiente planeación y estimación de tiempos para el primer sprint del proyecto.

Sobreesfuerzos en los tiempos de desarrollo durante el primer sprint.

Errores en la integración de los objetos compilados.

A continuación los principales aciertos del proyecto:

Selecciona adecuada de la tecnología que permitió no tener errores relacionados al uso de

las tecnologías seleccionadas para el desarrollo.

Selección adecuada de la arquitectura del producto que permitió no tener problemas

derivados de la definición arquitectura.

60

28

13

208

135

86

0 50 100 150 200 250

1

2

3

Esfuerzo (Horas)

Spri

nts

Esfuerzo Total Vs Esfuerzo por Errores

Esfuerzo Total (Horas) Esfuerzo para solucionar errores (Horas)


Fácil adaptación a los cambios consecuencia de los errores y el sobreesfuerzo del primer

sprint.

5.3. Mejoras propuestas Se entiende que el proyecto pretende ser un ejemplo de la viabilidad de construir un sistema de

control de acceso apoyado en las tecnologías libres que se encentran en el mercado, es por esto

que dentro del desarrollo del producto se identificaron algunas características que aportarían un

gran valor al producto, y sería pertinente que en un futuro se contara con una versión que las

incluya, algunas de ellas son:

El usuario pueda identificarse con una forma alterna a la forma de identificación con que

cuenta el sistema de forma predefinida.

El sistema Envíe notificaciones de accesos prohibidos a los administradores del sistema.

Generación de Reportes de las estadísticas de cada una de las unidades.

El sistema permita hacer búsquedas de eventos por tipo y periodo de tiempo.

Las unidades de acceso puedan ser administradas de forma remota.

El sistema pueda funcionar en clúster.

Cuando por alguna razón el servidor esta fuera de línea, cualquier unidad del sistema esté

en la capacidad de asumir los servicios que el servidor central presta a todo el sistema.

Cuando exista un alto volumen de información que llega el servidor y que congestione la

red, cualquier unidad del sistema esté en la capacidad de asumir los servicios que el

servidor central presta a todo el sistema mientras se libera la congestión en el tráfico de

datos.


Conclusiones

El análisis y diseño son la parte más importante del desarrollo de software, puesto que al hacer una

plantificación detallada se reducen los tiempos de desarrollo y teniendo clara la arquitectura

permite organizar y distribuir mejor los componentes relacionados, de forma tal que el sistema

puede crecer fácilmente sin perderse el control sobre cada componente, así mismo al reconocer

claramente las funcionalidades comunes se reduce la redundancia de código.

La documentación del código es esencial para poder entender y recordar las funcionalidades de cada

clase, así como su utilidad y dominio sobre el negocio, permitiendo encontrar y corregir

fácilmente los errores.

La estandarización de los nombres de las clases y las tablas reduce la complejidad del sistema al

reunirlas por funcionalidades permitiendo una administración más sencilla.

El uso de archivos de configuración permite hacer modificaciones en las funcionalidades del

sistema de forma tal que se puede cambiar el comportamiento de la aplicación rápidamente,

también añaden características dinámicas extra.

Es importante mantener limpia la memoria usada, removiendo los objetos innecesarios, esto

aumenta el desempeño de la aplicación y es fundamental en entornos embebidos.

Para una funcionalidad especializada es preferible tomar tiempo para buscar una implementación ya

existente, y no emprender un desarrollo ya que el uso de bibliotecas dinámicas reduce

considerablemente el tiempo de desarrollo.

La implementación de la capa SSL minimiza los riesgos inherentes a la transmisión de datos.

Durante el proyecto se presentaron falencias en la definición de tiempos y esfuerzos para construir

el software a base de los requerimientos identificados, en la fase de cierre del proyecto se puede

observar como la mala planeación del primer Sprint represento una sobreesfuerzo en tiempo, una

mayor cantidad de errores y un tiempo mayor para la resolución de dichos errores a diferencia de

los Sprints subsiguientes.

La metodología Scrum permitió evidenciar las falencias y corregirlas de forma oportuna durante la

fase de desarrollo del producto, a su vez a medida que pasaban los Sprints, equilibrar las cargas

de trabajo y esfuerzos requeridos por cada recurso para llevar a cabo las tareas planeadas.


El enfoque de “servicio” que se le dio a la forma de funcionar de cada una de las unidades que

conforman el sistema permitió que el sistema en si sea escalable en hardware, ya que es

adaptarlo a el número de las unidades requeridas para el funcionamiento del sistema.

El uso de motores de bases de datos NoSql permite una gran adaptabilidad a los cambios que surgen

en el transcurso de la construcción del software como de los posibles cambios en los

requerimientos iniciales; A diferencia de las bases relacionales donde los cambios en las

estructuras de persistencia conllevan a mayores tiempos en la adaptación funcional por parte de

los componentes desarrollados.

Las tecnologías libres que se encuentran en el mercado actual como el Raspberry Pi, tienen un gran

potencial para ser usadas como puntos de integración entre diversas tecnologías más robustas

como los lenguajes de programación, motores de Bases de datos y aplicaciones web.


Recomendaciones

Ya que el sistema es distribuido y no tiene reloj global, se recomienda implementar servicios NTP y

configurar los diversos sistemas con dicho protocolo.

Se recomienda implementar SNMP y SYSLOG para la revisión extra de los dispositivos y el

servidor en redes locales, una de las herramientas libres disponibles que permiten dicha

integración es NAGIOS.

Para redes WAN o esquemas Cloud se recomienda la creación de CRON para la realización de

tareas de mantenimiento como son: limpieza de registro de log, reinicio programado de

procesos, actualización automática, etc.

Se recomienda el uso de logrotate, realizar labores de hardering sobre los servicios asociados al

sistema y la revisión periódica de las políticas de firewall local de cada dispositivo.

Si el sistema servidor se publica en internet, se recomienda el uso de IPS, IDS y registro de eventos

de seguridad con equipos especializados.


Bibliografía

CRAIG, Larman. UML y patrones. Introducción al análisis y diseño orientado a objetos 2a edición,

2003.

FALKNER, Jayson y JONES, Kevin. Servlets and JavaServer Pages™: The J2EE™ Technology

Web Tier. Addison Wesley, 2003.

KURNIAWAN, Budi. Java for the Web with Servlets, JSP, and EJB: A Developer's Guide to J2EE

Solutions. New Riders Publishing, 2004.

MARCHAL, Benoit, XML con ejemplos. Pearson Education. Mexico. 2001.

PRESSMAN, Roger S. Ingeniería del software. Un enfoque práctico MacGraw Hill, 2005 6ta

Edición.

WEITZENFELD, Alfredo. Ingeniería de Software orientada a objetos con UML, JAVA e

INTERNET. México: Thomson, 2005.


PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO

DISTRIBUIDO CON TECNOLOGIAS LIBRES

Javier Alfonso. Alvaro Ronderos

Ingeniería en Telemática, Universidad Distrital Francisco José de Caldas,

[email protected]

[email protected]

Abril de 2015, Bogotá, Colombia

Resumen

- Este documento provee una vista general de los

aspectos técnicos de la propuesta de grado

PROTOTIPO DE SISTEMA DE CONTROL DE

ACCESO DISTRIBUIDO CON TECNOLOGIAS

LIBRES. Este proyecto busca aprovechar las

ventajas de las tecnologías libres para desarrollar un

prototipo de sistema distribuido que permita el

control de acceso en las organizaciones de tal forma

que pueda adaptarse a diferentes contextos de

seguridad; Sea escalable y económico de

implementar.

Palabras claves- control de Acceso, desarrollo de

software libre, la tecnología Java, los sistemas

distribuidos, la seguridad física de las organizaciones

y las Bases de datos.

1. INTRODUCCIÓN

La seguridad de los activos es uno de los ítems más

importantes dentro de los planes de seguridad

implantados por cada organización, en la actualidad las

empresas y organizaciones comúnmente delegan la

función de seguridad en terceros, generalmente una

empresa de seguridad privada, estas empresas de

seguridad se encargan de salvaguardar las instalaciones

de las organizaciones y en algunos casos un cierto

control en el acceso a las instalaciones por parte de

extraños. sin embargo el nivel de acceso privilegiado

sobre ciertas áreas, recursos o activos de la empresa es

tratado de forma trivial en muchos casos y en otros hace

parte del plan general de la organización enfocado a la

seguridad de los activos de información con que cuenta

la empresa, la forma de control es mediante sistemas

como el RFID (Radio Frequency IDentification, en

español identificación por radiofrecuencia) que es un

sistema de almacenamiento y recuperación de datos

remoto que usa dispositivos denominados etiquetas,

tarjetas, transpondedores o tags RFID. El propósito

fundamental de la tecnología RFID es transmitir la

identidad de un objeto (similar a un número de serie

único) mediante ondas de radio. Las tecnologías RFID

se agrupan dentro de las denominadas Auto ID

(automatic identification, o identificación automática).

Esta clase de tecnología permite garantizar el acceso, sin

embargo no garantiza la identidad de quien accede, lo

que representa una gran falencia, en el otro extremo se

tienen los sistemas de control de acceso, con lectores

biométricos, que cuyos esquemas de seguridad permiten

controlar que a determinadas áreas de la organización

solo ingresen las personas autorizadas. En estos sistemas

de control de acceso se usa la huella digital, u otra

cualidad diferencial, a manera de llave o pase de entrada

por lo cual es plenamente identificable la identidad de

las persona que intenta obtener acceso.

Los sistemas de identificación biométrica son

esencialmente software que corre sobre un equipo que

permite la identificación inequívoca de personas,


previamente registradas por otra parte del sistema en una

base de datos. Estas características físicas individuales

no pueden ser falsificadas fácilmente. Habitualmente

estas lecturas biométricas se basan en las características

de las huellas digitales o cualquier otro identificador

biométrico.

Para proveer movilidad al sistema de identificación de

forma que permita ser transportado e instalado

fácilmente, este debe cumplir con ciertas características

como: ser liviano, permitir conectarse por diversos

medios, poseer respaldo de datos externo, permitir

guardar registros de transacciones, sincronizar las

transacciones cuando se encuentre de nuevo en línea,

permitir adicionar nuevo hardware de control, y las

demás características de un sistema distribuido.

2. DESCRIPCIÓN DEL PROBLEMA

Las empresas se ven abocadas en la actualidad a

proteger activos de gran valor para sus organizaciones,

los controles establecidos para salvaguardar dichos

activos no suelen ser muy efectivos ya que en gran parte

se ven limitados por los proveedores de soluciones de

seguridad, quienes en muchos casos no cuentan con

productos adaptables a la necesidad de cada cliente, o en

otros casos son muy costosas para ser implementadas, lo

que limita a las empresas para establecer un esquema de

seguridad adecuado y a su vez contribuye a que no

puedan tener controles adecuados eficientes que se

traduce en pérdidas de activos, como perdidas de

información o fugas de información.

Las soluciones que ofrecen los proveedores de

tecnología del área de la seguridad presentan costos

elevados para ser implementadas porque dependen de

una inversión económica para la adecuación de la

infraestructura física, contratos de servicio por periodos

de tiempo prefijados, cobros asociados a licencias de

tecnologías propietarias con periodos de expiración y

costos ocultos en la actualización de los esquemas de

seguridad como lo menciona John LaFond en su

artículo ‘Counting Up the Hidden Costs of Security

Licensing’:

“Al ampliar o actualizar los sistemas, todos los clientes

son susceptibles a una amplia gama de honorarios por

licencia (además de cualquier costo laboral o de

hardware) que puede aumentar significativamente la

cantidad que usted está pagando por las mejoras o

actualizaciones de tecnología que su empresa quiere y

necesita. Los costos ocultos pueden provenir de tarifas

de servicios cloud, cliente o cobros de licencias de base

de datos, comisiones por licencias de hardware, o

cualquier combinación de éstos. Esto significa que

cualquier momento que desee ampliar el número de

puntos de acceso, implementar la integración de vídeo

o tal vez actualizar su sistema con control de acceso al

ascensor, le podría costar en múltiples niveles.” [1]

Los controles de seguridad que se ofrecen en la

actualidad presentan problemas para las organizaciones

debido a que no siempre es posible de adaptar la

solución tecnológica a las necesidades de cada

organización, la mayoría de soluciones no están

enfocadas en las normas de calidad sino en el control de

acceso a áreas y presentan dificultades en la

escalabilidad del sistema a medida que la organización

crece o cambia.

“La seguridad física para diferentes ubicaciones puede

requerir variaciones en la implantación de las medidas

que permitan que se adapten a las peculiaridades de

cada sede o infraestructura. Por ello, niveles de

protección deseables pueden variar dentro de una

misma organización. Es recomendable implantar un

sistema de gestión maduro, que evite redundancias en

contratos y servicios, y que, por otra parte, no deje

ningún activo sin salvaguardar, adaptándose a las

necesidades específicas de cada lugar y los cambios de

las amenazas en el tiempo.” [2]

2.1 Formulación del problema


¿Cómo construir una solución tecnológica que sea una

alternativa a las soluciones actuales del mercado, que

sea económica, confiable y adaptable a las empresas

interesadas en proteger la integridad y confidencialidad

de sus activos por medio de control de acceso?

3. OBJETIVOS

En la propuesta de grados se pretende cumplir los

siguientes objetivos:

3.1. Objetivo General:

Desarrollar un prototipo de sistema de control de acceso

distribuido de software libre, adaptable y de bajo costo

de implementación.

3.2 Objetivos Específicos

Analizar los requerimientos para el desarrollo

del sistema de control de acceso.

Diseñar una solución tecnológica que cumpla

con los requerimientos identificados.

Desarrollar un prototipo de solución tecnológica

para el control del acceso que permita ser usada

con propósito general, que sea adaptable a

diferentes contextos dentro de las

organizaciones, permita la escalabilidad y

adaptación a diversos componentes de hardware

como lectores biométricos, teclados numéricos,

tarjetas RFID o etiquetas NFC.

Implementar una solución Tecnológica que no

tenga costos asociados al licenciamiento de las

tecnologías utilizadas.

Probar el prototipo en la empresa A & G

Tecnología para comprobar que el sistema

desarrollado cumple con los objetivos

planteados.

4. MARCO TEORICO

Los siguientes son las técnicas y tecnologías escogidas

para el desarrollo del proyecto, teniendo en cuenta que

son software libre y patrones de diseño disponibles para

su uso.

4.1. Arquitectura MVC (Modelo vista Controlador).

Fue descrita por primera vez en 1979 en el documento

“Applications Programming in Smalltalk-80(TM):

How to use Model-View-Controller (MVC)” [3].

Dirigido al lenguaje de programación Smalltalk. Usada

como el patrón clásico para aplicaciones donde el

usuario interactúa constantemente con el sistema, “La

arquitectura de diseño MVC (iniciales en inglés de

“Model View Controller” o “Modelo Vista

Controlador”) provee un mecanismo que posibilita

separar los datos (el modelo) de la forma en que estos

serán visualizados (la vista) Usando un puente entre

los dos (El controlador)”[4], lo anterior se puede

observar en la figura 1.

Figura 1: Arquitectura MVC.

4.2 Arquitectura de un sistema distribuido bajo el

patrón MVC:

En la figura 2 Se marca la disposición común con el cual

se desarrolla un sistema distribuido bajo la arquitectura o

patrón MVC, se muestra la forma en que interactúan las

tres capas de información, se debe denotar que el usuario

del sistema no debe tener acceso a la capa del Modelo

(donde están los datos) por seguridad y dado que así lo


dispone el patrón de diseño, el usuario solo debe

interactuar con la capa de vista o presentación a través

del Controlador y es este último quien se comunica con

todas las capas que componen la aplicación distribuida.

Figura 2: Arquitectura de un Sistema distribuido Bajo el

patrón MVC.

4.3 Raspberry Pi.

El Raspberry Pi (Figura 3) es un ordenador del tamaño

de una tarjeta de crédito, de bajo costo, se conecta a un

monitor de ordenador o un televisor, y utiliza un teclado

y un ratón estándar. Es un dispositivo poco capaz que

permite a las personas de todas las edades para explorar

la computación, y para aprender a programar en

lenguajes como Python, C++, o incluso Java. Es capaz

de hacer todo lo que espera un ordenador de sobremesa

que hacer, desde navegar por Internet y reproducción de

vídeo de alta definición, con la toma de hojas de cálculo,

procesador de textos, y jugar juegos. Lo que es más, el

Raspberry Pi tiene la capacidad de interactuar con el

mundo exterior, y se ha utilizado en una amplia gama de

proyectos fabricante digitales, como máquinas de

música, detectores de padres, estaciones meteorológicas

y twitteando casas de aves con cámaras infrarrojas.

La fundación Raspberry Pi espera masificar el uso del

Raspberry Pi como componente académico en todo el

mundo para aprender a programar y entender cómo

funcionan los ordenadores [5].

Figura 3: Componentes de un Raspberry Pi

4.4. Metodología Scrum

Como lo menciona Juan Palacios en el documento “El

Modelo Scrum”[6], Scrum es una metodología de

desarrollo muy simple, que requiere trabajo duro porque

no se basa en el seguimiento de un plan, sino en la

adaptación continua a las circunstancias de la evolución

del proyecto.

Scrum es una metodología ágil, y como tal:

Es un modo de desarrollo de carácter

adaptable más que predictivo.

Orientado a las personas más que a los procesos.

Emplea la estructura de desarrollo ágil:

incremental basada en iteraciones y


revisiones.

Se comienza con la visión general del producto,

especificando y dando detalle a las funcionalidades o

partes que tienen mayor prioridad de desarrollo y que

pueden llevarse a cabo en un periodo de tiempo breve

(normalmente de 30 días).

Cada uno de estos periodos de desarrollo es una

iteración que finaliza con la producción de un

incremento operativo del producto.

Estas iteraciones son la base del desarrollo ágil, y Scrum

gestiona su evolución a través de reuniones breves

diarias en las que todo el equipo revisa el trabajo

realizado el día anterior y el previsto para el día

siguiente como lo muestra la figura 4.

Figura 4: Flujo de trabajo en Scrum

5. PERSPECTIVAS:

Se pretende hacer el uso de las tecnologías libres para

construir un prototipo de sistema distribuido para el

control de acceso que en el futuro se pueda volver un

sistema mucho más robusto, cuyo costo de

implementación sea menor al que actualmente ofrecen

las demás soluciones tecnológicas que están en el

mercado colombiano.

Se propone aplicar los principios del desarrollo ágil en

proyectos bajo la metodología de Scrum.

Se proyecta tener un sistema que use elementos de

hardware y software libre, escalable y adaptable a

nuevas tecnologías de carácter libre.

6.CONCLUSIONES

Los avances en tecnologías libres de software y

hardware como el Raspberry Pi proveen una plataforma

robusta para el desarrollo de aplicaciones de interacción

con los humanos, debido a que poseen la potencia básica

de un ordenador de escritorio bajo una arquitectura

adaptable a sistemas embebidos.

Los Sistemas distribuidos son el presente de la

computación, siendo a la par de la computación en la

nube, las bases para los desarrollos de los sistemas

ubicuos que interactúan con los seres humanos.

La metodología Scrum es aplicable a diversos proyectos

de tecnología no solo de software por su enfoque de

actividades y adaptabilidad al cambio constante en los

requerimientos.

REFERENCIAS

[1] LaFond, John. Counting Up the Hidden Costs of

Security Licensing. Publicado en Security Magazine.

Junio 10 de 2014. [En línea]. [Consulta: 08 de febrero

de 2015] Disponible en:

http://www.securitymagazine.com/articles/85588-

counting-up-the-hidden-costs-of-security-licensing

[2] Rego, Miguel. La eficiencia y la eficacia en la

Seguridad Patrimonial. [En línea]. [Consulta: 22 de

febrero de 2015] Disponible en


http://www.redseguridad.com/opinion/articulos/la-

eficiencia-y-la-eficacia-en-la-seguridad-patrimonial

[3] Burbeck, Steve. Applications Programming in

Smalltalk-80(TM):

How to use Model-View-Controller (MVC) [en línea]

[consulta: 08 de noviembre de 2014]. Disponible en:

http://st-www.cs.illinois.edu/users/smarch/st-

docs/mvc.html

[4] Sznajdleder, Pablo. Java a fondo: estudio del

lenguaje y desarrollo de aplicaciones 1ª ed. Buenos

Aires, Alfaomega, 2010,528p.

[5] WHAT IS A RASPBERRY PI? [En línea]

[Consulta: 08 de febrero de 2014]. Disponible en:

https://www.raspberrypi.org/help/what-is-a-raspberry-pi/

[6] Palacios, Juan. El Modelo Scrum. [En línea]

[Consulta. 10 de marzo de 2015]. Disponible en

http://www.navegapolis.net/files/s/NST-010_01.pdf

Sobre los Autores

Javier Ricardo Alfonso Alba.

Es Tecnólogo grado I en la Contraloría

General de la República, Culmino sus

estudios de Ingeniería en telemática y es

Tecnólogo en Sistematización de datos de

la Universidad Distrital. Interesado en las redes,

sistemas distribuidos y seguridad de la información.

e-mail: [email protected]

Alvaro Iván Ronderos Acevedo,.

Es Ingeniero de Desarrollo en Grupo Dot

S.A.S, Culmino sus estudios de Ingeniería

en telemática y es Tecnólogo en

Sistematización de datos de la Universidad

Distrital. Interesado en la programación de portales web,

la gerencia y administración de proyectos informáticos.

e-mail: [email protected]


MANUAL DE USUARIO DEL PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO

DISTRIBUIDO CON TECNOLOGIAS LIBRES


Álvaro Iván Ronderos Acevedo




Bogotá 2016


Contenido 1. Introducción .............................................................................................................................................. 1

2. INSTALACION DEL SISTEMA ...................................................................................................................... 1

2.1. Requerimientos de Hardware ............................................................................................................ 1

2.2 Requerimientos de Software .............................................................................................................. 1

3. OPERACIÓN DE LA APLICACIÓN ................................................................................................................ 2

4. PÁGINA HOME .......................................................................................................................................... 2

4.1 Componentes de la página ................................................................................................................. 3

5. PÁGINA UNIDADES .................................................................................................................................... 4

5.1 Componentes de la página ................................................................................................................. 4

5.2 Acciones sobre la página. .................................................................................................................... 5

5.2.1 Seleccionar una unidad. ............................................................................................................... 5

5.2.2 Agregar una unidad a una zona. .................................................................................................. 6

5.2.3 Quitar una unidad de una zona.................................................................................................... 7

5.2.4 Agregar una nueva unidad. .......................................................................................................... 9

6. PÁGINA USUARIOS .................................................................................................................................. 10

6.1 Componentes de la página ............................................................................................................... 11

6.2 Acciones sobre la página. .................................................................................................................. 12

6.2.1 Agregar usuario a un grupo. ...................................................................................................... 12

6.2.2 Quitar usuario de un grupo. ....................................................................................................... 13

7. PÁGINA REGLAS DE ACCESO ................................................................................................................... 15

7.1 Componentes de la página ............................................................................................................... 17


7.2.1 Agregar grupo a la regla ............................................................................................................. 18

7.2.2 Quitar grupo de la regla. ............................................................................................................ 19

7.2.3. Agregar usuario a la regla. ........................................................................................................ 21

7.2.4 Quitar usuario de la regla........................................................................................................... 22

7.2.5 Agregar zona a la regla ............................................................................................................... 24

7.2.6 Quitar zona de la regla ............................................................................................................... 25

7.2.7 Agregar unidad a la regla ........................................................................................................... 27

7.2.8 Quitar unidad de la regla ........................................................................................................... 28

7.2.9 Agregar una nueva regla de acceso ........................................................................................... 30


8. PÁGINA EVENTOS .................................................................................................................................... 31

8.1 Componentes de la página. .............................................................................................................. 32


8.2.1 Buscar por fechas ....................................................................................................................... 33

8.2.2 Buscar por usuario ..................................................................................................................... 34

8.2.3 Buscar por unidad ...................................................................................................................... 34


1

1. Introducción

El prototipo de sistema de control de acceso con tecnologías libres, es un aplicativo informático

diseñado como alternativa libre para los sistemas de control de acceso. Este sistema está enfocado en la

utilización de tecnologías libres como un medio para la construcción de un prototipo de sistema de

control de acceso.

El prototipo consta de un aplicativo servidor con interfaz gráfica el cual permite al administrador del

sistema administrar los componentes del sistema: Usuarios, Unidades, Reglas de Acceso, Grupo de

Usuarios y Zonas. Este manual de usuario pretende guiar al usuario administrador sobre las diferentes

interfaces graficas que componen el sistema.

2. INSTALACION DEL SISTEMA

2.1. Requerimientos de Hardware

Para la Instalación del Sistema se requiere un computador de escritorio con las siguientes características

o superiores:

Procesador de 2.3 Ghz.

Disco duro de 80 GB.

Memoria RAM de 2048 MB.

Periféricos estándar (Mouse, Teclado, Pantalla).

2.2 Requerimientos de Software

El equipo Servidor requiere:

Conexión a Lan

Motor de bases de datos MongoDB 3.0 o superior.

JRE (java Runtime Environment) 6 o superior.

Navegador de Internet con soporte de Html 5


1

3. OPERACIÓN DE LA APLICACIÓN

Una vez el servidor este ejecutándose, se debe ingresar desde un equipo que se encuentre en la misma

red local y a través de un navegador web en a la dirección y puerto de la maquina donde se está

ejecutando el servidor, para este documento se asume que el servidor está ejecutándose en la maquina

local sobre el puerto 4567, por lo que será accesible desde la url 127.0.0.1:4567 o la url localhost:4567.

4. PÁGINA HOME

La página home es un medio para conocer el estado actual de las unidades que componen el sistema, al

ingresar se podrá ver una tabla con los campos Unidad, Último Reporte y Estado

Al ingresar a la página localhost:4567/home se podrá observar la siguiente interfaz gráfica:

Imagen 1 Página Home del aplicativo.


1

4.1 Componentes de la página

Columna Unidad: En esta columna se encuentran los nombres de las unidades que componen el

sistema.

Columna Último Reporte: En esta columna se encuentra la fecha y hora en que la unidad se ha

reportado como activa en el servidor.

Columna Status: En esta columna se puede observar el estatus de la unidad.


1

5. PÁGINA UNIDADES

La página unidades permite gestionar las unidades que componen el sistema y que se encuentran

asociadas a zonas definidas por el usuario, cada zona se compone de varias unidades y a su vez una

unidad pueda pertenecer a una o más zonas.

Al ingresar a la página localhost:4567/units se podrá observar la siguiente interfaz gráfica:

Imagen 2 Página Units del aplicativo.


COMPONENTE NOMBRE DESCRIPCION

Lista de unidades

Permite observar la lista de unidades que

componen el sistema


1

Lista de Zonas

Activas para la

Unidad

Permite ver las zonas a las que pertenece

una unidad seleccionada

Zonas disponibles

para la Unidad

Permite ver las zonas disponibles a las cuales

puede ser vinculada una unidad

Vinculo para

agregar una nueva

Unidad

Vinculo para agregar una nueva unidad.

Vinculo para

agregar una nueva

Zona

Vinculo para agregar una nueva zona al

sistema

Botón Agregar Botón que permite agregar el elemento

seleccionado a la lista correspondiente.

Botón Quitar Botón que permite quitar el elemento

seleccionado de la lista correspondiente.

Tabla 17 Componentes página Units.

5.2 Acciones sobre la página.

5.2.1 Seleccionar una unidad.

Cuando se selecciona una unidad de la lista se podrá ver los datos de esta, a su vez se mostraran las

zonas a las que pertenece y las posibles zonas a la que la unidad podrá ser vinculada.


1

Imagen 3 Seleccionar Unidad.

5.2.2 Agregar una unidad a una zona.

Para agregar una unidad a una zona ya existente se debe seleccionar la zona en la lista correspondiente

y a continuación se debe hacer clic en el botón agregar, a continuación la lista de zonas se verá

actualizada como lo muestra la siguiente imagen:


1

Imagen 4 Agregar una zona a una unidad.

5.2.3 Quitar una unidad de una zona.

Para proceder a quitar una unidad de una zona se debe seleccionar la zona de la lista de zonas para la

unidad y a continuación se debe dar clic en el botón quitar a continuación se ilustra el proceso de quitar

una unidad una zona existente:


1

Imagen 5 Quitar unidad de una zona (seleccionar zona).

Imagen 6 Quitar unidad de una zona (Zonas actualizadas)


1

5.2.4 Agregar una nueva unidad.

Para Agregar una nueva unidad al sistema se debe hacer clic en el vínculo correspondiente, luego se

debe diligenciar los datos Nombre y dirección IP, la dirección IP debe ser la misma que tenga asignada la

unidad en la red LAN.

Imagen 7 Crear una nueva unidad.


1

Imagen 8 Lista de unidades actualizadas.

6. PÁGINA USUARIOS

La página usuarios permite administrar los usuarios que componen el sistema y como estos se

relacionan con los grupos creados por el administrador del sistema, un grupo es una forma de agrupar a

unos usuarios de tal manera que facilite su administración frente a las reglas de acceso que cada unidad

del sistema va a tener.

Al ingresar a la página localhost:4567/users se podrá observar la siguiente interfaz gráfica:


1

Imagen 9 Página usuarios del aplicativo.



Lista de Usuarios

Permite observar la lista de Usuarios que

componen el sistema

Lista de Grupos

Activos para el

Usuario

Permite ver los grupos a los que pertenece

una usuario seleccionado

Grupos disponibles

para la Usuario

Permite ver los Grupos disponibles a los

cuales puede ser vinculado un Usuario

Lista de reglas que

afectan al usuario

seleccionado

Permite ver que reglas están afectando a un

usuario seleccionado


1

Agregar Grupo Permite agregar un nuevo grupo al sistema





Tabla 18 Componentes página Users.


6.2.1 Agregar usuario a un grupo.

Para proceder a agregar un usuario a un grupo ya existente se debe primero seleccionar el usuario, a

continuación se debe seleccionar el grupo al cual va a pertenecer el usuario de la lista de grupos

disponibles, luego se debe hacer clic en el botón de agregar.

Imagen 10 Seleccionar grupo Disponible.


1

Imagen 11 Resultado de agregar un usuario a un grupo existente.

.

6.2.2 Quitar usuario de un grupo.

Para eliminar la asociación de un grupo con un usuario es necesario seleccionar el usuario, luego

seleccionar el grupo del cual ya no hará más parte el usuario de la lista de grupos del usuario, a

continuación se debe hacer clic en el botón quitar.


1

Imagen 12 Seleccionar grupo asociado al usuario.

Imagen 13 Resultado de quitar a un usuario de un grupo.


1

7. PÁGINA REGLAS DE ACCESO La página rules permite administrar las reglas de acceso que componen el sistema y como estas se

relacionan con los usuarios; grupos, zonas y unidades creados por el administrador del sistema, una

regla de acceso puede afectar a un usuario de muchas maneras, ya sea a través de los grupos que a los

que pertenece o directamente, de la misma forma una regla de acceso puede afectar a una unidad

directamente o a través de una zona creada por el administrador

Al ingresar a la página localhost:4567/rules se podrá observar la siguiente interfaz gráfica:

Imagen 14 Vista general de la página rules.


1

Imagen 15 vista detallada de la página rules 1 de 2.

Imagen 16 vista detallada de la página rules 2 de 2.


1



Lista de Reglas

Permite observar la lista de Reglas que

componen el sistema

Lista de Usuarios


están afectados por la regla seleccionada

Usuarios

Disponibles


componen el sistema

Lista de Grupos

Activos para la

Regla

Permite ver los grupos afectados por una

regla

Grupos disponibles

para la Regla Permite ver los Grupos disponibles

Lista de usuarios

afectados por la

regla seleccionada

Permite ver que usuarios están siendo

afectados por la regla seleccionada

Lista de Zonas

afectada por la

regla

Permite ver las zonas a las se encuentra

afectando la regla seleccionada

Zonas disponibles

para la Regla Permite ver las zonas disponibles.

Unidades de la regla


están asociadas a la regla

Lista de unidades


componen el sistema

Agregar Regla de

Acceso

Vinculo que permite agregar una nueva

regla de acceso.


1





Tabla 19 Componentes página Rules.


7.2.1 Agregar grupo a la regla

Para agregar un grupo a una regla de acceso se debe primero seleccionar la regla, luego de la lista de

grupos disponibles se debe seleccionar el grupo que va a ser afectado por la regla y a continuación se

debe hacer clic en el botón agregar.

Imagen 17 Seleccionar grupo para ser afectado.


1

Imagen 18 Grupo agregado para ser afectado por la regla.

En las imágenes anteriores es posible evidenciar como al agregar un grupo a una regla, inmediatamente

se ve actualiza la lista de usuarios afectados por la regla, lo que facilita el control y el seguimiento de la

cantidad de usuarios que se ven afectados por una regla en particular.

7.2.2 Quitar grupo de la regla.

Para eliminar la asociación del grupo con la regla se debe seleccionar la regla, a continuación se debe

seleccionar de la lista de grupos afectados por la regla el grupo a quitar, luego de esto se debe hacer clic

en el botón quitar.


1

Imagen 19 Seleccionar el grupo a quitar de la regla.

Imagen 20 Resultado de eliminar el grupo de la regla.


1

7.2.3. Agregar usuario a la regla.

Para agregar un usuario para que sea afectado por una regla se debe primero seleccionar la regla, luego

se debe seleccionar el usuario a agregar de la lista de usuarios disponibles, a continuación se debe hacer

clic en el botón de agregar.

Imagen 21 Seleccionar usuario a agregar.


1

Imagen 22 Resultado de agregar un usuario a una regla.

7.2.4 Quitar usuario de la regla.

Para eliminar la asociación de un usuario con una regla se debe seleccionar la regla, a continuación se

debe seleccionar el usuario a retirar de la lista de usuarios afectados por la regla, y luego se debe hacer

clic en el botón quitar.


1

Imagen 23 Seleccionar el usuario.

Imagen 24 Resultado de quitar el usuario de la regla.

En las imágenes anteriores es posible evidenciar como la lista de usuarios afectados por una regla se

modifica una vez se quita el usuario de la regla.


1

7.2.5 Agregar zona a la regla

Para agregar una zona para que sea afectada por una regla se debe primero seleccionar la regla, luego

se debe seleccionar la zona a agregar de la lista de zonas disponibles, a continuación se debe hacer clic

en el botón de agregar.

Imagen 25 Seleccionar zona a agregar.


1

Imagen 26 Resultado de agregar una zona a la regla.

En las imágenes anteriores es posible evidenciar como la lista de unidades afectadas por una regla se

modifica una vez se agrega la zona a la regla.

7.2.6 Quitar zona de la regla

Para eliminar la asociación de una zona con una regla se debe seleccionar la regla, a continuación se

debe seleccionar la zona a retirar de la lista de zonas afectadas por la regla, y luego se debe hacer clic en

el botón quitar.


1

Imagen 27 Seleccionar zona a retirar de la regla.

Imagen 28 Resultado de retirar la zona.


modifica una vez se quita la zona de la regla.


1

7.2.7 Agregar unidad a la regla

Para agregar una unidad para que sea afectada por una regla se debe primero seleccionar la regla, luego

se debe seleccionar la unidad a agregar de la lista de unidad disponibles, a continuación se debe hacer

clic en el botón de agregar.

Imagen 29 Seleccionar unidad.


1

Imagen 30 Resultado de agregar unidad.


modifica una vez se agrega la unidad a la regla

7.2.8 Quitar unidad de la regla

Para eliminar la asociación de una unidad con una regla se debe seleccionar la regla, a continuación se

debe seleccionar la unidad a retirar de la lista de unidades afectadas por la regla, y luego se debe hacer

clic en el botón quitar.


1

Imagen 31 Seleccionar unidad a retirar.

Imagen 32 Resultado de retirar la unidad de la regla.


modifica una vez se quita la unidad de la regla.


1

7.2.9 Agregar una nueva regla de acceso

Para agregar una nueva regla de acceso se debe hacer clic en el vínculo de agregar nueva regla de

acceso, se deben diligenciar los datos:

Descripción: es el nombre descriptivo de la regla en el sistema.

Tipo de acceso: La regla creada puede operar de dos maneras, permitiendo el acceso o negándolo.

Imagen 33 Proceso de creación de una nueva regla.


1

Imagen 34 Resultado de agregar un nueva regla.

8. PÁGINA EVENTOS La página de eventos permite hacer una búsqueda de los eventos generados en el sistema, estos

eventos pueden ser filtrados por fecha, id de usuario, id de la unidad o tipo de evento.

Al ingresar a la página localhost:4567/events se podrá observar la siguiente interfaz gráfica:


1

Imagen 35 Página events.

8.1 Componentes de la página.


Campo Id Usuario Permite ingresar el id del usuario a

buscar

Campo id de la

Unidad

Permite ingresar el id de la unidad a

buscar

Campo tipo de

acceso

Permite seleccionar el tipo de acceso

a buscar

Fecha inicial Permite ingresar la fecha inicial del

periodo a buscar


1

Fecha Final Permite ingresar la fecha final del

periodo a buscar

Botón buscar Permite ejecutar la búsqueda de los

eventos.

Tabla 20 Componentes página Events.


8.2.1 Buscar por fechas

Para buscar por rango de fechas es necesario seleccionar la fecha inicial, luego la fecha final,

posteriormente se debe hacer clic en el botón buscar. Se debe tener en cuenta que la fecha inicial debe

ser menor a la fecha final.

Imagen 36 Ejemplo de búsqueda por fechas.


1

8.2.2 Buscar por usuario

Para buscar por usuario se hace necesario ingresar el id del usuario en el campo correspondiente, a

continuación se debe hacer clic en el botón buscar.

Imagen 37 Ejemplo de búsqueda filtrada por usuario.

8.2.3 Buscar por unidad

Para buscar por id de la unidad es necesario ingresar el id de la unidad en el campo correspondiente y a

continuación se debe hacer clic en el botón buscar.


1

Imagen 38 Ejemplo de búsqueda filtrada por unidad.

MANUAL DE INSTALACIÓN DEL PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON

TECNOLOGIAS LIBRES 36

1

MANUAL DE INSTALACIÓN DEL PROTOTIPO DE SISTEMA DE CONTROL DE

ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES


Álvaro Iván Ronderos Acevedo




Bogotá 2016



1

Contenido Instalar LDAP (Servidor) .................................................................................................................... 38

Instalar Sistema Operativo del Dispositivo ....................................................................................... 43

Desplegar el Sistema ......................................................................................................................... 45

Desplegar el Servidor ........................................................................................................................ 46

Desplegar el cliente (Dispositivo) ...................................................................................................... 47



1

Instalar LDAP (Servidor)

Nota: La instalación documentada corresponde a Ubuntu Linux, esta se realiza a modo de ejemplo,

puede realizarse la instalación de LDAP en cualquier sistema operativo que lo soporte.

Si ya tiene un servidor de dominio de Active Directory o LDAP solo debe modificar el archivo

configuration.properties del paquete acco_ldap_pscal para que cumpla con las

especificaciones del árbol de dominio.

Para instalar LDAP ejecute desde una terminal autenticado como super usuario:

apt-get install slapd

Cuando finalice la instalación del paquete, se debe reconfigurar, pare realizar la reconfiguración

ejecute en la terminal:

dpkg-reconfigure slapd

Responda a las preguntas de la siguiente forma:

¿Desea omitir la configuración del servidor LDAP?: No



1

Introduzca su nombre de dominio de DNS: acco.local

Nombre de la organización: acco

Contraseña del administrador: seleccione una contraseña para la instalación.

Verificación de contraseña: digite la contraseña seleccionada, de nuevo.

Motor de base de datos a utilizar: HDB

¿Desea que se borre la base de datos cuando se purgue el paquete slapd?: No

¿Desea mover la base de datos antigua?: Si

¿Desea permitir el protocolo LDAPv2?: No

Instale un administrador gráfico de LDAP como PHPldapadmin o Apache Directory Studio

para conectarse al directorio y restaurar el arbol de ejemplo de acco.local:



1

Indique los datos de conexión y datos del usuario administrador:

Al acceder se debe desplegar la siguiente pantalla:



1

Realizar la importación del archivo ldif de ejemplo:

Comprobar la creación de los objetos:



1

Contenido del Archivo ldif de ejemplo:

dn: ou=people,dc=acco,dc=local

objectClass: top

objectClass: organizationalUnit

ou: people

dn: ou=groups,dc=acco,dc=local

objectClass: top

objectClass: organizationalUnit

ou: groups

dn: uid=javier.alfonso,ou=people,dc=acco,dc=local

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: person

objectClass: top

cn: javier.alfonso

sn: ACCO

displayName: Javier Ricardo Alfonso Alba

givenName: Javier Ricardo Alfonso Alba

mail: [email protected]

title: Ingeniero

uid: javier.alfonso

userPassword::

e3NzaGF9N2FFYjZCOWRiQStnZTA3NTdxYXVXeDNiQ3VIenRKTmtjSTRna2c9

dn: uid=alvaro.acevedo,ou=people,dc=acco,dc=local

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: person

objectClass: top

cn: alvaro.acevedo

sn: ACCO

displayName: Alvaro Ivan Acevedo Ronderos

givenName: Alvaro Ivan Acevedo Ronderos

mail: [email protected]

title: Ingeniero

uid: alvaro.acevedo

userPassword::

e3NzaGF9N2FFYjZCOWRiQStnZTA3NTdxYXVXeDNiQ3VIenRKTmtjSTRna2c9

dn: cn=administradores,ou=groups,dc=acco,dc=local

objectClass: top

objectClass: posixGroup

cn: administradores

gidNumber: 500

memberUid: cn=javier.alfonso,ou=people,dc=acco,dc=local

memberUid: cn=alvaro.acevedo,ou=people,dc=acco,dc=local



1

Instalar Sistema Operativo del Dispositivo

Descargar

Para Instalar el sistema operativo del dispositivo primero debe descargar la última imagen de

raspbian de la página de raspberry pi, en

https://downloads.raspberrypi.org/raspbian_latest

Formatear la Tarjeta SD

Nota: esta guía es tomada enteramente de:

https://www.raspberrypi.org/documentation/installation/installing-images/linux.md

como referencia se ha realizado la traducción del formateo con Linux, pero puede

consultar el formateo con Windows o Mac OS en:

https://www.raspberrypi.org/documentation/installation/installing-images/README.md

Por favor tenga en cuenta que el uso del comando dd puede sobre escribir cualquier partición de

la máquina, si usted especifica un dispositivo incorrecto en las instrucciones posteriores,

puede eliminar la partición primaria del sistema operativo Linux. Por favor sea

cuidadoso.

Ejecute df –h para identificar los dispositivos montados

Si su equipo de cómputo tiene una ranura para tarjetas SD, inserte la tarjeta. De lo

contrario, inserte la tarjeta dentro de un lector de tarjetas SD, y conecte el lector al

computador.

Ejecute df –h de nuevo. El dispositivo adicional que aparece es su tarjeta SD, la siguiente

columna tiene el nombre del dispositivo de su tarjeta SD, este debe ser mostrado así

como: /dev/mmcblk0p1 o /dev/ssd1 . la última parte (p1 o 1 respectivamente) es el

número de la partición pero se debe escribir la tarjeta SD por completo, no solamente la

partición. Como consecuencia se debe remover esta parte del nombre, obteniendo así,

por ejemplo: /dev/mmcblk0 o /dev/sdd , este es el nombre del dispositivo para la tarjeta

SD completa. Tenga en cuenta que la tarjeta SD puede verse más de una vez en la salida

de la ejecución de df; Esto puede ocurrir si previamente se ha escrito una imagen de

raspberry pi en esta tarjeta, debido a que la imagen de tarjeta SD de raspberry pi tiene

más de una partición.

Ahora debe tener en cuenta el nombre del dispositivo, es necesario desmontarlo, para que

los archivos pueden ser leídos o escritos en la tarjeta SD mientras se realiza la copia de la

imagen.

Ejecute umount /dev/sdd1, reemplace sdd1 con cualquiera que sea el nombre del

dispositivo de la tarjeta SD (Incluido el número de partición).

Si la tarjeta SD aparece más de una vez en la salida de la ejecución del comando df quiere

decir que tiene múltiples particiones, debe desmontar cada una de ellas.

https://downloads.raspberrypi.org/raspbian_latest

https://www.raspberrypi.org/documentation/installation/installing-images/linux.md

https://www.raspberrypi.org/documentation/installation/installing-images/README.md



1

En una terminal, escriba la imagen a la tarjeta con el comando a continuación, debe estar

seguro de reemplazar el parámetro de archivo de entrada if= con el argumento adecuado

de ubicación del archivo de imagen .img, y /dev/sdd en el argumento de archivo de salida

of= con la ruta del nombre del dispositivo correcto. Este paso es muy importante debido a

que se puede perder información del disco duro principal si se ingresa un nombre de

dispositivo equivocado. Debe estar seguro que el nombre del dispositivo corresponde a la

tarjeta SD entera, descrito a continuación, no solamente a una partición, por ejemplo: sdd,

no sdd1 o sddp1, y mmcblk0, no mmcblk0p1.

dd bs=4M if=2016-03-18-raspbian-jessie.img of=/dev/sdd

Por favor tenga en cuenta establecer el tamaño del bloque en 4M así funciona bien la

mayoría de las veces, si no, por favor intente con 1M, sin embargo tomará

considerablemente más tiempo.

También tenga en cuenta que si no está autenticado como root es necesario anteponer el

comando sudo.

El comando dd no muestra ninguna información del progreso y puede parecer que está

congelado; la operación puede tomar más de cinco minutos en terminar de escribir la

tarjeta. Si su lector de tarjetas tiene un LED este puede parpadear en el proceso de

escritura. Para ver el progreso de la operación de copia usted puede ejecutar pkill -USR1 -

n -x dd en otra terminal, recuerde adicionar sudo si no está autenticado como root. El

progreso será visualizado en la ventana original y no en donde se ejecutó el comando pkill,

puede que el progreso no se visualice inmediatamente, debido a la recarga del buffer.

En lugar de dd se puede usar dcfldd; este ofrece un reporte de avance sobre que tanto ha

logrado escribir.

Se puede verificar que se escribió sobre la tarjeta SD haciendo una copia desde la tarjeta

hacia otro archivo de imagen en el disco duro, truncando la im{agen al mismo tamaño que

la original y ejecutando diff ( o md5sum) sobre las dos imágenes.

La tarjeta SD pude tener más capacidad de almacenamiento que la imagen original, y dd

haría una copia de la tarjeta entera. Como consecuencia se debe asegurar de truncar la

nueva imagen con el tamaño de la original. Debe estar seguro de reemplazar el parámetro

de archivo de entrada if= con el argumento correcto del nombre del dispositivo. Así diff

podría reportar que las imágenes son idénticas.

dd bs=4M if=/dev/sdd of=from-sd-card.img

truncate --reference 2016-03-18-raspbian-jessie.img from-sd-card.img

diff -s from-sd-card.img 2016-03-18-raspbian-jessie.img

Ejecute sync; para asegurarse que el caché de escritura es desocupado de forma segura

antes de desmontar la tarjeta SD.

Remueva la tarjeta SD del lector.



1

Primer Inicio

Antes de iniciar por primera vez el dispositivo, asegúrese de transferir a la tarjeta SD los archivos

necesarios para la instalación y/o ejecución de los programas a instalar.

Cuando finalice el proceso de copiado de los archivos, retire la tarjeta SD de forma segura del

computador e insértela en el dispositivo.

Conecte al dispositivo teclado, ratón, monitor y sus cables.

Ahora conecte el cable de poder USB al dispositivo

El dispositivo iniciará en modo de configuración, en este modo se puede: ampliar el

sistema de archivos para usar toda la tarjeta SD (Para dispositivos SD de más de 2 GB),

cambiar las opciones locales para seleccionar su ubicación, cambiar las opciones de zona

horaria para seleccionar su ubicación o crear usuarios. Para terminar seleccione finish y el

sistema se reiniciará.

Acceso por terminal

Después del reinicio de la configuración puede acceder a la terminal usando el usuario pi con la

contraseña raspberry.

Desplegar el Sistema Para desplegar el sistema, debe instalar mongDB v3 o superior y JRE (Java RunTime Environment)

1.6 o superior en el servidor y los dispositivos.

Instalar JRE

Descargar JRE

Descargar el tar.gz para Linux x64 de la página de Oracle (Servidor):

http://www.oracle.com/technetwork/es/java/javase/downloads/jre7-downloads-1880261.html

Descargar el tar.gz para arm hard Float de la página de Oracle (Dispositivo):

http://www.oracle.com/technetwork/java/javase/downloads/jdk7-arm-downloads-2187468.html

Descomprimir

Copiar el archivo tar.gz en una ubicación adecuada, por ejemplo /usr/local y descomprimirlo con

tar –xvzf.

Enlazar

Crear enlaces simbólicos a los binarios de java en la carpeta /bin con ln –s

/usr/local/bin/jre1.version/bin/java, repetir la operación para javac, javah, javadoc y jar.

http://www.oracle.com/technetwork/es/java/javase/downloads/jre7-downloads-1880261.html

http://www.oracle.com/technetwork/java/javase/downloads/jdk7-arm-downloads-2187468.html



1

Probar

Ejecute java –version para conocer la versión de java instalada en el sistema.

Desplegar el Servidor Instalar Mongo DB

Para instalar mongoDB ejecute en una terminal como super usuario apt-get install –y mongo-org ,

inicie el servicio de mogoDB con el comando service mongod start , verifique que mongoDB ha

iniciado correctamente visualizando el contenido del archivo /var/log/mongodb/mogod.log

Copiar el jar del servicio

Copie el archivo Acco.jar en la ubicación /usr/local/acco, si no existe la ubicación créela.

Copiar el bash del servicio

Ejecute:

cd /etc/init.d touch accod chmod +x accod vi accod

Inserte dentro del archivo:

#!/bin/sh

SERVICE_NAME=acco

PATH_TO_JAR=/usr/local/acco/Acco.jar

PID_PATH_NAME=/tmp/acco-pid

case $1 in

start)

echo "Starting $SERVICE_NAME ..."

if [ ! -f $PID_PATH_NAME ]; then

nohup java -jar $PATH_TO_JAR /tmp 2>> /dev/null >> /dev/null

&

echo $! > $PID_PATH_NAME

echo "$SERVICE_NAME started ..."

else

echo "$SERVICE_NAME is already running ..."

fi

;;

stop)

if [ -f $PID_PATH_NAME ]; then

PID=$(cat $PID_PATH_NAME);



1

echo "$SERVICE_NAME stoping ..."

kill $PID;

echo "$SERVICE_NAME stopped ..."

rm $PID_PATH_NAME

else

echo "$SERVICE_NAME is not running ..."

fi

;;

restart)



echo "$SERVICE_NAME stopping ...";

kill $PID;

echo "$SERVICE_NAME stopped ...";

rm $PID_PATH_NAME

echo "$SERVICE_NAME starting ..."


&



else


fi

;;

esac

Por último ejecute: service accod start

Desplegar el cliente (Dispositivo) Instalar Mongo DB 25

Para instalar mongoDB primero descargue los binarios para arm desde la url con el siguiente

comando y permisos de super usuario: wget

http://andyfelong.com/downloads/core_mongodb.tar.gz .

Descomprima el paquete con: tar –xvzf core_mongodb.tar.gz .

Copie los binarios a /usr/bin:

cd core_mongodb

25

Tomado de http://andyfelong.com/2016/01/mongodb-3-0-9-binaries-for-raspberry-pi-2-jessie/ traducción de los autores.

http://andyfelong.com/downloads/core_mongodb.tar.gz

http://andyfelong.com/2016/01/mongodb-3-0-9-binaries-for-raspberry-pi-2-jessie/



1

chown root:root mongo* chmod 755 mongo* strip mongo* cp -p mongo* /usr/bin

Cree el usuario mongodb: adduser --ingroup nogroup --shell /etc/false --disabled-password --

gecos "" --no-create-home mongodb

Cree el directorio de log con los permisos apropiados:

mkdir /var/log/mongodb chown mongodb:nogroup /var/log/mongodb

Cree el directorio de la base de datos con los permisos adecuados:

mkdir /var/lib/mongodb chown mongodb:root /var/lib/mongodb chmod 775 /var/lib/mongodb

Cree el archivo de configuración mongodb.conf en /etc:

cd /etc vi mongodb.conf


# /etc/mongodb.conf

# minimal config file (old style)

# Run mongod --help to see a list of options

bind_ip = 127.0.0.1

quiet = true

dbpath = /var/lib/mongodb

logpath = /var/log/mongodb/mongod.log

logappend = true

storageEngine = mmapv1

Cree la entrada en el systemd

cd /lib/systemd/system vi mongodb.service


[Unit]

Description=High-performance, schema-free document-oriented database



1

After=network.target

[Service]

User=mongodb

ExecStart=/usr/bin/mongod --quiet --config /etc/mongodb.conf

[Install]

WantedBy=multi-user.target

Ahora está listo para iniciar el servicio de mongoDB:

service mongodb start

Verificar el estado de mongoDB:

service mongodb status

Debe asegurarse que mongoDB baje limpiamente:

service mongodb stop

Copiar el bash de integración

Ejecute:

cd /usr/bin touch acco chmod +x acco vim acco


!/bin/bash

id_unidad="unidad_001"

Date=$(date +%d/%m/%Y\ %T )

DateL=$(date +%s)

#mongo acco --eval

"printjson(db.userDTO.findOne({accessToken:'$1'},{id:1,_id:0}))" | grep

id

result=$(/usr/bin/mongo acco --eval

"printjson(db.userDTO.findOne({accessToken:'$1'},{id:1,_id:0}))" | grep

id)

id_user="user_id:''"

if [ "$result" ] ; then

echo "encontrado"



1

id_user=$(echo "$result" | sed 's/id/user_id/g' | sed 's/{//' | sed

's/}//')

echo "id_user: $id_user"

type="GRANTED"

else

echo "no encontrado"

type="DENIED"

fi

mongo acco --eval

"db.eventDTO.insert({type:'$type',time:NumberLong('$DateL'),unit_id:'$id_

unidad',$id_user,description:'$Date',accessToken:'$1'})"

Modifique el nombre de la unidad acorde con la nomenclatura seleccionada.

Copiar el jar del servicio

Copie el archivo accomobile.jar en la ubicación /usr/local/acco, si no existe la ubicación créela.

Copiar el bash del servicio

Ejecute:

cd /etc/init.d touch accomobiled chmod +x accomobiled vi accomobiled


#!/bin/sh

SERVICE_NAME=accomobile

PATH_TO_JAR=/usr/local/acco/accomobile.jar

PID_PATH_NAME=/tmp/accomobile-pid

case $1 in

start)

echo "Starting $SERVICE_NAME ..."

if [ ! -f $PID_PATH_NAME ]; then


&



else

echo "$SERVICE_NAME is already running ..."

fi

;;



1

stop)



echo "$SERVICE_NAME stoping ..."

kill $PID;

echo "$SERVICE_NAME stopped ..."

rm $PID_PATH_NAME

else


fi

;;

restart)



echo "$SERVICE_NAME stopping ...";

kill $PID;

echo "$SERVICE_NAME stopped ...";

rm $PID_PATH_NAME

echo "$SERVICE_NAME starting ..."


&



else


fi

;;

esac

Por último ejecute: service accomobiled start

Documents

PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO ...repository.udistrital.edu.co/bitstream/11349/8319/2...estos sistemas de control de acceso se usa la huella digital, u otra cualidad diferencial,