Castillo Cerva

FACULTAD DE INGENIERÍA Y ARQUITECTURA
ESCUELA PROFESIONAL DE INGENIERÍA DE COMPUTACIÓN Y SISTEMAS
SISTEMA DE CONTROL Y SEGUIMIENTO DE PROCESOS

JUDICIALES PARA ESTUDIOS DE ABOGADOS UTILIZANDO
INTELIGENCIA DE NEGOCIOS EN CLOUD COMPUTING
PRESENTADA POR
DENNIS WILMER CASTILLO MAMANI
LUIS ALONSO CERVA CABRERA
TESIS PARA OPTAR EL TÍTULO PROFESIONAL DE
INGENIERO DE COMPUTACIÓN Y SISTEMAS
LIMA – PERÚ
2016
Reconocimiento - No comercial - Compartir igual
CC BY-NC-SA
El autor permite transformar (traducir, adaptar o compilar) a partir de esta obra con fines no comerciales,
siempre y cuando se reconozca la autoría y las nuevas creaciones estén bajo una licencia con los mismos
términos.
http://creativecommons.org/licenses/by-nc-sa/4.0/
ESCUELA PROFESIONAL DE INGENIERÍA DE COMPUTACIÓN Y
SISTEMAS
SISTEMA DE CONTROL Y SEGUIMIENTO DE PROCESOS

JUDICIALES PARA ESTUDIOS DE ABOGADOS UTILIZANDO
INTELIGENCIA DE NEGOCIOS EN CLOUD COMPUTING
TESIS
PARA OPTAR EL TÍTULO PROFESIONAL DE INGENIERO DE

COMPUTACIÓN Y SISTEMAS
PRESENTADO POR
CASTILLO MAMANI, DENNIS WILMER

CERVA CABRERA, LUIS ALONSO
LIMA – PERÚ
2016
Dedicatoria
Dedicamos esta tesis a nuestras familias,

maestros, compañeros y amigos, quienes sin
su ayuda nunca hubiéramos podido hacer
esta tesis.
ii
Agradecimiento
Expreso mi agradecimiento a mi casa de

estudios la universidad “San Martin de
Porres” y a mis tutores, por darme las
herramientas para ser el profesional que soy
ahora
A mi familia y a todas las personas que

dieron su respaldo para poder seguir
alcanzando nuevas de metas.
Luis Alonso Cerva Cabrera
iii
Agradecimiento
Expreso mi agradecimiento a los tutores

Castillo Síni y Pedro Chávez, asesores del
curso y todas las personas que me brindaron
su apoyo y que pueda culminar esta tesis.
A mi familia por todo el esfuerzo que hicieron

para que pueda llegar a cumplir mis metas.
Dennis Wilmer Castillo Mamani
iv
ÍNDICE
Página
RESUMEN ..................................................................................................... ix
ABSTRACT ....................................................................................................x
INTRODUCCIÓN ........................................................................................... xi
CAPÍTULO I: MARCO TEÓRICO................................................................. 20
1.1. Antecedentes del proyecto ................................................................. 20
1.2. Bases teóricas .................................................................................... 28
1.3. Definición de términos básicos ........................................................... 53
CAPÍTULO II: METODOLOGÍA ................................................................... 60
2.1. Material............................................................................................... 60
2.2. Métodos.............................................................................................. 63
2.3. Plan de trabajo ................................................................................... 76
CAPÍTULO III: DESARROLLO DE LA SOLUCIÓN ..................................... 77
3.1. Requerimientos del sistema ............................................................... 77
3.3. Derivación de STQR a FEAT ............................................................. 81
3.4. Análisis de Procesos .......................................................................... 82
3.5. SPRINT 0 ........................................................................................... 82
3.6. SPRINTS ............................................................................................ 94
3.7. Desarrollo del business intelligence ................................................. 104
3.8. Desarrollo del cloud computing ........................................................ 119
CAPÍTULO IV: PRUEBAS Y RESULTADOS............................................. 123
4.1. Pruebas de performance .................................................................. 123
4.2. Pruebas de conformidad .................................................................. 138
4.3. Gráficos de reportes e indicadores ................................................... 145
CAPÍTULO V: DISCUSIÓN Y APLICACIÓN.............................................. 152
5.1. Discusión .......................................................................................... 152
5.2. Aplicación ......................................................................................... 153
CONCLUSIONES ....................................................................................... 154
RECOMENDACIONES ............................................................................... 155
FUENTES DE INFORMACIÓN................................................................... 156
ANEXOS ..................................................................................................... 159
v
Lista de tablas
Página
Tabla N° 1: Cuadro comparativo de las soluciones existentes .................... 27
Tabla N° 2: Cuadro comparativo de gestores de base de datos .................. 39
Tabla N° 3: Cuadro comparativo de lenguajes de programación ................. 50
Tabla N° 4: Cuadro comparativo de patrones de diseño ............................. 52
Tabla N° 5: Requerimiento de software el proyecto ..................................... 60
Tabla N° 6: Requerimientos de hardware del proyecto ................................ 61
Tabla N° 7: Roles y funciones de los ejecutores del proyecto ..................... 61
Tabla N° 8: Costos totales del proyecto ....................................................... 62
Tabla N° 9: Periodo de recuperación ........................................................... 62
Tabla 10: Tabla de ponderaciones............................................................... 63
Tabla 11: Análisis cuantitativo de metodologías ágiles ................................ 64
Tabla 12: Análisis cualitativo de metodologías ágiles .................................. 65
Tabla 13: Modelo de ficha de procesos ....................................................... 72
Tabla 14: Plan de trabajo ............................................................................. 76
Tabla 15: Product backlog ........................................................................... 82
Tabla 16: Lista de actores del sistema......................................................... 86
Tabla 17: Relación de historias de usuario .................................................. 94
Tabla 18: Priorización de historias de usuario ............................................. 95
Tabla 19: Atributos de la dimensión tiempo por niveles ............................. 106
Tabla 20: Descripción de los atributos de la dimensión tiempo ................. 106
Tabla 21: Atributos de la dimensión cliente por niveles ............................. 107
Tabla 22: Descripción de los atributos de la dimensión tiempo ................. 107
Tabla 23: Atributos de la dimensión abogado por niveles .......................... 108
Tabla 24: Descripción de los atributos de la dimensión abogado .............. 108
Tabla 25: Atributos de la dimensión objeto por niveles .............................. 109
Tabla 26: Descripción de los atributos de la dimensión objeto .................. 109
Tabla 27: Atributos de la dimensión etapa por niveles ............................... 110
Tabla 28: Descripción de los atributos de la dimensión etapa ................... 110
Tabla 29: Atributos de la dimensión dependencia por niveles ................... 111
Tabla 30: Descripción de los atributos de la dimensión dependencia ........ 111
vi
Tabla 31: Descripción de la granularidad................................................... 112
Tabla 32: Descripción de los atributos ....................................................... 112
Tabla 33: Relación de vistas y reportes ..................................................... 119
Tabla 34: Análisis comparativo de servidores en cloud ............................. 120
Tabla 35: Administrar usuarios .................................................................. 124
Tabla 36: Condiciones de entrada del caso PR01 ..................................... 124
Tabla 39: Administrar clientes .................................................................... 127
Tabla 42: Administrar abogados ................................................................ 129
Tabla 46: Administrar procesos ................................................................. 131
Tabla 48: Condiciones de entrada del caso PR010 ................................... 132
Tabla 50: Administrar entradas judiciales .................................................. 133
Tabla 56: Trazabilidad de casos de uso y casos de prueba ...................... 137
Tabla 57: Parámetros de evaluación ......................................................... 138
Tabla 58: Modelo de encuesta al administrador de la firma de abogados . 139
Tabla 59: Resultados de la pregunta 1 ...................................................... 140
Tabla 64: Matriz de trazabilidad entre reportes y objetivos ........................ 150
vii
Lista de figuras
Página
Figura 1: Logotipo sistema SEINSIR ........................................................... 22
Figura 2: Logotipo sistema CONEXIONES .................................................. 23
Figura 3: Logotipo sistema IURIX ................................................................ 24
Figura 4: Logotipo sistema ABOGADOS MF ............................................... 24
Figura 5: Interfaz de sistema CEJ ................................................................ 25
Figura 6: Esquema de los servicios almacenados en cloud computing ....... 36
Figura 7: Beneficios de Amazon Web Services ........................................... 37
Figura 8: Relación de los componentes de business intelligence ................ 41
Figura 9: Esquema estrella .......................................................................... 43
Figura 10: Esquema copo de nieve ............................................................. 43
Figura 11: Constelación de hechos.............................................................. 44
Figura 12: Arquitectura de un data warehouse ............................................ 46
Figura 13: Fases de la metodología de Ralph Kimball ................................. 47
Figura 14: Logotipo JasperReports Server .................................................. 48
Figura 15: Proceso SCRUM ........................................................................ 67
Figura 16: Ciclo dimensional del negocio .................................................... 68
Figura 17: Ciclo de vida de BPM.................................................................. 71
Figura 18: Modelo de negocio tipo lienzo o canvas ..................................... 75
Figura 19: Actores del sistema..................................................................... 87
Figura 20: Módulos del sistema: Diagrama de paquetes ............................. 88
Figura 21: Casos de uso del sistema ........................................................... 89
Figura 22: Modelo de base de datos............................................................ 90
Figura 23: Capas de la arquitectura de cliente-servidor............................... 92
Figura 24: Capas de la arquitectura del sistema .......................................... 93
Figura 25: Capas de la arquitectura de cliente-servidor............................... 93
Figura 26. Modelo eestrella de la data mart ............................................... 113
Figura 27: JOB de carga de la dimensión tiempo ...................................... 114
Figura 28: JOB de carga de la dimensión abogado ................................... 115
Figura 29: JOB de carga de la dimensión cliente....................................... 115
Figura 30: JOB de carga de la dimensión dependencia ............................ 115
viii
Figura 31: JOB de carga de la dimensión objeto ....................................... 116
Figura 32: JOB de carga de la dimensión etapa ........................................ 116
Figura 33: Proceso ETL ............................................................................. 117
Figura 34: Arquitectura de inteligencia de negocios del sistema ............... 118
Figura 35: Despliegue del sistema en el servidor Amazon EC2 ................ 121
Figura 36: Despliegue de la base de datos en el servidor Amazon EC2 ... 122
Figura 37. Grafica de resultados de la pregunta 1 ..................................... 141
Figura 38: Grafica de resultados de la pregunta 2 ..................................... 142
Figura 42: Cantidad de casos por periodo de ejecución ............................ 146
Figura 43: Reporte de delito por materia en ejecución .............................. 147
Figura 44: Reporte de delitos por materia .................................................. 148
Figura 45: Reporte de delitos por materia .................................................. 149
ix
Lista de anexos
Página
ANEXO 1 Cronograma del proyecto 160
ANEXO 2 Acta de constitución del proyecto 164
ANEXO 3 Análisis económico 169
ANEXO 4 Modelo de negocio 179
ANEXO 5 Derivación de sqrt a feat 183
ANEXO 6 Sprint backlog 195
ANEXO 7 Cálculo de la muestra 199
ANEXO 8 Arquitectura de la informacion 204
ANEXO 9 Manual de usuario 218
x
RESUMEN
La presente tesis titulada “sistema de control y seguimiento de procesos

judiciales para estudios de abogados utilizando inteligencia de negocios en
cloud computing” tiene como objetivo el desarrollo e implementación de una
solución de sistemas la cual contribuya en la mejora de la gestión, control y
seguimiento de los procesos judiciales en los estudios de abogados,
teniendo como finalidad lograr un mejor desempeño de los procesos claves
del negocio, potenciar el aprovechamiento de los recursos y brindar un
servicio adecuado a los clientes, así como generar reportes y cuadros
estadísticos que puedan apoyar en la toma de decisiones del estudio de
abogados.
Para la ejecución del proyecto, se evaluó el proceso de gestión de los

procesos judiciales, asimismo se aplicaron la metodología de Ralph Kimball
en el desarrollo de la inteligencia de negocios y la metodología Scrum en el
desarrollo de la solución, realizando el despliegue del piloto del sistema en
un estudio de abogados para su ejecución.
Se obtuvo como resultado la reducción de tiempo en la ejecución de tareas

del proceso de gestión de los procesos judiciales mediante la
sistematización e integración de actividades y procedimientos en el sistema,
así como la reducción del tiempo requerido en el seguimiento de los
procesos judiciales dando con un modelo para la gestión los mismos en los
estudios de abogados. Del mismo modo se pudo generar reportes y
estadísticas de los procesos judiciales que apoyen en la toma de decisiones.
Se concluye que la implementación de un sistema para la gestión de los

procesos judiciales aportó un beneficio tangible a la empresa, logrando
integrar las tecnologías de cloud computing e inteligencia de negocios en su
consecución.
Palabras clave: mejora de procesos, sistemas de información, procesos

judiciales, estudio de abogados, inteligencia de negocios, cloud computing.
ix
ABSTRACT
The present thesis entitled "system for control and monitoring of judicial
processes for law firms, using business intelligence on cloud computing"
aims at the development and implementation of a systems solution which
contributes to improving the management, control and monitoring of judicial
processes in law firms, having as its ending archieve a better performances
of key business processes, improve the using of resources and provide an
adequate service to clients, as well as generate reports and statistics that
could support on the decision making of the law firm.
For execution of the proyect, the process of management of the judicial

processes was evaluated, as well as were applied the Ralph Kimball
methodology in the developement of the business intelligence and the Scrum
methodology in the development of the solution, accomplishing the
deployment of the system's pilot in the law firm for its execution.
As a result, the reduction of time in the execution of tasks of the process of

management of judicial process is archieved by systematizing and integrating
activities and procedures in the system, as well as the reduction of time
required to monitoring the judicial processes giving a model for the
management of judicial processes in law firms. Likewise, it was also possible
to generate reports and statistics of judicial processes in order to contribuite
to the decision-making process.
It is concluded that the implementation of a system for the management of

judicial processes brought a tangible benefit to the company, managing to
integrate cloud computing technologies and business intelligence in its
achievement.
Keywords: process improvement, information systems, judicial processes,

law firm, business intelligence, cloud computing.
x
INTRODUCCIÓN
Desde finales de la década de los años noventa, la administración de la

justicia en el Perú ha venido experimentado un proceso de mejora impulsado
por el gobierno, el cual tiene como objetivo elevar la calidad y modernización
de los servicios de justicia que brindan los actores que componen el sector,
dando como resultado al desarrollo e implementación de soluciones de
sistemas. No obstante, la mayoría de las soluciones desarrolladas han sido
destinadas a las instituciones que componen el sector, tales como los
juzgados, las cortes superiores, entre otros; dejando de lado a otros actores
que también participan del proceso como son los estudios de abogados.
Ante esta situación, muchos de los estudios de abogados optan por adquirir
soluciones de medios privados, sin embargo, los elevados costos de estas
limitan el número de estudios que pueden acceder a ellas. De igual manera,
las soluciones restantes no se adecúan fácilmente a la realidad nacional,
debido a que en su mayoría se encuentran basadas en el código legal del
país de origen, lo que ocasiona que muchos de los estudios de abogados,
particularmente los pequeños, carezcan de una herramienta que pueda
apoyar en la ejecución de sus principales procesos de negocios,
específicamente una solución de sistemas.
La presente tesis, aborda el desarrollo de una solución de sistemas

orientada a los pequeños estudios de abogados que posea un desarrollo de
inteligencia de negocios en cloud computing, la cual permita mejorar el
desempeño de la gestión, control y seguimiento de los procesos judiciales
que el estudio atiende, sistematizando los procesos claves del negocio y
contribuyendo al mejor aprovechamiento de los recursos. Asimismo, permita
generar reportes y cuadros estadísticos que apoyen en la toma de
decisiones del estudio de abogados, mejorando la calidad del servicio
ofrecido y sirviendo como herramienta de apoyo para la gestión de los
procesos judiciales.
xi
La presente tesis consta de cinco capítulos que están estructurados de la
siguiente manera:
El primer capítulo titulado marco teórico, se dan a conocer las soluciones

existentes, así como el análisis de los antecedentes desarrollados. De igual
manera se presentan las bases teóricas que componen el marco de
referencial de herramientas y tecnologías involucradas en el desarrollo de la
solución propuesta.
En el segundo, se presenta la metodología y se dan a conocer el análisis del

presupuesto de los materiales involucrados y el marco metodológico
utilizado para el desarrollo e implementación de la solución propuesta, así
como el desarrollo del plan de trabajo para el desarrollo del proyecto.
En el tercer capítulo titulado desarrollo del proyecto, se da a conocer el

desarrollo integral de la solución, así como el desarrollo los artefactos y
componentes definidos en el plan de trabajo.
En el cuarto capítulo titulado pruebas y resultados, se dan a conocer la

batería de pruebas realizadas durante la evaluación y despliegue de la
solución, así como los parámetros de conformidad, los casos planteados, los
resultados esperados y los resultados obtenidos.
Finalmente, en el quinto capítulo titulado discusión y aplicación, se

interpretan los resultados obtenidos durante la marcha blanca y el
despliegue del sistema en los estudios de abogados que hicieron uso de la
solución. De igual manera, se detalla futuras mejoras del producto ofrecido y
discute potenciales aplicaciones a este.
Al final de la tesis, se encuentran las conclusiones y recomendaciones

rescatadas al realizar el proyecto, así como las fuentes de investigación y
consulta.
xii
1. Planteamiento del problema
1.1. Situación problemática

En el Perú, la administración de justicia se ha convertido desde ya hace
varias décadas en una constante preocupación para los ciudadanos. Como
indica un estudio del Latinbarómetro en el 2002 (Pásara, 2004), en lo que
respecta a América Latina, el nivel de confianza de los peruanos hacia sus
instituciones de justicia y el Poder Judicial, sitúa al Perú en el puesto 14 de
17 países encuestados. Asimismo, en una encuesta publicada en el mismo
artículo sobre la labor que desempeñan los abogados en el Perú (Pásara,
2004), un 40% de los encuestados responde como desfavorable la labor
ejercida por estos, en contraposición a un número similar de personas que
consideran favorable mientras que el resto no supo responder.
De la misma forma, según un informe publicado por LaLey (2014), en el Perú

existen más de 130 mil abogados colegiados, lo que hace que haya una
proporción de un abogado por cada 234 habitantes, en comparación con
otras profesiones donde la relación es menor. De estos, más del 50% se
encuentra en Lima y Callao. De este informe, también se concluye que el
62% ejercen en el sector público y que solo 8% considera que la
administración de justicia funciona correctamente, en contraste con el 50%,
29% y 13% de la población que consideran que funciona regular, mal y muy
mal respectivamente.
En ese sentido, siendo el Perú un país atestado de abogados, se da la

paradoja de la existencia de un desempeño ineficiente y una percepción
negativa generalizada sobre los servicios de administración de justicia, así
como el cumplimiento de la ley. Diversos estudios (Gutierrez, 2015; LaLey,
2014; Pásara, 2012), concluyen que los principales problemas que afrontan
las instituciones de justicia son la sobrecarga procesal existente, el retardo
de la administración de justicia, la excesiva oferta de abogados existentes en
el mercado de servicios judiciales, la existencia de procedimientos legales
inadecuados y obsoletos, así como la carencia de medios tecnológicos que
apoyen en la administración del despacho judicial.
xiii
Frente a estas situaciones, se han ido implementando soluciones
principalmente en el marco de la administración con la implementación de la
Ley Orgánica del Poder Judicial (1993) y posteriormente con la Ley de
Modernización del Estado (2002), habiendo obtenido algunos resultados,
como lo es por ejemplo el servicio de Consultas de Expedientes Jurídicos
(CEJ) que proporciona el portal del Poder Judicial.
Pese a ello la situación actual sigue siendo deficiente en varios aspectos, ya
que aún queda una brecha por cubrir tanto a nivel administrativo, como
social y tecnológico; particularmente a nivel de soluciones de sistemas
siendo que muchas de estas apuntan principalmente a las instituciones
internas del sector como lo son los juzgados.
De igual forma, la actual sobre oferta de abogados existentes en el mercado

genera que muchos de los profesionales no se encuentren correctamente
capacitados. Al ser el Perú un mercado de servicios judiciales muy dispar,
hay pocos estudios de abogados destacados que poseen carteras ya
definidas o con una confianza relativamente establecida, mientras que en
contraposición, un gran porcentaje de los abogados son abogados
independientes o asociaciones pequeñas los cuales muchas veces atienden
a sectores de bajas posibilidades económicas, tomando a su cargo un
número excesivo de casos para cubrir sus cuotas requeridas, terminando,
como Pásara (2004) explica, en no tener un conocimiento acumulativo de los
procesos atendidos, descuidándolos, ya que a diferencia de los grandes
estudios de abogados, estos muchas veces no poseen las herramientas y
soluciones adecuadas por desconocimiento o por costos elevados de las
mismas. De igual manera, debido a la naturaleza de la realidad jurídica
peruana, de realizarse correctamente el seguimiento de casos, supondría
que los abogados de los pequeños estudios destinen un gran número de
horas hombres y recursos que no poseen.
Esta situación, sumada al constante ingreso de estudios de abogados

extranjeros que buscan posicionarse en el mercado nacional (SEMANA
xiv
Económica, 2014; El Comercio, 2014), dificulta en gran medida la situación
de los abogados independientes y pequeños asociados.
1.2. Definición del problema

Se puede observar que muchos de los estudios de abogados,
particularmente los pequeños presentan un deficiente control y seguimiento
de los procesos judiciales que atienden.
Los pequeños estudios de abogados carecen de sistemas de información

que los apoyen en la gestión de los procesos judiciales que atienden, debido
al elevado costo de estas lo que ocasiona que pocos estudios posean los
recursos económicos para solventarlos. De igual manera, las soluciones
restantes no se adecúan fácilmente, ya que en su mayoría se encuentran
basadas en el código legal del país de origen. Finalmente, hay un número
significativo de estudios que desconoce de soluciones afines. Por lo tanto, el
control y seguimiento de los procesos judiciales en muchos de los pequeños
estudios de abogados es realizado de forma manual. Asimismo, a diferencia
de los grandes estudios, estos carecen de una cartera fija de clientes,
haciendo que reúnan un número elevado de casos para cubrir sus cuotas.
Para realizar el correcto control y seguimiento de un proceso judicial, es

necesario dedicar un número determinado de horas hombre y recursos, los
cuales, al realizar el procedimiento de forma manual, se elevan. De igual
manera, al llevar múltiples casos en forma simultánea, dificulta en gran
medida cubrir la demanda de horas hombre y recursos involucrados para
llevar a cabo un adecuado control y seguimiento de los procesos judiciales,
lo que ocasiona un deficiente manejo en la gestión de los procesos y causa
informalidad. Esto sumado a la carencia de reportes y estadísticas sobre los
que apoyarse, dificulta en gran medida toma de decisiones del negocio.
1.3. Problema general

