sistema de monitoreo de juicios laborales

DIVISIÓNDEESTUDIOSDEPOSGRADOEINVESTIGACIÓN

SISTEMADEMONITOREODE

JUICIOSLABORALES

TESIS

QUEPARAOBTENERELGRADODE

MAESTROENSISTEMASCOMPUTACIONALES

PRESENTA:ING.GABRIELLÓPEZSÁNCHEZ

DIRECTORADETESIS:MTRA.RAMONAEVELIACHÁVEZVALDEZ

CO-DIRECTORA:DRA.PATRICIAELIZABETHFIGUEROAMILLÁN

VILLADEALVAREZ,COLIMA.DICIEMBRE2018.

Sistema de Monitoreo de Juicios Laborales

1


2

Epígrafe “Si no conozco una cosa, la investigaré”. --Louis Pasteur

“Investigar es ver lo que todo el mundo ha visto, y pensar lo que nadie más ha pensado”. --Albert Szent-Györgyi

“La educación científica de los jóvenes es al menos tan importante, quizá incluso más, que la propia investigación”. --Glenn Theodore Seaborg

"Si la industria automovilística hubiera seguido el mismo desarrollo que los ordenadores, un Rolls-Royce costaría hoy 100 dólares, circularía un millón de millas con 3,7 litros y explotaría una vez al año, eliminando a todo el que estuviera dentro en ese momento". -- Robert X. Cringely.

"No se trata bits, bytes y protocolos, sino de beneficios, pérdidas y márgenes". -- Lou Gerstner

"La función de un buen software es hacer que lo complejo aparente ser simple". -- Grady Booch

"Medir el progreso del desarrollo de software por líneas de código es como medir el progreso de la construcción de un avión por su peso". -- Bill Gates

"Primero resuelve el problema. Entonces, escribe el código". -- John Johnson

"Los buenos programadores usan sus cerebros, pero unas buenas directrices nos ahorran de tener que hacerlo en cada caso". -- Francis Glassborow


3

Dedicatoria Dedico esta tesis a mi familia.

A mi mamá, quien dedicó tiempo y esfuerzo en apoyarme en la decisión de estudiar un

posgrado.

A mis hermanas, quienes me impulsaban a siempre seguir sin importar nada.

A mis amigos, quienes me apoyaron en todo cuanto pudieron.


4

Agradecimientos Agradezco a mi familia por apoyarme en mi decisión de estudiar un posgrado; a mis amigos

por su apoyo intelectual y emocional para el desarrollo de este trabajo de investigación.

Agradezco a la dirección del posgrado en sistemas computacionales en el Tecnológico

Nacional de México campus Instituto Tecnológico de Colima y a mis maestros por brindarme

las herramientas para el desarrollo de este proyecto.

En especial al CONACYT por mantener el Programa Nacional de Posgrado de Calidad e

incentivar la formación en maestrías y doctorados, mediante el programa de Becas; al

Tecnológico Nacional de México campus Instituto Tecnológico de Colima por ocuparse de

la formación de capital humano que brinde soluciones informáticas al sector productivo,

gubernamental y de servicios en la región.


5

Resumen En esta investigación se desarrolló un sistema de información denominado Sistema de

Monitoreo de Juicios Laborales (SMJL), el cual permite a las Juntas Locales de Conciliación

y Arbitraje optimizar los procesos de administración de la información, creando un punto de

colaboración para los involucrados en la resolución de los juicios laborales.

Para el análisis de éste, se realizaron entrevistas semiestructuradas con los involucrados en

el proceso; mientras que, para el desarrollo del sistema se empleó la metodología Kanban

hasta su implementación en la Junta Local por su facilidad para distribuir el trabajo entre los

miembros del equipo, así como evaluar el tiempo y esfuerzo requerido para las tareas,

siguiendo una arquitectura cliente servidor. El cliente se desarrolló empleando el framework

Angular 5 con Bootstrap 4; mientras que, para el servidor se empleó Node.js con el

framework Express, considerando buenas prácticas de usabilidad para lograr una mejor

interacción de los usuarios con el sistema. Además, se aplicó un enfoque innovador

considerando las herramientas y técnicas necesarias para ofrecer servicio de impartición de

justicia en medios electrónicos (e-justicia), mejorando así la calidad de los servicios que se

ofrecen a la población y facilitando las actividades del capital humado de esta dependencia.

El sistema SMJL es una contribución al sector gubernamental y social que innova en el

ámbito de justicia laboral, lleva un registro histórico de los estados del juicio laboral,

proporcionando una alta disponibilidad de los archivos que acompañan cada una de las

demandas, permitiendo aplicar filtros de búsqueda por nombre de los archivos y por fecha de

creación para una rápida consulta.


6

Abstract In this research, an information system was developed that allows the Local Conciliation

and Arbitration Boards to optimize the information management processes, creating a point

of collaboration for those involved in the resolution of labor lawsuits.

For the analysis of this, semi-structured interviews were conducted with those involved in

the process; while, for development, the Kanban methodology was used until its

implementation in the Local Board, for its facility to distribute the work among the members

of the team, as well as to evaluate the time and effort required for the tasks, following a client

server architecture. The client was developed using the Angular 5 framework with Bootstrap

4; while, for the server Node.js was used with the Express framework, considering good

usability practices to achieve a better interaction of the users with the system. In addition,

an innovative approach was applied considering the tools and techniques necessary to offer

a service of Electronic Justice (e-justice), improving the quality of the services offered to the

population and facilitate the activities of human capital of this dependence.

The SMJL system is a contribution to the governmental and social sector that innovates in

the area of labor justice, keeps a historical record of the labor lawsuits states, providing a

high availability of the files that accompany each of the demands, allowing to implement of

search filters by name of the files and by date of creation for a quick consultation.


7

Índice General

EPÍGRAFE --------------------------------------------------------------------------------------------------------- 1

DEDICATORIA -------------------------------------------------------------------------------------------------- 3

AGRADECIMIENTOS ----------------------------------------------------------------------------------------- 4

RESUMEN --------------------------------------------------------------------------------------------------------- 5

ABSTRACT -------------------------------------------------------------------------------------------------------- 6

ÍNDICE GENERAL---------------------------------------------------------------------------------------------- 7

ÍNDICE DE FIGURAS ------------------------------------------------------------------------------------------ 9

1. INTRODUCCIÓN ------------------------------------------------------------------------------------------- 12

1.1 LA NATURALEZA DEL PROBLEMA ---------------------------------------------------------------------- 12 1.2 EL CONTEXTO DEL PROBLEMA ------------------------------------------------------------------------- 13 1.3 REVISIÓN DE LA LITERATURA -------------------------------------------------------------------------- 14

1.3.1 Sistema Automatizado para el Seguimiento de Procesos Judiciales en un Estudio de Abogados ---------------------------------------------------------------------------------------------------- 14 1.3.2 Sistema Inteligente de Búsqueda de Expedientes Judiciales basado en Web Semántica para Consultorios Jurídicos ----------------------------------------------------------------------------- 16

1.4 PLANTEAMIENTO DE LA SOLUCIÓN DEL PROBLEMA A INVESTIGAR ------------------------------ 17 1.5 JUSTIFICACIÓN -------------------------------------------------------------------------------------------- 18 1.6 MOTIVACIÓN ---------------------------------------------------------------------------------------------- 19 1.7 OBJETIVOS ------------------------------------------------------------------------------------------------- 19 1.8 METAS ------------------------------------------------------------------------------------------------------ 20 1.9 HIPÓTESIS -------------------------------------------------------------------------------------------------- 20 1.10 DESCRIPCIÓN DE LOS MÉTODOS EMPLEADOS ------------------------------------------------------- 20 1.11 ORGANIZACIÓN DEL DOCUMENTO-------------------------------------------------------------------- 20

2. ESTADO DEL CAMPO DEL CONOCIMIENTO -------------------------------------------------- 22

2.1 MARCO HISTÓRICO --------------------------------------------------------------------------------------- 22 2.2 MARCO CONTEXTUAL ------------------------------------------------------------------------------------ 24 2.3 MARCO TEÓRICO ------------------------------------------------------------------------------------------ 27

2.3.1 Trazabilidad ----------------------------------------------------------------------------------------- 27 2.3.2 Aplicaciones Web ----------------------------------------------------------------------------------- 28

2.3.2.1 Arquitectura de una aplicación web -------------------------------------------------------- 30 2.3.3 Kanban ----------------------------------------------------------------------------------------------- 31 2.3.4 Modelo-Vista-Controlador (MVC) --------------------------------------------------------------- 32 2.3.4 Node.Js ----------------------------------------------------------------------------------------------- 33

2.3.3.1 Concurrencia ----------------------------------------------------------------------------------- 34 2.3.3.2 Módulos ---------------------------------------------------------------------------------------- 34

2.3.5 Express ----------------------------------------------------------------------------------------------- 35 2.3.6 Framework Angular -------------------------------------------------------------------------------- 35

3. MÉTODOS EMPLEADOS -------------------------------------------------------------------------------- 36

3.1 METODOLOGÍA -------------------------------------------------------------------------------------------- 36 3.2 INGENIERÍA DE SOFTWARE ------------------------------------------------------------------------------ 37 3.3 TECNOLOGÍAS DE DESARROLLO WEB UTILIZADAS-------------------------------------------------- 38

4. DESARROLLO DE LA PROPUESTA ----------------------------------------------------------------- 41


8

4.1 RECOPILACIÓN DE INFORMACIÓN ---------------------------------------------------------------------- 41 4.2 HISTORIAS DE USUARIO PRIORIZADAS ---------------------------------------------------------------- 46 4.3 IMPLEMENTACIÓN ---------------------------------------------------------------------------------------- 48

4.3.1 Implementación de las historias de usuario ---------------------------------------------------- 49 4.3.1.1 Historia de usuario<<Registrar demanda>> ---------------------------------------------- 50 4.3.1.2 Historia de usuario<<Registrar documentos>> ------------------------------------------ 53 4.3.1.3 Historia de usuario <<Registrar Cambio de estado de las demandas>> -------------- 56 4.3.1.4 Historia de usuario<<Registrar audiencia>> --------------------------------------------- 58 4.3.1.5 Historia de usuario<<Limitar visualización de información por rol>> --------------- 61

4.4 EL MODELO DE DATOS DEL SMJL --------------------------------------------------------------------- 63 4.4 DIAGRAMA DE WARNIER -------------------------------------------------------------------------------- 64 4.5 DIAGRAMA DE NAVEGACIÓN --------------------------------------------------------------------------- 65 4.6 DIAGRAMA DE COMPONENTES ------------------------------------------------------------------------- 66

5. RESULTADOS ------------------------------------------------------------------------------------------- 68

6. CONCLUSIONES ------------------------------------------------------------------------------------------- 80

FUENTES DE INFORMACIÓN ---------------------------------------------------------------------------- 82


9

ÍNDICE DE FIGURAS

Figura 1. Modelo Conceptual del SMJL. ____________________________________________ 17 Figura 2 Actores en los juicios laborales ____________________________________________ 36 Figura 3. Tablero Kanban del SMJL ________________________________________________ 38 Figura 4 Diagrama de actividades Oficialía__________________________________________ 42 Figura 5 Diagrama de Actividades Radicaciones ______________________________________ 43 Figura 6 Diagrama de actividades Mesa ____________________________________________ 44 Figura 7 Diagrama de actividades Proyectista________________________________________ 45 Figura 8 Diagrama de actividades Actuario __________________________________________ 45 Figura 9 Arquitectura de implementación ___________________________________________ 49 Figura 10. Tablas para registrar demanda. __________________________________________ 50 Figura 11. Diseño de interfaz para registrar demanda. _________________________________ 50 Figura 12. Fragmento de vista registrar demanda. ____________________________________ 51 Figura 13. Fragmento modelo para registrar una demanda. _____________________________ 51 Figura 14. Fragmento de controlador registrar demanda. _______________________________ 52 Figura 15 Tablas para registrar documento __________________________________________ 53 Figura 16. Diseño de interfaz para registrar documento. ________________________________ 53 Figura 17. Fragmento de vista registrar documento. ___________________________________ 54 Figura 18. Fragmento modelo para registrar documento. _______________________________ 54 Figura 19. Fragmento de controlador registrar documento. _____________________________ 55 Figura 20. Tablas para cambio de estado de las demandas. _____________________________ 56 Figura 21. Diseño de interfaz para cambio de estado de las demanda. _____________________ 56 Figura 22. Fragmento de vista cambio de estado de la demanda. _________________________ 57 Figura 23. Fragmento modelo cambio de estado de la demanda. _________________________ 57 Figura 24. Fragmento de controlador cambio de estado de la demanda. ___________________ 57 Figura 25. Tablas para registrar audiencias _________________________________________ 58 Figura 26. Diseño de interfaz para registrar audiencia. ________________________________ 59 Figura 27. Fragmento de vista registrar audiencia. ____________________________________ 59 Figura 28. Fragmento modelo registrar audiencia. ____________________________________ 60 Figura 29. Fragmento de controlador registrar audiencia.. ______________________________ 60 Figura 30. Limitar visualización de información por rol. ________________________________ 61 Figura 31. Diseño de interfaz limitar visualización de información por rol. _________________ 61 Figura 32. Fragmento de vista limitar visualización de información por rol. ________________ 62 Figura 33. Fragmento modelo limitar visualización de información por rol. ________________ 62 Figura 34. Fragmento de controlador limitar visualización de información por rol. __________ 63 Figura 35. Modelo de datos. ______________________________________________________ 64 Figura 36. Diagrama de Warnier. __________________________________________________ 65 Figura 37. Diagrama de Navegación. _______________________________________________ 66 Figura 38. Diagrama de componentes. ______________________________________________ 67 Figura 39. Pantalla de inicio de sesión. _____________________________________________ 68 Figura 40. Pantalla registrar usuarios. _____________________________________________ 69 Figura 41. Pantalla modificar usuario. ______________________________________________ 69 Figura 42. Pantalla agregar mesa. _________________________________________________ 70 Figura 43. Pantalla modificar mesa. ________________________________________________ 70 Figura 44. Pantalla registrar actores. ______________________________________________ 71 Figura 45. Pantalla modificar actores. ______________________________________________ 71 Figura 46. Pantalla agregar demandado. ____________________________________________ 72 Figura 47. Pantalla modificar demandado. __________________________________________ 72 Figura 48. Pantalla agregar demanda. ______________________________________________ 73


