DISEÑO Y DESARROLLO DE UN PROTOTIPO WEB Y ...repository.udistrital.edu.co/bitstream/11349/3118/1/...2 DISEÑO Y DESARROLLO DE UN PROTOTIPO WEB Y MOVIL DE APOYO A LA GESTION DE LITIGIO

DISEÑO Y DESARROLLO DE UN PROTOTIPO WEB Y MOVIL DE APOYO A LA GESTION DE LITIGIO DE PROCESOS JUDICIALES CIVILES

Presentado por:

OMAR ALEJANDRO TÉLLEZ FLECHAS

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA

PROYECTO CURRICULAR DE SISTEMAS BOGOTÁ D.C.

2016

2

DISEÑO Y DESARROLLO DE UN PROTOTIPO WEB Y MOVIL DE APOYO A LA GESTION DE LITIGIO DE PROCESOS JUDICIALES CIVILES

Presentado Por:

OMAR ALEJANDRO TÉLLEZ FLECHAS cod. 20031020094

Trabajo de grado

Director Julio Barón Velandia

Profesor facultad de Ingeniería

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA

PROYECTO CURRICULAR DE SISTEMAS BOGOTÁ D.C.

2016

3

TABLA DE CONTENIDO

Pág.

TABLA DE CONTENIDO......................................................................................... 3

LISTA DE TABLAS .................................................................................................. 8

LISTA DE IMAGENES ............................................................................................ 9

GLOSARIO ............................................................................................................ 11

0. INTRODUCCIÓN ........................................................................................... 14

1. PLANTEAMIENTO DEL PROBLEMA ............................................................ 16

1.1 DESCRIPCIÓN DEL PROBLEMA .............................................................. 16

1.2 FORMULACIÓN DEL PROBLEMA ............................................................ 17

2. OBJETIVOS ................................................................................................... 18

2.1 OBJETIVO GENERAL ................................................................................ 18

2.2 OBJETIVOS ESPECÍFICOS ...................................................................... 18

3. JUSTIFICACIÓN ............................................................................................ 19

4. ALCANCES Y LIMITACIONES ...................................................................... 22

4.1 ALCANCES ................................................................................................ 22

4.2 LIMITACIONES .......................................................................................... 23

5. MARCO CONCEPTUAL ................................................................................ 24

5.1 PROCESO JUDICIAL ................................................................................. 24

5.1.1 Clasificación de los procesos judiciales .................................................. 24

5.1.2 Secuencia de los procesos judiciales civiles ........................................... 26

4

5.2 ACTOS PROCESALES .............................................................................. 28

5.2.1 Tipos de actos procesales ...................................................................... 28

6. MARCO TECNOLÓGICO .............................................................................. 30

6.1 APLICACIONES WEB ................................................................................ 30

6.1.1 Java Enterprise Edition (Java EE)........................................................... 30

6.2 APLICACIONES MÓVILES ........................................................................ 38

6.2.1 Android. ................................................................................................... 38

6.3 SERVICIOS WEB ....................................................................................... 42

6.3.1 Servicios Web SOAP .............................................................................. 43

6.3.2 Servicios Web REST ............................................................................... 45

6.4 BASE DE DATOS ....................................................................................... 48

6.4.1 Mapeo objeto-relacional .......................................................................... 48

6.4.2 Motor de base de datos .......................................................................... 48

7. DISEÑO METODOLÓGICO ........................................................................... 51

7.1 METODOLOGÍA DE DESARROLLO .......................................................... 51

7.1.1 Descripción ............................................................................................. 51

7.1.2 Definición de objetivos, alternativas y restricciones ................................ 53

7.1.3 Evaluación de alternativas y reducción de riesgos ................................. 54

7.1.4 Desarrollo y validación de producto ........................................................ 54

7.1.5 Planificación del siguiente ciclo ............................................................... 55

7.2 METODOLOGIA DE INTEGRACIÓN Y PRUEBAS .................................... 56

7.2.1 Descripción ............................................................................................. 56

8. DEFINICIÓN DE REQUERIMIENTOS ........................................................... 57

8.1 FUNCIONALIDAD DE REGISTRO DE PROCESOS JUDICIALES ............ 57

8.1.1 Requerimientos funcionales .................................................................... 57

8.1.2 Requerimientos de información .............................................................. 58

8.2 FUNCIONALIDAD DE CONSULTA DE PROCESOS JUDICIALES ........... 61



8.3 FUNCIONALIDAD DE CAPTURA Y ENVÍO DE INFORMACIÓN DE ACTUACIONES PROCESALES ........................................................................... 65



5

8.4 FUNCIONALIDAD DE RECEPCIÓN Y ORGANIZACIÓN DE INFORMACIÓN PROCESAL ................................................................................ 67



8.5 FUNCIONALIDAD DE AUTENTICACIÓN DE USUARIOS ......................... 69



8.6 REQUERIMIENTOS NO FUNCIONALES .................................................. 71

9. DISEÑO DEL SISTEMA ................................................................................. 72

9.1 ARQUITECTURA ....................................................................................... 72

9.1.1 Capa de Datos ........................................................................................ 73

9.1.2 Capa de Negocio .................................................................................... 73

9.1.3 Capa de Presentación Web .................................................................... 74

9.1.4 Capa de Presentación Móvil ................................................................... 74

9.1.5 Comunicación ......................................................................................... 74

9.1.6 Estructura de paquetes ........................................................................... 74

9.2 MODELO DE CLASES ............................................................................... 76

9.2.1 Clases del paquete ‘datos.entidades’ ...................................................... 76

9.2.2 Clases del paquete ‘datos.DAO’ ............................................................. 76

9.2.3 Clases del paquete ‘servicios’ ................................................................. 77

9.2.4 Clases del paquete ‘web.controladores’ .................................................. 78

9.3 DIAGRAMAS DE SECUENCIA .................................................................. 80

9.3.1 Funcionalidad de registro de procesos judiciales .................................... 80

9.3.2 Funcionalidad de consulta de procesos judiciales .................................. 82

9.3.3 Funcionalidad de captura y envío de información de actos procesales .. 83

9.3.4 Funcionalidad de recepción y organización de información procesal ..... 84

9.3.5 Funcionalidad de autenticación de usuarios ........................................... 84

10. INTERFAZ DE USUARIO ........................................................................... 86

10.1 FUNCIONALIDAD DE REGISTRO DE PROCESOS JUDICIALES ............ 86

10.2 FUNCIONALIDAD DE CONSULTA DE PROCESOS JUDICIALES ........... 88

10.3 FUNCIONALIDAD DE CAPTURA Y ENVÍO DE INFORMACIÓN DE ACTOS PROCESALES ...................................................................................................... 90

10.4 FUNCIONALIDAD DE AUTENTICACIÓN DE USUARIOS ......................... 91

6

11. DISEÑO DE MODELO LÓGICO Y FÍSICO DE BASE DE DATOS............. 92

11.1 DISEÑO MODELO LÓGICO DE LA BASE DE DATOS ............................. 92

11.2 DISEÑO MODELO FÍSICO DE LA BASE DE DATOS ............................... 93

11.2.1 Creación del esquema ............................................................................ 93

11.2.2 Creación tabla ‘PROCESO’ .................................................................... 93

11.2.3 Creación tabla ‘ACTUACION’ ................................................................. 93

11.2.4 Creación tabla ‘TIPO_ACTUACION’ ....................................................... 94

11.2.5 Creación tabla ‘FOTOGRAFIA’ ............................................................... 94

11.2.6 Creación tabla ‘JUZGADO’ ..................................................................... 94

11.2.7 Creación tabla ‘JUZGADO_PROCESO’ ................................................. 95

11.2.8 Creación tabla ‘SUJETO’ ........................................................................ 95

11.2.9 Creación tabla ‘SUJETO_PROCESO’ .................................................... 95

11.2.10 Creación tabla ‘USUARIO’ .................................................................. 96

11.2.11 Creación tabla ‘ROL’ ........................................................................... 96

12. DESARROLLO DE LOS MÓDULOS DEL PROTOTIPO ............................ 97

12.1 HERRAMIENTAS Y FRAMEWORKS UTILIZADOS ................................... 98

13. DISEÑO DE PRUEBAS DEL SISTEMA ................................................... 100

13.1 DISEÑO DE REGLAS DE INTEGRACIÓN ............................................... 100

13.2 DISEÑO DE REGLAS DE PRUEBAS ...................................................... 100

13.2.1 Diseño general de pruebas unitarias..................................................... 100

13.3 CRITERIOS DE ACEPTACIÓN ................................................................ 101

13.3.1 Funcionalidad de registro de procesos judiciales .................................. 101

13.3.2 Funcionalidad de consulta de procesos judiciales ................................ 102

13.3.3 Funcionalidad de captura y envío de información de actos procesales 104

13.3.4 Funcionalidad de recepción y organización de información procesal ... 105

13.3.5 Funcionalidad de autenticación de usuarios ......................................... 105

14. RESULTADOS OBTENIDOS ................................................................... 107

15. ESTIMACIÓN BENEFICIO / COSTO ....................................................... 116

15.1 ESTIMACIÓN DE COSTOS RELACIONADOS CON PROBLEMAS DE GESTIÓN ............................................................................................................ 116

15.2 ESTIMACIÓN DE COSTO DE IMPLEMENTACIÓN DEL PROYECTO.... 117

15.3 RELACIÓN BENEFICIO COSTO ............................................................. 120

7

16. TRABAJO FUTURO Y RECOMENDACIONES ........................................ 121

17. CONCLUSIONES ..................................................................................... 122

18. BIBLIOGRAFÍA ......................................................................................... 124

8

LISTA DE TABLAS

Tabla 1: Requerimiento crear proceso judicial ...................................................... 57

Tabla 2: Requerimiento crear sujeto procesal ....................................................... 58

Tabla 3: Requerimiento administrar juzgados ....................................................... 58

Tabla 4: Información sobre el proceso judicial ...................................................... 59

Tabla 5: Información sobre el sujeto procesal ....................................................... 59

Tabla 6: Información sobre juzgados .................................................................... 60

Tabla 7: Requerimiento consultar lista de procesos judiciales activos .................. 61

Tabla 8: Requerimiento consultar lista de procesos judiciales inactivos ............... 61

Tabla 9: Requerimiento consultar proceso judicial específico ............................... 62

Tabla 10: Información sobre lista de procesos judiciales activos .......................... 62

Tabla 11: Información sobre lista de procesos judiciales inactivos ....................... 63

Tabla 12: Información sobre consulta de proceso judicial ..................................... 63

Tabla 13: Requerimiento captura y envío de información de actuación procesal.. 65

Tabla 14: Información sobre captura y envío de información procesal ................. 66

Tabla 15: Requerimiento recepción y organización de información procesal ........ 67

Tabla 16: Información sobre recepción y organización de información procesal .. 68

Tabla 17: Requerimiento de control de acceso a componente móvil .................... 69

Tabla 18: Requerimiento de control de acceso a componente web ...................... 69

Tabla 19: Información sobre usuarios en el sistema ............................................. 70

Tabla 20: Información sobre roles de los usuarios en el sistema .......................... 70

Tabla 21: Requerimientos no funcionales ............................................................. 71

Tabla 22: Criterios de aceptación para funcionalidad de registro de procesos judiciales.............................................................................................................. 101

Tabla 23: Criterios de aceptación para funcionalidad de consulta de procesos judiciales.............................................................................................................. 102

Tabla 24: Criterios de aceptación para funcionalidad de captura y envío de información de actos procesales ......................................................................... 104

Tabla 25: Criterios de aceptación para funcionalidad de recepción y organización de información procesal ...................................................................................... 105

Tabla 26: Criterios de aceptación para funcionalidad de autenticación de usuarios ............................................................................................................................ 105

Tabla 27: Pérdida anual estimada para abogado con 1500 procesos simultáneos ............................................................................................................................ 117

Tabla 28: Pérdida anual estimada de acuerdo a cantidad de procesos simultáneos ............................................................................................................................ 117

Tabla 29: Costos de talento humano para el desarrollo del proyecto .................. 118

Tabla 30: Costos estimados de implementación del proyecto ............................ 119

Tabla 31: Beneficio-costo estimado para la implementación del proyecto durante 5 años .................................................................................................................... 120

9

LISTA DE IMAGENES

Imagen 1: Etapas de un proceso civil colombiano ................................................ 26

Imagen 2: Contenedores Java EE estándar .......................................................... 31

Imagen 3: Servicios proporcionados por los contenedores Java EE ..................... 35

Imagen 4: Archivos en contenedores Java EE ...................................................... 36

Imagen 5: Secciones y capas principales del sistema operativo Android ............. 40

Imagen 6: Porcentaje de uso de las diferentes versiones de Android ................... 41

Imagen 7: Servicio web y uno de sus clientes ....................................................... 42

Imagen 8: Interacción de un servicio web SOAP .................................................. 45

Imagen 9: Interacción de un servicio web tipo REST ............................................ 45

Imagen 10: interacción en técnica de mapeo objeto-relacional ............................. 48

Imagen 11: Modelo en espiral para el proceso de desarrollo de software ............ 52

Imagen 12: Niveles de la arquitectura usada ........................................................ 72

Imagen 13: Capas de la arquitectura usada .......................................................... 73

Imagen 14: Diagrama de paquetes del sistema .................................................... 75

Imagen 15: Diagrama de clases del paquete 'datos.entidades' ............................. 76

Imagen 16: Diagrama de clases del paquete 'datos.DAO' .................................... 77

Imagen 17: Diagrama de clases del paquete 'servicios' ........................................ 78

Imagen 18: Diagrama de clases del paquete 'web.controladores' ......................... 79

Imagen 19: Diagrama de secuencia de registro de procesos judiciales ................ 80

Imagen 20: Diagrama de secuencia de administración de juzgados en el sistema .............................................................................................................................. 81

Imagen 21: Diagrama de secuencia de consulta de procesos activos .................. 82

Imagen 22: Diagrama de secuencia de consulta de procesos inactivos ............... 82

Imagen 23: Diagrama de secuencia de captura y envío de información de actos procesales ............................................................................................................. 83

Imagen 24: Diagrama de secuencia de recepción y organización de información procesal ................................................................................................................. 84

Imagen 25: Diagrama de secuencia de autenticación de usuarios en componente móvil ...................................................................................................................... 85

Imagen 26: Diagrama de secuencia de autenticación de usuario en componente web ........................................................................................................................ 85

Imagen 27: Interfaz de usuario de formulario de creación de proceso judicial ...... 86

Imagen 28: Interfaz de usuario de formulario de agregación de sujeto procesal .. 87

Imagen 29: Interfaz de usuario de administración de juzgados ............................ 87

Imagen 30: Interfaz de usuario de búsqueda de procesos .................................... 88

Imagen 31: Interfaz de usuario de visualización de proceso ................................. 88

Imagen 32: Interfaz de usuario de visualización de registro de actuación ............ 89

Imagen 33: Interfaz de usuario de definición de tipos de actuación ...................... 90

Imagen 34: Interfaz de usuario de registro de actuación ....................................... 90

Imagen 35: Interfaz de usuario de autenticación de usuario en componente móvil .............................................................................................................................. 91

Imagen 36: Interfaz de usuario de autenticación de usuario en componente web 91

10

Imagen 37: Diseño modelo lógico de base de datos ............................................. 92

Imagen 38: Interfaz de formulario de autenticación ............................................. 107

Imagen 39: Interfaz de creación de proceso judicial en el sistema ..................... 108

Imagen 40: Interfaz de administración de juzgados en el sistema ...................... 108

Imagen 41: Interfaz de agregación de sujeto procesal a un proceso judicial ...... 109

Imagen 42: Validaciones de lógica de negocio en la creación de procesos judiciales.............................................................................................................. 110

Imagen 43: Interfaz de consulta de procesos judiciales activos .......................... 110

Imagen 44: Interfaz de consulta de procesos judiciales inactivos ....................... 111

Imagen 45: Interfaz de visualización de detalle de proceso judicial .................... 111

Imagen 46: Interfaz de visualización de registro fotográfico de actuación .......... 112

Imagen 47: Interfaz de administración de tipos de actuación .............................. 113

Imagen 48: Interfaz de autenticación en componente móvil ............................... 113

Imagen 49: Interfaz de validación de credenciales en componente móvil ........... 114

Imagen 50: Interfaz de registro de actuación procesal en componente móvil ..... 114

Imagen 51: Interfaz de registro de actuación procesal en componente web ....... 115

11

GLOSARIO

ACTO PROCESAL (Actuación Procesal): manifestación de voluntad que tiene relevancia procesal y en virtud del cual se crean, modifican o extinguen efectos procesales. ANDROID: sistema operativo basado en el kernel de Linux diseñado principalmente para dispositivos móviles con pantalla táctil, como teléfonos inteligentes o tabletas. API: conjunto de funciones y procedimientos de programación, ofrecido por alguna biblioteca de programación, para ser utilizado por otro software como una capa de abstracción. APLICACIÓN MÓVIL: aplicación informática diseñada para ser ejecutada en teléfonos inteligentes, tabletas y otros dispositivos móviles. APLICACIÓN WEB: aplicación de software que se utiliza accediendo a un servidor web a través de internet o de una intranet mediante un navegador. AUTO: acto emanado del juez o magistrado que no está encaminado a resolver el objeto del debate, sino que se limita a disponer un trámite para impulsar el proceso, definir algún incidente, o cualquier otro aspecto esencial. JURISDICCIÓN: potestad derivada de la soberanía del Estado de aplicar el derecho en casos concretos, resolviendo de modo definitivo una controversia, es ejercida por los tribunales de justicia. CLIENTE LIGERO: software o computador que se encarga de transportar la entrada y salida de información entre el usuario y el servidor remoto, en una arquitectura de red cliente-servidor. DEMANDA: petición formulada ante un tribunal de justicia mediante la cual la parte demandante expone pretensiones frente a la parte demandada. DEMANDA CIVIL: tipo de demanda judicial que siempre es presentada por un particular, ya sea persona natural o jurídica, y que va destinada principalmente al reconocimiento de derechos establecidos legalmente o a la declaración de derechos.

12

DEPENDIENTE JUDICIAL: persona encargada de vigilar los movimientos de los procesos judiciales de un abogado en los juzgados respectivos y tomar copias de los mismos. ETAPA PROCESAL: cada una de las subdivisiones que presentan los procesos, y en cuyo transcurso tienen lugar determinados actos materiales y jurídicos, así como hechos jurídicos. FALLO: acto procesal proveniente de un tribunal de justicia, mediante el cual se resuelve las peticiones de las partes, o autoriza u ordena el cumplimiento de determinadas medidas. FIRMA DIGITAL: mecanismo criptográfico que permite al receptor de un mensaje firmado digitalmente determinar la entidad originadora de dicho mensaje y confirmar que el mensaje no ha sido alterado. INADMISION: Es un acto por el cual el juez se abstiene de darle curso a la demanda cuando ésta no cumple determinados requisitos, y le da al demandante el término de cinco (5) días para que los subsane. INFORMACIÓN PROCESAL: información relacionada con un proceso judicial y su desarrollo. JAVA EE (Java Enterprise Edition): plataforma de programación para desarrollar y ejecutar software de aplicaciones en el lenguaje de programación Java. Permite utilizar arquitecturas de n capas distribuidas y se apoya en componentes de software modulares ejecutándose sobre un servidor de aplicaciones. JUEZ: autoridad pública que sirve en un tribunal de justicia y que se encuentra investido de la potestad jurisdiccional para aplicar la ley y las normas jurídicas. JURISPRUDENCIA: conjunto de decisiones de los tribunales de justicia sobre una materia determinada, de las cuales se puede extraer la interpretación dada por los jueces a una situación concreta. JUZGADO: órgano público cuya finalidad principal es ejercer la jurisdicción, es decir, resolver litigios con eficacia de cosa juzgada. LITIGIO: conflicto de intereses calificado y elevado a una autoridad jurisdiccional por un sujeto de derecho con una intención o pretensión contra otro que manifiesta una resistencia o que se opone al planteamiento del primero. MANIFESTACION: declaración escrita que emana de alguno de los sujetos procesales en un proceso judicial.

13

PERSONAL JURISDICCIONAL: personal envestido con la autoridad de aplicar el derecho en casos concretos, para resolver una controversia. PLAZO PROCESAL: lapso de tiempo dentro del cual, en términos legales, debe realizarse un acto procesal. PROCESO JUDICIAL: conjunto de actos coordinados y sucesivos realizados por los órganos investidos de jurisdicción y los demás sujetos que actúan en él, con el fin de obtener la aplicación de la ley sustancial o material a un caso concreto o particular. RADICACIÓN DE DEMANDA: acto mediante el cual se da por recibida una demanda nueva en un tribunal de justicia. REST: técnica de arquitectura de software para desarrollar servicios en sistemas hipermedia distribuidos. Actualmente se usa el término para describir interfaces web que utilicen el protocolo HTTP sin las abstracciones adicionales de los protocolos basados en patrones de intercambio de mensajes. SENTENCIA: acto mediante el cual un juez o magistrado expresa la voluntad que el estado toma sobre el objeto del proceso SERVICIOS WEB (Web Services): Conjunto de especificaciones que posibilitan la comunicación y provisión de servicios entre diferentes aplicaciones vía web. SISTEMA JUDICIAL: conjunto de instituciones gubernamentales y normas jurídicas, que están en vigor en determinado lugar y época. SOAP: protocolo estándar que define como dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. TERMINO PROCESAL: límite legal de plazo en el cual tiene que realizarse un acto procesal. VENCIMIENTO DE TERMINOS: terminación improrrogable del plazo legal para la realización de actos procesales.

14

0. INTRODUCCIÓN