Ineficiencia de los procesos de control y seguimiento de procesos judiciales
en los pequeños estudios de abogados.
xv
1.4. Problemas específicos
a. Carencia de soluciones de sistemas que apoyen en la gestión los
procesos judiciales.
b. Dificultad para cubrir la demanda de horas hombres y recursos
involucrados para llevar el control y seguimiento de los procesos
judiciales.
c. Existencia de altos niveles de informalidad en el seguimiento de los
procesos judiciales debido a la excesiva cantidad de casos atendidos
afectando negativamente a los clientes.
d. Desarrollo de procesos y procedimientos manuales.
e. Carencia de reportes y estadísticas que apoyen a la toma de
decisiones del estudio de abogados.
2. Objetivos
2.1. Objetivo general

Mejorar la eficiencia de los procesos de control y seguimiento de procesos
judiciales para un estudio de abogados utilizando un sistema que incluya
inteligencia de negocios en cloud computing.
2.2. Objetivos específicos

a. Mejorar en un 35% los tiempos de ejecución de las tareas del proceso
de gestión de procesos judiciales.
b. Aumentar en un 30% el aprovechamiento de los recursos en las
acciones de seguimiento de procesos judiciales del estudio de
abogados.
c. Mejorar en un 10% la calidad del servicio ofrecido a los clientes del
estudio de abogados.
d. sistematizar e integrar los procesos de registro, control y seguimiento
de los procesos judiciales del estudio de abogados.
e. Generar reportes y estadísticas que apoyen a la toma de decisiones del
xvi
3. Justificación
3.1. Justificación técnica

El desarrollo y despliegue de una solución de sistemas, implica la
sistematización de actividades manuales en los procesos de control y
seguimiento, lo cual proporcionaría una mejora de procesos reduciendo el
margen de tiempo empleado en el mismo, de igual forma el uso de métodos
como la digitalización de los expedientes durante las etapas procesales y el
desarrollo de interfaces con aplicaciones como el CEJ (Consulta de
Expediente Judicial) del Poder Judicial significa una apuesta por la reducción
en la acumulación de documentación física y el uso de expediente digital.
De igual manera la incorporación de tecnologías como cloud computing e

inteligencia de negocios, significan un aumento en el valor agregado del
servicio prestado por el estudio y la formalización de los procesos de
negocio.
3.2. Justificación económica

La incorporación de tecnologías y métodos como cloud computing y
digitalización, permiten que la solución sea asequible para los estudios de
abogados interesados en contar con una solución de sistemas que
contribuya a la mejora en la prestación de servicios de justicia y mejora de
sus procesos de negocios.
Asimismo, el desarrollo de una solución orientada al grueso que representan

los pequeños estudios de abogados, busca brindar valor a las empresas y a
la vez ser un sistema que resulte rentable frente a otras soluciones
existentes en el mercado.
3.3. Justificación social

El desarrollo de una solución de sistemas orientada a los pequeños estudios
de abogados, busca atacar al problema de la informalidad y la brecha
tecnológica proporcionando una herramienta que sea útil y ayude en la
mejora de la prestación de los servicios de justicia.
xvii
Asimismo, mediante el uso de tecnologías y técnicas de desarrollo como
realizar un despliegue en la nube, genera una reducción en los costos de
producción, despliegue y mantenimiento, con lo cual se busca proporcionar
con una plataforma accesible para la mayoría de estudios pequeños, los
cuales no poseen una gran cantidad de recursos como para apostar por
otros sistemas existentes en el mercado, debido principalmente a los altos
costos de estas.
Finalmente, el desarrollo de una solución con estas características

representaría un impacto positivo en el marco general de la prestación de los
servicios de justicia, ya que la solución podrá permitir el desarrollo de
interfaces con otras aplicaciones existentes en el sector como el CEJ
(Consulta de Expedientes Judiciales), lo cual brindará una mayor conexión
entre las instancias que componen el sector justicia.
4. Alcance
La presente tesis se centra en el desarrollo de un sistema que apoye al
control y seguimiento de los procesos judiciales en los pequeños estudios de
abogados. Asimismo, presentará un desarrollado de inteligencia de negocio
que permita obtener reportes y estadísticas, siendo desplegado en un
servidor en la nube.
El sistema contará con cinco módulos, los cuales agrupan las principales
funcionalidades del sistema, contemplando todo el proceso de la gestión de
los procesos judiciales que incluye desde el registro del proceso judicial en el
sistema y posterior asignación del proceso judicial a un abogado para su
seguimiento, hasta la finalización del proceso y obtención de los resultados
del mismo.
En su piloto el sistema contemplará solo las dependencias judiciales en el

distrito judicial de Lima, que comprende la zona metropolita de la ciudad
Lima, asimismo el sistema contará con soporte para el registro y monitoreo
xviii
de los procesos en las principales materias judiciales: civil, penal, laboral y
familiar.
Finalmente, el sistema incorporará conexiones con las principales

aplicaciones judiciales como lo son el CEJ para consulta de expedientes
electrónicos y el SINOE para notificaciones en casillas electrónicas.
5. Limitaciones.
Para el desarrollo del proyecto se toma en cuenta las siguientes limitaciones:
a. El desarrollo de la solución tendrá como resultado un sistema de
gestión de con características generales, el cual pueda ser desplegado
en diversos estudios de abogados realizando ajustes de configuración
menores.
b. La información y documentación relacionada al expediente judicial será
consultada mediante interfaces con el servicio CEJ del portal del Poder
Judicial, debido a la naturaleza privada de los expedientes y su cautela
física en los juzgados.
c. La información y documentación relacionadas a los procesos judiciales
será provista de los archivos físicos de los estudios de abogados para
su digitalización, siendo estos subidos a un repositorio privado por
estudio, debido a la naturaleza jurídica de la documentación.
d. La información legal digitalizada será de acceso a los abogados del
estudio que administren el proceso judicial. Asimismo, el usuario podrá
observar un reporte de estado del proceso que muestre características
relevantes del proceso.
e. Para una mayor transparencia, el manejo del expediente del proceso
será realizado de manera personal entre el abogado y su cliente.
xix
CAPÍTULO I:
MARCO TEÓRICO
1.1. Antecedentes del proyecto
1.1.1. Otros estudios sobre el tema
a. Antecedente 1
Bayona y Sánchez (2008) en su tesis titulada “sistema automatizado para el
seguimiento para el seguimiento de procesos judiciales en un estudio de
abogados”, sustentan que uno de los principales problemas que afrontan los
estudios de abogados son la pérdida de tiempo y recursos en gestionar y
evaluar las solicitudes y los expedientes de los casos son atendidos por la
junta de abogados, así como otros problemas derivados de este.
Del análisis realizado, se pudo identificar que el desarrollo de una solución

de sistema que reúna los principales procesos de negocio de un estudio de
abogados, produciría una mejora reduciendo de tiempo y recursos
requeridos para realizar las actividades del negocio, así como el desarrollo
funcionalidades que contribuyan a facilitar la labor de los abogados.
Para abordar esta problemática se tomó como objeto de estudio al estudio

de abogados “Morales Godo y Asociados” teniendo como objetivo la
automatización de los procesos de gestión y seguimiento de un proceso
judicial.
De la ejecución del proyecto se concluye que el desarrollo de un sistema que

englobe los principales procesos de negocio del estudio de abogados
“Morales Godo y Asociados”, produjo mejoras en la calidad del servicio
prestado por los abogados, asimismo se pudo generar un ahorro en tiempo y
recursos invertidos para la ejecución de las actividades del negocio.
20
b. Antecedente 2
Fisfalen (2014) en su tesis titulada “análisis económico de la carga procesal
del Poder Judicial”, sustenta el impacto económico que representa en los
agentes del sector justicia el exceso de carga procesal, así como las
consecuencias que genera en el desarrollo del proceso judicial.
Del análisis realizado, se pudieron identificar las diversas causas tanto a

nivel del marco de la administración de justicia, como a nivel tecnológico y
cultural; las cuales afectan de forma negativa al adecuado manejo del
proceso judicial.
Para abordar esta problemática surgen hipótesis que buscan aminorar la

carga procesal mediante el uso de TICS o tecnologías de información, con la
finalidad de mejorar la eficiencia de la gestión de los expedientes procesales
en el proceso judicial, así como aminorar el impacto económico que
representa su uso.
Del contraste de la hipótesis se concluye que la implantación de TICS para

la gestión del proceso judicial supondría un impacto positivo en el tiempo de
ejecución de la carga procesal, así como supondría una reducción en los
costos involucrados a los diversos agentes que forman parte del proceso
judicial.
1.1.2. Soluciones existentes

En los diversos países de Latinoamérica, en particular los países de América
del Sur, se han desarrollado soluciones orientadas a la gestión de los
procesos judiciales, las cuales, si bien comparten similitudes entre sí, toman
en cuenta la realidad jurídica del país de origen.
1.1.2.1. INDRA
INDRA es una compañía española que provee servicios de TI y consultoría,
desarrollando una oferta integral de soluciones propias y servicios
avanzados con un alto valor añadido en tecnología. Entre las soluciones
destinadas al mejoramiento de la administración judicial que INDRA ha
21
desarrollado, se encuentra el sistema SEINSIR el cual aporta una mayor
agilidad y transparencia a los procesos de administración de justicia, siendo
desplegado en Ecuador con el objetivo de la modernización de su sistema
judicial.
Sistema SEINSIR
Es una plataforma tecnológica que facilita el registro, control y seguimiento
de los asuntos judiciales que se resuelvan en un órgano judicial de cualquier
tipo, contemplando desde la entrada de escritos hasta la ejecución de
sentencias. SEINSIR se utiliza en el Consejo de la Judicatura de Transición
de Ecuador, además posee un desarrollo de business intelligence que
proporciona información necesaria para tratar aspectos de planificación y
gestión y obtener así una visión completa y un diagnóstico exacto de la
realidad judicial.
Figura 1: Logotipo sistema SEINSIR

Fuente: http://www.indracompany.com/es/justicia
1.1.2.2. CONEXIONES
Conexiones.com es una empresa argentina que ha desarrollado un sistema
de información judicial el cual permite a sus clientes acceso a una réplica
exacta de todas las novedades de sus expedientes judiciales en línea y en
formato digital, el cual ha contribuido en mejorar los procesos de gestión de
los colegios de abogados en algunas provincias de Argentina.
Sistema CONEXIONES JUDICIALES

Es un sistema desarrollado en el año 2004 con el objetivo de ser el primer
sistema de Argentina que permita a cualquier interesado acceder a una
copia fiel de los movimientos de cualquier expediente judicial.
22
CONEXIONES JUDICIALES cuenta con dos tipos de servicios:
a. Conexiones judiciales seguimiento

Permite realizar el monitoreo continuo de todas las novedades detectadas en
su expediente judicial, desde la fecha de contratación en adelante.
b. Conexiones judiciales réplica

Permite obtener una copia exacta de todo el contenido de su expediente,
desde el inicio de la demanda hasta la fecha de contratación.
Figura 2: Logotipo sistema CONEXIONES

Fuente: http://latam.conexiones.com
1.1.2.3. DDS UNITECH

DDS Unitech es una empresa argentina especializada en la innovación,
diseño y desarrollo de soluciones informáticas de gran envergadura, la cual
ha desarrollado el sistema IURIX, una solución integrada orientada a los
organismos del sistema judicial argentino, el cual sistematiza y agiliza los
diversos procesos y trámites correspondientes a los servicios de justicia.
Sistema IURIX
Es una solución integral para la gestión judicial orientada a la construcción
del expediente electrónico. Permite que el personal de los organismos que
componen el Poder Judicial y los Ministerios Públicos, desempeñen con
mayor eficacia y eficiencia las funciones administrativas y jurisdiccionales a
su cargo. IURIX permite construir expedientes electrónicos y acceder a ellos
a través de redes privadas y públicas, desde cualquier navegador,
permitiendo realizar notificaciones vía correo, intercambios de actuaciones
entre organismos públicos y privados y recepción de escritos de los
abogados.
23
Figura 3: Logotipo sistema IURIX
Fuente: http://www.unitech.com.ar/productos/iurix
1.1.2.4. Abogados MF
Abogados MF, es una iniciativa española sin ánimo de lucro que nació con el
objetivo de prestar una ayuda a todos aquellos profesionales del derecho,
especialmente abogados y procuradores, que deseen gestionar de una
forma sencilla todos los aspectos que conlleva el funcionamiento normal de
un despacho mediante un software de uso gratuito, el cual cubra
prácticamente todas las necesidades que la gestión de un despacho
dedicado a la rama jurídica puede tener.
Sistema ABOGADOS MF
Es un sistema de gestión para despachos de abogados y procuradores
de uso gratuito y fácil instalación. Puede administrar múltiples despachos
independientes unos de otros en red local y posee una configuración sencilla
que permite una gran versatilidad al momento de adaptar el sistema a las
exigencias y funcionalidades de los clientes.
Figura 4: Logotipo sistema ABOGADOS MF

Fuente: http://abogados-mf.com
24
1.1.2.5. Consulta de Expedientes Judiciales (CEJ)
Aplicación ofrecida por el portal web del Poder Judicial del Perú para la
consulta de expedientes judiciales de las especialidades familiar, laboral y
civil de todas las Cortes Superiores de Justicia presentando la evolución
histórica y los documentos resultantes del desarrollo de los procesos
judiciales.
Figura 5: Interfaz de sistema CEJ

Fuente: http://cej.pj.gob.pe/cej/forms/busquedaform.html
1.1.2.6. Sistema de Control y Seguimiento de Procesos

Judiciales (SCSPJ)
El Sistema de Control y Seguimiento de los Procesos Judiciales es un
sistema orientado a estudios de abogados que busquen mejorar el
desempeño de sus procesos de negocio mediante el uso de una solución de
sistemas que cubra con las principales funciones de un despacho, así como
gestionar los casos que el estudio atienda, obteniendo cuadros e información
estadística que pueda ser usados para la toma de decisiones.
25
Es el sistema propuesto en el trabajo y tiene como principales
funcionalidades:
- Definir los principales procesos de negocios del despacho en un nivel
modular dentro del sistema.
- Seguimiento a detalle de la evolución del proceso judicial durante las
diversas etapas de su ejecución.
- Digitalización y anexo de los documentos resultantes en cada etapa del
proceso.
- Transferencia de responsabilidades entre los participantes del proceso.
- Conexión con las principales aplicaciones del órgano de justicia.
- Acceso al expediente judicial por parte de los responsables del caso en
todo momento.
- Regionalización al código jurídico peruano.
- Soporte de procesos judiciales en las principales materias jurídicas.
- Análisis de registros históricos sobre los procesos judiciales llevados en
el despacho.
- Generación de reportes y cuadros estadísticos que apoyen la toma de
decisiones gerenciales en el despacho.
- Entre otras funcionalidades.
26
La tabla 1 presenta el cuadro comparativo de las soluciones existentes
indicando el nivel de cumplimiento de las principales características.
Tabla N° 1: Cuadro comparativo de las soluciones existentes
CUADRO COMPARATIVO DE LAS SOLUCIONES EXISTENTES
CONEXIONES ABOGADOS
Características SEINSIR
JUDICIALES
IURIX
MF
CEJ SCSPJ
Software open source No No No Sí No No
Copia exacta del

No Sí Sí Sí No Parcial
expediente judicial
Elaboración de escritos
No No Sí Sí No Sí
por abogados
Monitoreo de Sí Sí Sí Sí Sí Parcial
expediente judicial
Seguimiento de la
evolución del proceso Parcial Parcial Parcial Parcial No Sí
judicial en el tiempo
Acceso al expediente en
cualquier momento y No Sí Sí No Sí Sí
desde cualquier lugar.
Adjuntar archivos e No No No No No Sí
imágenes
Envío y recepción de
datos entre órganos Sí No Sí No No No
jurisdiccionales
Grabación de voz.
Sí No No No No No
Transcripción a Textos
Elaboración de
Sí No Sí No No Sí
estadísticas judiciales
Manejo de agenda No No No Sí No Sí
Seguridad de datos
mediante accesos por No No Sí Sí Sí Sí
usuarios
Notificaciones sobre
actualizaciones en No Sí Sí No No Sí
expedientes
Interconexión con otras
aplicaciones del órgano No No No No No Sí
de justicia
Elaboración de reportes
de nivel intermedio y Sí Sí Sí Sí No Sí
gerencial
Regionalización acorde Sí
No No No No No
al código peruano
Fuente: Propia
27
1.2. Bases teóricas
1.2.1. Procesos judiciales

El proceso judicial es el conjunto dialéctico de actos, ejecutados con sujeción
a determinadas reglas más o menos rígidas, realizados durante el ejercicio
de la función jurisdiccional del Estado, por distintos sujetos que se relacionan
entre sí con intereses idénticos, diferentes o contradictorios, pero vinculados
intrínsecamente por fines privados y públicos. (Monroy, 1996).
El Estado a través del Poder Judicial ejerce la función jurisdiccional, la cual

le permite tutelar los derechos de las personas. Esta función es realizada por
los órganos jurisdiccionales del Poder Judicial mediante los procesos
judiciales, ya que el Estado necesita del proceso para juzgar debido a que
no puede hacerles de forma directa. Por ende, todo proceso judicial
cualquiera sea su denominación o especialidad, debe ser sustanciado bajo
los principios procesales de legalidad, inmediación, concentración, celeridad,
preclusión, igualdad de las partes, oralidad y economía procesal, dentro de
los límites de la normatividad que le sea aplicable. (Texto Único Ordenado
de la Ley Orgánica del Poder Judicial, 1993).
1.2.1.1. Naturaleza jurídica del proceso judicial

En la doctrina jurídica actual, como Sagastegui (1996) explica, se puede
encontrar cuatro teorías que muestran la esencia del proceso judicial:
a. El proceso como contrato consiste en que la relación establecida
entre el demandante y el demandado, es producto de un acuerdo de
voluntades entre ambos litigantes comprometiéndose a aceptar lo que
se resuelva al final.
b. El proceso como cuasicontrato consiste en que lo resuelto en un
proceso exige el cumplimiento de la parte desfavorecida considerando
al proceso como una fuente de obligaciones.
c. El proceso como relación jurídica define el proceso como una
relación jurídica porque para su actuación concurren cierto número de
sujetos que asumen conductas en función al rol e interés con que
28
participan en él y que estos roles y conductas están preestablecidos en
la ley.
d. El proceso como situación jurídica sostiene que cuando una
persona empieza un proceso se encuentra en un determinado estado
respecto de la sentencia a recibir y este estado está presente tanto en
el demandante como en el demandado como una situación jurídica.
1.2.1.2. Diferencia entre proceso y procedimiento

a. El proceso es un conjunto dialéctico, dinámico y temporal de actos,
que se realizan durante la ejecución de la función jurisdiccional del
Estado, bajo su dirección, regulación y con el propósito de obtener
fines privados y públicos, los que son comunes a todos los
participantes del proceso.
b. El procedimiento se refiere a un conjunto de normas y reglas de
conducta que regulan la actividad, participación, facultades y deberes
de los sujetos procesales, así como la forma de los actos realizados en
un proceso o en parte de este, provistos por el Estado con anticipación
a su inicio.
En suma, el proceso se caracteriza por su finalidad jurisdiccional compositiva

del litigio, mientras que el procedimiento se reduce a ser una coordinación
de actos en marcha, relacionados o ligados entre sí por la unidad del efecto
jurídico final, que puede ser el de un proceso o el de un procedimiento
incidental o impugnativo. (Devis, 1984)
1.2.1.3. Clasificación de procesos judiciales

Los procesos judiciales están clasificados por materias judiciales y por
instancias. Entre las principales materias judiciales se encuentran la civil,
penal, laboral, de familia y comercial.
1.2.1.4. Instancias del proceso judicial

Las instancias en el proceso judicial se refieren a las etapas por las que
pasa un proceso por cada uno de los órganos jurisdiccionales. Un proceso
puede presentar diversas variantes a lo largo de su desarrollo, pero en
29
general su esencia se mantiene. Esto hace referencia al órgano
jurisdiccional en el cual se encuentra un proceso en un momento dado
dependiendo de su naturaleza.
Los órganos jurisdiccionales son:

a. Juzgados de paz no letrados y letrados: son el menor nivel
jerárquico en que se encuentra organizado el Poder Judicial.
b. Juzgados de primera instancia especializados o mixtos:
representan el segundo nivel jerárquico en que se encuentra
organizado el Poder Judicial del Perú.
c. Cortes Superiores: representan el tercer nivel jerárquico en que se
organiza el Poder Judicial. Solo se encuentran bajo la autoridad de la
Corte Suprema de la República y es, en la mayoría de procesos, el
último organismo que conoce un proceso.
d. Corte Suprema: máximo órgano jurisdiccional del Perú. Su
competencia se extiende a todo el territorio del país.
Mediante las instancias se puede realizar una impugnación a un fallo y es la

Corte Suprema la última instancia ante la cual se pueden apelar todos los
procesos judiciales. (Sagastegui, 1996).
1.2.1.5. Etapas del proceso judicial

El proceso judicial se divide en etapas según la materia judicial, así en un
proceso civil se tiene etapas: postulatoria, de saneamiento, conciliatoria,
probatoria y resolutiva dentro de las cuales se suceden una serie de actos
para obtener la declaración del derecho; de igual forma en un proceso penal
se distinguen claramente dos etapas: la instrucción, que se caracteriza por
ser un período de investigación en el cual se da la búsqueda, recolección y
selección del material probatorio; y una de juzgamiento en la que se
establece la responsabilidad del presunto autor y cuyo objeto es determinar
si alguien ha cometido un delito, su responsabilidad, la tipificación del delito y
la determinación de la pena; sirve pues para la realización del derecho
penal, diferenciándose del proceso civil por la significación pública de su
objeto: que es la reintegración del derecho violado. (García Rada, 1980).
30
1.2.1.6. Descripción de un proceso judicial
a. Interposición de la demanda
Es el acto procesal de parte que no solo da inicio al proceso, sino que
también a través de esta se pide la tutela jurisdiccional, materializando el
derecho de acción que a su vez contiene la cuantía, aquello que solicitan las
partes. En el acto de la demanda es el que da inicio a un proceso, está
revestida de ciertas formalidades y requisitos de forma que establece la ley,
y del cumplimiento de estos se procede a la admisión de la demanda, dando
como resultado a su admisión y expedición del auto admisorio; o caso
contrario, el rechazo o improcedencia.
Dentro de la demanda se consigna como requisitos de forma los siguientes

contenidos:
- La designación del juez ante quien se interpone.
- El nombre, datos de identidad, dirección domiciliaria y domicilio
procesal del demandante.
- Nombre y dirección domiciliaria del representante o apoderado del
demandante.
- El nombre y dirección domiciliaria del demandado.
- Señalamiento del petitorio, que comprende la determinación clara y
concreta de lo que se pide.
- Exposición de los hechos en que se funda el petitorio.
- Fundamentación jurídica del petitorio, es decir, calificación jurídica de
los hechos.
- Indicación de la vía procedimental.
- Los medios probatorios.
b. Emplazamiento del demandado