10

Figura 49. Pantalla modificar demanda. ____________________________________________ 74 Figura 50. Pantalla agregar audiencia. _____________________________________________ 75 Figura 51. Pantalla modificar audiencia. ____________________________________________ 75 Figura 52. Pantalla audiencias programadas. ________________________________________ 76 Figura 53. Pantalla agregar comisión. ______________________________________________ 77 Figura 54. Pantalla modificar comisión. ____________________________________________ 77 Figura 55. Pantalla modificar permisos. ____________________________________________ 78 Figura 56. Pantalla historico de la demanda. _________________________________________ 78


11

Índice de Tablas Tabla 1 Historias de usuario del SMJL ......................................................................................... 46 Tabla 2. Datos de Prueba registrar demanda. .............................................................................. 52 Tabla 3 Datos de prueba registrar documento .............................................................................. 55 Tabla 4 Datos de prueba cambio de estado de la demanda ........................................................... 58 Tabla 5 Datos pruebas registrar audiencia................................................................................... 60 Tabla 6 Datos de prueba limitar visualización de información por rol .......................................... 63


12

1. Introducción

1.1 La naturaleza del problema

Los juicios laborales tienen como propósito llevar justicia tanto a empleadores como a

empleados, de acuerdo con lo establecido en la (Ley Federal del Trabajo, 1970); estos juicios

laborales son administrados por el poder ejecutivo a nivel estatal, en la Dirección del Trabajo

a través de las Juntas Locales de Conciliación y Arbitraje (JLCA). Dichas juntas están

conformadas por una administración tripartita: el presidente, el representante obrero y el

representante patronal, quienes juntos conforman el Pleno de la junta y serán quienes

dictaminen el laudo o la resolución del juicio. Además de los dictámenes de laudo, el Pleno

es quién radica las demandas y autoriza los acuerdos a los que puedan llegar las partes durante

el proceso.

Los autores (Middlebrook & Ramirez, 1998) declaran que las juntas tripartitas de

conciliación y arbitraje desempeñan un papel especialmente relevante en el sistema mexicano

de justicia laboral, aun cuando éstas no tienen injerencia en asuntos como las disputas en el

interior de un sindicato.

Actualmente, el seguimiento de los juicios laborales se lleva en hojas de papel y documentos

de Excel, lo cual es poco práctico para la consulta del estado y de los documentos asociados

al juicio; en situaciones donde se desconoce el estado específico de una demanda en curso,

el realizar la consulta de un expediente requiere al empleado que invierta en promedio más

de una jornada laboral, lo cual representa una merma en la productividad de la junta; si por

un error administrativo se omite agregar algún documento que de origen al cambio de estado

en el expediente, entonces se presenta una inconsistencia en el mismo, y toma más tiempo

corroborar con todos los actores que fue lo ocurrido; por lo tanto, se detiene el flujo normal

del juicio y se incrementa el tiempo en la resolución.

Para solventar esa problemática el autor (Contreras, 2012), menciona que “En esencia, hay

una tendencia generalizada a ir incorporando el apoyo de las Tecnologías de Información y

Comunicación (TIC) en la operación jurisdiccional con distintas modalidades. La

introducción de las TIC en la administración de justicia en general tiende a ser parcial,


13

experimental y gradual. Principalmente, los expedientes casi invariablemente siguen siendo

físicos, con promociones y acuerdos autentificados en papel, complementados con apoyos

electrónicos para consultar a distancia reproducciones digitalizadas parciales o totales de los

mismos”. Por otro lado (Melitski & Calista, 2016) comentan que “la literatura pertinente

asume que las jurisdicciones deben ir mejorando continuamente el gobierno digital, a través

de la oferta de mejor atención al cliente y dando más oportunidades para que los ciudadanos

se involucren”.

1.2 El contexto del problema

Actualmente el uso de TICs en las actividades cotidianas se incrementa cada vez más, con

base en la Encuesta Nacional sobre Disponibilidad y Uso de Tecnologías de la Información

en los Hogares (INEGI, 2017); como se muestra en la Grafica 1, al segundo trimestre se

registraron 65.5 millones de personas de seis años o más en el país, usuarias de los servicios

que ofrece Internet, lo que representa el 59.5 por ciento de esta población. Esto significa un

incremento del 2.1% con respecto a 2015.

Grafica 1. Población según condición de uso de Internet. Fuente: INEGI, 2016.

En la actualidad existen algunos sistemas similares para el seguimiento de juicios, pero de

otras dependencias, tales como en el Tribunal Federal de Justicia Administrativa, el cual se

encarga de dirimir las controversias jurídicas que se susciten entre la Administración Pública

Federal y los particulares.


14

(Supo & Araujo, 2015) describen un sistema para el seguimiento de los documentos para los

distintos tipos de juicios del Consultorio Jurídico Díaz Pulido en la república de Perú, éstos

hablan las de las deficiencias de tiempo y calidad del servicio que se presentan en la búsqueda

de expedientes judiciales, al realizarlo de forma manual; ellos proponen el desarrollo de un

sistema inteligente de búsqueda basada en web semántica.

(Bayona & Sánchez, 2008) plantean el desarrollo de un sistema para la mejora de la gestión

y el seguimiento de los procesos judiciales en la institución “Estudió Morales Godo y

Asociados” en Perú, marca algunos de los problemas dentro del proceso, tales como el

desperdicio del recurso tiempo en la búsqueda de los expedientes para su consulta, pruebas

y documentación referente al caso, la ausencia de control y programación en las actividades

de los abogados; todo esto a través de un sistema de información de escritorio.

1.3 Revisión de la literatura

La revisión de la literatura muestra la evolución que han tenido los sistemas para el

seguimiento de procesos jurídicos, tanto a nivel internacional como nacional. En las

siguientes secciones se presenta un análisis de estos sistemas.

1.3.1 Sistema Automatizado para el Seguimiento de Procesos Judiciales en un Estudio de Abogados

(Bayona & Sánchez, 2008) comentan sobre el desarrollo de un sistema automatizado que

controle la gestión y seguimiento de los procesos judiciales en un estudio de abogados. Ellos

realizan su investigación en el estudio de abogados “Morales Godo y Asociados”, localizado

en la ciudad de Lima, Perú; también mencionan que algunos de los problemas detectados

durante la gestión y seguimiento de los procesos judiciales son:

● No brindar información oportuna y rápida a los clientes sobre la situación actual y

desarrollo de su caso en el proceso judicial.

● Pérdida de tiempo en la ubicación de los expedientes, pruebas y documentación

asociada a un caso.

● Falta de control y programación en las actividades de los abogados.


15

● Pérdida de tiempo en la búsqueda de información histórica asociada a un expediente.

● No tener un recordatorio de los procedimientos a realizar en la gestión de un caso.

● Pérdida de tiempo en consultar un expediente puesto que se tiene que revisar en los

sistemas manuales de información.

● No dar soporte a la toma de decisiones al momento del seguimiento de un caso en el

proceso judicial.

Los beneficios que proponen con su desarrollo son:

● Mejora en la calidad de las solicitudes de atención que se registran porque el sistema

proporciona los requisitos de documentación necesarios de acuerdo con el tipo de

proceso judicial.

● Ahorro de tiempo en la evaluación de las solicitudes de atención para el inicio de un

proceso judicial debido a que se tiene registrada la información en el sistema

propuesto.

● Mejora en el tiempo de registro y apertura de los expedientes judiciales porque el

sistema sugiere los procedimientos necesarios según el tipo de proceso judicial.

● Ahorro de tiempo en la búsqueda de información histórica de procesos judiciales

anteriores.

● Programación detallada y oportuna de las acciones a seguir en los procesos judiciales.

● Ahorro de tiempo del personal en la búsqueda de expedientes judiciales.

● Mejora de la calidad en la atención a los clientes, brindando información oportuna

sobre el desarrollo de un proceso judicial.

Este sistema está desarrollado para escritorio, por lo que limita los procesos de consultas de

información dentro de las oficinas, e incrementa el tiempo que se requiere para agregar

nuevos equipos con acceso al sistema, ya que requieren instalación del software y

configuración para las respectivas conexiones.

Otra de las limitaciones de desarrollar un sistema para escritorio, es que cuando uno o más

paquetes necesarios para el funcionamiento de este quedan obsoleto, se vuelve complicado

instalarlo en equipos nuevos.


16

1.3.2 Sistema Inteligente de Búsqueda de Expedientes Judiciales basado en Web Semántica para Consultorios Jurídicos

Los autores (Supo & Araujo, 2015) mencionan que la mayor parte de estudios jurídicos en

el Perú tiene un problema, el tiempo que emplean en localizar sus expedientes judiciales entre

sus archivos.

Afirman que para solucionar esta problemática requerían modelar los procesos principales

del Estudio Jurídico Díaz Pulido, con el fin de entender cómo funciona realmente el

desarrollo de sus actividades; a partir del cual plantearon un prototipo de sistema inteligente

de búsqueda que utilice el lenguaje natural de las personas para establecer parámetros de

búsqueda, apoyándose en la metodología Methontology para realizar esta conversión.

Durante la fase de análisis encontraron las siguientes deficiencias:

● Tiempo: actualmente el estudio jurídico presenta demoras en la búsqueda de los

documentos, ya que cada uno de estos representa a un cliente y en algunos casos

existe más de un expediente porque puede llevar más de un proceso judicial a la vez,

esta actividad puede tardar de veinte minutos a varias horas.

● Servicio Deficiente: al no tener los documentos de manera ordenada y de fácil acceso,

eso influirá en el manejo de los servicios hacia sus clientes, ya que tienen que hacer

las mencionadas búsquedas cada vez que un cliente hace una consulta sobre el

progreso de su caso.

Las tecnologías que utilizaron para el desarrollo del prototipo fueron:

● MongoDB: para la base de datos.

● Zend Framework: como base para el desarrollo de la aplicación, este basado en PHP5

La mayor limitación del sistema es el uso de MongoDB, por sus características no es factible

utilizarlo con grandes volúmenes de datos, ya que entre más información este almacenando

la cantidad de memoria RAM requerida crece exponencialmente.


17

1.4 Planteamiento de la solución del problema a investigar

Considerando las áreas de oportunidad identificadas en las investigaciones previas y a las

necesidades identificadas como resultado del trabajo de investigación de campo realizado a

través de las entrevistas semiestructuradas en la Junta Local de Conciliación y Arbitraje en

el estado de Colima, se propone la creación del Sistema de Monitoreo de Juicios Laborales

(SMJL) que describe la Figura 1 ; el usuario del sistema, en principio un miembro de la junta

con el rol de oficialía, recibe y registra una demanda, adjuntándole los documentos básicos

requeridos, una vez validada la turna a radicaciones para su aceptación o cancelación; se

notifica al demandado, quien también puede ver la demanda en línea y el expediente que se

va integrando; el personal la turna con el funcionario correspondiente. Los miembros de la

junta son quienes usan la aplicación cliente del sistema para gestionar información mediante

un servidor API que interactúa con la base de datos y el servidor de archivos, este último

contiene las promociones o documentos que acompañan la demanda.

Figura 1. Modelo Conceptual del SMJL.


18

Los usuarios del sistema son quienes tienen contacto directo con el sistema, estos registran y

consultan las demandas y todos sus documentos relacionados; a través de un equipo dentro

de la junta se accede al cliente de la aplicación, el cliente realiza consultas hacia la API; el

API maneja los accesos y la manipulación de la información y los documentos; el manejo de

los documentos se maneja en un servidor separado al de base de datos, para reducir los

tiempos de consulta.

La solución propuesta, ha permitido a la junta en general y en particular al pleno, tener una

visión general sobre el estado de las demandas; actualmente, son los demandantes los que

activan una demanda cuando queda en espera de avanzar en el proceso. Respecto a soluciones

previas, la solución propuesta utiliza nuevas tecnologías de desarrollo web, mejorando los

sistemas antes citados y haciendo énfasis en una mejor usabilidad y mejor visualización en

los distintos navegadores y dispositivos; capaz de llevar un registro del procedimiento a

seguir en los juicios y de los documentos asociados a éstos, denotado en la Ley Federal del

Trabajo (1970).

1.5 Justificación

El uso de las TIC se ha ido incrementando dentro de las actividades que realizamos

cotidianamente, desde las comunicaciones hasta los trámites gubernamentales, de aquí nace

el término E-Justicia, los autores (Melitski & Calista, 2016) lo definen como justicia

digitalizada y consideran que: “La literatura pertinente asume que las jurisdicciones deben

ir mejorando continuamente el gobierno digital, a través de la oferta de mejor atención al

cliente y dando más oportunidades para que los ciudadanos se involucren”.

Esta mejora en el proceso brinda un seguimiento más eficiente y una mejor transparencia de

los procesos públicos y permite darles un seguimiento más minucioso. La solución también

permite una mejor comunicación con los actores, demandados y los miembros de la junta. La

capacidad de verificar el estado de un caso en cualquier momento provoca una reducción en

los tiempos necesarios para realizar un trámite. Esta modificación en los servicios permite


19