En el marco legal, y concretamente en el ámbito civil colombiano, cuando es presentada una demanda ante una autoridad jurisdiccional se inicia un proceso judicial, el cual tiene una transición por varias etapas desde la radicación de la demanda hasta la sentencia por parte de un juez; durante cada una de las etapas del proceso ocurren diversos actos que en su gran mayoría quedan plasmados en un documento. Por cada parte implicada en el conflicto usualmente hay un abogado que litiga en el proceso procurando defender los intereses de su respectivo cliente, lo que implica consultar todos los documentos del proceso correspondiente; ya que estos documentos determinan la base para poder generar manifestaciones y entregarlas al juzgado, teniendo un plazo legal para la entrega. En el país existe un elevado índice de demandas civiles, las cuales tienen un procedimiento judicial extenso y de estructura predominantemente escrita para su solución1, además legalmente no existe un límite para la cantidad de procesos judiciales que puede litigar un abogado de manera simultánea y por lo tanto ésta cantidad de procesos litigados paralelamente suele superar el millar. Con el alto volumen de trabajo de los abogados y el largo procedimiento de cada proceso, habitualmente se generan problemas concernientes con la gestión y organización del trabajo debido a la dificultad de llevar un control adecuado de las fechas y plazos en todos los procesos, y aunque cada abogado suele tener asistentes que saquen copias a los actos de los procesos en los juzgados, existe un retraso entre la toma de estas copias y su entrega al abogado, debido a que la alta cantidad de éstas copias implica un considerable gasto de tiempo para su unión y organización. Los problemas de gestión y organización del trabajo afectan tanto a los abogados como a sus clientes, debido a que suelen incumplirse las fechas establecidas para la entrega de manifestaciones al juzgado en algunos procesos, lo cual puede implicar la emisión de fallos en contra en dichos procesos. En este proyecto se propone una solución haciendo uso de las tecnologías de la información, usándolas como herramientas de soporte a la gestión del litigio de los abogados, buscando que la información de los actos procesales se obtenga de manera oportuna y que la información se encuentre organizada y centralizada de manera digital, facilitando el cumplimiento de los términos delimitados dentro del proceso y permitiendo el acceso ágil a la información. Para lograr la solución, dentro del marco de este trabajo de grado se realiza el diseño y desarrollo de un prototipo para apoyar la gestión del litigio de procesos judiciales civiles, que consta

1 Según el informe nacional de competitividad 2011-2012, el 58% de las demandas en Colombia son civiles, las cuales tardan en promedio 1346 días en resolverse, debido entre otras cosas al sistema “excesivamente procesalista” que requiere la participación del juez en todos los actos procesales y que la comunicación entre las partes se realiza por medio de memoriales (Competitividad, 2012)

15

de un componente web y un componente móvil integrados a través de servicios web. Abarcando en este prototipo desde la captura y envío de la información procesal en el juzgado, hasta la compilación, organización y archivo de esta información.

16

1. PLANTEAMIENTO DEL PROBLEMA

1.1 DESCRIPCIÓN DEL PROBLEMA

El sistema judicial actual en Colombia determina que los procesos judiciales cumplan con una serie de actos procesales, los cuales pueden provenir del juez o de las partes intervinientes en el proceso (demandante, demandado y/o terceros). Para que los actos procesales tengan validez es necesario cumplir con los términos que indica la ley, entre los cuales se encuentra el plazo para presentarlos, que puede ir desde dos hasta treinta días. Los actos procesales se realizan en orden secuencial, por consiguiente los abogados tienen la necesidad de vigilar los procesos constantemente para estar al tanto de los actos emanados por las demás partes implicadas en el proceso, y poder así, actuar de manera oportuna según sea el caso. Para llevar a cabo la vigilancia de procesos, los abogados se apoyan de asistentes llamados dependientes judiciales, quienes día a día revisan en los juzgados respectivos los movimientos que se hayan generado dentro del proceso judicial y ya que cada acto implica la generación de un documento, le entregan copias de esta información al abogado para que él pueda realizar las manifestaciones pertinentes. En Colombia es habitual que un abogado litigue en promedio dos mil procesos judiciales de manera simultánea, lo cual implica que debe vigilar diariamente los actos de esta cantidad de procesos en los juzgados, estar pendiente de las fechas de esos actos y generar sus manifestaciones por cada proceso dentro de los plazos que dicta cada juzgado; dado que si se incumplen los plazos dictados se considera como vencimiento de términos y el juzgado no admite la manifestación realizada por el abogado. Actualmente existe un tiempo de retraso entre la captura de la información procesal en los juzgados por parte de los dependientes y la entrega de ésta información al abogado, debido a que el procedimiento de sacar las copias de los actos, unirlas y organizarlas puede tardar entre uno y dos días, dependiendo de la cantidad de procesos. El retraso entre la captura de la información procesal y su entrega al abogado ocasiona que se pierda parte del tiempo que otorga la ley para realización de manifestaciones respecto del acto procesal, lo cual puede provocar la disminución de la calidad de las manifestaciones o hasta el vencimiento de términos, teniendo en cuenta que hay plazos únicamente de dos días. Por ley, cada proceso judicial luego de cerrado debe ser archivado por cada una de las partes durante un periodo de diez años debido a posibles re-aperturas del

17

proceso, de manera que todas las copias de los actos consultados deban ser archivadas, ocasionando que se reserve gran parte del espacio en las oficinas para este fin debido a la alta cantidad de procesos y de documentos que componen cada uno, además del impacto ambiental que supone el uso de esta cantidad de papel.

1.2 FORMULACIÓN DEL PROBLEMA

¿Cómo apoyar la gestión de litigio de procesos judiciales, reduciendo el tiempo de acceso de los abogados a los actos consultados por los dependientes judiciales y manteniendo un registro unificado y ordenado de los actos procesales, con sus respectivas fechas y términos? .

18

2. OBJETIVOS

2.1 OBJETIVO GENERAL

Diseñar y desarrollar un prototipo software para apoyar la gestión de litigio de procesos judiciales civiles, con el uso de tecnologías web y móviles.

2.2 OBJETIVOS ESPECÍFICOS

• Establecer los requerimientos funcionales, no funcionales y de información

necesarios en el ámbito de la gestión de litigio de procesos judiciales civiles.

• Diseñar una arquitectura que permita mantener la información centralizada, y obtener ésta información por medio del uso de clientes web y una aplicación móvil usando protocolos de internet, teniendo como base los requerimientos establecidos.

• Diseñar la interfaz de usuario de la aplicación web y la aplicación móvil de manera que exista una interacción intuitiva entre los usuarios y el sistema.

• Diseñar el modelo lógico y físico de base de datos del sistema incluyendo los datos persistentes tanto de la aplicación web como de la aplicación móvil que permita mantener consistencia en el modelo.

• Desarrollar los diferentes módulos web y móvil del prototipo de sistema de información de manera que se cumplan con las funcionalidades requeridas.

• Diseñar las pruebas del sistema aplicando integración continua como mecanismo de verificación del correcto incremento de funcionalidades.

• Realizar la documentación técnica y de usuario necesaria para el correcto entendimiento del sistema.

• Realizar una estimación beneficio-costo de la implementación del proyecto.

19

3. JUSTIFICACIÓN

La implementación de tecnologías de información y telecomunicaciones ha crecido enormemente en los últimos años incluyendo el ámbito de la administración, debido al gran aporte de utilidad que las herramientas tecnológicas brindan en este tema; el contexto de la administración de justicia no ha sido la excepción, ya que alrededor del mundo se han ido implementando diversas estrategias tecnológicas para apoyar esta gestión. Uno de los primeros casos de implementación de tecnologías de información y comunicación en el sistema judicial en América Latina es Costa Rica, que hace uso de expedientes electrónicos en los procesos judiciales y permite realizar toda la comunicación del proceso judicial, tal como consultar, notificar y contestar las demandas totalmente de manera digital, logrando desde su implementación la agilización en el avance de los procesos judiciales y la reducción de la saturación de los juzgados (Madrigal, 2005). Para el caso colombiano, aunque se tiene planeada la implementación de tecnologías de información para optimizar la gestión de la rama judicial, ésta no ha tenido avance en su ejecución y puede demorarse aún muchos años, lo cual sumado con los altos niveles de congestión judicial generan un ambiente complicado para los usuarios del sistema judicial colombiano el cual, además, es diagnosticado como ineficiente (Competitividad, 2013) De manera que actualmente en Colombia la forma en la que se da curso a un proceso judicial es manual, siendo esto especialmente impactante para los usuarios del sistema en el caso de la notificación de las actuaciones, ya que la forma en la que se producen las notificaciones es por medio de planillas publicadas en lugares visibles al público que indican el número del proceso, las partes implicadas, la actuación ocurrida y la fecha a partir de la cual surte efecto dicha actuación. Este tipo de notificación aplica para todas las actuaciones del proceso y para cualquiera de las decisiones del juez, incluyendo en las que las partes implicadas en el proceso tienen un plazo de tiempo para proceder de acuerdo a las decisiones del juez, y aunque este plazo es establecido por la ley, es impredecible el momento en el que el juez se va a manifestar sobre un proceso determinado. Teniendo en cuenta la condición del sistema judicial, dentro del contexto del litigio de procesos judiciales, los abogados deben revisar el movimiento de las actuaciones diariamente para evitar el vencimiento de términos en la entrega de manifestaciones al juez. Pero debido a la alta cantidad de procesos simultáneos de cada abogado se presenta una dificultad de llevar control sobre todos los procesos, fechas y plazos y por lo tanto es bastante común el problema de vencimiento de términos; situación que además afecta al sistema judicial en sí, ya

20

que al no poder seguir con el curso normal del proceso haciendo entrega de las respectivas manifestaciones al juzgado, es una práctica habitual por los abogados abrir otro proceso judicial con las mismas demandas, contribuyendo de esta manera en la saturación del sistema judicial. Además de la dificultad de llevar control en la vigilancia de procesos, se debe considerar que una vez que el juzgado ha generado una manifestación, empieza a contarse el tiempo para que los abogados de las partes procedan de acuerdo a la manifestación, y ya que éste plazo va desde 2 hasta 30 días algunas veces el tiempo entre la captura de una manifestación y su puesta en conocimiento al abogado es mayor que el plazo dado por ley para responder al juez, dado que los asistentes del abogado deben recorrer todos los juzgados, sacar copias o fotografías de las actuaciones, organizarlas y luego entregarlas al abogado, y estas actividades suelen tardar entre 1 y 2 días, debido a la alta cantidad de procesos litigados simultáneamente por el abogado, haciendo que no se aproveche de manera óptima el tiempo dado por el juzgado para manifestarse. En el contexto tecnológico, actualmente es popular el uso de aplicaciones web, ya que éstas al tener navegadores web como clientes ligeros permiten mantener independencia del sistema operativo, con disponibilidad de acceso 24 horas al día y desde cualquier lugar que se disponga de conexión a internet, manteniendo toda la información centralizada y favoreciendo la gestión de usuarios. Adicionalmente, el uso de aplicaciones móviles proporciona portabilidad y disponibilidad en cualquier lugar, con la posibilidad de hacer uso en la aplicación de los dispositivos integrados al teléfono o tableta, tales como cámara o receptor GPS entre otros. Además, actualmente existe una gran aceptación y difusión de los dispositivos móviles, teniendo en cuenta que en los últimos años el uso de dispositivos móviles se ha incrementado a un ritmo bastante acelerado, y en Colombia la difusión de dispositivos móviles “inteligentes” ha sido particularmente alta, ya que la activación de éstos creció 278% en el año 2012, mismo año en el que el país fue el de mayor tasa de adopción de dispositivos móviles “inteligentes” en el mundo (Farago, 2013). Por lo tanto, teniendo en cuenta la disponibilidad y aceptación de los dispositivos móviles “inteligentes” en el país, en este proyecto se pretende aprovechar sus funciones multimedia, de conectividad y procesamiento, junto con la disponibilidad, portabilidad y centralización de información que proporcionan las aplicaciones web, en favor de la gestión del litigio de procesos judiciales civiles, ya que en ese tipo de procesos todas las actuaciones se realizan por medio de documentos y actualmente tiene la tasa de procesos más alta en Colombia; esto con el fin de reducir el tiempo de recepción de la información procesal, disminuir la probabilidad de errores y optimizar los procedimientos de gestión, archivo y control de los procesos judiciales por parte de los abogados, además de reducir el gasto de papel utilizado.

21

22

4. ALCANCES Y LIMITACIONES

4.1 ALCANCES

Se desarrollará un prototipo de software que contemple un componente web y un componente para dispositivos móviles, los cuales para efectos del presente proyecto se realizarán usando el lenguaje de programación Java en su plataforma Enterprise Edition 6 para el componente web, y el sistema operativo Android para el componente móvil; realizando la integración entre los dos sistemas por medio de Servicios Web. El prototipo permitirá registrar, consultar y archivar procesos judiciales, además de capturar, transmitir y organizar la información de los actos procesales; haciendo uso de los siguientes módulos:

• Registro de procesos judiciales: Éste permitirá registrar de manera web nuevos procesos judiciales en el sistema.

• Consulta de procesos judiciales: Éste permitirá consultar de manera web los procesos judiciales registrados en el sistema y sus respectivos actos asociados.

• Captura y envió de información de actos procesales: Éste permitirá registrar con el uso de dispositivos móviles la información de los actos procesales junto con las fotografías de los mismos, y enviarla al servidor web a través de internet.

• Recepción y organización de información de actos procesales: Éste permitirá recibir en el servidor web la información de los actos procesales enviados desde el dispositivo móvil, para organizarla y persistirla para que pueda ser consultada por la aplicación web.

• Autenticación de usuarios: se trata del módulo transversal al sistema, que permitirá controlar el acceso al sistema teniendo como base los roles abogado y dependiente.

23

4.2 LIMITACIONES

El prototipo contempla únicamente la gestión para procesos judiciales del tipo civil, ya que cada tipo de proceso judicial tiene principios, etapas y procedimientos completamente diferentes, y en los otros tipos de procesos se pueden incluir actos procesales no documentados en papel. Por facilidad de investigación, la distribución de juzgados civiles que se tuvo en cuenta dentro del prototipo fue limitada a la ciudad de Bogotá. Debido a que se trata de un prototipo, el sistema no implementa un sistema de creación y gestión de usuarios, sino que asume la existencia de un abogado y un dependiente judicial. Para facilitar el desarrollo del sistema y evitar el costo de licencias, el proyecto se realizó haciendo uso exclusivo de herramientas de software libre. Dentro de las pruebas realizadas al prototipo no se contempla la ejecución de pruebas de desempeño, y por lo tanto no es posible conocer el desempeño del sistema en ambiente de producción. En el prototipo no se aplican atributos y políticas de seguridad necesarias para un proyecto con el nivel de confidencialidad requerida, para ser usado en ambiente de producción.

24

5. MARCO CONCEPTUAL

Dentro del contexto judicial es necesario entender los conceptos relacionados con los procesos judiciales civiles y su respectivo el procedimiento dentro del cual se encuentran las etapas procesales y los actos procesales.

5.1 PROCESO JUDICIAL

El proceso judicial se puede definir como “la serie de actos que se desenvuelven progresivamente, con el objeto de resolver, mediante un juicio de autoridad, el conflicto sometido a su decisión” (Couture, 1958), por lo tanto en un proceso siempre existen dos partes entre quienes se presenta el litigio y un funcionario judicial que imparte el juicio de autoridad.

5.1.1 Clasificación de los procesos judiciales

En el estado colombiano la rama judicial es la encargada de administrar justicia, facultad que se lleva a la práctica mediante diferentes órganos del poder público y diferentes jurisdicciones. Cada funcionario de la rama judicial tiene su jurisdicción, siendo:

• Jurisdicción ordinaria : Los jueces que hacen parte de esta jurisdicción hacen uso del derecho para dirimir conflictos y decidir controversias entre particulares.

• Jurisdicción contenciosa administrativa : Los jueces de esta jurisdicción solucionan conflictos que se presentan entre particulares y el Estado, o conflictos que se presentan al interior del estado mismo.

• Jurisdicción constitucional : Es la rama de la justicia que vela por la supremacía de la Constitución Política Colombiana y el estado de derecho en todo el territorio nacional. Todos los jueces de la nación pertenecen a esta rama en primera instancia.

• Jurisdicción disciplinaria: Es la encargada de administrar el presupuesto, la disciplina y la organización de la rama judicial colombiana.

• Jurisdicción especial: La presente rama judicial reconoce la jurisdicción especial indígena y autoriza a la ley para la creación y administración de jueces de paz al interior del territorio nacional, encargados de resolver conflictos a partir de un criterio de equidad y con la característica especial de ser elegidos por votación popular.

Las diferentes jurisdicciones son divididas a su vez en especialidades o ramas, tomando en consideración diversos ordenamientos de carácter sustancial que

25

sirven como medio para dar cumplimiento al proceso, teniendo un ordenamiento positivo (código) por cada especialidad que lo regula en su totalidad. Para el caso de la jurisdicción ordinaria, ésta se divide en:

• Civil • Penal • Laboral • De familia • De comercio • Agraria

Además de la jurisdicción, los procesos pueden dividen también de acuerdo a la competencia y al factor de competencia, siendo la competencia el conjunto de funciones que se le atribuyen a un juez para ejercer su jurisdicción en determinados asuntos, siendo los factores determinantes para la competencia de un proceso civil los siguientes:

• Factor objetivo: Atiende a la naturaleza o la cuantía del asunto • Factor subjetivo: Tiene en cuenta los sujetos intervinientes en el proceso. • Factor funcional: Tiene en cuenta la instancia del proceso. • Factor territorial: Tiene en cuenta el lugar del territorio nacional donde deba

tramitarse el proceso. • Factor de conexión: Relacionado con las pretensiones del demandante.

Dentro de los aspectos del factor objetivo la naturaleza se relaciona de manera directa con la pretensión, refiriéndose al interés de las partes en relación con la decisión que se tome en la sentencia; se divide en:

• Contencioso: cuando existe controversia, litigio o intereses encontrados y es iniciado por una demanda.

• Voluntario: no existe litigio sino interesados que reclaman para sí el reconocimiento de un derecho, este tipo de proceso inicia con una solicitud.

El aspecto de la cuantía se determina por la suma de todas las pretensiones a la fecha de la presentación de la demanda, clasificándose en:

• Mínima cuantía • Menor cuantía • Mayor cuantía

De acuerdo a todas estas clasificaciones se define el tipo de juez que conocerá un proceso determinado, esto es definido al momento de ser presentada la demanda. Para el caso de los procesos civiles, los jueces que pueden conocer un proceso

26

son Civiles municipales, Del circuito, Tribunales, Corte suprema de justicia y, recientemente, jueces de pequeñas causas.

5.1.2 Secuencia de los procesos judiciales civiles

Como parte del derecho al debido proceso, los procesos judiciales deben seguir una secuencia definida dependiendo de la clasificación ya que cada tipo de proceso tiene una secuencia diferente definida en su código de procedimiento; para el caso de los procesos judiciales de tipo civil la secuencia puede ser definida teniendo en cuenta los diferentes artículos del código de procedimiento civil colombiano (CPC) como se puede apreciar en la Imagen 1, en cada etapa pueden existir múltiples actuaciones, siendo las etapas marcadas en las que hay manifestaciones de respuesta por las partes implicadas en el proceso y que tienen un plazo para realizarse. Imagen 1: Etapas de un proceso civil colombiano

Fuente: Elaboración propia

1. Presentación de la demanda: un proceso judicial en general se inicia cuando una de las partes presenta una demanda ante la autoridad jurisdiccional.

2. Calificación de la demanda: Luego de presentada la demanda, el juez competente observa si se cumplen los requisitos legales para aceptar la demanda, y puede ya sea rechazarla, inadmitirla o admitirla. (CPC Art. 84, Art. 85 y Art. 86).

27

3. Notificación de la demanda: Es el momento procesal en el cual se le da a conocer a la parte demandada u otros sujetos procesales la existencia de la demanda. (CPC Art 87, Art 315, Art 318, Art. 320 y Art. 330).

4. Contestación de la demanda: Es un pronunciamiento expreso que hace la parte demandada sobre las pretensiones y los hechos de la demanda, con indicación de los que se admiten y los que se niegan y dado el caso podrá adjuntar las pruebas pertinentes. (CPC Art 92).

5. Etapa Probatoria Es el momento procesal en el cual el juez toma a consideración todo el material probatorio que le ha sido suministrado por las partes en el proceso, ya que toda decisión judicial debe fundamentarse en las pruebas que han sido allegadas de manera regular y oportuna. (CPC Art 174).

6. Resolución: Se da cuando el juez, después de haber tenido en cuenta las pruebas y demás actos procesales que se hayan llevado a cabo dentro del proceso, toma una decisión respecto a las pretensiones de la demanda.(CPC Art. 304, Art 331)

7. Ejecución de la sentencia: Es el momento en el cual se hacen efectivas las disposiciones que están contenidas dentro de la sentencia, la forma de hacerlas efectivas se reglamentan en los artículos 334 y 335 del código de procedimiento civil colombiano. (CPC Art. 334, Art. 335)

8. Terminación del proceso: Una vez se haya ejecutado la sentencia a cabalidad se declara mediante auto la terminación del caso. En caso de no haberse ejecutado la sentencia el proceso puede terminar de manera anormal. (CPC Titulo XVI, Titulo XVII).

28

5.2 ACTOS PROCESALES

Los actos procesales cobran vital importancia en los procesos judiciales ya que éstos son los que definen el proceso como tal, entendiendo el acto procesal como un “acto jurídico emanado de las partes, de los agentes de la jurisdicción o aun de los terceros ligados al proceso, susceptible de crear, modificar o extinguir efectos procesales” (Couture, 1958). Todo acto procesal involucra un conjunto de elementos que lo definen, estos elementos son los sujetos, el objeto, la actividad y el tiempo. (Universidad Católica de Colombia, 2010).

• Sujetos : Personas de quienes el acto procesal emana o están representados por quienes tienen esa calidad en el proceso, es decir, el funcionario jurisdiccional y las partes, aunque se pueden incluir otras personas que también participan, tales como los auxiliares de la justicia y ciertos órganos de pruebas como por ejemplo los testigos.

• Objeto : lo constituye el aspecto sobre el cual versa y la finalidad que con él persigue el sujeto que lo realiza.

• Actividad : también denominada formas procesales, consistente en las circunstancias de lugar, tiempo y modo en que deben llevarse a cabo los actos procesales.

• Tiempo: se refiere al lapso dentro del cual el acto procesal debe realizarse, de acuerdo con la ley procesal se le denomina términos. Los términos cumplen una función primordial en el proceso, porque demarcan las diferentes etapas que él comprende, tanto para su iniciación como para su terminación. Los términos se cuentan a partir del día siguiente a la notificación de la providencia que lo fija, o a partir del día siguiente de la última notificación.