Es la puesta en conocimiento del demandado por parte del juez, de la
existencia de una demanda en su contra y del auto que la admitió, y le
concede un plazo para que la conteste. El emplazamiento se hace con
notificación por cédula, ejecutado por el secretario del juzgado y que se
entregará en su domicilio; la cédula de notificación es un documento en el
31
cual se debe hacer constar la fecha y la hora en que se entregue, proceso al
que corresponda, juzgado y secretario donde se tramita, etc., conforme a lo
regulado por el Código Procesal Civil (Poder Judicial, 1993).
c. Contestación de la demanda
Es la respuesta que da el demandado a la situación jurídica que ha creado el
demandante con la interposición de la demanda, con ella queda integrada la
relación procesal y fijados los hechos sobre los cuales debe versar los
hechos y recaer la sentencia, es decir, se fijan los puntos que son materia de
controversia y quedan obligados a continuar el proceso, ya que una vez
contestada la demanda, ni el demandante puede variarla.
Es en esta etapa donde el demandado tiene toda oportunidad para

defenderse. La contestación de la demanda, así como la demanda posee de
ciertas formalidades y requisitos esenciales que son los mismos exigidos
para la demanda.
El demandado puede adoptar dos posturas: una negativa que consiste en la

rebeldía al dejar de pronunciarse sobre la demanda, lo cual recae dentro de
una presunción de verdad por parte a los hechos del demandante, lo que
lleva a no entrar a la etapa probatoria e ir directo a la etapa resolutoria; y una
positiva en la que puede interponer excepciones, medios de defensa a
través de los cuales el demandado denuncia la existencia de una relación
inválida, ya sea porque omisión o defectuosidad de un requisito procesal; o
contestar la demanda, pudiendo optar por allanarse, admitiendo la demanda
y aceptar la pretensión y los hechos expuestos en ella; negar los hechos y el
derecho y/o reconvenir la demanda del demandado contra el demandante.
d. Saneamiento del proceso

Tiene por objeto limpiar el proceso de toda cuestión que impida su
conocimiento y la del juez sobre el fondo de la controversia. Para sanear el
proceso, como Taramona (1999) explica, el juez tiene que haber examinado
si se han cumplido los requisitos o elementos esenciales del debido proceso,
así como el cumplimiento de garantías provistas en la contestación. Solo al
32
estar convencido de que los actos procesales no adolecen de causal de
nulidad insubsanable, dicta el auto de saneamiento, declarando la existencia
de una relación jurídica válida.
e. Audiencia de conciliación
La conciliación es el acuerdo de las partes para poner fin a un asunto
litigioso. Una vez superada la etapa procesal del saneamiento se procede a
la conciliación que es un trámite obligatorio en el que el juez debe tener una
activa participación, proponiendo incluso la fórmula de arreglo que su
prudente arbitrio le aconseje.
El Código Procesal Civil (Poder Judicial, 1993) señala que las partes pueden
conciliar sus conflictos de intereses en cualquier estado del proceso, siempre
que no se haya expedido sentencia en segunda instancia; la conciliación es
pues una facultad de las partes; para ello el juez debe fijar día y hora para la
realización de la audiencia conciliatoria después de expedido el auto por el
cual se declara saneado el proceso. Durante el desarrollo de la audiencia el
juez escucha a cada una de las partes y propone la fórmula de conciliación,
si la fórmula de conciliación es aceptada por las partes el juez levanta un
acta anotando en forma detallada el acuerdo logrado en la vía de
conciliación y luego es aprobado con un auto; de no ser aceptada la
propuesta conciliatoria se levanta el acta mencionándose que no fue
aceptada, procediéndose luego a actuar los medios probatorios.
f. Presentación de medios probatorios

Son los instrumentos con los cuales se pretende lograr certeza del juzgado
sobre los hechos del objeto de prueba. Estos instrumentos pueden consistir
en objetos materiales, documentos, fotografía, o en conducta humana
realizada bajo ciertas condiciones, declaraciones de partes, declaraciones
de testigos, dictámenes periciales, inspecciones judiciales etc.
El principio general, como Rodríguez (1999) explica, es que las partes

prueben en el proceso los hechos que alegan en sus escritos, de no ser
probados los hechos que sustentan, la demanda se declara infundada.
33
Existen dos tipos de medios probatorios:
- Medios probatorios típicos: son medios probatorios regulados
detallados por el código procesal civil para su utilización, ofrecimiento,
actuación e integración al proceso para luego ser valorizados en
conjunto (Taramona, 1999). Ejemplos: declaraciones de las partes,
declaraciones de los testigos, documentos referidos a la demanda
como medios probatorios, dictámenes de los peritos y la inspección
judicial.
- Medios probatorios atípicos: son medios auxiliares técnicos o
científicos que hacen de finalidad de medios probatorios
g. Emisión de la sentencia
Es la resolución que emite el juzgado sobre el litigio sometido a su
conocimiento y mediante la cual normalmente pone término al proceso. La
terminación normal del proceso conduce al juzgador a pronunciar sentencia
sobre el litigio sometido a proceso, una vez que las partes han formulado sus
pretensiones y, en su caso sus negaciones y excepciones en la fase
expositiva, que han suministrado los medios que consideraron pertinente
para verificar en la fase probatoria los hechos sobre los cuales trataron de
fundar sus respectivas actitudes y que formularon sus conclusiones en la
fase de alegatos, corresponde ahora al juzgador expresar en la sentencia su
decisión sobre el conflicto (Alzamora, 1981), poniendo fin a la instancia o al
proceso en definitivo, consignando el veredicto en una resolución.
En caso de que las partes consideren afectados sus derechos con tal
resolución, como explica Rodríguez (1999), podrán presentar ante el juez
medios impugnatorios con los cuales contradecir las resoluciones judiciales,
a fin de ser modificada la resolución emitida o sea concedida ante el superior
jerárquico para su revisión.
h. Ejecución de la sentencia
Es el verdadero fondo del proceso: embargo, remate, adjudicación, entrega
del bien, etc. (Alzamora 1981).
34
1.2.2. Cloud computing
Según el National Institute of Standards and Technology (NIST), cloud
computing es un modelo tecnológico que permite el acceso continuo,
adaptado y bajo demanda en red a un conjunto compartido de recursos de
computación configurables compartidos, por ejemplo: redes, servidores,
equipos de almacenamiento, aplicaciones y servicios, que pueden ser
rápidamente aprovisionados y liberados con un esfuerzo de gestión reducido
o interacción mínima con el proveedor del servicio.
El despliegue en cloud computing permite lograr ahorros a los usuarios, los

cuales se deben a la alta eficiencia de los centros de datos, los altos niveles
de automatización y la elasticidad de los costos en base al uso, en
comparación con el modelo tradicional.
Cloud computing es el resultado de buscar la mayor eficiencia posible en la

asignación de los recursos informáticos. Cloud computing es para la
industria informática lo que la línea de producción supuso para la industria
del automóvil a principios del siglo XX. (Huibert, 2014).
Modelo de servicios de cloud computing

a. Infraestructura como Servicio (IAAS) es el modelo de servicio más
básico de cloud computing en el que los clientes pagan por el uso de
diversos servicios como capacidad de procesamiento, almacenamiento
o ancho de banda.
Ejemplos de proveedores incluyen a IBM (Softlayer), Amazon Web

Services, Rackspace, Google Docs.
b. Plataforma como Servicio (PAAS) modelo de servicio de cloud

computing que permite que los clientes desarrollen sus aplicaciones
sobre una plataforma elástica en la nube. Esto significa que la
aplicación se adapta automáticamente al nivel de usuarios que tiene en
un momento dado, garantizando un determinado nivel de servicio, la
35
cual normalmente incluye servicios como base de datos o mensajería
que simplifica en el desarrollo de aplicaciones para los programadores.
Ejemplos de empresas que usan PaaS son: Google App Engine,

Microsoft Azure, Google Apps, Heroku.
c. Software como Servicio (SAAS) en este modelo de cloud computing,

los clientes en lugar de comprar un software para instalarlo en un
servidor propio, pagan por el uso de una aplicación por número
determinado de usuarios.
Ejemplos de empresas que usan SaaS son: salesforce.com, Google

Docs, Oracle, Google Mail, Office 365. (Urueña, 2012).
Figura 6: Esquema de los servicios almacenados en cloud computing

Fuente: IngenieríaHosting.com
1.2.3. Amazon Web Services

Es una plataforma de servicios de cloud computing que ofrece potencia de
cómputo, almacenamiento de bases de datos, entrega de contenido, entre
otras funcionalidades para ayudar a las empresas a escalar y crecer, con lo
cual permita poder crear aplicaciones sofisticadas y cada vez más flexibles,
escalables y fiables.
36
El servicio de nube de AWS proporciona un amplio conjunto de servicios de
infraestructura, como potencia de cómputo, opciones de almacenamiento,
redes y bases de datos, ofertados como una utilidad: bajo demanda,
disponibles en cuestión de segundos y pagando solo por lo que utiliza.
Figura 7: Beneficios de Amazon Web Services

Fuente: https://aws.amazon.com/es/s3/?nc2=h_l3_sc
1.2.4. Base de datos

Las bases de datos son arreglos de datos que pertenecen a un mismo
contexto. Cada base de datos se compone de una o más tablas que guarda
un conjunto de datos y están relacionadas entre sí.
a. Características
- Permite el intercambio de datos.
- Permite la reducción de la redundancia.
- Disminuya la inconsistencia de datos.
- Provee facilidad al manejo de transacciones.
- Permite el respaldo de recuperación.
- Provee seguridad de acceso y auditoria.
- Realiza consultas optimizadas.
- Mantiene la integridad de datos.
Las bases de datos proporcionan la infraestructura requerida para los

sistemas de apoyo a la toma de decisiones y para los sistemas de
información estratégicos, ya que estos sistemas explotan la información
37
contenida en las bases de datos de la organización para apoyar el proceso
de toma de decisiones o para lograr ventajas competitivas.
b. Sistema gestor de bases de datos

Es el servicio principal para almacenar, procesar y proteger datos.
Proporciona, además, acceso controlado y procesamiento de transacciones
para cumplir con los requisitos de las aplicaciones.
c. Tareas del sistema gestor de base de datos

- Diseñar y crear una base de datos que contenga las tablas relacionales
- Implementar sistemas para obtener acceso y cambiar los datos
almacenados en la base de datos
- Aplicar los sistemas implementados en la organización o en los
clientes.
- Proporcionar soporte técnico para optimizar el rendimiento de la base
de datos.
d. Motores de bases de datos

Entre los motores de bases de datos más conocidos, se puede mencionar:
- Oracle Database: es una de las más potentes, robustas y escalables
herramientas a nivel mundial y de alta confiabilidades. Oracle Database
es una solución completa que incluye un motor de base de datos con
posibilidad de crear sistemas de tablas relacionadas, índices, así como
el lenguaje PL/SQL para el desarrollo de procedimientos almacenados
y triggers lo que permite un crecimiento escalable.
- Microsoft SQL Server: la alternativa de Microsoft para el mercado de
bases de datos, optimizado para ser utilizado en conjunto con
aplicaciones desarrolladas en la plataforma Microsoft .NET, SQL
Server es una buena alternativa un poco más accesible en términos
económicos que otros motores. Al igual que los otros motores de base
de datos, cuenta con un lenguaje T-SQL para el desarrollo de
procedimientos almacenados o triggers y es bastante estable.
38
- MYSQL: motor de base de datos de bajo costo, bastante maduro, el
cual cuenta desde hace mucho tiempo con características de las bases
de datos de pago como sistemas de tablas relacionales, varios tipos de
datos, desarrollo de procedimientos y triggers, etc. Tras su adquisición,
cuenta con el soporte de base de datos por parte de Oracle, lo que ha
potenciado a MySQL como un motor de uso más empresarial.
- PostgreSQL: gestor de bases de datos de tipo objeto relacional u
ORDBMS. Es software libre bajo licencia BSD, el cual utiliza el lenguaje
SQL92/SQL99 y posee una gran escalabilidad. Es considera como un
gran gestor de bases de datos, capaz de competir con muchos
gestores comerciales, aunque carece de un conjunto de herramientas
que permitan una fácil gestión de los usuarios y de las bases de datos
que administre. Por otro lado, la velocidad de respuesta resulta
favorable para bases de datos grandes y no pequeñas.
La tabla 2 presenta el cuadro comparativo de los gestores de base de datos,

indicando la evaluación de sus principales características.
Tabla N° 2: Cuadro comparativo de gestores de base de datos
GESTORES DE BASE DE DATOS
Oracle SQL
Características MySQL PostgreSQL
Database Server
Usabilidad Buena Muy buena Muy buena Muy buena
Robustez Muy buena Regular Muy buena Muy buena
Instalación y configuración Regular Fácil Muy buena Regular
Apariencia Buena Muy buena Regular Buena
Nivel de experiencia Básico Intermedio Avanzado Intermedio
Velocidad de respuesta Buena Muy buena Buena Buena
Control de acceso y
Difícil Fácil Buena Buena
autenticación de usuarios
Soporte de triggers y
Mejor Deficiente Mejor Mejor
procedimientos almacenados
Consumo de recursos Mucho Poco Mucho Mucho
Fuente: Varias
39
1.2.5. Business intelligence
El objetivo de business intelligence es apoyar de forma sostenible y continua
a las organizaciones para mejorar su competitividad, facilitando la
información necesaria para la toma de decisiones.
Los beneficios que se pueden obtener a través del uso de business

intelligence pueden ser de distintos tipos:
- Beneficios tangibles, por ejemplo: reducción de costes, generación de
ingresos, reducción de tiempos para las distintas actividades del
negocio.
- Beneficios intangibles: al tener disponible la información para la toma
de decisiones hace que más usuarios utilicen dicha información lo que
contribuye en mejorar la competitividad.
- Beneficios estratégicos: todos aquellos beneficios que facilitan la
formulación de la estrategia, es decir, a qué clientes, mercados o con
qué productos dirigirnos.
Como Lluís (2007) expone, mediante el uso de tecnologías y las

metodologías de business intelligence se puede convertir datos en
información y a partir de la información ser capaces de descubrir
conocimiento.
Componentes del business intelligence

Los distintos componentes de business intelligence son:
- Fuentes de información. Alimentan de información al data warehouse.
- ETL. Proceso de extracción, transformación y carga de los datos en la
data warehouse. Los datos de los sistemas transaccionales son
transformados, limpiados, filtrados y redefinidos antes de ser
almacenados.
- Data warehouse. Almacén de datos de forma que maximice la
flexibilidad, facilidad de acceso y administración de la información.
- Las herramientas de visualización. Herramientas de visualización,
análisis y navegación.
40
- OLAP o Procesamiento Analítico en Linea. Permite realizar cálculos,
consultas, funciones, pronóstico y análisis de escenarios en relación a
los grandes volúmenes de datos de la data warehouse.
La figura 8 muestra la relación de los componentes que conforman el

business intelligence.
Figura 8: Relación de los componentes de business intelligence

Fuente: CanalTech
1.2.6. Modelo de datos

Un modelo de datos es un sistema formal y abstracto que permite describir
los datos de acuerdo con reglas y convenios predefinidos. Es formal pues los
objetos del sistema se manipulan siguiendo reglas perfectamente definidas y
utilizando exclusivamente los operadores definidos en el sistema,
independientemente de lo que estos objetos y operadores puedan significar.
Existen dos tipos de modelos de datos: el modelo relacional y el modelo
multidimensional:
1.2.6.1. Modelo relacional

El modelo relacional es el pilar fundamental para el diseño de la mayoría de
las bases de datos que existen hoy en las grandes y pequeñas empresas. La
composición de estas bases de datos son decenas de tablas relacionadas
que almacenan conjuntos de datos o “tuplas” a través de una compleja tela
de araña de uniones, logrando con ellos una simplificación considerable de
las estructuras de datos con las cuales debe interactuar el usuario, lo cual a
su vez simplifica los operadores requeridos para manejar esas estructuras.
41
1.2.6.2. Modelo multidimensional
El modelo multidimensional es una técnica para modelar bases de datos
simples y entendibles para el usuario final, presentando la información en un
marco estándar e intuitivo que permitan un acceso de alto rendimiento,
teniendo como objetivos representar los datos en forma cercana a la
intuición del usuario y resolver problemas planteados en sistemas
relaciónales.
Componentes del modelo multidimensional

El modelo multidimensional está compuesto principalmente por dos
elementos: esquemas y tablas.
a. Tablas
Las tablas en el modelo multidimensional pueden ser de dos tipos:
- Tablas de hechos: Son los objetos a analizar, poseen atributos de tipo
cuantitativo llamados atributos de hechos o síntesis, cuyos valores son
obtenidos generalmente por aplicación de una función estadística que
resume un conjunto de valores en un único valor.
- Tablas dimensiones: representan cada uno de los ejes en un espacio

multidimensional. Como todas las tablas también poseen atributos
llamados de dimensión o de clasificación, estos son de tipo cualitativo
los cuales suministran el contexto en el que se obtienen las medidas en
un esquema de hecho. Las dimensiones poseen jerarquías, que son
varios atributos unidos mediante una relación de tipo jerárquico.
b. Esquemas
Un esquema multidimensional se puede representar como un esquema
estrella o star join, copo de nieve o snowflake, o constelación de hechos:
- Esquema estrella: es un conjunto de tablas compuestas por una tabla
de hechos con una única tabla para cada dimensión. El esquema
estrella deriva su nombre del hecho que su diagrama forma una
estrella, con puntos radiales desde el centro, el centro de la estrella
42
consiste de una o más tablas de hechos, y las puntas de la estrella son
las tablas de dimensión.
Figura 9: Esquema estrella

Fuente: http://www.dataprix.com/datawarehouse-manager /
- Esquema copo de nieve: la diferencia del esquema snowflake

comparado con el esquema estrella, está en la estructura de las tablas
dimensión ya que estas, se encuentran normalizadas. Cada tabla
dimensión contiene solo el nivel que es clave primaria en la tabla y la
foreign key de su parentesco del nivel más cercano del diagrama.
Figura 10: Esquema copo de nieve

- Constelación de hechos: es un conjunto de tablas de hechos que

comparten algunas tablas de dimensiones.
43
Figura 11: Constelación de hechos
1.2.7. Data warehouse

Los data warehouse, surgen de la necesidad de contar información de apoyo
para la toma de decisiones, debido a que por sí solos, los datos
operacionales no cumplen eficientemente con este objetivo. Esto conlleva al
desarrollo de la data warehouse para lograr un uso estratégico de la
información como generador de ventajas competitivas.
Según Susan Ostterfeldt (1993), una data warehouse es algo que provee
dos beneficios empresariales reales: integración y acceso de datos. La data
warehouse elimina una gran cantidad de datos inútiles y no deseados, como
también el procesamiento desde el ambiente operacional clásico.
Para Ralph Kimball (2002), una data warehouse es una copia de los datos
de las transacciones de una organización, estructurados específicamente
para la pregunta y el análisis.
Finalmente, Bill Inmon (2005) define, una data warehouse es una colección
de datos integrados, temáticos, no volátiles y variantes en el tiempo,
organizados para soportar necesidades empresariales orientadas a la toma
de decisiones.
44
Se puede concluir, que una data warehouse, es el proceso de extraer y filtrar
datos de las operaciones comunes de las empresas, procedentes de los
distintos subsistemas operacionales, para transformarlos, integrarlos,
sumariarlos y almacenarlos en un depósito o almacén de datos, con la
finalidad de poder acceder a ellos cada vez que se necesite mediante
mecanismos flexibles para el usuario.
Características de la data warehouse:

Los data warehouse, comparten las siguientes características:
- Integrado: los datos almacenados deben integrarse en una estructura
consistente, por lo que las inconsistencias existentes en la información
de los diversos sistemas operacionales deben ser eliminadas. La
información suele estructurarse también en distintos niveles de detalle
para adecuarse a las distintas necesidades de los usuarios.
- Temático: solo los datos necesarios para el proceso de generación del
conocimiento se integran desde el entorno operacional. Los datos se
organizan por temas para facilitar su acceso y entendimiento por parte
de los usuarios finales.
- Histórico: el tiempo es parte implícita de la información contenida en
una data warehouse. En los sistemas operacionales, los datos siempre
reflejan el estado de la actividad del negocio en el momento presente,
por el contrario, la información almacenada en la data warehouse sirve,
entre otras cosas, para realizar análisis de tendencias en el tiempo.
- No volátil: el almacén de información de una data warehouse existe
para ser leído, y no modificado. La información es por tanto
permanente, significando la actualización de la data warehouse la
incorporación de los últimos valores que tomaron las distintas variables
contenidas en él sin ningún tipo de acción sobre lo que ya existía.
45
Figura 12: Arquitectura de un data warehouse
Fuente: http://www.aunalytics.com/building-a-data-warehouse /
1.2.8. Metodologías de inteligencia de negocios

La elaboración de una data warhouse, responde a las necesidades de
información de la empresa, por ende, el desarrollo que implica que la
construcción debe ser planificada, considerando los intereses de los
usuarios finales de la información.
En su libro (Kimball, 2002), propone una metodología la cual se enfoca

principalmente en el diseño de la base de datos que almacenará la
información para la toma de decisiones, estructurando el desarrollo en una
serie de pasos contemplando tareas de alto nivel requeridas para el efectivo
diseño, desarrollo e implementación de la data warehouse.
46
La figura 13 muestra la relación de los pasos específicos en la metodología
de Ralph Kimball para el diseño, desarrollo e implementación de la data
warehouse.
Figura 13: Fases de la metodología de Ralph Kimball

Fuente: The Datawarehouse Lifecycle Toolkit, 2° Edición
El diseño es basado en el modelo estrella que consiste en la creación de

tablas de hechos, es decir, tablas que contengan la información numérica o
cuantitativa de los indicadores a analizar para la toma de decisiones; los
cuales se relacionen con tablas de dimensiones, es decir las tablas
contienen la información cualitativa, de los indicadores.
1.2.9. Herramientas de inteligencia de negocios

Las herramientas de inteligencia de negocios son un tipo de software de
aplicaciones diseñado para apoyar a la inteligencia de negocios o business
intelligence en los procesos de las organizaciones. Las herramientas son
usadas para acceder a los datos de los negocios y proporcionar reportes,
análisis, visualizaciones y alertas a los usuarios. La gran mayoría de las
herramientas de inteligencia de negocios son usadas por usuarios finales
para acceder, analizar y reportar contra los datos que más frecuentemente
residen en data warehouse, data marts y almacenes de datos operacionales.
47
JasperReports
La biblioteca JasperReports es motor de informes de código abierto más
popular del mundo. Está escrito completamente en lenguaje de
programación Java y permite conectarse al origen de datos para producir
documentos, reportes y cuadros que se pueden ver, imprimir o exportar en
una variedad de formatos de documentos incluyendo HTML, PDF, Excel,
OpenOffice y Word. Asimismo, incorpora un servidor de dominio
configurable, el cual permite a los usuarios acceder a los reportes y cuadros,
así como publicarlos.
El propósito principal es ayudar a crear documentos de tipo páginas,

preparados para imprimir en una forma simple y flexible.
Figura 14: Logotipo JasperReports Server