que los ciudadanos puedan involucrarse en las etapas de los procesos judiciales para la toma

de decisiones.

1.6 Motivación

La motivación para realizar este desarrollo tecnológico ha sido la experiencia en casos de

juicios laborales de personas cercanas, quienes tienen impactos en su calidad de vida

personal, familiar y económica por el tiempo que invierten en dar seguimiento a los procesos

que interponen en virtud de que los procesos son largos y les demandan atención continua;

se considera que será un gran aporte a la sociedad ya que ahorrará tiempo y recursos tanto a

los empleados de los organismos judiciales como a los ciudadanos y en lo personal ha sido

el medio para formarme como Maestro en Sistemas Computacionales.

1.7 Objetivos

Objetivo general:

Desarrollar un Sistema de Monitoreo de Juicios Laborales (SMJL) que lleve el registro

histórico de los expedientes legales, para dar seguimiento oportuno a las actividades

implícitas en la atención de las demandas laborales.

Objetivos particulares:

● Investigar las etapas de los juicios laborales declarados en la Ley Federal del

Trabajo.

● Elaborar el diagrama del proceso actual de los juicios laborales.

● Identificar los actores que intervienen en el proceso de los juicios laborales.

● Investigar las bases de usabilidad.

● Diseñar y desarrollar las interfaces para el usuario.

● Realizar pruebas de usabilidad de los usuarios sobre las interfaces.

● Implementar las interfaces con la estructura de los datos.

● Realizar pruebas de usabilidad completa del sistema.

● Presentar los resultados.


20

1.8 Metas

Antes del mes de junio de 2018:

● Operar el sistema con el 100% de sus funcionalidades, en la Junta de Conciliación

y Arbitraje en la ciudad de Colima.

● Capacitar el 100% de los usuarios internos del sistema.

● Medir el impacto del sistema propuesto con relación al uso del sistema anterior

respecto a la variable tiempo, en cada uno de los roles.

1.9 Hipótesis

El desarrollo de sistemas de información con características web para el monitoreo de los

juicios laborales promueve la impartición de justicia electrónica, reduciendo los tiempos de

procesamiento, consulta y resolución de los mismos.

1.10 Descripción de los métodos empleados

Esta investigación aplicada se apoyó en investigación documental y de campo para dar

soporte a la solución propuesta; la primera facilitó la información jurídica respecto a los

procesos de justicia laboral y la segunda permitió conocer cómo se operan los procesos en

las JLCA del estado. Por otro lado, para desarrollar el sistema de información se utilizó la

metodología Kanban por su precisión para marcar qué actividades se deben hacer, y cuándo

se necesitan hacer, mediante la asignación de prioridades a las tareas, flujo de trabajo y el

tiempo de espera hasta la entrega (Lei, Ganjeizadeh, Jayachandran, & Ozcan, 2017).

1.11 Organización del documento

El capítulo uno del presente documento describe la información que plantea las bases para el

desarrollo de la tesis y de este modo entender el problema para encontrar la solución más

viable y factible que se adecue al proyecto.


21

El capítulo dos enfatiza la teoría de la investigación, esto quiere decir qué herramientas,

modelos, tecnologías, metodologías se utilizarán para cumplir con el desarrollo del proyecto

y de la investigación, al mismo tiempo que se cumplen los objetivos planteados en el capítulo

uno.

El capítulo tres describe el cronograma de actividades así mismo como las metodologías

utilizadas para la realización de una metodología híbrida que tome los elementos más

importantes y permita ser utilizada en proyectos de desarrollo de software a pequeña y

mediana escala.

En el capítulo cuatro muestra el desarrollo de la investigación, para el cual se realizó un

análisis de la problemática y así encontrar una solución que sea factible. Este capítulo

también incluye el diseño y modelado de la información en forma de diagramas y esquemas

para una mejor comprensión del problema que se intenta resolver.

El capítulo cinco presenta los resultados obtenidos del proceso de desarrollo del sistema para

el seguimiento de los juicios laborales.

Por último, el capítulo seis describe las conclusiones a las que se llegó una vez finalizada la

investigación y el desarrollo del sistema.


22

2. Estado del campo del conocimiento

2.1 Marco histórico

Las tecnologías de información y comunicación muestran avances significativos y

disruptivos. (Chaniotis, Kyriakou, & Tselikas, 2015) indican que: “El nacimiento de la

World Wide Web fue favorecido por la interacción social a través de internet, en 1991 Tim

Berners-Lee, publicó una síntesis del proyecto en alt.hypertext un grupo de noticias en

Usenet”.

A su vez, las aplicaciones web pueden ser definidas como sistemas de software basados en

las tecnologías y estándares del consorcio World Wide Web (W3C).

La web ha ido evolucionando a lo largo de la historia, las evoluciones de la web son:

● Web 1.0: La web 1.0 fue la primera generación de la web, esta se consideraba de solo

lectura y como un sistema de cognición. La web 1.0 inició como un lugar de

información para que las empresas exponen su información a la gente. La recién

creada web proveía una limitada interacción y contribución de los usuarios, solo se

les permitía buscar y leer información. (Aghaei, Nematbakhsh, & Farsani, 2012).

● Web 2.0: Esta es considerada como la segunda generación de la web, (Codina, 2009)

dice que esta se puede representar mediante los siguientes componentes:

1. Contenido creado por los usuarios

2. Redes Sociales.

3. Aplicaciones en línea.

4. Herramientas de colaboración.

● Web 3.0: Esta tercera etapa es considerada la más reciente y que aún está en

desarrollo, (Codina, 2009) propone algunas características para esta etapa, las cuales

son:

1. Computación en la nube y vinculación de datos y aplicaciones.

2. Agentes de usuario.

3. Anchura de banda.

4. Ubicuidad de la Web.


23

A lo largo de la historia siempre se ha buscado la manera de facilitar procesos desde los más

sencillos como el fabricar un banco hasta el proceso burocrático de gobierno.

El surgimiento de sistemas computacionales accesibles mediante un navegador web

conectado a una red, también llamados aplicaciones web, sucedió́ a mediados de la década

de 1990 impulsado por la aparición en escena de lenguajes y herramientas como CGI, Flash,

JavaScript, Java Pallets y PHP, que al trabajar de manera conjunta con el lenguaje de marcado

pionero en la web, HTML, ampliaban su funcionalidad más allá́ de la visualización de

documentos estáticos (Lujan, 2002).

La rápida adopción de aquellas herramientas por parte de los desarrolladores fomentó el

advenimiento de una nueva generación de sitios web que rompían los patrones hasta ese

momento establecidos, al brindar a los usuarios servicios novedosos con niveles de

interactividad antes vistos en Internet. Sin embargo, a pesar de representar una evolución

sustancial, el consenso general era que en comparación con las aplicaciones de escritorio, las

aplicaciones web aún tenían un gran camino que recorrer para lograr los mismos niveles de

desempeño y usabilidad.

Un importante número de tecnologías para el desarrollo de este tipo de aplicaciones salió al

dominio público y experimentó mejoras desde entonces, brindando una experiencia similar

con las aplicaciones de escritorio, generando una gran aceptación.

En el año 1996 los desarrolladores Sabeer Bhatia y Jack Smith lanzaron Hotmail, un servicio

de correo en línea que facilitaba el acceso a éstos sin estar frente a un ordenador.

El 17 de enero de 1998 el sitio web The Drudger Report difundió un informe sobre el

escándalo Clinton/Lewinsky, este evento fue el detonante del periodismo en línea tal como

lo conocemos hoy en día. Ese mismo año la compañía Google desarrolló su primer motor de

búsqueda en línea, por su nueva forma de indexar las páginas web, facilitó enormemente la

búsqueda de información en internet.

En EvaluandoERP (2017) se dice que las tecnologías de la información se han convertido,

hoy en día, en relevantes para la gestión empresarial, siendo una realidad contrastable que su

aplicación está cambiando drásticamente la forma de competir entre las empresas y lo que

éstas demandan de los profesionales. Sin embargo, a pesar de que las empresas son


24

conscientes del importante papel que juega la tecnología en sus sistemas de información, no

implica que las incorporen a sus procesos de negocio. El desarrollo tecnológico ofrece

mejoras consistentes para los procesos de negocio. De esta manera, la organización puede

mejorar la eficiencia y la efectividad de sus procesos de negocio, desarrollando nuevos

procesos o generando procesos de reingeniería.

EvaluandoERP (2017) comenta que las tecnologías de la información que dan soporte a la

gestión de los procesos de negocio suponen cambios en:

1. La organización (en la cultura de empresa, la forma de liderazgo, etc.).

2. Los procesos (soporte del servicio, servicio prestado, etc.) y,

3. La propia tecnología (integración de aplicaciones, análisis, visualización,

automatización, etc.)

2.2 Marco contextual

La autora (Zepeda, 2013) enumera las etapas de juicio laboral de la siguiente manera:

El juicio laboral inicia con la presentación de la demanda, la cual es analizada por la

junta competente a efecto de detectar alguna deficiencia o contradicción en ella.

Si la Junta detecta deficiencias en la demanda o el reclamo de prestaciones

contradictorias manda prevenir al trabajador para que la aclare (Art. 873 LFT), y

hecho lo anterior señalará fecha y hora para que tenga verificativo la audiencia de:

● Conciliación

● Demanda y excepciones

● Ofrecimiento y admisión de pruebas

Cada una de las etapas del proceso se especifica en los artículos 876, 878 y 880 de la Ley

Federal del Trabajo, se describen en los siguientes párrafos.

Artículo 876, Ley Federal del Trabajo, la etapa conciliatoria se desarrolla de la siguiente

forma:

I. Las partes comparecerán personalmente a la Junta y podrán ser asistidas por

sus abogados, patrones asesores o apoderados. Si se trata de personas morales,


25

el representante o apoderado deberá tener facultades para asumir una solución

conciliatoria que obligue a su representada.

II. La Junta, por conducto del funcionario conciliador o de su personal jurídico,

intervendrá para la celebración de pláticas entre las partes y las exhortará para

que procuren llegar a un arreglo conciliatorio.

III. Si las partes llegaren a un acuerdo, se dará por terminado el conflicto.

IV. (Se deroga)

V. La Junta, por conducto del funcionario conciliador o de su personal jurídico,

procurará, sin entorpecer el procedimiento y estando en contacto personal con

las partes y hasta antes de que se declare cerrada la instrucción, que lleguen a

un acuerdo conciliatorio, insistiendo siempre en opciones de solución justas y

equitativas para ambas; si las partes no llegan a un acuerdo se les tendrá por

inconformes, pasando a la etapa de demanda y excepciones.

VI. De no haber concurrido las partes a la conciliación, se les tendrá por

inconformes con todo arreglo y deberán presentarse personalmente a la etapa

de demanda y excepciones.

Artículo 878, Ley Federal Del Trabajo, la etapa de demanda y excepciones se desarrollará

conforme a las normas siguientes:

I. El presidente o el funcionario conciliador y demás personal jurídico de la

Junta exhortará nuevamente a las partes para que resuelvan el conflicto

mediante un arreglo conciliatorio.

II. El actor expondrá su demanda, ratificándola, aclarándola o modificándola,

precisando los puntos petitorios. Tratándose de aclaración o modificación de

demanda, la Junta, a petición del demandado, señalará nueva fecha, dentro del

término de diez días, para la continuación de la audiencia a fin de que se pueda

contestar la demanda en su totalidad.

III. Expuesta la demanda por el actor, el demandado procederá en su caso a dar

contestación a la demanda oralmente o por escrito. En este último caso estará

obligado a entregar una copia simple al actor de su contestación; si no lo hace,

la Junta la expedirá a costa del demandado.


26

IV. En su contestación opondrá el demandado sus excepciones y defensas,

debiendo de referirse a todos y cada uno de los hechos aducidos en la demanda

afirmándolos o negándolos, y expresando los que ignore cuando no sean

propios; pudiendo agregar las explicaciones que estime convenientes.

V. La excepción de incompetencia no exime al demandado de contestar la

demanda en la misma audiencia.

VI. Las partes podrán por una sola vez, replicar y contra replicar brevemente,

asentándose en actas sus alegaciones si lo solicitaren.

VII. Si el demandado reconviene el actor, éste procederá a contestar de inmediato.

VIII. Al concluir el periodo de demanda y excepciones, se citará a la audiencia de

ofrecimiento y admisión de pruebas, que tendrá verificativo dentro de los diez

días siguientes.

Artículo 880, Ley Federal del Trabajo, la audiencia de ofrecimiento y admisión de pruebas

se desarrollará de acuerdo con las normas siguientes:

I. El actor ofrecerá sus pruebas en relación con los hechos controvertidos.

Inmediatamente después el demandado ofrecerá sus pruebas y podrá objetar

las de su contraparte y aquel a su vez podrá objetar las del demandado.

II. Las partes podrán ofrecer nuevas pruebas, siempre que se relacionen con las

ofrecidas por la contraparte, así como las que tiendan a justificar sus

objeciones a las mismas, en tanto no se haya cerrado la audiencia.

III. Las partes deberán ofrecer sus pruebas, observando las disposiciones del

Capítulo XII de la Ley Federal del Trabajo.

IV. Concluido el ofrecimiento, la Junta resolverá inmediatamente sobre las

pruebas que admita y las deseche.

(Ley Federal del Trabajo, 1970)

Actualmente la junta de conciliación y arbitraje realiza todos sus procesos en papel, ya sea

anexando escritos a una carpeta con sus respectivas evidencias.

Como se mencionó anteriormente existen varios sistemas con finalidades similares tales

como:


27

● PJN en Argentina (Dalla, 2011): este sistema se basa en las leyes de manipulación y

ejecución del país antes mencionado, tiene un sistema vulnerable basado en flash,

