Tesis de grado control automatizado de ingreso salida - cadav

DESAROLLO DE UN SOFTWARE PARA EL CONTROL AUTOMATIZADO DEL
INGRESO Y SALIDA DE VEHÍCULOS EN EL CAMPUS DE LA PUCE SD,
DEMOSTRANDO SU FUNCIONALIDAD MEDIANTE UN PROTOTIPO
PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR
SEDE SANTO DOMINGO
ESCUELA DE SISTEMAS
Disertación de Grado Previa la obtención del título de Ingeniero en Sistemas
y Computación
AUTORES:
CRISTIAN FERNANDO BARRENO RAMIREZ
PAÚL FERNANDO TAPIA PEÑA
DIRECTOR:
ING. JOSÉ LUIS CENTENO
SANTO DOMINGO- ECUADOR, 2013

ii
PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR
SEDE SANTO DOMINGO
APROBACIÓN DE LA DISERTACION DE GRADO
DESAROLLO DE UN SOFTWARE PARA EL CONTROL AUTOMATIZADO DEL
INGRESO Y SALIDA DE VEHÍCULOS EN EL CAMPUS DE LA PUCE SD,
DEMOSTRANDO SU FUNCIONALIDAD MEDIANTE UN PROTOTIPO
AUTORES:
TRIBUNAL
ING. JOSÉ LUIS CENTENO
ING. MILTON ANDRADE Ms.
ING. RAMIRO HURTADO
Santo Domingo, Diciembre 2012

iii
AUTORÍA
Nosotros Paúl Fernando Tapia Peña con C.I.171896632-6 y Cristian Fernando Barreno
Ramírez con C.I. 180368237-4, egresados de la Escuela de Sistemas de la Pontificia
Universidad Católica del Ecuador sede Santo Domingo; declaramos que el presente
trabajo de investigación previo a la obtención del título de Ingenieros en Sistemas y
Computación, es inédito por lo que liberamos de cualquier responsabilidad a la PUCE
SD, siendo la disertación responsabilidad de los autores; y el patrimonio intelectual de la
misma a la Pontificia Universidad Católica Sede Santo Domingo.
Atentamente,
Paúl Fernando Tapia Peña Cristian Fernando Barreno Ramírez

iv
DEDICATORIA
La presente Tesis se la dedico a Dios y a mi familia. A mi madre, pilar fundamental en mi
vida, por quien todo esto ha sido posible. A mi hijo Alex por regalarme la fuerza necesaria
a través de su sonrisa y palabras.
Este trabajo está dedicado a las personas más importantes de mi vida, mis padres en
agradecimiento a su esfuerzo, cariño y sacrificio, de quienes me llevo el mejor ejemplo de
esfuerzo y superación. A mis hermanos por su solidaridad y apoyo en todos los buenos y
malos momentos.

v
AGRADECIMIENTOS
El más sincero agradecimiento a la empresa EVISEL automatismos, equipos de vigilancia
y seguridad electrónica y de forma especial al Sr. Gerente Juan Carlos Alvia, por haber
facilitado información necesaria y por demás valiosa, para el desarrollo del presente
trabajo, sobre equipos de automatismos.
Un agradecimiento especial a todos y cada una de las personas que con sus consejos
aportaron para que el trabajo avance y en especial al Ingeniero José Luis Centeno
Director de la Disertación, por su apoyo y empuje sin el cual el presente trabajo no
hubiera podido ser concluido.

vi
RESUMEN
El presente trabajo de grado comprende el desarrollo de un software para el control del
proceso de ingreso y salida vehicular del Campus universitario de la PUCE SD, su
funcionalidad se demuestra a través de un prototipo, el cual simula el funcionamiento de
un control de barrera. Se considera que el prototipo simule la sección del control de
entrada vehicular, garita de guardianía; en pro de mejorar los niveles de seguridad
existentes.
El software está diseñado para la administración del control, a través del cual se registra
las entradas y salidas de los vehículos en el Campus, además de toda lo información
necesaria para asegurar un correcto control vehicular. La interface para el usuario está
hecha en Visual Basic.Net 2008 el código utilizado para el desarrollo es Visual Basic.Net.
Cuenta con una base de datos desarrollada en Oracle 10g bajo el lenguaje SQL.
La parte física del trabajo realizado comprende a la maqueta que representa la sección
de guardianía, en la que se encuentra un modelo del control de barrera propuesto, así
como la circuitería necesaria para la interacción del software con los componentes del
control, tal y como son los motores de la barrera y el lector de tarjetas.

vii
ABSTRACT
This current work includes the development degree of software for process control
vehicular entrance and exit of the PUCE SD, its functionality is demonstrated through a
prototype, which simulates the operation of a control of barrier. It is considered that the
prototype simulating the control section of driveway, gated guardianship; towards
improving existing safety levels.
The software is designed to control management, through which you register the inputs
and outputs of the vehicles on campus, plus all the information necessary to ensure
proper vehicle control. The user interface is made in Visual Basic.Net 2008 the code used
for development is Visual Basic.Net. It has developed a database in Oracle 10g on SQL.
The physical part of the work includes the model representing guardianship section, which
is a model of the proposed barrier control and the circuitry needed for software interaction
control components, as are engines of the barrier and the card reader.

viii
INDICE DE CONTENIDOS
AUTORÍA.......................................................................................................................... iii
DEDICATORIA .................................................................................................................iv
AGRADECIMIENTOS........................................................................................................v
RESUMEN........................................................................................................................vi
ABSTRACT ..................................................................................................................... vii
INDICE DE CONTENIDOS……………………………………………………………………. viii
LISTA DE FIGURAS........................................................................................................ xii
LISTA DE TABLAS ......................................................................................................... xiv
ANTECEDENTES Y JUSTIFICACIÓN.............................................................................15
OBJETIVO GENERAL.....................................................................................................17
OBJETIVOS ESPECÍFICOS............................................................................................17
PROCESO DE DESARROLLO........................................................................................18
MARCO TEÓRICO ..........................................................................................................20
INTRODUCCION.............................................................................................................20
1.1. CONTROL AUTOMÁTICO........................................................................................20
1.1.1. Definición...............................................................................................................20
1.1.2. Variables................................................................................................................21
1.1.3. Diagramas de bloque.............................................................................................22
1.1.4. Tipos de controles Automáticos .............................................................................23
1.2. SOFTWARE .............................................................................................................24
1.2.1. Ciclos de Vida del Software ...................................................................................24

ix
1.2.2. Clases de Software................................................................................................27
1.3. SISTEMAS DE ALMACENAMIENTO DE DATOS.....................................................28
1.3.1. Base de datos........................................................................................................28
1.4.1. Codificación ...........................................................................................................30
1.4.2. Tecnología .NET....................................................................................................30
1.5. GESTORES DE BASE DE DATOS...........................................................................31
1.5.1. Oracle ....................................................................................................................32
1.5.2. Lenguaje SQL........................................................................................................32
1.6. CIRCUITO ELECTRÓNICO......................................................................................33
1.6.1. Elementos de un circuito........................................................................................33
1.7. MODELOS................................................................................................................34
1.7.1. Modelos Verbales ..................................................................................................34
1.7.2. Modelos de Simulación..........................................................................................35
1.7.3. Modelos Analíticos.................................................................................................35
1.8. ANÁLISIS DE LA INFORMACIÓN ............................................................................36
METODOLOGIA..............................................................................................................38
2.1. DETERMINACIÓN DE REQUERIMIENTOS.............................................................38
2.1.1. Población y Muestra ..............................................................................................39
2.1.2. Resultados de la encuesta.....................................................................................40
2.1.3. Contextualización del Sistema para mejorar el control vehicular............................50
2.1.4. Requerimientos Funcionales..................................................................................54

x
2.1.5. Requerimientos No Funcionales ............................................................................60
2.2. ANALISIS Y DISEÑO DE LA SOLUCIÒN .................................................................61
2.2.1. Arquitectura ...........................................................................................................61
2.2.2. Modelado...............................................................................................................62
RESULTADOS Y DISCUSION ........................................................................................66
3.1. RESULTADOS .........................................................................................................66
3.2. ESTRUCTURA DEL SOFTWARE ............................................................................67
3.2.1. Conectividad con la Base de Datos........................................................................67
3.2.2. Método de Desarrollo.............................................................................................68
3.2.3. Módulos del Sistema..............................................................................................68
3.3. ESTRUCTURA DEL PROTOTIPO............................................................................70
3.4. MODO DE OPERACIÓN ..........................................................................................73
3.5. DISCUSIÓN..............................................................................................................74
CONCLUSIONES Y RECOMENDACIONES ...................................................................76
CONCLUSIONES............................................................................................................76
RECOMENDACIONES....................................................................................................76
BIBLIOGRAFÍA................................................................................................................78
LIBROS ...........................................................................................................................78
REVISTAS.......................................................................................................................78
SOPORTE ELECTRÓNICO.............................................................................................78
GLOSARIO......................................................................................................................79

xi
ANEXOS..........................................................................................................................81
ANEXO 1.........................................................................................................................81
ENTREVISTA DIRECTORA RECURSOS FÍSICOS ........................................................81
ANEXO 2.........................................................................................................................85
ENCUESTA SOBRE EL USO DE PARQUEADERO........................................................85
ANEXO 3.........................................................................................................................87
INFORME DEPARTAMENTO RECURSOS FÍSICOS......................................................87
ANEXO 4.........................................................................................................................88
CODIFICACIÓN DEL SISTEMA CADAV .........................................................................88
ANEXO 5.......................................................................................................................128
Manual Técnico de Instalación y Configuración .............................................................128
ANEXO 6.......................................................................................................................158
Manual de usuario CADAV ............................................................................................158

xii
LISTA DE FIGURAS
Figura 1. 1 Tipos de Variables .........................................................................................21
Figura 1. 2 Diagrama de Bloque ......................................................................................23
Figura 1. 3 Control Automático de Lazo Abierto...............................................................23
Figura 1. 4 Control Automático de Lazo Cerrado .............................................................24
Figura 1. 5 Modelo de Cascada .......................................................................................25
Figura 1. 6 Ciclo de Vida del Software – Modelo Cascada con retroalimentación............27
Figura 1. 7 Sistemas de Almacenamiento de datos .........................................................28
Figura 1. 8 Base de Datos ...............................................................................................29
Figura 1. 9 Entorno Visual Basic.NET..............................................................................31
Figura 1. 10 Sistema Gestor de Base de Datos ...............................................................32
Figura 1. 11 Circuito Electrónico ......................................................................................33
Figura 1. 12 Elementos de un circuito electrónico............................................................33
Figura 1. 13 Modelo de Simulación..................................................................................35
Figura 1. 14 Modelo Analítico ..........................................................................................36
Figura 1. 15 Análisis de la Información ............................................................................36
Figura 2- 1 Diagrama de flujo procedimiento propuesto Acceso Vehicular.......................50
Figura 2- 2 Diagrama de Clases Diagrama Prototipo CADAV..........................................51
Figura 2- 3Diagrama posibles Casos de Uso...................................................................56
Figura 2- 4 Diagrama CU-01............................................................................................57