Fuente: http://community.jaspersoft.com
Características
JasperReports es una biblioteca que puede ser embebida o desplegada en
cualquier aplicación en lenguaje de programación Java. Sus funciones
incluyen:
- Scriptlets, que pueden acompañar a la definición del informe y pueden
ser invocados en cualquier momento por la definición para realizar un
procesamiento adicional. El scriptlet se basa en lenguaje programación
Java, y tiene muchos ganchos o hooks que se pueden invocar antes o
después de las etapas de la generación de informes, como el informe,
página, columna o grupo.
- Sub-informes
- Cuadros y gráficos
48
1.2.10. Lenguajes de programación
Un lenguaje de programación es un lenguaje que puede ser utilizado para
controlar el comportamiento de una máquina, mediante la comunicación
usuario - máquina, particularmente una computadora. La comunicación se
realiza mediante traductores de lenguaje, estos son programas especiales
de tipo compiladores o intérpretes, los cuales convierten las instrucciones de
alto nivel o de nivel de usuario, a instrucciones a nivel código máquina para
que estas puedan ser interpretadas por la computadora.
Traductores de lenguaje:
a. Lenguajes compiladores
Los lenguajes de tipo compilador son programas que traducen los
programas fuentes escritos de alto nivel a lenguaje máquina, la operación de
traducción en estos programas se realiza en un solo bloque y se denomina
compilado. Estos, como los programas ensambladores avanzados, pueden
generar muchas líneas de código de máquina por cada proposición del
programa fuente. Es requerido una ejecución de compilación antes de
procesar los datos de un problema.
b. Lenguajes interpretadores
Los lenguajes intérprete son una alternativa diferente de los compiladores
para traducir lenguajes de alto nivel. En vez de traducir el programa fuente y
grabar en forma permanente el código objeto que se produce durante la
corrida de compilación para utilizarlo en una corrida de producción futura, el
programador solo carga el programa fuente en la computadora junto con los
datos que se van a procesar.
Entre los lenguajes analizados se tiene:

- PHP: Es un lenguaje de script interpretado en el lado del servidor
utilizado para la generación de páginas web dinámicas, embebidas en
páginas HTML y ejecutadas en el servidor.
- Java: Es un lenguaje de programación orientado a objetos y que fue
desarrollado por Sun Microsystems. El lenguaje en sí mismo toma
49
mucha de la sintaxis de C y C++, pero tiene un modelo de objetos más
simple, además elimina herramientas de bajo nivel que suelen inducir a
muchos errores como la manipulación directa de punteros.
- Python: Es un lenguaje de programación script, interpretado,
interactivo y orientado a objetos. Se le compara con lenguajes como
Tcl, Perl, Scheme o Java.
La tabla 3 presenta el cuadro comparativo de lenguajes de programación

indicando la evaluación de las principales características asociadas.
Tabla N° 3: Cuadro comparativo de lenguajes de programación
LENGUAJES DE PROGRAMACIÓN
Características PHP Java Python
Multiplataforma Sí Sí Sí
Nivel de
Fácil - Intermedio Intermedio Fácil
aprendizaje
Software libre Sí Sí Sí
Documentación
Regular Bastante Bastante
existente
Organización por
Básico Intermedio -
capas
Extensiones Sí Sí Sí
Muy deficiente para Penalización en

aplicaciones grandes tiempo debido a Lentitud por ser un
Rendimiento que demandan gran características lenguaje
cantidad de solicitudes propias del interpretado.
del servidor. lenguaje.
Fuente: Varias
1.2.11. Patrón de diseño

Dado que existe gran cantidad de patrones de diseño, se describirán y
compararán dos de los patrones de diseño más conocidos.
50
a. Patrón Modelo – Vista – Controlador (MVC)
MVC es el patrón de diseño arquitectural recomendado para aplicaciones
interactivas en lenguaje de programación Java. Entre sus características se
tiene que separar los conceptos de diseño, y por lo tanto reduce la
duplicación de código, la centralización del control y hace que la aplicación
sea más extensible.
Los componentes en los que se separan los datos de una aplicación, la

interfaz de usuario y la lógica de control son los siguientes:
- Modelo: encapsula los datos y las funcionalidades del negocio. Accede
a la capa de acceso a datos.
- Vista: se encarga de mostrar la información recibida al usuario por
medio de la interfaz gráfica de usuario. Así como también notifica al
Controlador que se ha producido algún evento.
- Controlador: recibe los eventos de entrada y se encarga de realizar
peticiones de actualización al modelo o a la vista según sea el caso.
b. Patrón Modelo – Vista – Presentador (MVP)

MVP es un patrón de diseño arquitectural derivado del patrón MVC. Está
más enfocado a que la interfaz de usuario tenga la menor cantidad de código
posible y cuya lógica sea administrada por un “presentador” que no dependa
de los componentes de la interfaz gráfica siendo más fácil de probar.
Sus componentes son los siguientes:

- Modelo: compuesto por los objetos que manejan los datos dentro de la
aplicación.
- Interfaz de vista (IView): interfaz con la que el presentador se
comunica con la vista.
- Vista: implementa la interfaz IView y se encarga de manejar los
aspectos visuales. Mantiene una referencia a su presentador, al cual le
delega la responsabilidad del manejo de los eventos.
51
- Presentador: contiene la lógica para responder a los eventos y
manipula el estado de la vista mediante una referencia a la interfaz
IView. Utiliza el modelo para saber cómo responder a los eventos.
La tabla 4 presenta el cuadro comparativo entre los principales patrones de

diseño, indicando la evaluación de las principales características asociadas.
Tabla N° 4: Cuadro comparativo de patrones de diseño
PATRONES DE DISEÑO
Características MVC MVP
Clara separación de conceptos Sí Sí
Reutilización de código Sí Sí
Flexibilidad Sí Sí
Facilidad de probar Regular Fácil
Facilidad de manejo de múltiples vistas Fácil Regular
Nivel de aprendizaje Fácil Regular
Nivel de conocimientos previos Regular -
Documentación existente Bastante Poca
Fuente: Varias
1.2.12. Framework
Un framework es una estructura conceptual y tecnológica de soporte
definido, normalmente con artefactos o módulos de software concretos, que
puede servir de base para la organización y desarrollo de software.
Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje
interpretado, entre otras herramientas, para así ayudar a desarrollar y unir
los diferentes componentes de un proyecto.
Representa una arquitectura de software que modela las relaciones

generales de las entidades del dominio, y provee una estructura y una
metodología de trabajo, la cual utiliza las aplicaciones del dominio.
52
Codeigniter Framework
Codeigniter es un framework open source orientado en desarrollo web usado
principalmente en desarrollos basados en lenguaje PHP. Se encuentra
basado en el patrón de diseño modelo-vista-controlador, las facultades de
Codeigniter permiten que los modelos y vistas sean opcionales mientras el
controlador de las clases es necesariamente parte del desarrollo.
Características
- Basado en el patrón de diseño MVC.
- No se encuentra sujeto a requerimientos de servidor: Trabaja con PHP
4 y PHP 5, lo que facilita el trabajo entre entornos.
- Fácil de entender y profundizar.
- Presenta múltiples herramientas para el desarrollo y librerías.
- No requiere instalación.
- Permite construir capas de seguridad para las aplicaciones
- Presenta capa de abstracción de datos.
1.3. Definición de términos básicos
a. Carga procesal
Son exigencias procesales que, de no cumplirse, causan un perjuicio
procesal al incumplido, de manera que las partes tienen un interés propio de
llevar a cabo la actuación, pues en su defecto, se verán afectados por la
omisión. Así, las pruebas constituyen una carga para las partes de un trabajo
o un proyecto.
b. Caso
Caso. (Del latín "casus", caída, accidente) problema o hecho sobre el que se
consulta a alguien y pedirle su dictamen. ¿Y quién soluciona los problemas
de la gente, en primera instancia? Los jefes de tribu, los ancianos, el cura,
luego la policía. La policía denominó al conflicto de las personas: caso, al no
darles solución, el caso era remitido a sus superiores, a los jueces, pasando
así también la denominación de caso, al proceso.
53
c. Cloud computing
Cloud computing o computación en la nube es una tecnología que consiste
en ofrecer servicios a través de internet. A diferencia de un almacenamiento
tradicional, la computación en la nube buscando reducir el espacio físico
almacenando archivos e información en internet sin la dependencia de
poseer la capacidad suficiente para almacenar información.
Cloud computing explica las nuevas posibilidades de forma de negocio

actual, ofreciendo servicios a través de internet, conocidos como e-
business o negocios por Internet.
d. Contienda
Dícese de una disputa, pelea, riña, discusión o un debate. En derecho, se
refiere al conflicto que existe entre las partes, el cual en materia
jurisdiccional, se establece en lo que respecta a las competencias sobre un
determinado proceso.
e. Data mart
Es una data warehouse solo que más pequeña; en otras palabras, es una
data warehouse orientada a algún tema en particular. Las data mart suelen
ser usados por un departamento o grupo de usuarios en una compañía, para
un conjunto definido de tareas.
Las data mart aislados, es decir los que toman sus datos directamente
desde sistemas transaccionales y no dependen de otros data warehouse,
recién el nombre de “data marts independientes”. Una data mart se
considera independiente, ya que recibe datos desde una data warehouse.
f. Data warehouse
Es un repositorio de información extraída de otros sistemas corporativos,
sean estos sistemas transaccionales, bases de datos departamentales, o
intranet de la compañía, a la que los hombres de negocios de la empresa
pueden acceder.
54
Los sistemas de data warehouse están orientados a procesos de consultas
en contraposición con los procesos transaccionales, sus tablas pueden no
estar normalizadas y se admite redundancia en los datos; mejor dicho, la
data warehouse es un sistema, no un producto, en el que se almacenan y
consolidan datos de variadas fuentes con el propósito de responder
preguntas de negocios y tomar decisiones, de una forma rápida. Una data
warehouse se vale de una base de datos relacional diseñada para el acceso
rápido y análisis y no al proceso transaccional. La data warehouse separa la
carga del análisis y normalmente contiene datos históricos derivados de
datos transaccionales.
g. Dimensión
Entidad independiente dentro del modelo multidimensional de una
organización, que sirve como llave de búsqueda actuando como índice, o
como mecanismo de selección de datos.
h. ETL
Pasos por los que atraviesan los datos para ir desde el sistema OLTP o la
fuente de datos utilizada, a la bodega dimensional. Extracción, se refiere al
mecanismo por medio del cual los datos son leídos desde su fuente original.
Transformación, también conocida como limpieza, es la etapa por la que
puede atravesar una base de datos para estandarizar los datos de las
distintas fuentes, normalizando y fijando una estructura para los datos.
Finalmente está el transporte, que consiste básicamente en llevar los datos
leídos y estandarizados a la bodega dimensional de forma remota o
localmente. Generalmente, para una data mart no es necesario atravesar por
todos estos pasos, pues al ser información localizada, sus datos suelen estar
naturalmente estandarizados, es decir, posee una sola fuente.
i. Expediente
Es un conjunto de documentos que corresponden a una determinada
cuestión sobre los cuales un juez debe emitir su dictamen. Conjunto de serie
de procedimientos de carácter judicial o administrativo.
55
j. Inteligencia de negocios
Es la habilidad para transformar los datos en información, y la información en
conocimiento, de forma que se pueda optimizar el proceso de toma de
decisiones en los negocios.
Desde un punto de vista más pragmático, y asociándolo directamente con

las tecnologías de la información, se puede definir la inteligencia de negocios
o business intelligence como el conjunto de metodologías, aplicaciones y
tecnologías que permiten reunir, depurar y transformar datos de los sistemas
transaccionales e información desestructurada interna y externa de la
compañía en información estructurada, para su explotación directa mediante
reporting, análisis OLTP / OLAP, alertas, entre otros.; o para su análisis y
conversión en conocimiento, dando así soporte a la toma de decisiones
sobre el negocio.
La inteligencia de negocio actúa como un factor estratégico para una

empresa u organización, generando una potencial ventaja competitiva, que
no es otra que proporcionar información privilegiada para responder a los
problemas de negocio: entrada a nuevos mercados, promociones u ofertas
de productos, eliminación de islas de información, control financiero,
optimización de costes, planificación de la producción, análisis de perfiles de
clientes, rentabilidad de un producto concreto, etc.
k. Litigio
Del latín "litis contestatio". Es la composición o arreglo de un conflicto a
través de un contrato. Modernamente un proceso nunca puede ser un
contrato.
l. OLAP- OnLine Anlytical Processing

Procesamiento Analítico en Línea u OLAP es una forma específica para
representar datos financieros, operacionales, comerciales y estadísticos
orientados a los ejecutivos, especialistas y analistas. Está diseñada para
ayudar a la toma de decisiones y una mejor comprensión de la información.
La idea central es poder contestar las preguntas de los usuarios, de una
56
forma fácil, poderosa e intuitiva. Un sistema OLAP permite a los usuarios
entrar en detalles y generalizar, filtrar, ordenar, clasificar y reagrupar datos,
calculándose totales intermediarios y finales en forma instantánea.
La tecnología OLAP permite un uso más eficaz de los almacenes de datos

para el análisis en línea, lo que proporciona respuestas rápidas a consultas
analíticas complejas e iterativas. Los modelos de datos multidimensionales
de OLAP y las técnicas de agregados de datos organizan y resumen
grandes cantidades de datos para que puedan ser evaluados con rapidez
mediante el análisis en línea y las herramientas gráficas. Los sistemas OLAP
proporcionan la velocidad y la flexibilidad necesarias para dar apoyo al
analista en tiempo real. Cabe indicar que la tecnología OLAP tiene como
base el proceso de transacciones en línea (OLTP).
Las siguientes son características que la tecnología OLAP posee:

 Las bases de datos de OLAP tienen un esquema que está optimizado
para que las preguntas realizadas por los usuarios sean respondidas
rápidamente.
 Las preguntas que se le hacen a un OLAP, deben permitir un uso
interactivo con los usuarios.
 Los cubos de OLAP almacenan varios niveles de datos conformados
por estructuras altamente optimizadas que responden a las
expectativas de negocio de la empresa.
 Un sistema OLAP está preparado para realizar informes complejos de
una manera simple.
 La tecnología OLAP proporciona una vista de datos multidimensional.
Los cubos proporcionan una vista de los datos multidimensional que se
extiende más allá del análisis de dos dimensiones que puede
proporcionar una simple planilla de cálculo utilizada como tal.
 Los usuarios pueden cambiar fácilmente las filas, las columnas, y las
páginas en informes de OLAP, pudiendo leer la información de la
manera que se crea más conveniente para el análisis.
57
m. Órgano jurisdiccional
Es un órgano público cuya finalidad principal es ejercer la jurisdicción, es
decir, resolver litigios con eficacia de cosa juzgada sin perjuicio de cumplir
actos de otra índole que las leyes que los organizan les pueda atribuir; estos
asuntos son denominados no contenciosos. No debe confundirse el órgano
jurisdiccional como el tribunal, con las personas que en calidad de
funcionarios sirven en él como lo son los jueces y demás personal auxiliar.
n. Proceso
Sucesión de fases jurídicas concatenadas realizadas conforme al orden
trazado por la ley, el juez, las partes y los terceros en ejercicio de los
poderes, derechos, facultades y cargas que les atribuye la ley procesal o en
cumplimiento de los deberes y obligaciones que la misma les impone,
cursadas ante órgano jurisdiccional, pretendiendo y pidiendo la actuación de
la ley para que: que dirima la controversia, verificado que sean los hechos
alegados o que: que se imponga una pena o medida de seguridad al
procesado averiguado que sea su delito o peligrosidad criminal, pretensión y
petición que se plasmará en una sentencia pasada por autoridad de cosa
juzgada.
o. Sistemas transaccionales OLTP

Los sistemas de Procesamiento de Transacciones en Linea u OLTP son
sistemas transaccionales que están altamente afinados para realizar su
trabajo rápidamente, usualmente en tiempo real, y a menudo con el uso de
mainframes y otros servidores grandes, capturan las transacciones de un
negocio y las persisten en estructuras relacionales llamadas base de datos.
Las características principales de los sistemas OLTP son:

 Realizan transacciones en tiempo real del proceso de un negocio, con
lo cual los datos almacenados cambian continuamente. Los sistemas
OLTP en sus transacciones conducen procesos esenciales del
negocio.
58
 Los sistemas OLTP son los responsables del mantenimiento de los
datos, ya sea agregando datos, realizando actualizaciones o bien
eliminándolos.
 Las estructuras de datos deben estar optimizadas para validar la
entrada de los mismos, y rechazarlos si no cumplen con determinadas
reglas de negocio.
 Para la toma de decisiones, proporciona capacidades limitadas ya que
no es su objetivo, por lo tanto, no es prioridad en su diseño. Sí se
quisiera obtener determinada información histórica relativa al negocio
consultando un sistema OLTP, se produciría un impacto negativo en el
funcionamiento del sistema.
59
CAPÍTULO II:
METODOLOGÍA
2.1. Material
2.1.1. Software
La tabla 5 presenta los requerimientos de software utilizado para el
desarrollo del proyecto.
Tabla N° 5: Requerimiento de software el proyecto
SOFTWARE
Descripción Cantidad Licencia
Base de datos: MySQL 1 Propietario

Programación: PHP 1 Open Source
Programación: Sublime Text 1 Open Source
Diseño: Pencil Project 1 Open Source
Pruebas: Apache Tomcat 1 Open Source
sistemas operativos: Windows 8 1 Propietario
Servidor de business intelligence: TIBCO JasperReport 1 Open Source
Reportes: TIBCO Jaspersoft Studio 1 Open Source
Integración ETL: TIBCO Jaspersoft ETL Comunity 1 Open Source
Documentación: Microsoft Office 2013 2 Propietario
Fuente: Propia
2.1.2. Hardware
La tabla 6 presenta los requerimientos de hardware necesario para el
60
Tabla N° 6: Requerimientos de hardware del proyecto
HARDWARE
Descripción Cantidad
Laptop Toshiba Satellite 845C Core i3 1
Laptop Toshiba Satellite I845 Core i5 1
Fuente: Propia
2.1.3. Recursos humanos

El desarrollo del proyecto contará con la participación activa de los tesistas
los que asumirán diversos roles para la ejecución del proyecto. El equipo de
trabajo está compuesto por:
- Castillo Mamani Dennis Wilmer (DC)
- Cerva Cabrera Luis Alonso (LC)
La tabla 7 muestra el detalle de las funciones principales de los roles

asociados a los recursos humanos:
Tabla N° 7: Roles y funciones de los ejecutores del proyecto
ROLES Y FUNCIONES
Rol Responsable Funciones
Análisis y modelado del esquema de base de datos

Analista de BI LC según la información recolectada.
Modelado y levantamiento de los procesos.
Realizar los mockups de los flujos de navegación

Diseñador DC
web que tendrá el sistema.
Análisis de la arquitectura de la aplicación.

Desarrollador DC Desarrollo de capa BackEnd o lógica de negocio.
Desarrollo de FrontEnd o capa cliente del sistema.
Analista QA LC Realizar las pruebas funcionalidad del sistema.
Fuente: Propia
61
2.1.4. Presupuesto
El proyecto consta de un coste total de realización por un monto de S/.
8,462, presupuestados durante un periodo de desarrollo de cuatro meses.
Asimismo, se tiene un periodo de recuperación estimado por el proyecto en
seis meses, fijando el costo de la solución en S/. 2,000 como precio de venta
y el costo por mantenimiento en S/. 200 soles. Ver Anexo 6.
La tabla 8 presenta el detalle de los costos totales en los que infiere el

desarrollo del proyecto. La tabla 9 presenta el detalle del periodo de
recuperación del proyecto.
Tabla N° 8: Costos totales del proyecto
COSTOS TOTALES
Tipo de Costo Subtotal (S/.)
Recursos humanos 7900

Hardware 367
Software 195
Total 8462
Fuente: Propia
Tabla N° 9: Periodo de recuperación
PERIODO DE RECUPERACIÓN
Flujo de Caja Mes 0 Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6
Inversión 8462
Ingresos netos 2113 2113 2113 2113 2113 2113
Ingreso actualizado 1921 1746 1588 1443 1312 1193

Suma de los
- 8462 1921 3667 5255 6698 8090 9283
ingresos
Fuente: Propia
62
2.1.5. Modelo de negocio
Se ha definido como modelo de negocio, el modelo de alquiler de software,
el cual es muy usado por empresas que desarrollan y distribuyen software
para su comercialización, el cual consiste la venta de la licencia del software
y posteriormente en coste por el mantenimiento de la solución. Ver Anexo 4.
2.2. Métodos
2.2.1. Referencia metodológica para la gestión del proyecto

El presente punto presenta tres metodologías ágiles para la implementación
de software, las cuales serán comparadas y para determinar la metodología
a usar en la elaboración del proyecto.
- Scrum. Metodología ágil que se centra en las iteraciones a presentar y
las reuniones.
- Crystal. Metodología ágil que hace énfasis en la comunicación y
tolerancia.
- XP. Metodología ágil que se centra en potenciar las relaciones
interpersonales y la retroalimentación.
a. Análisis cuantitativo por criterio de las metodologías

elegidas
La tabla 11 presenta el análisis comparativo cuantitativo de metodologías
ágiles. Los valores tomados para el análisis comparativo cuantitativo se
describen en la tabla 10.
Tabla 10: Tabla de ponderaciones
TABLA DE PONDERACIONES
Valor Descripción
1 Bajo
1 Medio
1 Alto
Fuente: Propia
63
Tabla 11: Análisis cuantitativo de metodologías ágiles
METODOLOGIAS AGILES
Criterio SCRUM Crystal XP
Adaptabilidad 3 2 2
Complejidad del proyecto 3 2 2
Entendimiento de requerimientos 2 2 2
Disponibilidad de recursos 3 2 2
Conocimiento del dominio del problema 2 3 2
Manejo de las perspectivas de riesgos 1 3 3
Tiempo de desarrollo 3 2 2
Costos del proyecto 2 1 2
Resultados 3 2 2
Documentación 3 2 2
Calidad del software 2 2 3
TOTAL 27 23 24
Fuente: Varias
b. Análisis cualitativo por criterio de las metodologías

elegidas
La tabla 12 presenta el análisis comparativo cualitativo de las metodologías
ágiles.
64
Tabla 12: Análisis cualitativo de metodologías ágiles
METODOLOGÍAS ÁGILES
Criterio SCRUM Crystal XP
Adaptabilidad Alta Media Media

Complejidad del proyecto Alta Media Media
Entendimiento de requerimientos Media Especifico Media
Disponibilidad de recursos Alta Media Media
Conocimiento del dominio del problema Regular Alto Regular
Manejo de las perspectivas de riesgos No Sí Sí
Tiempo de desarrollo Bajo Bajo Bajo
Costos del proyecto Medio Bajo Medio
Resultados Alta Media Media
Documentación Alta Media Media
Calidad del software Media Media Alta
Fuente: Varias
c. Resultado del análisis cualitativo y cuantitativo