esto mismo lo deja como obsoleto y reduce su velocidad de respuesta.

● CEJ en Perú (Bayona & Sánchez, 2008): está acotado a los estatutos de Perú los

cuales son distintos a los de nuestro país, se encuentra recientemente actualizado,

pero sin embargo utiliza tecnologías básicas que no permiten una gran escalabilidad

posterior.

● Un sistema automatizado para el seguimiento de procesos judiciales (Supo & Araujo,

2015): es el más actual de los sistemas consultados, se basa en los lineamiento de

Perú para el seguimiento de procesos, cuenta con un sistema autónomo para la

búsqueda de los expedientes, pero se ve limitado a que sigue en desarrollo y la parte

que lo convierte en un sistema autónomo requiere mayor tiempo de uso para poder

incrementar la fiabilidad de sus resultados, ya que mucho se basa en aprender sobre

las consultas que se realizan.

2.3 Marco teórico

En esta sección se presentan conceptos relacionados al proyecto, así el término: trazabilidad

infiere el histórico que el SMJL muestra de la demanda en particular; aplicaciones web tiene

que ver con las características del sistema desarrollado; Kanban y MVC con la metodología

de seguimiento y programación respectivamente; Node JS con la tecnología empleada en el

desarrollo; Express y Angular los entornos de trabajo para vincular la programación backend

y frontend, respectivamente.

2.3.1 Trazabilidad

El término trazabilidad es definido por la Organización Internacional para la Estandarización

(ISO 9001:2008), en su International Vocabulary of Basic and General Terms in Metrology

como: “La propiedad del resultado de una medida o del valor de un estándar donde éste pueda

estar relacionado con referencias especificadas, usualmente estándares nacionales o

internacionales, a través de una cadena continua de comparaciones todas con incertidumbres

especificadas.”


28

Según el Comité de Seguridad Alimentaria de AECOC:

“Se entiende trazabilidad como el conjunto de aquellos procedimientos

preestablecidos y autosuficientes que permiten conocer el histórico, la ubicación y

la trayectoria de un producto o lote de productos a lo largo de la cadena de

suministros en un momento dado, a través de unas herramientas determinadas.”

El autor (Awad, 2014) dice que al momento de tener que entender la trazabilidad de un

producto que se mueve a través de su cadena de suministro o de su rama logística, el concepto

de trazabilidad se divide en dos tipos:

● Trazabilidad Interna: es obtener la traza que va dejando un producto por todos los

procesos internos de una compañía, con sus manipulaciones, su composición, la

maquinaria utilizada, su turno, su temperatura, su lote, etc., es decir, todos los indicios

que hacen o pueden hacer variar el producto para el consumidor final.

● Trazabilidad Externa: es externalizar los datos de la traza interna y añadirle algunos

indicios más si fuera necesario, como una rotura del embalaje, un cambio en la cadena

de temperatura, etc.

Para el caso de estudio presentado en este trabajo de investigación aplica la trazabilidad

interna, en virtud de que el SMJL traza los puntos del proceso donde la demanda ha sido

atendida.

2.3.2 Aplicaciones Web

En la ingeniería de software se denomina aplicación web a aquellas herramientas que los

usuarios pueden utilizar accediendo a un servidor web a través de Internet, intranet o extranet

mediante un navegador. En otras palabras, es una aplicación de software que se codifica en

un lenguaje soportado por los navegadores web en la que se confía la ejecución al navegador.

Las aplicaciones web son populares debido a lo práctico del navegador web como cliente

ligero, a la independencia del sistema operativo, así como a la facilidad para actualizar y

mantener aplicaciones web sin distribuir e instalar software a miles de usuarios potenciales.

Es importante mencionar que una página Web puede contener elementos que permiten una

comunicación activa entre el usuario y la información. Esto permite que el usuario acceda a


29

los datos de modo interactivo, gracias a que la página responderá a cada una de sus acciones,

como por ejemplo rellenar y enviar formularios, participar en juegos diversos y acceder a

gestores de base de datos de todo tipo (Berti & Thompson, 2014).

El autor (Lujan, 2002) menciona que en las aplicaciones web suelen distinguirse tres niveles:

el nivel superior que interactúa con el usuario (el cliente web, normalmente un navegador),

el nivel inferior que proporciona los datos (la base de datos) y el nivel intermedio que procesa

los datos (el servidor web).

El cliente web es un programa con el que interactúa el usuario para solicitar a un servidor

web, el envío de los recursos que desea obtener mediante HTTP.

El servidor web es un programa que está esperando permanentemente las solicitudes de

conexión, mediante el protocolo HTTP por parte de los clientes web.

(Lujan, 2002) Declara que las aplicaciones web se emplean en tres entornos informáticos

muy similares que suelen confundirse entre sí:

● Internet: La internet posee un diseño descentralizado. Cada ordenador (host) en la

Internet es independiente. Sus operadores pueden elegir qué servicio de Internet usar

y qué servicios locales quieren proporcional al resto de la internet.

● Intranet: Una intranet es una red de ordenadores basada en los protocolos que

gobiernan Internet (TCP/IP) que pertenece a una organización y que es accesible

únicamente por los miembros de la organización, empleados u otras personas con

autorización.

● Extranet: Una extranet es una intranet a la que pueden acceder parcialmente personas

autorizadas ajenas a la organización o empresa propietaria de la intranet. Mientras

que, una intranet reside detrás de un cortafuego y sólo es accesible por las personas

que forman parte de la organización propietaria de la intranet, una extranet

proporciona diferentes niveles de acceso a personas que se encuentran en el exterior

de la organización.

Algunas de las características de las aplicaciones web son:


30

● Compatibilidad: Una versión única de una aplicación web puede ejecutarse en

cualquier sistema operativo, ya que se interactúa con ella mediante un navegador web,

independiente de que se trabaje sobre Windows, Linux, Android, Mac, etc.

● Distribución: No requiere distribución individual, al ser accesible por web, no

requiere instalación por cada computador.

● Actualizaciones: Las actualizaciones de la aplicación web se ejecutan una sola vez en

un servidor centralizado que la contiene y así no requiere actualización individual.

● Capacidad de cómputo: No requiere de una gran capacidad de cómputo en su

hardware, las aplicaciones web solo necesitan un mínimo posible para la ejecución

del navegador, la aplicación ejecuta todo el procesamiento de información en los

procesadores del servidor que la contiene.

● Seguridad: La seguridad se centraliza en el servidor que contiene la aplicación web y

no es necesario la instalación de software de seguridad en cada uno de los equipos.

● Escalabilidad: Ya que la aplicación se ubica en un servidor, se puede mejorar sus

prestaciones y fusionar con otras aplicaciones web para que trabajen en un solo

conjunto.

2.3.2.1 Arquitectura de una aplicación web

A continuación, se listan los componentes que forman parte de la arquitectura de una

aplicación web:

● Base de datos: Es el servidor cuyo servicio se encarga de almacenamiento y

tratamiento de información.

● Servidor Web: Es un servidor el cual se conforma de un conjunto de programas que

están en permanente estado de ejecución y que ofrecen una serie de servicios donde

la aplicación web corre.

● Red: Es el conjunto de protocolos y servicios de comunicación que interconectan a

los servidores con los clientes para que puedan acceder a las aplicaciones web.

● Navegador web: Es un programa que se ejecuta en el cliente, permite acceder y

desplegar las aplicaciones web en el equipo mediante protocolos de comunicación.


31

2.3.3 Kanban

Dentro de las metodologías ágiles para el desarrollo de software se encuentra Kanban y

SCRUM. Kanban es una de metodología que hace énfasis en la entrega “just-in-time” (justo

a tiempo), estableciendo con precisión qué trabajo se debe hacer, y cuándo se necesita hacer,

a través de la asignación de prioridades a las tareas, flujo de trabajo y el tiempo de espera

hasta la entrega (Lin, Chen, & Chen, 2013). Mientras que, SCRUM se enfoca en lograr la

colaboración eficaz de equipos en proyectos, empleando un conjunto de reglas y artefactos y

definiendo roles que generan la estructura necesaria para su correcto funcionamiento

(Navarro, Fernandez, & Morales, 2013).

(Vilijan, 2013) y (LeanKit, 2018) mencionan las siguientes características: Kanban es menos

preceptiva que SCRUM, ya que SCRUM proporciona una forma de hacer las cosas; Kanban

proporciona menos restricciones y lineamientos que SCRUM; Kanban no prescribe qué

columnas y que límites de trabajo debe contener el tablero Kanban, por lo cual el

desarrollador puede experimentar con el proceso y personalizarlo a su entorno, buscando la

mejor solución que encaje en el proceso de desarrollo de software y finalmente, permite

realizar cambios a mitad del camino, permitiendo iteraciones y mejoras continuas antes de la

finalización del proyecto; mientras que en SCRUM, los cambios durante el sprint son

fuertemente desaconsejados.

Los autores (Lin, Chen, & Chen, 2013) mencionan que Kanban es la palabra japonesa para

tarjeta visual que proporciona información para regular el flujo de inventario y materiales.

Kanban tiene tres reglas: (1) visualizar el flujo de trabajo, (2) limitar el trabajo en progreso

(WIP) en cada estado de flujo de trabajo, y (3) medir la dirección. Kanban cumple la función

de visibilidad, control de producción y control de inventarios, es decir, un sistema Kanban

está destinado a introducir estabilidad y previsibilidad en inventarios que se consideran

receptivos a los cambios del mercado. Además de la fabricación, Kanban se ha aplicado a la

producción de software como un modelo de proceso para la gestión de proyectos.

La metodología se caracteriza por la visualización de todas sus tareas y elementos en una

tabla que permite a todos los miembros del equipo tener la facultad de visualizar los avances

del proyecto y las tareas a las cuales fueron asignados, se tiene un límite de trabajos en

proceso, esto para prevenir el exceso de compromiso y que los miembros sean incapaces de


32

cumplir con sus asignaciones en el tiempo previsto. Plantea una forma sencilla para evaluar

el seguimiento del tiempo y esfuerzo; al utilizarse indicadores visuales para definir los tipos

de trabajo, prioridades, fechas límite, entre otros. Permite con un rápido vistazo identificar

qué es lo que está ocurriendo.

(Lin, Chen, & Chen, 2013) mencionan algunos beneficios de la metodología:

1. Estímulo de rendimiento. Mediante la realización de un análisis profundo y

estimaciones se puede medir el rendimiento, permitiendo detectar problemas

existentes y realizar ajustes dentro del flujo de trabajo para ganar eficiencia.

2. Organización y colaboración. Esta metodología se beneficia mucho por el enfoque

visual que se obtiene por el tablero, mediante el uso de columnas, carriles y tarjetas

de colores, todo el equipo tiene acceso a estos elementos por lo que se puede colaborar

en tiempo real y mantener una comunicación constante con todos los miembros.

3. Distribución del trabajo. Una cómoda visualización general de todos los trabajos en

curso y reduce el tiempo dedicado a la distribución y presentación de los trabajos; ya

que las estimaciones son imperfectas, un flujo constante de tareas reducirá su tiempo

de espera y el tiempo dedicado a asignarlas.

2.3.4 Modelo-Vista-Controlador (MVC)

Para el desarrollo del sistema se utilizó la arquitectura cliente servidor; por lo tanto, para el

cliente se utilizó el patrón de diseño de software Modelo-Vista-Controlador (MVC), uno de

los más utilizados en la actualidad.

Los autores (Gonzalez & Romero, 2012) dicen que fue diseñado para reducir el esfuerzo de

programación necesario en la implementación de sistemas múltiples y sincronizados de los

mismos datos. Sus características principales están dadas por el hecho de que, el Modelo, las

Vistas y los Controladores se tratan como entidades separadas; esto hace que cualquier

cambio producido en el Modelo se refleje automáticamente en cada una de las Vistas.

Este modelo de arquitectura se puede emplear en sistemas de representación gráfica de datos,

donde se presentan partes del diseño con diferente escala de aumento, en ventanas separadas.

Este tiene el objetivo de reducir el esfuerzo de programación, necesario en la implementación


33

de sistemas múltiples y sincronizados de los mismos datos, a partir de estandarizar el diseño

de las aplicaciones.

Algunas de las ventajas que presenta esta arquitectura son:

● Separación clara entre los componentes de un programa; lo cual permite su

implementación por separado.

● Interfaz de Programación de Aplicaciones API (Aplication Programming Interface)

muy bien definida; cualquiera que use el API, podrá reemplazar el Modelo, la Vista

o el Controlador, sin aparente dificultad.

● Conexión entre el Modelo y sus Vistas dinámicas; se produce en tiempo de ejecución,

no en tiempo de compilación.

Al incorporar el modelo de arquitectura MVC a un diseño, las piezas de un programa se

pueden construir por separado y luego unirlas en tiempo de ejecución. Si posteriormente, se

observa que uno de los componentes funciona mal, puede reemplazarse sin que las otras

piezas se vean afectadas. Este escenario contrasta con la aproximación monolítica típica de

muchos programas de pequeña y mediana complejidad. Todos tienen un frame que contiene

todos los elementos, un controlador de eventos, un montón de cálculos y la presentación del

resultado.

2.3.4 Node.Js

El autor (Jurado, 2013) menciona que NodeJS es un entorno de programación basado en el

lenguaje de programación Javascript, totalmente asíncrono en la capa del servidor y corriendo

sobre el motor V8, un motor de Javascript creado por Google, a travéz de una arquitectura

basada en eventos. La principal característica de NodeJS es el enfoque o tipo de software al

que va dirigido su uso, aunque puede ser usado para otras muchas cosas más. Fue creado

principalmente para el desarrollo de software de red altamente escalable y de baja latencia.

Creado por Ryan Dahlen en 2009 y su evolución está patrocinada por la empresa Joyent.