xiii
Figura 2- 10 Diagrama CU-07..........................................................................................59
Figura 2- 11 Diagrama CU-08..........................................................................................60
Figura 2- 12Requerimientos para el Sistema ...................................................................63
Figura 2- 13Funciones Actores del Control......................................................................63
Figura 2- 14Diagrama Base de Datos CADAV.................................................................65
Figura 3- 1Sistema de Control de Acceso Vehicular ........................................................66
Figura 3- 2Esquema del Sistema de Control de Acceso ..................................................67
Figura 3- 3 Formulario para acceder al sistema (Loggin) .................................................69
Figura 3- 4 Formulario de Gestión del Sistema................................................................69
Figura 3- 5 Formulario de CADAV Consola .....................................................................70

xiv
LISTA DE TABLAS
Tabla 2- 1 Clase USUARIO .............................................................................................52
Tabla 2- 2 Clase ROL ......................................................................................................51
Tabla 2- 3 Clase CLIENTE...............................................................................................52
Tabla 2- 4 Clase TARJETA..............................................................................................53
Tabla 2- 5 Clase PASE....................................................................................................53
Tabla 2- 6 Clase VEHÍCULO ...........................................................................................53
Tabla 2- 7 Clase PARQUEADERO..................................................................................54
Tabla 2- 8 Clase ESPACIO..............................................................................................54
Tabla 2- 9 Clase TRANSACCIONES...............................................................................54
Tabla 2- 10 Actores .........................................................................................................55
Tabla 2- 11 Listado Casos de Uso...................................................................................56
Tabla 2- 12 Diagrama de Casos de Uso CADAV.............................................................57

15
ANTECEDENTES Y JUSTIFICACIÓN
Actualmente nuestra sociedad se encuentra en una capacidad de desarrollo y evolución
como nunca antes se pensó, esto ha sido gracias al fácil acceso a la información con la
que contamos ahora. Tomando en cuenta que podemos acceder desde cualquier lugar
del planeta, sea con algún dispositivo fijo o móvil, a un sin número de bancos de datos,
donde su fuente puede estar ubicada de igual manera en cualquier lugar de nuestro
planeta.
Esto ha desencadenado por lógica en un enorme incremento en nuestra capacidad de
procesamiento de información, lo que nos permite demandar mejores sistemas con
mayores tasas de rendimiento, fiabilidad, seguridad, etc.; En especial en aquellos que
están destinados a realizar tareas de monitoreo. Ya que deben poder contar con la
capacidad de registrar todo lo que sucede, en los entornos para los que fueron creados.
Enfoquémonos en especial en los Sistemas de control de Acceso Vehicular, ya que estos
deben ser lo suficientemente robustos para asegurar que la empresa, institución o
persona que los emplee pueda contar con información completa y precisa para salir
avante de cualquier situación que pueda comprometer la seguridad de su parque
automotor,
El contar con un control que permita tener un registro eficiente del parque automotor que
ingresa y sale de las instalaciones de una empresa o cualquier tipo de institución ya sea
pública o privada siempre resulta de vital importancia para garantizar y precautelar la
integridad y seguridad del establecimiento que se encuentra bajo el control aplicado.
Existen muchas instituciones que utilizan controles obsoletos para este fin o simplemente
no tienen un sistema de control que les garantice una mayor seguridad de los vehículos
que ingresan o salen de sus instalaciones.
El proceso de control vehicular que actualmente se lleva a cabo en el Campus de la
Pontificia Universidad Católica del Ecuador Sede Santo Domingo (PUCE SD) se lo realiza
mediante distintivos que son colocados en los vehículos registrados por el departamento
de Recursos Físicos.
El procedimiento a seguir para el ingreso en caso de que el vehículo se encuentre
debidamente registrado es: el conductor recibirá por parte del personal de seguridad un
carné al ingresar al Campus, el cual deberá ser presentado y devuelto al momento de la

16
salida. En caso de no estar registrado, el conductor deberá entregar un documento de
identificación personal, con el cual se registrará y validará su ingreso, este también
recibirá un carné, para poder canjear el documento entregado a su salida del Campus.
Al aplicar este control no se puede contar con un completo historial del parque automotor
que ingresa y sale del Campus universitario, debido a que solo se registra el ingreso de
los vehículos que no poseen el respectivo distintivo de la Universidad, es así que se han
evidenciado varios problemas de tipo administrativos, por ejemplo con los datos que
actualmente se tiene resulta imposible establecer la real demanda de parqueaderos en la
Institución. Así también se han podido identificar algunos problemas con respecto a la
seguridad del parque automotor en los interiores de la Universidad, esto como
consecuencia de contar con un limitado control que no permite determinar posibles
responsables o implicados, en actos delictivos cometidos en contra del parque automotor
que ingresa al Campus, como ha sucedido en varias ocasiones1
.
Además cabe destacar que aplicar el procedimiento durante las horas pico provoca
demoras en el proceso, tanto en la entrada como en la salida del Campus Universitario e
incluso ocasiona molestos embotellamientos.
Por lo tanto se hace imperiosa la necesidad de una mejora en el proceso de acceso
vehicular al Campus, la cual debe permitir registrar, almacenar y dar a conocer el número
de vehículos en tránsito, así como su tiempo de permanencia en las instalaciones; lo cual
desencadenaría en un incremento considerable en los niveles de seguridad del Campus
de la Pontificia Universidad Católica del Ecuador Sede Santo Domingo (PUCE SD).
Por lo antes dicho se plantea automatizar el proceso de ingreso y salida al Campus
Universitario a través de una solución tecnológica compuesta por dos partes: la primera,
constituida por un software diseñado para la administración del sistema, con el que se
realizan tareas como el registro, almacenamiento y edición de datos a través de los que
se concederá o negará la autorización para acceder o abandonar las instalaciones
universitarias; mientras que la segunda, es el dispositivo de seguridad de control de
1
Anexo 3 Informe de Eventos por Parte de Recursos Físicos

17
barrera, que constituye la parte mecánica. Todo esto bajo la supervisión del operador de
la solución.
Este proyecto realizado en el marco de los requerimientos del proceso investigativo final
de graduación, permite conocer y contar con un eficiente registro del parque automotor
existente en el Campus, mejorando el nivel de seguridad de control de acceso vehicular
que brinda el Campus de la PUCE SD.
Los principales beneficios alcanzados a través del proyecto son: la obtención exacta e
inmediata de la información necesaria para la toma de decisiones en cuanto al control
vehicular, la emisión de reportes con los que pueda conocer los detalles sobre el proceso
de acceso vehicular, el ingreso de vehículos debidamente autorizados e identificados al
Campus de la PUCE SD. Lo que permitirá precautelar eficazmente el parque automotor
en las Instalaciones.
Los beneficiarios directos de este proyecto son: el personal administrativo, docentes y
estudiantes de la Pontificia Universidad Católica del Ecuador Sede Santo Domingo y de
forma indirecta la ciudadanía santodomingueña que visita las instalaciones.
El principal resultado de implementar el prototipo en el Campus Universitario es: contar
con un control eficiente del ingreso y salida vehicular.
OBJETIVO GENERAL
Desarrollar un software que permita la automatización del control del ingreso y salida de
vehículos en el Campus de la PUCE SD, facilitando el ordenamiento del acceso vehicular
y la optimización de tiempos de parqueo en el campus universitario, lo cual ayudará a
mejoría en la seguridad del parque automotor que hace uso de los parqueaderos de la
Institución.
OBJETIVOS ESPECÍFICOS
Desarrollar el programa Control Automatizado De Acceso Vehicular (CADAV) con una
interface gráfica amigable que permita Administrar el proceso de ingreso y salida
vehicular al Campus universitario.
Crear una base de datos que almacene información, la misma que permitirá obtener

18
reportes de acuerdo a los requerimientos de la unidad responsable del control de
vehículos.
Construir un prototipo que permita simular el proceso real del sistema automatizado
propuesto.
PROCESO DE DESARROLLO
Equipo de Trabajo
Para el desarrollo de la Disertación se formó un equipo de trabajo formado por Paúl Tapia
y Cristian Barreno egresados de la Escuela de Sistemas de la PUCE SD y el Ing. José
Luis Centeno, quien dirigió y supervisó todo el proceso de desarrollo del presente trabajo.
Asignación del Tema
La Institución como tal asignó el tema para la disertación de grado previo a la obtención
del título Ingeniero de Sistemas y Computación, el cual consiste en el Desarrollo de un
software para el control automatizado del ingreso y salida de vehículos en el campus de
la PUCE SD, demostrando su funcionalidad mediante un prototipo.
Documentación
Se inició con el proceso de recopilación de información, con el fin de establecer la
necesidad de la elaboración del software para la Universidad, es así que se procedió a
realizar encuestas a los miembros de la comunidad universitaria (Estudiantes, Docentes,
Administrativos, Otros), cuyo resultado obtenido indicó la necesidad del desarrollo del
producto para la universidad.
Para establecer los requerimientos del software se llevó a cabo una entrevista con la
Directora del Departamento de Recursos Físicos2
, a través de la cual se obtuvieron
resultados favorables y de extrema importancia para el desarrollo y la realización del
Proyecto, ya que se corroboró la problemática existente por no contar con un software
exclusivo que almacene los datos que se generan en cada una de las etapas y
2
Anexo 1 Entrevista con la Directora del departamento de Recursos Físicos

19
situaciones suscitadas durante la ejecución del proceso de ingreso y salida del parque
automotor del Campus universitario.
Análisis de la información
La siguiente etapa fue la del análisis de la información obtenida, esta etapa comprendió la
clasificación, análisis, investigación y estudio de la información, ya que se buscaba
abarcar cada uno de los requerimientos identificados de forma eficiente, beneficiando a
cada uno de los actores del proceso.
Diseño del Software y de la base de datos
Se procedió a realizar el diseño del software, la elección de las herramientas a utilizarse y
el gestor de base de datos para el desarrollo del software. Se acordó utilizar herramientas
de modelamiento gráfico, ORACLE 10G como el gestor de Base de datos y para el
software se utilizará Visual Basic.NET 2008. La arquitectura a utilizarse es la de cliente
servidor. Para la parte mecánica se empleará los dispositivos de seguridad de control de
barrera, activados mediante tarjetas de códigos de barras, tomando en todo momento a
consideración para la implementación del mismo, factores como seguridad y rendimiento
Construcción del Prototipo
Una vez desarrollado el software, con el fin de evaluar y demostrar su funcionamiento se
construyó una maqueta que represente el punto de acceso a las instalaciones
universitarias (garita de guardianía), así también con la asesoría de un experto
electrónico se procedió al desarrollo la circuitería necesaria para generar movimiento en
el dispositivo de seguridad vehicular (control de barrera)
Pruebas y Ajustes
Por último y contando ya, tanto con el software así como con la maqueta, se procedió a
realizar las pruebas y ajustes necesarios con los que se asegure su correcto
funcionamiento ante las diferentes situaciones a presentarse, sincronizando de esta
forma su accionar en virtud de lo requerido. Quedando así listo el Software y el Prototipo
para su entrega.

