tesina de ingeniería - tsu. jonatan alcocer zamora

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 41 Minuta de presentación funcional (1/4). .................................................... 64




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


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


agregar registros dentro de un módulo seleccionado.


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


importar registros dentro de un módulo seleccionado.


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.


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


eliminar registros dentro de un módulo seleccionado.


Flujo 1. Seleccionar el registro que desea eliminar correspondiente al módulo.

2. Seleccionar el botón de Eliminar (X) para realizar el proceso.


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


G: EL usuario podrá realizar las operaciones necesarias para el modulo del

Contrato del personal (Buscar, agregar, editar, eliminar, subir registros en


H: EL usuario podrá realizar las operaciones necesarias para el modulo del

Sindicatos (Buscar, agregar, editar, eliminar, subir registros en EXCEL,


I: EL usuario podrá realizar las operaciones necesarias para el modulo del

Agremiados a sindicatos (Buscar, agregar, editar, eliminar, subir registros en


J: EL usuario podrá realizar las operaciones necesarias para el modulo del

Horario de trabajo (Buscar, agregar, editar, eliminar, subir registros en EXCEL,


K: EL usuario podrá realizar las operaciones necesarias para el modulo del

Horarios especiales (Buscar, agregar, editar, eliminar, subir registros en


L: EL usuario podrá realizar las operaciones necesarias para el modulo del

Formatos de justificantes (Buscar, agregar, editar, eliminar, subir registros en


M: EL usuario podrá realizar las operaciones necesarias para el modulo del

Tipos de justificantes (Buscar, agregar, editar, eliminar, subir registros en


36

N: EL usuario podrá realizar las operaciones necesarias para el modulo del

Quincena (Periodo nómina) (Buscar, agregar, editar, eliminar, subir registros en


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


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


T: EL usuario podrá realizar las operaciones necesarias para el modulo del

Biométrico persona (Buscar, agregar, editar, eliminar, subir registros en EXCEL,


U: EL usuario podrá realizar las operaciones necesarias para el modulo del

Biométrico checado (Buscar, agregar, editar, eliminar, subir registros en


V: EL usuario podrá realizar las operaciones necesarias para el modulo del

Procesamiento de horarios (Buscar, agregar, editar, eliminar, subir registros en


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


61


62


63


64

Evidencia de minuta de reunión, presentación con el cliente

Figura 41 Minuta de presentación funcional (1/4).

65


66


67


68

Formato de observación

Figura 45 Formato de Observación pasiva.

tesina de ingeniería - tsu. jonatan alcocer zamora

Documents