Esta tecnología permite crear un entorno de desarrollo y producción fácil de administrar y

con una gran capacidad de escalabilidad, gracias a la gran cantidad de aditamentos que se le


34

pueden anexar, desde frameworks para el desarrollo de las vistas, hasta para manejar a la

información y mantenerla segura y que esta sea consistente.

2.3.3.1 Concurrencia

Node.js funciona con un modelo de evaluación de un único hilo de ejecución, usando

entradas y salidas asíncronas, las cuales pueden ejecutarse concurrentemente en un número

de hasta cientos de miles sin incurrir en costos asociados al cambio de contexto. Este diseño

de compartir un único hilo de ejecución entre todas las solicitudes atiende a necesidades de

aplicaciones altamente concurrentes, en el que toda operación que realice entradas y salidas

debe tener una función callback. Un inconveniente de este enfoque, de único hilo de

ejecución, es que Node.js requiere de módulos adicionales como clúster para escalar la

aplicación con el número de núcleos de procesamiento de la máquina en la que se ejecuta

(Node.js, S.F.).

2.3.3.2 Módulos

Node.js incorpora varios "módulos básicos" compilados en el propio binario, como por

ejemplo el módulo de red, que proporciona una capa para programación de red asíncrona y

otros módulos fundamentales, como por ejemplo Path, FileSystem, Buffer, Timers y el de

propósito más general Stream. Es posible utilizar módulos desarrollados por terceros, ya sea

como archivos ".node" precompilados, o como archivos en javascript plano. Los módulos

Javascript se implementan siguiendo la especificación CommonJS para módulos, utilizando

una variable de exportación para dar a estos scripts acceso a funciones y variables

implementadas por los módulos.

Los módulos de terceros pueden extender Node.js o añadir un nivel de abstracción,

implementando varias utilidades middleware para utilizar en aplicaciones web, como por

ejemplo los frameworks connect y express. Pese a que los módulos pueden instalarse como

archivos simples, normalmente se instalan utilizando el Node Package Manager (npm) que

facilitará la compilación, instalación y actualización de módulos, así como la gestión de las

dependencias. Además, los módulos que no se instalen en el directorio por defecto de


35

módulos de Node.js, necesitarán la utilización de una ruta relativa para poder encontrarlos

(Node.js, S.F.).

2.3.5 Express

El autor (Hahn, 2016) define a Express como un framework ligero, que se sienta por encima

de la funcionalidad del servidor web de Node.js, para simplificar sus API y agregar nuevas y

útiles funciones. Hace más fácil organizar la funcionalidad de su aplicación con middleware

y enrutamiento; agrega utilidades a los objetos HTTP de Node.js; facilita la representación

de vistas dinámicas en HTML; define un estándar de extensibilidad de fácil implementación.

Express es filosóficamente similar a jQuery. La gente quiere agregar contenido dinámico a

sus páginas web, pero las API básicas del navegador tienden a tener características detalladas,

confusas y limitadas. Los desarrolladores tienden a escribir mucho código y repetitivo.

jQuery existe para reducir este código repetitivo, simplificando las API del navegador y

agregando nuevas funciones útiles.

2.3.6 Framework Angular

Angular es un framework para el desarrollo de aplicaciones del lado del cliente con plantillas

declarativas en HTML, inyección de dependencias y JavaScript o en su caso TypeScript que

compila código de JavaScript.

Angular es de código abierto y respaldado por Google, ha estado presente desde el 2010 y es

constantemente mejorado y expandido (Holmes, 2015). Consiste en un conjunto de librerías,

algunas que ya forman parte del núcleo y otras opcionales, las cuales el desarrollador puede

ir implementando según la necesidad del proyecto. Las aplicaciones se construyen de

plantillas en HTML con las recomendaciones de Angular, y la creación de componentes para

administrar estas, agregando lógica de aplicación y servicios dentro de módulos.


36

3. Métodos empleados

Esta sección describe la metodología y herramientas tecnológicas utilizadas en el proceso de ingeniería de software aplicado al SMJL.

3.1 Metodología

Esta investigación aplicada se apoyó en una metodología mixta soportada en los siguientes

pasos:

● Investigación documental. Se buscó información en fuentes oficiales, que

describiera la normatividad con relación a los procesos de justicia laboral. Tales

documentos fueron: Ley Federal del Trabajo (1970) , El procedimiento ordinario

laboral en la Ley Federal del Trabajo (Ramirez, 2012) , este es el procedimiento que

se sigue en los juicios laborales (Coto, 2018).

● Investigación de campo. Se realizó una estancia en la Junta Local de Conciliación y

Arbitraje con sede en la ciudad de Colima, en donde se aplicaron entrevistas

semiestructuradas cerradas, se observó y documentó las funciones que realizan los

empleados que cubren los roles que se describen en la Figura 2 , siendo éstos:

Oficialía de partes, Radicaciones, Mesa de Acuerdo, Actuario, Proyectista y Pleno.

Figura 2 Actores en los juicios laborales


37

Por tanto, cada rol cuenta con una serie de actividades y una serie de permisos sobre

el acceso a la información, esto en informática se conoce como autorización de acceso

a la información y propone el marco de trabajo y de interacción de los usuarios en el

SMJL.

● Limitaciones. Se identificaron las limitaciones del contexto, principalmente la

ausencia de procesos documentados que describan las funciones de cada puesto, la

falta de tecnologías de información y comunicación, y de alfabetización digital en

parte del personal.

● Procesamiento y análisis de datos. La información recolectada fue analizada y

procesada utilizando la metodología ágil Kanban, a fin de iniciar y dar seguimiento

al proceso de ingeniería de software.

3.2 Ingeniería de software

El contexto de desarrollo de la solución propuesta dio lugar a la utilización de una

metodología ágil para el proceso de ingeniería. Para la elección de la metodología se

evaluaron las características de Kanban y SCRUM, considerando aquellas que benefician el

desarrollo del sistema propuesto con base en las limitaciones de su contexto de desarrollo.

Se optó por la utilización de la metodología Kanban, por sus preceptos en precisar qué trabajo

se debe hacer y cuándo se necesita hacer, a través de la asignación de prioridades a las tareas,

flujo de trabajo y el tiempo de espera hasta la entrega (Lin, Chen, & Chen, 2013).

Así durante la gestión de ingeniería de software del SMJL se observaron las reglas de

Kanban, visualizando las historias de usuario y el flujo de trabajo, limitando el trabajo en

progreso en las columnas del tablero para medir la dirección de lo realizado.

Implementando la metodología se optó por operar con dos roles, el primero de propietario

del producto para escribir las historias y validar los resultados, y el segundo rol fue el de

desarrollador, para implementar las historias de usuario mediante su codificación en el

lenguaje de programación seleccionado.


38

De la implementación de la metodología se generó el tablero de la Figura 3, en el que se

muestran las historias de usuario y la fase en que se encuentran: desarrollo, pruebas o

terminada. Como se puede observar, en la lista de historias se van agregando nuevas historias

más específicas o de nuevas características que se le agregan al sistema.

Figura 3. Tablero Kanban del SMJL

La visualización de las tareas y elementos del tablero permitieron visualizar los avances del

proyecto y las tareas a las cuales fueron asignados los miembros del equipo; se favoreció el

rendimiento, la autoorganización y colaboración de los miembros del equipo, mediante la

visualización de la distribución y avance de las tareas.

3.3 Tecnologías de desarrollo Web utilizadas

Para el desarrollo del sistema se utilizó la arquitectura cliente servidor, para el cliente se

utilizó el patrón de diseño de software Modelo-Vista-Controlador (MVC), uno de los más

utilizados en la actualidad (Gonzalez & Romero, 2012), este tiene el objetivo de reducir el


39

esfuerzo de programación, necesario en la implementación de sistemas múltiples y

sincronizados de los mismos datos, a partir de estandarizar el diseño de las aplicaciones; el

framework Angular 6 fue seleccionado para la creación de la aplicación web que toma el rol

de cliente, utilizando Bootstrap como Framework de CSS; mientras que el servidor, se

desarrolló utilizando el Framework Express para Node.js.

Una vez escritas y priorizadas las historias de usuario, se colocaron sobre el tablero Kanban

y se configuró el entorno de programación con las tecnologías:

§ MVC: El sitio del sistema quedó organizado en carpetas para cada uno de los

componentes que contienen los archivos correspondientes a la implementación de las

historias de usuario; dentro de cada carpeta de componente quedó almacenado su

respectivo modelo, vista y controlador; estos últimos permiten invocar los modelos y

las vistas para lograr la interacción de las funcionalidades del SMJL que atienden a

las historias de usuario.

§ Angular 6: La organización de las carpetas para los componentes está dada por el

framework, para un fácil acceso a los paquetes de angular y correcto funcionamiento

de las funciones que este facilita.

§ Bootstrap: Las vistas de cada uno de los componentes se construyeron utilizando

componentes de bootstrap, esto facilitando los mantenimientos posteriores y

adaptaciones a diferentes tipos de resoluciones.

§ Express: La API RESTful se creó bajo esta infraestructura, creando un enrutador y

separando cada una de las funcionalidades en carpetas, cada una de las

funcionalidades es accesible desde el enrutador a través de una URL específica.

§ Node.js: Tanto Bootstrap como Express corren sobre Node.js, éste funge como

servidor de aplicaciones web, encargándose de las interacciones de la aplicación con

el hardware.

Por otro lado, el SMJL considera una arquitectura de API RESTful para un fácil acceso a la

información que el usuario puede consultar. Se pensó en utilizar los frameworks más

actualizados para entregar un producto moderno que pueda estar vigente en el largo plazo,

conservando su utilidad a las JLCA. Los autores (Barry, Purcell, Eck, Hayes, & Arandia,

2014) mencionan que los servicios web RESTful se basan en los principios arquitectónicos


40

de REST (Representacional State Transfer) para la transferencia de datos representativos.

Como su nombre sugiere, sólo se transfiere una representación del recurso y no el recurso en

sí. Los principios de una arquitectura RESTful definen una interfaz uniforme entre clientes

y servidores y solicitudes encapsuladas.

Para el desarrollo de la arquitectura de software del sistema o también conocida como

arquitectura lógica del sistema, se recurrió a la implementación de los patrones de diseño

Singleton y Adapter para la manipulación de la información como si fueran objetos. El código

está estructurado para ser mantenible y fácilmente manipulable por futuros desarrolladores

trabajando sobre la plataforma.

Es importante señalar que la combinación de las metodologías utilizadas con el proceso

universal de ingeniería de software y las tecnologías de desarrollo tiene un papel

preponderante en la entrega de un software de calidad.


41

4. Desarrollo de la propuesta

En este capítulo se muestra el desarrollo del proyecto SMJL atendiendo la investigación

documental y de campo, así como la metodología Kanban para el desarrollo del software; se

presentan los artefactos utilizados y el seguimiento de estos.

4.1 Recopilación de información

Las lecturas de los documentos: Ley Federal del Trabajo (1970) , “El Procedimiento

Ordinario Laboral en la Ley Federal del Trabajo” (Ramirez, 2012) y “Este es el

procedimiento que se sigue en los juicios laborales” (Coto, 2018), permitieron entender los

procesos que se ejecutan cuando una demanda se registra en la JLCA. La información más

relevante fue el flujo que sigue el proceso es no lineal, lo que da lugar a terminar en cualquiera

de sus estados; los distintos roles de los individuos involucrados en el proceso de atención,

el actor, del demandado, el miembro de oficialía, etc., y la definición de las responsabilidades

de cada uno.

Durante la estadía en la operación de las Juntas, observando cada uno de los roles que

participan en el proceso, se pudieron trazar las diversas actividades, de acuerdo con lo

marcado en la Ley y las tareas jurídicas que se realizan en la JLCA. Dicha traza se presenta

en diagramas de actividades, los cuales se describen a continuación.

En la Figura 4 se muestra las actividades que los empleados con rol oficialía realizan durante

el juicio, desde la recepción de los documentos que presenta el actor para interponer la

demanda, hasta el envío a su siguiente etapa con otro miembro de la junta.


42

Figura 4 Diagrama de actividades Oficialía

En la Figura 5, se muestra las actividades a realizar por un miembro de radicaciones, siendo

la más crucial la de redactar la radicación, la cual presenta la información de la demanda de

manera resumida.


43

Figura 5 Diagrama de Actividades Radicaciones

En la Figura 6, se muestran las actividades que realiza un miembro de la mesa, siendo éstas

las que más veces se repiten dentro del proceso, ya que la mesa encargada de controlar las

audiencias valora y verifica todo lo presentado y comentado para la resolución de la demanda.


44

Figura 6 Diagrama de actividades Mesa

En la Figura 7, se muestran las actividades que realiza el proyectista, desde analizar el

expediente hasta crear un laudo con la propuesta de resolución para la demanda y después

derogar al actuario para que se tomen las acciones correspondientes.


45

Figura 7 Diagrama de actividades Proyectista

En la Figura 8, se muestran las actividades del actuario, que se encarga de hacer cumplir lo

resuelto en el laudo creado por el proyectista.

Figura 8 Diagrama de actividades Actuario


46

Como se puede observar las entrevistas con los usuarios, empleados de la JLCA, permitieron

identificar las actividades de los actores que participan y elaborar con precisión las historias

de usuario.

4.2 Historias de usuario priorizadas

Las historias de usuario que se identificaron se muestran en la Tabla 1, se presentan

priorizadas y marcando las dependencias con otras historias de usuario.

Tabla 1 Historias de usuario del SMJL

ID TÍTULO DESCRIPCIÓN PRIORIDAD DEPENDENCIAS

1 Registrar demanda