En base al análisis realizado permite concluir en el uso de la metodología
SCRUM para el desarrollo del proyecto, ya que posee mayor el resultado
ponderado del análisis cuantitativo, asimismo este resultado se ve reflejado
de igual forma en el análisis cualitativo.
2.2.2. Resumen de la metodología SCRUM

Es un marco de desarrollo ágil para proyectos que poseen entornos
complejos donde los requisitos suelen ser cambiantes, donde la innovación,
competitividad, flexibilidad y productividad son fundamentales.
Entre sus principales características se encuentran:

- Desarrollo de software mediante interacciones o SPRINTS, de carácter
incremental, los cuales definen una lista de tareas que serán
desarrolladas durante un ciclo o iteración determinado.
65
- Énfasis en equipos auto-dirigidos y auto-organizados con roles
definidos, los cuales se reúnen periódicamente para discutir el avance
del equipo.
- Énfasis en uso de retrospectiva, al finalizar cada desarrollo o iteración
incremental.
Elementos de SCRUM
a. Roles
SCRUM posee tres roles definidos los cuales intervienen en todo el
- Dueño del producto: es el responsable de establecer la visión del
producto y las prioridades.
- Equipo responsable de la implementación el producto.
- Scrum Master: es el facilitador del proyecto, elimina los impedimentos
y proporciona liderazgo en el proceso.
b. Reuniones
En SCRUM existen diferentes tipos de reuniones, las cuales están dadas
dependiendo de la periodicidad y el tipo de revisión a realizar:
- SPRINT planning: consiste en estimar el trabajo del SPRINT en ciclos
de desarrollo de 15 o 30 días.
- SPRINT review: consiste en revisar el trabajo que fue completado y no
completado.
- SPRINT retrospective: consiste en ejecutar una retrospectiva del
SPRINT, en la cual todos los miembros del equipo dejan sus
impresiones sobre el SPRINT recién superado, para una mejora
continua del proceso.
- Daily scrum meeting: reunión diaria sobre el estado del proyecto.
c. Artefactos
- Product backlog o pila del producto: es la lista de requerimientos o
“ítems” que contendrá el producto.
66
- SPRINT backlog: es la lista de “ítems” que se serán realizados en el
SPRINT actual.
- Incremento: es la interrogación del “software funcionando” realizado en
el SPRINT actual.
- Burndown chart: es el gráfico del trabajo pendiente.
- Realease: incremento que se le entrega al cliente.
La figura 15 muestra la relación de los elementos de Scrum dentro de una

iteración de Scrum.
Figura 15: Proceso SCRUM

Fuente: Mountain Goat Sotware
2.2.3. Metodología para el business inteligence

La metodología desarrollada, se basa en lo que Kimball denomina ciclo de
vida dimensional del negocio (Business Dimensional Lifecycle). Este ciclo de
vida del proyecto de data warehouse, está basado en cuatro principios
básicos:
- Centrarse en el negocio: consiste en la identificación de los
requerimientos del negocio y su valor asociado, agudizando el análisis
de estos y la competencia consultiva de los implementadores.
- Construir una infraestructura de información adecuada: consiste
en diseñar una base de información única, integrada, fácil de usar y de
67
alto rendimiento donde se refleje la amplia gama de requerimientos de
negocio identificados en la empresa.
- Realizar entregas en incrementos significativos: consiste en
estructurar la creación del almacén de datos o data warehouse en
entregables incrementos en plazos de 6 a 12 meses.
- Ofrecer la solución completa: consiste en proporcionar todos los
elementos necesarios para entregar valor a los usuarios de negocios,
comenzando con un almacén de datos sólido, bien diseñado, con
calidad probada, y accesible. De igual manera, se debe hacer entrega
de las herramientas de consulta ad hoc, aplicaciones para informes y
análisis avanzado, capacitación, soporte, sitio web y documentación.
El ciclo dimensional de negocio

La construcción de una solución de inteligencia de negocio es sumamente
compleja, ante esta situación Kimball propone una metodología que ayuda a
simplificar dicha complejidad.
La figura 16 muestra las tareas involucradas en el ciclo de dimensional del

negocio para el desarrollo e implementación de una data warehouse.
Figura 16: Ciclo dimensional del negocio

Fuente: The Data Warehouse Lifecycle Toolkit. 2º Edición
68
Del análisis del ciclo dimensional del negocio, se puede distinguir en primer
lugar, la tarea de definición de requerimientos del negocio, los cuales
representan el soporte inicial de las tareas subsiguientes, y en segundo lugar
se puede identificar que existen tres rutas que se enfocan en tres diferentes
áreas de la integración:
- Tecnología, camino superior, implica tareas relacionadas con software
específico, por ejemplo, MSAS.
- Datos, camino central, implica el diseño e implementación del modelo
dimensional, y el desarrollo del subsistema de Extracción,
Transformación y Carga (Extract, Transformation, and Load - ETL) para
cargar la data warehouse.
- Aplicaciones de inteligencia de negocios, camino inferior, implica el
diseño y desarrollo de las aplicaciones de negocios para los usuarios
finales.
Estas rutas se combinan posteriormente cuando es instalado finalmente el

sistema de inteligencia de negocios. A partir de este punto se empieza a
realizar el mantenimiento del sistema y todo desarrollo posterior será
incrementado dentro de éste.
2.2.4. Métodos para gestión de procesos BPM

La Gestión de Procesos de Negocio o Business Process Management
(BPM) es un conjunto de métodos, herramientas y tecnologías utilizados
para diseñar, representar, analizar y controlar procesos de negocio, los
cuales buscan mejorar el rendimiento de los procesos combinando las
tecnologías de la información con metodologías de proceso y gobierno.
BPM abarca personas, sistemas, funciones, negocios, clientes, proveedores

y socios, dando soporte para interacción humana, e integración de
aplicaciones, integrándolos y combinándolos con métodos ya probados y
establecidos de gestión de procesos con herramientas de software
empresarial. Todo esto, ha posibilitado adelantos muy importantes en cuanto
a la velocidad y agilidad con que las organizaciones mejoran el rendimiento
de negocio. (Garimella, K. et al, 2008).
69
BPM, contempla tres aspectos fundamentales que son: el negocio, el
proceso y la gestión, mediante las cuales se dirige al mundo empresarial
sobre esas tres dimensiones:
a. Dimensiones del BPM

- Dimensión del negocio. Representa la dimensión de valor y de la
creación de valor tanto para los clientes como para los stakeholders.
- Dimensión del proceso. Representa la dimensión de la
transformación en la cual se crea valor a través de actividades
estructuradas o procesos, los cuales transforman los recursos y
materiales en productos o servicios para clientes y consumidores
finales. Mientras más efectiva sea esta transformación, con mayor éxito
se crea valor.
- Dimensión de la gestión. La gestión pone a las personas y a los
sistemas en movimiento, además empuja a los procesos a la acción en
pos de los fines y objetivos del negocio.
b. Componentes funcionales de BPM

- Centrado en los procesos: BPM unifica las actividades de negocio y
de TI, coordinando las acciones y comportamientos de personas con
sistemas dentro de los procesos de negocio.
- Alineación negocio/TI: BPM facilita la colaboración directa y la
responsabilidad conjunta de los profesionales de la empresa y de TI en
el desarrollo, implementación y optimización de los procesos de
negocio operacionales.
- Mejora continua de los procesos: BPM implementa los métodos y
herramientas de gestión y de comportamiento de la mejora continua de
procesos.
- Composición de soluciones: BPM facilita el diseño, ensamblaje e
implementación rápida de los procesos de negocio, haciendo uso de un
conjunto de conectores y herramientas que agilizan el desarrollo de
soluciones.
70
- Transparencia: BPM proporciona visibilidad funcional cruzada en
tiempo real de los procesos operacionales y una comprensión común
de las actividades para todos los participantes.
- Aprovechar lo existente y hacer uso de lo nuevo: BPM incorpora de
forma directa sistemas de información y activos existentes permitiendo
reutilizar cualquiera aplicación de TI existentes.
La figura 17 muestra el ciclo de vida de BPM.
Figura 17: Ciclo de vida de BPM

Fuente: Propia
2.2.5. Métodos de pruebas

Para la etapa de realización de pruebas se están considerando las
siguientes herramientas:
a. Relevamiento de procesos y toma de tiempos

Consiste en realizar el levantamiento de las actividades de los principales
procesos identificando los responsables del proceso, los flujos principales y
secundarios, la toma de decisiones y los tiempos y recursos involucrados en
la realización de estas actividades en la situación actual, para
posteriormente ser relevado nuevamente durante el despliegue de la
solución contrastando la situación original con la futura y obteniendo las
variaciones.
71
La tabla 13 presenta el modelo general de una ficha de procesos
Tabla 13: Modelo de ficha de procesos
FICHA DE PROCESOS
FICHA DEL PROCESO NIVEL 1
1) Nombre
2) Objetivo
3) Descripción
4) Alcance
7) Listado de procesos 9) Destinatario de los bienes

5) Proveedor 6) Entrada 8) Salida
de nivel 2 y servicios
10) Indicadores
del Proceso
11) Registros
Fuente: Propia
72
b. Pruebas unitarias
Consiste en realizar la evaluación de los diversos componentes que forman
parte del sistema de manera independiente, para corroborar su correcto
funcionamiento. Estas pruebas consiguen una gran cobertura ya que
favorecen la granularidad, disminuyen la necesidad de depuración, ayudan a
mejorar el diseño y sirven como documentación. Por sí solas, estas pruebas
no son suficientes dado que, si se realizará algún cambio, se tendrían que
volver a pasar todas las pruebas para asegurarse que todo sigue conforme,
es decir, regresión. Es por ello, que también se realizan pruebas de
integración.
c. Pruebas de integración
Consiste en realizar la evaluación de las distintas combinaciones de las de
las partes del sistema para determinar si funcionan correctamente en
conjunto. Luego de realizadas las pruebas unitarias sobre los componentes
individuales, estos son llamados cuando son necesarios, es decir, cuando
los datos que se transmiten son los requeridos. Estas pruebas tampoco son
suficientes ya que aún no se puede dar un diagnóstico del sistema en
general, para lo cual se realizan las pruebas de sistema.
d. Pruebas de sistema
Consiste en la ejecución de pruebas de forma global. Secuencialmente están
dadas después del desarrollo de las pruebas unitarias y pruebas de
integración dentro de un ambiente de desarrollo. Estas pruebas están
basadas en los requerimientos generales y a través de ellas se puede
verificar adicionalmente anteriormente probado entro otros aspectos
mediante pruebas de tipo funcional, de rendimiento, de disponibilidad de
datos, de facilidad de uso, entre otras.
e. Encuestas
Consiste en la elaboración de formulario de preguntas con la finalidad
relevar información de los usuarios y responsables de los procesos acerca
de la apreciación y análisis de los resultados cuantificados, sobre lo cual
contrastarlo con la información recopilada del resto de pruebas.
73
2.2.6. Metodología para el modelo de negocio
El modelo de negocio del proyecto, se basa en el modelo propuesto por
Osterwald y Pigneur (2009), más conocido como modelo de negocio de
lienzo o canvas, en el cual se definen nueve bloques de negocio que deben
ser considerados a la hora de definir un modelo para la empresa.
Bloques del modelo de negocios tipo lienzo

El modelo de negocios tipo lienzo o canvas está compuesto por nueve
bloques expuestos a continuación.
- Segmento de clientes. Hace referencia al nicho de mercado al que se
encuentra dirigido el producto. ¿A quién se crea valor?
- Propuesta de Valor. Hace referencia a las soluciones que ofrece el
producto frente a los problemas que poseen los clientes. ¿Qué
problemas ayuda a solucionar a tus clientes?
- Canales. Hace referencia a los medios por los cuales va a ser
difundido el producto a los segmentos de clientes objetivo. ¿Cuáles son
los canales de distribución del producto?
- Relación con clientes. Hace referencia a la relación que se tiene con
los clientes. Teniendo en cuenta aspectos como la fidelización y
satisfacción ofrecido por el consumo del producto. ¿Dónde empieza y
dónde termina la relación con mis clientes?
- Flujo de ingresos. Hace referencia a la forma en la cual se va a
percibir ingresos por la comercialización del producto. ¿Cómo está
definido el proceso de venta del producto?
- Recursos clave. Hace referencia a los componentes físicos,
económicos, humanos o intelectuales necesarios para el
funcionamiento de la actividad de la empresa. ¿Qué necesitas para
llevar a cabo la actividad de tu empresa?
- Actividades clave. Hace referencia a definir las actividades nucleares
de la empresa. ¿Cuáles son las actividades que aportan más valor a la
empresa?
- Asociaciones clave. Hace referencia a los agentes con los que es
necesario trabajar para hacer posible el funcionamiento del modelo de
74
negocio. ¿Quiénes son los proveedores necesarios para el
funcionamiento de la empresa?
- Estructura de costes. Hace referencia a los costos en los que incurre
la empresa.
La figura 18 muestra los nueves bloques que componen el modelo de

negocio tipo lienzo o canvas.
Figura 18: Modelo de negocio tipo lienzo o canvas

Fuente: Business Model Generator: A Handbook for Visionaries, Game Changers, and
Challengers
75
2.3. Plan de trabajo
La tabla 14 presenta el detalle del plan de trabajo para el desarrollo del
proyecto.
Tabla 14: Plan de trabajo
PLAN DE TRABAJO
Sistema de Control y Seguimiento de Procesos Judiciales
Fecha de reunión de
15/03/2016
planificación:
 Castillo Mamani Dennis Wilmer (DC)
Nombre de documentador:
 Cerva Cabrera Luis Alonso (LC)
Sprints a implementar en la entrega
Fecha de Respons
Número de sprint Título Prioridad
entrega able
Planificación general del
Release R0 proyecto (gestión del Media Marzo
proyecto) Castillo
Release R1 Fase de análisis Alta Marzo / Cerva
Arquitectura de la Marzo /
Release R2 Media
información Abril
Elaboración de artefactos y
0 Alta Abril
repositorio de datos
1 Módulo de mantenimiento Muy Alta Abril
2 Módulo de seguridad Alta Abril
Castillo
3 Módulo de gestión Alta Mayo
/ Cerva
4 Módulo de seguimiento Alta Mayo
5 Módulo de reportes Media Junio
Pruebas y ajustes Media Junio
Finalización del proyecto Junio
Fuente: Propia
76
CAPÍTULO III:
DESARROLLO DE LA SOLUCIÓN
3.1. Requerimientos del sistema

En este punto se presenta el análisis de los requerimientos funcionales y no
funcionales de la solución, los cuales responden a las necesidades de
mejora de los procesos seleccionados para la firma de abogados.
3.2.1. Identificación de requerimientos

Se listan los requerimientos funcionales y no funcionales globales del
sistema que son de primera prioridad y cuya implementación es exigible.
3.2.1.1. Requerimientos funcionales

En el siguiente punto se presenta los requerimientos funcionales del
proyecto agrupados en los módulos que contará la solución. La descripción
de los módulos es profundizada a mayor detalle en el punto 4.4.3.
a. Módulo de gestión
- [RQF001] El administrador requiere consultar la relación de abogados.
- [RQF002] El administrador requiere registrar y modificar el registro del
abogado.
- [RQF003] El administrador requiere consultar la relación de abogados
por especialidad.
- [RQF004] El administrador requiere asignar y modificar abogados por
especialidad.
- [RQF005] El administrador requiere consultar la relación de clientes.
cliente.
- [RQF007] El administrador requiere consultar la relación de procesos.
proceso.
- [RQF009] El administrador requiere consultar la relación de abogados
por proceso.
77
- [RQF010] El administrador requiere asignar y modificar abogados a un
proceso.
b. Módulo de seguimiento
- [RQF011] El abogado requiere consultar la relación de procesos
asignados.
- [RQF012] El abogado requiere consultar la relación de entradas
judiciales por proceso asignado.
- [RQF013] El abogado requiere registrar y modificar el registro de
entradas al proceso judicial.
- [RQF014] El abogado requiere realizar interface con la aplicación CEJ.
- [RQF015] El abogado requiere realizar interface con la aplicación
SINOE.
c. Módulo de mantenimiento
- [RQF016] El administrador del sistema requiere realizar el
mantenimiento de los estados del sistema.
mantenimiento de los tipos de juzgados.
mantenimiento de los distritos judiciales.
mantenimiento de los órganos jurisdiccionales.
mantenimiento de las dependencias judiciales.
mantenimiento de las materias judiciales.
mantenimiento de los departamentos.
mantenimiento de las provincias.
mantenimiento de los distritos.
78
mantenimiento de los tipos de documento de identidad.
mantenimiento de los tipos de doc. jurídicos.
mantenimiento de los tipos de personas.
d. Módulo de seguridad
mantenimiento de los perfiles de usuario de acceso de información.
mantenimiento de los usuarios.
- [RQF030] El usuario ingresara sus credenciales de usuario para
acceder al sistema.
e. Módulo de reportes
- [RQF031] El administrador requiere realizar reportes por criterios.
- [RQF032] El administrador requiere realizar cuadros estadísticos por
criterios.
3.2.1.2. Requerimientos no funcionales

En este punto se detallará los requerimientos no funcionales que presenta la
solución propuesta.
a. Usabilidad
- [RNF001] La interfaz de usuario del sistema ha de proveer facilidad de
uso a los usuarios con conocimiento básico de informática.
- [RNF002] El sistema ha de indicar mensajes en caso de errores
indicando la fuente del error.
- [RNF003] El sistema ha de presentar terminología empleada en el
ámbito legal para el mejor entendimiento de los usuarios finales.
- [RNF004] La interfaz de usuario del sistema ha de aplicar
regionalización en el lenguaje por defecto usado en el sistema.
79
b. Disponibilidad
- [RNF005] El sistema ha de estar disponible entre las 8:00 a.m. y las
02:00 a.m.
- [RNF006] El sistema ha de poder recuperarse tras fallos en el
hardware.
c. Desempeño
- [RNF007] El sistema ha de permitir poder consultar y actualizada la
información permanentemente y de forma simultánea por los usuarios,
sin que se afecte el tiempo de respuesta.
- [RNF008] El tiempo máximo de respuesta ha de ser 4 segundos para
los mantenimientos y de 6 segundos para las transacciones.
d. Escalabilidad
- [RNF009] El sistema ha de ser fácilmente escalable en caso se
produzca un incremento en la cantidad de los usuarios.
- [RNF010] El sistema ha de estar en capacidad de permitir desarrollar
nuevas funcionalidades, modificar o eliminarlas funcionalidades en el
futuro.
e. Mantenibilidad
- [RNF011] El sistema ha de estar documentado y los artefactos que
forman parte de la solución propuesta debidamente documentados,
tanto en manuales de sistema como de usuario.
f. Seguridad
- [RNF012] El sistema ha de restringir y rechazar accesos o
modificaciones no autorizados.
- [RNF013] El acceso ha de ser restringido al uso de contraseñas
encriptados y asignadas a cada uno de los usuarios. Solo podrán
ingresar las personas registradas, los cuales según su perfil tendrán
acceso a opciones de trabajo definidas.
- [RNF014] El control de acceso ha de permitir asignar perfiles de
usuario para cada rol identificado.
80
g. Validación
- [RNF015] El sistema ha de validar la información contenida en los
formularios de ingreso, considerando aspectos como obligatoriedad de
campos, longitud de caracteres, manejo de tipo de datos, etc.
3.2.2. Seguridad del software

Con la finalidad de garantizar un correcto control de accesos a las diferentes
funcionalidades del sistema, han sido definidos los siguientes aspectos:
- Se han de almacenar en base de datos los usuarios del sistema, los
cuales poseerán un perfil de usuario que determinará el nivel de
acceso a la información.
- Se han de elaborar mantenimientos que contengan la información
maestra utilizada en el sistema por los usuarios. A estos
mantenimientos solo tendrá acceso el encargado de soporte del
sistema.
- El usuario que interactúa con el sistema solo podrá usar las opciones
definidas por su perfil de usuario, siendo tomado como premisa en el
desarrollo.
- Sí el usuario no logra ingresar al sistema tras ingresar sus credenciales
en un máximo de tres oportunidades, el sistema notificará una alarma
al bloqueando al usuario.
- Los registros y modificaciones efectuadas por los usuarios en las
principales funcionalidades, han de ser almacenas en logs de
seguridad de la base de datos, indicando el usuario que operó la
funcionalidad para tener constatación.
- Las funcionalidades del sistema, solo procesarán si se completan los
datos necesarios, en caso contrario, indicará un mensaje comunicando
el error.
3.3. Derivación de STQR a FEAT

En este punto se presenta la derivación de los requerimientos en
características asociadas a los requerimientos obtenidos, ordenados en
módulos operativos y administrativos, con lo cual se puede obtener las
características asociadas a cada requerimiento funcional. Ver Anexo 5.
81
3.4. Análisis de Procesos
En este punto se presenta el flujo de los procesos de negocio involucrados
en el despliegue del sistema, asimismo se identificarán las actividades
sistematizables presentes dentro del proceso de negocios, las cuales
respondan a la solución propuesta por el proyecto. El análisis del proceso
en el sistema es realizado al nivel de subprocesos, lo cual permite un mejor
desarrollo de las funcionalidades involucradas en el proceso, así como dividir
las responsabilidades de los usuarios en paquetes que contengan las
funcionalidades con las que posteriormente interactúen en la solución. Ver
Anexo 8.
3.5. SPRINT 0
3.5.1. Product backlog

El product backlog del sistema, contiene descripciones genéricas de todos
los requerimientos y funcionalidades deseables priorizadas por el product
owner, en el cual se indica la prioridad y el valor para el negocio.
La tabla 15 presenta la relación de requerimientos especificados en el