20
I
MARCO TEÓRICO
INTRODUCCION
Desde hace algunos años atrás nos encontramos inmersos en una enorme evolución
tecnológica sin precedente alguno, esto ha permitido que la mayoría de los procesos,
llevados plenamente por seres humanos, si es que no son todos; cuenten con el soporte
y monitoreo de algún componente tecnológico.
Esto ha permitido un mayor y mejor desarrollo en cada una de las etapas de los
diferentes procesos en cada área existente. Sin lugar a dudas el área de la seguridad
vehicular no se ha quedado atrás de esta evolución, esto se ve claramente reflejado en
los sistemas de control de acceso vehicular lo que permite identificarlos ya no únicamente
como un conjunto de partes mecánicas destinadas a la restricción para acceder a algo;
sino que en conjunto con la implementación de mejores dispositivos y mecanismos de
seguridad, capaces de ajustarse a soluciones informáticas.
Se ha conseguido obtener un mayor y mejor nivel de protección, debido a que pueden
reaccionar y controlar la mayoría de las situaciones generadas por su entorno, desde
luego esto ha permitido que aparezcan nuevas y mejores políticas y procesos
organizacionales. En la actualidad estos dispositivos son capaces de identificar, registrar,
auditar y de restringir o permitir el acceso a aquello que les ha sido encomendado, como
por ejemplo el acceso a determinado espacio.
1.1. CONTROL AUTOMÁTICO
1.1.1. Definición
Podemos definir al Control Automático como el control que se ejerce sobre
determinados sistemas sin la intervención humana de forma directa. Estos
controles cuentan con pasos y procesos establecidos los que permiten omitir
parcial o totalmente la participación humana en su accionar, a la vez que su nivel
de complejidad no limita su funcionalidad.
Para que el control sea efectivo se busca que a través de los procesos
establecidos se puedan considerar todas o la mayoría de las situaciones que se

21
puedan presentar en su entorno, a estas situaciones se las conoce como
variables3
.
1.1.2. Variables
Podemos denominar variables a las características, factores, eventos y demás
situaciones medibles que están sujetas a posibles cambios. Por ejemplo en los
sistemas de control vehicular podríamos decir que una de sus variables es el
número de vehículos que ingresa al campus universitario y otra así también podría
ser el número de vehículos que abandona las instalaciones.
Figura 1. 1 Tipos de Variables
Fuente: http://datateca.unad.edu.co/contenidos/358030/ContLinea/captulo_8.html
1.1.2.1. Entrada
Las Variables de entrada son aquellos datos que ingresan al sistema de forma
externa esperando con esto una reacción por parte del mismo, un ejemplo de este
tipo de variables es el código que se le asigna a un usuario de un aplicativo para
acceder al mismo y que debe ser ingresado para que el sistema le conceda
acceso a sus características.
3
http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_control

22
1.1.2.2. Salida
Las variables de salida son las respuestas emitidas por parte del sistema ya sea
consecuencia de un ingreso o por el desenlace de su funcionamiento o accionar.
Como ejemplo tenemos al observado en los sistemas de control de acceso de
nómina el cual devuelve una respuesta cuando el usuario valida su ingreso o
salida y así mismo a determinada hora envía las estadísticas de lo sucedido en
el transcurso del día al Supervisor del proceso. En este caso las variables
serían: la respuesta devuelta al momento de validar el ingreso o salida, ya que
esta puede ser tanto afirmativa como negativa dependiendo del caso.
1.1.2.3. Perturbación
Las variables de perturbación son aquellos eventos que se pueden presentar
durante el desempeño de determinado sistema y que son contrarias al objetivo del
sistema4
. Podemos tomar como ejemplo al posible taponamiento en una de las
alcantarillas de un sistema de desagüe.
1.1.3. Diagramas de bloque
El Diagrama de Bloque es la representación gráfica de un sistema determinado, el
cual busca abarcar cada uno de sus aspectos en cuanto al funcionamiento se
refiere. Identificándose así también la forma en la que estos interactúan durante el
funcionamiento del sistema5
. Los diagramas de bloque están conformados por:
 Elementos.- Son los componentes del sistema de control.
 Flechas.- Son las interacciones que se presentan entre los bloques.
4
http://booki.flossmanuals.net/pythonparatroncos/capitulo-2-tipos-variables-entrada-y-salida-trivial/
5
http://books.google.com.ec/books?id=QK148EPC_m0C&pg=PA58&lpg=PA58&dq

23
Figura 1. 2 Diagrama de Bloque
Fuente: http://avibert.blogspot.com/2012/01/diagrama-de-flujo-herramientas-basicas.html
1.1.4. Tipos de controles Automáticos
Los tipos de sistemas de control son:
1.1.4.1. Lazo Abierto
En este tipo de control la variable de salida no tiene efecto sobre la variable de
entrada, es un control de tipo lineal, su estructura básica es: entrada -> control ->
salida.
Figura 1. 3 Control Automático de Lazo Abierto
Fuente: http://migueltecno17.wordpress.com/2012/06/01/lazo-abierto-y-cerrado/
1.1.4.2. Lazo Cerrado
Estos controles son parecidos a los lineales solo que usan retroalimentación, aquí
sí se puede presentar la influencia de la salida sobre la entrada o sobre el control
automático.

24
Figura 1. 4 Control Automático de Lazo Cerrado
Fuente: http://migueltecno17.wordpress.com/2012/06/01/lazo-abierto-y-cerrado/
1.2. SOFTWARE
El Software es la parte lógica del equipo de cómputo, se lo conoce como la parte
intangible del computador y es la sección en la que está establecida la forma en la
que el equipo de cómputo entero reaccionará ante cualquier solicitud externa. Está
conformado por un sub conjunto de procesos establecidos para realizar una tarea
determinada.
Existen reglas establecidas y recomendadas para realizar un correcto desarrollo de
Software dependiendo de las necesidades del solicitante. Están incluidas en este
grupo las reglas necesarias para brindar el soporte, incluso para su posterior
desinstalación. Estas series de etapas son conocidas como el ciclo de vida del
Software.
1.2.1. Ciclos de Vida del Software
El ciclo de vida del Software enmarca cada uno de los procesos inmersos en la
vida del software, es decir desde su concepción hasta su término. El objetivo por
el cual se ha identificado a las diferentes etapas inmersas en el desarrollo del
software es sin duda el de facilitar y sobre todo estandarizar el desarrollo a través
de modelos establecidos. El orden de cada una de las etapas de desarrollo del
Software dependerá del modelo de ciclo de vida escogido para esta tarea.
1.2.1.1. Modelos de ciclo de vida del Software
Existen varios modelos de ciclo de vida del Software, el modelo más utilizado para
el desarrollo de Software es el modelo en Cascada, siendo su nueva versión la de
Cascada con retroalimentación.

25
1.2.1.1.1. Modelo de Cascada
Es el modelo más utilizado para el desarrollo de Software pese a que es un
modelo no muy flexible ya que en el caso de que se requiera la revisión de
alguna de las etapas anteriores se debe realizar el rediseño de todas las
etapas siguientes y, para iniciar una nueva etapa es necesario que sea
concluida la etapa anterior.
Figura 1. 5 Modelo de Cascada
Fuente: http://ingenierosdelomejorluzmilena.blogspot.com/2010/09/ciclo-de-vida-del-software.html
 Definición de requerimientos
En esta etapa se elabora el documento de requerimientos, este es un
documento en el que se detalla en lenguaje no técnico todo lo requerido para el
software; en él se busca definir todos los aspectos necesarios para que el
producto solicitado sea exitoso, por esta razón se recomienda que el cliente
requirente esté presente en esta etapa.
 Análisis y Diseño del Software
En esta etapa se establecen los requerimientos identificados de forma técnica,
aquí se realizará el análisis de cada requerimiento para poder realizar un
correcto diseño de la solución, las herramientas que nos pueden servir para esta
etapa son los diagramas sean de flujo o de clases, etc.

26
 Implementación y Prueba de unidades
Es la etapa en la que se plasma el resultado de las etapas anteriores a través de
líneas de código, así también es aquí donde se realizarán las pruebas de
rendimiento del producto elaborado.
 Integración y Prueba del Sistema
En esta etapa se realiza la unificación de todo lo realizado para el sistema y
finalmente se prueba a cada uno de sus componentes funcionando en conjunto.
 Operación y Mantenimiento
En esta etapa se realiza cualquier ajuste al sistema que no implique cambios
drásticos a su estructura, de necesitarse cambios de este tipo se deberá ir a la
etapa respectiva y reiniciar todo el proceso desde ese punto.
1.2.1.1.1. Modelo de Cascada con retroalimentación
Es el modelo más utilizado para el desarrollo de Software, siendo la nueva
versión del modelo de Cascada, en este modelo podemos realizar cambios en
etapas anteriores a la que nos encontremos, con el fin de obtener el mejor
posible resultado en el producto final.
Este modelo está compuesto por las siguientes etapas:
 Concepto de Software. En esta etapa se realiza el levantamiento de la
información sobre la necesidad o necesidades del cliente y que serán
resueltas con el software a desarrollarse.
 Análisis de requerimientos. Aquí se realiza un análisis de lo que se va a
desarrollar, para de esta forma definir los componentes y funcionalidades del
producto en cuestión.
 Diseño global. En esta etapa se define la forma en la que se va a desarrollar
el Software o el sistema, así como las entidades de datos y cada uno de los
componentes del mismo.
 Diseño detallado. En la etapa del Diseño detallado se realiza el diseño

27
pormenorizado de cada uno de los componentes del sistema a desarrollar,
 Codificación y Depuración. En esta etapa se convierte lo que se ha
diseñado a lenguaje de máquina, es decir se realiza la codificación del
sistema.
 Prueba del sistema. Esta etapa se la destina para realizar pruebas al sistema
desarrollado y de ser el caso se realizan los ajustes necesarios que no
hubieran sido cubiertos durante la etapa de desarrollo.
Figura 1. 6 Ciclo de Vida del Software – Modelo Cascada con retroalimentación
Fuente: http://www.cenac.ipn.mx/Paginas/
1.2.2. Clases de Software
Existen varias clases de Software, la clasificación se la ha realizado dependiendo
de la aplicación o uso que se le vaya a dar:
1.2.2.1. Software de Aplicación
Esta clase de software es el utilizado por el usuario para realizar las diferentes
tareas, aquí se encuentran los procesadores de texto, reproductores de música,
juegos de video entre otros

28
1.2.2.2. Software de Programación
En esta clase de software se encuentran las herramientas de desarrollo de
software, comúnmente se conoce a este tipo de software como “software para
hacer software”, Aquí encontramos a los compiladores, depuradores, gestores
entre otros.
1.2.2.3. Software de Sistema
Esta clase de software es la que interactúa para controlar al Hardware en conjunto
con el Sistema Operativo, aquí podemos encontrar al firmware del computador,
herramientas de diagnóstico, drivers, controladores, etc.
1.3. SISTEMAS DE ALMACENAMIENTO DE DATOS
Los Sistemas de Almacenamiento son sistemas destinados para el almacenamiento
de datos, tal y como pueden ser chips, tarjetas de memoria, discos duros, entre
otros. Los que interactúan con software dedicado para este fin, para poder
garantizar la seguridad e integridad de la información en ellos almacenada.
Figura 1. 7 Sistemas de Almacenamiento de datos
Fuente: http://natikar.blogspot.com/2011/04/dispositivos-de-almacenamiento-de-datos.html
1.3.1. Base de datos
En una base de datos se puede almacenar de forma ordenada enormes
cantidades de información, para su posterior administración. Se puede definir a la