5.2.1 Tipos de actos procesales

En términos generales se pueden distinguir dos tipos de actos procesales, los actos emanados de las partes y los actos emanados del personal jurisdiccional (jueces). (Universidad Católica de Colombia, 2010) 5.2.1.1 Actos emanados de las partes. Las partes pueden realizar manifestaciones de disposición sobre los derechos e intereses que se discuten en el proceso, siempre y cuando sean titulares del mismo. Las manifestaciones pueden ser:

• Peticiones . Son manifestaciones en las que se pide algo al órgano judicial. La petición puede ser de fondo cuando se pide un pronunciamiento

29

concreto sobre el objeto del litigio, o interlocutoria cuando se pide una determinada actuación en la tramitación del procedimiento, como por ejemplo la citación de un testigo.

• Alegatos . Son manifestaciones que realizan las partes para suministrar al órgano judicial los elementos fácticos y jurídicos en que fundan su posición en el proceso y que estiman deben ser tenido en cuenta por el mencionado órgano al resolver el mismo.

• Aportes de pruebas . son manifestaciones que sirven como soporte del elemento factico, aportando al órgano judicial elementos de convicción que apoyan su posición en el proceso, y con base en los que consideran que el órgano judicial debe fijar los hechos que fundamenten su posterior resolución.

5.2.1.2 Actos emanados del personal jurisdiccional El personal jurisdiccional (Jueces y Magistrados), realiza manifestaciones resolutorias, encaminadas a resolver el objeto del litigio y las incidencias procesales que plantee su tramitación; las manifestaciones pueden ser:

• Providencias . También conocidas como sentencias, son manifestaciones mediante las cuales un juez o magistrado expresa la voluntad que el estado toma sobre el objeto del proceso, es decir, las pretensiones formuladas por el demandante y la conducta que debería adoptar el demandado frente a ellas.

• Autos . Son manifestaciones emanadas del juez o magistrado que no está encaminado a resolver el objeto del debate, sino que se utilizan para disponer un trámite de impulso para el proceso, definir algún incidente, o cualquier otro aspecto esencial dentro del transcurso del proceso.

30

6. MARCO TECNOLÓGICO

Dentro del contexto tecnológico se hace necesario aclarar los conceptos relacionados con las tecnologías utilizadas en el desarrollo del proyecto, tales como las relacionadas con aplicaciones web, aplicaciones móviles, servicios web y bases de datos.

6.1 APLICACIONES WEB

Se denomina aplicación web a aquellas herramientas que los usuarios pueden utilizar accediendo a un servidor web a través de internet o de una intranet mediante un navegador web. Las aplicaciones web usan el navegador web como cliente ligero, su ejecución es independiente del sistema operativo, y pueden ser actualizadas sin distribuir e instalar software a todos los usuarios. Una aplicación web es estructurada como una aplicación de varias capas, siendo la estructura más común la de tres capas; en la cual la presentación es la primera capa, que es accesible a través de un navegador web, la segunda capa corresponde a la lógica de la aplicación, ejecutada por un motor capaz de usar alguna tecnología web dinámica, y la tercera capa es la de almacenamiento que comúnmente implica una base de datos. En esta estructura el navegador web manda peticiones a la capa intermedia que ofrece servicios valiéndose de consultas y actualizaciones a la base de datos y a su vez proporciona una interfaz de usuario, permitiendo que el usuario acceda a los datos de modo interactivo. (Wikipedia)

6.1.1 Java Enterprise Edition (Java EE)

Es una plataforma de computación que hace parte de la plataforma Java, la cual proporciona APIs y un ambiente de ejecución para desarrollar y ejecutar software de aplicaciones empresariales, las cuales normalmente se desarrollan de manera modular y con el uso de N capas distribuidas ejecutándose sobre servidores de aplicaciones. Las APIs deJEE cumplen con funciones importantes de las aplicaciones típicamente empresariales, tales como persistencia, envío de mensajes, exposición y consumo de servicios web, invocaciones remotas de métodos, envío de correos, transacciones en red, entre otras, además define como coordinar estas funciones entre sí. Asimismo Java EE tiene especificaciones únicas para componentes, entre los cuales se encuentran los EJB, Servlets, JSF, JSP, y Portlets. Los componentes son desplegados en diferentes contendedores que ofrecen una serie de servicios.

31

6.1.1.1 Arquitectura. El conjunto de especificaciones de Java EE son implementadas en diferentes contenedores, los cuales son ambientes de ejecución que proveen ciertos servicios a los componentes que almacenan, dentro de estos servicios se encuentran la gestión de ciclo de vida, la inyección de dependencia, manejo de concurrencia, entre otros. Los componentes usan contratos bien definidos para comunicarse con la infraestructura de Java EE y con los otros componentes. Los componentes se empaquetan en una forma estándar para ser desplegados. Java EE es una extensión de la plataforma Java SE, lo cual significa que las APIs de Java SE pueden ser usadas en los componentes Java EE. La Imagen 2 muestra las relaciones lógicas entre los contenedores. Las flechas representan los protocolos usados por los contenedores para acceder a otros. Imagen 2: Contenedores Java EE estándar

Fuente: (Goncalvez, 2013) 6.1.1.2 Componentes. El ambiente de ejecución de Java EE define cuatro tipos de componentes que una implementación puede soportar:

• Applets. Son aplicaciones graficas que son ejecutadas en un navegador web, hacen uso del API de Swing para generar las interfaces de usuario.

32

• Aplicaciones. Son programas que son ejecutados sobre un cliente, típicamente son interfaces graficas de usuario o programas de procesamiento por lotes que tienen acceso a todas las funciones de la capa media de Java EE.

• Aplicaciones web. Son aplicaciones ejecutadas en un contenedor web y responden a solicitudes HTTP de clientes web. Tienen soporte para servicios web tipo SOAP y RESTful, las aplicaciones web también pueden contener EJBs Lite.

• Aplicaciones empresariales. Son aplicaciones ejecutadas en un contenedor EJB. Los EJBs son componentes gestionados por el contenedor para procesar lógica de negocio transaccional. Pueden ser accedidos tanto local como remotamente a través de los protocolos RMI o HTTP para servicios web.

6.1.1.3 Contenedores. La infraestructura de Java EE esta particionada en dominios lógicos llamados contenedores. Cada contenedor tiene un rol específico, soporta un conjunto de APIs y ofrece diferentes servicios a los componentes, tales como seguridad, acceso a base de datos, manejo de transacciones, inyección de recursos o directorio de nombres. Los contenedores ocultan la complejidad técnica e incrementa la portabilidad. Dependiendo de la clase de aplicación que se quiera construir, se escogen los contenedores a usarse, por ejemplo si se va a construir una aplicación web, se desarrolla una capa JSF con una capa EJB Lite y se despliegan en un contenedor web. Pero en el caso de construir aplicaciones web que invoquen la capa de negocios remotamente y use llamadas y mensajes asíncronos, se requiere el uso de los contenedores web y EJB. Java tiene cuatro contenedores diferentes:

• Contenedor de aplicaciones cliente. Incluye un conjunto de clases Java, librerías, y otros archivos requeridos para brindar inyección, gestión de seguridad, y servicio de nombrado a las aplicaciones Java SE. El contenedor se comunica con el contenedor EJB usando el protocolo RMI y con el contenedor web usando HTTP (para servicios web).

• Contenedor web. Provee los servicios necesarios para el manejo y ejecución de componentes web como servlets, EJB Lite, JSPs, filtros, paginas JSF y servicios web. Es responsable por la instanciación, inicialización e invocación de servlets y el soporte de los protocolos HTTP y HTTPS. Es el contenedor usado para alimentar las páginas web a los navegadores cliente.

• Contenedor EJB. Es el responsable de manejar la ejecución de los Enterprise beans (sesión beans y message-driven beans) conteniendo la capa de lógica de negocio de las aplicaciones Java EE. El contenedor crea nuevas instancias de EJBs, maneja su ciclo de vida y proporciona servicios

33

tales como transacción, seguridad, concurrencia, distribución, servicio de nombrado, y la posibilidad de ser invocados asincrónicamente.

• Contenedor de applets. Es proporcionado por los navegadores web para ejecutar los componentes applet. El contenedor proporciona un ambiente seguro para las aplicaciones applet, usando un modelo de seguridad que previene que cualquier código descargado a maquinas locales puedan acceder a recursos del sistema, como procesos y archivos.

6.1.1.4 Servicios. Los contenedores proveen servicios a sus componentes desplegados, en la Imagen 3 se pueden apreciar los servicios proporcionados por cada contenedor. Los siguientes son los servicios ofrecidos por la plataforma Java EE:

• JTA (Java Transaction API). Este servicio ofrece un API de transacción usada por el contenedor y la aplicación. Además proporciona una interfaz entre el gestor de transacciones y el gestor de recursos en el nivel de la interfaz proveedora de servicio.

• JPA (Java Persistence API). Es una API estándar para el mapeo objeto-relacional, que incluye el lenguaje JPQL para creación de sentencias a la base de datos de manera estándar independientemente del motor de base de datos utilizado.

• Validación (Bean Validation). Proporciona declaración de restricciones y facilidades de validación a nivel de clases y métodos.

• JMS (Java Message Service). Este permite a los componentes comunicarse de manera asincrónica a través de mensajes, soporta mensajes punto a punto (P2P) siguiendo el modelo publicador-subscriptor.

• JNDI (Java Naming and Directory Interface). Esta API, incluida en Java SE, es usada para acceder a sistemas de nombres y directorio. Las aplicaciones usan esta API para asociar nombres a objetos y luego para encontrar esos objetos en un directorio. Se pueden buscar fuentes de datos, fabricas JMS, EJBs, y otros recursos.

• JavaMail. API que proporciona la habilidad de implementar el envío de correos electrónicos.

• JAF (JavaBeans Activation Framework). API incluida en Java SE, proporciona un fremework para el manejo de datos en diferentes tipos MIME, esta es usada por JavaMail.

• Procesamiento XML. Debido a que muchos de los componentes de Java EE pueden ser desplegados con descriptores de despliegue XML, y las aplicaciones a menudo tienen que manipular documentos XML, el API para procesamiento XML (JAXP) proporciona soporte para convertir documentos con APIs SAX y DOM, así como XSLT.

• JSON processing. API que permite a las aplicaciones convertir, generar, transformar y buscar documentos JSON.

34

• JCA (Java EE Connector Architecture). Los conectores permiten acceder a los sistemas de información empresariales desde un componente Java EE, esos sistemas pueden ser bases de datos, programas ERPs o computadores centrales.

• Servicios de seguridad. El servicio de autenticación y autorización de Java (JAAS) permite a los servicios autenticarse y forzar controles de acceso a los usuarios. El contrato de proveedor de servicio de autorización para contenedores (JACC) define un contrato entre un servidor de aplicaciones y un proveedor de servicio de autorización, permitiendo que los proveedores de servicios de autorización sean enlazados dentro de un producto Java EE. La interfaz de proveedores de servicios de autenticación para contenedores (JASPIC) define una interfaz estándar con la cual los módulos de autenticación pueden ser integrados con los contenedores de manera que esos módulos puedan establecer las identidades de autenticación usadas por los contenedores.

• Servicios Web. Java EE provee soporte para servicios web tipo SOAP y RESTful, el API para servicios web XML (JAX-WS) proporciona soporte para los servicios web usando el protocolo SOAP/HTTP. El API para los servicios web RESTful (JAX-RS) proporciona soporte para servicios web que usen el estilo REST.

• Inyección de Dependencias. Permite que los recursos como fuentes de datos, unidades de persistencia y EJBs, entre otros, puedan ser inyectados en componentes.

• Gestión. Java EE define APIs para el manejo de contendedores y servidores usando un “Enterprise Bean”. El API para manejo de extensiones (JMX) también es usada para proporcionar algún suporte de gestión.

• Despliegue. La especificación de despliegue de Java EE define un contrato entre herramientas de despliegue y los productos Java EE para estandarizar el despliegue de aplicaciones.

35

Imagen 3: Servicios proporcionados por los contenedores Java EE

Fuente: (Goncalvez, 2013) 6.1.1.5 Protocolos de Red. Como se puede apreciar en la Imagen 3 los componentes desplegados en contenedores pueden ser invocados a través de diferentes protocolos, los protocolos soportados por Java EE son los siguientes:

• HTTP. Es el protocolo web, el cual es el más usado en las aplicaciones modernas. El API del lado de cliente es definida por el paquete java.net en Java SE, y el API del lado del servidor HTTP es definida por servlets, interfaces JSP y JSF, así como servicios web SOAP y RESTful.

• HTTPS. Es una combinación de HTTP y el protocolo SSL • RMI-IIOP. Invocación remota de métodos (RMI) permite invocar objetos

remotos independientemente del protocolo subyacente. El protocolo RMI nativo en Java SE es el Java Remote Method Protocol (JRMP). RMI-IIOP es una extensión de RMI usada para integrar con CORBA. El lenguaje de descripción de interfaces Java (IDL) permite a los componentes de aplicación Java EE invocar objetos CORBA externos usando el protocolo IIOP. Los objetos CORBA pueden ser escritos en diversos lenguajes incluyendo Java.

36

6.1.1.6 Empaquetado Para que un componente sea desplegado en un contendedor, primero debe ser empaquetado en un archivo de formato estándar. Java SE define los archivos .jar (Java Archive) los cuales son usados para agregar muchos archivos (como clases Java, descriptores de despliegue, recursos o librerías externas) dentro de un archivo comprimido. Como se puede ver en la Imagen 4 Java EE define diferentes tipos de módulos que tienen su propio formato de empaquetado basado en el formato jar. Imagen 4: Archivos en contenedores Java EE

Fuente: (Goncalvez, 2013) Los tipos de módulos son:

• Módulo de aplicación cliente: Contiene clases java y otros recursos empaquetados en un archivo jar, este jar puede ser ejecutado en un ambiente Java SE o en un contenedor de aplicación cliente. Como cualquier otro formato de archivo, los archivos jar contienen un directorio opcional META-INF para la meta información que describe el archivo.

• Módulo EJB: Contiene uno o más beans de sesión o beans orientados a mensajes empaquetados en un archivo jar. Este puede ser desplegados solo en un contenedor de EJBs.

• Módulo de aplicación web: Contienen servlets, JSPs, páginas JSF y servicios web, así como otros archivos relacionados (HTML, CSS, JS, imágenes, videos, etc). Además un módulo de aplicación web puede también contener beans EJB Lite (un subconjunto del API EJB). Todos esos

37

artefactos son empaquetados en un archivo jar con la extensión .war (Web Archive).

• Módulo empresarial: Puede contender cero o más módulos de aplicación web, cero o más módulos EJB, y librerías. Todos es empaquetado dentro de un archivo empresarial con extensión .ear, el despliegue de esos módulos se realiza de manera simultánea y coherente. El directorio lib es usado para compartir librerías comunes entre los módulos.

38

6.2 APLICACIONES MÓVILES

Una aplicación móvil es una aplicación informática para ser ejecutada en teléfonos inteligentes, tabletas y otros dispositivos móviles. Por lo general se encuentran disponibles a través de plataformas de distribución, operadas por las compañías propietarias de los distintos sistemas operativos móviles. (Wikipedia) Las aplicaciones para dispositivos móviles se han popularizado debido a la portabilidad y versatilidad de los dispositivos, ya que comúnmente cuentan con una gran cantidad de dispositivos integrados como cámara, receptor gps y acelerómetro, entre otros, además de poder conectarse a internet. Aunque durante el desarrollo de aplicaciones móviles se debe tener en cuenta las limitaciones de estos dispositivos, ya que dispositivos móviles funcionan con batería y comúnmente tienen procesadores menos poderosos que los computadores personales.

6.2.1 Android.

Android es un sistema operativo de código libre, basado en una versión modificada de Linux, diseñado principalmente para dispositivos móviles con pantalla táctil como smartphones y tablets, aunque tiene interfaces especializadas para su ejecución en televisores, automóviles y relojes de muñeca que puedan soportarlo. En los últimos años Android ha sido el sistema operativo para dispositivos móviles más usado en el mundo2 y tiene más de un millón de aplicaciones publicadas en su plataforma oficial de distribución de aplicaciones, llamada Google Play. El desarrollo de aplicaciones en Android tiene como su principal ventaja que una aplicación puede ser ejecutada en muchos dispositivos diferentes, siempre y cuando estos tengan el sistema operativo. 6.2.1.1 Características. Dado que Android es de código abierto y disponible de manera libre a los fabricantes para modificaciones, no hay configuraciones fijas de hardware o software. Aunque Android por sí mismo soporta las siguientes características:

• Almacenamiento: el almacenamiento interno de datos de las aplicaciones puede lograrse con el uso de SQLite, una base de datos relacional ligera disponible de manera nativa.

• Conectividad: soporta los tipos de redes y conexiones GSM/EDGE, IDEN, CDMA, EV-DO, UMTS, Bluetooth, Wi-Fi, LTE, y WiMAX.

• Envío de mensajes: soporta SMS y MMS.

2 http://www.businessinsider.com/androids-share-of-the-computing-market-2014-3

39

• Navegación Web: basada en el motor de navegación web de código abierto WebKit, junto con el motor de JavaScript.

• Soporte multimedia: incluye soporte para diferentes formatos multimedia como: H.263, H.264 (en un contenedor MP4 o 3GP), MPEG-4 SP, AMR, AMR-WB (en un contenedor 3GP), AAC, HE-AAC (en un contenedor MP4 o 3GP), MP3, MIDI, Ogg Vorbis, WAV, JPEG, PNG, GIF y BMP.

• Soporte de hardware: sensor de acelerómetro, cámara, compas digital, sensor de proximidad y GPS.

• Multi-tarea: soporta aplicaciones con tareas concurrentes. • Multi-touch: soporta pantallas multitouch. • Soporte para flash: a partir de la versión 2.3 de android cuenta soporte para

la ejecución de flash 10.1 • Tethering: soporta la función de compartir conexión a internet, con el

dispositivo móvil actuando como punto de red tanto alámbrico como inalámbrico.

6.2.1.2 Arquitectura de Android. El sistema operativo Android está dividido en cinco secciones, organizadas en cuatro capas principales, como se puede ver en la Imagen 5. Las secciones son:

• Kernel Linux: esta es el kernel en el cual Android está basado, esta capa contiene todos los controladores de bajo nivel del dispositivo para los distintos componentes de hardware de un dispositivo Android.

• Librerías: Esta contiene todo el código que proporciona las características

principales de un sistema operativo Android.

• Ambiente de ejecución: en la misma capa de las librerías, el ambiente de ejecución proporciona un conjunto de librerías del núcleo que permite a los desarrolladores escribir aplicaciones Android usando el lenguaje de programación Java. El ambiente de ejecución también incluye la máquina virtual Dalvik, la cual permite a cada aplicación ejecutarse en su propio proceso, con su propia instancia de la máquina virtual, ya que las aplicaciones de Android son compiladas como ejecutables. Dalvik es una máquina virtual especializada diseñada específicamente para Android y optimizada para dispositivos móviles con memoria y procesamiento limitados.

• Framework de aplicaciones: Expone varias de las capacidades del sistema

operativo Android a los desarrolladores de aplicación de tal manera que ellos puedan hacer uso de ellas en sus aplicaciones.

• Aplicaciones: esta es la capa superior, en la cual se encuentran las aplicaciones del dispositivo.

40

Imagen 5: Secciones y capas principales del sistema operativo Android

Fuente: (Lee, 2012) 6.2.1.3 Versiones de Android. El sistema operativo Android tuvo su primera versión comercial en Septiembre del 2008 con la versión 1.0, y a partir de esto ha venido haciendo actualizaciones al sistema operativo en las cuales agrega alguna funcionalidad o cambia características. Las versiones de Android con sus características más relevantes son las siguientes:

• Android 1.6, Donut: Con funciones de red necesarias para realizar navegación web

• Android 2.0, Eclair: Organización de las aplicaciones y widgets a través de múltiples pantallas y carpetas.

• Android 2.2, Froyo: Se incluye entrada de texto y ejecución de acciones a través de entrada de voz.

• Android 2.3, Gingerbread: Soporte para acciones basadas en sensores de la pantalla del dispositivo, tales como como deslizar e inclinar.

• Android 3.0, Honeycomb: Versión optimizada para ser ejecutada en tablets. • Android 4.0, Ice Cream Sandwich: A partir de esta versión se redefine el

diseño del sistema operativo, siendo funcional tanto para tablets como para dispositivos Smartphone más pequeños.

41

• Android 4.1, Jelly Bean: Se optimiza la velocidad y se mejoran las gráficas, además de la inclusión del asistente personal inteligente Google Now.

• Android 4.4, KitKat: Se refina el diseño y se cambian algunas características internas del sistema buscando la optimización del rendimiento.

La Imagen 6 muestra el porcentaje de uso de las diferentes versiones a nivel mundial. Imagen 6: Porcentaje de uso de las diferentes versiones de Android

Datos recolectados durante un periodo de 7 días, terminando el 06 de abril de 2015 (Versiones con menos de 0.1% no son mostradas) Fuente: (Google Inc, 2015) Según estos datos, la versión de Android más usada actualmente es KitKat, que corresponde al 41.4% de los dispositivos, seguida de Jelly Bean con el 40.7%

42

6.3 SERVICIOS WEB

Un servicio Web es un sistema de software diseñado para soportar la interacción interoperable entre diferentes dispositivos sobre una red y por lo tanto son consumidos programáticamente. Suelen ser APIs Web que pueden ser accedidas dentro de una red, comúnmente Internet, y son ejecutados en el sistema que los aloja teniendo una interfaz descrita en un formato entendible por los diferentes sistemas (Kalin, 2009). De manera que un servicio web es un sistema de software distribuido cuyos componentes pueden ser desplegados y ejecutados en dispositivos fisicamente diferentes, en su forma mas basica consta de un servidor del servicio y un cliente que accede a el, como puede verse en la Imagen 7. Imagen 7: Servicio web y uno de sus clientes