product backlog del proyecto.
Tabla 15: Product backlog
PRODUCT BACKLOG
ID Ítem Tipo Prioridad
Como administrador, se requiere consultar la relación
R01 de abogados, con lo cual poder identificar los Requerimiento 2
abogados disponibles de procesos judiciales.
Como administrador, se requiere registrar y modificar
R02 el registro de abogador, con lo cual poder agregar o Requerimiento 3
dar de baja abogados.
de abogados por especialidad, con lo cual poder
R03 Requerimiento 3
identificar las especialidades en materia judicial de los
abogados.
82
el registro de abogados por especialidad, con lo cual
R04 Requerimiento 3
poder agregar las especializaciones en el tiempo de
los abogados.
R05 de clientes, con lo cual poder identificar los clientes Requerimiento 2
con procesos en curso.
R06 el registro de clientes, con lo cual poder agregar o Requerimiento 3
subsanar datos de clientes.
R07 de procesos judiciales, con lo cual poder identificar Requerimiento 3
los procesos en curso.
R08 el registro de procesos judiciales, con lo cual poder Requerimiento 4
agregar o subsanar un proceso judicial.
de abogados por proceso judicial, con lo cual poder
R09 Requerimiento 5
identificar los abogados a cargo de los procesos
judiciales.
Como administrador, se requiere asignar y modificar
abogados a un proceso judicial, con lo cual poder
R10 Requerimiento 5
habilitar al abogado para realizar el seguimiento del
proceso judicial.
Como abogado, se requiere consultar la relación de
R11 procesos judiciales asignados, con lo cual poder Requerimiento 5
identificar los procesos judiciales a cargo.
Como abogado, se requiere consultar la relación de
entradas judiciales por proceso judicial asignado, con
R12 Requerimiento 5
lo cual poder llevar el control y seguimiento de la
evolución del proceso judicial en el tiempo.
Como abogado, se requiere registrar y modificar el
registro de entrada judicial de un proceso asignado,
R13 con lo cual poder llevar el seguimiento de la Requerimiento 5
resolución de las etapas del proceso judicial
asignado.
Como abogado, se requiere tener una interface a la
aplicación CEJ desde el sistema, con lo cual poder Requerimiento
R14 2
consultar el expediente judicial electrónico del / Mejora
proceso judicial.
83
Como abogado, se requiere tener una interface a la
aplicación SINOE desde el sistema, con lo cual poder Requerimiento
R15 2
consultar la casilla electrónica judicial asignada al / Mejora
abogado.
Como SYSADMIN, se requiere realizar el
Requerimiento
mantenimiento de los estados del sistema, con lo cual
R16 / 4
poder consultar, registrar, modificar y utilizar los
Mantenimiento
registros de estados en el sistema.
Requerimiento
mantenimiento de los tipos de juzgados, con lo cual
R17 / 4
Mantenimiento
registros de tipos de juzgados en el sistema.
Requerimiento
mantenimiento de los distritos judiciales, con lo cual
R18 / 4
Mantenimiento
registros de distritos judiciales en el sistema.
Requerimiento
mantenimiento de los órganos jurisdiccionales, con lo
R19 / 4
cual poder consultar, registrar, modificar y utilizar los
Mantenimiento
registros de órganos jurisdiccionales en el sistema.
Requerimiento
mantenimiento de las dependencias judiciales, con lo
R20 / 4
Mantenimiento
registros de dependencias judiciales en el sistema.
Requerimiento
mantenimiento de las materias judiciales, con lo cual
R21 / 44
Mantenimiento
registros de materias judiciales en el sistema.
Requerimiento
mantenimiento de los departamentos del ubigeo, con
R22 / 4
lo cual poder consultar, registrar, modificar y utilizar
Mantenimiento
los registros de distritos del ubigeo en el sistema.
Requerimiento
mantenimiento de las provincias del ubigeo, con lo
R23 / 4
Mantenimiento
registros de provincias del ubigeo en el sistema.
Requerimiento
mantenimiento de los distritos del ubigeo, con lo cual
R24 / 4
Mantenimiento
registros de distritos del ubigeo en el sistema.
84
mantenimiento de los tipos de documentos de Requerimiento
R25 identidad, con lo cual poder consultar, registrar, / 4
modificar y utilizar los registros de tipos de Mantenimiento
documentos de identidad en el sistema.
Requerimiento
mantenimiento de los tipos de persona, con lo cual
R26 / 4
Mantenimiento
registros de tipos de persona en el sistema.
mantenimiento de los tipos de documentos legales, Requerimiento
R27 con lo cual poder consultar, registrar, modificar y / 4
utilizar los registros de tipos de documentos legales Mantenimiento
en el sistema.
Requerimiento
mantenimiento de los perfiles de usuario, con lo cual
R28 / 4
Mantenimiento
registros de perfiles de usuario en el sistema.
Requerimiento
mantenimiento de los usuarios, con lo cual poder
R29 / 5
consultar, registrar, modificar y utilizar los usuarios en
Mantenimiento
el sistema.
Como usuario, se requiere ingresar mis credenciales
de usuario para acceder al sistema, con lo cual poder Requerimiento
R30 3
acceder a las funcionalidades asignadas según el / Seguridad
perfil de usuario.
Como administrador, se requiere realizar reportes Requerimiento
R31 según criterios, con lo cual poder obtener información / Mejora / 4
relevante para la toma de decisiones. Reporte
Como administrador, se requiere realizar cuadros Requerimiento
R32 estadísticos según criterios, con lo cual obtener / Mejora / 4
información relevante para la toma de decisiones. Reporte
Fuente: Propia
85
3.5.2. Sprint backlog
El sprint backlog del sistema de seguimiento de procesos judiciales, describe
cómo el equipo de trabajo va a implementar los requisitos durante los sprints
definidos en el plan de trabajo. Las tareas en el sprint backlog son tomadas
por los miembros del equipo para su desarrollo durante la iteración. Ver
Anexo 6.
3.5.3. Modelo de casos de uso del sistema
3.5.3.1. Actores del sistema

La solución propuesta presenta cuatro actores, los cuales interactuarán el
sistema una vez desarrollado. A continuación, la tabla 16 presenta la
relación de actores del sistema.
Tabla 16: Lista de actores del sistema
LISTA DE ACTORE DEL SISTEMA
Actor del sistema Descripción

Es el rol responsable de la defensa o representación del cliente y
pertenecer a una materia judicial. Es el responsable de la
AS_abogado información confiada por el cliente, llevando el seguimiento del
caso del cliente por medio del sistema durante el desarrollo del
proceso y sus instancias.
Es el rol responsable de la gestión del negocio y de la toma de
decisiones referente a los procesos. Asigna a los abogados para la
AS_administrador
atención de los casos y lleva el control del desarrollo de los
procesos mediante revisiones y reportes.
Es el rol encargado de la administración de los datos maestros del

AS_SYSADMIN sistema, así como la administración de los usuarios y control de los
de acceso a la información.
Es el rol ejecutado por cada usuario en el momento en que ingresa

al sistema y ejecuta la pantalla inicial de seguridad. Es el rol que
AS_Usuario identifica el perfil de usuario al ingresar las credenciales de
usuario, desplegando las opciones correspondientes según el
perfil.
Fuente: Propia
86
La figura 19 muestra los actores que interactúan con el sistema.
Figura 19: Actores del sistema

Fuente: Propia
3.5.3.1. Paquetes del sistema

El sistema propuesto está compuesto de cinco módulos, los cuales se
encuentra representados en los paquetes descritos a continuación.
a. Paquetes de gestión
El paquete de gestión se encarga del registro, consulta y modificación de la
información de los clientes, abogados y procesos judiciales, así como de la
asignación de un abogado para la atención de un proceso y los permisos
para el seguimiento y control del mismo.
b. Paquete de seguimiento
El paquete de seguimiento se encarga del registro, consulta y modificación
de las entradas inherentes a un proceso para el seguimiento del mismo
reflejando su evolución en el tiempo; así como la actualización y
modificación del estado del proceso durante su desarrollo.
c. Paquete de mantenimiento
El paquete de mantenimiento se encarga del manejo maestro del sistema, es
decir los mantenimientos básicos para el mismo, los que incluyen: ubigeo,
distritos judiciales, materia judicial, etapas judiciales, entre otros.
87
d. Paquete de reportes
El paquete de reportes se encarga de la consulta y generación de reportes e
indicadores relacionados a los procesos judiciales para el control y toma de
decisiones sobre los procesos judiciales en la firma de abogados.
e. Paquete de seguridad
El paquete de seguridad se encarga de la regulación y mantenimiento del
acceso al sistema mediante la asignación de perfiles y credenciales de
usuarios, que limiten el nivel de acceso e interacciones con el sistema.
La figura 20 muestra el agrupamiento paquetes y la relación entre los estos

en el sistema.
Diagrama de Paquetes
Reportes Gestión
Seguridad
Seguimiento Mantenimiento
Figura 20: Módulos del sistema: Diagrama de paquetes

Fuente: Propia
88
3.5.3.2. Diagrama de casos de uso del sistema.
Figura 21: Casos de uso del sistema

Fuente: Propia
3.4.4. Modelo de datos

En base a lo definido anteriormente se obtiene el modelo de datos de la
solución propuesta. A continuación, la figura 22 muestra el diagrama de base
de datos que se ha definido para el desarrollo del proyecto, en el mismo se
representa las principales entidades para el desarrollo de la solución
propuesta.
89
Figura 22: Modelo de base de datos
Fuente: Propia
90
3.4.5. Arquitectura de software
La arquitectura de software desarrollada en el proyecto será de tipo cliente-
servidor. El cliente es la aplicación que será implementada en el lugar donde
se encuentra la empresa. Se desarrollará una sola aplicación integrada, en
la que solo se permitirá el acceso a los usuarios registrados en el sistema y
a las áreas a las cuales tengan acceso autorizado empleando un solo
servidor centralizado.
Capas de la arquitectura de software
a. Capa de presentación
Es la capa responsable de presentar la interfaz gráfica y se caracteriza por
ser amigable para el usuario. Asimismo, esta capa se comunica únicamente
con la capa de negocio.
En esta capa se encuentra la aplicación web que está dedicada a la

administración del sistema de Control y Seguimiento de Procesos Judiciales,
la cual estará conformada por las pantallas de presentación al usuario.
b. Capa de lógica de negocio

Es la capa que agrupa las funcionalidades del sistema. Se comunica con la
capa de presentación, para recibir las solicitudes y devolver resultados, y
con la capa de datos interactuando con el gestor de base de datos.
En esta capa se encuentran las funcionalidades del sistema, las cuales se

encuentran codificadas en lenguaje de programación PHP. Estas se
encuentran agrupadas en paquetes para garantizar un mejor desempeño de
la aplicación y son ejecutadas en el servidor AWS Cloud, pudiendo acceder
al origen de datos mediante consultas.
91
c. Capa de acceso a datos
Esta capa permite saber cómo está distribuido el esquema de base de datos,
así como saber cómo será la relación entre tablas y su implementación
física. Está formada por uno o más gestores de base de datos, reciben
solicitudes de almacenamiento o recuperación de información desde la capa
de negocio.
A nivel del sistema, el desarrollo de la base de datos estará dado en MySql.
A continuación, la figura 23 muestra los componentes arquitectura cliente-

servidor del sistema, agrupados.
Figura 23: Capas de la arquitectura de cliente-servidor

Fuente: Propia
92
3.4.6. Arquitectura de sistemas
Figura 24: Capas de la arquitectura del sistema

Fuente: Propia
3.4.7. Vista de despliegue
Figura 25: Capas de la arquitectura de cliente-servidor

Fuente: Propia
93
3.6. SPRINTS
3.6.1. Historias de usuario

Una vez realizada la distribución y división del desarrollo del proyecto en las
diversas iteraciones SPRINTS, se han identificado las historias de usuarios
en relación a los requerimientos obtenidos en el product backlog y el sprint
backlog siendo las siguientes a corroborar con los usuarios.
La tabla 17 presenta la relación de historias de usuario por cada actor del

sistema.
Tabla 17: Relación de historias de usuario
RELACION DE HISTORIAS DE USUARIO

Actor Historia de usuario
Administrador del sistema Control de las tablas maestras
Administrador del sistema Control de usuarios
Usuarios Autenticar usuarios
Administrador Administrar clientes
Administrador Administrar abogados
Administrador Asignar especialidad
Administrador Administrar procesos
Administrador Asignar abogados a procesos
Abogado Consultar proceso judicial asignado
Abogado Administrar entradas judiciales
Abogado Subir documentos judiciales
Abogado Interface a aplicaciones
Administrador Generar reportes
Fuente: Propia
3.6.2. Priorización de historias de usuario

Una vez identificadas las historias de usuario, se realiza la priorización de las
historias, identificando el tiempo invertido por cada una de ellas en relación
al desarrollo.
94
La tabla 18 presenta la priorización y valoración de las historias de usuario
Tabla 18: Priorización de historias de usuario
PRIORIZACION DE HISTORIAS DE USUARIO
0.4 0.3 0.2 0.1

Nº ACTOR HISTORIA DE USUARIO IMPORTANCIA COMPLEJIDAD RIESGO IMPACTO TOTAL SPRINT TIEMPO SPRINT - DIAS
1 Administrador del Sistema Control de las Tablas Maestras 8 5 6 10 6.9 1 12
2 Administrador del Sistema Control de Usuarios 8 5 6 10 6.9 4
2
3 Usuarios Autenticar Usuarios 6 4 7 8 5.8 1
4 Administrador Administrar Clientes 6 5 5 6 5.5 2
5 Administrador Administrar Abogados 6 5 6 8 5.9 2
6 Administrador Asignar Especialidad 6 5 5 6 5.5 3 3
7 Administrador Administrar Procesos 8 6 6 10 7.2 2
8 Administrador Asignar Abogados a Procesos 10 7 6 8 8.1 3
9 Abogado Consultar Proceso Judicial Asignado 6 6 5 6 5.8 2
10 Abogado Administrar Entradas Judiciales 8 6 6 8 7 3
4
11 Abogado Subir documentos judiciales 6 5 5 6 5.5 2
12 Abogado Interface a aplicaciones 5 6 5 4 5.2 1
13 Administrador Generar Reportes 5 8 5 4 5.8 5 8
Fuente: Propia
95
3.6.3. SPRINT 1
Historia de usuario
Número: 001 Nombre historia de usuario: Control de tablas maestras
Usuario: SYSADMIN
Prioridad en negocio: Alta
(Alta / Media / Baja)
Riesgo en desarrollo: Medio
(Alto / Medio / Baja)
Descripción:
El administrador del sistema podrá realizar el control de las tablas maestras
del sistema para la gestión interna y funcionamiento de los módulos. El
administrador del sistema podrá registrar, actualizar, modificar y eliminar los
datos relacionados a las tablas maestras del sistema: estados del sistema,
tipos de juzgados, distritos juridiciales, órganos jurisdiccionales,
dependencias judiciales, etapas judiciales, ubigeo, tipos de documento de
identidad, tipo de documento judicial, tipo de persona
Observaciones:
El administrador del sistema hará el registro de los datos mediante ingreso
en consulta directa a la base de datos, y posteriormente mediante
parametrización dentro del módulo de mantenimiento respectivo
96
3.6.4. SPRINT 2
Historia de usuario
Número: 002 Nombre historia de usuario: Control de usuarios
Usuario: SYSADMIN
Riesgo en desarrollo: media
(Alto / Medio / Bajo)
Descripción:
El administrador del sistema podrá administrar los perfiles de usuario y los
usuarios del sistema, asimismo éste al registrar un usuario podrá realizar la
asignación de los perfiles de usuario, asignando el perfil correspondiente,
determinando el nivel de accesos y permisos a la información que el usuario
pueda manejar en su sesión.
Observaciones:
Historia de usuario
Número: 003 Nombre historia de usuario: Autenticar usuario
Usuario: Usuario
Descripción:
El usuario ingresará sus credenciales para autenticarse en el sistema,
verificado las credenciales con los registros existentes en la base de datos,
despliega los accesos y opciones para el usuario según su perfil. Para
confirmar la identidad del usuario se solicitan usuario y contraseña.
Observaciones:
Tras tres intentos fallidos de ingresar un usuario, se notificará una alerta al
administrador del sistema indicando el intento de ingreso.
97
3.6.5. SPRINT 3
Historia de usuario
Número: 004 Administrar cliente
Usuario: Administrador
Prioridad en negocio: Media
Riesgo en desarrollo: Media
Descripción:
El administrador podrá administrar los clientes de los procesos judiciales,
consultando la relación de clientes por default y por filtros, así como
visualizar información relevante de los mismos. El registro de los clientes
será por formulario, ingresando los datos relevantes como nombre / razón
social, tipo de persona, documento de identidad, entre otros., así como datos
de contacto como número telefónico, dirección, correo, otros.
Observaciones:
Tanto durante el registro, como en la modificación de la información del
cliente, se crearán los logs de seguridad correspondientes, identificando el
usuario y la fecha de registro o modificación.
Historia de usuario
Número: 005 Administrar abogados
Riesgo en desarrollo: media
Descripción:
El administrador podrá administrar los abogados del estudio de abogados,
pudiendo consultar la relación de abogados por default y por filtros, así como
visualizar información relevante de los mismos. El registro de los abogados
será por formulario, ingresando los datos relevantes como usuario, nombre,
98
documento de identidad, código de colegiatura, entre otros., y de contacto
como número, dirección, correo, otros.
Observaciones:
abogado, se crearán los logs de seguridad correspondientes, identificando el
usuario y la fecha de registro o modificación.
Historia de usuario
Número: 006 Asignar especialidad
Descripción:
El administrador registrará la relación de especialidades en materias judicial
de los abogados de la firma de abogados. Una vez especificado la materia
judicial, se podrá visualizar la lista de abogados y sus especialidades.
Observaciones:
El abogado puede tener múltiples especialidades en materia jurídica, lo
cual le posibilita tomar una variedad de casos y realizar el seguimiento
correspondiente. Asimismo, la identificación del abogado por especialidad,
ayuda en la generación de reportes asociados a esta información.
Historia de usuario
Número: 007 Administrar proceso
Prioridad en negocio: Alto
99
Descripción:
El administrador podrá administrar los procesos judiciales del estudio de
abogados. Este podrá consultar la relación de procesos por default y por
filtros, visualizando información relevante de los mismos. El registro de los
procesos judiciales será por formulario, ingresando los datos relevantes
como distrito judicial, órgano jurisdiccional, dependencia, fecha de ingreso
al juzgado; datos de los litigantes como demandante, domicilio legal del
demandante, demandado, domicilio legal del demandado; y otros datos
como expediente, materia, objeto, etapa, sumilla, entre otros.
Observaciones:
abogado, se crearán los logs de seguridad correspondientes, identificando
el usuario y la fecha de registro o modificación.
Historia de usuario
Número: 008 Asignar especialidad
Prioridad en negocio: Alto
Descripción:
El administrador realizará la asignación de los abogados a los procesos
judiciales. La asignación del abogado se efectúa acorde a la materia judicial
del caso del proceso. Una vez especificado la materia judicial, se filtrarán
acorde a la lista de abogados, los abogados disponibles según la materia
para la asignación del caso y otorgamiento de los permisos respectivos.
Observaciones:
El registro del proceso esta anidado al cliente y al abogado, una vez
asignado el abogado y registrado el proceso, se levantan los permisos y el
abogado tiene control de la gestión del detalle del proceso judicial durante
el tiempo de ejecución de éste.
100
3.6.6. SPRINT 4
Historia de usuario
Número: 009 Consultar proceso judicial
Usuario: Abogado
Riesgo en desarrollo: Bajo
Descripción:
El abogado realizará la consulta de los procesos activos asignados a su
control mediante una consulta al sistema, la cual obtendrá el registro de los
procesos asociados al abogado para su control y seguimiento con datos
relevantes como la etapa actual del proceso judicial, el objeto, la materia, el
cliente, entre otros.
Observaciones:
Historia de usuario
Número: 010 Administrar entradas judiciales
Descripción:
El abogado podrá administrar las entradas judiciales de un proceso judicial
asignado. Este podrá consultar la relación de entradas judiciales de los
procesos judiciales asignados y por filtros, visualizando información
relevante de los mismos. El registro de las entradas judiciales será por
formulario, ingresando los datos relevantes como proceso, nro. de entrada,
101
sumilla, fecha de registro, entre otros.; datos de anexos como expediente,
tipo de documento judicial, documento judicial, sumilla, observación, entre
otros.
Observaciones:
Las entradas procesales son registradas durante todo el ciclo de vida el
proceso judicial, y están asociadas a las etapas procesales del mismo,
pudiendo haber varias por cada etapa, en el cual se indica el avance del
proceso e información relevante para el seguimiento.
Historia de usuario
Número: 011 Subir documentos judiciales
Usuario: Abogado
Riesgo en desarrollo: Bajo
Descripción:
El abogado durante el registro de la entrada judicial podrá anexar
documentación asociada al proceso judicial y almacenarla en formato PDF,
Excel, Word.
Observaciones:
La documentación anexada podrá ser consultada durante la consulta de la
relación de entradas judiciales, obteniendo los datos de estas y los
documentos anexos de haber.
102
Historia de usuario
Número: 012 Interface a aplicaciones
Riesgo en desarrollo: Baja
Descripción:
El abogado podrá consultar otras aplicaciones del sistema de justicia como
el CEJ (Consulta de Expedientes Judiciales) y el SINOE (Sistema de
Notificaciones Electrónicas) mediante interface con la aplicación,
visualizándose la información dentro de las ventanas de la sesión del
usuario, pudiendo interactuar con estas.
Observaciones:
3.6.7. SPRINT 5
Historia de usuario
Número: 013 Consultar proceso judicial
Usuario: Abogado
Descripción:
El abogado realizará la consulta de los procesos activos asignados a su
control mediante una consulta al sistema, la cual obtendrá el registro de los
procesos asociados al abogado para su control y seguimiento.
Observaciones:
103
3.7. Desarrollo del business intelligence
Para el desarrollo del business intelligence, se utilizará como referente el
marco de trabajo propuesta por Ralph Kimball, explicado en el capítulo III. La
metodología de Ralph Kimball, es una metodología que posee muchas
experiencias exitosas en el desarrollo e implementación de soluciones de
business intelligence y provee procesos específicos que contribuirán con el
ciclo del desarrollo del proyecto.
3.7.1. Planificación del proyecto de business intelligence

- Objetivo. Ver Introducción. Objetivos específicos.
- Alcance. Ver Introducción. Alcance.
- Personal. Ver 2.1.3. Recursos humanos.
3.7.2. Definición de los requerimientos del negocio

Se presenta los requerimientos de negocio que se han podido identificar
durante la entrevista y levantamiento de información del estudio de
abogados.
Estos requerimientos representan las diversas necesidades específicas de