29
base de datos como “un sistema formado por un conjunto de datos almacenados
en discos que permiten el acceso directo a ellos y de programas que manipulen
ese conjunto de datos.”6
Es decir, es el conjunto de datos almacenados en un
espacio físico y lógico, al que podemos acceder, para administrar la información a
través de soluciones informáticas denominadas Gestores de Bases de Datos.
Los sistemas de bases de datos tienen varias características entre ellas: manejo
de integridad de datos, acceso múltiple de usuarios a la información, consultas y
reportes optimizados, seguridad y auditoria de datos, respaldo y recuperación a
través de backups, disponibilidad de lenguajes estándar de programación.
Las Bases de datos están conformadas por “una o más tablas que guarda un sin
número de datos. Cada tabla tiene una o más columnas y filas. Las columnas
guardan una parte de la información sobre cada elemento que queramos guardar
en la tabla, cada fila de la tabla conforma un registro”7
.
Figura 1. 8 Base de Datos
Fuente: http://www.monografias.com/trabajos34/base-de-datos/base-de-datos.shtml
1.4. HERRAMIENTAS DE DESARROLLO DE SOFTWARE
Las Herramientas de Desarrollo de Software son sistemas diseñados para hacer
sistemas, es decir que a través de sus funcionalidades podemos identificar, diseñar y
6
http://fundamentosinformaticosjl.wordpress.com/category/base-de-datos/
7
http://informatica.wikia.com/wiki/Bases_de_datos

30
realizar un sistema, así como a las partes físicas con que las que están vinculados
(maquetas, circuitos, etc.).
Esto abarca a todo lo necesario para el desarrollo de una solución informática o
software, desde su inicio hasta su término, estas herramientas pueden ser utilizadas
en cada una de las etapas del ciclo de vida del Software, ya que actualmente se
cuentan con herramientas que permiten desarrollar la aplicación desde el diseño
hasta la etapa de puesta en producción, todo a través de la debida codificación de
cada etapa.
1.4.1. Codificación
La codificación es la acción de codificar o “traducir” lo que debe hacer un equipo
informático en un lenguaje que él lo pueda entender. Para que la programación
pueda ser más entendible entre diferentes programadores se crearon y
establecieron un conjunto de reglas o estándares, si son bien aplicados hacen que
no sea tan difícil la compresión de un código en el caso de que necesite ser
revisado.
1.4.2. Tecnología .NET
Punto Net es una tecnología punta, esta tecnología ha sido producida por
Microsoft, quien repotenciando a sus clásicas herramientas de desarrollo en la
búsqueda de liderar el campo de desarrollo de aplicaciones informáticas, ha
puesto en marcha su exitosa interface de tipo IDE. Entre estas herramientas
tenemos como las más importantes a C y Visual Basic. Siendo Visual Basic la de
mayor uso debido al excelente desempeño ofrecido. Las herramientas ofrecidas
por Microsoft en este campo las podemos encontrar en el paquete Visual
Studio.NET
1.4.2.1. Visual Basic.Net
La interface de desarrollo conocida como entorno de desarrollo integrado o IDE,
alojada actualmente en el paquete Visual Studio, ofrece una amplia gama de
herramientas con las que podemos obtener los mejores resultados al momento de
la generación de soluciones con las que incluso permiten interactuar con ciertos
componentes físicos del sistema a través de puertos como lo son: COM, USB,

31
entre otros.
Figura 1. 9 Entorno Visual Basic.NET
Fuente: Los Autores
1.4.2.2. Lenguaje Basic
Es un lenguaje de Programación Orientado a Objetos (POO), esta es la nueva
versión del conocido lenguaje de programación Visual Basic (VB). Su sintaxis es
de fácil comprensión, pero no por eso es limitado en cuanto al tipo de productos
(software) que puede hacer. Este es el lenguaje utilizado en el entorno de Visual
Basic.NET.
1.5. GESTORES DE BASE DE DATOS
Un Gestor de Base de Datos es un sistema que se encarga de la administración de
los datos que le fueren conferidos, es un administrador de bases de datos, por lo
que también se encarga de la verificación y validación del acceso a la información,
existen múltiples Gestores de Datos en el mercado, su uso o elección dependerá de
varios aspectos a considerar, número de usuarios, cantidad de información a
manejar, seguridades, etc. Los más utilizados al momento son Oracle, SQL, MySQL

32
Figura 1. 10 Sistema Gestor de Base de Datos
Fuente: http://elblogdeelsant0.blogspot.com/2011/04/instalar-y-configurar-el-gestor-de.html
1.5.1. Oracle
Es considerado como uno de los mejores y más completo Sistema Gestor de
Base de Datos, reconocido por los excelentes resultados en la administración de
grandes o enormes cantidades de información. Debido a sus beneficios suele ser
utilizado en sistemas de gran valía. Es un gestor multiplataforma, entre sus
características están: escalabilidad, estabilidad, transacciones e integridad de
datos. Para el desarrollo de soluciones utiliza como lenguaje nativo a SQL, con el
que podemos realizar consultas, actualizaciones, ingresos y eliminación de datos.
1.5.2. Lenguaje SQL
El lenguaje SQL es un lenguaje estándar utilizado para el manejo de bases de
datos, a través del cual podemos realizar las diferentes operaciones en las Bases
de Datos, como lo son: creación, modificación y eliminación de datos. Es oportuno
indicar que si bien es cierto SQL es un lenguaje estándar, cada gestor de bases
de datos ha creado ciertas adaptaciones para sus propias herramientas,
entendiéndoselas como sentencias que realizan diferentes funciones dependiendo
del gestor que las ejecute e incluso sentencias únicas para ciertos Gestores.

33
1.6. CIRCUITO ELECTRÓNICO
El circuito electrónico es una red a través de la cual se conectan varios elementos o
componentes electrónicos para cumplir un objetivo determinado. Pueden funcionar
con corriente alterna o continua. Su complejidad así como la cantidad de
componentes electrónicos utilizados dependerá del objetivo a realizar, ya que puede
ser desde iluminar una habitación hasta el total control de una industria
manufacturera.
Figura 1. 11 Circuito Electrónico
Fuente: http://10cosasdetecnologia.blogspot.com/2011/08/circuitos-electronicos-formulas-y.html
1.6.1. Elementos de un circuito
Un circuito está conformado por varios elementos los cuales interactúan entre sí
para cumplir con el objetivo para el que fueron creados:
Figura 1. 12 Elementos de un circuito electrónico
Fuente: http://arita-unviajehacialacreatividad.blogspot.com/2010/05/circuito-electrico.html

34
 Componente. Son los dispositivos que tienen dos o más terminales, rama,
diodos, entre otros.
 Nodo. Son los puntos de convergencia de los conductores dentro del circuito.
 Rama. Las ramas son los subconjuntos del circuito formados por los nodos, a
través del cual circula electricidad.
 Malla. La malla es el camino cerrado del circuito, son los hilos del que
interconectan a los componentes.
 Fuente. Es el componente que se encarga de suministrar energía al circuito.
 Conductor. Es el medio a través del cual se unen los componentes.
1.7. MODELOS
Un modelo es una representación de un algo, con el fin de representar una realidad
se pueden valer de herramientas gráficas, verbales y analíticas. Los tipos de
modelos existentes son: verbales, de simulación y analíticos.
La utilización de un modelo en el desarrollo de un producto nos permite poder
anticiparnos a las posibles situaciones por las que puede atravesar o enfrentar el
producto que estamos desarrollando8
.
1.7.1. Modelos Verbales
Los modelos verbales son modelos condicionantes, es decir que identifican las
posibles situaciones dependiendo de “si es que se cumple determinada situación
entonces sucederá tal cosa”. Un ejemplo sería si un vehículo no cuenta con
permiso para acceder a un edificio entonces no podrá entrar y si posee permiso
para el ingreso entonces podrá entrar.
8
http://www.uam.es/personal_pdi/ciencias/joaquina/BOXES-POP/que_es_un_modelo.htm

35
1.7.2. Modelos de Simulación
Los modelos de Simulación nos permiten representar a través de condiciones y
reglas existentes y previamente identificadas posibles realidades de un
determinado sistema, un claro ejemplo de estos modelos son los prototipos, en los
que se representan segmentos a escala de determinados lugares para poder
simular e identificar aspectos propios de un sistema determinado.
Figura 1. 13 Modelo de Simulación
Fuente: http://dew.uniclick.com.pe/category/simulacion/
1.7.3. Modelos Analíticos
Los modelos analíticos son modelos de mayor complejidad ya que la definición del
sistema se la realiza a través de ecuaciones planteadas los que a través de la
asignación de valores a sus variables pretenden predecir la posible realidad del
sistema. Desde luego este tipo de modelos si bien es cierto, requieren un mayor
esfuerzo para su realización, son modelos muy potentes y de muy cercana
aproximación a la realidad del comportamiento del sistema.

36
Figura 1. 14 Modelo Analítico
Fuente: http://www.scielo.org.bo/scielo.php?pid=S1562-38232009000100003&script=sci_arttext
1.8. ANÁLISIS DE LA INFORMACIÓN
El análisis de la información es el proceso completo a través del cual podemos
realizar una toma de decisión sobre algún tema específico. El proceso inicia desde la
recolección de datos, posterior a esto se realiza la respectiva clasificación de la
información con miras a descartar datos no trascendentales y a eliminar
ambigüedades en la información recopilada, a través de métodos y procedimientos
existentes los cuales pueden ser cuantitativos (resultados de encuestas,
puntuaciones de exámenes, frecuencia) o cualitativos (niveles de satisfacción).
Luego de esto es necesario valerse de todas las herramientas a disposición para la
interpretación de la información recopilada, es así que para un correcto análisis de la
información se debe incluso volver a repasar la información ya seleccionada, todo
esto con el fin que el análisis realizado permita realizar una adecuada toma de
decisión.
Figura 1. 15 Análisis de la Información
Fuente: http://scielo.sld.cu/scielo.php?script=sci_arttext&pid=S1024-94352005000600011

37
El proceso de recolección de la información, es por demás importante ya que si no es
bien realizado el análisis completo puede fracasar, debido a que si no recolectamos
suficientes datos para un correcto estudio no vamos a poder hablar de una decisión
que afecte completamente al entorno en cuestión, es por esto que para determinar
un correcto número de muestra a tomar, es decir de datos a recopilar o individuos a
seleccionar, existen fórmulas que permiten establecer el tamaño correcto de la
muestra con un margen de error aceptable para la toma de nuestra decisión9
.
Para nuestro estudio la fórmula que nos permite hacer esto de forma correcta es:
Dónde:
n = el tamaño de la muestra.
N = tamaño de la población.
Desviación estándar de la población que, generalmente cuando no se tiene su
valor, suele utilizarse un valor constante de 0,5.
Z = Valor obtenido mediante niveles de confianza. Es un valor constante que, si no
se tiene su valor, se lo toma en relación al 95% de confianza equivale a 1,96 (como
más usual) o en relación al 99% de confianza equivale 2,58, valor que queda a
criterio del investigador.
e = Límite aceptable de error muestral que, generalmente cuando no se tiene su
valor, suele utilizarse un valor que varía entre el 1% (0,01) y 9% (0,09), valor que
queda a criterio del encuestador.
9
http://www.monografias.com/trabajos87/calculo-del-tamano-muestra/calculo-del-tamano-
muestra.shtml