Fuente: (Kalin, 2013) Los Servicios Web pueden ser clasificados en dos grupos, los servicios basados en el protocolo SOAP y los servicios que usan el estilo de arquitectura REST. SOAP es un dialecto XML con una gramática que especifica la estructura que debe tener un documento, en los servicios web basados en SOAP la comunicación se realiza a través de mensajes de este tipo. Los servicios web que usan el estilo REST hacen uso del protocolo HTTP y sus diferentes métodos de petición para realizar el paso de mensajes, que pueden ser de diferentes tipos. En los dos casos tanto el servicio como sus clientes pueden ser escritos en cualquier lenguaje, que tenga las librerías adecuadas para su manejo, haciendo posible que exista independencia de los lenguajes para la comunicación de diferentes sistemas, gracias al uso de estándares abiertos para manejar las diferencias entre los lenguajes. Las características más importantes de los servicios web son:

• Infraestructura abierta: Los Servicios Web son desarrollados usando estándares y protocolos abiertos e independientes de los fabricantes y los lenguajes, estándares como HTTP, XML y JSON, los cuales son ampliamente usados y bien comprendidos en la web.

• Transparencia de lenguaje: Los Servicios Web y sus clientes pueden inter-

operar independientemente del lenguaje de programación en el cual son desarrollados. Lenguajes como C/C++, Java, Python, Ruby y otros

43

proporcionan las librerías y herramientas adecuadas para soportar el uso de Servicios Web.

• Diseño Modular: Los Servicios Web están destinados a tener un diseño

modular, de tal manera que nuevos servicios puedan ser generados a través de la integración de servicios existentes.

6.3.1 Servicios Web SOAP

Se puede considerar SOAP como un protocolo de comunicación entre aplicaciones que establece el formato para el envío de mensajes entre una red usando el protocolo HTTP, es independiente de las plataformas y lenguajes de programación, está basado en XML y tiene una gramática que especifica la estructura que debe tener un documento para ser clasificado como SOAP. En los servicios web basados en SOAP tanto el cliente como el servidor envían mensajes que consisten en documentos XML que contienen los siguientes elementos:

• Envoltura (envelope): Es el elemento raíz del mensaje e identifica el documento XML como un mensaje SOAP, un ejemplo puede ser el siguiente:

<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> ... < información del mensaje> ... </soap:Envelope>

El valor del espacio de nombres y del estilo de codificación deben ser siempre los mismos para todos los mensajes, ya que estos definen el mensaje como tipo SOAP.

• Encabezado (header): elemento que contiene la información de encabezado específica para la aplicación, como puede ser autenticación, pago, etc. Si el encabezado está presente debe ser el primer elemento hijo del elemento envoltura. SOAP define tres atributos en el espacio de nombres estándar, los cuales se pueden definir en el encabezado y especifican como un receptor debe procesar el mensaje, los atributos son “mustUnderstand”, “actor” y “encodingStyle”. El primer atributo puede ser usado para indicar si una entrada del encabezado es obligatoria u opcional para que el receptor procese; el segundo atributo es usado para direccionar el encabezado a un

44

punto específico; el tercer atributo es usado para definir los tipos de dato usados en el documento. El siguiente es un ejemplo del elemento

<soap:Header> <m:Trans xmlns:m="http://www.w3schools.com/transaction/" soap:actor="http://www.w3schools.com/appml/">234 </m:Trans> </soap:Header>

• Cuerpo (body): Elemento que contiene el mensaje como tal a ser enviado, osea, la información de llamada y respuesta del mensaje. Los elementos hijos de este elemento deben tener un espacio de nombres calificado. Por ejemplo.

<soap:Body>

<m:GetPrice xmlns:m="http://www.w3schools.com/prices"> <m:Item>Apples</m:Item> </m:GetPrice> </soap:Body>

• Fallas (fault): Elemento que contiene los errores y la información de estado para un mensaje SOAP. Si este elemento está presente, debe aparecer como un elemento hijo del elemento cuerpo y solo puede aparecer una vez en todo el mensaje. Tiene los siguientes sub-elementos:

o <faultcode>: código para identificar la falla. o <faultstring>: explicación entendible de la falla. o <faultactor>: información acerca de quien causó que la falla

ocurriera. o <detail>: mantiene la información del error específica de la aplicación

relacionada en el elemento cuerpo. El resultado del uso de servicios web SOAP es un sistema para realizar llamadas remotas a métodos entre diferentes plataformas por medio del uso de acciones y URIs. Los servicios basados en SOAP casi siempre tienen una única URI y muchas acciones diferentes, de manera que cada servicio SOAP crea nuevas acciones, usando el método POST en caso de que se haga el paso de mensajes sobre HTTP. Las reglas de sintaxis definidas por SOAP para los mensajes son las siguientes:

• Debe ser codificado usando XML. • Debe usar el espacio de nombres de la envoltura SOAP. • Debe usar el espacio de nombres de la codificación SOAP. • No debe contener una referencia DTD (Definición de Tipo de Documento). • No debe contener instrucciones de procesamiento XML.

45

En los servicios web basados en SOAP tanto el cliente como el que expone el servicio deben usar librerías que “entiendan” el protocolo para realizar la comunicación, tal como se aprecia en la Imagen 8. Imagen 8: Interacción de un servicio web SOAP

Fuente: (Kalin, 2013)

6.3.2 Servicios Web REST

REST es un estilo de arquitectura de software para sistemas hipermedia distribuidos, ósea sistemas en los cuales texto, gráficos, audio y otros tipos de multimedia son almacenados a través de una red e interconectados a través de hipervínculos. Los servicios web tipo REST (o RESTful) se basan en este este tipo de arquitectura y tienen una interacción como se puede apreciar en Imagen 9. Imagen 9: Interacción de un servicio web tipo REST

Fuente: (Kalin, 2013) El estilo REST se basa en los diferentes principios: 6.3.2.1 Principio de los recursos direccionables. La abstracción clave de la información y datos en REST es un recurso, y cada recurso debe ser direccionable por medio de una URI (Uniform Resource Identifier) de manera que se tenga una sintaxis universal para identificar los recursos ya que existe un formato estándar para las URI.

esquema://servidor:puerto/ruta?cadenaDeBusqueda#fragmento

46

En este formato el esquema es el protocolo usado en la comunicación que usualmente es http o https; el servidor es un DNS o una dirección ip y el puerto es un número que puede ser opcional, estos dos representan la maquina donde está localizado del recurso sobre una red; la ruta es un conjunto de segmentos de texto delimitados por el carácter “/” y representan la localización del recurso en la maquina donde se encuentra; la cadena de búsqueda es una lista opcional de parámetros representados por el par nombre/valor, cada par está delimitado con el carácter “&”; la última parte de una URI es un fragmento el cual es usado para apuntar a una parte especifica en el documento que se solicita. 6.3.2.2 Principio de Interfaz uniforme y restringid a. Se hace uso de un conjunto de operaciones bien definidas que se aplican a todos los recursos de información. Se usan las operaciones definidas por HTTP en donde las más importantes son POST, GET, PUT y DELETE; de esta manera no es necesario tener un parámetro que especifique la acción en la URI. Cada uno de los métodos de http tiene un propósito específico que puede usarse como una acción.

• GET: Es una operación de solo lectura, es usada para consultar al servidor por información específica. Esta operación no cambia el estado del servidor y el resultado siempre es el mismo.

• PUT: Solicita que el servidor guardar el cuerpo del mensaje enviado con la solicitud bajo la localización proporcionada en el mensaje http. Esto es usualmente modelado como una acción de inserción o actualización.

• DELETE: Es usado para eliminar recursos.

• POST: Es la única operación de http que cambia el resultado de respuesta y cambia el estado del servidor cada vez que es invocado. Cada invocación puede modificar el servicio en una forma única. Se puede enviar o no información con la solicitud y se puede o no recibir información de respuesta.

• HEAD: Funciona de la misma manera que GET pero con la excepción de que en lugar de retornar un cuerpo de respuesta, retorna un código de respuesta y cualquier encabezado asociado con la solicitud.

• OPTIONS: Es usado para solicitar información acerca de las opciones de comunicación del recurso en el cual se está interesado, este permite a los clientes determinar las capacidades de un servidor y un recurso sin necesidad de ejecutar alguna acción para probar.

47

6.3.2.3 Orientado a la representación. Cada servicio es direccionable a través de una URI específica y las representaciones son intercambiadas entre el cliente y el servicio. Con una operación GET el cliente recibe una representación del estado actual de un recurso, con las operaciones PUT y POST se realiza un paso de una representación de un recurso al servidor. Las representaciones pueden ser XML, JSON, HTML o cualquier otro formato de hipermedia, por lo tanto http usa el identificador de tipo de contenido (Content-Type) para comunicar al cliente o servidor el formato usado; algunos tipos de contenido son:

text/plain text/html application/xml text/html

Es posible que un cliente y el servidor negocien los formatos de mensaje que serán intercambiados entre ellos, con el encabezado de aceptación un cliente puede listar sus formatos de respuesta preferidos. 6.3.2.4 Comunicación sin estado. Cada mensaje HTTP contiene toda la información necesaria para comprender la petición, de manera que ni el cliente ni el servidor necesitan recordar ningún estado de las comunicaciones entre mensajes y por lo tanto no se guarda ninguna sesión del cliente en el servidor. El servidor solamente guarda y gestiona el estado de los recursos que expone. 6.3.2.5 Hipermedia como motor de estado de aplicaci ón. Hipermedia es un enfoque centrado en documentos con el soporte para insertar vínculos a otros servicios e información dentro del formato del documento. Uno de los usos de los sistemas hipermedia y los hipervínculos es componer conjuntos complejos de información desde fuentes diferentes.

48

6.4 BASE DE DATOS

6.4.1 Mapeo objeto-relacional

El mapeo objeto-relacional es una técnica de programación para convertir datos entre el sistema de tipos utilizado en los lenguajes de programación orientados a objetos y la utilización de una base de datos relacional como motor de persistencia. Esto posibilita el uso de las características propias de la orientación a objetos y la independencia del motor de base de datos utilizado para el sistema. En esta técnica, para lograr la interacción con la base de datos, se crea una base de datos virtual orientada a objetos sobre la base de datos relacional como se ilustra en la Imagen 10. Imagen 10: interacción en técnica de mapeo objeto-relacional

Fuente: (Visual Paradigm, 2015) Algunas de las ventajas del uso de esta técnica son la centralización de la lógica de negocio del sistema y la independencia del motor de base de datos, teniendo la posibilidad de cambiarlo durante el desarrollo sin mayores complicaciones. Como desventaja tiene que las aplicaciones funcionan un poco más lento con el uso de esta técnica debido a que todas las consultas que se hagan sobre la base de datos, el sistema debe primero transformarlas al lenguaje propio de la herramienta, luego leer los objetos y por ultimo crear los objetos

6.4.2 Motor de base de datos

49

6.4.2.1 Postgresql PostgreSQL es un sistema de gestión de bases de datos relacionales, libre y de código abierto, manejado por una comunidad de desarrolladores apoyados por organizaciones comerciales. Algunas de las principales características de éste motor de base de datos son:

• Alta concurrencia: hace uso de un sistema denominado MVCC (Acceso concurrente multiversión, por sus siglas en ingles) que permite que mientras un proceso escribe en una tabla, otros procesos puedan acceder a la misma sin necesidad de bloqueos ya que cada usuario tiene una visión consistente de los últimos cambios.

• Amplia variedad de tipos nativos: provee soporte nativo para números de

precisión arbitraria, texto de largo ilimitado, figuras geométricas, direcciones ip, y otros. Adicionalmente es posible crear nuevos tipos de datos que pueden ser indexables.

• Claves foráneas: se puede hacer uso de las claves foráneas como

mecanismo de integridad referencial de las bases de datos.

• Disparadores: incluye la posibilidad de ejecutar acciones específicas programáticamente al ocurrir un evento determinado.

• Vistas: es posible hacer uso de vistas como consultas accesibles como una

tabla virtual en la base de datos.

• Integridad transaccional: permite que al realizar actualizaciones sobre la base de datos, ésta permanezca en estado consistente a pesar de finalizaciones anormales.

• Herencia de tablas: permite crear tablas de bases de datos que heredan de

otras tablas de la misma forma que ocurre en las clases para los lenguajes orientados a objetos.

• Tipos de datos y operaciones geométricas: cuenta con soporte para tipos

de datos utilizados en sistemas de información geográfica y realizar operaciones con estos tipos de datos.

• Soporte para transacciones distribuidas: permite a postgresql integrarse en un sistema distribuido formado por varios recursos (que pueden ser de diferentes fabricantes) y gestionado por un servidor de aplicaciones.

50

• Funciones: son bloques de código que se ejecutan en el servidor, que

pueden ser escritos en varios lenguajes como C, C++, Java PL, plPHP, PL/Python o en un lenguaje propio del motor llamado PL/PgSQL. Para el caso de Postgres, maneja los disparadores como funciones enlazadas a operaciones sobre los datos. Las funciones pueden ser definidas para ejecutarse con los derechos del usuario ejecutor o con los derechos de un usuario previamente definido. El concepto de funciones son equivalentes a los "procedimientos almacenados" en otros sistemas de gestión de base de datos.

51

7. DISEÑO METODOLÓGICO

El proyecto se ve reflejado dentro del marco planteado por el modelo de desarrollo software en espiral, el cual también puede ser utilizado como marco para el diseño de las bases de datos y abarca dentro de su proceso un direccionamiento básico del proyecto que tiene en cuenta los posibles riesgos. Además se plantea una metodología para integración y pruebas durante el desarrollo del proyecto

7.1 METODOLOGÍA DE DESARROLLO

7.1.1 Descripción

El modelo de desarrollo en espiral es un modelo del tipo iterativo e incremental, el cual representa el proceso de software como una espiral en la que cada ciclo corresponde a una iteración en el proceso. Cada iteración tiene por lo menos cuatro sectores, cada uno con un conjunto de actividades no fijadas desde el comienzo del proyecto, sino que se eligen a partir del análisis realizado en el ciclo anterior. El modelo en espiral del proceso de software fue originalmente propuesto por Boehm en 1988. Este modelo no representa el proceso del software como una secuencia de actividades con retrospectiva de una actividad a otra, sino que lo representa como una espiral en donde cada ciclo representa una fase del proceso de software, como se muestra en la Imagen 11, De manera que el ciclo más interno puede referirse a la viabilidad del sistema, el siguiente ciclo a la definición de requerimientos, el siguiente al diseño del sistema, y así sucesivamente. El modelo en espiral combina la evitación del riesgo con tolerancia al mismo, asumiendo que los cambios son un resultado de los riesgos del proyecto e incluye actividades explicitas de gestión del riesgo para reducirlo. Cada ciclo de la espiral se divide en cuatro sectores:

1. Definición de objetivos : En este sector de la espiral se definen los objetivos específicos para el proyecto en la respectiva iteración, se identifican las restricciones del proceso y producto, y se traza un plan detallado de gestión. Se identifican los riesgos del proyecto, y dependiendo de estos riesgos se plantean estrategias alternativas.

2. Evaluación y reducción de riesgos : En este sector se lleva a cabo un análisis detallado para cada uno de los riesgos de proyecto identificados. Se definen los pasos para reducir dichos riesgos. Por ejemplo, si existe el riesgo de tener requerimientos inapropiados, se puede desarrollar un prototipo del sistema.

52

Imagen 11: Modelo en espiral para el proceso de desarrollo de software

Fuente: (Sommerville, 2005)

3. Desarrollo y validación : Después de la evaluación de riesgos, en este sector se elige un modelo para el desarrollo del sistema. Por ejemplo, si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si los riesgos de seguridad son la principal consideración, un desarrollo basado en transformaciones formales podría ser el más apropiado, y así sucesivamente.

4. Planificación : En este sector el proyecto se revisa y se toma la decisión de

si se debe continuar con un ciclo posterior de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto.

Un ciclo de la espiral empieza con la elaboración de objetivos, como el rendimiento y la funcionalidad. Entonces se enumeran formas alternativas de alcanzar estos objetivos y las restricciones impuestas en cada una de ellas. Cada alternativa se evalúa contra cada objetivo y se identifican las fuentes de riesgo del proyecto. El siguiente paso es resolver esos riesgos mediante actividades de recopilación de información como puede ser el detallar más el análisis, la construcción de prototipos o la simulación. Una vez que se han evaluado los

53

riesgos, se lleva a cabo cierto desarrollo, seguido de una actividad de planificación para la siguiente fase del proyecto. La diferencia principal entre el modelo en espiral y los otros modelos del proceso del software es la consideración explicita del riesgo. El riesgo implica la posibilidad de que algo pueda ir mal, originando problemas en el proyecto, por lo tanto la disminución de riesgos es una actividad muy importante en la gestión del proyecto. En el presente proyecto se planteará cada funcionalidad del sistema como una iteración del modelo en espiral; teniendo en total cinco iteraciones relacionadas con las funcionalidades de la siguiente manera: 1. Registro de procesos judiciales. 2. Consulta de procesos judiciales. 3. Captura y envío de información de actos procesales. 4. Recepción y organización de información procesal. 5. Autenticación de usuarios.

Dentro del proyecto se abordará de la siguiente manera la implementación de los cuatro sectores de cada ciclo de la espiral:

7.1.2 Definición de objetivos, alternativas y restr icciones

Aunque en cada ciclo de la espiral se realizarán actividades relacionadas con todos los objetivos específicos del proyecto, para este sector de la espiral en cada iteración los objetivos se priorizarán de manera diferente de acuerdo a la importancia que tengan en el momento especifico del proyecto.

• En la primera iteración se priorizará en los objetivos relacionados con el establecimiento de requerimientos, diseño de arquitectura del sistema, diseño de la interfaz de usuario y diseño del modelo de base de datos; evaluando las formas alternativas de llevar a cabo estos objetivos y sus riesgos asociados teniendo en cuenta que la elección realizada en esta iteración se mantendrá durante todo el proyecto.

• En la segunda iteración se priorizará en los objetivos relacionados con el establecimiento de requerimientos, el diseño de interfaz de usuario y el diseño de pruebas del sistema; incluyendo una especial atención en la actividad de revisión y ajustes dentro de las formas alternativas de llevar a cabo estos objetivos y sus riesgos asociados.

• En la tercera iteración la prioridad serán los objetivos relacionados con el establecimiento de requerimientos, el diseño de arquitectura del sistema, el diseño de interfaz de usuario y diseño de modelo de base de datos; todos éstos abordados desde el punto de vista del desarrollo de la aplicación móvil.

54

• En la cuarta iteración la prioridad estará en los objetivos relacionados con el diseño de la arquitectura del sistema, el diseño del modelo de base de datos y el diseño de las pruebas del sistema; tomando en consideración que la importancia en esta iteración es la integración del sistema.

• En la quinta iteración se aborda una funcionalidad transversal del sistema, y por lo tanto se priorizará en el diseño de la arquitectura del sistema, el diseño de la interfaz de usuarios, el diseño del modelo de base de datos y el diseño de pruebas del sistema; y ya que se trata de la última iteración del proyecto también habrá prioridad en la realización de la documentación del proyecto.

7.1.3 Evaluación de alternativas y reducción de rie sgos

En este sector se realizarán actividades de recopilación de información detallada de cada una de las formas alternativas de llevar a cabo los objetivos definidos para cada iteración y la posible construcción de prototipos pequeños para realizar pruebas de concepto, teniendo como finalidad la reducción de riesgos asociados y la evaluación de alternativas de cada iteración. Existirá una priorización de los riesgos a mitigar de acuerdo a la iteración que corresponda, de la siguiente manera:

• En la primera iteración se priorizará en la reducción de los riesgos relacionados con el enfoque del proyecto y la disponibilidad de la información.

• En la segunda iteración se priorizará en la reducción de los riesgos relacionados con integridad de la información y el enfoque de la solución.

• En la tercera iteración se priorizará en la reducción de riesgos asociados con la disponibilidad e integridad de la información.

• En la cuarta iteración la prioridad será la reducción de riesgos relacionados con la disponibilidad, integridad y acceso a la información.

• En la quinta iteración se priorizará en la reducción de riesgos relacionados con la confidencialidad, seguridad e integridad de la información.

7.1.4 Desarrollo y validación de producto

Durante este sector se realizarán los productos correspondientes para las funcionalidades definidas en cada iteración. Los productos no varían entre las diferentes iteraciones sino que van incrementando su contenido, estos productos son:

• Listado de requerimientos funcionales, no funcionales y de información. • Diagramas de diseño de arquitectura. • Diseño del modelo lógico y físico de base de datos. • Diseño de interfaz de usuario de la aplicación. • Código fuente. • Documentación del proyecto.

55

7.1.5 Planificación del siguiente ciclo

Este sector servirá para realizar una evaluación de cada iteración, buscando obtener retroalimentación de los productos, realizando actividades de revisión y contraste con los objetivos, alcance y limitaciones del proyecto completo.

56

7.2 METODOLOGIA DE INTEGRACIÓN Y PRUEBAS

Como metodología de integración y pruebas durante el desarrollo del proyecto se utiliza la integración continua.

7.2.1 Descripción

La integración continua es una práctica de desarrollo de software, que consiste en realizar integraciones de un proyecto lo más a menudo posible para poder detectar posibles fallas en etapas tempranas del desarrollo por medio de pruebas realizadas a esos productos compilados. En la integración continua se suelen incluir un conjunto de prácticas para que su implementación sea exitosa, algunas de las prácticas comunes son:

• Definición previa de reglas de integración y pruebas por las que debe pasar el software

• Ejecución de pruebas unitarias antes y después de cada integración. • Establecimiento de criterios de aceptación y estrategias para resolución de

errores. • Control de versiones de código.

Habitualmente se utilizan software que automatice las integraciones y pruebas unitarias, aunque esto no es un requerimiento para su implementación.

57

8. DEFINICIÓN DE REQUERIMIENTOS

Para poder realizar la definición de requerimientos se definió la recolección de información a través de los códigos de procedimiento civil, entrevistas y sesiones conjuntas con expertos del dominio, tanto abogados como dependientes judiciales, de manera que se lograra obtener claridad sobre el procedimiento de gestión de procesos judiciales, para realizar la definición de requerimientos funcionales, no funcionales y de información necesarios para el desarrollo de cada una de las funcionalidades definidas en el prototipo.