los actores del negocio, los cuales, pueden ser resueltos con uno o varios
reportes.
- Número de casos por periodo
- Número de casos por distrito judicial
- Número de casos por materia y objeto
- Delitos más frecuentes
- Clientes más frecuentes
- Número de delitos por periodo
- Histórico de casos
104
3.7.3. Modelo dimensional
La elaboración del modelo dimensional de la data mart se realiza mediante
el análisis de los requerimientos de negocio obtenidos, identificando la
información que el negocio desea obtener.
El diseño del modelo de datos para soportar estos análisis se hace mediante
la identificación de las dimensiones y tomando como referencia el modelo de
datos del sistema transaccional para su construcción.
Dimensiones
Las dimensiones que conforman la data mart son:
- Tiempo
- Cliente
- Abogado
- Objeto
- Etapa
- Dependencia
105
3.7.3.1. Dimensión Tiempo
a. Descripción
Dimensión que almacena los parámetros de fechas que la data mart usará
para filtrar la información relevante.
b. Jerarquía
Contiene el día, mes, año y el número de semanas en el año.
Tabla 19: Atributos de la dimensión tiempo por niveles
Nivel Atributo
Nivel 1 Año
Nivel 2 Semestre
Nivel 3 Trimestre
Nivel 4 Mes
Nivel 5 Día
Fuente: Propia
c. Atributos
Tabla 20: Descripción de los atributos de la dimensión tiempo
Contenido
Atributo Valor por
Descripción Formato
Defecto
Llave primaria de la dimensión CADENA DE Ninguno
Id_Tiempo
tiempo CARACTERES
Fecha Contiene la fecha entera DATETIME Ninguno
Año Contiene el número del año ENTERO Ninguno
Semestre Contiene el número del semestre ENTERO Ninguno
Trimestre Contiene el número del trimestre ENTREO Ninguno
Día Contiene el número del día en el mes ENTERO Ninguno
Fuente: Propia
106
3.7.3.2. Dimensión Cliente
a. Descripción
Dimensión que contiene los datos de los clientes que solicitan los servicios
de defensa o representación legal del estudio de abogados.
b. Jerarquía
Datos generales del cliente.
Tabla 21: Atributos de la dimensión cliente por niveles
Nivel Atributo
Nivel 1 IdCliente
Nivel 2 IdTipoPersona
Nivel 2 IdDepartamento
Nivel 3 IdProvincia
Nivel 4 IdDistrito
Fuente: Propia
c. Atributos
Tabla 22: Descripción de los atributos de la dimensión tiempo
Contenido
Atributo Valor por
Defecto
Llave primaria de la
Id_Cliente CADENA DE CARACTERES Ninguno
dimensión cliente
IdCliente Código del cliente CADENA DE CARACTERES Ninguno
IdDepartamento Código del departamento CADENA DE CARACTERES Ninguno
IdProvincia Código de provincia CADENA DE CARACTERES Ninguno
Código de tipo de
IdTipoPersona CADENA DE CARACTERES Ninguno
persona
Nombre Nombre del cliente CADENA DE CARACTERES Ninguno
Descripción del
Departamento CADENA DE CARACTERES Ninguno
departamento
Provincia Descripción de provincia CADENA DE CARACTERES Ninguno
Descripción de tipo de
TipoPersona CADENA DE CARACTERES Ninguno
persona
Fuente: Propia
107
3.7.3.3. Dimensión Abogado
a. Descripción
Dimensión que contiene los datos de los abogados que prestan servicios en
el estudio de abogados.
b. Jerarquía
Datos generales del abogado.
Tabla 23: Atributos de la dimensión abogado por niveles
Nivel Atributo
Nivel 1 Idabogado
Fuente: Propia
c. Atributos
Tabla 24: Descripción de los atributos de la dimensión abogado
Contenido
Atributo Valor por
defecto
Id_abogado CADENA DE CARACTERES Ninguno
dimensión abogado
Idabogado Código del abogado CADENA DE CARACTERES Ninguno
Nombre Nombre del abogado CADENA DE CARACTERES Ninguno
Casilla electrónica del
CAL CADENA DE CARACTERES Ninguno
abogado
Fuente: Propia
108
3.7.3.4. Dimensión Objeto
a. Descripción
Dimensión que contiene las materias judiciales y los objetos del delito que se
incurren en el caso.
b. Jerarquía
Datos generales del objeto.
Tabla 25: Atributos de la dimensión objeto por niveles
Nivel Atributo
Nivel 1 IdObjeto
Nivel 2 IdMateria
Fuente: Propia
c. Atributos
Tabla 26: Descripción de los atributos de la dimensión objeto
Contenido
Atributo Valor por
defecto
Id_Objeto CADENA DE CARACTERES Ninguno
dimensión objeto
IdObjeto Código del objeto CADENA DE CARACTERES Ninguno
IdMateria Código de materia CADENA DE CARACTERES Ninguno
Objeto Descripción de la objeto CADENA DE CARACTERES Ninguno
Materia Descripción de materia CADENA DE CARACTERES Ninguno
Fuente: Propia
109
3.7.3.5. Dimensión Etapa
a. Descripción
Dimensión que contiene las etapas judiciales en las que incurre un caso.
b. Jerarquía
Tabla 27: Atributos de la dimensión etapa por niveles
Nivel Atributo
Nivel 1 IdEtapa
Fuente: Propia
c. Atributos
Tabla 28: Descripción de los atributos de la dimensión etapa
Contenido
Atributo Valor por
defecto
Llave primaria de la CADENA DE Ninguno
Id_Etapa
dimensión etapa CARACTERES
Código de la etapa CADENA DE Ninguno
IdEtapa
judicial CARACTERES
Descripción de la CADENA DE Ninguno
Descripcion
etapa judicial CARACTERES
Fuente: Propia
110
3.7.3.6. Dimensión Dependencia
a. Descripción
Dimensión que contiene los datos de las dependencias, tipo de juzgado,
órganos jurisdiccionales y distritos judiciales.
b. Jerarquía
Tabla 29: Atributos de la dimensión dependencia por niveles
Nivel Atributo
Nivel 1 IdDependencia
Nivel 2 IdTipoJuzgado
Nivel 2 IdOrgano
Nivel 3 IdDistritoJud
Fuente: Propia
c. Atributos
Tabla 30: Descripción de los atributos de la dimensión dependencia
Contenido
Atributo Valor por
defecto
Id_Dependencia CADENA DE CARACTERES Ninguno
dimensión dependencia
IdDependencia Código de dependencia CADENA DE CARACTERES Ninguno
Código de órgano
IdOrgano CADENA DE CARACTERES Ninguno
judicial
Código de distrito
IdDistritoJud CADENA DE CARACTERES Ninguna
judicial
Código de tipo de
IdTipoJuzgado CADENA DE CARACTERES Ninguna
juzgados
Descripción de
Dependencia CADENA DE CARACTERES Ninguna
dependencia
Organo Descripción de órgano CADENA DE CARACTERES Ninguna
Descripción de distrito
DistritoJud CADENA DE CARACTERES Ninguna
judicial
Descripción de tipo de
TipoJuzgado CADENA DE CARACTERES Ninguna
juzgado
Fuente: Propia
111
3.7.3.7. Facts Proceso
a. Descripción
La tabla facts contiene las medidas numéricas del negocio, agrupadas
utilizando sumas, promedios, máximos, mínimos, etc.
Contiene las llaves de las dimensiones y medidas levantadas en etapas
anteriores del proyecto de acuerdo a los requerimientos.
b. Granularidad
Tabla 31: Descripción de la granularidad
Nombre de Llave
N° Descripción
dimensión primaria
1 Tiempo Fecha en la que se realizó el caso Sí
Cliente al que se le dio el servicio de defensa o
2 Cliente Sí
representación
3 Abogado Abogado que realizó la defensa o representación Sí
4 Objeto Objeto del delito de los casos Sí
5 Etapa Etapa en la que incide el caso Sí
6 Dependencia Dependencia en donde se desarrolla el caso Sí
Fuente: Propia
c. Atributos
Tabla 32: Descripción de los atributos
N° Nombre Descripción
1 Num_Casos_Ingresados N° de casos ingresados
2 Num_Casos_Terminados N° de casos terminados
3 Num_Casos_Nuevos N° de casos nuevos
4 Num_Casos_Seguimiento N° de casos en seguimiento
5 Num_Casosxabogado N° de casos por abogado
6 Num_CasosxMateria N° de casos por materia
7 Num_CasosxObjeto N° de casos por objeto
8 Num_Delitos_Atendidos N° de delitos atendidos
Fuente: Propia
112
3.7.4. Diseño físico
El modelo estrella diseñado en el proyecto consiste en siete tablas, una tabla
de hechos Fact_Procesos y seis tablas de dimensiones llamados
dim_tiempo, dim_cliente, dim_abogado, dim_objeto, dim_etapa,
dim_dependencia.
La figura 26 muestra el modelo estrella del diseño físico de la data mart.
Figura 26. Modelo eestrella de la data mart

Fuente: Propia
113
3.7.5. Diseño y presentación de datos
El proceso de ETL es desarrollado integrando el diseño del modelo en la
base de datos con la herramienta Jaspersoft ETL, en la cual se elaboran los
jobs necesarios para realizar el poblamiento de la data mart.
3.7.5.1. Carga de dimensiones
a. Dimensión Tiempo
Para poblar la dim_tiempo, se consulta mediante conexión SQL los datos
OLTP de los registros de los procesos obteniéndose la fecha base, sobre la
cual se hacen los cálculos, obteniendo el año, mes y día del año; y mediante
fórmulas se obtiene el periodo por trimestre y semestre.
Los datos obtenidos son almacenados en una tabla temporal y luego
transformados e ingresados en la dimensión tiempo.
La figura 27 muestra el job de carga para la dimensión tiempo.
Figura 27: JOB de carga de la dimensión tiempo

Fuente: Propia
Para realizar la lectura de las dimensiones abogado, cliente, dependencia,

objeto y materia, los datos son obtenidos mediante consulta SQL al OTLP
necesarios para la carga de la dimensión, siendo transformados e
ingresados en la dimensión abogado, cliente, dependencia, objeto y materia,
respectivamente.
En las figuras 28, 29, 30, 31 y 32, se muestran los jobs de carga de las
dimensiones.
114
b. Dimensión abogado
Figura 28: JOB de carga de la dimensión abogado

Fuente: Propia
c. Dimensión cliente
Figura 29: JOB de carga de la dimensión cliente

Fuente: Propia
d. Dimensión dependencia
Figura 30: JOB de carga de la dimensión dependencia

Fuente: Propia
115
e. Dimensión objeto
Figura 31: JOB de carga de la dimensión objeto

Fuente: Propia
f. Dimensión etapa
Figura 32: JOB de carga de la dimensión etapa

Fuente: Propia
116
3.7.5.2. Proceso ETL
La figura 33 muestra el proceso ETL desarrollado para la carga de la tabla
facts_procesos de la data mart.
Figura 33: Proceso ETL

Fuente: Propia
Las actividades que lleva a cabo el proceso son:

- Inicio: inicia la ejecución del proceso ETL realizando la conexión con la
base de datos.
- Carga de dimensiones: dim_tiempo, dim_dependencia, dim_etapa,
dim_objeto, dim_abogado, dim_cliente obteniendo los datos de las
dimensiones.
- Carga de tabla de hechos procesos: transformación y transferencias
de los datos a la tabla facts_procesos.
117
3.7.6. Diseño de la arquitectura técnica de business intelligence
A partir de la ejecución del proceso ETL, se desarrolla una data mart que
permita obtener información consolidada de los procesos judiciales del
estudio de abogados, generando reportes que ayuden en la toma de
decisiones y contribuyan al cumplimiento de sus objetivos. La publicación de
estos reportes será realizada en un entorno web que permita a los usuarios
acceder a la información desde cualquier navegador mediante una conexión
a internet.
La figura 34 muestra los componentes de la arquitectura de business

intelligence del sistema.
Figura 34: Arquitectura de inteligencia de negocios del sistema

Fuente: Propia
3.7.7. Especificación de aplicaciones para usuarios

Los reportes y el análisis OLAP han de ser desarrollados para el
administrador del estudio de abogados, usuario que ejecuta un rol más
estratégico y requiere de información de más alto nivel. Asimismo, los
reportes desarrollados para este usuario, permitirá cambiar los parámetros y
con enfoques en cuadros y drill down.
3.7.8. Desarrollo de aplicaciones para usuarios finales

Tomando en cuenta el punto anterior, definimos que el usuario final de los
reportes al jefe del estudio de abogados, sobre el cual se construirán vistas y
reportes basados en la información de los requerimientos de negocio
recopilados anteriormente.
118
Vistas y reportes
Para la generación de los reportes se han considerado el desarrollo de
consultas agrupadas y dentro de cada grupo poder visualizar una serie de
reportes.
La tabla 19 presenta la relación de vistas y reportes del sistema.
Tabla 33: Relación de vistas y reportes
VISTAS Y REPORTES
Tema Reporte
Casos por periodo
Análisis de casos Casos por dependencia judicial
Histórico de casos
Delitos más frecuentes
Delitos por objeto
Análisis de delitos
Delitos por materia
Delitos por periodo
Clientes más frecuentes
Análisis de cliente
Variación de ingreso de imputados
Fuente: Propia
3.8. Desarrollo del cloud computing
3.8.1. Amazon Web Services

La nube de AWS proporciona un amplio conjunto de servicios de
infraestructura, como potencia de cómputo, opciones de almacenamiento,
redes y bases de datos, ofertados como una utilidad: bajo demanda,
disponibles en cuestión de segundos y pagando solo por lo que utiliza.
Básicamente, Amazon Web Services se divide en varios servicios que
ofrecen servicios muy concretos. En un servidor compartido/privado todos
estos servicios ya vienen configurados de serie sin tocar prácticamente
nada, lo que pude suponer una dificultad considerable a alguien que no está
acostumbrado a lidiar con administración de servidores y servicios web.
119
La tabla 20 presenta el cuadro comparativo valorado de servidores que
prestan servicios en la nube.
Tabla 34: Análisis comparativo de servidores en cloud
SERVIDORES EN CLOUD
Amazon Web Google

Características iCloud
Services AppEngine
Costo por almacenamiento 8 6 5
Grado de personalización 9 7 6
Disponibilidad del servidor 9 9 8
Velocidad del servidor 9 8 8
Seguridad del servidor 9 9 8
Total 44 39 35
Fuente: Propia
Del análisis comparativo de servidores en la nube, se puede concluir que el

servicio ofrecido por el servidor AWS es el mejor para el alojamiento de la
solución, el cual permita desplegar el código de la aplicación y la base de
datos en MySQL en una instancia de Amazon, asimismo poder almacenar
archivos y documentos como hacer uso de los reportes de business
intelligence.
Servicios del AWS
a. Amazon EC2
- Repositorio en donde se alojará el servidor virtual y donde se podrá
instalar el sistema con la base de datos.
- EC2 cobra por cada hora que se encuentre en funcionamiento el
servidor, así como por ancho de banda utilizado. Sí se quisiera tener
desplegado el servidor en un régimen de 24/7, se tendría que pagar la
cuota máxima, que son una media de 24 x 31 días.
- El costo de EC2, en una instancia t2 small, es de $ 26.28 mensuales y
proporciona una capacidad de almacenamiento de 2Gb.
120
En las figuras 35 y 36, se muestra el despliegue del sistema dentro del
servidor virtual en Amazon EC2.
Figura 35: Despliegue del sistema en el servidor Amazon EC2

Fuente: Amazon EC2
b. Amazon S3
- Repositorio donde serán almacenadas las imágenes y archivos
estáticos digitalizados.
- Depende de la cantidad de espacio en disco que se utilice y del número
de peticiones PUT/POST que se haga al contenido almacenado.
- El costo de S3, es de $0.0408 por Gb, mensual.
121
Figura 36: Despliegue de la base de datos en el servidor Amazon EC2
Fuente: Amazon EC2
122
CAPÍTULO IV:
PRUEBAS Y RESULTADOS
4.1. Pruebas de performance
4.1.1. Parámetros de evaluación

Las evaluaciones que constituyen la batería de pruebas de performance,
buscan el cumplimiento satisfactorio de la integración modular del sistema,
así como dar la conformidad en el nivel de funcionalidad alcanzado y
corroborar los resultados esperados de los mismos.
Entre los parámetros a evaluar se tiene:

- Medición de cumplimiento de funcionalidades de soporte.
- Medición de cumplimiento de las principales funcionalidades
operativas.
- Control, identificación y despliegue de usuarios.
- Evaluación de almacenamiento de datos en las tablas de la base de
datos.
- Evaluación de tiempo de respuesta de consultas en base de datos.
- Evaluación de consulta mediante interface a otras aplicaciones.
- Generación de reportes.
123
4.1.2. Casos de prueba
4.1.2.1. Administrar usuarios
a. Objetivo de la prueba
Verificar que el caso de prueba realiza las validaciones correctas al registrar
un usuario, modificar el registro de un usuario, realizar consultas de los
usuarios y autentificar los usuarios.
b. Data inicial
Tabla 35: Administrar usuarios
Código Estado Usuario que

Tipo de
de Correo del usuario Contraseña del realizó el
perfil
usuario registro registro
U-001 [email protected] abogado 3 1 00001
00003 [email protected] 12345 3 1 00001
00004 [email protected] 12345 3 1 00001
Fuente: Propia
c. CASO PR01 - Registro correcto de un usuario
Tabla 36: Condiciones de entrada del caso PR01
Condición de entrada Valor
Código del usuario U-001

Correo del usuario [email protected]
Contraseña 12345
Tipo de perfil 4
Estado de registro 1
Usuario que realizó el registro 00001
Fuente: Propia
124
Resultado esperado
- El sistema indica que el registro no puede ser ingresado debido a
poseer código repetido.
- El sistema indica que el registro no puede ser registrado debido a la no
existencia del registro de perfil ‘4’.
d. CASO PR02 - Actualización de un usuario
Código del usuario 0004
Contraseña 12345
Tipo de perfil 3
Usuario realizó la modificación 00001
Fuente: Propia
Resultado esperado
- El sistema indica la actualización del registro de estado activo a
inactivo = ‘0’
125
e. CASO PR03 - Autentificar usuarios
Código del usuario 0003
Contraseña 12345
Tipo de perfil 3
Usuario que realizó el registro 00001
Fuente: Propia
Resultado esperado
- El sistema consulta la relación de usuarios en la base de datos e
identifica el registro ingresado.
- El sistema autentifica al usuario y despliega las funcionalidades según
el perfil del registro.
4.1.2.2. Administrar clientes

un abogado, modificar el registro de un abogado, asignar especialidad en
materia judicial al abogado.
b. Data inicial
126
Tabla 39: Administrar clientes
Código Código Tipo

Nombre / Nro. Doc.
de de doc. Correo Número Dirección
razón social Identidad
usuario abogado Id.
Carlos Alberto
ca_mendoza@a +51 Av. Ingenieros
00003 A0001 Mendoza DNI 90182214
bogados.com 955533322 432, La Molina
Montreuil
Pedro Pablo
pp_cisneros@ab +51 Av. Aramburu 863,
00004 A0002 Cisneros DNI 08932469
ogados.com 989366612 San Isidro
Campos
Carlos Av. Salaverry n°
Enrique eninahuaman@g +51 647, piso 8, dpto.
U-001 A-003 DNI 41838968
Ninahuamán mail.com 931985291 802, oficina d -
Ninahuamán Jesús María.
Fuente: Propia
c. CASO PR04 - Registro correcto de un cliente
Código de abogado A-004
Nombre Micaela Rojas Cuadros
Tipo de doc. De identidad DNI
Nro. Documento identidad. 71923558
Correo [email protected]
Número +51 991 352 840
Dirección Av. Paseo de la Republica 3622
Fuente: Propia
Resultado esperado
- El sistema muestra un mensaje de error indicando que el usuario ya se
encuentra asociado a un registro de abogado.
127
d. CASO PR05 - Consulta por filtros
Código de abogado A-003
Nombre Carlos Enrique Ninahuamán Ninahuamán
Tipo de doc. De identidad DNI
Número +51 931985291
Fuente: Propia
Resultado esperado
- El sistema muestra un mensaje de indicando la modificación
satisfactoria del registro.
- El sistema registra el log del usuario que realizó la modificación.
4.1.2.3. Administrar abogados

un abogado, modificar el registro de un abogado y asignar una especialidad
en materia a un abogado.
128
b. Data inicial
Tabla 42: Administrar abogados
Tipo
Código de Nombre / Tipo de Nro. Doc.
doc. Correo Número Dirección
cliente razón social persona Identidad
Id.
JORGE Av. Alfonso
jl_sanchez@ +51
C0000001 LUIS LIMO NATURAL DNI 09163224 Ugarte 1180,
gmail.com 949386552
SANCHEZ Breña.
OLTURSA Av. Aramburu
2006046556 oltursa@cont
C0000002 PERU JURIDICA RUC +51 708 600 1160, San
8 actos.pe
S.A.C. Isidro.
ANDRES Jr. Riobamba
MAURO 231, SMP.
C-000005 NATURAL DNI 08559901 - -
DALENS
SEQUIROS
Fuente: Propia
c. CASO PR06 - Registro correcto de un abogado
Código del usuario C0000004
Nombre / razón social JULIO AMADOR ROJAS SUAREZ
Tipo de persona Natural
Tipo de doc. de identidad DNI
Número +51 505 1412

Fuente: Propia
Resultado esperado
- El sistema indica el correcto registro del cliente.
- El sistema visualiza el registro ingresado en la consulta.
129
Código del usuario -
Nombre / razón social -
Tipo de persona Natural
Tipo de doc. De identidad -
Nro. Documento identidad. -
Estado 1
Fuente: Propia
Resultado esperado
- El sistema consulta los registros en la base de datos y anida los
resultados obtenidos de la consulta individual por cada filtro.
- El sistema muestra la relación de clientes cuyo tipo de persona y
estado concuerdan con los ingresados.
e. CASO PR08 - Asignar especialidad en materia

al abogado
Código del abogado A-003
Materia judicial Civil
Estado 1
Fuente: Propia
130
Resultado esperado
- El sistema muestra un mensaje de indicando el registro satisfactorio de
la especialidad en materia al abogado.
- El sistema registra el log del usuario que realizó el registro.
4.1.2.4. Administrar procesos

un proceso, consultar un proceso judicial y asignar un proceso judicial a un
abogado
b. Data inicial
Tabla 46: Administrar procesos
Código de Etapa Materia Litigante Litigante

Caso Expediente Objeto
proceso judicial judicial demandante demandado
Demanda por
P00000000 Limo - 2- Jorge Luis Limo Liliana Castro
01 Civil Manutención
1 Castro 0000000843 Sánchez Herrera
- Divorcio
Demanda por
incumplimient
DALENS 03510-2015- ANDRES
PJ- o de pagos G4S PERU
- G4S 10 Civil 0-3001-JP- DALENS
0000001 por SAC
PERU LA-01 SEQUIROS
beneficios
sociales
Fuente: Propia
c. CASO PR09 - Registro correcto de un proceso

judicial
Código del proceso P000000003
Caso Arana - PETRO PERU
131
Etapa judicial 08
Materia judicial Laboral
Expediente 2-0000001050
Objeto Honorarios
Litigante demandante Marco Arana Campos

Litigante demandado PETRO PERU S.A.C.
Fuente: Propia
Resultado esperado
- El sistema indica el mensaje de registro satisfactorio de un proceso
judicial, visualizando el registro en la consulta.
Código del proceso -
Materia judicial Penal
Caso -
Etapa judicial -
Estado 1
Fuente: Propia
Resultado esperado
- El sistema muestra la lista vacía tras la consulta en la base de datos
sobre registros que coincidan con los filtros expuestos.
e. CASO PR11 - Asignar procesos judiciales al

abogado
132
Código del proceso judicial P000000003
Código del abogado A-003
Cliente Marco Arana Campos
Fecha de inicio 03/06/2016
Etapa judicial 01
Fuente: Propia
Resultado esperado
- El sistema muestra un mensaje de indicando el registro satisfactorio del
proceso judicial asociado al abogado.
- El sistema registra en base de datos y otorga los permisos para que el
abogado pueda consultar el proceso judicial.
4.1.2.5. Administrar entradas judiciales

Verificar que el caso de prueba realiza las validaciones correctas al consultar
un proceso asignado, consultar entradas judiciales del proceso, registrar
entradas judiciales y cargar archivos.
b. Data inicial
Tabla 50: Administrar entradas judiciales
Código de Código del Etapa