38
II
METODOLOGIA
Para el desarrollo del presente proyecto se empleó una metodología de tipo convencional
o prescriptiva de procesos, esta metodología define un conjunto de procesos a seguir
para el desarrollo de un software, es una metodología inductiva de tipo lineal, en la que
es necesario haber terminado con una etapa para poder continuar a la siguiente etapa; si
bien es cierto es una metodología no muy flexible pero, si es bien aplicada los resultados
estarán conforme a lo deseado por el requirente.
Para el Ciclo de Vida del software se empleó el modelo de Cascada con
retroalimentación.
2.1. DETERMINACIÓN DE REQUERIMIENTOS
Para lograr que el sistema desarrollado sea completamente funcional el equipo de
trabajo en esta etapa se valió del método inductivo, es así que para establecer los
requerimientos para el software se obtuvo información acerca del proceso que se
lleva a cabo actualmente, con respecto al ingreso y salida vehicular en el Campus; a
través de una entrevista realizada a la Directora del Departamento encargado del
mismo. También fue necesario presenciar el funcionamiento completo del proceso,
así como del procedimiento aplicado en cada una de sus etapas, con lo que se
determinó: El proceso llevado actualmente no cuenta con los elementos necesarios,
que permitan un control efectivo del ingreso vehicular al campus universitario, esto se
debe a que únicamente son identificados aquellos vehículos que no poseen el
distintivo entregado por el Departamento encargado de la administración del proceso,
por lo que es imposible conocer datos, que podrían ser vitales en la toma de
decisiones; como lo son: tiempo de permanencia de un vehículo al interior del
campus, con el respectivo registro de la hora en la que se dio su entrada o salida;
capacidad en tiempo real del parqueadero automotriz, tiempo en el que se registra el
mayor número de ingresos/salidas, entre otros. Al no contar con una solución
automatizada el esfuerzo y el alto tiempo que representaría realizar el registro de
forma manual de todos los vehículos que ingresan al campus haría inefectivo al
proceso para respuestas inmediatas, ya que primero sería necesario procesar
información antes de una posible respuesta.

39
Así también y con el objetivo de conocer acerca del uso que por parte de los usuarios
se da al parqueadero, el equipo de trabajo se valió de la realización de encuestas a
los usuarios de este servicio universitario, ver anexo 2.
2.1.1. Población y Muestra
Para esta etapa la determinación del tamaño de la muestra se la realizó acorde a
un registro histórico que fue facilitado por el departamento de Recursos Físicos,
con el siguiente detalle:
Tabla 2. 1 Usuarios registrados con vehículos
Fuente: Departamento de Recursos Físicos
Este registro evidenció un crecimiento significativo en el número de personas que
con sus vehículos harían uso de las instalaciones universitarias, por lo que se
decidió determinar el tamaño de la muestra con la población registrada del año
2012 (465), con un nivel de confianza del 95% (Z=1.96). Como se muestra a
continuación se procedió a determinar el tamaño de la muestra requerido:
Tabla 2. 2 Datos para el Cálculo de la muestra
Fuente: Los Autores
Aplicando la fórmula:
n = 211
ESTUDIANTES DOCENTES ADMINISTRATIVO OTROS TOTAL
2010 266 37 11 0 314
2011 325 59 15 0 399
2012 342 100 23 0 465
AÑO
USUARIOS REGISTRADOS CON VEHICULOS
Z=1.96 e=0.05
σ= 0.5 N=465
DATOS PARA EL CÁLCULO DE
LA MUESTRA (n)

40
Con la finalidad de cumplir con el objetivo planteado de conocer sobre el uso del
parqueadero por parte de los usuarios registrados se realizaron las encuestas
acorde al tamaño de la muestra determinada.
Una vez concluida esta tarea se procedió a realizar la clasificación y tabulación de
las respuestas, obteniéndose resultados tanto cuantitativos así como cualitativos,
estos resultados servirán para identificar varios aspectos relacionados con el
servicio de parqueadero brindado por la Universidad.
2.1.2. Resultados de la encuesta
1.- ¿Usted es? Administrativo ( ) Docente ( ) Estudiante ( ) Otro ( )
Tabla 2. 3 Pregunta 1, encuesta
Fuente: Los Autores
Figura 2. 1 Pregunta 1
Fuente: Los Autores
Análisis
De los datos que se obtuvieron podemos identificar que de los usuarios del
parqueadero encuestados 5 fueron del personal administrativo, 6 Docentes, 188
ADMINISTRATIVO 5
DOCENTE 6
ESTUDIANTE 188
OTROS 12
TOTAL 211

41
estudiantes y 12 de otro tipo de usuarios, entendiéndose como otro tipo de usuario
a los proveedores, autoridades, prestadores de servicios y demás personas que
pueden ingresar a las instalaciones universitarias.
Las encuestas fueron realizadas en varios momentos al día por lo que podemos
decir que de los usuarios hacen uso del servicio de parqueadero los que más
entran y salen de las instalaciones universitarias pertenecen al grupo del
estudiantado.
2.- ¿Cuál es su horario de entrada?
Fuente: Los Autores
Figura 2. 2 Pregunta N 2
Fuente: Los Autores
Análisis
De los datos recopilados y para efectos de interpretación se escogió a los de
mayor incidencia, estableciéndose una hora promedio para cada una de las

42
jornadas solicitadas, para el ingreso las horas identificadas fueron 7:00; 12:00;
18:00, para la salida las horas identificadas fueron 8:30; 15:00; 23:00.
Las horas que se identificaron como de mayor aforo a las instalaciones
universitarias nos permiten establecer un rango en el que el servicio de
ingreso/salida tiene mayor demanda el cual coincide con el horario estudiantil así
como con la hora de ingreso del personal universitario.
3.- ¿Señale 3 aspectos que considere importantes para el servicio de parqueaderos?
Fuente: Los Autores
Fuente: Los Autores
DETALLE VOTOS TOTAL
Ubicación con respecto al
lugar de destino.
68 211
Facilidad de acceso. 118 211
Disponibilidad de espacios
físicos.
211 211
Información sobre la
disponibilidad de espacios
físicos.
26 211
Seguridad 201 211

43
Análisis
De los datos tabulados de la pregunta 3 podemos observar que los usuarios
consideran que los lugares e Instituciones que presten este tipo de servicios
deben brindar seguridad, que se tenga facilidad de acceso a cada lugar y además
se observó que para los usuarios encuestados es primordial los espacios físicos
en el parqueadero.
4.- ¿Cuánto tiempo le lleva a usted ingresar con su vehículo dentro de las
instalaciones universitarias?
Tabla 2. 6 Pregunta N 4, encuesta
Fuente: Los Autores
Fuente: Los Autores
1 - 5 minutos 110
5-10 minutos 85
10 - 15 minutos 12
15 - 20 minutos 4
TOTAL 211

44
Análisis
Podemos observar acorde a la información recopilada que los usuarios podrían
tardar entre 1 a 10 minutos como máximo en ingresar a la institución, pero si bien
es cierto es un tiempo relativamente bajo al momento de estar en la fila de espera
para ingresar a la institución esperar ese tiempo se puede convertir en una
verdadera molestia, por lo que lo más loable sería buscar una alternativa para
disminuir estos tiempos de espera.
5.- ¿El tiempo que le toma ingresar a las instalaciones de la universidad le ha
causado inconvenientes al desarrollo de su actividad?
Tabla 2. 7 Pregunta N5, encuesta
Fuente: Los Autores
Fuente: Los Autores
SI 64
NO 147
TOTAL
211

45
Análisis
En esta pregunta encontramos, en los datos cuantificables, que: el 85% de los
entrevistados han tenido inconvenientes en su normal desempeño, mientras el
15% de los entrevistados no han tenido inconveniente al momento de ingresar al
campus. Las razones por las que los entrevistados indican que han tenido
inconvenientes debido al tiempo que les toma ingresar a las instalaciones
universitarias no es posible tabularlas ya que no existe un esquema para la
identificación de estos inconvenientes. Pero la razón más común por llamarla así
es el atraso a sus clases, inicio de jornada, entre otros.
6.- ¿Los parqueaderos de la PUCE SD son?
Fuente: Los Autores
Fuente: Los Autores
Muy adecuados 45
Adecuados 139
Poco Adecuados 24
Muy poco Adecuados 3
TOTAL 211

46
Análisis
Lo que se puede rescatar de los datos tabulados de esta pregunta es que los
usuarios se encuentran conformes con las instalaciones del Campus ya que el
66% indican que el parqueadero es Adecuado, mientras que el 21% considera
Muy Adecuados a los parqueaderos universitarios, es decir más de la mitad de los
encuestados se encuentra conforme con las instalaciones físicas del parqueadero,
lo que nos permite pensar que el inconveniente claramente no es con las
instalaciones físicas del Campus.
7.- ¿Cómo califica usted el sistema de ingreso a los parqueaderos de la institución?
Tabla 2. 9 Pregunta N 7
Fuente: Los Autores
Figura 2. 7 Respuesta N 7
Fuente: Los Autores
Muy bueno 2
Bueno 57
Regular 149
Malo 3
TOTAL 211

47
Análisis
Según lo indicado por los usuarios encuestados consideran al sistema de ingreso
al campus universitario es bueno, regular, esto nos da la pauta para verificar el
hecho de que el proceso requiere cambios para que sea el adecuado a las
exigencias de los usuarios actuales.
8.- ¿El sistema de salida de vehículos es?
Tabla 2. 10 Pregunta N 8
Fuente: Los Autores
Fuente: Los Autores
Muy Satisfactorio 32
Satisfactorio 105
Regular 43
Insatisfactorio 31
TOTAL 211

48
Análisis
Acorde a los datos recopilados nos podemos dar cuenta que existe un nivel de
satisfacción por parte del usuario con respecto al proceso de salida vehicular, pero
con el proceso actual no quedaría registro alguno de las situaciones acontecidas
siempre y cuando parezcas “normales”.
9.- ¿Considera que el control de salida vehicular garantiza la seguridad de su vehículo?
Fuente: Los Autores
Fuente: Los Autores
Análisis
Aquí nos podemos dar cuenta que si bien es cierto el usuario se encuentra
satisfecho por el proceso manejado actualmente, pero pese a ello no está
SI 64
NO 147
TOTAL 211