8.1 FUNCIONALIDAD DE REGISTRO DE PROCESOS JUDICIALE S

El propósito de la funcionalidad de registro de procesos judiciales es la creación de procesos judiciales dentro del sistema, de manera que queden disponibles para su posterior consulta y actualización.

8.1.1 Requerimientos funcionales

Los requerimientos funcionales definidos para que se pueda llevar a cabo la funcionalidad de registro de procesos judiciales son:

• Creación de procesos judiciales • Creación de sujetos procesales • Administración de juzgados existentes.

Estos requerimientos se describen en la Tabla 1, Tabla 2 y Tabla 3. Tabla 1: Requerimiento crear proceso judicial RF 1 Crear proceso judicial Descripción El usuario podrá registrar un proceso judicial en el sistema

haciendo uso del componente web, con los datos obtenidos de la radicación del proceso en el juzgado respectivo.

Usuario Abogado Factores a tener en cuenta.

• A cada proceso, judicial al ser radicado en los juzgados, le es a asignado un número de radicación único.

• La radicación del proceso es considerada la primera actuación de todos los procesos judiciales.

Importancia Alta Requerimientos asociados

RF 2 RF 3 RI 1 RI 2

58

RI 3

Tabla 2: Requerimiento crear sujeto procesal RF 2 Crear sujeto procesal Descripción El usuario podrá registrar en el sistema los datos de los

sujetos procesales intervinientes en cada proceso y asociarlos de acuerdo al rol que desempeñen en el respectivo proceso judicial. Esto se realiza haciendo uso del componente web.

Usuario Abogado Factores a tener en cuenta

Un mismo sujeto procesal puede estar implicado en múltiples procesos judiciales


RF 1 RI 2

Tabla 3: Requerimiento administrar juzgados RF 3 Administrar juzgados Descripción El usuario podrá registrar, editar y eliminar información de

los juzgados que se tendrán en cuenta en el sistema, por medio del componente web.


• El juzgado debe ser seleccionado al momento de la creación de procesos judiciales.

• Un proceso judicial puede cambiar de juzgado durante su transcurso.

Importancia Media Requerimientos asociados

RF 1 RI 3

8.1.2 Requerimientos de información

Los requerimientos de información necesaria para poder llevar a cabo el desarrollo de los requerimientos funcionales de la funcionalidad de registro de procesos judiciales son:

• Información sobre el proceso judicial • Información sobre el sujeto procesal • Información sobre juzgados.

59

La información respectiva de estos requerimientos se encuentra definida en la Tabla 4, Tabla 5 y Tabla 6. Tabla 4: Información sobre el proceso judicial RI 1 Información sobre el proceso judicial Requerimie ntos asociados

RF 1

Datos específicos • Numero de radicación • Juzgado • Fecha de radicación • Cuantía • Crédito • Sujetos procesales implicados

Restricciones • El número de radicación debe ser único

• El número de radicación es un numero de 20 dígitos, con un formato de organización de los dígitos de la siguiente manera: xxxxxxxxx-xxxxx-xxxx-xx

• La fecha de radicación debe ser anterior al día en que se registra el proceso en el sistema.

• La cuantía tiene tres opciones de valor: o Mínima cuantía o Menor cuantía o Mayor cuantía

• El crédito es un valor monetario que no puede ser negativo.

Tabla 5: Información sobre el sujeto procesal RI 2 Información sobre el sujeto procesal Requerimientos asociados

RF 2

Datos específicos • Parte en el proceso • Es cliente en el proceso • Tipo de identificación • Número de identificación • Dirección • Número de teléfono • Número de teléfono celular

Restricciones • Las opciones de parte en el proceso son demandante y

demandado. • Un proceso puede tener múltiples demandantes o

múltiples demandados. • Un proceso debe tener por lo menos un demandante y un

demandado.

60

• Mínimo uno de los sujetos procesales debe ser cliente en el proceso judicial.

• No pueden registrarse como clientes del proceso demandantes y demandados de manera simultánea.

Tabla 6: Información sobre juzgados RI 3 Información sobre juzgados Requerimientos asociados

RF 3

Datos específicos • Nombre del juzgado • Tipo de juzgado • Departamento • Municipio • Dirección

Restricciones • El nombre del juzgado debe ser único

• El único tipo de juzgado en el sistema es el tipo Civil

61

8.2 FUNCIONALIDAD DE CONSULTA DE PROCESOS JUDICIALE S

El propósito de la funcionalidad de consulta de procesos judiciales es la búsqueda y acceso a la información de los procesos judiciales que han sido creados dentro del sistema, incluyendo la información de las diferentes actuaciones que son registradas para cada proceso.


Los requerimientos funcionales definidos para que se pueda llevar a cabo la funcionalidad de consulta de procesos judiciales son:

• Consultar lista de procesos judiciales activos • Consultar lista de procesos judiciales inactivos • Consultar proceso judicial específico

La descripción de estos requerimientos se encuentra en la Tabla 7, Tabla 8 y Tabla 9. Tabla 7: Requerimiento consultar lista de procesos judiciales activos RF 4 Consultar lista de procesos judic iales activos Descripción El usuario podrá acceder a una lista de registros de procesos

activos en el sistema, aplicar filtros y organización de la lista de acuerdo a los parámetros disponibles.


• El número de radicación es un identificador único de cada proceso.

• Es importante poder visualizar en la lista, la fecha tentativa de vencimiento de los términos de la última actuación de cada proceso.

• Se deben ver todos los demandados y demandantes de cada proceso

Impor tancia Alta Requerimientos asociados

RF 6 RI 4 RI 6

Tabla 8: Requerimiento consultar lista de procesos judiciales inactivos RF 5 Consultar lista de procesos judiciales inactivos Descripción El usuario podrá acceder a una lista de registros de procesos

62

inactivos en el sistema, aplicar filtros y organizar la lista de acuerdo a los parámetros disponibles.


• En los procesos inactivos no se debe tener en cuenta el vencimiento de términos de las actuaciones.


RF 6 RI 5 RI 6

Tabla 9: Requerimiento consultar proceso judicial específico RF 6 Consultar proceso judicial especifico Descripción El usuario podrá acceder a la información de un proceso judicial

especifico, al cual se accede por medio de la consulta de lista de procesos judiciales


• Las actuaciones de un proceso activo pueden ser actualizado mientras está siendo consultado


RF 4 RF 5 RI 6


Los requerimientos de información necesaria para poder llevar a cabo el desarrollo de los requerimientos funcionales de la funcionalidad de consulta de procesos judiciales son:

• Información sobre lista de procesos activos • Información sobre lista de procesos judiciales inactivos • Información sobre consulta de proceso judicial

La información respectiva de estos requerimientos se encuentra definida en la Tabla 10, Tabla 11 y Tabla 12. Tabla 10: Información sobre lista de procesos judiciales activos RI 4 Información sobre lista de procesos judiciales activos Requerimientos asociados

RF 4

Datos específicos • Numero de radicación • Demandante(s) • Demandado(s) • Juzgado • Fecha última actuación

63

• Termino Restricciones • Por cada registro se debe incluir el enlace a la consulta

del proceso específico. • Se debe poder ordenar por cualquiera de los campos de

la lista. • Se debe poder filtrar por número de radicación,

demandantes, demandados o juzgado. Tabla 11: Información sobre lista de procesos judiciales inactivos RI 5 Información sobre lista de procesos judiciales

inactivos Requerimientos asociados

RF 5

Datos específicos • Numero de radicación • Demandante(s) • Demandado(s) • Juzgado • Fecha última actuación

Restricciones • Por cada registro se debe incluir el enlace a la consulta del proceso específico.

• Se debe poder ordenar por cualquiera de los campos de la lista.

• Se debe poder filtrar por número de radicación, demandantes, demandados o juzgado.

Tabla 12: Información sobre consulta de proceso judicial RI 6 Información sobre consulta de proceso judicial Requerimientos asociados

RF 6

Datos específicos • Numero de radicación • Fecha de radicación • Juzgado • Cuantía • Crédito • Demandante(s) • Demandado(s) • Lista de actuaciones registradas o Tipo de actuación o Fecha de ocurrencia o Término o Anotación o Fotografías de registro de la actuación.

Restricciones • Pueden existir múltiples demandantes y demandados. • El proceso judicial puede cerrarse únicamente si existe la

actuación de sentencia.

64

• Se debe tener el registro de los juzgados en los cuales se ha tenido conocimiento del proceso judicial.

• El registro del proceso judicial puede estar compuesto de múltiples fotografías.

65

8.3 FUNCIONALIDAD DE CAPTURA Y ENVÍO DE INFORMACIÓ N DE ACTUACIONES PROCESALES

El propósito de la funcionalidad de captura y envío de información de actuaciones procesales es el registro de las actuaciones directamente desde los juzgados por parte del dependiente judicial, y la puesta en conocimiento de esta información en tiempo real al abogado, por medio del envío de los datos a través de internet al componente web. Para el cumplimiento de esta funcionalidad se hace uso de dispositivos móviles que cuenten con cámara y conexión a internet.


El requerimiento funcional definido para que se pueda llevar a cabo la funcionalidad de captura y envío de información de actuaciones procesales es:

• Captura y envío de información de actuación procesal La descripción de este requerimiento se encuentra en la Tabla 13. Tabla 13: Requerimiento captura y envío de información de actuación procesal RF 7 Captura y envío de información de actuación

procesal Descripción El usuario podrá ingresar los datos de la actuación

registrada, capturar las fotografías correspondientes a la actuación y enviar toda la información al componente web a través de internet.

Usuario Dependiente judicial Factores a tener en cuenta

• El dependiente tiene acceso al número de radicación del proceso en el juzgado respectivo.

• El registro de una actuación puede estar compuesto de múltiples fotografías, de acuerdo a la cantidad de hojas de la actuación.

• Las actuaciones ocurren de manera secuencial y cronológica.

• El envío masivo de archivos por internet en un único mensaje genera un tráfico elevado, que puede generar que no se reciba el mensaje completo.

• Se debe regular el tamaño de la imagen que es enviada.

Importancia Muy alta Requerimientos asociados

RF 8 RI 7

66


La información necesaria para poder llevar a cabo el desarrollo del requerimiento funcional de la funcionalidad de captura y envío de información de actuaciones procesales es:

• Información sobre captura y envío de información procesal

Esta información se encuentra definida en la Tabla 14. Tabla 14: Información sobre captura y envío de información procesal RI 7 Información sobre captura y envío de información

procesal Requerimientos asociados

RF 7

Datos específico s • Número de radicación • Tipo de actuación o Auto o Avalúo o Alegato de conclusión o Desistimiento tácito o Cambio de juzgado o Entrada a despacho o Excepciones de mérito o Excepciones previas o Liquidación costas o Nulidad o Reposición o Sentencia o Subsanación o Sustentación apelación o Término de ejecutoría

• Fecha de actuación • Fecha de término • Anotación • Fotografías anexas

Restricciones • No se puede registrar una actuación con fecha superior a la actual.

• La fecha de ocurrencia de la actuación es obligatoria al momento de llenar el formulario.

• Se debe limitar el tamaño de las fotografías para que puedan ser enviadas por red.

• Las fotografías deben ser enviadas individualmente debido a posibles restricciones de tamaño de paquetes en la red.

67

8.4 FUNCIONALIDAD DE RECEPCIÓN Y ORGANIZACIÓN DE IN FORMACIÓN PROCESAL

El propósito de la funcionalidad de recepción y organización de información procesal es recibir en el servidor la información enviada por el componente móvil, y la organización de esta información en los medios necesarios para que sean disponibles para consulta por medio del componente web.


El requerimiento funcional definido para que se pueda llevar a cabo la funcionalidad de recepción y organización de información procesal es:

• Recepción y organización de información procesal La descripción de este requerimiento se encuentra en la Tabla 15. Tabla 15: Requerimiento recepción y organización de información procesal RF 8 Recepción y organización de información procesal Descripción El sistema recibirá la información de la actuación

suministrada y enviada por el dependiente judicial a través de internet y la organizará de manera automática, creando la actuación en el sistema y cargándola con la información recibida.

Usuario Sistema Factores a tener en cuenta

• Se debe verificar la existencia del proceso con el número de radicación enviado.

• El envío masivo de archivos por internet en un único mensaje genera un tráfico elevado, que puede generar que no se reciba el mensaje completo.

• No es recomendable el almacenamiento de imágenes en base de datos.


RF 7 RI 8


La información necesaria para poder llevar a cabo el desarrollo del requerimiento de la funcionalidad de recepción y organización de información procesal es:

68

• Información sobre recepción y organización de información procesal.

Esta información se encuentra definida en la Tabla 17. Tabla 16: Información sobre recepción y organización de información procesal RI 8 Información sobre recepción y organización de

información procesal Requerimientos asociados

RF 8

Datos específicos • Se debe recibir la actuación procesal con los siguientes datos:

o Numero de radicación o Tipo actuación o Fecha de ocurrencia o Fecha termino o Fecha de revisión o Anotación

• Una actuación puede tener varios registros de fotografías y por lo tanto se debe tener en cuenta la cantidad de fotografías por actuación, el índice de cada una y el nombre.

Restricciones • Las fotografías se deben poder recibir individualmente y ser agregadas a la actuación.

• Los nombres de las fotografías deben ser únicos.

69

8.5 FUNCIONALIDAD DE AUTENTICACIÓN DE USUARIOS

El propósito de la funcionalidad de autenticación de usuarios es la de controlar el acceso a la aplicación, para que únicamente los usuarios que tengan la autorización de uso puedan hacer uso del sistema, evitando el acceso a la información privada a personas no autorizadas.


Los requerimientos funcionales definidos para que se pueda llevar a cabo la funcionalidad de autenticación de usuarios son:

• Control de acceso a componente móvil. • Control de acceso a componente web

La descripción de estos requerimientos se puede apreciar en la Tabla 17 y Tabla 18. Tabla 17: Requerimiento de control de acceso a componente móvil RF 9 Control d e acceso a componente móvil Descripción El sistema debe controlar el acceso de usuarios a la

aplicación móvil, de manera que únicamente pueda ser accedida por los usuarios que se encuentren registrados en el sistema y tengan las credenciales correspondientes a dependientes judiciales.


• La validación de credenciales de autenticación debe realizarse en el servidor.

• El número de identificación puede usarse como nombre de usuario único.

Importancia Media Requerimie ntos asociados

RI 9 RI 10

Tabla 18: Requerimiento de control de acceso a componente web RF 10 Control de acceso a componente web Descripción El sistema debe controlar el acceso de usuarios a la

aplicación web, de manera que únicamente pueda ser accedida por los usuarios que se encuentren registrados en el sistema y tengan las credenciales correspondientes a abogados.


• El número de identificación puede usarse como nombre de usuario único.

70


RI 9 RI 10


La información necesaria para poder llevar a cabo el desarrollo de los requerimientos funcionales de la funcionalidad de autenticación de usuarios es:

• Información sobre usuarios en el sistema. • Información sobre roles de los usuarios en el sistema.

Esta información se encuentra definida en la Tabla 19 y Tabla 20. Tabla 19: Información sobre usuarios en el sistema RI 9 Información sobre usuarios en el sistema Requerimientos asociados

RF 9 RF 10 RI 10

Datos específicos • Nombres • Apellidos • Número de identificación • Contraseña • Roles asociados

Restricciones • La contraseña debe transmitirse y almacenarse de forma

segura Tabla 20: Información sobre roles de los usuarios en el sistema RI 10 Información sobre roles de los usuarios en el sistema Requerimientos asociados

RF 9 RF 10 RI 9

Datos es pecíficos • Nombre del rol • Descripción • Usuarios asociados

Restricciones • Un rol puede ser asignado a varios usuarios diferentes

• Un usuario preferiblemente solo debe ejercer un rol a la vez.

71

8.6 REQUERIMIENTOS NO FUNCIONALES

Los requerimientos no funcionales definidos para el prototipo de apoyo a la gestión de litigio de procesos judiciales se pueden encontrar en la Tabla 21. Tabla 21: Requerimientos no funcionales

REQUERIMIENTOS NO FUNCIONALES

NOTACION REQUERIMIENTO DESCRIPCION RNF 1 Disponibilidad El sistema debe estar en la capacidad

de estar disponible para su correcto uso a cualquier hora del día, especialmente durante los horarios laborales y días hábiles de trabajo.

RNF 2 Integridad de los datos

El sistema debe realizarse de manera que garantice en la mayor medida posible la calidad de los datos almacenados y transmitidos durante el uso de los componentes.

RNF 3 Usabilidad La interfaz del sistema debe ser de fácil uso para los diferentes usuarios del sistema.

RNF 4 Escalabilidad Ya que se trata de un prototipo, el sistema debe desarrollarse de manera que pueda ser ampliado en funcionalidad en el futuro.

RNF 5 Rendimiento Los tiempos de respuesta del sistema con respecto a transferencias y actualizaciones de datos no deben sobrepasar los 10 minutos.

RNF 6 Confidencialidad La información manejada por el sistema debe estar protegida de acceso no autorizado.

72

9. DISEÑO DEL SISTEMA

El sistema desarrollado es un prototipo de sistema de información para el apoyo a abogados y sus asistentes en la gestión de procesos judiciales de tipo civil. El sistema permite crear, organizar, consultar y archivar procesos judiciales civiles de manera web, alimentando los datos de estos procesos por medio del registro, en tiempo real, de actuaciones procesales consultadas en los juzgados por medio de dispositivos móviles.

9.1 ARQUITECTURA

El sistema está construido con una arquitectura de tres capas y dos niveles. Los niveles corresponden a los ordenadores utilizados, donde uno se refiere a los clientes, tanto web como la aplicación móvil y el otro es el que contiene la lógica de negocio y de datos, como se puede apreciar en la Imagen 12. El nivel 1 es el de cliente donde se encuentra la aplicación móvil en Android y también los clientes que hagan uso de la aplicación por medio de un navegador web, el nivel 2 es el de servidor donde se encuentra el servidor de aplicación y de base de datos en un mismo ordenador, incluyendo en este nivel la lógica de negocio y de persistencia de datos. Imagen 12: Niveles de la arquitectura usada

Fuente: Elaboración propia Las capas de la arquitectura usada corresponden a la capa de presentación, capa de negocio y capa de datos, como se puede ver en la Imagen 13.

73

Imagen 13: Capas de la arquitectura usada

Fuente: Elaboración propia En la capa de presentación se encuentra toda la interfaz gráfica y parte de la lógica para comunicarse con la capa de negocio, en esta capa se encuentran a nivel web las operaciones de creación, consulta y archivo de procesos judiciales y a nivel móvil la función de registro y envío de actos procesales, la lógica para realizar todas las operaciones se encuentra en la capa de negocio, la cual utiliza llamados a la capa de datos para realizar las funciones de consulta, inserción, actualización o eliminación de datos, ya que la capa de datos tiene la lógica de persistencia y comunicación con la base de datos.

9.1.1 Capa de Datos

Esta capa desarrollada en Java, usando el patrón de diseño DAO (Data Access Object) y la especificación JPA (Java Persistence API), se encuentra la lógica de acceso a datos que hace uso de SessionBeans y la herramienta EclipseLink para interacción con la base de datos por medio del mapeo objeto-relacional. Además en esta misma capa se definen los objetos de dominio del sistema que representan tablas en la base de datos.

9.1.2 Capa de Negocio

La capa de negocio se encuentra desarrollada usando Session Beans del lenguaje Java, y es la que contiene la lógica de negocio del sistema y hace uso de la capa de datos para prestar los diferentes servicios que son solicitados desde la capa de presentación. También en esta capa se exponen servicios web tipo REST que se encargan de realizar la interacción entre la aplicación móvil y el servidor de aplicaciones.

74

9.1.3 Capa de Presentación Web

La capa de presentación en su parte web se encuentra desarrollada usando el framework JSF (Java Server Faces) y la librería Primefaces, contiene la lógica de presentación para las siguientes funcionalidades:

• Creación de procesos judiciales • Creación de sujetos procesales • Consulta de procesos judiciales • Archivo de procesos judiciales • Consulta de actuaciones procesales • Administración de tipos de actuación • Administración de plazos de las actuaciones procesales

9.1.4 Capa de Presentación Móvil

La capa de presentación en su parte móvil está desarrollada usando el ambiente de desarrollo Android SDK (Software Development Kit) para su ejecución en el sistema operativo Android. Cumple con la funcionalidad de registro de actuaciones procesales y su correspondiente envío al servidor de aplicaciones por medio de servicios web tipo REST.

9.1.5 Comunicación

La comunicación entre la capa de presentación y la capa de negocio se realiza a través de internet, usando el protocolo HTTP para los clientes web y servicios web tipo REST para la comunicación con la aplicación móvil, enviando información desde la aplicación móvil hacia el servidor de aplicaciones en formato JSON. La capa de datos se comunica con la base de datos usando el conector JDBC de Java, y la capa de negocio usa una interfaz local para realizar el llamado a los diferentes métodos que usa. Una vez que definidos los requerimientos funcionales, no funcionales y de información, se usan estos como insumo para plantear el diseño del sistema teniendo en cuenta la arquitectura definida. El diseño del sistema abarca diagramas UML que definen la estructura de paquetes, clases y secuencia.

9.1.6 Estructura de paquetes

Teniendo en cuenta que el sistema usa una arquitectura de tres capas, para el componente web se define los paquetes web, servicios y datos, siendo los equivalentes a las capas de presentación, negocio y datos definidos en la arquitectura, adicionalmente se definen los paquetes que contienen los componentes de utilitarios para el sistema. El esquema de paquetes del componente web se puede apreciar en la Imagen 14.

75

Imagen 14: Diagrama de paquetes del sistema


76

9.2 MODELO DE CLASES

El modelo de clases es el diseño de la estructura estática del sistema, realizado por medio de diagramas de clases que describen de manera general las clases del sistema, sus atributos, métodos y las relaciones entre las mismas. Se define un diagrama de clases por cada uno de los paquetes definidos para el sistema.

9.2.1 Clases del paquete ‘datos.entidades’