Fecha de inicio Cliente Estado
abogado proceso judicial
2015-05-22 Jorge Luis Limo

A-003 PJ-0000001 10 1
00:00:00 Sánchez
133
2016-06-03 Marco Arana
A-003 P000000003 1 1
00:00:00 Campos
Fuente: Propia
c. CASO PR12 – Consultar procesos judiciales

asignados
Código del proceso -
Etapa judicial -
Materia judicial -
Expediente -
Cliente -
Estado 1
Fuente: Propia
Resultado esperado
- El sistema realiza la consulta en base de datos obteniendo el usuario
de la sesión, y obtiene la relación de procesos asignados activos del
abogado.
d. CASO PR13 - consultar entradas judiciales
Código del proceso PJ-0000001
Tipo de doc. Judicial -
134
Etapa judicial -
Fecha de registro -
Estado 1
Fuente: Propia
Resultado esperado
- El sistema consulta en base de datos la relación de instancias
judiciales activas del proceso seleccionado, mostrando la lista
correspondiente de instancias adjuntas al proceso judicial.
e. CASO PR14 - registrar instancia judicial
Código del proceso judicial P000000003
Código de instancia procesal A-003

Etapa judicial 01
Sumilla -
Fecha de ingreso 03/06/2016
Expediente 2-0000000651
Tipo de doc. Judicial Demanda
Nro. De hojas 6
Archivo Documento.PDF
Fuente: Propia
Resultado esperado
- El sistema muestra un mensaje de indicando el registro satisfactorio de
la entrada judicial asociado al abogado.
- El sistema carga el documento anexado y lo almacena con una
dirección URL para su posterior vista en la consulta de entradas
judiciales.
135
4.1.2.6. Otras funcionalidades
Verificar que el caso de prueba realiza las conexiones de interface con las
aplicaciones pertenecientes al sistema de justicia CEJ y SINOE, asimismo
validar la generación de reportes de indicadores de gestión.
b. CASO PR15 - Consultar aplicaciones
Condición de
Valor
entrada
Aplicación SINOE / CEJ
Fuente: Propia
Resultado esperado
- El sistema visualiza en la interfaz de la sesión del abogado la interface
con la aplicación SINOE y CEJ.
- El sistema puede realizar interacciones con las aplicaciones
consultadas.
c. CASO PR16 – Generar reportes
Condición de
Valor
entrada
Tipo de Reporte Varios
Fuente: Propia
Resultado esperado
- El sistema recibe el tipo de reporte solicitado, generando el reporte y
siendo mostrado en la interfaz.
136
4.1.3. Matriz de trazabilidad entre casos de uso y casos de
prueba
La tabla 56 presenta la matriz de trazabilidad entre los casos de usos y los
casos de prueba.
Tabla 56: Trazabilidad de casos de uso y casos de prueba
Fuente: Propia
137
4.2. Pruebas de conformidad
4.2.1. Parámetros de evaluación

De acuerdo a los estudios realizados sobre el beneficio que implica el uso de
un sistema de apoyo para el seguimiento de procesos judiciales. La firma de
abogados obtiene beneficios mediante el uso del sistema, pudiendo
facilitarles tareas al automatizar partes del proceso, como también obtener
mejores resultados en la gestión de los procesos del negocio, mediante la
consulta de reportes.
Para cuantificar el beneficio a obtener gracias a la aplicación de la solución

brindada se propone evaluar los parámetros presentados en la tabla 57.
Tabla 57: Parámetros de evaluación
PARÁMETROS DE EVALUACIÓN
Tiempos de ejecución de las tareas
Aprovechamiento de los recursos
Calidad del servicio
Estado de los procesos judiciales
Cantidad de procesos por materia judicial
Cantidad de procesos por objeto según
materia judicial
Fuente: Propia
4.2.2. Encuesta
Se muestra el modelo de encuesta desarrollado junto a los representantes
de los estudios de abogados con las cuales se trabaja para este proyecto
Estudio Ulloa y Naveda y Estudio Enrique Ninahuaman y abogados
independientes, y donde fue desplegado el piloto del sistema. Se realizó la
encuesta a una muestra de 83 abogados colegiados de las especialidades
de penal, civil y laboral, que interactuaron con el sistema.
138
La tabla 58 presenta la encuesta de satisfacción para la evaluación de los
indicadores del sistema.
Tabla 58: Modelo de encuesta al administrador de la firma de abogados
ENCUESTA
1.- ¿Considera usted que el sistema SCSPJ mejora los tiempos de ejecución de las
tareas del proceso de gestión? ¿En qué medida?
o Mejoró entre un 0% a 9%
o Mejoró en más del 50%
2.- ¿Considera usted que el uso del sistema SCPSPJ contribuyó en el aprovechamiento
de los recursos en las acciones de seguimiento de procesos judiciales? ¿En qué
porcentaje?
o Contribuyó entre un 0% a 7%
o Contribuyó en más del 40%
3.- ¿Considera usted que el sistema SCSPJ ha permitido mejorar la calidad del servicio
ofrecido a los clientes? ¿En qué porcentaje?
o Mejoró en más del 25%
4.- ¿Cree usted que el sistema SCSPJ le ha ayudado a sistematizar e integrar los
procesos de registro, control y seguimiento de los procesos judiciales que atienden?
139
¿De qué manera?
o Muy alta.
o Alta.
o Media.
o Baja.
o Muy baja.
5.- ¿El uso de sistema SCSPJ permitió generar reportes y estadísticas que apoyen a la
toma de decisiones del estudio de abogados?
o Genera reportes muy útiles.
o Genera reportes útiles.
o Genera reportes medianamente útiles.
o Genera reportes poco útiles.
o Genera reportes nada útiles.
Fuente: Propia
4.2.3. Cuadro de resultados

Una vez terminado con la encuesta al administrador y a los abogados de los
estudios de abogados con los que se trabajó, y teniendo en cuenta ciertos
parámetros técnicos, se muestra los resultados obtenidos.
Pregunta 1: ¿Considera usted que el sistema SCSPJ mejora los tiempos de

ejecución de las tareas del proceso de gestión?
Tabla 59: Resultados de la pregunta 1
Fuente: Propia
140
Figura 37: Grafica de resultados de la pregunta 1
Fuente: Propia
Se puede observar que el 54.22% de los abogados considera que el sistema

SCSPJ ha ayudado a mejorar los tiempos de ejecución de las tareas del
proceso de gestión de procesos judiciales entre un 30% a 39%.
Pregunta 2: ¿Considera usted que el uso del sistema SCPSPJ contribuyó

en el aprovechamiento de los recursos en las acciones de seguimiento de
procesos judiciales?
Fuente: Propia
141
Fuente: Propia
Se observa que el 33.73% de los abogados considera que el sistema SCSPJ

ha contribuido positivamente en el aprovechamiento de recursos como son
las horas hombre o tiempo de uso en máquina para la ejecución de las
actividades de seguimiento de los procesos judiciales en un 32% a 39%.
Pregunta 3: ¿Considera usted que el sistema SCSPJ ha permitido mejorar

la calidad del servicio ofrecido a los clientes?
Fuente: Propia
142
Fuente: Propia
Se observa que el 50.6% de los abogados encuestados consideran que el

sistema SCSPJ ha permitido mejorar la calidad del servicio que ofrecen a
sus clientes en un 11% a 15%.
Pregunta 4: ¿Cree usted que el sistema SCSPJ le ha ayudado a

sistematizar e integrar los procesos de registro, control y seguimiento de los
procesos judiciales que atienden?
Fuente: Propia
143
Fuente: Propia
Se observa que el 49.4% de los abogados encuestados confirman que el

sistema SCSPJ ha ayudado en la sistematización e integración de los
procesos de registro, control y seguimiento de los procesos judiciales y de
una forma alta y que el 20.48% de los abogados considera que el sistema
les ayudo en una forma muy alta en la sistematización.
Pregunta 5: ¿El uso de sistema SCSPJ permitió generar reportes y

estadísticas que apoyen a la toma de decisiones del estudio de abogados?
Fuente: Propia
144
Fuente: Propia
Se observa que el 79.52% de los abogados encuestados opinan que el

sistema SCSPJ permite generar reportes útiles o muy útiles para la toma de
decisiones para el estudio de abogados.
4.3. Gráficos de reportes e indicadores

Las figuras 42, 43, 44, y 45, muestran los reportes obtenidos del análisis de
los procesos judiciales atendidos por los estudios de abogados, los cuales
serán consultados en el servidor de business intelligence por el
administrador del despacho.
145
4.3.1. Reporte de casos por periodo de ejecución
Figura 42: Cantidad de casos por periodo de ejecución

Fuente: Propia
146
4.3.2. Reporte de delitos por materia en ejecución
Figura 43: Reporte de delito por materia en ejecución

Fuente: Propia
147
4.3.3. Reporte de delitos por materia down drill
Figura 44: Reporte de delitos por materia

Fuente: Propia
148
4.3.4. Análisis de casos en ejecución
Figura 45: Reporte de delitos por materia

Fuente: Propia
149
4.3.5. Matriz de trazabilidad entre reportes y objetivos
La tabla 64 presenta la matriz de trazabilidad entre los objetivos del proyecto
y los reportes que pueden ayudar a alcanzarlos.
Tabla 64: Matriz de trazabilidad entre reportes y objetivos
MATRIZ DE TRAZABILIDAD ENTRE REPORES Y OBJETIVOS

Objetivos Reporte
Proveer el diseño de una
herramienta integral que ayude a Casos por periodo.
Controlar de manera efectiva la
asignación y seguimiento de
Todos los casos registrados como Casos por distrito judicial.
nuevos, en seguimiento y
concluidos por los defensores de
tal manera de contar con
estadísticas y métricas que
permitan observar los volúmenes Relación entre imputados en trámite
de trabajo de los defensores, así y terminados ingresados en los
como tomar acciones correctivas últimos doce meses por distrito
para garantizar la calidad de los judicial.
servicios prestados, optimizando el
uso de los recursos de manera
progresiva.
Delitos terminados con sentencias
Generar consultas, reportes, condenatorias y absolutorias en
estadísticas y métricas que juicio oral por periodo.
permita evaluar, en todo momento, Relación entre prisión preventiva y
los niveles de calidad de trabajo otras medidas cautelares.
del defensor y la estrategia en Nº de salidas alternativas favorables
relación al trabajo desarrollado por por defensor.
cada uno de ellos. Formas de término agrupadas
según categoría de delitos.
150
El porcentaje de absoluciones en
juicio oral de imputados terminados
por esta vía procesal.
Medidas cautelares decretadas por
sexo.
Delitos por sexo.
Delitos por edad.
Proveer a los niveles directivos del
Delitos por periodo.
ministerio de justicia, un
Delitos más frecuentes.
mecanismo capaz de otorgar
Imputados ingresados por distrito
información acerca del avance
Judicial y periodo.
global de la gestión de los
Variación mensual del ingreso de
defensores para cada una de las
Imputados.
áreas de interés, pudiendo
Número de imputados ingresados
establecer métricas comparativas
por sexo y periodo.
entre el avance real de todas las
Número de imputados ingresados
actividades desarrolladas bajo un
por rango de edades.
determinado periodo de tiempo.
Imputados ingresados por distrito
judicial y periodo.
Fuente: Propia
151
CAPÍTULO V:
DISCUSIÓN Y APLICACIÓN
5.1. Discusión
El objetivo de este proyecto fue el realizar una solución de sistemas para
atacar la problemática de la carencia de soluciones y herramientas en las
pequeñas y medianas firmas de abogados, brindando un sistema que
pudiese ayudar a sistematizar y estandarizar los principales procesos de
negocio de una firma de abogados, así como generar información relevante
para el negocio y mejorar el servicio.
Se partió del hito de que si bien ha habido intentos y pequeñas mejoras en la

formalización y sistematización de las instancias que componen el Poder
Judicial, no se ha puesto mucho énfasis en dar soluciones a los terceros que
también participan en el sector, como son los estudios de abogados, entre
otros aspectos que fueron explicados en el Capítulo 1; generando entre
muchas cosas los cuadros de ineficiencia e informalidad que se encuentra
en muchos estudios pequeños.
Para constatar el éxito de la solución, se contó con el apoyo del estudio de

abogados Ulloa y Naveda, ubicad en la Av. Saco Oliveros N°236, en el
distrito de Lince, en la cual se realizó el despliegue y marcha blanca
evaluando los resultados obtenidos durante un mes del periodo de pruebas,
obteniendo los resultados expresados en el Capítulo 4; mostrándose una
mejora en la gestión del negocio y servicio provista por la firma de abogados,
realizándose una transición a un modelo estandarizado utilizando la relación
proceso judicial e instancia procesal (ver reporte de procesos y reporte de
instancia por proceso), y pudiendo identificar puntos relevantes para el
negocio (ver reporte procesos por materia judicial, reporte de clientes
frecuentes, reporte de procesos por objeto de la materia) que en el tiempo
152
conforme se vaya ingresando información al sistema, representará un gran
activo al negocio.
5.2. Aplicación
El desarrollo de la solución su bien fue desplegada en el estudio de
abogados Ulloa y Naveda, fue elaborado bajo el concepto de desarrollar un
sistema estándar que pueda replicarse en otros negocios y ser aprovechado
por la mayor cantidad de usuarios. Asimismo, el sistema es escalable, lo que
significa que se puede seguir mejorando y haciendo más compacto y
alineado a las necesidades de los usuarios finales.
Para finalizar, se pudo comprobar que el sistema es integrable dentro del

sector justicia al desarrollarse efectivamente interfaces con aplicaciones
pertenecientes al sector como lo son el CEJ (sistema de Consulta de
Expediente Electrónico) y el SINOE (Sistema de Notificaciones Electrónicas),
así como la virtualización y digitalización de archivos adjuntos a las
instancias, con lo cual agiliza y libera de papeleos y actividades manuales a
los usuarios del mismo.
153
CONCLUSIONES
Primera : El sistema de control y seguimiento de procesos judiciales

SCSPJ tiene efectos positivos en la eficiencia de los procesos
de control y seguimiento de procesos judiciales en los
estudios de abogados
Segunda: El sistema de control y seguimiento de procesos judiciales

SCSPJ logra una reducción en más de un 30% de los tiempos
requeridos para ejecutar las tareas del proceso de gestión de
los procesos judiciales en el estudio de abogados.
Tercera : El sistema de control y seguimiento de procesos judiciales

SCSPJ logra mejorar el uso de recursos en más de un 30% la
reduciendo las horas-hombre y agilización de las tareas de
seguimiento de procesos judiciales en el estudio de abogados.
Cuarta : El sistema de control y seguimiento de procesos judiciales

SCSPJ tiene efectos positivos en la calidad del servicio
brindado a los clientes del estudio de abogados mejorándolos
en más de un 10%.
Quinta : El sistema de control y seguimiento de procesos judiciales

SCSPJ logra sistematizar e integrar los principales procesos
de negocio en el estudio de abogados.
Sexta : El sistema de control y seguimiento de procesos judiciales

SCSPJ tiene efecto en la generación de reportes y
estadísticas que apoyen en la toma de decisiones del estudio
de abogados.
154
RECOMENDACIONES
Primera : Para garantizar la continuidad en la eficiencia, se sugiere

potenciar un mínimo los servicios de conectividad en el
estudio de abogados con la finalidad no detener el uso
continuo de las funcionalidades del sistema.
Segunda: Para mejorar la reducción de los tiempos, se recomienda

realizar la documentación de los procesos y procedimientos
del negocio definiendo una línea base con la finalidad de
poseer procesos definidos y elaborar los activos del negocio.
Tercera : Para mejorar el uso de los recursos, se sugiere realizar la

toma de tiempos y el cálculo de recursos actualizado de los
procesos del negocio para definir una línea base sobre la cual
contrastar futuras mejoras.
Cuarta : Para mejorar la calidad del servicio, se recomienda

documentar y desarrollar la cartera de servicios para el
Quinta : Los interesados del estudio de abogados en coordinación con

el equipo de desarrollo, deberían proponer requerimientos y
funcionalidades que ayuden a mejorar sus procesos. Estas
funcionalidades serían desarrolladas e integradas en el
sistema facilitando las tareas de los procesos de negocios.
Sexta : Los interesados del estudio de abogados en coordinación con

el equipo de desarrollo, deberían proponer reportes y cuadros
estadísticos que apoyen a la toma de decisiones. Estos
reportes y estadísticas serían desarrollados e integrados en el
sistema generando valor e información relevante para el
negocio.
155
FUENTES DE INFORMACIÓN
Alzamora, M. (1981). Derecho Procesal Civil. Edilli.
Bayona, W., y Sánchez, C. (2016). Sístema automatizado para el

seguimiento de procesos judiciales en un estudio de abogados.
UPC.
Congreso del Perú (2002). Ley Nº 27568, Ley de Modernización del Estado.
Lima, Perú.
Congreso del Perú (1993). Ley Nº 25869, Texto Único Ordenado de la Ley
Orgánica del Poder Judicial. Lima, Perú.
Devis, H. (1984) Teoría General del Proceso. Tomo I. Universidad Buenos

Aires.
El Comercio (08 de Marzo del 2015). Más estudios de abogados españoles

tienen interés en el Perú. Lima. Obtenido de El Comercio:
http://elcomercio.pe/economia/Perú/mas-estudios-abogados-
espanoles-tienen-interes-Perú-noticia-1724260
Fisfálen, M. (2014). Análisis Económico de la Carga Procesal del Poder

Judicial. PUCP.
García, D. (1980). Manual de Derecho Procesal Penal. 7º Edición. Sesator.
Gutiérrez, W. (2015). La Justicia en el Perú. Cinco grandes problemas,

Documento Preliminar, 2014 - 2015. Gaceta Jurídica.
Inmon, B (2005). Building the Data Warehouse. 4º Edición. Editorial Wiley.

EEUU.
156
Kimball, R (2008). The Data Warehouse Lifecycle Toolkit. 2º Edición.
Editorial Wiley. EEUU.
La Ley. (08 de Marzo del 2015). Los abogados en el Perú - Informe Especial.
Lima. Obtenido de La Ley:
http://laley.pe/not/1215/los-abogados-en-el-Perú/
Monroy, J. (1996). Introducción al Proceso Civil. Tomo I. Temis.
Pásara, L. (2004). La enseñanza del Derecho en el Perú: su impacto sobre

la administración de justicia. Lima: Justicia Viva.
Poder Judicial (2010), Informe de Evaluación Anual del Desempeño

Institucional, Lima, Perú.
Poder Judicial (2012). Plan Estratégico de Tecnologías de Información del

Poder Judicial 2012-2016. Lima, Perú.
Osterfeld, S (1993). Suplements of Data Warehousing.
Osterfeld, S. y Pigneur, Y. (2009). Business Model Generator: A Handbook

for Visionares, Game Changers, and Challengers. Editorial Wiley.
Rodríguez, E. (1999). Manual de Derecho Procesal Civil. Editorial Grijley.

Lima, Perú.
Sagastegui, P. (1996). Teoría General del Proceso Judicial. San Marcos.
Semana Económica (08 de Marzo del 2015). Estudios de abogados: ¿Las

próximas empresas multilatinas? Lima. Obtenido de Semana
Económica:
http://semanaeconomica.com/article/management/servicios-
profesionales/145645-estudios-de-abogados-las-proximas-
empresas-multilatinas/
157
Taramona, J. (1999). Derecho Procesal Civil. Lima, Huallaga.
Garimella, K. et al (2008). BPM Basics for Dummies. Special Edition. Wiley.
158
ANEXOS
(consultables solo en versión impresa)
159

Castillo Cerva

Cargado por

Copyright:

Formatos disponibles

Castillo Cerva

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Castillo Cerva

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE INGENIERÍA Y ARQUITECTURA

ESCUELA PROFESIONAL DE INGENIERÍA DE COMPUTACIÓN Y SISTEMAS

SISTEMA DE CONTROL Y SEGUIMIENTO DE PROCESOS

DENNIS WILMER CASTILLO MAMANI

LUIS ALONSO CERVA CABRERA

TESIS PARA OPTAR EL TÍTULO PROFESIONAL DE

INGENIERO DE COMPUTACIÓN Y SISTEMAS

SISTEMA DE CONTROL Y SEGUIMIENTO DE PROCESOS

PARA OPTAR EL TÍTULO PROFESIONAL DE INGENIERO DE

CASTILLO MAMANI, DENNIS WILMER

Dedicamos esta tesis a nuestras familias,

Expreso mi agradecimiento a mi casa de

A mi familia y a todas las personas que

Expreso mi agradecimiento a los tutores

A mi familia por todo el esfuerzo que hicieron

La presente tesis titulada “sistema de control y seguimiento de procesos

Para la ejecución del proyecto, se evaluó el proceso de gestión de los

Se obtuvo como resultado la reducción de tiempo en la ejecución de tareas

Se concluye que la implementación de un sistema para la gestión de los

Palabras clave: mejora de procesos, sistemas de información, procesos

For execution of the proyect, the process of management of the judicial

As a result, the reduction of time in the execution of tasks of the process of

It is concluded that the implementation of a system for the management of

Keywords: process improvement, information systems, judicial processes,

Desde finales de la década de los años noventa, la administración de la

La presente tesis, aborda el desarrollo de una solución de sistemas

El primer capítulo titulado marco teórico, se dan a conocer las soluciones

En el segundo, se presenta la metodología y se dan a conocer el análisis del

En el tercer capítulo titulado desarrollo del proyecto, se da a conocer el

En el cuarto capítulo titulado pruebas y resultados, se dan a conocer la

Finalmente, en el quinto capítulo titulado discusión y aplicación, se

Al final de la tesis, se encuentran las conclusiones y recomendaciones

1.1. Situación problemática

De la misma forma, según un informe publicado por LaLey (2014), en el Perú

En ese sentido, siendo el Perú un país atestado de abogados, se da la

De igual forma, la actual sobre oferta de abogados existentes en el mercado

Esta situación, sumada al constante ingreso de estudios de abogados

1.2. Definición del problema

Los pequeños estudios de abogados carecen de sistemas de información

Para realizar el correcto control y seguimiento de un proceso judicial, es

1.3. Problema general

2.1. Objetivo general

2.2. Objetivos específicos

3.1. Justificación técnica

De igual manera la incorporación de tecnologías como cloud computing e

3.2. Justificación económica

Asimismo, el desarrollo de una solución orientada al grueso que representan

3.3. Justificación social

Finalmente, el desarrollo de una solución con estas características

En su piloto el sistema contemplará solo las dependencias judiciales en el

Finalmente, el sistema incorporará conexiones con las principales

1.1. Antecedentes del proyecto

1.1.1. Otros estudios sobre el tema

Del análisis realizado, se pudo identificar que el desarrollo de una solución

Para abordar esta problemática se tomó como objeto de estudio al estudio

De la ejecución del proyecto se concluye que el desarrollo de un sistema que

Del análisis realizado, se pudieron identificar las diversas causas tanto a

Para abordar esta problemática surgen hipótesis que buscan aminorar la

Del contraste de la hipótesis se concluye que la implantación de TICS para

1.1.2. Soluciones existentes