49
conforme con el nivel de seguridad brindado por el mismo, ya que la pregunta nos
ha dado como resultado que el 70% de los usuarios considera que el proceso
actual no garantiza la seguridad de su vehículo.
Una vez realizado todos los pasos necesarios para levantar la información
correcta con respecto al proceso actual se ha podido establecer las demandas a
ser solventadas por el sistema, siendo las siguientes:
1. Contar con un completo registro del parque automotor que ingresa a las
instalaciones Universitarias. El registro de contener las características
importantes para el proceso: identificación del vehículo, tiempo de
permanencia, cantidad de vehículos, conductor, entre otros.
2. Registrar en tiempo real de los vehículos que ingresaron o abandonaron las
instalaciones, para la obtención de reportes con la información necesaria en la
toma de decisiones.
3. Aumentar los niveles de seguridad a través de la validación de acceso a los
vehículos.
4. Agilitar el registro de todos los vehículos al campus, ya que el ingreso manual
de cada uno demandaría un incremento de tiempo en el ingreso o salida del
automotor.
5. Mejorar el proceso de acceso vehicular al Campus.
Para conseguir satisfacer los requerimientos anteriormente identificados y para
poder contrarrestar las falencias indicadas, se plantea la implementación de una
solución tecnológica.
Con toda la información recabada se puede ya iniciar el prototipado del sistema,
partiendo desde la contextualización del mismo. Para luego continuar con la
determinación de los requerimientos funcionales y los no funcionales para el
sistema, tarea que se la realiza haciendo uso de las herramientas existentes para
esto, como lo son los Diagramas de Clases y los Casos de Uso.

50
2.1.3. Contextualización del Sistema para mejorar el control vehicular
Al prototipo de control de acceso vehicular se lo ha denominado Sistema de
Control de Acceso Vehicular CADAV, es prototipado y diseñado con la finalidad,
de facilitar la administración de los vehículos que ingresan y salen del Campus
Universitario, lo que permite tener mayor seguridad; así como también, utilizar
tecnologías que facilitan el montaje íntegro del sistema. Con la solución propuesta
el acceso al campus universitario se lo realizaría a través de tarjetas de códigos
de barras, esta sería la mejor opción por su bajo costo y durabilidad. El control
automatizado contaría con lectores de códigos de barras dispuestos en la entrada
y en la salida del Campus Universitario. A través de los cuales llegaría información
sobre el vehículo al operador del sistema; quien dispondría el acceso o salida del
automotor, con lo que en el caso de validar los datos el operador accionaría por
medio del sistema el control de barrera, terminando así el proceso. Aquellos
usuarios que no contaren con la tarjeta respectiva, el sistema concedería el
acceso siempre y cuando se justifique el mismo, ya que podría tratarse de algún
proveedor, de autoridades o que algún usuario olvidó la tarjeta.
Figura 2- 1 Diagrama de flujo procedimiento propuesto Acceso Vehicular
Fuente: Los Autores

51
2.1.3.1. Diagrama de Clases
Un diagrama de clases nos sirve como ayuda para poder representar en una
forma más clara lo que se busca del sistema, siendo necesario para su estudio
la traducción a través de un diagrama el procedimiento anteriormente descrito.
Figura 2- 2 Diagrama de Clases Diagrama Prototipo CADAV
Fuente: Los Autores
2.1.3.2. Diccionario de Clases
Como siguiente paso en la determinación de los requerimientos se revisará a
cada clase incluyendo a sus respectivos atributos.
Tabla 2- 1 Clase ROL
Fuente: Los Autores
CLASE DESCRIPCION
ROL
Determina las funciones o accesos permitidas a un usuario
determinado
ATRIBUTOS DESCRIPCION
rol_id Número que identifica al rol
rol_nombre Caracteristica que identifica al rol asignado

52
Tabla 2- 2 Clase USUARIO
Fuente: Los Autores
Tabla 2- 1 Clase CLIENTE
Fuente: Los Autores
CLASE DESCRIPCION
USUARIOS
Son los encargados del manejo y administración del sistema,
sus funciones van desde el registro de los automotores hasta el
manejo del parqueadero
usu_id Número que identifica al usuario
usu_nombre Caracteristica que identifica al usuario, nombre
usu_apellido Caracteristica que identifica al usuario, apellido
usu_identi Número propio de identificación del usuario
usu_contacto Datos para poder contactar al usuario
usu_nick Caracteristica que identifica al usuario, nick
usu_clave Datos de seguridad para acceder al sistema, contraseña
usu_estado Indica el estado en el que se encuentra el usuario
CLASE DESCRIPCION
CLIENTE Es la persona que hace uso de las instalaciones
cli_id Número que identifica al cliente
cli_identidad Número propio de identificación del cliente
cli_apellido Caracteristica que identifica al cliente, apellido
cli_nombre Caracteristica que identifica al cliente, nombre
cli_tipo Caracteristica que identifica al cliente, registrado o invitado
cli_estado Indica el estado en el que se encuentra el cliente
cli_procede
Indica a que sector pertenece el cliente: estudiante, profesor,
administrativo
cli_descripcion
Datos del cliente que pueden ser utilizados para realizar alguna
validación o registrar novedades

53
Tabla 2- 2 Clase TARJETA
Fuente: Los Autores
Tabla 2- 3 Clase PASE
Fuente: Los Autores
Tabla 2- 4 Clase VEHÍCULO
Fuente: Los Autores
CLASE DESCRIPCION
TARJETA Token de acceso, tarjeta de código de barras
tar_id Número que identifica a la tarjeta
tar_femision Fecha en la que fue emitida la tarjeta al usuario
tar_estado Estado en el que se encuentra la tarjeta de código de barras
CLASE DESCRIPCION
PASE
Tarjeta provisional que se entrega a un usuario de tipo invitado
para acceder a las instalaciones
pas_id Número que identifica al pase
CLASE DESCRIPCION
VEHICULO
Vehículo perteneciente al usuario que parmencerá por un lapso
de tiempo estacionado en el parqueadero de la Institución
veh_id Número que identifica al vehículo
veh_placa Combinación alfanumerica que identifica al vehículo
veh_modelo Caracteristicas que identifica al vehículo, modelo
veh_caracteristicas Caracteristicas propias que identifican a cada vehículo
veh_anio Año en el que fue ensamblado el automotor
veh_clase Identifica la clase de un vehículo automotor
veh_subclase Identifica la clase y sub clase de un vehículo automotor

54
Tabla 2- 5 Clase PARQUEADERO
Fuente: Los Autores
Tabla 2- 6 Clase ESPACIO
Fuente: Los Autores
Tabla 2- 7 Clase TRANSACCIONES
Fuente: Los Autores
2.1.4. Requerimientos Funcionales
El reconocimiento sobre el comportamiento que el sistema CADAV debe realizar
ante las diferentes situaciones a presentarse se describe mejor a través del
CLASE DESCRIPCION
PARQUEADERO
Representa al espacio físico destinado para el aparcamiento de
los automotores
par_id
Número que identifica al parqueadero
par_nombre Caracteristica que identifica al parqueadero, nombre
par_capacidad Número de vehículos soportados por el parqueadero
par_ubicacion
Lugar físico en el campus que se encuentra dispuesto como
parqueadero
CLASE DESCRIPCION
ESPACIO
Lugares disponibles en el parqueadero o parqueaderos del
Campus
dis_id
Número que identifica al número de espacios físicos del
parqueadero
CLASE DESCRIPCION
TRANSACCIONES
Es el evento que se da al momento del ingreso o salida de las
instalaciones universitarias
tran_id Número que identifica a la transacción
tran_fecha Fecha en la que se registra la transacción
tran_tipo Es el tipo de transacción registrada, ingreso o salida
tran_novedades
Se utiliza para registrar posibles novedades que hubieren
surgido durante la transacción

55
modelo de Casos de Uso y de sus elementos como son: actores, casos de uso y
relaciones, es por esto que se utilizó este modelo para establecer los
requerimientos funcionales.
2.1.4.1. Determinación de Actores
Los Actores del Sistema serán los encargados de la administración, uso y manejo
del mismo, la descripción la podemos encontrar en la siguiente tabla.
Tabla 2- 8 Actores
Fuente: Los Autores
2.1.4.2. Determinación de casos de Uso
Una vez establecidos los Actores se delineó las funcionalidades es decir la
determinación de los casos de uso, el bosquejo inicial se dio a través de un
diagrama herramienta que sirvió para perfilarlos y listarlos definitivamente.
ACTORES DESCRIPCIÓN
ADMINISTRADOR
Es el usuario máster del sistema, es quien se encarga de
manejar el sistema. Este usuario tendrá opción de acceso a
todas las áreas del sistema y podrá realizar y acceder a
cualquiera de las opciones existentes
ANALISTA
Supervisará que el procedimiento sea aplicado correctamente
por parte de los operadores. Es el encargado de realizar la
verificación e ingreso, al sistema, de los datos de los clientes y
de los vehículos, también posee accesos para la obtención de
reportes varios.
USUARIO
Es quien se encuentra en la terminal de ingreso o salida de
vehículos sus opciones son las de permitir o denegar el acceso
al Campus universitario.
CLIENTE
Es la persona que va a hacer uso de las instalaciones, ya sea
como invitado o como usuario registrado

56
Figura 2- 3Diagrama posibles Casos de Uso
Fuente: Los Autores
Tabla 2- 9 Listado Casos de Uso
Fuente: Los Autores
Nº CASOS DE USO
CU-01 Gestionar Usuarios y Perfiles
CU-02 Gestionar Clientes
CU-03 Gestionar Tarjetas
CU-04 Gestionar Vehículos
CU-05 Gestionar Parqueadero
CU-06 Gestionar Ingresos
CU-07 Gestionar Salidas
CU-08 Generar Reportes

57
Tabla 2- 10 Diagrama de Casos de Uso CADAV
Fuente: Los Autores
2.1.4.2.1. Detalle de Casos de Uso
A continuación se presentan los diagramas de los Casos de uso identificados:
Figura 2- 4 Diagrama CU-01
Fuente: Los Autores

58
Fuente: Los Autores
Fuente: Los Autores
Fuente: Los Autores

59
Fuente: Los Autores
Fuente: Los Autores
Fuente: Los Autores

60
Fuente: Los Autores
2.1.5. Requerimientos No Funcionales
La selección de las herramientas tecnológicas utilizadas para la realización del
prototipo se la hizo basándose en aquellas que ofrecen mayores y mejores
características en el desarrollo de soluciones informáticas y, que además se
encuentran a disposición de la Pontificia Universidad Católica del Ecuador Sede
Santo Domingo.
Hardware (mínimo):
 Servidor:
Procesador: Pentium IV
Memoria RAM: 512Mb
Espacio en Disco: 1 Gb
Bus de datos: 1 Ghz
 Cliente
Procesador: Pentium IV
Memoria RAM: 512Mb
Espacio en Disco: 500 Mb
Bus de datos: 600 Mhz
Software (mínimo):
 Servidor:
La herramienta utilizada para el desarrollo del sistema en lo referente al
Front End fue Microsoft Visual Studio 2008. El código fuente está escrito

61
bajo el lenguaje de programación Visual Basic.Net. La administración de la
información se la realiza utilizando el Gestor de Base de Datos ORACLE
versión 10g y para la creación, definición y control de la base de datos
empleamos el lenguaje de consulta estructurado SQL.
 Cliente