El paquete ‘datos.entidades’ es donde se almacenan las clases de dominio del sistema, las cuales tienen una identidad con las tablas de base de datos, por lo tanto al definir las clases y relaciones de este paquete se definen también la estructura de base de datos del sistema. El diagrama de clases del paquete ‘datos.entidades’ se puede apreciar en la Imagen 15. Imagen 15: Diagrama de clases del paquete 'datos.entidades'


9.2.2 Clases del paquete ‘datos.DAO’

En el paquete ‘datos.DAO’ está basado en el patrón de diseño DAO (Data Access Object) el cual busca proporcionar una interfaz común entre la aplicación y la base de datos, para aislar la aplicación de la tecnología usada para persistencia y el motor de base de datos. Este paquete contiene las clases con la lógica de

77

persistencia de las clases de dominio del sistema, y su diagrama de clases se puede apreciar en la Imagen 16. Imagen 16: Diagrama de clases del paquete 'datos.DAO'


9.2.3 Clases del paquete ‘servicios’

Las clases del paquete ‘servicios’ son las que contienen la lógica del negocio del sistema y sus restricciones. En este paquete se encuentran las funciones principales del sistema incluyendo los servicios web expuestos para la comunicación con la aplicación móvil. El diagrama de clases del paquete ‘servicios’ se puede ver en la Imagen 17.

78

Imagen 17: Diagrama de clases del paquete 'servicios'


9.2.4 Clases del paquete ‘web.controladores’

El paquete ‘web.controladores’ es donde se alojan las clases que hacen las veces de controlador según el patrón MVC (Modelo Vista Controlador), y por lo tanto

79

hacen las veces de puente entre la interfaz del usuario y la capa de servicios del sistema. En este paquete se define una clase controlador por cada una de las páginas web definidas para el componente web y su diagrama de clases se puede ver en la Imagen 18. Imagen 18: Diagrama de clases del paquete 'web.controladores'


80

9.3 DIAGRAMAS DE SECUENCIA

Los diagramas de secuencia muestran la interacción entre los diferentes objetos a través del tiempo, definiendo el paso de mensajes entre las instancias de las clases definidas que intervienen en cada una de las funcionalidades.

9.3.1 Funcionalidad de registro de procesos judicia les

Para la funcionalidad de registro de procesos judiciales se toman en cuenta dos actividades, el registro de procesos judiciales en el sistema y la administración de juzgados en el sistema. El diagrama de secuencia correspondiente a la creación de procesos judiciales en el sistema se puede apreciar en la Imagen 19 y el diagrama de secuencia correspondiente a la administración de juzgados en el sistema se puede apreciar en la Imagen 20. Imagen 19: Diagrama de secuencia de registro de procesos judiciales

Fuente: Elaboración propia.

81

Imagen 20: Diagrama de secuencia de administración de juzgados en el sistema


82

9.3.2 Funcionalidad de consulta de procesos judicia les

La funcionalidad de consulta de procesos judiciales consiste en dos actividades diferentes, que son la consulta de procesos activos y la consulta de procesos inactivos. Los diagramas de estas actividades se pueden apreciar en la Imagen 21 e Imagen 22, correspondiendo a la consulta de procesos activos y consulta de procesos inactivos respectivamente. Imagen 21: Diagrama de secuencia de consulta de procesos activos

Fuente: Elaboración propia Imagen 22: Diagrama de secuencia de consulta de procesos inactivos


83

9.3.3 Funcionalidad de captura y envío de informaci ón de actos procesales

La funcionalidad de captura y envío de información de actos procesales se realiza en el componente móvil del sistema, y es la actividad donde ocurre la comunicación más importante entre los componentes. El diagrama de secuencia de esta funcionalidad se aprecia en la Imagen 23. Imagen 23: Diagrama de secuencia de captura y envío de información de actos procesales

Fuente: Elaboración propia.

84

9.3.4 Funcionalidad de recepción y organización de información procesal

La funcionalidad de recepción y organización de información procesal, es realizada gracias a la interacción entre componentes del sistema sin que el usuario intervenga de manera directa. El diagrama de secuencia de esta funcionalidad se puede apreciar en la Imagen 24. Imagen 24: Diagrama de secuencia de recepción y organización de información procesal


9.3.5 Funcionalidad de autenticación de usuarios

La funcionalidad de autenticación de usuarios se realiza tanto en el componente web como en el componente móvil de distinta manera, y por lo tanto se definen dos diagramas de secuencia, el diagrama correspondiente al componente móvil se puede apreciar en la Imagen 25, mientras que el correspondiente al componente web se puede apreciar en la Imagen 26.

85

Imagen 25: Diagrama de secuencia de autenticación de usuarios en componente móvil

Fuente: Elaboración propia Imagen 26: Diagrama de secuencia de autenticación de usuario en componente web


86

10. INTERFAZ DE USUARIO

El diseño de la interfaz de usuario se realiza para las funcionalidades del sistema que tienen interacción con el usuario, tanto abogado como dependiente judicial. En el diseño se tiene en cuenta la distribución de los elementos que intervienen en la comunicación del usuario con el sistema, estos elementos se diseñan basándose en interfaces comunes y conocidas para los usuarios, de manera que la interacción con el sistema sea intuitiva.

10.1 FUNCIONALIDAD DE REGISTRO DE PROCESOS JUDICIAL ES

Para la funcionalidad de registro de procesos judiciales se definen tres interfaces, que corresponden con el formulario de creación de proceso, el formulario de agregación de sujeto procesal y la interfaz de administración de juzgados; estas interfaces se pueden apreciar en la Imagen 27, Imagen 28 e Imagen 29 respectivamente. Imagen 27: Interfaz de usuario de formulario de creación de proceso judicial


87

Imagen 28: Interfaz de usuario de formulario de agregación de sujeto procesal

Fuente: Elaboración propia Imagen 29: Interfaz de usuario de administración de juzgados


88

10.2 FUNCIONALIDAD DE CONSULTA DE PROCESOS JUDICIAL ES

Para la funcionalidad de consulta de procesos judiciales se definen diferentes interfaces, que corresponden a la actividad de búsqueda, la visualización del proceso y la visualización de cada registro de actuación; estas interfaces se pueden apreciar en la Imagen 30, Imagen 31 e Imagen 32 respectivamente. Imagen 30: Interfaz de usuario de búsqueda de procesos

Fuente: Elaboración propia Imagen 31: Interfaz de usuario de visualización de proceso


89

Imagen 32: Interfaz de usuario de visualización de registro de actuación


90

10.3 FUNCIONALIDAD DE CAPTURA Y ENVÍO DE INFORMACIÓ N DE ACTOS PROCESALES

En la funcionalidad de captura y envío de información de actos procesales el usuario interactúa de dos formas, la primera es la definición de los posibles tipos de actuación que serán usados por los dos componentes, esta definición es realizada en el componente web, el diseño de interfaz de usuario de esta actividad es mostrada en la Imagen 33. Imagen 33: Interfaz de usuario de definición de tipos de actuación

Fuente: Elaboración propia La segunda forma de interacción con usuario que interviene en la funcionalidad de captura y envió de información de actos procesales es el registro de la actuación que se realiza por medio del uso del componente móvil del sistema, el diseño de interfaz de usuario definido para esto se puede ver en la Imagen 34. Imagen 34: Interfaz de usuario de registro de actuación


91

10.4 FUNCIONALIDAD DE AUTENTICACIÓN DE USUARIOS

La funcionalidad de autenticación de usuarios tiene interacción con usuario tanto en el componente web como en el componente móvil, el diseño de interfaz para la aplicación de esta funcionalidad en el componente móvil se puede apreciar en la Imagen 35 y en el componente web en la Imagen 36. Imagen 35: Interfaz de usuario de autenticación de usuario en componente móvil

Fuente: Elaboración propia Imagen 36: Interfaz de usuario de autenticación de usuario en componente web


92

11. DISEÑO DE MODELO LÓGICO Y FÍSICO DE BASE DE DAT OS

Con base en la obtención de información y en los requerimientos definidos para el proyecto, se realiza el diseño lógico y físico de la base de datos a ser usada por el sistema.

11.1 DISEÑO MODELO LÓGICO DE LA BASE DE DATOS

El diseño del modelo lógico de la base de datos del sistema sirve como descripción de la estructura de la base de datos en forma de tablas, atributos y relaciones. En la Imagen 37 se puede apreciar el diseño del modelo lógico de la base de datos del sistema. Imagen 37: Diseño modelo lógico de base de datos


93

11.2 DISEÑO MODELO FÍSICO DE LA BASE DE DATOS

Una vez definido el diseño del modelo lógico de la base de datos, se toma como base para para diseñar el diseño físico de la misma, teniendo en cuenta que según la arquitectura definida, el servidor de base de datos se encuentra en el mismo ordenador del servidor de aplicación y el motor de base de datos del sistema es PostgreSQL En el modelo físico se establece el esquema contenedor, las tablas, los campos y sus características (tipo de datos, restricciones), los índices, las restricciones y el tipo de codificación.

11.2.1 Creación del esquema

CREATE SCHEMA IF NOT EXISTS `gpj` DEFAULT CHARACTER SET utf8;

11.2.2 Creación tabla ‘PROCESO’

CREATE TABLE IF NOT EXISTS ‘gpj’.’proceso’ ( ‘id_proceso’ BIGINT(20) NOT NULL,

‘activo’ TINYINT(1) NULL DEFAULT '0', ‘credito’ VARCHAR(255) NULL DEFAULT NULL, ‘cuantia’ VARCHAR(255) NULL DEFAULT NULL, ‘fecha_radicacion’ DATE NOT NULL, ‘num_radicacion’ VARCHAR(27) NOT NULL, PRIMARY KEY (‘id_proceso’), UNIQUE INDEX ‘num_radicacion’ (‘num_radicacion’ ASC)) DEFAULT CHARACTER SET = utf8;

11.2.3 Creación tabla ‘ACTUACION’

CREATE TABLE IF NOT EXISTS ‘gpj’.’actuacion’ ( ‘id_actuacion` BIGINT(20) NOT NULL, ‘anotacion` VARCHAR(255) NULL DEFAULT NULL, ‘fecha_ocurrencia` DATE NOT NULL, ‘fecha_revision` DATETIME NULL DEFAULT NULL, ‘termino` DATE NULL DEFAULT NULL, ‘id_proceso` BIGINT(20) NOT NULL, ‘id_tipoActuacion` BIGINT(20) NULL DEFAULT NULL, PRIMARY KEY (ìd_actuacion`), INDEX `FK_actuacion_id_proceso` (‘id_proceso’ASC), INDEX `FK_actuacion_id_tipoActuacion` (ìd_tipoActuacion` ASC), CONSTRAINT `FK_actuacion_id_tipoActuacion`

94

FOREIGN KEY (ìd_tipoActuacion`) REFERENCES `gpj`.`tipo_actuacion` (ÌD_TIPOACTUACION`), CONSTRAINT `FK_actuacion_id_proceso` FOREIGN KEY (ìd_proceso` ) REFERENCES `gpj`.`proceso` (‘id_proceso’)) DEFAULT CHARACTER SET = utf8;

11.2.4 Creación tabla ‘TIPO_ACTUACION’

CREATE TABLE IF NOT EXISTS `gpj`.`tipo_actuacion` ( ‘id_tipoactuacion’ BIGINT(20) NOT NULL , `nombre` VARCHAR(255) NULL DEFAULT NULL , `plazo_estandar` INT(11) NULL DEFAULT NULL , PRIMARY KEY (ÌD_TIPOACTUACION`) ) DEFAULT CHARACTER SET = utf8;

11.2.5 Creación tabla ‘FOTOGRAFIA’

CREATE TABLE IF NOT EXISTS `gpj`.`fotografia` ( ÌD` BIGINT(20) NOT NULL , `ruta` VARCHAR(255) NULL DEFAULT NULL , ìd_actuacion` BIGINT(20) NULL DEFAULT NULL , PRIMARY KEY (ÌD`) , UNIQUE INDEX `ruta` (`ruta` ASC) , INDEX `FK_fotografia_id_actuacion` (ìd_actuacion` ASC) , CONSTRAINT `FK_fotografia_id_actuacion` FOREIGN KEY (ìd_actuacion` ) REFERENCES `gpj`.àctuacion` (ìd_actuacion` )) DEFAULT CHARACTER SET = utf8;

11.2.6 Creación tabla ‘JUZGADO’

CREATE TABLE IF NOT EXISTS `gpj`.`juzgado` ( ÌD_JUZGADO` BIGINT(20) NOT NULL , `departamento` VARCHAR(255) NULL DEFAULT NULL , `direccion` VARCHAR(255) NULL DEFAULT NULL , `municipio` VARCHAR(255) NULL DEFAULT NULL , `nombre` VARCHAR(255) NOT NULL , `tipo` VARCHAR(255) NULL DEFAULT NULL , PRIMARY KEY (ÌD_JUZGADO`) ) DEFAULT CHARACTER SET = utf8;

95

11.2.7 Creación tabla ‘JUZGADO_PROCESO’

CREATE TABLE IF NOT EXISTS `gpj`.`juzgado_proceso` ( ÌD_PROCESO` BIGINT(20) NOT NULL , ÌD_JUZGADO` BIGINT(20) NOT NULL , ès_actual` TINYINT(1) NULL DEFAULT '0' , `fecha_ingreso` DATE NULL DEFAULT NULL , PRIMARY KEY (ÌD_PROCESO`, ÌD_JUZGADO`) , INDEX `FK_juzgado_proceso_ID_JUZGADO` (ÌD_JUZGADO` ASC) , CONSTRAINT `FK_juzgado_proceso_ID_PROCESO` FOREIGN KEY (ÌD_PROCESO` ) REFERENCES `gpj`.`proceso` (ÌD_PROCESO` ), CONSTRAINT `FK_juzgado_proceso_ID_JUZGADO` FOREIGN KEY (ÌD_JUZGADO` ) REFERENCES `gpj`.`juzgado` (ÌD_JUZGADO` )) DEFAULT CHARACTER SET = utf8;

11.2.8 Creación tabla ‘SUJETO’

CREATE TABLE IF NOT EXISTS `gpj`.`sujeto` ( ÌD_SUJETO` BIGINT(20) NOT NULL , `celular` VARCHAR(255) NULL DEFAULT NULL , `direccion` VARCHAR(255) NULL DEFAULT NULL , `nombre` VARCHAR(255) NULL DEFAULT NULL , `num_identificacion` VARCHAR(255) NULL DEFAULT NULL , `telefono` VARCHAR(255) NULL DEFAULT NULL , `tipo_identificacion` VARCHAR(255) NULL DEFAULT NULL , PRIMARY KEY (ÌD_SUJETO`) ) DEFAULT CHARACTER SET = utf8;

11.2.9 Creación tabla ‘SUJETO_PROCESO’

CREATE TABLE IF NOT EXISTS `gpj`.`sujeto_proceso` ( ÌD_PROCESO` BIGINT(20) NOT NULL , ÌD_SUJETO` BIGINT(20) NOT NULL , ès_cliente` TINYINT(1) NULL DEFAULT '0' , `parte_proceso` VARCHAR(255) NULL DEFAULT NULL , PRIMARY KEY (ÌD_PROCESO`, ÌD_SUJETO`) , INDEX `FK_sujeto_proceso_ID_SUJETO` (ÌD_SUJETO` ASC) , CONSTRAINT `FK_sujeto_proceso_ID_SUJETO` FOREIGN KEY (ÌD_SUJETO` ) REFERENCES `gpj`.`sujeto` (ÌD_SUJETO` ), CONSTRAINT `FK_sujeto_proceso_ID_PROCESO` FOREIGN KEY (ÌD_PROCESO` ) REFERENCES `gpj`.`proceso` (ÌD_PROCESO` )) DEFAULT CHARACTER SET = utf8;

96

11.2.10 Creación tabla ‘USUARIO’

CREATE TABLE IF NOT EXISTS `gpj`.ùsuario` ( ÌD_USUARIO` BIGINT(20) NOT NULL , àpellido1` VARCHAR(255) NULL DEFAULT NULL , àpellido2` VARCHAR(255) NULL DEFAULT NULL , `contrasenia` VARCHAR(255) NULL DEFAULT NULL , ìdentificacion` VARCHAR(255) NULL DEFAULT NULL , `nombres` VARCHAR(255) NULL DEFAULT NULL , ìd_rol` BIGINT(20) NULL DEFAULT NULL , PRIMARY KEY (ÌD_USUARIO`) , UNIQUE INDEX ìdentificacion` (ìdentificacion` ASC) , INDEX `FK_usuario_id_rol` (ìd_rol` ASC) , CONSTRAINT `FK_usuario_id_rol` FOREIGN KEY (ìd_rol` ) REFERENCES `gpj`.`rol` (ÌD_ROL` )) DEFAULT CHARACTER SET = utf8;

11.2.11 Creación tabla ‘ROL’

CREATE TABLE IF NOT EXISTS `gpj`.`rol` ( ÌD_ROL` BIGINT(20) NOT NULL , `descripcion` VARCHAR(255) NULL DEFAULT NULL , `nombre` VARCHAR(255) NULL DEFAULT NULL , PRIMARY KEY (ÌD_ROL`)) DEFAULT CHARACTER SET = utf8;

97

12. DESARROLLO DE LOS MÓDULOS DEL PROTOTIPO

El sistema de información desarrollado está compuesto de dos módulos complementarios, uno web y otro móvil, los cuales cuentan con las siguientes características:

• Módulo Web: El modulo web está desarrollado para ser manejado por el abogado y se encarga de los aspectos concernientes a la administración y consulta de los procesos judiciales, por medio de las siguientes funcionalidades:

o Creación de procesos judiciales: Permite que el abogado registre un nuevo proceso judicial en el sistema, con los datos de la radicación del proceso, por lo tanto éste proceso debe haber sido radicado en el juzgado respectivo.

o Creación de sujetos procesales: Esta funcionalidad hace parte del proceso de creación de procesos judiciales, y permite el registro de los datos de las personas relacionadas en el proceso judicial creado.

o Consulta de procesos judiciales: Permite que el abogado liste los

procesos judiciales registrados en el sistema, pudiendo consultar la información detallada de alguno de ellos que incluye las actuaciones registradas en el sistema sobre éste proceso.

o Archivo de procesos judiciales: Permite archivar un proceso judicial, de manera que no se liste dentro de los procesos activos del sistema.

o Administración de tipos de actuación sus plazos: Ésta funcionalidad

permite que el abogado administre los tipos de actuación que puede incluir un dependiente judicial al registrar una actuación en el sistema. Adicionalmente permite definir los plazos estándar, para dar respuesta al juzgado, de cada uno de los tipos de actuación agregados, de manera que el sistema tenga valores definidos para conocer los términos de una actuación.

o Registro web de actuaciones procesales: Ésta funcionalidad adicional permite el registro de actuaciones procesales por medio del uso del navegador web, se desarrolló como alternativa para poder registrar actuaciones por medio de los archivos de fotografía sin necesidad del uso de dispositivos móviles.

98

• Módulo Móvil: El módulo móvil se desarrolló para ser manejado por los dependientes judiciales que se encuentren a cargo de la revisión de las actuaciones de los procesos judiciales que litiga el abogado. Éste módulo se encarga de alimentar de los datos de las actuaciones procesales para cada proceso judicial almacenado en el sistema, esto lo realiza por medio de una única funcionalidad:

o Registro y envío de actuaciones procesales: Ésta funcionalidad permite al dependiente judicial registrar en el sistema, en tiempo real, los datos de las actuaciones de los procesos que revisa en cada juzgado. El registro se realiza por medio de un formulario con los datos de la actuación, que puede incluir registro fotográfico de la misma, y el envío de estos datos por internet hacia el servidor donde se encuentra centralizada la información de los procesos.

Es importante tener en cuenta que la comunicación entre los dos módulos se realiza a través de internet, por lo tanto es necesario que se cuente con conectividad a internet en cada uno de ellos. La descripción del funcionamiento y la forma de uso del sistema se puede apreciar en el anexo A.

12.1 HERRAMIENTAS Y FRAMEWORKS UTILIZADOS

Las herramientas y frameworks, más relevantes, utilizados para el desarrollo del prototipo se presentan a continuación: Android SDK : Es el conjunto de herramientas y librerías desarrolladas por Google para desarrollar, compilar y depurar aplicaciones en el sistema operativo Android. Este ambiente de desarrollo se encuentra basado en el lenguaje de programación Java. EclipseLink: Es un proyecto de código abierto para servicios de persistencia creado por la Eclipse Foundation. El proyecto proporciona un framework extensible que permite a las aplicaciones Java interactuar con varios servicios de datos, incluyendo bases de datos, servicios web, mapeo objeto-XML y sistemas de información empresarial. Soporta estándares como Java Persistence API (JPA), Java Architecture for XML Binding (JAXB), Java Connector Architecture (JCA) y Service Data Objects (SDO). Java Server Faces : Es un framework de aplicaciones usado para el desarrollo de interfaces de usuario en aplicaciones java basadas en web, hace parte del estándar de java EE a partir de la versión 6 e incluye componentes para interfaz

99

de usuario, bibliotecas de etiquetas personalizadas, administración de estados, modelo de eventos, validaciones, definición de esquemas de navegación, entre otras características. Jax-RS : API del lenguaje de programación Java que proporciona soporte para la creación de servicios web acordes con el patrón de arquitectura REST. JSON: Formato ligero para el intercambio de datos entre sistemas. Primefaces : librería de componentes de interfaz de usuario para aplicaciones web, basada en Java Server Faces (JSF). Proporciona un conjunto de componentes empaquetados en un mismo archivo, el cual no requiere de configuración especial o dependencias externas. Postgresql 9.3: Sistema gestor de base de datos libre y de código abierto ampliamente usado para producción de aplicaciones que van desde sistemas de escritorio hasta sistemas expuestos a internet con múltiples usuarios concurrentes. SessionBeans: Componentes de programación del lado del servidor en Java EE, que son utilizados para la construcción modular de aplicaciones empresariales ya que su ciclo de vida es administrado por el servidor de aplicaciones de manera automática.

100

13. DISEÑO DE PRUEBAS DEL SISTEMA