COMO usuario (Rol Oficialía) QUIERO <registrar una demanda laboral> para <dar seguimiento en línea y finalmente obtener un dictamen judicial > PRUEBAS DE ACEPTACIÓN: Validar que es usuario registrado, Validar que sube los documentos básicos que acompañan a una demanda.

10 6,7,8

2 Registrar documentos

Como usuario del sistema (Todos los roles) QUIERO <registrar un documento> dentro del sistema para <vincular la copia digital de los documentos a una demanda, y poder consultarlos dentro del sistema> PRUEBAS DE ACEPTACIÓN: Validar que sea un usuario registrado.

15 1

3

Registrar cambios de

estado de las demandas

Como usuario del sistema (Todos los roles) QUIERO <registrar un cambio de estado de la demanda> para <que otra instancia dentro del proceso tenga acceso a ella> PRUEBAS DE ACEPTACIÓN: Validar que sea un usuario registrado, Validar que el usuario tenga el rol necesario para modificar el estado de la demanda desacuerdo a sus permisos.

17 1

4 Registrar audiencias

Como usuario del sistema (Rol Pleno o Mesa) QUIERO <registrar una audiencia> para <agendarla en el calendario de la mesa y se reserve el espacio para esta> > PRUEBAS DE ACEPTACIÓN: Validar que sea un usuario registrado, Validar el rol del usuario, Validar las fechas y horarios disponible dentro de las mesas.

12 1

5

Limitar visualización

de información

por rol

Como administrador del sistema o miembro del pleno QUIERO <limitar visualización de información por rol > para <no exista filtrado de información a individuos que no tienen el permiso para consultarlo> PRUEBAS DE ACEPTACIÓN: Validar que la información

20


47

ID TÍTULO DESCRIPCIÓN PRIORIDAD DEPENDENCIAS que se muestra sea la correcta para el rol del usuario

6 Registrar actores

Como usuario del sistema (Rol oficialía o pleno) QUIERO <registrar un nuevo actor> para <almacenar la información pertinente del actor y poder consultarlo en cualquier momento> PRUEBAS DE ACEPTACIÓN: Validar que sea un usuario registrado, Validar el rol del usuario.

4 8

7 Registrar demandados

Como usuario del sistema (Rol Oficialía o pleno) QUIERO <registrar un nuevo demandado> para <almacenar la información pertinente del demandado y poder consultarlo en cualquier momento> PRUEBAS DE ACEPTACIÓN: Validar que sea un usuario registrado, Validar el rol del usuario.

6 8

8 Registrar usuarios

Como usuario del sistema (Rol Pleno) QUIERO <registrar un nuevo usuario> para <almacenar la información pertinente del usuario y otorgarle acceso al sistema> PRUEBAS DE ACEPTACIÓN: Validar que sea usuario registrado. Validar el rol del usuario.

1

9 Registrar

cambios de rol de usuario

Como usuario del sistema (Rol Pleno) QUIERO <registrar cambios en el rol del usuario> para <llevar un control de los roles por los que ha pasado un usuario> PRUEBAS DE ACEPTACIÓN: Validar que sea un usuario del sistema, Validar que el usuario tenga el rol de pleno.

18 8

10 Visualizar las

audiencias programadas

Como usuario del sistema (Todos los roles) QUIERO <visualizar todas las audiencias programas> para <visualizar las cargas de trabajo de las mesas> PRUEBAS DE ACEPTACIÓN: Validar que sea un usuario registrado.

13 4

11 Modificar audiencias

Como usuario del sistema (Rol Pleno y Mesa) QUIERO <modificar los datos relacionados a una audiencia tales como fecha, hora, mesa> para <re agendar una audiencia o agregar notas a esta> PRUEBAS DE ACEPTACIÓN: Validar que sea un usuario registrado, Validar el rol del usuario.

16 4

12 Modificar actores

Como usuario del sistema (Rol oficialía o pleno) QUIERO <registrar modificar la información de un actor> para <almacenar los cambios de información que se puedan suscitar> PRUEBAS DE ACEPTACIÓN: Validar que sea un usuario registrado, Validar el rol del usuario.

5 6

13 Modificar demandados

Como usuario del sistema (Rol oficialía o pleno) QUIERO <registrar modificar la información de un demandado> para <almacenar los cambios de información que se puedan suscitar> PRUEBAS DE

7 7


48

ID TÍTULO DESCRIPCIÓN PRIORIDAD DEPENDENCIAS ACEPTACIÓN: Validar que sea un usuario registrado, Validar el rol del usuario.

14 Consulta demanda

Como usuario del sistema (Todos los roles) QUIERO <consultar la información y el estado en que la demanda se encuentra>para <atenderla o proveer información a las personas interesadas> PRUEBAS DE ACEPTACIÓN: Validar que sea usuario registrado. Validar el rol del usuario.

11 1

15 Consulta

documentos por demanda

Como usuario del sistema (Todos los roles) QUIERO <consultar los documentos relacionados a una demanda> para <seguir con su atención o consultar información de estos> PRUEBAS DE ACEPTACIÓN: Validar que sea usuario registrado. Validar el rol del usuario.

14 2

16

Acceso al sistema sólo por usuarios registrados

Como usuario del sistema (Todos los roles) QUIERO <acceder al sistema> para <consultar y complementar la información almacenada> PRUEBAS DE ACEPTACIÓN: Validar que sea un usuario registrado.

4 8

17 Registrar mesas

Como usuario del sistema (Rol Pleno) QUIERO <registrar una nueva mesa> para <almacenar la información relacionada con la mesa> PRUEBAS DE ACEPTACIÓN: Validar que sea un usuario registrado. Validar el rol del usuario.

8 8

18 Modificar mesas

Como usuario del sistema (Rol Pleno) QUIERO <modificar la información de la mesa> para <modificar los datos de la mesa> PRUEBAS DE ACEPTACIÓN: Validar que sea un usuario registrado. Validar el rol del usuario.

9 17

19 Modificar usuarios

Como usuario del sistema (Rol Pleno) QUIERO <modificar la información de un usuario> para <modificar ya sea su rol, sus datos, o revocar permiso de acceso> PRUEBAS DE ACEPTACIÓN: Validar que sea un usuario registrado. Validar el rol del usuario.

2 8

20 Modificar solo descripción de

documento

Como usuario del sistema (Todos los roles) QUIERO <modificar la descripción del documento> para <hacer correcciones en caso de un error al momento de registrarlo> PRUEBAS DE ACEPTACIÓN: Validar que sea un usuario registrado.

19 2

4.3 Implementación

La implementación de la arquitectura física del sistema, que se muestra en la Figura 9, se

llevó a cabo a través de las tecnologías de desarrollo mencionadas en la sección anterior.


49

Como se podrá observar, el front-end del sistema, que desempeña el rol del cliente en la

arquitectura cliente-servidor, fue desarrollado utilizando el framework Angular 6 en conjunto

con Bootstrap como framework de CSS, implementando la arquitectura MVC.

Figura 9 Arquitectura de implementación

Por otro lado, el back-end del sistema, correspondiente al servidor de la arquitectura cliente-

servidor, fue desarrollado utilizando el framework Express con Node.js. Finalmente, como

mecanismo de comunicación y acceso a la información se empleó el API RESTful,

permitiendo el acceso a los datos a través de los “endpoints” definidos para el sistema. Un

endpoint es una URL única que permite realizar funciones específicas dentro de la API.

La arquitectura propuesta es el resultado de la integración de los estilos arquitectónicos

MVC, Cliente-Servidor y API RESTful, proporcionado con esta arquitectura una solución

integral para el sistema SMJL.

4.3.1 Implementación de las historias de usuario En atención a la metodología Kanban las historias de usuario fueron atendiéndose por

prioridad y de acuerdo con las iteraciones marcadas. Se expone la implementación de tres de

ellas, las cuales se describen a continuación.


50

4.3.1.1 Historia de usuario<<Registrar demanda>>

La implementación de la historia de usuario <Registrar demanda> implicó diseñar las tablas

que se muestran en la Figura 10. Ésta muestra las tablas demandas, demandados y actores,

que se requieren para almacenar los datos respectivos a la demanda. Por otro lado, la Figura

11, muestra el prototipo de interfaz para captura y envío de datos a las tablas señaladas.

Figura 10. Tablas para registrar demanda.

Figura 11. Diseño de interfaz para registrar demanda.


51

El código que permite la captura, registro y consulta de la información se muestra en la Figura

12, Figura 13 y Figura 14. Atendiendo el modelo MVC, la figura 12 muestra un segmento

de código que implementa la vista para registrar demanda.

<div [@routerTransition]> <div class="row"> <div class="col-xl-12"> <ol class="breadcrumb"> <li class="breadcrumb-item"> <i class="fa fa-address-book"></i> <a href="Javascript:void(0)" [routerLink]="['/demandas']"> <== Demandas</a> </li></ol></div></div> <p class="h3 text-center">{{title}}</p><hr/> <div class="row"> <div class="col-sm-10"> <form role="form"> <div class="form-group input-group" id='fClave'> <div class="col-8 col-sm-8 offset-sm-2 input-group-prepend" *ngIf="hd"> <span class="input-group-text bg-primary text-white" id="basic-addon1"> Clave

</span> <input id="DemClave" type="text" class="form-control" placeholder="Clave de

Demanda" value="{{demanda.DemClave}}" [disabled]=true> </div></div>

Figura 12. Fragmento de vista registrar demanda.

La figura 13 muestra un fragmento de código correspondiente al modelo para registrar una

demanda. A su vez la figura 14, muestra un fragmento del código que corresponde al

controlador de la historia registrar demanda.