Microsoft Windows XP
Microsoft Windows .NET Framework 3.5
Microsoft Windows Installer 3.1
2.2. ANALISIS Y DISEÑO DE LA SOLUCIÒN
La solución está integrada por dos partes: la primera es software diseñado para el
sistema y la segunda la parte mecánica, es decir los dispositivos físicos.
En lo referente al software se diseñó un modelo, a través del cual se busca no
represente mayores inconvenientes, ni cambios drásticos al procedimiento utilizado
actualmente, para el operador del sistema. Con especial atención en la sección de
atención al cliente que se da en el portón de acceso, tomando en cuenta la posible
capacidad para el manejo de soluciones informáticas por parte del usuario.
Debido a que se trata de una solución prototipada para la parte mecánica fue
necesaria la utilización de una maqueta, que nos ayude a representar la sección del
Campus en la que estaría dispuesta. Cabe indicar que las siguientes etapas del
modelo de desarrollo de software se desarrollan en el siguiente capítulo.
2.2.1. Arquitectura
La arquitectura empleada para desarrollar el sistema informático es de tipo cliente
servidor, debido a que esta arquitectura de desarrollo permite la interacción entre
cada una de las partes que conforman el sistema. Esto es de vital importancia ya
que tanto el procedimiento actual como el propuesto, cuentan con puntos de
atención, que se interrelacionan entre sí; y no podríamos hablar de una solución
como tal sin esta característica.
Para accionar los dispositivos de seguridad control de barrera, que forman la parte
mecánica se utilizará el método de control de acceso denominado: sistema

62
biométrico a través de tarjetas de códigos de barras. Debido a la seguridad, alto
rendimiento y bajo costo que este ofrece, lo que permitiría a la Universidad reponer
en corto la inversión realizada para la implementación del sistema.
Figura 2. 1 Control de Acceso Vehicular, metodo de barrera
Fuente: http://guayaquil.olx.com.ec/barreras-vehiculares-y-control-de-parqueos-iid-232717426
2.2.2. Modelado
Para llevar a cabo cualquier tipo de proyecto siempre es necesario diseñar
previamente un modelo de lo que se quiere realizar para en base a esto llegar a la
consecución exitosa del producto esperado. Se recomienda en estos casos
trabajar con el diseño del software y el de la Base de Datos de forma
independiente, pero considerando que ambos deben interactuar entre sí. Lo
concerniente a la parte física de igual manera se recomienda dividir la parte
mecánica de la electrónica y una vez concluidas ambas partes proceder a la
unificación de la parte mecánica con la electrónica.
2.2.2.1. Modelado del Sistema
Para la realización del modelado se identificó la forma de satisfacer los
requerimientos establecidos. Siendo necesario que los usuarios cuenten con un
sistema que les permita registrar y consultar los datos concernientes al acceso
vehícular que se dá en la Institución, datos como tiempos de permanencía,
características del vehículo, entre otros y desde luego el sistema debe poder

63
identificar plenamente al usuario interventor en cada una de estas acciones en el
sistema.fig2-12
Figura 2- 12Requerimientos para el Sistema
Fuente: Los Autores
También se deben considerar los distintos niveles jerárquicos que intervienen en
el proceso. Ya que dependerá del nivel del usuario las tareas a él encomendadas.
Figura 2- 13Funciones Actores del Control
Fuente: Los Autores
Para el proceso del Acceso del vehículo automotor, cuyas características
fueron previamente ingresadas al sistema por el validador del departamento
respectivo véase figura 2-13 se determinó deberá ser de la siguiente forma:

64
El Cliente en el caso de que se encuentre registrado, pasará por el dispositivo su
tarjeta de código de barras, si los datos son admitidos, es decir el lector identifique
como válido el código de barras, procederá al envío de los mismos para la
validación. Si son validados se registrarán los datos, concediéndole el acceso a la
institución. Si por el contrario el cliente no estuviera registrado o no se le hubiese
admitido los datos presentados, el usuario procederá a pedir un documento de
identificación concediendo o no, esto a criterio propio; el acceso a la institución.
Si el usuario concediera acceso debe ingresar, inmediatamente o posterior a esto;
los datos requeridos para el acceso. Así también puede ingresar alguna
observación o anomalía que pueda ser de utilidad posteriormente.
Figura 2. 2 Diagrama de Flujo Procedimiento empleado
Fuente: Los Autores
Por lo que en base a estas premisas el diseño del software se estableció de tal
forma que cumpla con las necesidades expuestas. El sistema se lo desarrollo por
módulos: Clientes, Usuario, Vehículos, Transacciones y Reportes; en los que
podemos realizar funciones de ingreso, modificación, consulta y eliminación de

65
datos, dependiendo del tipo de usuario que esté utilizando el sistema, véase
Figura 2-5.
2.2.2.2. Modelado de la Base de Datos
En lo relacionado a la base de datos (BD), se escogió al modelo de base de datos
relacional, que es el modelo que mejor se adapta a este tipo de soluciones.
Se identificó y clasificó, acorde a la sección en la que intervienen en el sistema
cada una de las tablas y vistas necesarias para su funcionamiento, como por
ejemplo: tablas para validación de usuarios, verificación accesos, identificación de
clientes; aquí cabe indicar que fue necesario distinguirlos en dos posibles tipos de
clientes: invitados (autoridades externas, proveedores, padres de familia, entre
otros) y registrados (alumnos, personal administrativo, docentes, entre otros). De
estos últimos la Universidad posee el registro completo de cada uno de ellos
(Clientes registrados), por lo que se facilitará una vista con la información
necesaria para el funcionamiento del sistema.
Para los datos correspondientes a los clientes de tipo invitado, así como para el
resto de campos, fueron creadas tablas para su respectivo registro figura 2-14.
Figura 2- 14Diagrama Base de Datos CADAV
Fuente: Los Autores

66
III
RESULTADOS Y DISCUSION
3.1. RESULTADOS
El Sistema para el Prototipo de Control Automatizado del Acceso Vehicular en el
Campus de la PUCE SD, denominado CADAV, se desarrolló para la plataforma
Windows utilizando un lenguaje de alto nivel orientado a objetos como es Visual
Basic.Net, se realizó bajo modelamiento UML; con un sistema de control de gestión
de Base de Datos de modelo entidad relación, a través del Gestor de BD Oracle 10g.
Es así que a través de este enfoque se desarrolló el prototipo para poder cumplir con
los objetivos planteados; con una interface que permita una correcta interacción
hombre-máquina, en este punto cabe señalar que fueron desarrolladas dos
soluciones para el sistema, la primera empleada para la gestión de datos, habilitada
únicamente para los usuarios de tipo Administrador y Analista su nombre es CADAV;
la segunda denominada CADAV-Consola desarrollada para el control vehicular.
Su labor es realizada en un entorno que integra: equipos de cómputo, dispositivos
lectores, interfaces hombre-máquina así también un control de barrera; los cuales
interactúan entre sí y por lo que ha sido necesario definir los diferentes controles que
normen correctamente su funcionamiento en el sistema.
Figura 3- 1Sistema de Control de Acceso Vehicular
FUENTE: Los Autores

67
3.2. ESTRUCTURA DEL SOFTWARE
El software se ha desarrollado con las características necesarias para la interacción
de los componentes y así cumplir con los objetivos planteados, ver anexo 4.
Figura 3- 2Esquema del Sistema de Control de Acceso
FUENTE: Los Autores
3.2.1. Conectividad con la Base de Datos
La conectividad con la Base de Datos se la realiza a través de una cadena de
conexión utilizando el Objeto de conexión OracleConnection, con lo que
garantizamos la conexión al servidor. A continuación se muestra el código fuente de
la cadena de conexión:
PublicFunction GetConnectionString() AsString
'Objetos usados en el caso de que no se desee ingresar el
servidor
Dim cs AsString = "Data Source={2};User Id={0};Password={1};"
Dim cs2 AsString = String.Format(cs, _UserName, _Password,
_Servidor)
Return cs2
EndFunction

68
Como se observa en el código fuente en la cadena definimos la ruta, el usuario y
el password a utilizarse para el enlace con la Base de Datos.
3.2.2. Método de Desarrollo
El método de desarrollo empleado para la elaboración del Software fue por
Capas con lo que se garantiza la distribución efectiva del trabajo, se escogió n=3,
es decir existen 3 capas: presentación, enlace y transacciones. La forma de su
funcionamiento obedece a la arquitectura cliente-servidor por capas. Donde la
capa de presentación envía y presenta los datos tanto las solicitudes como los
resultados al Usuario del Sistema, en la capa de enlace se realiza la definición e
interpretación de las solicitudes realizadas. En la capa de transacciones es donde
se resuelven las peticiones realizadas, aquí es donde interactuamos con la Base
de Datos para la obtención de los resultados.
3.2.3. Módulos del Sistema
Para el desarrollo del Sistema fue necesario separarlo en dos grandes módulos,
los que trabajan guardando relación sobre su funcionamiento pese a estar
dirigidos a dos grupos distintos. Los módulos creados con este fin son:
administración y consola. El sistema en sus dos componentes (CADAV y CADAV
Consola) utiliza para su funcionamiento Formularios, los formularios básicos
utilizados son Loggin y administración o consola.
3.2.3.1. Módulo de Administración
El módulo de Administración está diseñado para interactuar directamente con las
tablas y con las opciones correspondientes a los usuarios del sistema como son:
registro, consulta, modificación y eliminación de datos. Este módulo es el
encargado de velar por el correcto uso del sistema, esto se logra a través de
reglas de validación, inmersas en el código fuente del software también a través
del control de ingreso de los usuarios con el método biométrico de ingreso por
conocimiento, esto es aplicado en el formulario de la solución denominado
Loggin. El cual es utilizado en ambos componentes de la solución con el mismo
fin.

69
Figura 3- 3 Formulario para acceder al sistema (Loggin)
FUENTE: Los Autores
Es a través de este módulo que podremos obtener la información en tiempo real
de las transacciones del proceso aplicado, las cuales se pueden ajustar a
nuestras necesidades específicas del momento.
Es aquí donde se encuentran las opciones para el manejo de la información tanto
de los usuarios, así como la de los clientes, sus vehículos y el registro de los
datos del ingreso/salida de la Institución.
Figura 3- 4 Formulario de Gestión del Sistema
FUENTE: Los Autores

70
3.2.3.2. Módulo de Consola
El Módulo de Consola fue creado para llevar el control de los datos concernientes
a los clientes, transacciones y vehículos que ingresan a la Universidad. Para su
manejo, en sus componentes, fueron creados los formularios de Gestión y
Consola, con los que se puede realizar las todas las operaciones de la lógica del
negocio, desde luego acorde al rol del usuario que se hubiere otorgado, es decir a
su perfil.
En este Módulo el usuario podrá validar la información representativa para el
proceso y ejecutar las acciones que le corresponden acorde a la presente
propuesta. Como son: registro de novedades al momento del ingreso/salida de la
institución del vehículo, esto se puede dar al momento que el usuario otorga
acceso a un cliente invitado, o que no se le registraron los datos en el sistema.
También permite denegar el acceso a la Universidad en el caso de así
considerarlo.
Figura 3- 5 Formulario de CADAV Consola
FUENTE: Los Autores
3.3. ESTRUCTURA DEL PROTOTIPO
El presente trabajo comprende de dos partes, la parte mecánica y el software a
continuación vamos a revisar la parte mecánica, sobre la implementación del
prototipo ya que si bien es cierto el software desarrollado busca trabajar con equipos