Las pruebas del sistema se definen para ser realizadas por medio de ejecución de pruebas de integración continua, razón por la cual se clasifican las actividades de diseño de acuerdo a las buenas practicas que hacen parte de esta metodología, como son:

• Definición de reglas de integración • Definición de reglas de pruebas • Diseño general de pruebas unitarias • Definición de criterios de aceptación

13.1 DISEÑO DE REGLAS DE INTEGRACIÓN

Las reglas de integración definidas para el desarrollo del sistema son:

1. Tener una copia principal del proyecto en la cual se integra cada incremento de funcionalidad terminado.

2. Generar una copia de trabajo para el desarrollo de cada funcionalidad. 3. Realizar integración del proyecto al término del desarrollo de cada una de

las funcionalidades definidas en el proyecto. 4. Guardar una copia del proyecto antes y después de cada integración.

13.2 DISEÑO DE REGLAS DE PRUEBAS

Las reglas de pruebas definidas para el desarrollo del sistema son:

1. Realizar pruebas de caja blanca y de caja negra por cada funcionalidad desarrollada en la copia de trabajo.

2. Realizar pruebas de regresión sobre la copia principal del proyecto cada que es integrada una funcionalidad.

3. Realizar pruebas unitarias de manera prioritaria en la capa de servicio de la aplicación web.

4. Validar las pruebas funcionales contra los criterios de aceptación en cada funcionalidad.

13.2.1 Diseño general de pruebas unitarias

Las pruebas unitarias se realizan como parte del proceso de desarrollo, de manera que se prueban pequeñas partes de la aplicación de manera individual e

101

independiente para asegurar su correcta operación. Como diseño de las pruebas unitarias se definen las prácticas generales que se aplicarán en su ejecución, y estas son:

1. Hacer cada prueba independiente de todas las demás. 2. Probar solo una unidad de código a la vez. 3. Crear representaciones de servicios necesarios para el funcionamiento de

las clases o unidades a probar. 4. Verificar la operación de las operaciones con valores normales, limite y

anormales. 5. Evitar precondiciones innecesarias. 6. No probar ajustes de configuración en pruebas unitarias.

13.3 CRITERIOS DE ACEPTACIÓN

Ya que la el proceso de desarrollo se realiza de manera iterativa e incremental, los criterios de aceptación de las pruebas se definen tanto para pruebas de caja negra como pruebas de caja blanca, garantizando así que se realicen pruebas durante todo el proceso de desarrollo y no únicamente al final; lo cual permite la solución de errores de manera rápida y eficaz.

13.3.1 Funcionalidad de registro de procesos judici ales

Tabla 22: Criterios de aceptación para funcionalidad de registro de procesos judiciales Código Nomb re

Requerimiento Criterio de aceptación Observaciones

RF 1 Crear proceso judicial

* Son actualizadas las tablas de base de datos: proceso, actuación, juzgado y sujeto; agregando el registro respectivo en cada una y las relaciones entre estos registros. * Se cumplen con las restricciones del requerimiento RI 1.

Debe ser probado junto con el requerimiento RF 2. Se requieren juzgados creados en el sistema.

RF 2 Crear sujeto procesal

* Son actualizadas las tablas de base de datos: sujeto y proceso; agregando el registro respectivo en cada una y la

Debe ser probado junto con el requerimiento RF 1

102

relaciones entre registros. * Se cumplen con las restricciones del requerimiento RI 2.

RF 3 Administrar juzgados

* La creación de un juzgado en el sistema se ve reflejado en la lista de juzgados y en la base de datos con los datos ingresados. * La edición de un juzgado previamente creado modifica los datos anteriores por lo nuevos ingresados. * La eliminación de un juzgado remueve el registro de la base de datos y de la lista de juzgados en la interfaz gráfica. * Se cumplen con las restricciones del requerimiento RI 3.

Es requerida la creación de juzgados para poder probar el requerimiento RF 1

13.3.2 Funcionalidad de consulta de procesos judici ales

Tabla 23: Criterios de aceptación para funcionalidad de consulta de procesos judiciales Código Nombre


RF 4 Consultar lista de procesos judiciales activos

* Se despliega la lista de procesos judiciales activos en la interfaz gráfica, que se corresponda con los registros de la tabla de procesos activos en la base de datos. * Al aplicar cualquiera de

103

los filtros disponibles se reducen los resultados de la lista de procesos de manera que únicamente se listen los registros que correspondan al filtro aplicado. * Se cumplen con las restricciones del requerimiento RI 4.

RF 5 Consultar lista de procesos judiciales inactivos

* Se despliega la lista de procesos judiciales activos en la interfaz gráfica, que se corresponda con los registros de la tabla de procesos inactivos en la base de datos. * Al aplicar cualquiera de los filtros disponibles se reducen los resultados de la lista de procesos de manera que únicamente se listen los registros que correspondan al filtro aplicado. * Se cumplen con las restricciones del requerimiento RI 5.

RF 6 Consultar proceso judicial especifico

* Desde el registro en la lista se puede acceder a la información específica del proceso judicial solicitado. * La información del proceso consultado se carga correctamente de acuerdo a los datos registrados en las tablas proceso, juzgado y sujeto de la base de datos.

104

* Se visualiza correctamente la lista de actuaciones del proceso y sus registros fotográficos respectivos en los casos en los que aplique. * Se cumplen con las restricciones del requerimiento RI 6.

13.3.3 Funcionalidad de captura y envío de informac ión de actos procesales

Tabla 24: Criterios de aceptación para funcionalidad de captura y envío de información de actos procesales Código Nombre


RF 7 Captura y envío de información de actuación procesal.

* Es posible ingresar datos al formulario de acuerdo al requerimiento de información RI 7. * Se puede realizar la toma de fotografías y anexarlas al registro de actuación. * Las fotografías son codificadas para envío. * Todos los datos son enviados al servidor, de manera que se correspondan con los datos del requerimiento RI 7. * Se cumplen con las restricciones del requerimiento RI 7.

Para efectuar la prueba de envío de datos al servidor se requiere, como mínimo, la construcción de un prototipo web de recepción de datos.

105

13.3.4 Funcionalidad de recepción y organización de información procesal

Tabla 25: Criterios de aceptación para funcionalidad de recepción y organización de información procesal Código Nombre


RF 8 Recepción y organización de información procesal

* Los datos de información procesal recibidos corresponden a los datos del requerimiento RI 8. * Las fotografías son almacenadas en archivos dentro del servidor y pueden ser visualizadas correctamente. * Las fotografías son clasificadas dentro de carpetas de acuerdo a su pertenencia a procesos judiciales. * Las rutas de las fotografías son almacenadas en el respectivo campo de la tabla actuaciones en la base de datos, y la ruta corresponde inequívocamente con la fotografía registrada. * Se cumplen con las restricciones del requerimiento RI 8.

13.3.5 Funcionalidad de autenticación de usuarios

Tabla 26: Criterios de aceptación para funcionalidad de autenticación de usuarios Código Nombre


RF 9 Control de acceso a componente móvil

* Los datos se transmiten al servidor de manera completa.

Durante el desarrollo de la funcionalidad se pueden realizar

106

* La contraseña es transmitida y almacenada de forma segura por medio de encriptación. * La aplicación muestra mensaje de error de autenticación al usar credenciales erróneas o no haber conexión. * La aplicación no permite acceso sin autenticación exitosa.

pruebas por medio de un prototipo web de recepción de datos.

RF 10 Control de acceso a componente web

* No es posible acceder a ninguna página de la aplicación sin haber realizado una autenticación exitosa. * Se muestra mensaje de error de autenticación al usar credenciales erróneas.

107

14. RESULTADOS OBTENIDOS

El resultado final de proyecto es el prototipo de apoyo a la gestión de litigio de procesos judiciales civiles, el cual que se compone de dos aplicaciones, un sistema web de administración de procesos judiciales, que funciona como servidor y un cliente desarrollado para el sistema operativo Android. El prototipo cumple con las características planteadas en el proyecto y a continuación se describen los componentes que conforman el prototipo. El componente web tiene una interfaz de autenticación que controla el acceso a la aplicación, permitiendo que únicamente los usuarios que se encuentren registrados en el sistema con el rol de abogado puedan ingresar, estos usuarios se gestionan directamente desde la base de datos del sistema, ya que no se creó un mecanismo de creación y gestión de usuarios tal como se definió en el alcance y limitaciones del proyecto. Imagen 38: Interfaz de formulario de autenticación

Fuente: Captura de pantalla en Google Chrome Una vez autenticado, el sistema le permite al usuario abogado registrar nuevos procesos judiciales por medio de un formulario de creación, el cual incluye la información suministrada por el juzgado al momento de la radicación del proceso.

108

Imagen 39: Interfaz de creación de proceso judicial en el sistema

Fuente: Captura de pantalla en Google Chrome En el formulario de creación de proceso judicial en el sistema se incluye un selector de juzgado, este selector obtiene la lista de los juzgados creados en el sistema por medio del administrador de juzgados, el cual permite al abogado crear, editar o eliminar juzgados en el sistema. Imagen 40: Interfaz de administración de juzgados en el sistema

Fuente: Captura de pantalla en Google Chrome Para poder crear un proceso judicial en el sistema, es necesario agregar los sujetos procesales que participan en él, esto se realiza por medio de un formulario

109

contextual que permite agregar los datos de los sujetos procesales y relacionarlos directamente con el proceso judicial que se está registrando. En los casos en los que el sujeto ya ha sido registrado en el sistema los datos son autocompletados al momento de diligenciar el número de identificación, permitiendo actualizar los datos registrados anteriormente, de ser necesario. Imagen 41: Interfaz de agregación de sujeto procesal a un proceso judicial

Fuente: Captura de pantalla en Google Chrome El formulario de creación de procesos judiciales realiza las validaciones de lógica de negocio definidas en las restricciones de los requerimientos, evitando de esta manera que se puedan registrar procesos judiciales en el sistema que contengan errores desde el punto de vista de la lógica de negocio.

110

Imagen 42: Validaciones de lógica de negocio en la creación de procesos judiciales

Fuente: Captura de pantalla en Google Chrome La consulta de procesos se realiza a través del componente web, en la sección de consulta de procesos, donde se listan los procesos judiciales activos en el sistema. La información mostrada por cada proceso judicial es el número de radicación, los demandantes, demandados, juzgado que lleva el proceso, fecha de última actuación y fecha de término. En esta lista es posible ordenar y usar filtros por criterio, lo cual funciona como ayuda visual para que el abogado pueda priorizar el orden de revisión y respuesta de los procesos judiciales. Imagen 43: Interfaz de consulta de procesos judiciales activos

Fuente: Captura de pantalla en Google Chrome Adicionalmente es posible realizar consulta de procesos judiciales inactivos, los cuales han sido archivados por terminación y no se tiene en cuenta la fecha del término.

111

Imagen 44: Interfaz de consulta de procesos judiciales inactivos

Fuente: Captura de pantalla en Google Chrome Al ver la información detallada de un proceso judicial, se muestran todos los datos de éste incluida la lista de actuaciones que se han registrado en el sistema sobre este proceso Imagen 45: Interfaz de visualización de detalle de proceso judicial

Fuente: Captura de pantalla en Google Chrome La lista de las actuaciones registradas en cada proceso tiene los datos ingresados al momento de registrar la actuación en el sistema, como son el tipo de actuación, la fecha de ocurrencia, el término y una anotación; adicionalmente se tiene el registro fotográfico de la actuación capturada directamente en el juzgado, este puede contener varias fotografías por cada actuación.

112

Imagen 46: Interfaz de visualización de registro fotográfico de actuación

Fuente: Captura de pantalla en Google Chrome Los diferentes tipos de actuación que se pueden registrar en el sistema se pueden administrar en el componente web, en esta administración se puede cambiar el nombre y asignar el plazo estándar, en días, que tiene este tipo de actuación para dar respuesta al juzgado. Los datos sobre tipos de actuación definidos de esta manera son obtenidos al momento de registrar las actuaciones y llena los datos del selector de tipo de actuación, adicionalmente el sistema asigna de manera automática un término basado en el tipo de actuación, en caso de no ser definido un término fijo por el dependiente al momento de registrar la actuación.

113

Imagen 47: Interfaz de administración de tipos de actuación

Fuente: Captura de pantalla en Google Chrome El componente móvil del prototipo es una aplicación realizada para ser ejecutado en dispositivos móviles con sistema operativo Android 4 o superior, los cuales deben contar con cámara fotográfica. La aplicación cuenta con una interfaz de autenticación que controla el acceso, de manera que únicamente los usuarios registrados en el sistema con el rol de dependiente judicial puedan hacer uso de la aplicación. Imagen 48: Interfaz de autenticación en componente móvil

Fuente: Captura de pantalla de emulador android Para realizar la comprobación de las credenciales de los usuarios se realiza una solicitud al servidor enviando las credenciales ingresadas, y como respuesta se obtiene el permiso de autenticación a la aplicación.

114

Imagen 49: Interfaz de validación de credenciales en componente móvil

Fuente: Captura de pantalla de emulador android La función principal de la aplicación es hacer el registro de las actuaciones de un proceso judicial, esto debe realizarse en el juzgado respectivo donde se tenga conocimiento del proceso. Para realizar este registro se diligencia un formulario con los datos de la actuación, tales como el número de radicación del proceso, el tipo de actuación, la fecha de ocurrencia, la fecha de término y un espacio para realizar anotaciones para el abogado; y adicionalmente se realiza la captura de fotografías de la actuación. Imagen 50: Interfaz de registro de actuación procesal en componente móvil

Fuente: Captura de pantalla de emulador android Todos los datos capturados de la actuación son enviados al servidor en formato json por medio del uso de la función POST del protocolo HTTP y son recibidos

115

gracias al uso de servicios web tipo REST expuestos en el servidor. El servidor guarda la información en base de datos y almacena las imágenes forma de archivos de imagen. De esta manera se alimenta de datos el sistema para que el usuario del componente web pueda ver inmediatamente la información registrada y hacer uso de ella. Como funcionalidad adicional a las propuestas en el alcance del proyecto, en el prototipo se implementó una funcionalidad de registro de actuaciones por medio del uso del componente web, con el objetivo de poder registrar actuaciones de manera web para los casos en los que no se cuente con conectividad al momento de tomar las fotografías. Esta funcionalidad está presente tanto para el abogado como para el dependiente judicial y requiere tener los datos de la actuación y contar con los archivos de las fotografías en el equipo para poder cargarlos y enviarlos al servidor. Imagen 51: Interfaz de registro de actuación procesal en componente web

Fuente: Captura de pantalla en Google Chrome

116

15. ESTIMACIÓN BENEFICIO / COSTO

Para la estimación beneficio/costo se realizaron dos cálculos, el primero fue la estimación de los costos relacionados con los problemas de gestión del litigio de procesos judiciales y el segundo fue la estimación del costo de implementación del proyecto y su mantenimiento durante 5 años; para de esta manera poder contrastarlos y estimar la relación beneficio/costo de la implementación de un proyecto de gestión basado en el prototipo realizado.

15.1 ESTIMACIÓN DE COSTOS RELACIONADOS CON PROBLEMA S DE GESTIÓN

Para la estimación de los costos relacionados con los problemas de gestión del trabajo de litigio de procesos judiciales civiles se deben tener en cuenta las diferentes cuantías que pueden tener este tipo de procesos, las cuales son:

• Cuantía mínima: Procesos por un valor hasta de 40 millones de pesos. • Cuantía menor: Procesos por valores que van desde 40 millones de pesos

hasta 150 millones de pesos. • Cuantía mayor: Procesos por valores superiores a 150 millones de pesos.

Estas cuantías son especialmente relevantes para la estimación beneficio/costo debido a que son los valores que pueden perder los clientes en caso de que ocurra un fallo en contra en sus procesos, lo cual es posible que ocurra debido al vencimiento de los términos establecidos para presentar las manifestaciones al juzgado. Según las encuestas realizadas a los diferentes abogados, no se tiene registro de la cantidad de procesos a los cuales se les vencen los términos, pero se llega a la estimación de diez procesos al año por cada mil quinientos llevados, siendo de mínima cuantía aproximadamente el 70% de éstos procesos. Los procesos de mayor cuantía se excluyen de la estimación ya que estos son especialmente importantes para los abogados y habitualmente les prestan atención especial a sus términos, razón por la cual no es habitual el vencimiento de términos en estos procesos. Adicionalmente se asigna el estimado de que en los procesos con términos vencidos la perdida se hace efectiva el 60% de las veces, ya que el vencimiento de términos no en todos los casos implica la pérdida del proceso. Con estos valores asignados, se realiza el cálculo estimado del promedio de dinero perdido al año por vencimiento de términos en los procesos judiciales, que incluye tanto a clientes como al abogado, contando con que se vencen

117

aproximadamente 10 de cada 1500 procesos al año y esto influye el 60% de las veces en la pérdida del proceso, teniendo además que el 70% de los procesos son de mínima cuantía y 30% de menor cuantía. El cálculo estimado se puede ver en la Tabla 27. Tabla 27: Pérdida anual estimada para abogado con 1500 procesos simultáneos Cuantía

del proceso

Valor del proceso

Promedio de valores

Cantidad de

procesos

Posible p érdida Posible p érdida efectiva para

clientes

Posible pérdida

efectiva para abogado (10%

de honorarios)

Mínima 0-40 millones

$20.000.000 7 $140.000.000 $84.000.000 $8.400.000

Menor 40-150 millones

$95.000.000 3 $285.000.000 $171.000.000 $17.100.000

TOTAL 10 $425.000.000 $255.000.000 $25.500.000 De esta manera se puede apreciar que el vencimiento de términos en los procesos judiciales por problemas de gestión le cuesta en promedio $25.500.000 al año a un abogado y $255.000.000 en promedio a los clientes de éste, para un abogado que lleve en promedio 1500 procesos judiciales al mismo tiempo; aunque esta cifra puede variar dependiendo de la forma de organización del trabajo de cada abogado, pudiendo ser mayor o menor. Por lo tanto, con estos valores estimados se puede hacer la relación de la perdida estimada con la cantidad de procesos que litiga simultáneamente un abogado, tal como muestra la Tabla 28, teniendo como máximo 4500 procesos ya que los casos de abogados con más de 3500 procesos simultáneos no son comunes. Tabla 28: Pérdida anual estimada de acuerdo a cantidad de procesos simultáneos Cantidad de procesos litigados

simultáneamente Perdida estimada anual para

clientes Perdida estimada anual para

abogado

1500 $255.000.000 $25.500.000 3000 $510.000.000 $51.000.000 4500 $765.000.000 $76.500.000

15.2 ESTIMACIÓN DE COSTO DE IMPLEMENTACIÓN DEL PROY ECTO

La implementación de un proyecto de apoyo a la gestión del litigio de procesos judiciales civiles como el planteado en el prototipo tiene costos asociados con la

118

infraestructura necesaria para su ejecución, costos de desarrollo y costos de mantenimiento. La infraestructura mínima necesaria para la implementación del proyecto consta de un equipo de cómputo que funcione como servidor, los dispositivos móviles y la conexión a internet de cada uno, asumiendo la necesidad de 3 dispositivos por cada 1500 procesos revisados. Un equipo servidor en el mercado se encuentra actualmente por un precio de $6.149.9913 pesos. Cada teléfono inteligente con las características mínimas requeridas se encuentra por un valor de $729.9004 pesos, aunque este valor puede oscilar dependiendo del modelo y la marca. Los planes de internet empresarial se encuentran en el mercado por $84.9005 pesos mensuales, dando como resultado $1.018.800 pesos al año. Los costos de desarrollo se estiman teniendo en cuenta el talento humano requerido para un proyecto de este tipo, con salarios promedio, por un tiempo estimado de 9 meses, dando los valores de la Tabla 29; teniendo en cuenta que estos valores solo aplican una única vez. Tabla 29: Costos de talento humano para el desarrollo del proyecto Talento Humano Salario promedio por 9

meses Líder de proyecto $40.500.000 Arquitecto de software $40.500.000 Analista funcional $22.500.000 Desarrollador $27.000.000 Desarrollador $27.000.000 TOTAL $157.500.000 Los costos de mantenimiento del proyecto se estiman en un 20% del costo de desarrollo de forma anual, dando como resultado $31.500.000 al año. De esta forma se obtiene el costo estimado del desarrollo e implementación del proyecto para 1500 procesos judiciales revisados, proyectado a 5 años de uso, teniendo en cuenta que a mayor número de procesos aumenta únicamente el costo de infraestructura por la cantidad de dispositivos móviles utilizados. Este estimado se puede apreciar en la Tabla 30 .

3 Consulta de precios realizada a equipos servidores marca Dell (Dell Inc.) 4 Consulta de precios realizada a equipos de teléfonos inteligentes marca Motorola (Colombiana de Comercio S.A.) 5 Consulta de precios realizada a planes empresariales de la empresa movistar (Telefonica)

119

Tabla 30: Costos estimados de implementación del proyecto Costos

estimados de infraestructura

Costos estimados de desarrollo

Costos estimados de mantenimiento

Total

Año 1 $9.358.491 $157.500.000 $31.500.000 $189.000.000 Año 2 $1.018.800 $0 $31.500.000 $32.518.800 Año 3 $1.018.800 $0 $31.500.000 $32.518.800 Año 4 $1.018.800 $0 $31.500.000 $32.518.800 Año 5 $1.018.800 $0 $31.500.000 $32.518.800 Total $13.433.691 $157.500.000 $157.500.000 $319.075.200

120

15.3 RELACIÓN BENEFICIO COSTO

Con el estimado de costos relacionados con los problemas de gestión del litigio de procesos judiciales y la estimación de costo de implementación del proyecto y su mantenimiento se realiza un contraste con proyección a 5 años para estimar la relación beneficio costo de la implementación de un proyecto de gestión basado en el prototipo realizado. El resultado de la estimación se puede apreciar en la tabla Tabla 31. Tabla 31: Beneficio-costo estimado para la implementación del proyecto durante 5 años Cantidad de

procesos litigados

simultáneamente por el abogado

Perdida estimada para

clientes durante 5 años

Perdida estimada para

abogado durante 5

años

Costo de implementación

del proyecto durante 5 años

Beneficio estimado para

clientes

Beneficio estimado para

abogado

