Date post: | 15-Jan-2016 |
Category: |
Documents |
Upload: | jonatan-alcocer-zamora |
View: | 16 times |
Download: | 1 times |
UNIVERSIDAD TECNOLÓGICA DE LA SELVA
ROYECTO FIRUM (FINANZAS Y RECURSOS HUMANOS),
AUTOMATIZACIÓN DEL CONTROL DE HORARIOS Y
GENERACIÓN DE NÓMINA”
T E S I N A
QUE PARA OBTENER EL TÍTULO DE
INGENIERO EN TECNOLOGÍAS DE LA INFORMACIÓN
P R E S E N T A
Jonatan Alcocer Zamora
ASESOR ACADÉMICO
Mtro. Mario Alberto Vázquez
Sánchez
ASESOR EMPRESARIAL
MC. Armando
Méndez Morales.
OCOSINGO, CHIAPAS; ABRIL, 2015
I
AGRADECIMIENTOS
A Dios.
Por darme la vida, la familia en la que estoy, amigos que conozco y la oportunidad de
superarme profesionalmente, por mantenerme sano, por darme de su misericordia,
conocimiento, sabiduría y su infinito amor. Dios ha sido y es la fuente que me da
fuerzas de poder superarme, porque todo lo que soy y tengo se lo agradezco a mi
Dios.
A mis Padres.
Francisco y Aurelia, que son los que me han apoyado durante toda mi vida en mis
estudios, han sido y serán mi fuente de inspiración, mi ejemplo, mi motor para no
retroceder y vencerme. Me dan la fuerza necesaria para poder seguir adelante y
demostrarme que puedo salir adelante en esta vida.
A mis Hermanos.
Uziel que me ha dado el ejemplo que con esfuerzo, disciplina y dedicación se logra
todo lo que me propongo. Ivan y Jafet, que me han brindado su apoyo
incondicionalmente y han estado conmigo en los momentos más difíciles a lo largo de
este camino del estudio.
A los Maestros.
Mtra. Gloria, M.C. Armando, Mtro. Mario que me han enseñado todo lo que se, y que
se han preocupado por el aprendizaje que adquiera como profesional, y tener la
disponibilidad de apoyarme, para prepararme en el mundo laboral; les aprecio mucho.
II
A mis Amigos.
Julián, Wiliams, Israel, Audomar por estar en las buenas y malas de nuestras
experiencias; por su apoyo moral y espiritual.
A la Universidad Tecnológica de la Selva.
Que me brindaron sus servicios, por otorgarme la oportunidad de representarla
laboralmente en la estadía y me emprendieron para poder terminar mis estudios para
ser todo un profesional.
III
RESÚMEN
El control de entrada y salida del personal que labora en la Universidad Tecnológica
de la Selva es de gran importancia, ya que por medio de este proceso surge el poder
realizar los pagos de nómina de cada individuo, llevando a cabo un análisis del pago
que debe ganar un empleado de la institución, menos las faltas acumulas durante el
checado de las entradas y salidas de una quincena. El siguiente proyecto de
investigación se efectuó en la Universidad Tecnológica de la Selva, la cual es una
institución dedicada a brindar servicios de calidad para mejorar la carrera universitaria
de un individuo. Es por ello la necesidad de automatizar el proceso de control de
acceso y la generación de la nómina del personal que labora en dicha institución y las
diferentes actividades que conllevan tener un mayor control y agilidad de la
información que se requiere. Durante el desarrollo del proyecto, se realizó la
investigación correspondiente para tomar en cuenta cual sería la mejor tecnología a
utilizar para la programación del mismo; como evidencia se dará a conocer el diseño
del sistema FIRUM (Finanzas y Recursos Humanos).
Esta investigación tiene como objetivo desarrollar módulos que automaticen el control
de horarios y generación de nómina, mediante el uso de software y dispositivos
biométricos y desarrollo de funcionalidades para gestionar y optimizar la labor
administrativa de Finanzas y Recursos Humanos de la información en la plataforma,
teniendo la facilidad del usuario para que pueda operarlo. Es muy importante
mencionar que las funciones que se integraron fueron tomadas de acuerdo los
módulos que se fueron creando. Se ocuparon estratégicamente las técnicas de
desarrollo para una mejor utilización de los usuarios. Se tomó en cuenta todos los
procedimientos que las áreas realizan para así mismo aterrizar todo esto en métodos
y funciones que en el desarrollo del módulo (programación) a utilizar.
IV
Índice de contenido
CAPÍTULO I. INTRODUCCIÓN ........................................................................................... 1
I.1 Introducción ..................................................................................................................... 1
CAPÍTULO II. ANTECEDENTES ......................................................................................... 3
II.1 Marco teórico .................................................................................................................. 3
II.2 Marco referencial .................................................................................................... 13
II.2.1 Actividad económica a la que pertenece la empresa, institución u
organización ...................................................................................................................... 13
II.2.2 Bienes y/o servicios que produce ..................................................................... 13
II.2.3 Localización geográfica de la empresa (nivel estatal y municipal) ...... 14
Ubicación Estatal ............................................................................................................. 14
II.2.4 Giro y tamaño de la empresa .................................................................................... 16
II.2.5 Área de influencia ...................................................................................................... 17
II.2.6 Objetivos de la empresa ............................................................................................ 17
Misión: .............................................................................................................................. 17
Visión: ............................................................................................................................... 17
Política de calidad: ........................................................................................................... 18
Objetivos de calidad ........................................................................................................ 18
II.2.7 Área de la empresa en donde se desarrolla el proyecto ......................................... 19
II.3 Planteamiento del problema ........................................................................................ 19
II.4 Objetivos ........................................................................................................................ 20
Objetivo general ............................................................................................................... 20
Objetivos específicos ........................................................................................................ 20
II.5. Justificación ................................................................................................................. 20
V
CAPÍTULO III. METODOLOGÍA ....................................................................................... 22
III.1 Enfoque metodológico ................................................................................................ 22
III.2 Método de recolección de datos ................................................................................. 23
III.3 Definir el universo y el tamaño de muestra .............................................................. 25
III.4 Recopilación de datos. ................................................................................................ 26
CAPÍTULO IV. ANÁLISIS DE RESULTADOS Y DISCUSIÓN ...................................... 28
IV.1 Descripción del Caso de Uso ...................................................................................... 30
IV.2 Diagrama de interacción del sistema ......................................................................... 34
IV.3 Arquitectura de la aplicación (MVC) ........................................................................ 37
IV.4 Componentes de la aplicación .................................................................................... 39
IV.5. Diagrama de la base de datos .................................................................................... 41
CAPÍTULO V. CONCLUSIONES Y RECOMENDACIONES ......................................... 54
V.1 Conclusiones .................................................................................................................. 54
V.2 Recomendaciones .......................................................................................................... 54
CAPÍTULO VI. REFERENCIAS DOCUMENTALES ....................................................... 55
ANEXOS .................................................................................................................................. 57
Cronograma de actividades ................................................................................................ 57
Reunión con el cliente .......................................................................................................... 58
Evidencia de minuta de reunión de prototipos ................................................................. 59
Evidencia de minuta de reunión, presentación con el cliente .......................................... 64
Formato de observación ...................................................................................................... 68
VI
Índice de figuras
Figura 1 Logo de Play Framework. ............................................................................. 3
Figura 2 Logo de Bootstrap. ........................................................................................ 5
Figura 3 Logo de Scala. .............................................................................................. 5
Figura 4 Logo de GIT. ................................................................................................. 7
Figura 5 Logo de TortoiseGIT. .................................................................................... 7
Figura 6 Logo de The Reactive Manifesto. .................................................................. 8
Figura 7 Logo de Server Netty. ................................................................................... 9
Figura 8 Logo de API REST. ..................................................................................... 10
Figura 9 Logo de RESTful. ........................................................................................ 10
Figura 10 Logo de Json. ............................................................................................ 11
Figura 11 Grafica de sintaxis Json. ........................................................................... 12
Figura 12 Logo de la Universidad Tecnológica de la Selva. ...................................... 13
Figura 13 Ubicación estatal de Chiapas. ................................................................... 14
Figura 14 Plantilla de la observación pasiva. ............................................................ 26
Figura 15 Plantilla de la minuta de reunión. .............................................................. 27
Figura 16 Diagrama de caso de uso de la interfaz gráfica del sistema FIRUM. ........ 30
Figura 17 Diagrama de interacción del Sistema. ....................................................... 34
Figura 18 Diagrama del Modelo-Vista-Controlador. .................................................. 37
Figura 19 Componentes de la aplicación. ................................................................. 39
Figura 20 Entidad-Relación de la base de datos. ...................................................... 41
Figura 21 Entidad-Relación de horarios checados. .................................................. 42
Figura 22 Entidad-Relación de horarios planeados y justificantes. ........................... 43
Figura 23 Vista principal de los módulos desarrollados. ........................................... 44
Figura 24 Módulo de Personalhorariolectorusuario. .................................................. 45
Figura 25 Módulo de Personalhorariolectorusuario-importar registros de ACCESS. 46
Figura 26 Módulo de Personalhorariolectorusuario-descargar registros en PDF. ..... 47
Figura 27 Módulo de Personalhorariolectorchecado. ................................................ 48
VII
Figura 28 Módulo de Personalhorariolectorchecado-importar registros de ACCESS.
.................................................................................................................................. 49
Figura 29 Módulo de Personalhorariolectorchecado-descargar registros en PDF. ... 50
Figura 30 Módulo Personalhorariojustificante. .......................................................... 51
Figura 31 Módulo Personalhorariojustificante-agregar. ............................................. 52
Figura 32 Módulo Personalhorariojustificante-descargar registros en PDF. ............. 53
Figura 33 Cronograma de actividades. ..................................................................... 57
Figura 34 Presentación de prototipos. ....................................................................... 58
Figura 35 Demostración de los módulos. .................................................................. 58
Figura 36 Minuta de prototipos (1/5). ........................................................................ 59
Figura 37 Minuta de prototipos (2/5). ........................................................................ 60
Figura 38 Minuta de prototipos (3/5). ........................................................................ 61
Figura 39 Minuta de prototipos (4/5). ........................................................................ 62
Figura 40 Minuta de prototipos (5/5). ........................................................................ 63
Figura 41 Minuta de presentación funcional (1/4). .................................................... 64
Figura 42 Minuta de presentación funcional (2/4). .................................................... 65
Figura 43 Minuta de presentación funcional (3/4). .................................................... 66
Figura 44 Minuta de presentación funcional (4/4). .................................................... 67
Figura 45 Formato de Observación pasiva................................................................ 68
VIII
Índice de tablas
Tabla 1 Muestreo del universo. ................................................................................. 25
Tabla 2 Comparativa de las tecnologías candidatas. ................................................ 28
Tabla 3 Autenticar el usuario. .................................................................................... 31
Tabla 4 Mostrar Operaciones. ................................................................................... 31
Tabla 5 Búsqueda de la información. ........................................................................ 32
Tabla 6 Agregar nuevos registros. ............................................................................ 32
Tabla 7 Registros en Excel........................................................................................ 33
Tabla 8 Eliminar datos. .............................................................................................. 33
1
CAPÍTULO I. INTRODUCCIÓN
I.1 Introducción
La Universidad Tecnológica de la Selva, inició a controlar la entrada y salida del
personal con un mecanismo de tarjetas de papel, el cual consiste en que la persona
llega al lugar de salida, pide su tarjeta asignada y la inserta en un aparato electrónico
que registra ya sea la entrada o salida del mismo.
Tomando en cuenta que actualmente son alrededor de 318 personas y todo este
proceso se lleva a cabo por una persona de Finanzas y Recursos Humanos, si piensas
en el tiempo que se tarda en realizar todo el análisis del horario planeado del personal,
junto con los justificantes previos, aplicando una nómina de percepción o deducción,
las faltas que haya tenido y al final generar la nómina para cada quincena, haciendo
todo este cálculo para cada persona se hace muy pesado y genera estrés en el
personal. Debido al crecimiento de la institución, conlleva de igual manera al personal
y cada vez más exige el cumplimiento de procesos internos para las áreas de Finanzas
y Recursos Humanos.
Es por eso que el siguiente proyecto de investigación se efectuó para brindar mejor los
servicios o procesos que llevan a cabo en estas áreas que son de vital importancia,
sin embargó existen situaciones que podrán suscitarse provocando una deficiencia en
el éxito esperado para estas dos áreas. Como resultado de esto se espera la
implementación de un sistema web llamado “FIRUM”, que automatizara el control de
horarios y generación de nómina, que junto a las buenas prácticas ayudara la
obtención de servicios de calidad siendo una herramienta para lograr un fin aceptable
y seguro.
Su aprobación deberá ser realizada en presencia de las personas que son
participantes en los procedimientos, de esta manera aplicar los requerimientos que
2
exige el proceso de control de horarios y generación de nómina con el propósito de
reducir al mínimo esfuerzo y riesgos en fallos.
Los capítulos que conformaran esta investigación son:
II. Antecedentes, se describen los temas relacionados con el motivo de estudio, para
fundamentar el análisis y la interpretación.
III. Metodología, en esta sección se encuentra la descripción del proceso a seguir para
cada etapa.
IV. Análisis de resultados y discusión, con base a los datos encontrados, se presentara
en esquemas, tablas para ser interpretados y realizar la discusión de resultados.
V. Conclusiones, se debe formular las afirmaciones con base a la discusión de
resultados.
VI. Referencias documentales, se enlista todo el material documental utilizado para
fundamentar lo teórico del trabajo, incluye libros, revistas, páginas web, bases de
datos, entre otros.
Anexos, en este apartado se incluyeron todos los materiales utilizados durante el
proceso de investigación (cuestionarios, cartas, tablas y otros documentos).
3
CAPÍTULO II. ANTECEDENTES
II.1 Marco teórico
FRAMEWORK
Es una estructura de soporte definida (marco de trabajo, patrón), en la cual otro
proyecto de software puede ser organizado, implementado y/o desarrollado.
(Jordisan.net, 2006)
Suelen incluir:
Soporte de programas.
Bibliotecas.
Lenguaje de scripting.
Software para desarrollo y unir diferentes componentes en un proyecto.
Permiten:
Facilitar el desarrollo de software.
Evitar los detalles de bajo nivel, concentrándose en los requerimientos de
software.
PLAYFRAMEWORK
Es un Framework de desarrollo web para Java y Scala.
Desarrollado por Guillaume Bort como proyecto interno
Para su empresa Zenexity y luego como Open Source.
(Playframework, 2015) Figura 1 Logo de Play Framework.
4
Ideal para crear Webs con estructura MVC (Modelo-Vista-Controlador) utilizando Java,
Scala y por supuesto HTML con sus respectivas hojas de estilo y librerías
cualesquiera.
Play 2.0 hace uso de varias bibliotecas Java populares:
JBoss Netty para el servidor web.
No se requiere ORM, pero Anorm (Scala) y Ebean (Java) se incluyen para el
acceso de base de datos.
Scala para el motor de plantillas.
Construido en caliente recarga.
SBT para la gestión de la dependencia
La siguiente funcionalidad está presente en el núcleo:
Un marco limpio, REST.
CRUD: un módulo para simplificar la edición de objetos de modelo.
Seguro: un módulo para habilitar la autenticación de usuario sencilla.
Un marco de validación basado en anotaciones.
Un planificador de tareas.
Un sencillo de usar SMTP Mailer.
JSON y XML analizadores y señaleros.
Una capa de persistencia basada en JPA.
Una base de datos integrada con fines rápido despliegue / prueba.
Un marco de plena prueba incrustado.
Una funcionalidad automática de carga de archivos.
Conciencia de configuración multi-medio ambiente.
Una arquitectura modular, lo que permite que aporta nuevas características en
el núcleo fácilmente.
OpenID clientes de servicios web.
5
BOOTSTRAP
Esta metodología mediante prácticas, herramientas
y estándares de calidad internacional; mide, evalúa
y propone mejoras al proceso de desarrollo de SW
que siguen las Unidades de Producción de Software
(UPS) de las empresas. Bootstrap es otra de las iniciativas para resolver la crisis del
desarrollo de software. (Otto, 2015)
La metodología Bootstrap se compone de:
1. Un modelo,
2. Un proceso de evaluación,
3. Una base de datos de soporte,
4. Un proceso de mejora y
5. Lis instrumentos de evaluación.
SCALA
Moderno lenguaje de programación multi-paradigma
diseñado para expresar patrones de programación comunes
de una forma concisa, elegante y de tipado seguro. Integra
fácilmente características de lenguajes orientadas a objetos
y funcionales. (Scala, 2015)
Características de Scala:
Es orientado a objetos: Descritos por clases o extendidas a subclases y traits.
Es funcional: Toda funcional es un valor, de primer orden, anidadas y soporta
currying. Reconoce el procesamiento de datos XML.
Figura 2 Logo de Bootstrap.
Figura 3 Logo de Scala.
6
Es estáticamente tipado: Conformado por un expresivo sistema tipado en
particular en clases genéricas, clases internas, anotaciones variables, límites
de tipado superiores e inferiores, tipos abstractos, tipos compuestos, auto-
referencias explícitamente tipadas, vistas y método de polimorfismo.
Es extensible: En la práctica el desarrollo de aplicaciones específicas para un
dominio generalmente requiere de “Lenguajes de dominio específico” (DSL).
SISTEMAS DE CONTROL DE VERSIONES
Son sistemas que están diseñados para guardar y registrar los cambios a los datos a
lo largo del tiempo, de modo que puedas recuperar versiones específicas más
adelante. (Collins-Sussman & Fitzpatrick, 2015)
Sistemas De Control De Versiones Locales: Usado por mucha gente es
copiar los archivos a otro directorio (quizás indicando la fecha y hora en que lo
hicieron, si son avispados).Este enfoque es muy común porque es muy simple,
pero también tremendamente propenso a errores. Es fácil olvidar en qué
directorio te encuentras, y guardar accidentalmente en el archivo equivocado o
sobrescribir archivos que no querías. Para disolver este problema, los
programadores desarrollaron hace tiempo VCSs locales conteniendo una
simple base de datos registrando cambios realizados.
Sistemas De Control De Versiones Centralizados: Ideal para colaborar con
desarrolladores en otros sistemas como CVS, subversión y Perforce, teniendo
en un único servidor archivos versionados y varios clientes que descargan los
archivos desde el lugar central.
Sistemas De Control De Versiones Distribuidas: Como Git, Mercurial, Bazaar
o Darcs, los clientes no solo descargan la última instantánea de los archivos:
replican completamente el repositorio. Si un servidor muere, y estos sistemas
estaban colaborando a través de él, cualquiera de los repositorios de los clientes
7
puede copiarse en el servidor para restaurarlo. Cada vez que se descarga una
instantánea, en realidad se hace una copia de seguridad completa de todos los
datos.
GIT (SISTEMA DISTRIBUIDO).
Git nace en 2005 y su creador es Linus Torvalds. Git es un
sistema distribuido, rápido y tiene un diseño sencillo,
(Torvalds, 2015). El contenido del código almacenado en Git
se debe de ver como un sistema de archivos; con el cual, por
cada versión, se guarda el contenido íntegro del proyecto; es
decir, de los archivos modificados, se guarda la nueva versión; y de los archivos no
modificados, se guarda una referencia al archivo sin modificar. Git almacena el
contenido de todo el historial en local, así, se tiene la información de todo lo que ha
pasado desde la creación del proyecto. En cada versión, Git por regla general, solo
añade información que llegado el caso, si sucede algo inesperado, es sencillo
recuperar. Git por cada versión mantiene su integración porque aplica una función
hash SHA-1.
TortoiseGIT
Es un interfaz de Windows más fresca de control de versiones
GIT. Este apoyara tareas regulares, como cometer, mostrando
registros, diffing dos versiones, la creación de las ramas y
etiquetas, la creación de parches y ver imágenes o
documentación. (TortoiseGit, s.f.)
Fígura 1 Logo GIT.
Fígura 2 Logo TortoiseGIT.
Figura 4 Logo de GIT.
Figura 5 Logo de TortoiseGIT.
8
THE REACTIVE MANIFESTO
Son sistemas más robustos, elásticos, flexibles y buenos para la
demanda moderna. Haciendo mucho más fácil de desarrollar y dócil
al cambio. Significativamente tolerantes a fallos y si existen son
elegantes en el lugar de desastre, (The Reactive Manifesto, 2015).
Los Sistemas Reactivo son muy sensibles, dando eficacia a la
interacción feedback a los usuarios.
Los Sistemas Reactivos son:
Responsive (Sensible): El sistema responde de una manera oportuna, a todo
lo posible. Siendo la sensibilidad el auge, en la usabilidad y utilidad logrando así
mismo el descubrimiento de problemas y distribución con eficacia
proporcionando rápida contestación, para entregar una calidad de servicio
consistente.
Resilient (Resistente): Ser resistente es muy importante y disponible bajo a
circunstancias críticas de los sistemas para evitar posibles fallos. La resistencia
es lograda a la repetición, contención, aislamiento y comisión. Conteniendo los
fallos, de cada componente, aislando componentes uno del otro y así evitando
comprometer todo el sistema entero.
Elastic (Flexible): Es capaz de reaccionar a cambios de acuerdo a la proporción
a la que se encuentra los recursos de entrada. Son sistemas que predicen y
escalan las medidas pertinentes de actuar logrando rentabilidad en el hardware
y software.
Message Driven (Mensaje controlado): Confían en los mensajes de tipo
asíncrono para estableces un límite para asegurar acoplamiento, aislamiento,
transparencia y la delegación de los mensajes de la situación. El Nonbloking
permite consumir recursos mientras este activo, evitando consumir menos el
sistema.
Fígura 3 Logo The
Reactive Manifesto.
Figura 6 Logo de The
Reactive Manifesto.
9
SERVER NETTY
Es una infraestructura de servidor de cliente NIO que permite el
desarrollo rápido y sencillo de las aplicaciones de red, tales
como servidores de protocolo y clientes. Simplifica y agiliza
enormemente la programación aplicación de red como TCP y
servidor de socket UDP. Orientada a eventos asíncronos, para
el desarrollo rápido de mantenibles servidores y clientes de protocolo de alto
rendimiento. (The Netty Project Community, 2015)
Características:
1. Diseño:
Unified API para los distintos tipos de transporte – bloqueo y sin bloqueo
zócalo.
Modelo de eventos flexibles y extensible que permite separación clara de
preocupación.
Personalizable hilo-hilo único como SEDA.
Soporte real socket de datagramas sin conexión desde la 3,1.
2. Facilidad de uso:
Documentación Javadoc, guía del usuario y ejemplos.
No dependencias adicionales, JDK 5 o 6 es suficiente.
Rendimiento:
Mejor rendimiento, baja latencia.
Consumo de recursos menos.
Minimizado de memoria innecesaria.
3. Seguridad:
Completa SSL / TLS y apoyo StartTLS.
Fígura 4 Logo de Server Netty. Figura 7 Logo de Server Netty.
10
REST
Representational State Transfer, es un estilo de arquitectura
para desarrollar servicios. (REST, 2015)
Los servicios web que siguen este estilo deben cumplir con las siguientes premisas:
Cliente/Servidor: Como servicios web son clientes servidor y definen un
interface de comunicación entre ambos separando completamente las
responsabilidades entre ambas partes.
Sin estado: Son servicios web que no mantienen estado asociado al cliente.
Cada petición que se realiza a ellos es completamente independiente de la
siguiente.
Cache: El contenido de los servicios web REST, se puede cachear de tal forma
que una vez realizada la primera petición al servicio el resto pueden apoyarse
en la cache si fuera necesario.
Servicios uniformes: Todos los servicios REST, compartirán una forma de
invocación y métodos uniforme utilizando los métodos GET, POST, PUT y
DELETE.
Arquitectura en capas: Todos los servicios REST están orientados hacia la
escalabilidad y un cliente REST no será capaz de distinguir, entre si está
realizando una petición directamente al servidor, o se lo está devolviendo un
sistema de caches intermedio (balanceador).
RESTful.
Representational State Transfer ful, hace referencia a un
servicio web que implementa la arquitectura REST, (Fielding,
2015) contiene lo siguiente: Fígura 5 Logo de RESTFul
Figura 8 Logo de API REST.
Figura 9 Logo de RESTful.
11
URI del recurso: Ejemplo: http://api.servicio.com/recursos/casas/1 (esto nos
daría acceso al recurso “Casa” con el ID “1″).
Tipo de representación de dicho recurso: Ejemplo, podemos devolver una
cabecera “Content-type: aplication/json”, siendo los más comunes JSON, XML
y TXT.
Operaciones soportadas: HTML define operaciones que pueden ser GET,
PUT, POST, DELETE, PURGE entre otros.
Hipervínculos: La respuesta puede incluir hipervínculos a otras acciones
sobre los recursos.
JSON
JavaScript Object Notation (Notación de objetos de JavaScript)
es un formato ligero de intercambio de datos. Leerlo y escribirlo
es simple para humanos, mientras que para las maquinas es
simple interpretarlo y generarlo. Formato de texto que es
completamente independiente del lenguaje pero utiliza
convenciones que son ampliamente conocidos por los programadores de la familia de
lenguajes C, C++, C#, Java, JavaScript, Perl, Python y muchos otros. (JSON, 2015)
Está constituido por dos estructuras:
Colección de pares de nombre/valor. Conocido como un objeto, registro,
estructura, diccionario, tabla hash, lista de claves o arreglo asociativo.
Lista ordenada de valores. Implementado como arreglos, vectores, listas o
secuencias.
Figura 10 Logo de Json.
12
En JSON, se presentan de estas formas:
Figura 11 Grafica de sintaxis Json.
13
II.2 Marco referencial
II.2.1 Actividad económica a la que pertenece la empresa, institución u
organización
Figura 12 Logo de la Universidad Tecnológica de la Selva.
En la actualidad la Universidad Tecnológica de la Selva imparte educación de nivel
superior de tipo tecnológico para formar técnicos superiores universitarios, ingenieros
técnicos e ingenieros competentes y comprometidos con el desarrollo socioeconómico
de la entidad.
II.2.2 Bienes y/o servicios que produce
La Universidad Tecnológica del a Selva en el que a través de la administración de sus
recursos, del capital y del trabajo, se producen bienes y/o servicios educativos
tendientes a la satisfacción de las necesidades de la comunidad estudiantil.
14
II.2.3 Localización geográfica de la empresa (nivel estatal y municipal)
Ubicación Estatal
Chiapas, estado situado en el sureste de México, al este del istmo de Tehuantepec,
dentro de la región Pacífico Sur. Limita por el norte con el estado de Tabasco, por el
este con Guatemala (comparte la Frontera Sur), por el sur y sureste con el golfo de
Tehuantepec del océano Pacífico, y por el oeste con los estados de Veracruz y
Oaxaca. Ocupa el 8º lugar en el conjunto del país en cuanto a extensión territorial que
es de 75,634 km, representa el 3.8% de la superficie del país.
Chiapas se sitúa entre los paralelos 14º 32’ al sur y 17º 59’ de latitud norte y los
meridianos 90º 22’ al este y 94º 15’ de longitud oeste.
Fuente:
https://www.google.com.mx/maps/@16.6395712,-92.2834792,10z
Figura 13 Ubicación estatal de Chiapas.
15
Ubicación Estatal
La Universidad Tecnológica de la Selva se encuentra ubicada en la ciudad de
Ocosingo, Chiapas. Se localiza en la carretera Ocosingo–Altamirano, entronque
Tonina Km 0.5.
Fuente:
https://www.google.com.mx/maps/place/Universidad+Tecnol%C3%B3gica+De+La+Selva
Fígura 6 Ubicación regional de la Universidad de la Selva.
16
II.2.4 Giro y tamaño de la empresa
De acuerdo a la prestación que brinda esta casa de estudios indican que su giro
pertenece a Servicios de educación pública descentralizado donde el capital pertenece
al Estado y generalmente su finalidad es satisfacer las necesidades de carácter social
en la cual se desarrollan actividades que competen al Estado y que son de interés
social, pero que está dotando personalidad y patrimonio. La Universidad Tecnológica
de la Selva ha crecido enormemente durante los últimos años, aumentando el número
de empleados a 200 aproximadamente que laboran en esta institución y ascendió el
número de estudiantes a 2,000 aproximadamente. La Universidad Tecnológica de la
Selva es una institución que oferta servicios educativos de calidad, al estar evaluada,
acreditada y certificada bajo la norma ISO 9001-2000.
En la actualidad la Universidad Tecnológica de la Selva imparte educación de nivel
superior de tipo tecnológico para formar técnicos superiores universitarios, ingenieros
técnicos e ingenieros competentes y comprometidos con el desarrollo socioeconómico
de la entidad.
La estructura organizacional de la Universidad contempla los siguientes
departamentos para la administrar eficientemente de sus recursos: Administración y
Finanzas, Vinculación, Planeación y Evaluación, Servicios Escolares, Servicios
Bibliotecarios, Sistema de Gestión de la Calidad, y Servicios Generales y control
patrimonial. Conjuntamente la gestión educativa se delega en cuatro divisiones:
División de Tecnologías de la Información, Carrera de Administración Área Empresas
Turísticas, Carrera de Administración y Evaluación de Proyectos y División de
Agroalimentos. Con un total aproximado de 200 colaboradores, la Universidad.
17
II.2.5 Área de influencia
El área de influencia de la Universidad Tecnológica de la Selva comprende cuatro
regiones económicas, con 28 municipios, a saber: Región I Centro, Región II Altos,
Región III Fronteriza y Región VI Selva. Dentro de estas regiones económicas, se
encuentran inmersos los siguientes Municipios: Venustiano Carranza, Altamirano,
Amatenango del Valle, Chalchihuitan, Chamula, Chanal, Chenalho, Huistán, La Raizar,
Mitoctic, Oxchuc, Pantelhó, Las Rosas, San Cristóbal de las Casas, Tenejapa,
Teopisca, Zinacantan, Comitán; Las Margaritas, Chilón, Ocosingo, Palenque,
Sabanilla, Sitalá, Tila, Túmbala, Yajalón y San Juan Cancún. Generalmente los
alumnos que ingresan a la Universidad provienen de familias de bajo y medio nivel; de
las instituciones como: COBACH, CBTA, CECYT, CBTIS, TELEBACHILLERATO y
Preparatorias Particulares, entre otras.
II.2.6 Objetivos de la empresa
Misión:
Brindar educación superior tecnológica de calidad, realizar investigación aplicada y
difundir los valores de la cultura, para formar profesionistas íntegros, competitivos y
emprendedores, comprometidos con el desarrollo del país y con el uso sustentable de
los recursos naturales.
Visión:
En el 2020, la Universidad Tecnológica de la Selva será la institución de educación
superior tecnológica más reconocida en Chiapas por la competitividad y
posicionamiento de sus egresados en los sectores público, social y privado; por la
18
investigación aplicada que desarrolle y transfiera a la planta productiva; así como por
la preservación y difusión de la cultura que realice en beneficio de la comunidad.
Política de calidad:
El compromiso del personal docente, administrativo y directivo que laboramos en la
Universidad Tecnológica de la Selva, radica en la mejora continua de nuestras
funciones con una excelente actitud de servicio, para satisfacer las expectativas de
alumnos, trabajadores, sector productivo y sociedad en su conjunto.
Objetivos de calidad
1. Ofrecer educación tecnológica intensiva, polivalente, pertinente, flexible,
continua y de calidad.
2. Mejorar la competitividad académica.
3. Elevar la capacidad académica.
4. Impulsar la investigación aplicada y su transferencia al sector productivo.
5. Fortalecer la presencia universitaria en la sociedad para incidir en su desarrollo.
6. Incrementar la rentabilidad social de la universidad.
7. Mantener una eficiente y eficaz administración de los recursos universitarios en
la prestación de los servicios.
19
II.2.7 Área de la empresa en donde se desarrolla el proyecto
Mi enfoque ha sido en el área de Finanzas y Recursos Humanos, donde pondré en
práctica los conocimientos adquiridos durante mi instancia en la UTS. El proyecto será
desarrollado e implementado para un debido control del personal que labora en la
institución antes mencionada. Finanzas y Recursos Humanos es un área que necesita
de un método para poder controlar las entradas y las salidas del personal, así como
las formas de pagos.
II.3 Planteamiento del problema
El problema se debe por generación de la nómina y el acceso del personal que labora
en la institución de la Universidad Tecnológica de la Selva, ya que este proceso se
lleva a cabo por tarjetas prediseñadas por el personal de finanzas y recursos humanos.
Todo este proceso es demasiado tardado puesto que una persona se encarga de
realizar todo el chequeo de entradas y salidas, comparándolas con un horario
establecido al personal de dicha institución, basta también saber que después de
haber verificado, se realizan una serie de descuentos o aumentos ya sea el caso, esto
se deberá a las faltas que se hayan obtenido durante una quincena de un individuo.
Todo recae en la generación de la nómina de un individuo que labora en dicha
institución, tomando en cuenta que son demasiadas personas que trabajan, este
proceso llega a ser demasiado pesado, causa de estrés y deficiencia en el trabajo;
puesto que dos o tres personas lo realizan.
20
II.4 Objetivos
Objetivo general
Desarrollar modulo del software que automatice el control de horarios y
generación de nómina, mediante el uso de software y dispositivos biométricos
y desarrollo de funcionalidades para gestionar y optimizar la labor administrativa
de Finanzas y Recursos Humanos de la información en la plataforma.
Objetivos específicos
Evaluar las condiciones de los procesos y procedimientos en las que
actualmente se encuentra la institución mediante las reuniones.
Elaborar el modulo que integre la información de la base de datos obtenida por
los biométricos al sistema Firum.
Desarrollar la funcionalidad para el registro y exportación de información
importante en formatos Microsoft Office Excel y PDF.
Automatizado eficiente y eficaz respecto a la generación de nómina que
calculara el contador.
II.5. Justificación
Actualmente la labor administrativa en las áreas de Finanzas y Recursos Humanos es
ardua, debido al incremento del personal que se integra a la institución educativa.
En el presente proyecto se presenta una manera de cómo garantizar la inocuidad de
los servicios, mediante la automatización del control de horarios y generación de
nómina que garantice que los resultados estarán realizados conforme a los
21
procedimientos, políticas y restricciones que estos conllevan, añadiéndole una
eficiencia en rendimiento, para ayudar a agilizar la labor administrativa de Finanzas y
Recursos Humanos respecto a la información del personal , cálculo de nóminas y la
administración de la información, teniendo efectos favorables para el cumplimiento del
objetivo general.
Algunos de los beneficios que obtendrá son:
Mayor rendimiento productivo.
Reducir problemas del resultante (control de horarios y generación de nómina).
Disminución de procesos.
Mantener la eficiencia y eficacia en la calidad de servicios.
22
CAPÍTULO III. METODOLOGÍA
III.1 Enfoque metodológico
La investigación que se realizará para llevar a cabo la metodología es la de
investigación acción, este método se basa en la investigación de tipo cualitativo, para
poder desarrollar la investigación los fenómenos se presentaran por medio de la
observación y reuniones que se realizaran para conocer las posibles soluciones que
se tiene ante el problema .
En la investigación realizada se identificara el problema de la empresa en este caso
en el área de Recursos Humanos y Finanzas, esto nos llevara a indagar y conocer los
roles de las personas que están interesados en solucionar los problemas que se
presentan en dicho departamento.
Es muy importante mencionar que la recolección de datos será pieza fundamental para
esta investigación, ya que nos proporcionara información relevante para poder
desarrollar una planeación estratégica que genere las posibles respuestas o solución
ante el problema expuesto.
Este método de investigación es factible para la administración de proyecto de TI para
llevarlo a cabo, debido a que nos proporcionara un enfoque claro de lo que se pretende
establecer ante la problemática, seleccionando las herramientas que se necesiten para
la recolección de datos y dándole un mejor uso a la información.
23
III.2 Método de recolección de datos
a) El principal método a utilizar que se utilizó para obtener toda la información
relacionada con esta investigación, tomando como base el tipo de investigación.
Este tipo de investigación es la investigación-acción (IA), aplicado con la
finalidad de poner la información teórica en práctica, destacando rasgos como
la participación y colaboración, investigación, análisis, práctica y la crítica; Para
(Kemmis, 1984) la IA es ”[...] una forma de indagación autor reflexiva realizado por
quienes participan (profesorado, alumnado, o dirección por ejemplo) en las
situaciones sociales (incluyendo las educativas) para mejorar la racionalidad y la
justicia de: a) sus propias prácticas sociales o educativas; b) su comprensión sobre
las mismos; y c) las situaciones e instituciones en que estas prácticas se realizan
(aulas o escuelas, por ejemplo)”. Se utilizaran métodos de recolección de datos
por medio de ello se evaluara el problema, se estudiara el caso y se llegara a
una solución, para beneficio del departamento de Recursos Humanos y
Finanzas.
b) Se describen cada una de las técnicas de recolección de datos:
Observación pasiva: La observación pasiva se llevara a cabo sin que
las personas observadas participen, simplemente el investigador tomara
nota de lo que los clientes en este caso los responsables del
departamento de Recursos Humanos y Finanzas, digan en las
reuniones, para implementarlo a la programación de módulos del
sistema.
Reunión de grupos focales: Estas reuniones servirán para conocer el
avance del proyecto, igualmente nos ayudara a conocer los puntos de
vistas del cliente y las mejoras que se pueden hacer al sistema.
Es muy importante mencionar que la programación de los módulos del
sistema es clave fundamental para el desarrollo del sistema y con las
24
observaciones de las personas interesadas en el desarrollo del proyecto
se concretara aún mejor la programación del mismo, para beneficio del
departamento anteriormente mencionado. Además de realizar las
respectivas minutas de cada una de las reuniones que se realicen para
mantener el equilibrio de lo que se está realizando y darle continuidad a
las mejoras que se mencionen en dichas reuniones.
c) Para la elaboración de esta investigación se deben tomar en cuenta diversas
técnicas que actúan como medio para encontrar el problema principal y aplicar
una solución tomando en cuenta los pasos de la investigación mediante el cual
se conocerá de forma completa. Como se muestra en las siguientes fases:
1. Efectuar las minutas de reunión de grupos focales necesarias.
2. Realizar la observación pasiva y anotar toda la información que se
recapitulo.
3. Utilizar instrumentos de medición como grabación de video y audio en
caso de ser pertinente y necesario.
4. Una vez obtenidos los datos se realizara las modificaciones según los
requerimientos obtenidos en las minutas de reunión, con el fin de
identificar y priorizar las que sean más importantes.
5. Realizar conclusiones, en este se detallan los resultados finales así como
las recomendaciones.
De acuerdo al propósito de la investigación, las técnicas utilizadas como se
mencionan en el inciso anterior, la selección de los grupos focales son de gran
importancia para concentrar información necesaria de nuestro cliente como
también realizar un análisis y las observaciones pasivas son de igual manera
un punto importantísimo para recabar datos importantes que serán
determinantes para tener un informe unánime con conclusiones y
recomendaciones acertadas.
25
III.3 Definir el universo y el tamaño de muestra
El proyecto Firum se realizara en la universidad tecnológica de la selva, solicitando
información de las áreas de finanzas y recursos humanos, Secretario académico y
Abogado general, todo esto para poder obtener todos los requerimientos necesarios,
A continuación se presentan en tablas los involucrados mencionados anteriormente.
Tabla 1 Muestreo del universo.
Nombre
completo Cargo
Rol que
desempeña Descripción
Dr. Antonio
Magdiel
Velázquez
Secretario
Académico
Usuario
Los usuarios son las
personas que utilizaran el
sistema, para hacer los
registros que actualmente
realizan. Para tener un
mejor funcionalidad y
control del personal que
labora en la institución.
Dr. Mario
Domínguez
Muñoz
Director de
Admón. Y
Finanzas
C.P. Lázaro
Chong Palacios
Jefe de Dpto.
de personal
Lic. Carlos
Ángel Vázquez
Zenteno
Abogado
general
Ing. Adelita
Gutiérrez
Ramírez
Asistente del
área de
personal
Lic. José
Antonio Rojas
Hernández
Asistente
26
III.4 Recopilación de datos.
Uno de los métodos de recolección de datos a utilizar es el uso de observación pasiva,
esto es importante en una reunión con los clientes para obtener los requerimientos o
necesidades que ellos tengan, Anexo (Formato de observación), un ejemplo seria:
Figura 14 Plantilla de la observación pasiva.
Es muy importante mencionar que uno de los métodos para recolección de datos se
realizó mediante reuniones focales con los interesados del proyecto, tomando en
cuenta las evidencias necesarias (fotos, videos, observaciones), así como la
realización de minutas de reunión, un ejemplo:
Participantes para la reunión.
1. Participante 1
2. Participante 2
3. Participante 3
Puntos a tratar:
Punto 1.
Punto 2
Punto 3.
27
Figura 15 Plantilla de la minuta de reunión.
Con base a los métodos de recolección de datos a utilizar (observación y reuniones
focales), se obtuvo los requerimientos o necesidades que aporto el cliente con la
finalidad de desarrollar el proyecto FIRUM, Anexo (Reunión de presentación de
prototipos y con cliente).
28
CAPÍTULO IV. ANÁLISIS DE RESULTADOS Y DISCUSIÓN
De acuerdo a la recopilación de datos, durante el desarrollo de la investigación se tomaron en cuenta varios aspectos
(tiempo, conocimientos adquiridos) que ayudaron a tomar la mejor y más adecuada tecnología para el desarrollo del
proyecto FIRUM. A continuación se muestra en una tabla comparativa las diferentes tecnologías candidatas, para el
desarrollo del proyecto mediante sus características.
Tabla 2 Comparativa de las tecnologías candidatas.
Características de
acuerdo a
conocimientos
adquiridos
Tecnología para la programación del proyecto FIRUM.
Framework
Play Grails
Google Web
Toolkit Vaadin
Spring
Framework
JavaServer
Faces
Programación en java. x x x x x x
Entorno web para
facilitar la accesibilidad
al usuario final
x x x x x x
Compatibilidad con
diseño responsivo x x x x x x
Patrón de diseño (MVC) x x x
MYSQL x
.
29
Analizada la información de la tabla comparativa de las tecnologías para el desarrollo
del proyecto, se identificó, que las características de acuerdo a los conocimientos
adquiridos tuvieron un mismo enfoque, pero uno de los puntos más relevantes fue que
la mayoría de las tecnologías no usan MYSQL, esto puede ser una barrera, puesto
que todo se basa en tiempos y el avance del mismo podría ser afectado, porque se
tendría que conocer los SGBD(Sistema gestor de base de datos) o tecnologías como
No SQL.
De acuerdo a los requerimientos del cliente, el desarrollo rápido de los módulos es
muy importante, ya que se tiene planeado el proyecto bajo un cronograma de
actividades, tener una tecnología muy lenta para programar, se tendrá muchos riesgos
de cumplir las expectativas del mismo.
Otro punto es la velocidad con la que la tecnología responde en una petición del cliente,
por mencionar Java Server Faces es una framework que es muy robusto puesto que
la configuración por parte del modelo de la base de datos, modelo en JAVA y vista de
HTML son muchas y requiere de que si hay cambios por parte del cliente se tendrá
que configurar los antes mencionados y esto hace que el proyecto se muy pesado y
por supuesto al interactuar con el aplicación web será bastante lenta.
Al igual que esta tecnología, la mayoría usa demasiada configuración, es por eso que
la más conveniente para cumplir con los requerimientos del cliente y los conocimientos
que se tienen es Play Framework, porque se podrá trabajar con lo que se conoce
actualmente ahorrando tiempo, programación de módulos rápidamente y velocidad de
respuesta al momento que el cliente interactúe con la aplicación web.
Es importante mencionar que el orden de interacción del usuario con el sistema, se
programaron los mensajes de ayuda para que el usuario se familiarice rápidamente en
cuanto a la facilidad de uso del sistema. Se buscó métodos para que la estructura del
30
sistema tenga una mejor visualización siendo limpia y estratégica no solo en las
computadoras también en los dispositivos móviles, para tener una mejor navegación.
IV.1 Descripción del Caso de Uso
En el siguiente diagrama de uso se plasma la relación que el usuario podrá tener con
aplicación ya concluida.
Figura 16 Diagrama de caso de uso de la interfaz gráfica del sistema FIRUM.
31
Tabla 3 Autenticar el usuario.
Núm. De caso 001
Nombre de caso Autenticar el usuario
Actor Administrador
Descripción Es el proceso que sigue el administrador para ingresar a
la aplicación Firum
Precondición Tener cargada la base de datos
Flujo 1. Ingresar con su login y password
2. Ir a la ventana principal del sistema
3. Seleccionar una de las opciones que se muestran en la ventana principal
Post_Condición Si en caso de no pueda accesar intente nuevamente
Tabla 4 Mostrar Operaciones.
Núm. De caso 002
Nombre de caso Mostrar Opciones
Actor Administrador
Descripción Es el proceso que sigue el administrador para poder
visualizar las opciones del menú principal
Precondición Tener acceso al sistema
Flujo 1. Visualización del menú principal 2. Seleccionar un módulo para poder realizar las
operaciones que desee el administrador.
Post_Condición
32
Tabla 5 Búsqueda de la información.
Núm. De caso 003
Nombre de caso Búsqueda de información
Actor Administrador
Descripción Es el proceso que sigue el administrador para poder
buscar registros dentro de un módulo seleccionado.
Precondición Estar dentro de un módulo de la aplicación
Flujo 1. Ingresar datos correctamente en los filtros de búsqueda que contiene la aplicación.
2. Seleccionar el botón de Buscar para realizar el filtro.
Post_Condición Si en caso no realiza la búsqueda, revisar la conexión
con la base de datos.
Tabla 6 Agregar nuevos registros.
Núm. De caso 004
Nombre de caso Agregar nuevos registros
Actor Administrador
Descripción Es el proceso que sigue el administrador para poder
agregar registros dentro de un módulo seleccionado.
Precondición Estar dentro de un módulo de la aplicación
Flujo 1. Ingresar datos correctamente en los campos solicitados que contiene la aplicación.
2. Seleccionar el botón de Agregar para realizar el registro.
Post_Condición Si en caso no realiza la búsqueda, revisar la conexión con
la base de datos.
33
Tabla 7 Registros en Excel.
Núm. De caso 005
Nombre de caso Registros en Excel
Actor Administrador
Descripción Es el proceso que sigue el administrador para poder
importar registros dentro de un módulo seleccionado.
Precondición Estar dentro de un módulo de la aplicación
Flujo 1. Seleccionar el archivo que contendrá los registros, con la estructura correspondiente del módulo.
2. Seleccionar el botón de Importar para realizar el proceso.
Post_Condición Si en caso no realiza la búsqueda, revisar la conexión
con la base de datos y la estructura del archivo.
Tabla 8 Eliminar datos.
Núm. De caso 006
Nombre de caso Eliminar datos
Actor Administrador
Descripción Es el proceso que sigue el administrador para poder
eliminar registros dentro de un módulo seleccionado.
Precondición Estar dentro de un módulo de la aplicación
Flujo 1. Seleccionar el registro que desea eliminar correspondiente al módulo.
2. Seleccionar el botón de Eliminar (X) para realizar el proceso.
Post_Condición Si en caso no realiza la búsqueda, revisar la conexión
con la base de datos.
34
IV.2 Diagrama de interacción del sistema
El funcionamiento del sistema desarrollado con PlayFramework para el usuario y la
interacción que tendrá con el sistema se presenta un diagrama de las actividades, así
como la correlación, que el personal del área de Finanzas y Recursos Humanos podrá
realizar, ya sea desde una computadora o desde sus dispositivos móviles.
Figura 17 Diagrama de interacción del Sistema.
A: El usuario podrá ingresar al sistema con un nombre de usuario y una
contraseña.
B: EL usuario podrá visualizar las opciones de operaciones que el menú tendrá
y podrá ingresar en los módulos existentes del sistema para realizar las
operaciones que necesite hacer
C: EL usuario podrá realizar las operaciones necesarias para el modulo del
personal (Buscar, agregar, editar, eliminar, subir registros en EXCEL, Descargar
registros en PDF y EXCEL).
35
D: EL usuario podrá realizar las operaciones necesarias para el modulo del
Áreas y responsables (Buscar, agregar, editar, eliminar, subir registros en
EXCEL, Descargar registros en PDF y EXCEL).
E: EL usuario podrá realizar las operaciones necesarias para el modulo del
Tipos de contrato (Buscar, agregar, editar, eliminar, subir registros en EXCEL,
Descargar registros en PDF y EXCEL).
F: EL usuario podrá realizar las operaciones necesarias para el modulo del
Categorías y sueldo (Buscar, agregar, editar, eliminar, subir registros en
EXCEL, Descargar registros en PDF y EXCEL).
G: EL usuario podrá realizar las operaciones necesarias para el modulo del
Contrato del personal (Buscar, agregar, editar, eliminar, subir registros en
EXCEL, Descargar registros en PDF y EXCEL).
H: EL usuario podrá realizar las operaciones necesarias para el modulo del
Sindicatos (Buscar, agregar, editar, eliminar, subir registros en EXCEL,
Descargar registros en PDF y EXCEL).
I: EL usuario podrá realizar las operaciones necesarias para el modulo del
Agremiados a sindicatos (Buscar, agregar, editar, eliminar, subir registros en
EXCEL, Descargar registros en PDF y EXCEL).
J: EL usuario podrá realizar las operaciones necesarias para el modulo del
Horario de trabajo (Buscar, agregar, editar, eliminar, subir registros en EXCEL,
Descargar registros en PDF y EXCEL).
K: EL usuario podrá realizar las operaciones necesarias para el modulo del
Horarios especiales (Buscar, agregar, editar, eliminar, subir registros en
EXCEL, Descargar registros en PDF y EXCEL).
L: EL usuario podrá realizar las operaciones necesarias para el modulo del
Formatos de justificantes (Buscar, agregar, editar, eliminar, subir registros en
EXCEL, Descargar registros en PDF y EXCEL).
M: EL usuario podrá realizar las operaciones necesarias para el modulo del
Tipos de justificantes (Buscar, agregar, editar, eliminar, subir registros en
EXCEL, Descargar registros en PDF y EXCEL).
36
N: EL usuario podrá realizar las operaciones necesarias para el modulo del
Quincena (Periodo nómina) (Buscar, agregar, editar, eliminar, subir registros en
EXCEL, Descargar registros en PDF y EXCEL).
O: EL usuario podrá realizar las operaciones necesarias para el modulo del
Subsidio cuota DOF (Diario Oficial de la Federación) (Buscar, agregar, editar,
eliminar, subir registros en EXCEL, Descargar registros en PDF y EXCEL).
P: EL usuario podrá realizar las operaciones necesarias para el modulo del Tipo
de percepción y deducción (Buscar, agregar, editar, eliminar, subir registros en
EXCEL, Descargar registros en PDF y EXCEL).
Q: EL usuario podrá realizar las operaciones necesarias para el modulo del
Percepción y deducción por categoría (Buscar, agregar, editar, eliminar, subir
registros en EXCEL, Descargar registros en PDF y EXCEL).
R: EL usuario podrá realizar las operaciones necesarias para el modulo del
Percepción y deducción individual (Buscar, agregar, editar, eliminar, subir
registros en EXCEL, Descargar registros en PDF y EXCEL).
S: EL usuario podrá realizar las operaciones necesarias para el modulo del
Procesamiento nómina (Buscar, agregar, editar, eliminar, subir registros en
EXCEL, Descargar registros en PDF y EXCEL).
T: EL usuario podrá realizar las operaciones necesarias para el modulo del
Biométrico persona (Buscar, agregar, editar, eliminar, subir registros en EXCEL,
Descargar registros en PDF y EXCEL).
U: EL usuario podrá realizar las operaciones necesarias para el modulo del
Biométrico checado (Buscar, agregar, editar, eliminar, subir registros en
EXCEL, Descargar registros en PDF y EXCEL).
V: EL usuario podrá realizar las operaciones necesarias para el modulo del
Procesamiento de horarios (Buscar, agregar, editar, eliminar, subir registros en
EXCEL, Descargar registros en PDF y EXCEL).
37
IV.3 Arquitectura de la aplicación (MVC)
Una aplicación de Play sigue el patrón de arquitectura para aplicaciones web conocido
como MVC (Modelo-Vista-Controlador). Este patrón organiza la aplicación en capas
separadas: la capa de presentación y la capa del modelo. A su vez la capa de
presentación se divide en una capa de vista y otra de controlador.
Figura 18 Diagrama del Modelo-Vista-Controlador.
El Modelo es la representación de la información que es específica del dominio
de la aplicación. La lógica del dominio es la que agrega ‘significado’ a la
información, que de otra manera no serían más que datos. (ej. calcular si hoy
es el cumpleaños del usuario, o el importe, impuestos y cargos de envío de un
carrito de compras, de no ser por la lógica de dominio, éstos no serían más que
datos de tipo fecha y numérico sin ningún significado específico). Comúnmente
las aplicaciones utilizan algún mecanismo de almacenamiento persistente,
38
como una base de datos, para guardar la información. MVC no hace mención
específica a ninguna capa de acceso a datos, ya que se entiende que se
encuentra por debajo, o encapsulada en, el Modelo.
La Vista despliega la información del Modelo de manera apropiada para que el
usuario interactúe con ella, típicamente a través de una interfaz de usuario.
Múltiples vistas pueden existir para un único modelo, sirviendo diferentes
propósitos. En una aplicación web la vista es comúnmente desplegada en un
‘formato web’ como HTML, XML o JSON. Sin embargo hay casos en los cuales
la vista puede producir como resultados archivos binarios, por ejemplo en la
generación de diagramas u otros tipos de gráficos.
El Controlador responde a eventos (típicamente acciones generadas por el
usuario) y los procesa, también puede invocar cambios en el modelo, En una
aplicación web, los eventos son típicamente pedidos HTTP: un controlador
escucha estos pedidos HTTP, extrae la información relevante de este ‘evento’,
como pueden ser los parámetros del query string o request headers … y aplica
los cambios al modelo de objetos.
39
IV.4 Componentes de la aplicación
En una aplicación de Play las tres capas que son Modelo, Vista, Controlador se definen
en el directorio app, cada una en un package de Java distinto.
Figura 19 Componentes de la aplicación.
app/controllers: Un controlador es una clase de java en la cual cada método
público y estático es una acción o action method. Una acción es un punto de
entrada a una aplicación Java que es invocado cuando un pedido HTTP es
recibido. El código Java del controlador, en realidad no está orientado a objetos,
es meramente código procedural. El action method extrae la información
relevante del pedido HTTP, lee o actualiza el modelo de objetos, y retorna el
resultado bajo la forma de una respuesta HTTP.
app/models: La capa de modelo de objetos de dominio, es un conjunto de
clases de Java que hace uso de la orientación a objetos que provee el lenguaje
Java. Contiene estructuras de datos (estado) y operaciones (comportamiento)
sobre la cual opera la aplicación. En caso de que el modelo de objetos requiera
40
ser persistido a una base de datos, puede contener directivas como anotaciones
JPA o sentencias SQL.
app/views: La mayor parte de las vistas de una aplicación son generadas por
un eficiente motor de templates provisto por Play. El controlador obtiene la
información pertinente consultando la capa de datos, y luego aplica un template
para ‘decorar’ estos objetos. Esta capa contiene HTML, XML, JSON y otros
archivos de templates con directivas especiales para generar dinámicamente la
representación del modelo.
41
IV.5. Diagrama de la base de datos
En el siguiente diagrama se ilustra toda la relación de las tablas que utilice yo en la base de datos.
Figura 20 Entidad-Relación de la base de datos.
Nota: Los comentarios de la base de datos que muestren este son módulos creados por Jonatan Alcocer Zamora.
42
En el siguiente diagrama se ilustra las tablas relacionadas del sistema, que
representan los datos y tipos de datos para el funcionamiento de registros de
información, del personal y gestión de permisos justificantes, nóminas.
Figura 21 Entidad-Relación de horarios checados.
Nota: Los comentarios de la base de datos que muestren este son módulos
creados por Jonatan Alcocer Zamora.
J
43
Figura 22 Entidad-Relación de horarios planeados y justificantes.
Nota: Los comentarios de la base de datos que muestren este son módulos
creados por Jonatan Alcocer Zamora.
J
44
IV.6. Resultado de la aplicación desarrollada con PlayFramework
Como evidencia al usar la tecnología antes menciona se presentan estas imágenes,
Para dar a conocer el desarrollo de uno de los módulos del sistema, se presenta el
Menú principal donde se encuentran todos los módulos disponibles.
Figura 23 Vista principal de los módulos desarrollados.
45
Para dar a conocer el desarrollo de uno de los módulos del sistema, se presenta el
Módulo de “Personalhorariolectorusuario”, con los usuarios extraídos de la
importación de la base de datos de los lectores biométricos y con las operaciones
correspondientes que el usuario podrá realizar (buscar, asociar, importar registros en
ACCESS, Descargar registros en PDF y EXCEL).
Figura 24 Módulo de Personalhorariolectorusuario.
46
Se presenta el Módulo de “Personalhorariolectorusuario”, en la operación de
importar registros de ACCESS donde se buscara el archivo que se exporto de los
lectores biométricos y se importaran solamente los usuarios encontrados.
Figura 25 Módulo de Personalhorariolectorusuario-importar registros de ACCESS.
47
Se presenta el Módulo de “Personalhorariolectorusuario”, en la operación de
descargar registros en PDF donde se exportara todos los registros de dicho módulo.
Figura 26 Módulo de Personalhorariolectorusuario-descargar registros en PDF.
48
Se presenta el Módulo de “Personalhorariolectorchecado”, con los horarios
checados extraídos de la importación de la base de datos de los lectores biométricos
y con las operaciones correspondientes que el usuario podrá realizar (buscar, importar
registros en ACCESS, Descargar registros en PDF y EXCEL).
Figura 27 Módulo de Personalhorariolectorchecado.
49
Se presenta el Módulo de “Personalhorariolectorchecado”, en la operación de
importar registros de ACCESS donde se buscara el archivo que se exporto de los
lectores biométricos y se importaran solamente las fechas checadas por los usuarios
encontrados
Figura 28 Módulo de Personalhorariolectorchecado-importar registros de ACCESS.
50
Se presenta el Módulo “Personalhorariolectorchecado”, en la operación de
descargar registros en PDF todos los registros de cada usuario mostrando la fecha
y hora de checado que contiene dicho módulo.
Figura 29 Módulo de Personalhorariolectorchecado-descargar registros en PDF.
51
Se presenta el Módulo de “Personalhorariojustificante”, con los datos necesarios y
las operaciones correspondientes que el usuario podrá realizar (buscar, agregar,
importar registros en ACCESS, Descargar registros en PDF y EXCEL).
Figura 30 Módulo Personalhorariojustificante.
52
Se presenta el Módulo “Personalhorariojustificante”, en la operación de agregar un
justificante, mostrando los campos requeridos para su creación ya sea a individual o
grupal (Usuarios).
Figura 31 Módulo Personalhorariojustificante-agregar.
53
Se presenta el Módulo “Personalhorariojustificante”, en la operación de descargar
registros en PDF un justificante con toda la información necesaria ya sea a individual
o grupal (Usuarios).
Figura 32 Módulo Personalhorariojustificante-descargar registros en PDF.
54
CAPÍTULO V. CONCLUSIONES Y RECOMENDACIONES
V.1 Conclusiones
Al realizar la investigación para el proyecto FIRUM (Finanzas y Recursos Humanos)
en la Universidad Tecnológica de la Selva, fue de manera factible, el utilizar las
herramientas tecnológicas para poder solucionar, mejorar y optimizar los
procedimientos que se realizan en las áreas de Finanzas y Recursos Humanos.
Teniendo como resultados un sistema web funcional con los requerimientos
necesarios para llevarlo a producción, actualmente hay más validaciones y cambios
por parte del cliente, esto será tomado en cuenta en el mantenimiento del sistema
mencionado para dar otro mejor enfoque de calidad al servicio que brinda al personal
que labora en esta casa de estudios.
V.2 Recomendaciones
Es importante tomar en cuenta la información previa (marco teórico), el
planteamiento del problema y el análisis de la información, definen el inicio y fin
de la investigación.
Analizar el tipo de método (cualitativo, cuantitativo o mixto) para la metodología.
Verificar de acuerdo a la metodología a utilizar los métodos de recolección de
datos adecuados.
Verificar los tipos de datos de las tablas de la base de datos con las de los
modelos que sean idénticos.
55
CAPÍTULO VI. REFERENCIAS DOCUMENTALES
Asynchronous I/O. (05 de 01 de 2015). Obtenido de http://technet.microsoft.com/en-
us/library/hh997032.aspx
Collins-Sussman, B., & Fitzpatrick, B. a. (05 de 01 de 2015). Sistemas de control de versiones.
Obtenido de Sistemas de control de versiones: http://producingoss.com/es/vc.html
Fielding, R. T. (05 de 01 de 2015). RESTFUL. Obtenido de Chapter 5: Representational State
Transfer (REST)". Architectural Styles and the Design of Network-based Software
Architectures (Ph.D.). University of California, Irvine.:
http://en.wikipedia.org/wiki/Representational_state_transfer
Jordisan.net. (2006). Jordisan.net. Obtenido de http://jordisan.net/blog/2006/que-es-un-
framework
JSON. (05 de 01 de 2015). Obtenido de Using JSON with Yahoo! Web services:
http://es.wikipedia.org/wiki/JSON
Kemmis. (1984). La investigacion-acción critica.
Otto, M. (05 de 01 de 2015). Bootstrap. Obtenido de Bootstrap in A List Apart #342:
http://es.wikipedia.org/wiki/Twitter_Bootstrap
Playframework. (05 de 01 de 2015). Obtenido de Genbeta:dev, Desarrollo y software:
http://www.genbetadev.com/frameworks/introduccion-play-framework-2-parte-i-scala
Programming 4 us. (05 de 01 de 2015). Obtenido de TortoiseGit:
http://mscerts.programming4.us/es/722808.aspx
REST. (05 de 01 de 2015). Obtenido de
http://es.wikipedia.org/wiki/Representational_State_Transfer
Riehle, D. (. (05 de 01 de 2015). Framework. Obtenido de Framework Design: A Role Modeling
Approach: http://es.wikipedia.org/wiki/Framework
Scala. (05 de 01 de 2015). Obtenido de Genbeta:dev, Desarrollo y Software:
http://www.genbetadev.com/frameworks/introduccion-play-framework-2-parte-i-scala
The Netty Project Community. (2015). Netty. Obtenido de The Netty Project Community:
http://www.netty.io
56
The Reactive Manifesto, P. o. (05 de 01 de 2015). The Reactive Manifesto. Obtenido de
http://www.reactivemanifesto.org/
TortoiseGit. (s.f.). TortoiseGit. Obtenido de http://code.google.com/p/tortoisegit
Torvalds, L. (05 de 01 de 2015). Kernel SCM saga. Obtenido de http://git.kernel.org.
57
ANEXOS
Cronograma de actividades
Figura 33 Cronograma de actividades.
58
Reunión con el cliente
Figura 34 Presentación de prototipos.
Figura 35 Demostración de los módulos.
59
Evidencia de minuta de reunión de prototipos
Figura 36 Minuta de prototipos (1/5).
60
Figura 37 Minuta de prototipos (2/5).
61
Figura 38 Minuta de prototipos (3/5).
62
Figura 39 Minuta de prototipos (4/5).
63
Figura 40 Minuta de prototipos (5/5).
64
Evidencia de minuta de reunión, presentación con el cliente
Figura 41 Minuta de presentación funcional (1/4).
65
Figura 42 Minuta de presentación funcional (2/4).
66
Figura 43 Minuta de presentación funcional (3/4).
67
Figura 44 Minuta de presentación funcional (4/4).
68
Formato de observación
Figura 45 Formato de Observación pasiva.