71
reales para efectos demostrativos se realizó un prototipo conformado por una
maqueta del área de garita de guardianía con escala 1- 47 y, la parte de la circuitería
está compuesta por: dos motores eléctricos de tipo paso a paso, un circuito de
control conformado por un micro controlador, codificado para que controle a los
motores y emita las órdenes para su funcionamiento.
Figura 3. 1 Maqueta para el Sistema
Fuente: Los Autores
El circuito de control está conformado por transistores, resistencias, led, diodos. La
comunicación se la realiza de forma serial RS-232, por su utilidad en el control que
se va a implementar y por facilidad en el manejo y comunicación con el puerto.
Para el desarrollo de la circuitería de la maqueta fue necesario contar con el soporte
de un experto electrónico para cada etapa de la producción del circuito. Lo primero
en desarrollar fue la red de la circuitería, el resultado de esto lo podemos ver en la
siguiente figura:
Figura 3. 2 Malla para el circuito de control de los motores
Fuente: Experto electrónico

72
Tomando en cuenta que se necesitaría contar con dos motores (proceso
ingreso/salida) se elaboraron dos mallas de este tipo una para cada motor. En la
siguiente imagen se puede ver el resultado de la aplicación de la malla desarrolla.
Figura 3. 3 Malla con el detalle de sus componentes electrónicos
Fuente: Los Autores
Figura 3. 4 Circuito electrónico desarrollado
Fuente: Los Autores
La implementación de los motores se la realizó sobre una base de madera instalada
en la maqueta y en su terminales de giro se les coloco las barreras respectivas.

73
Figura 3. 5 Motor de dos tiempos con la barrera adaptada
Fuente: Los Autores
3.4. MODO DE OPERACIÓN
Para el ingreso al Campus Universitario en un vehículo automotor el prototipo
considera dos posibles casos: Cliente registrado, Cliente no registrado.
Para ser considerado como cliente registrado es necesario que los datos de la tarjeta
de código de barras coincidan con los del vehículo en el que se intenta acceder en
ese momento. El acceso en este caso se lo realiza utilizando la tarjeta en el
dispositivo lector de código de barras, cuando la lectura es realizada de manera
exitosa el Operador verificará que los datos del vehículo coincidan con lo mostrado
en su terminal, si esto ocurre se permitirá el acceso a las instalaciones universitarias
a través del control de barrera.
Cuando el acceso no sea realizado por un cliente registrado o porque el dispositivo
no reconoce a la tarjeta, el operador del sistema deberá solicitar para el acceso al
Campus un documento de identificación tanto del Cliente como del automotor, con lo
cual se entregará y permitirá el acceso con una tarjeta creada para este
procedimiento. Recordando que el acceso a invitados estará normado por lo que así
disponga el administrador del sistema.
Figura 3. 6 Maqueta simulando el acceso concedido
Fuente: Los Autores

74
El sistema registrará cada uno de las transacciones realizadas lo que permitirá
posteriormente su correcta supervisión. Es importante mencionar que para cada
ingreso el sistema verificará la disponibilidad de espacios en el parqueadero para
conceder o negar el acceso.
Así también el sistema cuenta con botones de pánico los mismos que podrán ser
activados en el momento que así se requiera, un claro ejemplo se daría al
presentarse un incendio por lo que sería necesario la evacuación del Campus y a la
vez el ingreso de las unidades de socorro, por lo que se debería tener levantadas
ambas barreras. Y de igual forma se podrían presentar situaciones en las que se
debería denegar toda salida o todo ingreso de vehículos automotores.
Figura 3.7 Modulo de consola con botones de pánico para casos fortuitos
Fuente: Los Autores
3.5. DISCUSIÓN
Los resultados obtenidos han sido suficientes en relación a los objetivos planteados
ya que a través de la solución, se puede contar con un registro completo del tránsito
diario

75
vehicular; lo que nos permite realizar los filtros necesarios para obtener la
información completa de lo requerido por los usuarios del sistema.
Al contar con un completo reporte sobre las transacciones realizadas durante los
rangos de tiempos solicitados podemos encontrar, incluso posibles errores cometidos
sea por los usuarios del sistema o por la parte mecánica del mismo, lo que
finalmente nos servirá para poder determinar responsabilidades y de esta forma
poder realizar la respectiva toma de decisiones cuando así se lo requiera, esto último
era algo imposible de saber con el anterior procedimiento empleado.
Ahora se cuentan con reportes exportables a Excel, estos reportes manejan criterios
de búsqueda para facilitar la tarea, filtros como por ejemplo el de fecha por horas del
día, por tipos de usuario, por tipo de transacción, etc.
Figura 3. 8 Modulo para reporte de Operaciones
Fuente: Los Autores

76
CONCLUSIONES Y RECOMENDACIONES
CONCLUSIONES
En la Pontificia Universidad Católica del Ecuador Sede Santo Domingo actualmente
no se está llevando un adecuado control de ingreso y salida de vehículos, lo que
podría ser perjudicial para la Universidad ante algún caso fortuito, ya que no contaría
con la información necesaria para establecer responsabilidades.
En el caso de que sea implementado el Sistema mejorará y manejará de forma
eficiente el acceso de vehículos al Campus de la Pontificia Universidad Católica del
Ecuador sede Santo Domingo, incrementándose considerablemente los niveles de
seguridad en la Universidad.
El Sistema CADAV ofrece un eficiente control del ingreso y salida del parque
automotor, que usa las instalaciones del Campus universitario, por lo que de
requerirlo se podrá contar con la información necesaria para, resolver las situaciones
que surgen derivadas del control.
La toma de decisiones con respecto a los casos suscitados en la Universidad, sobre
el parque automotor contará con un mejor sustento, debido a la información que se
dispondrá del proceso.
La Universidad al emplear la infraestructura tecnológica y las herramientas de
desarrollo informático que posee en la implementación del sistema, incrementará
significativamente los niveles de seguridad y de satisfacción por parte del usuario de
parqueaderos tal y como un sistema de control lo requiere.
RECOMENDACIONES
Se recomienda llevar un mejor control del proceso de ingreso y salida vehicular del
Campus universitario, el cual permita contar con toda la información suficiente para
establecer responsabilidades de los actores de cada caso dado en la Universidad.
Se recomienda seguir rigurosamente los pasos indicados para la instalación del
sistema del Manual de Instalación, ver anexo 5; con lo que se garantizaría el buen
funcionamiento del sistema.

77
Se recomienda el uso de la metodología convencional con métodos inductivos para
el desarrollo de sistemas de control, ya que a través de esta metodología se pueden
establecer claramente todo lo necesario para que sea un eficaz y eficiente Sistema
de Control.
Se recomienda la implementación del prototipo denominado CADAV, en el Campus
de la Pontificia Universidad Católica del Ecuador sede Santo Domingo, así como la
creación de políticas que permitan un mejor control del ingreso y salida vehicular de
la Institución.
Se recomienda realizar capacitaciones previas a los usuarios del Sistema CADAV

78
BIBLIOGRAFÍA
LIBROS
Halvorson, Michael. Microsoft Visual Basic 2008 Step by Step. Microsoft Team
Loney, Kevin. Oracle Database 10g The Complete Reference. McGraw-Hill. 3ra
Edición
Ramez, Elmasri. Fundamentos de Sistemas de Bases de Datos. 3ra: Edición
Roger S. Pressman, 4 Edición, Mc Graw Hill 1998.
REVISTAS
BOLETÍN INFORMATIVO No.382 re/hcpt Ambato, julio 18, 2008
SOPORTE ELECTRÓNICO
http://www.maestrosdelweb.com/principiantes/%C2%BFque-son-las-bases-de-
datos/
http://www.tungurahua.gov.ec/Publicaciones/NoticiaPdf.php?key=325
http://www.misitio.com.ec/2065f079fd/topic.php?r=6aa8bf9112ea520d7b89d2d478
ddc79a&ct=programming&a=showtopic
http://www.ordenadores-y-portatiles.com/glosario-de-informatica.html
http://fundamentosinformaticosjl.wordpress.com/category/base-de-datos/
http://www.cavsi.com/preguntasrespuestas/quees-un-detector-de-barras-impresas/
http://es.scribd.com/doc/56768256/prototipos
http://www.eumed.net/libros/2008a/358/LOS%20PROTOTIPOS.htm
http://www2.ing.puc.cl/~iing/ed429/sistemas_biometricos.htm
http://www.iec.csic.es/criptonomicon/autenticacion/nombre.html

79
GLOSARIO
Back-end.
Es la parte que procesa la entrada desde el front-end o la base de datos que se vaya a
utilizar.
Dispositivo.
Elemento de "hardware" con el que el sistema interactúa, como son discos duros,
módem, o ratón.
Escalabilidad.
Es la propiedad deseable de un sistema, una red o un proceso, que indica su habilidad
para, o bien manejar el crecimiento continuo de trabajo de manera fluida, o bien para
estar preparado para hacerse más grande sin perder calidad en los servicios ofrecidos.
Estabilidad.
Se dice que un sistema es estable cuando su nivel de fallos disminuye por debajo de un
determinado umbral, que varía dependiendo de la estabilidad que se requiera.
Integridad de datos.
Se refiere a la corrección y completitud de los datos en una base de datos. Cuando la
integridad de los datos almacenados puede perderse de muchas maneras diferentes.
Pueden añadirse datos no válidos a la base de datos, tales como un pedido que
especifica un producto no existente.
Modelamiento.
Aprendizaje por imitación a través de un modelo. También denominado aprendizaje
vicario.
Periféricos.
Dispositivo electrónico físico que se conecta a una computadora. Los periféricos permiten
que la computadora interactúe con el exterior.

80
Prototipado.
Es la acción de haber realizado un prototipo de una situación, cosa, momento, evento,
etc.
Tokens.
Pequeños grupos de datos que representan un conjunto de información mayor
previamente establecida
Transacciones.
Es un conjunto de órdenes que se ejecutan formando una unidad de trabajo.

81
ANEXOS
ANEXO 1
ENTREVISTA DIRECTORA RECURSOS FÍSICOS
Fecha: FEBRERO 2008
Entrevistada: Sra. Fanny Peña, Directora del Departamento de Recursos Físicos
Entrevistador: Sr. Cristian Barreno
Objetivos:
a.- Identificar el procedimiento actual llevado a cabo para el acceso vehicular en el
Campus de la PUCE SD
b.- Identificar a cada uno de los actores del proceso en cuestión
c.- Identificar las ventajas y desventajas del procedimiento aplicado
f.- Establecer las necesidades del Departamento con respecto al procedimiento
Lugar: Oficina de Dirección Departamento de Recursos Físicos.
Fecha: Febrero 2008
Hora: 12:45
Duración: 2 horas
Cuerpo de la entrevista:
Entrevistador: El motivo de la presente entrevista es para identificar plenamente la
realidad del proceso actual, así como sus ventajas y necesidades; realizado en el
Campus de la Pontificia Universidad Católica del Ecuador sede Santo Domingo,
administrado según nos ha sido informado por el departamento que usted preside.
Esto nos es de suma importancia para poder elaborar o para formalizar el procedimiento
que actualmente se lleva a cabo y de ser necesario implementar los cambios que fuesen

Tesis de grado control automatizado de ingreso salida - cadav

Tesis de grado control automatizado de ingreso salida - cadav

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (17)

Similar a Tesis de grado control automatizado de ingreso salida - cadav

Similar a Tesis de grado control automatizado de ingreso salida - cadav (20)

Tesis de grado control automatizado de ingreso salida - cadav