1500 $1.275.000.000 $127.500.000 $319.075.200 $1.275.000.000 -$191.575.200

3000 $2.550.000.000 $255.000.000 $321.264.900 $2.550.000.000 -$66.264.900

4500 $3.825.000.000 $382.500.000 $323.454.600 $3.825.000.000 $59.045.400

De esta manera se puede apreciar que los beneficios, que para el caso se trata de la no pérdida de dinero, se ven reflejados de manera directa en los clientes del abogado los cuales no incurrirían en pérdidas monetarias debido a problemas de gestión del abogado. Para el caso del beneficio obtenido por el abogado, se puede ver como la no perdida de dinero empieza a reflejarse en beneficio para los casos de 4500 procesos simultáneos, tomando como ganancia el únicamente el 10% que recibe de honorarios en cada proceso, aunque si se toman valores superiores a 5 años el beneficio es mucho mayor.

121

16. TRABAJO FUTURO Y RECOMENDACIONES

El prototipo realizado plantea una base importante sobre el uso de la tecnología en la gestión del litigio de procesos judiciales, en especial la aplicación de dispositivos móviles en la optimización de tiempos de revisión y respuesta de actuaciones judiciales. En este prototipo se logra condensar la funcionalidad básica necesaria para apoyar la gestión de litigio de procesos judiciales. Como paso siguiente a este proyecto, se puede considerar la ampliación del modelo de distribución aplicando la prestación del software como servicio, de manera que se mantenga unificada la infraestructura, el mantenimiento y operación del sistema, y distintos clientes puedan hacer uso del servicio al mismo tiempo por medio de internet, sin tener que implementar toda la infraestructura necesaria para la ejecución del sistema en sus organizaciones. Para complementar el trabajo del prototipo y llevar el sistema a un mayor nivel de madurez, se puede incluir un mecanismo de administración de roles y flujos de trabajo, permitiendo que el sistema pueda ser ajustado a la organización interna de trabajo de cada abogado. Además, teniendo el prototipo como base, es posible realizar un incremento de funcionalidades del sistema para que tenga mayor utilidad en la gestión de litigio de procesos judiciales, como puede ser un sistema de alertas de términos próximos a vencerse, la organización de rutas de revisión y su envío directo a los dispositivos móviles, de manera que se puedan priorizar las revisiones y optimizar los tiempos de las mismas. Como un importante trabajo futuro se puede adicionar una funcionalidad que permita crear, editar y guardar las respuestas de las actuaciones desde el sistema, unificando todo el proceso de litigio en el mismo sistema, para lo cual se recomienda incluir adicionalmente la funcionalidad de la visualización de los códigos de procedimiento y jurisprudencias, para que sirvan como material de referencia en la generación de respuestas al juzgado.

122

17. CONCLUSIONES

• El uso de una metodología de desarrollo facilitó la organización de la

ejecución de actividades, aun siendo un equipo de unipersonal, ya que por medio del uso de la metodología fue posible conocer en todo momento en que punto de ejecución se encontraba el proyecto y cuáles eran las actividades pendientes.

• El uso de una metodología iterativa e incremental resultó más efectivo que el uso de metodologías tipo cascada, debido al desconocimiento inicial de todos los detalles del dominio del sistema o del desarrollo en las etapas de análisis y diseño, ya que permitió realizar ajustes de diseño en etapas avanzadas del desarrollo, a medida que fue teniendo claro el dominio del sistema.

• El uso de formatos de requerimientos simplificados resultaron ser eficientes

al momento realizar el desarrollo del sistema, ya que de ellos se puede obtener la información necesaria y suficiente de manera rápida, aunque requieren que el desarrollador tenga un entendimiento completo del sistema.

• El diseño de la interfaz de usuario fue uno de los temas más relevantes

para el entendimiento del sistema, teniendo en cuenta que se aplica en un ambiente laboral donde los usuarios del sistema no acostumbran trabajar con el uso de tecnología.

• El uso de servicios web tipo REST resultó ser más eficiente que los

servicios SOAP para la transmisión de datos desde clientes ligeros, debido a que se transmiten menos datos extras debido a la simplicidad del formato, además el uso de las funciones del protocolo http evita el uso de librerías de terceros que puedan generen incompatibilidad en los distintos dispositivos o versiones del sistema operativo.

• Al transmitirse imágenes por red es necesario controlar el tamaño de éstas,

debido a que la diferencia de resoluciones de cámara en los diferentes dispositivos puede generar que el mensaje sea demasiado grande y no pueda ser recibido, este problema se puede ser solucionado asignando el mismo tamaño a todas las imágenes antes de transmitirse.

• Resultó acertado realizar un análisis detallado del dominio del sistema

antes del mismo planteamiento del proyecto, ya que todas las características técnicas y del negocio relevantes eran conocidas y los

123

detalles fueron refinados de manera continua durante las diferentes iteraciones del proyecto.

124

18. BIBLIOGRAFÍA

Allamaraju, S. (2010). Restful Web Services Cookbook. O'Reilly Media, Inc. Cabanellas, G. (2006). Diccionario jurídico elemental. Buenos Aires: Heliasta. Colombiana de Comercio S.A. (s.f.). Alkosto. Recuperado el 01 de Septiembre de

2015, de Alkosto: http://www.alkosto.com/celular-motorola-moto-g-3era-generacion

Competitividad, C. P. (2012). Informe Nacional de Competitividad. Colombia. Competitividad, C. P. (2013). Informe Nacional de Competitividad. Colombia. Couture, E. J. (1958). Estudios de Derecho Procesal Civil. Buenos Aires: Roque

Depalma Editor. Dell Inc. (s.f.). Dell Colombia. Recuperado el 01 de Septiembre de 2015, de Dell

Colombia: http://www.dell.com/co/empresas/p/poweredge-t430/pd?oc=pe_t430_1454&model_id=poweredge-t430

Díaz, A. (2010). Los documentos electrónicos y sus efectos legales en Colombia. Revista de Derecho Informático.

El Espectador. (29 de Enero de 2014). Un proceso judicial en Colombia sin papeles. El Espectador, pág. 1.

Farago, P. (18 de Febrero de 2013). China Knocks Off U.S. to Become World's Top Smart Device Market. Recuperado el 1 de Julio de 2013, de Flurry, Inc: http://www.flurry.com/bid/94352/China-Knocks-Off-U-S-to-Become-World-s-Top-Smart-Device-Market

Goncalvez, A. (2013). Beginning Java EE 7. Apress. Google Inc. (15 de Agosto de 2015). Android developers. Obtenido de Android

developers: https://developer.android.com/about/dashboards Impacto Virtual. (2010). Asistente Judicial, Software Abogados. Recuperado el 1

de Febrero de 2014, de Impacto Virtual : http://www.impactovirtual.com/AsistenteJudicial/

Kalin, M. (2013). Java Web Services: Up and Running. O'Reilly Media, Inc. Landacom. (s.f.). Redelex. Recuperado el 16 de 05 de 2014, de Redelex:

http://www.redelex.com/ Lee, W.-M. (2012). Beginning Android 4 Application Development. Wrox. Madrigal, R. (2005). El procedimiento judicial electrónico. Revista de Derecho y

Tecnologías de la Información Nº 3-2005. UNED, Costa Rica. Pragmatica Software. (s.f.). Producto Orion Juridica. Recuperado el 25 de Enero

de 2014, de Pragmatica Software: http://www.pragmaticasoftware.com/id1.html

República de Colombia. (s.f.). Código de Procedimiento Cívil Colombiano. Sommerville, I. (2005). Ingeniería de Software. Septima edición. Madrid: Pearson

Education. Telefonica. (s.f.). Movistar Colombia. Recuperado el 2015 de Septiembre de 2015,

de Movistar Colombia: http://descubre.movistar.co/Oferta_Pymes/

125

Unitech. (s.f.). Producto Iurix. Recuperado el 5 de Febrero de 2014, de Unitech: http://www.unitech.com.ar/productos/iurix/

Universidad Católica de Colombia. (2010). Manual de derecho procesal Civil. Bogotá: U.C.C.

Visual Paradigm. (10 de Julio de 2015). Visual Paradigm Gallery. Obtenido de Visual Paradigm Gallery: http://www.visual-paradigm.com/VPGallery/orm/Overview.html

Wikipedia. (s.f.). Recuperado el 10 de Noviembre de 2013, de http://en.wikipedia.org/wiki/Web_application

Wikipedia. (s.f.). Recuperado el 10 de Noviembre de 2013, de http://en.wikipedia.org/wiki/Mobile_app

ANEXO A. MANUAL DE USUARIO DEL SISTEMA

El sistema desarrollado corresponde a un prototipo de sistema de información para el apoyo a la gestión del litigio de procesos judiciales civiles. El sistema está desarrollado para atender los requerimientos orientados a la gestión de información concerniente a los procesos judiciales civiles manejados por un abogado, de manera que pueda acceder a la información de manera oportuna para poder dar respuesta a las necesidades de litigio de tales procesos judiciales dentro de los plazos respectivos. El sistema se compone de dos módulos complementarios, un módulo web y un módulo móvil, con los cuales se cumple con las funcionalidades de registro de procesos judiciales, consulta de procesos judiciales, registro de actos procesales, administración de juzgados, administración de tipos de actuación, y autenticación de usuarios. A continuación se presenta una descripción práctica y didáctica sobre el modo de uso de las diferentes funcionalidades del sistema, tomando en consideración las acciones que ejecutan los dos tipos de usuarios del sistema, el usuario abogado y el usuario dependiente judicial.

REGISTRO DE PROCESOS JUDICIALES El propósito de la funcionalidad de registro de procesos judiciales es la creación de procesos judiciales dentro del sistema, de manera que queden disponibles para su posterior consulta y actualización. Incluye las siguientes acciones de usuario:

• Creación del proceso judicial • Creación y asociación de sujetos procesales

Creación del proceso judicial La creación de un proceso judicial en el sistema es una acción que únicamente puede ser ejecutada por un usuario que posea el rol de abogado, esta acción se realiza por medio del módulo web a través del formulario de “Nuevo Proceso”

De esta manera se despliega el formulario con el cual se crea un nuevo proceso judicial en el sistema

El formulario se encuentra dividido en tres secciones, la primera sección se destina para los datos de radicación del proceso, como son el número único de radicación, el juzgado y la fecha de radicación; la segunda sección hace referencia a la información del crédito del proceso, lo cual incluye la cuantía y el crédito litigado; la tercera sección se destina para la información de los sujetos del proceso, en donde se agregan los datos de todos los implicados en el proceso judicial. La información sobre el juzgado usa un mecanismo de autocompletado, para evitar errores de digitación.

Para el funcionamiento del mecanismo de autocompletado se deben digitar mínimo dos caracteres de esta manera el formulario despliega las opciones de juzgado correspondientes, de las cuales se debe elegir una para que la información de juzgado sea válida.

Crear proceso judicial Para poder crear el proceso judicial es necesario diligenciar completamente el formulario, incluyendo la información de los sujetos procesales. El proceso se puede crear usando el botón “Crear proceso”

En caso de tener errores en el formulario, como campos obligatorios faltantes o inconsistencias en los sujetos procesales, el sistema muestra el mensaje de error correspondiente y no permite la creación del proceso.

En caso de que el formulario no contenga errores el proceso judicial será registrado en el sistema y automáticamente el navegador se re-direccionará hacia la función de consulta de procesos judiciales.

Creación y asociación de sujetos procesales La acción de creación y asociación de sujetos procesales hace parte de la funcionalidad de registro de procesos judiciales en el sistema, y se utiliza para agregar los datos de todas las personas implicadas en el proceso judicial. Agregar sujeto procesal Para agregar un sujeto se debe dar clic en el botón “Agregar sujeto” dentro del formulario.

Al hacer esto, aparece un formulario emergente, para poder diligenciar los datos de un sujeto procesal

En el formulario destinado a ingresar información del sujeto procesal es obligatorio diligenciar los campos:

• Parte • Es cliente? • Tipo de identificación • Identificación • Nombre

El campo “Parte” en el formulario hace referencia al rol que cumple esa persona en el proceso judicial litigado. El campo “Es cliente?” en el formulario es una casilla de verificación para determinar si el sujeto que se está agregando es el cliente en el proceso judicial

litigado (en este caso se debe tener en cuenta que un proceso judicial no debe tener sujetos demandantes y sujetos demandados como clientes simultáneos) Las opciones disponibles en la lista desplegable de tipo de identificación son:

• C.C. (Cédula de ciudadanía) • NIT (Número de identificación tributaria) • C.E. (Cédula de extranjería)

El campo de número de identificación tiene la función de autocompletar todos los campos restantes del formulario en caso de ingresar un número de identificación registrado previamente. Es importante tener en cuenta que al editar la información del sujeto procesal, ésta se editará en todos los procesos judiciales en los cuales esté relacionado el sujeto.

ADMINISTRACION DE JUZGADOS Y TIPOS DE ACTUACIÓN

Administración de juzgados La acción de administración de juzgados se encuentra presente para el usuario abogado, y tiene la función de agregar, editar o eliminar juzgados en el sistema; los cuales estarán disponibles para ser elegidos por medio del mecanismo de autocompletado del campo juzgado durante la creación del proceso.

Acceso Para acceder a la administración de juzgados se debe navegar al menú “Administrar” y dar clic en la opción “Juzgados”.

Una vez hecho esto, se despliega el formulario de administración de juzgados y la lista de los juzgados ya cargados en el sistema.

Agregar juzgado Para agregar un juzgado se debe diligenciar los campos del formulario que se encuentra en la parte superior y luego dar clic en el botón “Agregar”

Una vez agregado el juzgado, éste aparece en la lista de juzgados de la parte inferior.

Editar juzgado

Para editar un juzgado se debe hacer clic en el botón con el símbolo de la fila correspondiente al juzgado a editar; de esta manera se habilita el modo de edición, lo cual permite modificar los datos directamente sobre la fila.

Una vez realizados y aceptados los cambios se guarda en el sistema la información actualizada del juzgado modificado.

Eliminar juzgado

Para eliminar un juzgado se debe hacer clic en el botón con el símbolo de la fila correspondiente al juzgado a eliminar, de esta manera el registro del juzgado es eliminado del sistema.

Administración de tipos de actuación La administración de tipos de actuación permite modificar los plazos estándar que se tiene para la entrega de una actuación procesal de acuerdo a su tipo.

Acceso Para acceder a la administración de tipos de actuación se debe navegar al menú “Administrar” y luego dar clic en la opción “Tipos de actuación”.

Una vez hecho esto, se despliega la tabla con los datos de los tipos de actuación disponibles en el sistema.

Editar plazo estándar Para editar el plazo estándar de un tipo de actuación determinado se debe dar clic

en el botón de la fila correspondiente al tipo de actuación que se desea modificar; de esta manera se habilita el modo de edición que permite cambiar el valor del plazo estándar, en días.

CONSULTA DE PROCESOS JUDICIALES El propósito de la funcionalidad de consulta de procesos judiciales es la búsqueda y acceso a la información de los procesos judiciales que han sido creados dentro del sistema, incluyendo la información de las diferentes actuaciones que son registradas para cada proceso. Incluye las siguientes acciones de usuario:

• Consultar lista de procesos judiciales activos • Consultar lista de procesos judiciales inactivos • Consultar proceso judicial específico

Consultar lista de procesos judiciales activos La consulta de procesos judiciales activos en el sistema es una acción disponible para el usuario abogado, ésta acción se realiza por medio del módulo web dando clic en la opción “Consultar Proceso”, lo cual despliega la lista de procesos activos en el sistema.

La lista de procesos muestra una tabla con la información para cada proceso del número de radicación, los demandantes, los demandados, el juzgado que lleva el proceso, la fecha de la última actuación registrada y el término de esa actuación, si se tiene registrado.

Filtro y ordenamiento de resultados

En la tabla es posible filtrar los resultados haciendo una búsqueda por el número de radicación en la caja de texto que se encuentra en el título de la columna.

La lista de resultados se puede ordenar en orden ascendente o descendente de acuerdo al criterio de fecha, tanto de la última actuación como del término de ésta; para esto se hace clic sobre el título de la columna que se quiera usar como

criterio, las columnas que tienen esta opción tienen el símbolo .

Consultar lista de procesos judiciales inactivos La consulta de procesos judiciales inactivos en el sistema es una acción disponible para el usuario abogado, ésta acción se realiza por medio del módulo web dando clic en la opción “Procesos Inactivos”.

La lista de procesos inactivos muestra una tabla con la información para cada proceso de número de radicación, demandantes, demandados, juzgado que lleva el proceso, fecha de última actuación registrada y tipo de ésta última actuación.

Consultar proceso judicial específico La consulta de proceso judicial específico se puede realizar, tanto desde la lista de procesos activos como de procesos inactivos, por medio del botón de consulta de

proceso que se encuentra en cada registro de la lista . Al dar clic en éste botón se despliega la información del proceso judicial específico.

La información del proceso se divide en dos secciones, la primera tiene la información general como el número de radicación, la fecha de radicación, el juzgado, la cuantía, el crédito y la lista de sujetos procesales, tanto demandantes como demandados. La segunda sección tiene la lista de las actuaciones registradas para este proceso, con la respectiva información en cada una del tipo de actuación, fecha de ocurrencia, término y una anotación opcional registrada por el dependiente judicial al momento de registrarla. En los casos en los que la actuación tiene registro fotográfico, es posible revisarlo

por medio del botón , lo cual despliega una ventana modal con el registro fotográfico de la actuación.

En caso de que la actuación tenga registradas múltiples fotografías, es posible

navegarlas usando los botones en la ventana modal. Para poder seguir navegando por las funcionalidades del sistema se debe cerrar la ventana modal desplegada.

REGISTRO Y ENVÍO DE INFORMACIÓN DE ACTOS PROCESALES El propósito de la funcionalidad de registro y envío de información de actuaciones procesales es el registro de las actuaciones directamente desde los juzgados por parte del dependiente judicial, y la puesta en conocimiento de ésta información en tiempo real al abogado, por medio del envío de tales datos a través de internet. Para el cumplimiento de esta funcionalidad se hace uso de dispositivos móviles que cuenten con cámara y conexión a internet. Incluye la siguiente acción del usuario:

• Registro y envío de información del acto procesal por medio de dispositivo

móvil Adicionalmente se cuenta con un sistema web para el registro de actos procesales, este tiene el propósito de servir como sistema de respaldo en caso de no poder realizar el envío de datos por medio del dispositivo móvil al momento del registro de la actuación. Incluye la siguiente acción del usuario

• Registro de información del acto procesal por medio de navegador web

Registro y envío de información del acto procesal p or medio de dispositivo móvil

Acción ejecutada por el usuario dependiente judicial, por medio del uso del módulo móvil del sistema usando el formulario que permite registrar información de una actuación en el sistema.

En el formulario se debe diligenciar la siguiente información:

• Numero de radicación del proceso • Tipo de actuación • Fecha de ocurrencia de la actuación • Termino de la actuación • Observaciones • Registro fotográfico de la actuación

Para poder tomar el registro fotográfico se usa el botón “Tomar Registro”, el cual despliega la aplicación de la cámara fotográfica del dispositivo móvil para realizar la toma de la fotografía, ésta acción se debe repetir para cada fotografía que se desee anexar al registro de la actuación.

Una vez que es diligenciado el formulario completo se puede usar el botón de

envío con el cual la información registrada es enviada al servidor web, por medio de la red, en caso de ser exitoso el envío aparece un mensaje informativo y se limpian automáticamente los campos del formulario.

Registro de información del acto procesal por medio de navegador web Esta acción puede ser ejecutada por un abogado por medio del uso de un navegador web, y requiere los archivos de las fotografías de la actuación. Para ingresar al formulario de registro se debe acceder al módulo web e dirigirse a la opción “Nueva Actuación”

De esta manera se despliega el formulario de registro de una actuación por medio del navegador web.

Los campos del formulario son los mismos que se encuentran en el componente

móvil. Para realizar la carga de las fotografías se usa el botón y luego seleccionar todos los archivos que se deseen anexar al registro.

Una vez elegidos los archivos de imagen deseados, se pueden ver todos los archivos elegidos.

En caso de un error en la selección de imágenes es posible descartarlas por

medio del botón para cada una, o el botón para descartarlas todas.

Para asociar las imágenes al registro de la actuación se usa el botón , lo cual las agrupa en una sección emergente que permite ver los archivos elegidos para anexar a la actuación al momento de registrarse en el sistema.

Una vez cargadas las imágenes y diligenciado el formulario se da clic en el botón “Crear Actuación”, lo cual registra la actuación en el sistema.

En caso de que los datos ingresados en el formulario sean erróneos, se mostrarán los mensajes de validación correspondientes y el sistema no permitirá la creación de la actuación.

AUTENTICACIÓN DE USUARIOS Por medio de esta funcionalidad se controla el acceso a los módulos, tanto web como móvil, para que únicamente los usuarios que tengan la autorización puedan hacer uso del sistema. Incluye las siguientes acciones de usuario:

• Acceder al componente web • Acceder a la aplicación móvil

Ingreso al módulo web El ingreso al módulo web únicamente está habilitado para usuarios registrados en el sistema con el rol de abogado. Para acceder al módulo se deben tener las credenciales de autenticación que incluyen identificación del abogado y contraseña.

En caso de autenticación exitosa, el sistema se redirige automáticamente a la lista de procesos activos. Si los datos de autenticación no son correctos no es posible acceder al módulo y muestra el mensaje de error correspondiente.

Ingreso al módulo móvil El ingreso al módulo móvil únicamente está habilitado para usuarios registrados en el sistema con el rol de dependiente. Para acceder al módulo se deben tener las credenciales de autenticación que incluyen identificación del usuario y contraseña.

En caso de que los datos de autenticación sean incorrectos el sistema muestra un mensaje de error correspondiente.

En caso de autenticación exitosa el sistema se redirigirá al formulario de registro de actuaciones.

Documents

DISEÑO Y DESARROLLO DE UN PROTOTIPO WEB Y ...repository.udistrital.edu.co/bitstream/11349/3118/1/...2 DISEÑO Y DESARROLLO DE UN PROTOTIPO WEB Y MOVIL DE APOYO A LA GESTION DE LITIGIO