@Injectable({ providedIn: 'root'}) export class DemandasService { demandas: DemandaCon[]; httpOptions = { headers: new HttpHeaders({ 'Content-Type': 'application/json', 'Authorization': 'my-auth-token' })}; addDemanda(nDemanda: Demanda): Observable<any> { const aux = JSON.stringify(nDemanda); return this._http.post<any>(UrlServ + '/demandas', aux, this.httpOptions); }

Figura 13. Fragmento modelo para registrar una demanda.


52

@Component({ selector: 'app-mDemanda', templateUrl: './mDemanda.component.html', styleUrls: ['./mDemanda.component.scss'], animations: [routerTransition()] }) constructor(private route: ActivatedRoute, private toastr: ToastrService, private router: Router, private _DService: DemandasService) { this.demanda = new DemandaConC(); try { this.rol = JSON.parse(sessionStorage.getItem('User'))[0].RolClave; this.usI = JSON.parse(sessionStorage.getItem('User'))[0].usrClave; } catch (Error) { } this._DService.getActores().subscribe( data => { if (data.length !== 0) { this.actores = data; } else {this.toastr.error('Error al obtener informacion');} }, err => { console.log(err); this.toastr.error('Error en el servidor'); });

Figura 14. Fragmento de controlador registrar demanda.

Durante el desarrollo de las historias de usuario, las funcionalidades fueron probadas con

datos plausibles. La Tabla 2 muestra los datos de prueba del modelo que captura una

demanda. Tabla 2. Datos de Prueba registrar demanda.

Variable Correcto Correcto Error Error

Clave 104 201 E35 T12

Folio AE05-12-1 AE05-24-3 AE05-15-2 AE05-24-7

Actor 1 3 Antonio José

Demandado 2 15 Ana Manuel

Ciudad Colima Colima Colima Colima

Fecha 12/05/2018 24/05/2018 15/05/2018 24/05/2018

Tipo Normal Urgente Normal Normal


53

4.3.1.2 Historia de usuario<<Registrar documentos>>

La implementación de la historia de usuario < Registrar documentos > implicó diseñar las

tablas que se muestran en la Figura 15, muestra las tablas usuarios y documentos, que se

requieren para almacenar los datos respectivos del documento. Por otro lado, la Figura 16,

muestra el prototipo de interfaz para captura y envío de datos a las tablas señaladas.

Figura 15 Tablas para registrar documento

Figura 16. Diseño de interfaz para registrar documento.


17, Figura 18 y Figura 19; donde se muestra un segmento del modelo, la vista y el controlador

respectivos a ese proceso.

54

<input type="file" #file style="display: none" (change)="onFilesAdded()" /> <div class="container" fxLayout="column" fxLayoutAlign="stretch"> <h1 mat-dialog-title>Nuevo Documento</h1>  <form role="form"> <div class="form-group input-group"> <div class="col-12 col-sm-12 input-group-prepend"> <span class="input-group-text bg-primary text-white" id="basic-addon1"> Nombre </span> <input id="DocNombre" type="text" class="form-control" value="" placeholder="Nombre Documento" [disabled]="true"> </div> </div> <div class="form-group input-group"> <div class="col-12 col-sm-12 input-group-prepend"> <span class="input-group-text bg-primary text-white" id="basic-addon1"> Tipo </span> <input id="DocTipo" type="text" class="form-control" value="" placeholder="Tipo Documento"> </div></div>

Figura 17. Fragmento de vista registrar documento.

@Injectable({ providedIn: 'root' }) export class DocumentosService { documentos: DocumentoC[]; httpOptions = { headers: new HttpHeaders({ 'Content-Type': 'application/json', 'Authorization': 'my-auth-token' }) }; constructor(private _http: HttpClient) {} getDocumentosByDemanda(i: number): Observable<DocumentoC[]> { return this._http.get<DocumentoC[]>(UrlServ + '/documentos/' + i); } setDocumentos(docs: DocumentoC[]) { this.documentos = docs;}

Figura 18. Fragmento modelo para registrar documento.


55

@Component({ selector: 'app-dialog', templateUrl: './dialog.component.html', styleUrls: ['./dialog.component.scss'] }) export class DialogComponent implements OnInit { @ViewChild('file') file; public files: Set<File> = new Set(); progress; canBeClosed = true; primaryButtonText = 'Guardar'; showCancelButton = true; uploading = false; uploadSuccessful = false; docName = ''; constructor(public dialogRef: MatDialogRef<DialogComponent>, public uploadService: UploadService) { } ngOnInit() { this.canBeClosed = false; }

Figura 19. Fragmento de controlador registrar documento.


datos plausibles. La Tabla 3 muestra los datos de prueba del modelo que captura un

documento. Tabla 3 Datos de prueba registrar documento


Clave 203 204 D205 D206

Nombre IFE Actor Proyecto1 Acta Actor Proyecto2

Tipo IFE Proyecto de

laudo

Acta de

nacimiento

Proyecto de

laudo

Cantidad de Copias 1 2 1 1

Descripción IFE del actor Primer

proyecto de

laudo escrito

Acta de

nacimiento del

actor

Segundo

proyecto de

laudo escrito

Folio Demanda AE05-24-3 AE05-24-3 AE05-24-3 AE05-24-3

Usuario Creado 5 2 Ana Manuel

Fecha Creacion 24/05/2018 25/05/2018 23/04/2018 22/05/2018

Clave Demanda 75 75 75 75

Hash JHT54DFT7T JDH562DRRT PN6529TCHL NS9182JHCP


56

4.3.1.3 Historia de usuario <<Registrar Cambio de estado de las demandas>>

La implementación de la historia de usuario < Registrar Cambio de estado de las demandas

> implicó diseñar las tablas que se muestran en la Figura 20. Ésta muestra las tablas

demandas, status demandas y status, que se requieren para almacenar los datos respectivos

del cambio de estado de las demandas. Por otro lado, la Figura 21 muestra el prototipo de

interfaz para captura y envío de datos a las tablas señaladas.

Figura 20. Tablas para cambio de estado de las demandas.

Figura 21. Diseño de interfaz para cambio de estado de las demanda.


22, Figura 23 y Figura 24, donde se muestra un segmento del modelo, la vista y el controlador

respectivos al proceso cambio de estado de la demanda.


57

<div class="form-group input-group"> <div class="col-8 col-sm-8 offset-sm-2 input-group-prepend"> <span class="input-group-text bg-primary text-white" id="basic-addon1">Status</span> <select class="form-control" id="demStatus"(change)="showProy($event.target.value)"> <option>Selecciona Status</option>> <option *ngFor="let stat of status; let i = index" value="{{stat.StaClave}}" [selected]="stat.StaClave === demanda.StaClave">{{stat.StaNombre}} </option></select> <span class="input-group-text bg-primary text-white" id="basic-addon1" *ngIf="pro"> Proyectista</span> <select class="form-control" id="proyDem" [disabled]="mpro" *ngIf="pro"> <option>Selecciona un Proyectista</option>> <option *ngFor="let proy of proyec; let i = index" value="{{proy.ProClave}}" [selected]="proy.ProClave === demanda.DemClaveProyectista">{{proy.ProNombre}} </option> </select></div></div>

Figura 22. Fragmento de vista cambio de estado de la demanda.

// Update Status updateStatusD(nStatus: StatusDemanda): Observable<any> { const aux = JSON.stringify(nStatus); return this._http.put<any>(UrlServ + '/statusD/' + nStatus.SDClaveDem, aux, this.httpOptions); } addStatusD(nStatus: StatusDemanda): Observable<any> { const aux = JSON.stringify(nStatus); return this._http.post<any>(UrlServ + '/statusD', aux, this.httpOptions); }

Figura 23. Fragmento modelo cambio de estado de la demanda.

if (this.action === 'mod') { this._DService.updateDemanda(nDemanda).subscribe( status => { if (status.message === 'Success') { btn.disabled = false; if (this.demanda.StaClave !== status) { this._DService.updateStatusD(stat).subscribe( status => { if (status.message === 'Success') { this._DService.addStatusD(stat).subscribe( status => {this.toastr.success('Demanda Guardada'); this.router.navigate(['/demandas']);btn.disabled = false;});}});} } else { this.toastr.error('Error en el servidor');} });

Figura 24. Fragmento de controlador cambio de estado de la demanda.


58


datos plausibles. La Tabla 4 muestra los datos de prueba del modelo donde cambia el estado

de la demanda.

Tabla 4 Datos de prueba cambio de estado de la demanda


Clave 13 24 75 34


Status 1 4 Radicaciones En proyecto de

laudo

Usuario 1 2 1 1

Time Stamp 1543344063 3726482756 45362738491 5637482745

Comentarios Requisitos

completados.

Faltan documentos. Falta confirmacion por

el actor.

Requisitos completados

4.3.1.4 Historia de usuario<<Registrar audiencia>>

La implementación de la historia de usuario < Registrar audiencia > implicó diseñar las tablas

que se muestran en la Figura 25. Ésta muestra las tablas mesas, audiencias y demandas, que

se requieren para almacenar los datos respectivos de la audiencia. Por otro lado, la Figura 26

muestra el prototipo de interfaz para captura y envío de datos a las tablas señaladas

Figura 25. Tablas para registrar audiencias


59

Figura 26. Diseño de interfaz para registrar audiencia.

El código que permite la captura, registro y consulta de la información se muestra en la

Figura 2727, Figura 28 y Figura 29 donde se muestra un segmento del modelo, la vista y el

controlador respectivos a ese proceso.

<div class="form-group input-group"> <div class="col-8 col-sm-8 offset-sm-2 input-group-prepend"> <span class="input-group-text bg-primary text-white" id="basic-addon1"> Status</span> <select class="form-control" id="demStatus" (change)="showProy($event.target.value)"> <option>Selecciona Status</option>> <option *ngFor="let stat of status; let i = index" value="{{stat.StaClave}}" [selected]="stat.StaClave === demanda.StaClave">{{stat.StaNombre}} </option> </select> <span class="input-group-text bg-primary text-white" id="basic-addon1" *ngIf="pro">Proyectista</span> <select class="form-control" id="proyDem" [disabled]="mpro" *ngIf="pro"> <option>Selecciona un Proyectista</option>> <option *ngFor="let proy of proyec; let i = index" value="{{proy.ProClave}}" [selected]="proy.ProClave === demanda.DemClaveProyectista">{{proy.ProNombre}} </option> </select></div></div>

Figura 27. Fragmento de vista registrar audiencia.


60

// Update Status updateStatusD(nStatus: StatusDemanda): Observable<any> { const aux = JSON.stringify(nStatus); return this._http.put<any>(UrlServ + '/statusD/' + nStatus.SDClaveDem, aux, this.httpOptions); } addStatusD(nStatus: StatusDemanda): Observable<any> { const aux = JSON.stringify(nStatus); return this._http.post<any>(UrlServ + '/statusD', aux, this.httpOptions); }

Figura 28. Fragmento modelo registrar audiencia.

if (this.action === 'mod') { this._DService.updateDemanda(nDemanda).subscribe( status => { if (status.message === 'Success') { btn.disabled = false; if (this.demanda.StaClave !== status) { this._DService.updateStatusD(stat).subscribe( status => { if (status.message === 'Success') { this._DService.addStatusD(stat).subscribe( status => {this.toastr.success('Demanda Guardada'); this.router.navigate(['/demandas']);btn.disabled = false;});}});} } else {this.toastr.error('Error en el servidor');}});

Figura 29. Fragmento de controlador registrar audiencia..


datos plausibles. La Tabla 5 muestra los datos de prueba del modelo que registra una

audiencia. Tabla 5 Datos pruebas registrar audiencia


Clave 5 23 52 15

Fecha 12/06/2018 17/05/2018 24/06/2018 08/05/2018

Hora 10:00 AM 02:00 PM 06:00 AM 10:00 PM

Clave Mesa 1 2 1 1


Notas Audiencia para

presentar pruebas.

Audiencia para

arreglo entre

demandado y actor.

Audiencia para

presentar pruebas.

Audiencia para presentar

resolucion a los

interesados.


61

4.3.1.5 Historia de usuario<<Limitar visualización de información por rol>>

La implementación de la historia de usuario < Limitar visualización de información por rol

> implicó diseñar las tablas que se muestran en la Figura 30, muestra las tablas mesas,

audiencias y demandas, que se requieren para almacenar los datos respectivos de la audiencia.

Por otro lado, la Figura 31 muestra el prototipo de interfaz para captura y envío de datos a

las tablas señaladas

Figura 30. Limitar visualización de información por rol.

Figura 31. Diseño de interfaz limitar visualización de información por rol.

El código que permite la captura, registro y consulta de la información se muestra en la

Figura 32, Figura 33, Figura 34 donde se muestra un segmento del modelo, la vista y el

controlador respectivos al proceso visualización de la información por rol.


62

<p class="h1 text-center">Modificar Permisos: {{rol.RolDescripcion}}</p> <hr/> <form role="form"> <div class="form-group input-group" id='fClave'> <div class="col-8 col-sm-8 offset-sm-2 input-group-prepend"> <span class="input-group-text bg-primary text-white" id="basic-addon1"> Clave Rol </span> <input id="RolClave" type="text" class="form-control" placeholder="Clave de Rol" value="{{rol.RolClave}}" [disabled]=true> </div> </div> <div class="form-group input-group" > <div class="col-8 col-sm-8 offset-sm-2 input-group-prepend"> <span class="input-group-text bg-primary text-white" id="basic-addon1"> Descripcion Rol </span> <input id="RolDescripcion" type="text" class="form-control" placeholder="Descripcion Rol" value="{{rol.RolDescripcion}}" [disabled]=true> </div> </div>

Figura 32. Fragmento de vista limitar visualización de información por rol.

// Permisos getRoles(): Observable<Rol[]> { return this._http.get<Rol[]>(UrlServ + '/roles'); } getStatus(): Observable<Status[]>{ return this._http.get<Status[]>(UrlServ + '/statusRol'); } getStatusOfRol(idRol: number): Observable<StatusCon[]> { idRol++; return this._http.get<StatusCon[]>(UrlServ + '/statusRol/' + idRol); } storeStatus(st: Status): Observable<any> { return this._http.put<any>(UrlServ + '/statusRol/' + st.SRClaveRol, st, this.httpOptions); }

Figura 33. Fragmento modelo limitar visualización de información por rol.


63

@Component({ selector: 'app-mPermiso', templateUrl: './mPermiso.component.html', styleUrls: ['./mPermiso.component.scss'], animations: [routerTransition()] }) export class MPermisoComponent implements OnInit { private parms: any; private index: number; public rol: Rol; public statusR: StatusCon[]; clave; constructor(private route: ActivatedRoute, private toastr: ToastrService, private router: Router, private _Cservice: CatalogosServiceService) { this.rol = new RolC(); } ngOnInit() { const fclave = <HTMLInputElement>document.getElementById('MesClave'); this.parms = this.route.params.subscribe(params => { try { this.index = +params['id']; if ( !isNaN(this.index) ) { this._Cservice.getRoles().subscribe(

Figura 34. Fragmento de controlador limitar visualización de información por rol.

La ¡Error! No se encuentra el origen de la referencia. muestra los datos de prueba del m

odelo que visualiza la información por rol.

Tabla 6 Datos de prueba limitar visualización de información por rol


Clave Permiso 1 2 3 4

Clave Status 1 3 10 12

Autorización True False False True

4.4 El modelo de datos del SMJL

Una vez concluidas las iteraciones con sus incrementos respectivos, la base de datos

relacional, correspondiente al sistema, quedó integrada como se muestra en la Figura 35. Es


64

la tabla denominada “demanda” el origen del proceso de demanda y la cual da seguimiento

al mismo.

Figura 35. Modelo de datos.

4.4 Diagrama de Warnier

En el diagrama de Warnier muestra una vista general de la estructura del sistema y los

módulos que lo componen. En la Figura 36 se aprecia la estructura del sistema SMJL. Para


65

la operación de los procesos jurídicos se requiere tener información en los catálogos. Los

procesos a realizar son registrar: Audiencias, Comisiones, Demandas y Documentos.

Figura 36. Diagrama de Warnier.

4.5 Diagrama de Navegación

El diagrama de navegación de la Figura 37, muestra cómo organizar y sistematizar las

secciones y contenidos dentro del sitio web SMJL. En él se puede observar la estructura

jerárquica, desde el inicio de sesión, luego el menú principal y el acceso a las funcionalidades

de cada opción para ejecución.


66

Figura 37. Diagrama de Navegación.

4.6 Diagrama de componentes

En el diagrama de componentes de la Figura 38, se muestran los componentes que conforman

el SMJL y su relación entre ellos. Un diagrama de componentes tiene un nivel más alto de

abstracción que un diagrama de clases, usualmente un componente contiene una o más clases.

A través del navegador web se accede al componente de inicio de sesión, al recibir los datos

proporcionados por el usuario estos se comprueban dentro del guard de acceso, esto es, en

caso de ser correctos, regresa los permisos que este usuario tiene, en caso de no contar con

ninguno restringe el acceso a los otros componentes, teniendo los permisos correspondientes

se da acceso a la aplicación web donde se encuentran todos los modelos, vistas y


67

controladores; a través de los modelos se solicita información a la API, la cual se encarga de

consultar la información a la base de datos y formatearla como la necesite la aplicación.

Figura 38. Diagrama de componentes.


68

5. Resultados

Como resultado se tiene un desarrollo de software que innova el proceso de atención jurídica

de las demandas laborales. Dicha innovación recae en el seguimiento electrónico inmediato,

en la comunicación de los actores que intervienen en la atención de la demanda y en las

propias tecnologías con que fue elaborado.

Para acceder al sistema se requiere ser usuario registrado, por lo que la primera pantalla que

se visualiza es la de iniciar sesión. Como se muestra en la Figura 39, se muestra el nombre

del sistema y presentan dos campos para recibir información, uno para el usuario y otro para

la contraseña.

Figura 39. Pantalla de inicio de sesión.

En el primer acceso por parte del administrador de sistema, es necesario crear usuarios para

cada uno de los miembros de la junta y otorgarle acceso dependiendo de sus funciones dentro

de la misma. En la Figura 40 se muestra la pantalla para agregar usuarios, aquí se le asigna

un usuario y una contraseña definida por el administrador o un miembro del pleno; en caso

de que el usuario olvide sus credenciales de acceso, se le pueden cambiar estos datos en

cualquier momento, como se muestra en la Figura 41, ambas pantallas solo son accesibles

por un miembro del pleno o el administrador del sistema.


69

Figura 40. Pantalla registrar usuarios.

Figura 41. Pantalla modificar usuario.

Una mesa requiere de varios usuarios para una mejor atención, así al rol de mesa se le asocian

uno o más usuarios. En la Figura 422 se muestra la pantalla para agregar nuevas mesas,

actualmente en la junta existen dos mesas que siempre están activas, pero en ocasiones el

trabajo excede las capacidades; por lo que, se crean mesas extraordinarias. En la Figura 43

se muestra la pantalla para modificar la descripción de la mesa y su nombre según sea

necesario.


70

Figura 42. Pantalla agregar mesa.

Figura 43. Pantalla modificar mesa.

Para comenzar con el proceso de registro de demandas es necesario registrar actores que son

los que interpondrán las demandas, se requiere entonces información para contactarlos. En

la Figura 44 se muestra la pantalla para agregar los datos generales de los actores al catálogo;

mientras que la Figura 45 muestra la interfaz para realizar cambios en la información de los

actores, esto en caso de que esta cambie a lo largo del proceso de atención.


71

Figura 44. Pantalla registrar actores.

Figura 45. Pantalla modificar actores.

Para interponer una demanda son necesarios los datos del demandado, por lo que estos se

deben agregar al catálogo de demandados. En la Figura 46 se muestra la pantalla para

almacenar su información. Los datos del demandado pueden cambiar a lo largo de la atención

de la demanda, dichos cambios pueden registrarse como muestra la Figura 47 para modificar

los datos de un demandado.


72

Figura 46. Pantalla agregar demandado.

Figura 47. Pantalla modificar demandado.

Al iniciar el proceso de interponer una demanda se crea un registro para ésta, en la Figura 48

se muestra la pantalla para registrar una nueva demanda, ésta se captura por un miembro de

oficialía, y en caso de existir alguna anomalía genera comentarios.


73

Figura 48. Pantalla agregar demanda.

En la Figura 49 se muestra la pantalla para modificar una demanda, permitiendo solo

modificar el estado de ésta, cuando se realiza un cambio en este campo se guarda un registro

del estado (En Oficialia, En Radicaciones, Audiencia Programada, Con Acturario, En

proyecto de laudo, Cancelada) con sus respectivos comentarios.


74

Figura 49. Pantalla modificar demanda.

Una vez que la demanda pasa por el estado de radicaciones y se deroga a una mesa, la mesa

agenda audiencias según los requerimientos del proceso, ya sea para presentar evidencias o

notificar la resolución de la demanda.

En la Figura 50 se muestra la pantalla para agregar nuevas audiencias, éstas pueden pasar

entre las mismas mesas dependiendo de su carga de trabajo. En caso de que la audiencia no

pueda llevarse a cabo, ésta deberá posponerse por lo que será necesario modificarla y cambiar

ya sea la fecha o la hora en que ésta se efectuaría. En la Figura 51 se muestra la pantalla para

modificar una audiencia.


75

Figura 50. Pantalla agregar audiencia.

Figura 51. Pantalla modificar audiencia.

Las audiencias son visibles por todos los miembros de la junta, en la Figura 52 se muestra el

calendario de audiencias programadas, mostrando las audiencias programadas por día, y

mediante un código de color su urgencia para atención. El color azul significa una demanda


76

ordinaria, el color rojo urgente. Mientras que, la celda resaltada en verde muestra el día

actual.

Figura 52. Pantalla audiencias programadas.

Todos los usuarios pueden llegar a cumplir las funciones de cualquiera de los roles, por lo

que se lleva un registro de todos estos cambios, para cambiar el rol de un usuario se crean

comisiones, al crear una nueva comisión ésta pone fecha de término a la que el usuario

anteriormente tenía y crea una nueva (ver Figura 53), donde se muestra la pantalla para

agregar nuevas comisiones. En la Figura 54 se muestra la pantalla para modificar una

comisión.


77

Figura 53. Pantalla agregar comisión.

Figura 54. Pantalla modificar comisión.

Hay información y componentes del sistema que no son accesibles por todos los usuarios,

por lo que se crearon permisos de acceso dependiendo del estado de la demanda. En la Figura

55 se muestran las opciones para modificar los permisos del rol del pleno.


78

Figura 55. Pantalla modificar permisos.

Durante el proceso de atención de una demanda se pueden consultar el estado actual y cada

uno por los que esta ha pasado. En la Figura 56 se muestra una línea de tiempo con los últimos

estados por los que ha pasado la demanda, mostrando la fecha en que se efectuó cambio de

estado y las notas correspondientes.

Figura 56. Pantalla historico de la demanda.


79

El SMJL ha tenido gran aceptación entre los usuarios, quienes han validado las

funcionalidades, se espera ampliar la infraestructura de cómputo para dejarlo en producción

en el corto plazo.


80

6. Conclusiones

Se ha cumplido con el objetivo de desarrollar un Sistema de Monitoreo de Juicios Laborales

(SMJL) que lleve el registro histórico de los expedientes legales, para dar seguimiento

oportuno a las actividades implícitas en la atención de las demandas laborales. Cualquier

usuario con credenciales puede consultar el histórico de una demanda y observar en que

momento ha sido turnada de una oficina a otra, situación que facilita dar información a los

interesados.

Por otra parte, la hipótesis planteada se ve apoyada ampliamente con la operación del sistema,

en virtud de que el desarrollo de sistemas de información con características web sí facilitan

la impartición de justicia por vía electrónica, reduciendo los tiempos de procesamiento,

consulta y resolución de estos.

El sistema opera el 100% de las funcionalidades especificadas y los usuarios internos de la

dependencia han valorado la construcción del SMJL porque se ejecuta en un entorno web, lo

que facilita el trabajo asíncrono; contribuye a la modernización del proceso de impartición

de justicia, volviéndolo un proceso más accesible, reduciendo los plazos de atención y

permitiendo un mejor manejo de los recursos para su resolución.

El proceso de ingeniería de software se facilitó en virtud de la investigación documental y de

campo realizada previo al desarrollo del proyecto, a la comprensión de los procesos que se

ejecutan para atender las demandas laborales identificando los actores que intervienen, el

diseño esbelto de las vistas, basado principalmente en estudios de usabilidad, el diseño

integral de la estructura de datos que da soporte al sistema.

El considerar un registro histórico de cada uno de los movimientos y documentos que se

relacionan con el proceso de atención a un juicio laboral, dentro de un sistema de

información, facilita el seguimiento de todas las actividades y la observancia de

responsabilidades y obligaciones de los miembros de la junta.

Los beneficios del Sistema de Monitoreo de Juicios Laborales se pueden resumir en:

• Trabajo más organizado y programado para su atención.


81

• Mejor comunicación entre los actores jurídicos que atienden una demanda.

• Seguimiento inmediato a la demanda por parte de los actores, demandante y

demandado.

• Seguimiento inmediato por parte del pleno, ante posibles quejas.

• Disminución de los tiempos de atención.

6.1 Trabajo futuro. Como parte del trabajo futuro una vez que el sistema se encuentre en producción, se

realizarán pruebas de usabilidad del sistema midiendo los tiempos efectuados en cada uno de

los procesos desde que se genera la demanda hasta que se otorga una resolución de esta y se

contrastará a través de métricas estadísticas con los tiempos efectuados antes de la

implementación del sistema, esto con la finalidad de otorgar evidencia estadística que

comprueben la hipótesis planteada en esta investigación.

Por otro lado, se recomienda continuar este proyecto con un módulo de indicadores que

incorpore la numeralia de demandas atendidas en un periodo de tiempo; reportes periódicos

de productividad por mesa de trabajo; indicadores de productividad por rol en la dependencia;

estimación de tiempos de atención a las demandas, factores que impiden la atención oportuna

de las demandas, entre otros.

Por otro lado, como la información que se integra a los expedientes es de gran volumen, se

sugiere un módulo de minería de datos para el análisis de la información y la detección de

tendencias en las demandas.


82

Fuentes de Información Chaniotis, I., Kyriakou, K., & Tselikas, N. (2015). Is Node. js a viable option for building

modern web applications? A performance evaluation study. Computing, 97(10), 1023-1044.

LeanKit. (2018). KANBAN VS. SCRUM: WHAT ARE THE DIFFERENCES? Planview LeanKit.

Lei, H., Ganjeizadeh, F., Jayachandran, P., & Ozcan, P. (2017). A statistical analysis of the effects of Scrum and Kanban on software development projects. Robotics and Computer-Integrated Manufacturing, 59-67.

Ley Federal del Trabajo. (1970). Lin, C., Chen, F., & Chen, Y.-m. (2013). Knowledge kanban system for virtual research

and development. Robotics and Computer-Integrated Manufacturing, 119-134. Codina, L. (2009). ¿Web 2.0, Web 3.0 o Web Semántica?: El impacto en los sistemas de

información de la Web. Congreso Internacional de Ciberperiodismo y Web (Vol. 2). Contreras, J. T. (2012). Juicio en línea en la justicia administrativa: Hacia la justicia

electrónica en México. Alegatos-Revista Jurídica de la Universidad Autónoma Metropolitana.

Coto, D. (2018). ESTE ES EL PROCEDIMIENTO QUE SE SIGUE EN LOS JUICIOS LABORALES. Obtenido de El Contribuyente: https://www.elcontribuyente.mx/2018/03/este-es-el-procedimiento-que-se-sigue-en-los-juicios-laborales/

Lujan, S. M. (2002). Desarrollo e implantación de una aplicación Web para la gestión integral de la empresa. Departamento de Lenguajes y Sistemas Informáticos de la Universidad de Alicante.

Aghaei, S., Nematbakhsh, M., & Farsani, H. (2012). EVOLUTION OF THE WORLD WIDE WEB: FROM WEB 1.0 TO WEB 4.0. International Journal of Web & Semantic Technology (IJWesT).

Awad, S. N. (2014). ¿Qué se entiende en logística por trazabilidad? Barry, M., Purcell, M., Eck, B., Hayes, J., & Arandia, E. (2014). Web services for water

systems: The iWIDGET REST API. Procedia Engineering, 1120-1127. Bayona, W. P., & Sanchez, C. T. (2008). Sistema automatizado para el seguimiento de

procesos judiciales en un estudio de abogados. Repositorio Académico UPC. Berti, E., & Thompson, R. (2014). Aplicaciones Web. Obtenido de wikieducator:

http://es.wikieducator.org/images/0/09/AplicacionesWeb.pdf Dalla Via, A. (2011). La participación política y la reforma electoral en Argentina. Revista

Justicia Electoral. EvaluandoERP. (2017). El papel del sistema de información en la mejora de los procesos. Gonzalez, Y., & Romero, Y. (2012). Patrón Modelo-Vista-Controlador. Revista

Telem@tica, 47-57. Hahn, E. (2016). Express in Action. United States: Manning. Holmes, S. (2015). Getting MEAN with Mongo, Express, Angular, and Node. Manning. INEGI. (2017). ESTADÍSTICAS A PROPÓSITO DEL... DÍA MUNDIAL DE INTERNET

(17 DE MAYO). INEGI. Obtenido de ESTADÍSTICAS A PROPÓSITO DEL... DÍA MUNDIAL DE INTERNET (17 DE MAYO).


83

Jurado, J. A. (26 de Enero de 2013). NodeJS: Introducción a NodeJS. Obtenido de Happy Minds! Software: http://www.happyminds.es/nodejs-introduccion-a-nodejs/#sthash.RQvN6YHi.iLujfuN5.dpbs

Melitski, J., & Calista, D. (2016). E-GOVERNMENT AND E-GOVERNANCE BEST PRACTICES IN CITIES AND COUNTRIES COMPARED BETWEEN 2003 AND 2012. Fad or Diffused Innovation?

Middlebrook, K. J., & Ramirez, C. Q. (1998). Las juntas locales de conciliación y arbitraje en México: registro sindical y solución de conflictos en los noventa. Estudios Sociológicos, 283-316.

Navarro, A. C., Fernandez, J. M., & Morales, J. V. (2013). Revisión de metodologías ágiles para el desarrollo de software. PROSPECTIVA.

Node.js. (S.F.). Node.js. Obtenido de https://es.wikipedia.org/wiki/Node.js Ramirez, C. J. (2012). EL PROCEDIMIENTO ORDINARIO LABORAL EN LA LEY

FEDERAL DEL TRABAJO. Revista Latinoamericana de Derecho Social. Supo, F., & Araujo, M. (2015). Sistema inteligente de búsqueda de expedientes judiciales

basado en Web semántica para consultorios jurídicos. http://repositorio.upao.edu.pe/bitstream/upaorep/1865/1/RE.SIS_MARLON.ARAUJO_FRANCISCO.SUPO_SISTEMA.INTELIGENTEP_T046_45440653_46325051T_TESIS.pdf, 1-93.

Vilijan, M. (2013). APPLYING KANBAN PRINCIPLES TO SOFTWARE DEVELOPMENT. 16th International Conference on Information Technology for Practice 2013.

Zepeda, K. (2013). Secretaria de Trabajo y Previsión Social. Obtenido de Demandas Laborales: https://stps.jalisco.gob.mx/asesoria-laboral/demandas

sistema de monitoreo de juicios laborales

Documents