UNIVERSIDAD NACIONAL DE UCAYALI
FACULTAD DE INGENIERÍA DE SISTEMAS E INGENIERÍA CIVIL
CARRERA PROFESIONAL DE INGENIERÍA DE SISTEMAS

TESIS PARA OPTAR EL TÍTULO PROFESIONAL DE
INGENIERO DE SISTEMAS

PINTO VELA, JUAN MANUEL

PUCALLPA – PERÚ
2019

“TECNOLOGÍA JEE 6 WEB PARA LA GESTIÓN
DE MEMBRESÍA Y LOGÍSTICA INTERNA DE
LA IGLESIA EVANGÉLICA PENTECOSTAL
MISIONERA ‘EL TABERNÁCULO’”
ii

iii

vii

DEDICATORIA

En primer lugar, dedico este trabajo a
quien es mi ayudador en todo paso de fe
que doy en mi vida, a Jesucristo, en quien
fundamento mi confianza y se ha
convertido en mi primer amor. A Dios sea
la gloria y a Su Santo Espíritu.

A mis padres Alberto y Moly, por sus
incansable esfuerzo, sacrificio constante y
gran amor para formar un hijo profesional y
con valores; a mi tía Anita, a mi tío Alfredo
y a mi prima Carolina, por el apoyo
incondicional que recibí desde mi niñez.

viii

AGRADECIMIENTO

 Principalmente, agradezco al Altísimo y Soberano Dios, por la vida, la
salud y haber sido Él quien me guio y abrió las puertas para la realización
de este proyecto, siendo así sus planes conmigo y haciendo siempre Su
Voluntad Perfecta en mi vida.

 A mis docentes de la Escuela Académica Profesional de Ingeniería de
Sistemas de la Universidad Nacional de Ucayali, por impartirme sus
conocimientos y consejos en todo el tiempo que duró mi formación
profesional en esta prestigiosa casa de estudios.

 Al Dr. Jorge Luis Hilario Rivas, por haberme asesorado en la tesis desde
la concepción del proyecto y dado las pautas con su experiencia en el
desarrollo de la investigación.

 Al pastor y a los líderes de la Iglesia Evangélica Pentecostal Misionera
“El Tabernáculo”, por brindarme las facilidades para recopilar la
información necesaria y poder trabajar en la realización de la presente
tesis.

RESUMEN

La Iglesia Evangélica Pentecostal Misionera “El Tabernáculo” es una
congregación cristiana evangélica que orienta sus actividades a llevar el mensaje
de Jesucristo por medio de la prédica a toda la población de la ciudad de
Pucallpa; pero como toda organización, la información que se maneja
internamente y el flujo de los procesos de las distintas actividades que realiza,
debe mantener un orden para evitar posibles errores futuros, ya sea de control,
evaluación, entre otros. El propósito de la tesis es hacer uso de la “Tecnología
JEE 6 Web para la Gestión de Membresía y Logística Interna de la Iglesia
Evangélica Pentecostal Misionera ‘El Tabernáculo’”, la cual se maneja en la
misma congregación con un control de usuarios para la administradora de la
tesorería, usando un formato web y fácil de manejar por el cliente. La
metodología utilizada para obtener los datos del análisis consiste en la Encuesta,
la cual ayudó a encontrar los inconvenientes y la importancia de la aplicación de
esta tecnología. Los datos se procesaron con el software IBM® SPSS® Statistics
23.

Palabras clave: Tecnología web, Gestión de Membresía, Logística Interna,
Congregación Cristiana.

ABSTRACT

Evangelical Pentecostal Missionary Church "El Tabernaculo" is a Christian
evangelical congregation that guides its activities to carry the message of Jesus
Christ through the preaching to all the population of the city of Pucallpa; but as
any organization, the information that is handled internally and the flow of the
processes of the different activities that it performs, must maintain an order to
avoid possible future errors, be it of control, evaluation, among others. The
purpose of the thesis is to make use of the "JEE 6 Web Technology for the
Management of Membership and Internal Logistics of the Evangelical
Pentecostal Missionary Church “El Tabernaculo", which is managed in the
same congregation with a user control for the manager of the treasury, using a
web format and easy to handle by the client. The methodology used to obtain the
data of the analysis consists of the Survey, which helped to find the
disadvantages and the importance of the application of this technology. Data
were processed using IBM® SPSS® Statistics 23 software.

Keywords: Web Technology, Membership Management, Internal Logistics,
Christian Congregation.

ÍNDICE DE CONTENIDO
DEDICATORIA .......................................................................................................................... vii
AGRADECIMIENTO ................................................................................................................ viii
RESUMEN ................................................................................................................................... ix
ABSTRACT .................................................................................................................................. x
LISTA DE ANEXOS ................................................................................................................. xiv
ÍNDICE DE FIGURAS ............................................................................................................... xv
ÍNDICE DE TABLAS ................................................................................................................ xvi
ÍNDICE DE DIAGRAMAS ..................................................................................................... xviii
INTRODUCCIÓN ...................................................................................................................... xix
CAPÍTULO I ................................................................................................................................ 1
EL PROBLEMA DE INVESTIGACIÓN ................................................................................... 1
1.1 PLANTEO DEL PROBLEMA DE INVESTIGACIÓN ............................................. 1
1.2 FORMULACIÓN DEL PROBLEMA DE INVESTIGACIÓN .................................. 3
1.2.1 Problema principal o general ............................................................................ 3
1.2.2 Problemas secundarios - derivados ................................................................ 3
1.3 OBJETIVOS DE LA INVESTIGACIÓN ................................................................... 4
1.3.1 Objetivo principal o general .............................................................................. 4
1.3.2 Objetivos específicos - derivados .................................................................... 4
1.4 JUSTIFICACIÓN DEL ESTUDIO ............................................................................. 5
1.4.1 Justificación Práctica ......................................................................................... 5
1.4.2 Importancia .......................................................................................................... 5
1.4.3 Limitaciones ........................................................................................................ 6
1.5 LIMITACIONES DE LA INVESTIGACIÓN.............................................................. 7
1.5.1 Delimitación espacial ......................................................................................... 7
1.5.2 Delimitación social .............................................................................................. 8
1.5.3 Delimitación temporal ........................................................................................ 8
1.5.4 Delimitación conceptual ..................................................................................... 9
CAPÍTULO II ............................................................................................................................. 10
MARCO TEÓRICO .................................................................................................................. 10
2.1 ANTECEDENTES DEL ESTUDIO ......................................................................... 10
2.2 BASES TEÓRICAS .................................................................................................. 30
2.3 DEFINICIÓN DE TÉRMINOS ................................................................................. 42
2.4 HIPÓTESIS ............................................................................................................... 44
xii

2.4.1 Hipótesis General ............................................................................................. 44
2.4.2 Hipótesis Específicas ....................................................................................... 44
2.5 VARIABLES .............................................................................................................. 45
2.5.1 Definición conceptual ....................................................................................... 45
2.5.2 Definición operacional ..................................................................................... 46
2.5.3 Operacionalización de las variables .............................................................. 46
CAPÍTULO III ............................................................................................................................ 47
METODOLOGÍA DE LA INVESTIGACIÓN .......................................................................... 47
3.1 DEFINICIÓN DEL TIPO Y NIVEL DE LA INVESTIGACIÓN ............................. 47
3.1.1 Tipo de la investigación ................................................................................... 47
3.1.2 Nivel de la investigación .................................................................................. 48
3.2 DESCRIPCIÓN DEL ÁMBITO DE LA INVESTIGACIÓN ................................... 48
3.2.1 Método de investigación .................................................................................. 48
3.2.2 Diseño de investigación ................................................................................... 48
3.3 POBLACIÓN Y MUESTRA ..................................................................................... 50
3.3.1 Población de investigación ............................................................................. 50
3.3.2 Muestra de investigación ................................................................................. 50
3.4 RECURSOS PARA LA RECOLECCIÓN DE DATOS ........................................ 51
3.4.1 Fuentes de recaudo de información. ............................................................. 51
3.4.2 Técnicas de recolección de información....................................................... 51
3.4.3 Instrumentos para recolectar información. ................................................... 52
3.5 CONFIABILIDAD Y VALIDEZ DEL INSTRUMENTO ......................................... 53
3.6 PROGRAMA DE RECOLECCIÓN Y PROCESAMIENTO DE DATOS ........... 53
3.6.1 Programa de recolección de datos. ............................................................... 53
3.6.2 Programa de procesamiento de información. .............................................. 56
CAPÍTULO IV ............................................................................................................................ 58
PROCESOS DE GESTIÓN DE MEMBRESÍA Y LOGÍSTICA INTERNA DE LA IGLESIA
..................................................................................................................................................... 58
4.1 SITUACIÓN DEL TRABAJO EN LA IGLESIA ..................................................... 58
4.1.1 Descripción de los procesos ........................................................................... 58
4.1.2 Deficiencias en los procesos .......................................................................... 71
CAPÍTULO V ............................................................................................................................. 74
RESULTADOS DE LA INVESTIGACIÓN ............................................................................. 74
5.1 Resultados de la investigación ............................................................................... 74
5.1.1 Resultados del Pre - test ................................................................................. 74
xiii

5.1.2 Resultados del Post - test ............................................................................... 86
5.2 Verificación de Hipótesis ......................................................................................... 96
5.2.1 Formulación de valores cuantitativos para los indicadores ....................... 96
5.2.2 Supuestos de la prueba de hipótesis ............................................................ 97
5.2.3 Cálculo del valor crítico y la función de prueba ........................................... 98
CAPÍTULO VI .......................................................................................................................... 102
DESARROLLO DE SOLUCIÓN ........................................................................................... 102
6.1 EJECUCIÓN DEL PLAN DE DESARROLLO DE LA SOLUCIÓN .................. 102
6.1.1 Definición de la metodología de desarrollo de software........................... 102
CAPÍTULO VII ......................................................................................................................... 224
DISCUSIÓN DE LOS RESULTADOS ................................................................................. 224
1.1 Contrastación de los resultados ........................................................................... 224
CAPÍTULO VIII ........................................................................................................................ 235
ANÁLISIS CRÍTICO Y APORTE A LA ENTIDAD.............................................................. 235
8.1 Análisis crítico ......................................................................................................... 235
8.2 Aporte técnico ......................................................................................................... 243
CAPÍTULO IX .......................................................................................................................... 244
CONCLUSIONES Y RECOMENDACIONES ..................................................................... 244
9.1 Conclusiones ........................................................................................................... 244
9.2 Recomendaciones .................................................................................................. 246
REFERENCIAS BIBLIOGRÁFICAS .................................................................................... 247

xiv

LISTA DE ANEXOS

Anexo 1: Matriz de Identificación del Problema: .............................................................. 254
Anexo 2: Hoja de Ruta de las Variables ............................................................................ 255
Anexo 3: Operacionalización de Variables ....................................................................... 256
Anexo 4: Matriz de Consistencia Sistémica ...................................................................... 257
Anexo 5: Instrumento de recolección de datos ................................................................ 258
Anexo 6: Validación por el Alfa de Cronbach ................................................................... 259

ÍNDICE DE FIGURAS

Figura 1: Mapa de la Provincia de Coronel Portillo.............................................................. 8
Figura 2: Buenas prácticas de XP ........................................................................................ 38
Figura 3: La tecnología JEE 6 Web es aplicada para la mejora de la gestión de
Membresía y Logística Interna de la Iglesia Evangélica Pentecostal Misionera “El
Tabernáculo” ............................................................................................................................. 46
Figura 4: Tipos de diseños experimentales y elección del modelo adecuado. ............. 49
Figura 5: Programación de recolección de datos – pre test ............................................. 55
Figura 6: Programación de recolección de datos - post test ............................................ 56
Figura 7: Flujo de proceso de membresía ........................................................................... 65
Figura 8: Flowchart del proceso de inventariado ............................................................... 70
Figura 9: Porcentajes de pregunta 1 - Test Previo ............................................................ 75
Figura 10: Porcentajes de pregunta 2 - Test Previo .......................................................... 76
Figura 11: Porcentajes de pregunta 3 - Test Previo .......................................................... 77
Figura 12: Porcentajes de pregunta 4 - Test Previo .......................................................... 79
Figura 13: Porcentajes de pregunta 5 - Test Previo .......................................................... 80
Figura 14: Porcentajes de pregunta 6 - Test Previo .......................................................... 81
Figura 15: Porcentajes de pregunta 7 - Test Previo .......................................................... 82
Figura 16: Porcentajes de pregunta 8 - Test Previo .......................................................... 83
Figura 17: Porcentajes de pregunta 9 - Test Previo .......................................................... 84
Figura 18: Porcentajes de pregunta 10 - Test Previo ........................................................ 85
Figura 19: Porcentajes de pregunta 1 - Test Posterior ..................................................... 86
Figura 20: Porcentajes de pregunta 2 - Test Posterior ..................................................... 87
Figura 21: Porcentajes de pregunta 3 - Test Posterior ..................................................... 88
Figura 22: Porcentajes de pregunta 4 - Test Posterior ..................................................... 89
Figura 23: Porcentajes de pregunta 5 - Test Posterior ..................................................... 90
Figura 24: Porcentajes de pregunta 6 - Test Posterior ..................................................... 91
Figura 25: Porcentajes de pregunta 7 - Test Posterior ..................................................... 92
Figura 26: Porcentajes de pregunta 8 - Test Posterior ..................................................... 93
Figura 27: Porcentajes de pregunta 9 - Test Posterior ..................................................... 94
Figura 28: Porcentajes de pregunta 10 - Test Posterior ................................................... 95
Figura 29: Adaptación de escala de Likert del proyecto. .................................................. 96
Figura 30: Determinación de regiones aceptable y rechazable. .................................... 101
Figura 31: Organigrama de la Iglesia ................................................................................. 105
Figura 32: EDT del proyecto ................................................................................................ 118
Figura 33: Diagrama de Gantt de desarrollo del proyecto .............................................. 119

xvi

ÍNDICE DE TABLAS

Tabla 1: Metodologías Tradicionales VS Ágiles ................................................................. 41
Tabla 2: Tecnología JEE 6 Web ............................................................................................ 46
Tabla 3: Gestión de Membresía y Logística Interna .......................................................... 46
Tabla 4: Programación de recolección de datos – Pre Test ............................................. 55
Tabla 5: Programación de recolección de datos – Post Test ........................................... 55
Tabla 6: Programación de procesamiento de datos .......................................................... 57
Tabla 7: Frecuencias – Pregunta 1 Cuestionario Pre Test ............................................... 74
Tabla 8: Frecuencias – Pregunta 2 Cuestionario Pre Test ............................................... 76
Tabla 9: Frecuencias – Pregunta 3 Cuestionario Pre Test ............................................... 77
Tabla 10: Frecuencias – Pregunta 4 Cuestionario Pre Test ............................................. 78
Tabla 11: Frecuencias – Pregunta 5 Cuestionario Pre Test ............................................. 79
Tabla 12: Frecuencias – Pregunta 6 Cuestionario Pre Test ............................................. 81
Tabla 13: Frecuencias – Pregunta 7 Cuestionario Pre Test ............................................. 82
Tabla 14: Frecuencias – Pregunta 8 Cuestionario Pre Test ............................................. 83
Tabla 15: Frecuencias – Pregunta 9 Cuestionario Pre Test ............................................. 84
Tabla 16: Frecuencias – Pregunta 10 Cuestionario Pre Test ........................................... 85
Tabla 17: Frecuencias – Pregunta 1 Cuestionario Post Test ........................................... 86
Tabla 18: Frecuencias – Pregunta 2 Cuestionario Post Test ........................................... 87
Tabla 19: Frecuencias – Pregunta 3 Cuestionario Post Test ........................................... 88
Tabla 20: Frecuencias – Pregunta 4 Cuestionario Post Test ........................................... 89
Tabla 21: Frecuencias – Pregunta 5 Cuestionario Post Test ........................................... 90
Tabla 22: Frecuencias – Pregunta 6 Cuestionario Post Test ........................................... 91
Tabla 23: Frecuencias – Pregunta 7 Cuestionario Post Test ........................................... 92
Tabla 24: Frecuencias – Pregunta 8 Cuestionario Post Test ........................................... 93
Tabla 25: Frecuencias – Pregunta 9 Cuestionario Post Test ........................................... 94
Tabla 26: Frecuencias – Pregunta 10 Cuestionario Post Test ......................................... 95
Tabla 27: Resumen de resultados de los valores Pre Test y Post Test ......................... 99
Tabla 28: Entregables del proyecto .................................................................................... 103
Tabla 29: Matriz FLOR .......................................................................................................... 106
Tabla 30: Factores de valoración de los actores .............................................................. 106
Tabla 31: Factores de valoración de los Use Case.......................................................... 107
Tabla 32: Asignación de tipo de proceso de Use Case ................................................... 108
Tabla 33: Factor Técnico de Complejidad ......................................................................... 110
Tabla 34: Factor Environment ............................................................................................. 112
Tabla 35: Recursos humanos .............................................................................................. 115
Tabla 36: Recursos materiales ............................................................................................ 115
Tabla 37: Presupuesto de mano de obra ........................................................................... 116
Tabla 38: Presupuesto de materiales ................................................................................. 117
Tabla 39: Total presupuesto de materiales ....................................................................... 117
Tabla 40: Definición estratégica del producto. .................................................................. 120
Tabla 41: Perfil SuperUser ................................................................................................... 121
Tabla 42: Perfil Secretario .................................................................................................... 122
Tabla 43: Perfil Líder de ministerio ..................................................................................... 122
Tabla 44: Perfil Directiva ...................................................................................................... 122
xvii

Tabla 45: Reseña de símbolos en casos de uso .............................................................. 126
Tabla 46: Reseña de símbolos - Modelo de Objetos del Negocio ................................. 135
Tabla 47: Especificación CU - Login................................................................................... 147
Tabla 48: Especificación CU - Control de usuarios .......................................................... 148
Tabla 49: Especificación CU - Control de parámetros de membresía e inventario .... 149
Tabla 50: Especificación CU - Control de iglesias ........................................................... 150
Tabla 51: Especificación CU – Control de artículos ......................................................... 150
Tabla 52: Especificación CU – Control de membresía .................................................... 152
Tabla 53: Especificación CU - Solicitud de traspaso ....................................................... 152
Tabla 54: Especificación CU – Respuesta a solicitud de traspaso ................................ 153
Tabla 55: Especificación CU – Generación de inventario ............................................... 154
Tabla 56: Especificación CU - Cambio de contraseña .................................................... 154
Tabla 57: Especificación CU – Reportes de membresía ................................................. 155
Tabla 58: Especificación CU – Reportes de inventario ................................................... 156
Tabla 59: Descripción de tabla - TARTICULO .................................................................. 187
Tabla 60: Descripción de tabla - TCARGO ....................................................................... 188
Tabla 61: Descripción de tabla - TCATEGORIA ............................................................... 188
Tabla 62: Descripción de tabla - TESTADO ...................................................................... 188
Tabla 63: Descripción de tabla - TFAMILIA ....................................................................... 189
Tabla 64: Descripción de tabla - TIGLESIA ....................................................................... 189
Tabla 65: Descripción de tabla - TINVANIO ...................................................................... 190
Tabla 66: Descripción de tabla - TINVENTARIO .............................................................. 190
Tabla 67: Descripción de tabla - TMARCA ........................................................................ 191
Tabla 68: Descripción de tabla - TMIEMBROS ................................................................ 192
Tabla 69: Descripción de tabla - TMINIGLE ...................................................................... 193
Tabla 70: Descripcion de tabla - TMINBAU ....................................................................... 193
Tabla 71: Descripción de tabla - TMINISTERIO ............................................................... 193
Tabla 72: Descripción de tabla - TREGCANTIDAD ......................................................... 194
Tabla 73: Descripción de tabla - TTRASPASO ................................................................ 194
Tabla 74: Descripción de tabla - TTRASP_EMISION ...................................................... 194
Tabla 75: Descripción de tabla - TTRASP_RECEPCION ............................................... 195
Tabla 76: Descripción de tabla - TUSUARIOS ................................................................. 195
Tabla 77: Descripción de tabla - TESTCIVIL .................................................................... 196
Tabla 78: Validación de restricciones del sistema ........................................................... 222
Tabla 79: Prueba por Use Case - Requerimientos funcionales ..................................... 223
Tabla 80: Cálculo de puntaje – Pre Test ............................................................................ 241
Tabla 81: Cálculo de puntaje – Post Test .......................................................................... 242

xviii

ÍNDICE DE DIAGRAMAS

Diagrama 1: Casos de Uso del Negocio ........................................................................... 125
Diagrama 2: Modelo de Objetos - Gestión de registros .................................................. 127
Diagrama 3: Modelo de Objetos - Control de membresía .............................................. 128
Diagrama 4: Modelo de Objetos - Proceso de cambio de iglesia .................................. 129
Diagrama 5: Modelo de Objetos - Control de artículos ................................................... 130
Diagrama 6: Modelo de Objetos - Generación de inventario ......................................... 131
Diagrama 7: Modelo de Objetos – Reportes de Membresía .......................................... 132
Diagrama 8: Modelo de Objetos - Reportes de Traspasos ............................................ 133
Diagrama 9: Modelo de Objetos - Reportes de Artículos e Inventarios ....................... 134
Diagrama 10: Modelo de Dominio ...................................................................................... 136
Diagrama 11: CUR – Mantenimiento de usuarios ........................................................... 139
Diagrama 12: CUR – Gestión de Registros ...................................................................... 140
Diagrama 13: CUR – Control de membresía .................................................................... 141
Diagrama 14: CUR – Proceso de Cambio de Iglesia ...................................................... 142
Diagrama 15: CUR – Generación de inventario ............................................................... 143
Diagrama 16: CUR – Reportes ........................................................................................... 144
Diagrama 17: Diagrama de Colaboración - Login ............................................................ 157
Diagrama 18: Diagrama de Colaboración - Registro de usuarios ................................. 157
Diagrama 19: Diagrama de Colaboración - Registro de Iglesias .................................. 158
Diagrama 20: Diagrama de Colaboración - Registro y control de membresía ............ 159
Diagrama 21: Diagrama de Colaboración - Solicitud de cambio de membresía ........ 160
Diagrama 22: Diagrama de Colaboración - Respuesta a solicitud de cambio de
membresía ............................................................................................................................... 160
Diagrama 23: Diagrama de Colaboración - Registro de Artículo .................................. 161
Diagrama 24: Diagrama de Colaboración – Generación de Inventario ........................ 162
Diagrama 25: Diagrama de Colaboración - Reportes ..................................................... 163
Diagrama 26: Diagrama de Clases .................................................................................... 164
Diagrama 27: Diagrama de Secuencia - Login ................................................................. 165
Diagrama 28: Diagrama de Secuencia - Registro de usuarios ...................................... 168
Diagrama 29: Diagrama de Secuencia - Registro de iglesia.......................................... 170
Diagrama 30: Diagrama de Secuencia - Registro y control de membresía ................. 172
Diagrama 31: Diagrama de Secuencia - Solicitud de traspaso ..................................... 175
Diagrama 32: Diagrama de Secuencia - Respuesta a traspaso .................................... 177
Diagrama 33: Diagrama de Secuencia – Crear inventario ............................................. 179
Diagrama 34: Diagrama de Secuencia - Registro de artículo ........................................ 181
Diagrama 35: Diagrama de Secuencia – Reportes ......................................................... 183
Diagrama 36: Diagrama de paquetes del software ......................................................... 186
Diagrama 37: Modelo de Base de Datos ........................................................................... 197
Diagrama 38: Diagrama de Red ......................................................................................... 217
Diagrama 39: Diagrama de Componentes ........................................................................ 218
Diagrama 40: Diagrama de Despliegue lógico del sistema ............................................ 219

xix

INTRODUCCIÓN

La presente tesis denominada “Tecnología JEE 6 Web para la gestión de
membresía y logística interna de la iglesia evangélica pentecostal misionera “El
Tabernáculo” es una investigación aplicada a la mencionada congregación
cristiana, en la cual se da solución a la problemática de la mala gestión de
miembros y el control de su inventario como recurso logístico, determinando que
la tecnología JEE 6 Web mejora dichas gestiones. También se estudiaron otros
objetivos concernientes al propósito principal.

Los temas tratados se organizaron por capítulos, divididos estos en
subcapítulos y subtemas dentro de ellos. Para la mejor comprensión de algunas
etapas se han puesto gráficos; para detallar resultados y artefactos se usaron
tablas; las figuras son utilizadas como referencias de resultados.

En el primer capítulo se define la situación problemática como base para el
inicio del trabajo, explicando y considerando las limitaciones que se tomaron en
cuenta para su ejecución. Los problemas secundarios son plasmados como
aquellos temas que deben ser tratados individualmente pero relacionándolos
para llegar a un mismo fin, solucionando el problema primario. Se justifica el
proyecto identificando la problemática que surge en la pérdida de tiempo al
realizar actividades sencillas.

En el segundo capítulo, se toca todo el contexto teórico relacionado al
proyecto de investigación como: antecedentes del problema, proyectos similares
en congregaciones eclesiásticas, tecnología que se usará para la realización del
sistema web, bases teóricas, definición de términos usados en el proyecto, etc.
En este mismo capítulo se cita de manera resumida algunos trabajos que tienen
una base tecnológica y que se pueden aplicar para este caso, así como
mencionar las hipótesis alternativas planteadas tras encontrar los problemas y
xx

definir los objetivos a alcanzar con el proyecto. Las variables a usar son
esclarecidas y se conceptualizan para relacionarlas y definir sus dimensiones e
indicadores, considerando el tipo de trabajo que se hace en la Iglesia.

El tercer capítulo se enfoca en la parte metodológica del proyecto, pues se
define el método, tipo, nivel y diseño de la investigación; se encuentra la muestra
a la que se aplicará el instrumento de recolección de datos y se valida por el
método del Alfa de Cronbach el nivel de fiabilidad de la técnica utilizada.

El cuarto capítulo describe el funcionamiento de los procesos de membresía
y logística interna de la iglesia entorno de trabajo, así como las deficiencias en
los mismos, describiendo los aspectos a considerar para el trabajo.

En el quinto capítulo se mostrarán los resultados de la aplicación de técnicas
de investigación, siendo estos los datos y la información obtenida por medio de
la encuesta y su representación por medio del software SPSS y el diseño de la
investigación.

El sexto capítulo contiene el desarrollo de un software web, lo propuesto
como solución a la problemática en el manejo de la información en los distintos
procesos. Se aplica una metodología tradicional para el desarrollo del software
y sus determinadas fases, con la documentación necesaria para la ejecución de
la tesis.

En el séptimo capítulo, se discuten los resultados obtenidos en la aplicación
de la investigación y el impacto que tuvo la aplicación de la solución en la entidad.

xxi

En el octavo capítulo se hace una discusión con respecto a los resultados de
la investigación relacionado a la hipótesis y problemas de la investigación y se
muestra el aporte técnico dado a la iglesia.

Finalmente, el noveno capítulo trata las conclusiones obtenidas con la
presente tesis y las recomendaciones para el correcto funcionamiento del
sistema y llevar en armonía los procesos determinados en el mismo.

El proyecto de tesis “Tecnología JEE 6 Web para la gestión de membresía y
logística interna de la Iglesia Evangélica Pentecostal Misionera ‘El Tabernáculo’”
está enfocado a solucionar un problema detectado en la congregación en
mención.

El propósito de la aplicación de esta tecnología web es el de sistematizar
algunos procesos que pueden ocupar menos tiempo y esfuerzo al ser
digitalizados, a la vez que se mejora el control de éstos.
1

CAPÍTULO I

EL PROBLEMA DE INVESTIGACIÓN

1.1 PLANTEO DEL PROBLEMA DE INVESTIGACIÓN

La Iglesia Evangélica Pentecostal Misionera “El Tabernáculo” es una
congregación cristiana evangélica que orienta sus actividades a llevar el
mensaje del reino de Dios por medio de la prédica a toda la población de la
ciudad de Pucallpa.

Ésta, a su vez, tiene una organización interna que le permite gestionar y
realizar sus actividades secundarias conforme a su estructura organizacional
y roles propios.

Se pudo identificar problemas en el almacenamiento y búsqueda de
información personal de un miembro de la iglesia, dado que el registro de
los miembros se hace en libros físicos y archivando de esa manera sus datos
para un posible uso en un momento dado.
2

Esto ocasiona una pérdida de tiempo al momento de buscar la
información de un miembro, ya que sus datos no son tan accesibles por el
recurso en el que se guardan y, en algunos casos, puede producir la pérdida
de la información.

El proceso de registro de membresía también muestra una demora, la
cual se debe a la forma manual en que se realiza en los libros físicos. El
escribir en una hoja de papel trae los errores ortográficos y de uso de
correctores si hay errores al escribir. También se da la posibilidad de
redundancia de datos si se olvida que un miembro ya ha sido registrado,
pues su comprobación se hace de manera manual. La pérdida de tiempo es
la principal consecuencia. El archivamiento de los documentos de manera
física supone otra limitación en un mundo en el que todo se puede digitalizar.

Cada nuevo integrante de la congregación (incluso el que viene de otra
iglesia) debe ser inscrito en el libro de la misma, evaluando por la
observación al posible miembro y confirmar si puede comenzar a participar
activamente en las responsabilidades que se asignen como cristiano dentro
y fuera de la Iglesia. Esto ocasiona al mismo tiempo algunos inconvenientes,
pues al ser requeridos algunos datos de los miembros con un documento
oficial de la iglesia solicitante (carta de recomendación), las comprobaciones
con los líderes externos y revisiones de formatos emplean un recurso no
recuperable que es el tiempo, dando lugar a trámites largos innecesarios,
pérdida de tiempo y truncamiento en la participación del nuevo miembro en
las labores de la iglesia.

Con respecto a las labores de inventariado, se identificaron problemas
en el control de inventario, como la ineficiencia en la verificación de un
inventario anterior con respecto al nuevo. Es necesario volver a identificar
los artículos actuales y no se valida el estado de ellos. Esto es causado por
el registro manual y no existir un recurso que ayude en las validaciones, lo
3

que ocasiona el mal control de inventario y hasta la pérdida de los haberes
físicos de la iglesia.

Los papeles y libros físicos constituyen un exceso de material para las
labores realizadas, lo cual es causado por la manera tradicional de llevar a
cabo sus actividades internas, dando como consecuencia el archivamiento
excesivo de la documentación y la posible pérdida de información.

Todos estos inconvenientes obstaculizan labores que no suelen ser
continuas, pero al momento de realizarse ocupan recursos que pueden ser
optimizados: minimizando el esfuerzo y tiempo empleado y maximizando los
resultados positivos y buena organización de la data que se maneja dentro
de la Iglesia.

1.2 FORMULACIÓN DEL PROBLEMA DE INVESTIGACIÓN

1.2.1 Problema principal o general

¿En qué medida la tecnología JEE 6 Web mejora la gestión
de membresía y logística interna de la Iglesia Evangélica
Pentecostal Misionera “El Tabernáculo”?

1.2.2 Problemas secundarios - derivados

1. ¿Cuáles son los principales actores, procesos y
requerimientos que participan en la gestión de membresía y
logística interna de la Iglesia Evangélica Pentecostal
Misionera “El Tabernáculo”?

2. ¿De qué manera se puede reducir el tiempo que tarda el
cambio de membresía entre la Iglesia Evangélica
Pentecostal Misionera “El Tabernáculo” y sus anexos?

3. ¿En qué medida se reducirá el tiempo de verificación y
errores de inventario de la Iglesia Evangélica Pentecostal
Misionera “El Tabernáculo”?

4. ¿De qué manera se pueden interconectar los registros de
miembros de la Iglesia Evangélica Pentecostal Misionera “El
Tabernáculo” con sus anexos?

1.3 OBJETIVOS DE LA INVESTIGACIÓN

1.3.1 Objetivo principal o general

Determinar que la tecnología JEE 6 Web mejora la gestión
de membresía y logística interna de la Iglesia Evangélica
Pentecostal Misionera “El Tabernáculo”

1.3.2 Objetivos específicos - derivados

1. Identificar los principales actores, procesos y requerimientos
que participan en la gestión de membresía y logística interna
de la Iglesia Evangélica Pentecostal Misionera “El
Tabernáculo”

2. Realizar el estudio del proceso de cambio de membresía o
de un nuevo miembro entre la Iglesia Evangélica
Pentecostal Misionera “El Tabernáculo” y sus anexos, y
elaborar un estándar de membresía común inter-
congregacional.

3. Reducir el tiempo de verificación de inventario y su registro
en libros físicos, haciendo uso de la tecnología JEE 6 Web
para gestionar los registros y se tenga una base de datos de
los haberes en almacén.

4. Incluir el registro de membresías de la Iglesia Evangélica
Pentecostal Misionera “El Tabernáculo” y sus anexos en un
sistema informático web.

1.4 JUSTIFICACIÓN DEL ESTUDIO

1.4.1 Justificación Práctica

La presente investigación se realizó al observar deficiencias
en la gestión de membresía y la logística interna de los inventarios
de la Iglesia Evangélica Pentecostal Misionera “El Tabernáculo”,
determinando sus diversos factores y teniendo como objetivo
principal mejorar dichas actividades con la aplicación de la
tecnología JEE 6 web.

1.4.2 Importancia

La presente investigación realizada en la Iglesia Evangélica
Pentecostal Misionera “El Tabernáculo” toma un valor
6

trascendental debido a dos perspectivas sobre la gestión de la
iglesia: internamente, no existía la oportunidad de mejora de los
procesos con el uso de tecnología debido a la inexistencia de
alguien que pueda dar inicio a una propuesta de solución y la
investigación sirve para realizar los cambios positivos a favor de la
iglesia; así mismo, desde un punto de vista externo, prácticamente
no existen investigaciones nacionales realizadas enfocadas al
estudio de la membresía y control de inventario, y al desarrollo de
software para este tipo de asociaciones sin fines de lucro, como es
el caso de este estudio en la iglesia en mención.

1.4.3 Limitaciones

La resistencia al cambio suele ser un factor que influye en
las mejoras de procesos o actividades al usarse tecnología
desconocida para muchas personas y este no es un caso ajeno. Si
bien es cierto, el Pastor de la Iglesia es quien representa a la
comunidad cristiana en todas las decisiones que se tomen, los
miembros deben ser conscientes de que los cambios afectan a
todos de alguna manera. No ha habido resistencia masiva, pero se
debió llamar a los ancianos (nivel de jerarquía de representantes
en la Iglesia) y convocar a una reunión de líderes para coordinar el
inicio del trabajo.

Algunas limitaciones incluyen la falta de un reglamento
interno establecido oficialmente, por lo que algunos datos o
información no fueron de fácil acceso hasta que se cerró la etapa
de confirmación.

La poca facilidad de recursos económicos (como la carencia
de una conexión a Internet) constituye una limitante, pero se
adecúa a la disponibilidad del recurso de algunos miembros.

Las Iglesias adicionales (filiales o anexos) que participan en
el proyecto también trataron algunos temas internos en su
congregación, pero la aprobación del pastor como líder da inicio a
la inclusión de ellos en el trabajo.

1.5 LIMITACIONES DE LA INVESTIGACIÓN

1.5.1 Delimitación espacial

La tesis “Tecnología JEE 6 Web para la gestión de
membresía y logística interna de la Iglesia Evangélica Pentecostal
Misionera ‘El Tabernáculo’” está enfocado a solucionar un
problema detectado en una congregación cristiana evangélica del
distrito de Yarinacocha, Provincia de Coronel Portillo,
Departamento de Ucayali, incluyendo y afectando directamente a
los líderes y por ende a los miembros de la organización
mencionada; sin embargo, la aplicación de este sistema también
incluye a otras congregaciones evangélicas de la ciudad (anexos
8

de la iglesia), puesto que la creación del modelo estándar de
membresía necesitará de pruebas inter-congregacionales.

Figura 1: Mapa de la Provincia de Coronel Portillo

1.5.2 Delimitación social

El proyecto está orientado a una asociación religiosa,
pertenecientes a una población creyente en la Palabra del Señor
Jesucristo. Su aporte es la mejora de procesos internos de la
congregación a la que ellos asisten y la unificación de uno de los
procesos entre otras Iglesias para agilizarlo y así aprovechar los
recursos disponibles.

1.5.3 Delimitación temporal

El trabajo es de actualidad, por lo que los resultados se
aprecian al darle uso al sistema. Todo el trabajo se llevó a cabo con
un cronograma de actividades que fue diagnosticando,
planificando, ejecutando y evaluando la realización del mismo, pero
con un seguimiento constante de los resultados que se obtuvieron
al realizar las operaciones; estos procesos internos y externos son
eventuales.
9

1.5.4 Delimitación conceptual

El marco del trabajo se concentra en la elaboración de una
solución para limitaciones que se han identificado dentro de la
congregación cristiana evangélica Iglesia Evangélica Pentecostal
Misionera ‘El Tabernáculo’, y todo esto engloba los procesos
internos de membresía interna y externa y la logística básica de la
organización religiosa. Su ámbito es netamente de procesos
internos y la creación de un sistema informático que gestione esta
información e incluya un módulo de membresía que relacione las
demás congregaciones participantes del proyecto.

CAPÍTULO II

MARCO TEÓRICO

2.1 ANTECEDENTES DEL ESTUDIO

Como tema de investigación, no hay registros de que se haya hecho algo
parecido en la Iglesia Evangélica Pentecostal Misionera “El Tabernáculo”, ya
que los temas de proyectos se enfocan en organizaciones gubernamentales
o en empresas que se dedican a algún negocio en específico; pero para
ampliar el ámbito de trabajo, se ha encontrado registro de proyectos
similares a nivel internacional y algunos proyectos relacionados con el
desarrollo web para solucionar otros problemas a nivel nacional.

Como parte de la documentación, se mostrarán los nombres de los
proyectos, nombre del autor, grado al que optaba, objetivos y conclusiones
de la investigación.

Título de Proyectos de Tesis en el ámbito nacional

1. Jiménez Bazán, Gerardo G. (2018). “SISTEMA WEB DE
CONTROL DE ASISTENCIA BASADO EN WEB SERVICES Y LA
BIOMETRÍA DE HUELLA DACTILAR PARA LAS INSTITUCIONES
EDUCATIVAS” (Tesis de pregrado). Universidad Nacional Mayor
de San Marcos, Lima, Perú.

Objetivo General:

Realizar el análisis, diseño e implementación de un sistema
web que realice el registro y control de asistencia de alumnos de
acuerdo a lo que requieran los colegios y escuelas.

Conclusiones principales:

A. Eficiencia al integrar el componente responsable del lector de
huellas dactilares en Java, la web en .NET y el servicio web
hecho en .NET – WCF.

B. El producto lector de huellas UareU 4500 es bueno, fiable y
se integra fácilmente con sistemas en formato web.

C. La aplicación de la metodología SCRUM permite que el
desarrollo de la solución esté centrada en el propósito
principal y las iteraciones sean las necesarias.

D. Las deducciones logradas expresan que una aplicación web
puede realizarse de manera eficiente y capaz para la labor de
toma de asistencia.

(Jiménez Bazán, 2018)

2. Huamanciza Gironda, Carolina (2018). “DESARROLLO DE UNA
APLICACIÓN WEB Y MÓVIL PARA LA GESTIÓN DE
ENCUESTAS DINÁMICAS APLICANDO UN MODELO DE BASE
DE DATOS NOSQL ORIENTADO A GRAFOS.” (Tesis de
pregrado). Universidad Nacional Mayor de San Marcos, Lima,
Perú.

Objetivo general:

El objetivo de esta tesis es desarrollar un sistema web y una
aplicación móvil para la gestión de encuestas dinámicas aplicando
una base de datos NoSQL orientada a grafos.

Conclusiones principales:

A. Se investigó y analizó los tipos, importancia y desventajas de
las encuestas a nivel internacional y nacional, trabajos
referentes a la recolección de datos mediante encuestas-web
y stack de tecnologías para el desarrollo del sistema
mencionadas en el capítulo 1, 2 y 3.

B. Se estudió el framework .Net, la herramienta Neo4j y el
lenguaje de consulta de grafos Cypher, se desarrolló la
aplicación web para la creación de encuestas dinámicas.

C. Se estudió el sistema operativo android y se desarrolló la
aplicación móvil para la recolección de datos.

D. Se tomó como caso de prueba el censo realizo en Perú el
2017, se aplicó las clases de equivalencia para la validación
del aplicativo.
(Huamanciza Gironda, 2018)
13

3. Reátegui Macedo, Ruddy, & Trujillo Romero, Henrri Rogger (2017).
“SISTEMA INFORMATICO CON TECNOLOGIA J2EE DE
EVALUACION DE DOCENTES EN LA ESCUELA PROFESIONAL
DE INGENIERIA DE SISTEMAS DE LA UNIVERSIDAD
NACIONAL DE UCAYALI” (Tesis de pregrado). Universidad
Nacional de Ucayali, Pucallpa, Perú.

Objetivo general:

Determinar de qué manera la evaluación de docentes de la
escuela de Ingeniería de Sistemas de la Universidad Nacional de
Ucayali mejora con la tecnología propuesta en su tesis.
Conclusión principal:

Su objetivo principal fue logrado de manera efectiva desde
el trabajo en campo al levantar información hasta la
implementación de la solución tecnológica en la Escuela de
Ingeniería de Sistemas de la Universidad Nacional de Ucayali.

(Reátegui Macedo & Trujillo Romero, 2017)

4. Romero Gutiérrez, Carlos A. (2017). “GESTIÓN DE LA
INFORMACIÓN ADMINISTRATIVA DE LA ACADEMIA
PERSONAL CLASS MEDIANTE LA IMPLEMENTACIÓN DE UN
SOFTWARE” (Tesis de pregrado). Universidad Nacional del Centro
del Perú, Huancayo, Perú.

Objetivo general:

Medir la influencia de la implementación del software en la
gestión de la información administrativa en la academia Personal
Class.

Conclusión principal:

El control de las asistencias de la academia objeto de
estudio fue mejorado al obtener un 0% de pérdidas, lo que quiere
decir que la administración está optimizada al implementarse el
sistema informático.

(Romero Gutiérrez, 2017)

5. Portugal Legua, Yuri G. (2017). “ANÁLISIS, DISEÑO E
IMPLEMENTACIÓN DE UN SISTEMA PARA LA GESTIÓN DE
PROMOCIONES DE DOCENTES DE UNA UNIVERSIDAD” (Tesis
de pregrado). Pontificia Universidad Católica del Perú, Lima, Perú.

Objetivo general:

El objetivo del proyecto es realizar el análisis, diseño e
implementación de un Sistema para la gestión de promociones de
docentes, mediante una intranet para la PUCP.

Conclusión principal:

La arquitectura tecnológica del Campus de la PUCP permite
la implementación del sistema de Gestión de Promoción Docente
y brindará un soporte tecnológico estable y seguro, además de
soportar una alta demanda de usuarios que se encontrarán
completando su ficha de inscripción.

(Portugal Legua, 2017)

6. Tanaka Terukina, Ricardo (2016). “SISTEMA DE GESTIÓN DE
FUERZA DE VENTAS WEB Y MÓVIL, UTILIZANDO EL ESTILO
ARQUITECTÓNICO REST, METODOLOGÍA SCRUM Y LA
GEOLOCALIZACIÓN” (Tesis de pregrado). Universidad Nacional
Mayor de San Marcos, Lima, Perú.

Objetivo general:

Optimizar la productividad y minimizar los espacios
inutilizados de tiempo en el área de ventas con el estilo REST, uso
de SCRUM y localización geológica por medio de un software de
ventas web y aplicativo móvil.

Conclusiones principales:

A. La supervisión de los vendedores, considerando todos los
aspectos de locación y actividades suyas de venta fueron
sistematizados con un sistema web, así como la gestión de
productos.

B. Se optimizó la productividad y se minimizaron los espacios
inutilizados de tiempo en el área de ventas, haciendo uso del
software web propuesto y las metodologías indicadas en el
proyecto.

(Tanaka Terukina, 2016)

7. Castillo Asencio, Pedro L. (2016). “DESARROLLO E
IMPLEMENTACIÓN DE UN SISTEMA WEB PARA GENERAR
VALOR EN UNA PYME APLICANDO UNA METODOLOGÍA ÁGIL.
CASO DE ESTUDIO: MANUFIBRAS PEREZ SRL” (Tesis de
pregrado). Universidad Nacional Mayor de San Marcos, Lima,
Perú.

Objetivo general:

Crear un sistema web mediante la utilización de una
metodología rápida para la entidad Manufibras Pérez SRL, con el
propósito de producir valor con la mejora en el impulso de
productos, diligencia de pedidos y el registro de ventas.

Conclusión principal:

Como desenlace, para diferenciar si una entidad genera
valor no es suficiente con prestar atención la tarea financiera, sino
de igual forma otros aspectos como la creación tecnológica y una
estrategia administrativa. Así como aún se demuestra que una
estrategia administrativa para mover el negocio y guiar sus
procedimientos apoyándose en herramientas tecnológicas hace
aumentar al negocio.

Además, se ha preparado el caso práctico referente a la
práctica de la Programación Extrema XP en el actual plan, con el
propósito de conocer cómo funciona, y según los resultados
obtenidos se puede manifestar que es correcto emplear estas
metodologías a la implementación de sistemas web debido a que
se estará generando valor con cada artefacto al final de las
iteraciones.

(Castillo Asencio, 2016)
17

8. Esteban Santamaría, Jelmi Y, & Valega Marquina, Jorge R. (2015).
“SISTEMA MÓVIL BASADO EN GEOLOCALIZACIÓN PARA
MEJORAR LA GESTIÓN DE RECLAMOS Y AVERÍAS EN
TELEFÓNICA DEL PERÚ” (Tesis de pregrado). Universidad
Nacional de Ucayali, Pucallpa, Perú.

Objetivo general:

Hacer que la gestión de reclamos y averías de la empresa
Telefónica en Surquillo mejore con la propuesta de una aplicación
móvil que usa la ubicación física por mapas.

Conclusiones principales:

A. Una base de datos Dataware House integra perfectamente
la gestión de reclamos y averías de la empresa con el
aplicativo móvil propuesto, considerando la parte física y
lógica de este.

B. Se demuestra la propuesta de mejora de la gestión de
reclamos y averías de la empresa Telefónica de Surquillo al
encontrar un nivel de relación directa entre las variables
estudiadas.

(Esteban Santamaría & Valega Marquina, 2015)

9. Chacón Campos, Pío (2015). “SISTEMA EXPERTO APLICADO AL
PROCESO DE ORIENTACIÓN VOCACIONAL EN LAS
ESCUELAS PROFESIONALES DE INGENIERÍA DE LA
UNIVERSIDAD NACIONAL DE UCAYALI” (Tesis de pregrado).
Universidad Nacional de Ucayali, Perú.

Objetivo general:

Desarrollar y construir un sistema experto que mejore el
proceso de orientación vocacional en las escuelas profesionales de
ingeniería de la Universidad Nacional de Ucayali.

Conclusiones principales:

A. Se desarrolló un sistema experto aplicado al proceso de
orientación vocacional, teniendo las siguientes
características:
a. El software logró que la mayoría de alumnos puedan
contestar la encuesta y receptar en un mínimo
período un consejo sobre la carrera profesional en la
que debería formarse.
b. La evaluación se hizo de manera digital sistemática,
así se evitó usar recursos humanos en el test por
cada alumno.
c. Se pudo hacer un seguimiento del test durante y
después de su realización por medio del aplicativo
web.
d. El sistema experto no busca sustituir la tarea del
profesional psicólogo, sino apoyar dicha actividad
aportando la información necesaria en la situación
pertinente.

(Chacón Campos, 2015)
19

10. Marcacuzco Polanco, Yanina, & Trigueros Vela, Katherine S.
(2014). “SISTEMA ERP T&G-INFORMÁTICA” (Tesis de pregrado).
Universidad Ricardo Palma, Lima, Perú.

Objetivo general:

Desarrollar e implantar un ERP con el objetivo de
sistematizar el control de la información de las principales
actividades y acelerar la salida de la información entre las
diferentes áreas de la entidad. Permitiendo la agilidad en los
procesos críticos como Ventas, Almacén, entre otros.

Conclusiones

Para ejecutar el rediseño de procesos, es menester realizar
una explicación exacta de toda actividad de la entidad, con
respecto a las mejores maneras y al propósito que se quiera
conseguir, se determina una solución eficaz como la institución de
un software ERP para la unificación de los procesos y la gestión de
la información.

(Marcacuzco Polanco & Trigueros Vela, 2014)

Título de Proyectos de Tesis en el ámbito internacional

1. Cruz Flores, Erick (2019). “DESARROLLO DE UNA APLICACIÓN
WEB PARA LA GESTIÓN ACADÉMICA EN UN CENTRO DE
NIVELACIÓN” (Tesis de pregrado). Escuela Politécnica Nacional,
Quito, Ecuador.

Objetivo general:

Desarrollar una aplicación web para la gestión académica en
un centro de nivelación, mediante la creación de prototipos y
experiencia de usuario.

Conclusiones principales:

Con el desarrollo de prototipo de baja fidelidad, se pudo
realizar una aplicación que cumple con los requisitos funcionales y
no funcionales identificados con la encueta realizada. […]

La experiencia de usuario estuvo presente en todo el
proceso de desarrollo del prototipo, sobre todo cuando se definen
los objetivos de los prototipos y sus retroalimentaciones.

(Cruz Flores, 2019)

2. Hurtado Samaniego, Diego F. (2019) “APLICACIÓN WEB
ADMINISTRATIVA PARA RESERVA DE SERVICIOS DE
TRANSPORTE Y ENVÍO DE ENCOMIENDAS PARA LA
EMPRESA ROMERO Y ASOCIADOS (AMBASEUR) DE LA
CIUDAD DE AMBATO” (Tesis de pregrado). Universidad Técnica
de Ambato, Ecuador.

Objetivo general:

Desarrollar una aplicación web para la reserva de servicios
de transporte y envío de encomiendas para la empresa Romero y
Asociados (AMBASEUR) de la ciudad de Ambato.

Conclusiones principales:

Utilizando XP como metodología principal durante el
desarrollo de la propuesta, ha facilitado la aplicación de cambios
en el proyecto de manera rápida. Posibilitando añadir
funcionalidades extra, como por ejemplo el chat en línea.

Para la implementación de la propuesta se utilizó el patrón
de diseño MVC, con lo cual se pudo obtener una aplicación
modular, susceptible a cambios, escalable y sostenible.

(Hurtado Samaniego, 2019)

3. Quishpe Guanotásig, César E. (2018). “DESARROLLO DE UNA
APLICACIÓN WEB QUE MEJORE LA GESTIÓN DE LOS
PRODUCTOS EXPERIMENTALES EN INGENIERÍA DE
SOFTWARE APLICANDO EL PARADIGMA DE LÍNEA DE
PRODUCTO SOFTWARE EN EL GRUPO DE INVESTIGACIÓN
GITBIO” (Tesis de pregrado). Universidad de las Fuerzas
Armadas, Lacatunga, Ecuador.

Objetivo general:

Desarrollar una aplicación web que mejore la gestión de los
productos experimentales en ingeniería de software aplicando el
paradigma de línea de producto software en el grupo de
investigación GITBIO.

Conclusión principal:

Se desarrolló la aplicación web que permite gestionar los
productos experimentales aplicando el paradigma LPS.

(Quishpe Guanotásig, 2018)

4. Díaz Sevilla, Michael, & Sarcos Vargas, Wilmer (2017).
“DESARROLLO DE UN SOFTWARE EN AMBIENTE WEB PARA
EL CÁLCULO DE HUELLA DE CARBONO, QUE PERMITA
DETERMINAR LA CANTIDAD DE CO2 QUE PRODUCEN LOS
AUTOBUSES DE TRANSPORTE URBANO DE LA
COOPERATIVA “CIUDAD DE MILAGRO”, DEL CANTÓN
MILAGRO, PROVINCIA DEL GUAYAS, EN EL PERIODO 2017”
(Tesis de pregrado). Universidad Estatal de Milagro, Ecuador.

Objetivo general:

Desarrollar e implementar una herramienta tecnológica
Software que permita determinar la cantidad de CO2 que producen
los autobuses de transporte urbano de la cooperativa “Ciudad de
Milagro”, del cantón Milagro, Provincia del Guayas, en el periodo
2017.

Conclusiones:

Se concluye que en la actualidad el tema sobre el medio
ambiental ha logrado mantener preferencia a nivel político social,
no obstante pocos son las gestiones que han sido tomadas o
implementadas dentro de empresas o instituciones tanto públicas
como privadas debido a que no existe una norma que regule al
100% el CO2 o se manejen sistemas informáticos que ayuden a
minimizar los riesgos de contaminación.

(Díaz Sevilla & Sarcos Vargas, 2017)

5. Guanoluisa Andagua, Gissela M., & Maldonado Moyolema,
Cristian D. (2016). “DESARROLLO DE UN SISTEMA WEB QUE
OPTIMICE LA GESTIÓN DE FLOTAS DE TRANSPORTE
TERRESTRE ASIGNADO AL ÁREA DE LOGÍSTICA DE LA
UNIVERSIDAD DE LAS FUERZAS ARMADAS ESPE
EXTENSIÓN LATACUNGA” (Tesis de pregrado). Universidad de
las Fuerzas Armadas, Lacatunga, Ecuador.

Objetivo general:

Implementar un software web para mejorar la gestión de
flotas terrestres asignadas al Área de Logística de la Universidad
de las Fuerzas Armadas ESPE Extensión Latacunga

Conclusión principal:

El sistema web SISGEV de acuerdo a la información
recolectada con los instrumentos (encuestas) y a la demostración
estadística Chi cuadrado cumple con la optimización de los
procesos que implica la gestión de flota de transporte terrestre:
gestión de vehículos, gestión de solicitudes, gestión de
mantenimiento y la gestión de asignaciones en tiempo real.

(Guanoluisa Andagua & Maldonado Moyolema, 2016)

6. Obando Mosquera, Daniel A. (2015). “DESARROLLO DE UN
SITIO WEB BAJO EL PATRÓN DE DISEÑO MODELO, VISTA,
CONTROLADOR, QUE PERMITA LA GESTIÓN DEL REGISTRO
DE VOLUNTARIOS Y DONACIONES PARA DAR SOPORTE E
INFORMACIÓN A LA FUNDACIÓN CONSTRUYAMOS UN
SUEÑO, UBICADA EN LA CIUDAD DE LATACUNGA EN EL AÑO
2015” (Tesis de pregrado). Universidad de las Fuerzas Armadas,
Lacatunga, Ecuador.

Objetivo general:

Desarrollar un Sitio web para la gestión de donaciones y el
registro de voluntarios para la Fundación Construyamos un Sueño,
ubicada en la ciudad de Latacunga

Conclusiones:

A partir del desarrollo de la propuesta planteada se pudo
establecer que, la definición de un marco teórico que reúna la
información para el desarrollo del proyecto, es de vital importancia
para lograr una adecuada selección de la mejor tecnología
encaminando nuestro proyecto de una manera clara y concisa.

Se pudo identificar deficientes flujos de trabajo para el
registro de donaciones en la fundación, por lo que el desarrollo de
la propuesta brindará una mejora significativa en dicho proceso.

Se concluye, a partir del desarrollo del Sitio web, que la
información manejada dentro del mismo, responde de manera
directa a la documentación entregada por la fundación,
recolectando los datos mediante la creación de formularios,
exitosamente.

(Obando Mosquera, 2015)

7. Fuentes Manzano, Gissela E. (2015). “DESARROLLO DE UN
SISTEMA WEB QUE APOYE LA COORDINACIÓN DE
APROBACIÓN, SEGUIMIENTO DE EJECUCIÓN Y CIERRE DE
PROYECTOS EN LA JEFATURA DE INVESTIGACIÓN,
INNOVACIÓN Y TRANSFERENCIA DE TECNOLOGÍA DE LA
UNIVERSIDAD DE LAS FUERZAS ARMADAS ESPE
EXTENSIÓN LATACUNGA” (Tesis de pregrado). Universidad de
las Fuerzas Armadas, Lacatunga, Ecuador.

Objetivo general:

Crear un software web que ayude en la programación de
gestión de proyectos en la Jefatura de Investigación, Innovación y
Transferencia de Tecnología de la Universidad de las Fuerzas
Armadas ESPE Extensión Latacunga.

Conclusiones:

La implementación del proyecto fue factible para apoyar
como repositorio de datos.

La metodología utilizada en el desarrollo del proyecto lo hace
manejable con el tiempo y permite el soporte para nuevas
propuestas de sistemas con relación al creado dentro de la jefatura.

El proceso de seguimiento de proyectos que se incluye en el
producto software SegPro, es la razón principal del desarrollo del
sistema y la solución de la necesidad es el resultado final.

La implementación de un software a medida permite tener
información integral digitalizada, para ser proporcionada en el
momento requerido y beneficia directamente a la comunidad
Universitaria.

(Fuentes Manzano, 2015)

8. Freire Vargas, Edison J. (2014). “SISTEMA INFORMÁTICO
BASADO EN SOFTWARE LIBRE PARA LA GESTIÓN
DOCUMENTAL EN LA FACULTAD DE CIENCIA E INGENIERÍA
EN ALIMENTOS” (Tesis de pregrado). Universidad Técnica de
Ambato, Ecuador.

Objetivo general:

Hacer que la Facultad de Ciencia e Ingeniería en Alimentos
utilice un software desarrollado con opensource.

Conclusiones:

La factibilidad en el uso de recursos de software libre para la
base de datos, el lenguaje de programación y el servidor web
representan una gran ventaja al aminorar los gastos de
mantenimiento y desarrollo.

Cuando se ejecutaron las pruebas del funcionamiento del
sistema se pudieron detectar errores que luego fueron manejados
correctamente.

Las capacitaciones al personal que hará uso del sistema,
tanto usuarios finales como administrador, dieron éxito, pues el
programa estipulado para estos talleres resultaron con la
familiarización de los interesados y el software, con prácticas
constantes y uso continuo.

Los recursos como la base de datos, el lenguaje de
programación y el servidor web soportan efectivamente lo
esperado con el sistema, por lo que es escalable y adaptable.

(Freire Vargas, 2014)

9. Castillo, Carlos, & Sicacha, Johao (2014). “SOFTWARE DE
REGISTRO Y CONTROL DE MEMBRESÍA Y APORTES PARA
LA IGLESIA CRUZADA CRISTIANA CASA DE RESTAURACIÓN
CALI”. (Proyecto propio) Iglesia Casa de Restauración, Cali,
Colombia.

Objetivo general

Se desea realizar un software que les permita el registro y el
almacenamiento de la membresía con información requerida de
cada persona de la iglesia. A demás que permita captura datos de
aportes voluntarios cada persona y una verificación de los mismos
para el debido reporte ágil cundo se requiere.

Conclusiones

XP se usa de una forma adaptable a cualquier punto de la
vida de cualquier proyecto, considerándose capaz de obtener
resultados más realistas y efectivos.

XP, toman en cuenta los cambios que puedan ir ocurriendo
a medida que se vaya desarrollando el proyecto para de esta
manera mejorar u optimizar la arquitectura del mismo a medida que
este se va llevando a cabo.

XP trabajan de forma iterativa, de manera que en cada una
se vaya mejorando la arquitectura del proyecto y se acerque más
al resultado esperado.

(Castillo & Sicacha, 2014)

10. Anillo Farello, Joly, & Pájaro Martínez, Eduardo E. (2014)
“SISTEMA DE INFORMACIÓN PARA LA GESTIÓN DE LA
MEMBRESÍA DE IGLESIAS CRISTIANAS” (Tesis de pregrado).
Universidad de Cartagena, Colombia.

Objetivo general:

Programar un software para gestionar las membresías de
iglesias evangélicas, creando un modelo de administración interno
en entorno web que mejorará la toma de decisiones y el acceso al
mismo.

Conclusiones

El sistema se implementó de manera efectiva y aporta en la
portabilidad del sistema y su fácil manejo, ayudando a la gestión
de membresía con el modelo de Jesús.

El modelo propuesto fue el adecuado según los resultados
de las encuestas, arrojando un 80% de iglesias encuestadas que
manejan este modelo y se pudo concordar con ellas.

(Anillo Farello & Pájaro Martínez, 2014)

Estas dos últimas tesis tienen un tema parecido a la idea central del
presente proyecto, motivo por el cual fueron consideradas en aspectos que
incluían el desarrollo y la evaluación de procesos que fueron comparados
con la realidad de la organización.

2.2 BASES TEÓRICAS

Los conceptos tratados en la tesis están netamente relacionados a un
tipo de desarrollo de software en entorno web, así como su modo de trabajo.
Para poder comprender y dar un mayor alcance de su orientación, se definirá
a grandes rasgos las bases teóricas de los términos y recursos utilizados en
este trabajo, así como la metodología de desarrollo de software a utilizarse:

Sitio web

Es un conglomerado de páginas en formato web que se
almacena en un hosting y se puede acceder por medio de un
navegador web. Su construcción es en HTML y se reconoce por
medio de un dominio en la World Wide Web. (Pairuna, 2017)

Definido esto, aclaramos la diferencia entre un sitio web y una
página web, siendo el primero el todo y el segundo una parte del
primero. Un sitio web contiene muchas páginas que tienen
información dentro de ellas.

¿Qué es una página web?

Es un documento electrónico que contiene texto, sonido, vídeo,
aplicaciones, enlaces, imágenes, y más cosas, ajustada para ser
utilizada en la conocida World Wide Web (WWW) y a la que se
accede por medio de un navegador web. (Wikipedia, Wikipedia,
Página Web, 2017)

Entre los tipos de páginas web podemos encontrar las páginas
estáticas y páginas dinámicas.

Página web estática
Es una página u hoja web que muestra solamente la
información disponible en la ventana del navegador, sin permitir
realizar interacciones con ella. Esto quiere decir que lo que se
muestra en pantalla es sólo texto o imágenes con el fin de informar,
mas no realizar operaciones dentro de ella. (CEFIRE,
Desconocido)

Página web dinámica
Esta es una página activa y permite que el usuario visitante
navegue dentro de ella realizando operaciones con el uso de
aplicativos en formato web, construyéndose de manera progresiva
mientras se interactúa. (CEFIRE, Desconocido)

Este tipo de páginas son las que se generan con un lenguaje
de programación internamente, entre las que podremos encontrar a:

 ASP (Active server pages): Son páginas del tipo
dinámico parecidas al Visual Basic. (CEFIRE,
Desconocido)

 JSP (Java server pages): Son páginas web dinámicas
que usan Java como lenguaje en su backend. (CEFIRE,
Desconocido)

 PHP (Personal Home Page / Hypertext Preprocessor):
Son páginas web dinámicas al igual que las anteriores,
sólo que su lenguaje es PHP y se maneja de manera
distinta. (CEFIRE, Desconocido)

Para el desarrollo del presente trabajo se hará uso de este tipo
de páginas, con un manejo interno de los procesos con código de
programación.

Sistema Web

Los sistemas web, también llamados ‘aplicaciones Web’ son
aquellos softwares desarrollados para funcionar en un servidor web,
ya sea en una intranet o en un hosting para acceder a ellos por medio
de internet; no son programas de computadora, sino de tipo web.
(Baez, 2012)
Las ventajas de este tipo de sistemas son:
 Compatible en muchas plataformas.
 Actualizable.
 Acceso inmediato.
 Se pueden hacer pruebas fáciles.
 No requieren mucha memoria.
 Pocos bugs.
 Los datos también van online.
 Múltiples usuarios concurrentes.
 Los datos son más seguros.
 Se puede usar el lenguaje que uno quiera.

(Canali de Rosi, s.f.)
33

Dentro de los sistemas web hay muchos lenguajes con los
cuales se puede codificar el software, tales como PHP, JSP,
ASP.NET, etc., pero el usado para este sistema será el Java Server
Pages, más conocido como JSP.

JSP
Es una tecnología de la empresa SUN MICROSYSTEMS que
nos ayuda a crear páginas web dinámicas; Java es su lenguaje de
programación. (Luján Mora, 2002)

Estas páginas JSP contienen parte de código HTML/XML que
hace uso de etiquetas dedicadas para crear scripts del lado del cliente
y luego escribir en el lenguaje Java. Podemos seguir utilizando
nuestro editor de este tipo de texto preferido debido a la mencionada
facilidad del JSP. (Álvarez, 2017)

Con JSP se pueden utilizar etiquetas especiales propias de
HTML y otros lenguajes, puesto que Java se maneja del lado de
servidor. (Fisteus, 2008)

Para realizar las consultas dinámicas a la base de datos,
haciendo uso de los controladores y/o servlets, se utilizará la técnica
de AJAX con objetos JSON.

AJAX

Asynchronous Javascript and XML se puede resumir en las
siglas AJAX; su traducción será Javascript y XML Asíncrono. Fue
Jesse James Garret quien creó el acrónimo en 2005, en su
publicación Ajax: a New Approach to Web Applications (Learning,
2012).

Entonces, ¿para qué usarlo?

Lo bueno de Ajax es que nos permite cargar información de
una base de datos aunque la página ya haya sido cargada en el
navegador. (Learning, 2012)

JSON

JSON (JavaScript Object Notation) es una forma de ordenar los
datos de un objeto, de acuerdo a la estructura propia, y así poder
intercambiarlo con otro formato. Es parecido a XML en la intención.
(RODRÍGUEZ, s.f.)

MySQL

Liderando entre sus semejantes, MySQL es la base de datos
de código libre más conocida en la informática. Tiene un gran
rendimiento, es fácil de usar y fiable.
(Oracle, s.f.)

¿Por qué usar MySQL?
 Acepta muchas plataformas
 Existen blogs de apoyo y soporte
 Aprendizaje fácil
 No es complicado
 Tiene un coste más bajo que sus mayores competidores
Oracle y Sql Server.
 MySQL es escalable
(Instituto Fomento Ocupacional, s.f.)

Apache Tomcat

Es un servidor web que aloja los sistemas web; funciona como
un contenedor y redirecciona las peticiones de estos sistemas desde
el navegador al Servlet en el que se almacena el código dinámico. Lo
ha desarrollado la empresa Apache Software Foundation.
(Edu4Java, s.f.)

Membresía de la Iglesia

Como parte de las labores internas de la congregación cristiana
“El Tabernáculo”, se encuentra el registro interno de los miembros
de la Iglesia, la cual lleva consigo la responsabilidad de mantener la
información íntegra y que pueda ser utilizada en cualquier momento,
sirviendo además como referencia de la cantidad de feligreses que
tiene ésta.

Los procesos que se llevan a cabo para gestionar estos
registros son un tanto tardíos cuando se trata de hacer un cambio
intercongregacional, ya que necesita la confirmación de la Iglesia
emisora. Aparte, los registros son físicos y no se cuenta con un
respaldo en caso de pérdidas o daños.

Una membresía en la Iglesia funciona como una matrícula en
la organización eclesiástica, que incluye algunas responsabilidades
internas y llevar un registro de las personas asistentes para eventos
a nivel regional o simples estadísticas.

Logística interna en una Iglesia

La logística interna de una empresa u organización se basa
en el control y estado de inventario; son procesos internos que
organizan los recursos disponibles para la correcta distribución en
los ambientes requeridos . (Wikipedia, Wikipedia, 2017), pero en
los términos propios de la congregación cristiana en mención, se
encarga del control de los implementos, materiales, equipos y
enseres con las que ésta cuenta.
37

Metodologías de desarrollo de software

Existen 2 grandes grupos en los cuales se puede encontrar
varias metodologías que se adecúen al tipo de trabajo que se
realizó, éstas son las metodologías ágiles y las tradicionales.

Metodologías ágiles

El desarrollo ágil de software es un conjunto de metodologías
de ingeniería del software basado en el desarrollo iterativo e
incremental. En un contexto tan impredecible es importante la
consideración de este tipo de metodologías. (Pastrana, s.f.)

Las metodologías ayudan en la relación directa entre equipo
de desarrollo y el usuario cliente, priorizando el trabajo presencial
antes que documentación innecesaria. (Wikipedia, Wikipedia,
2017)

Entre éstas metodologías se encuentran XP, SCRUM, Crystal
y Agile Unified Process.

 XP
Una metodología muy usada actualmente es la XP o eXtreme
Programming. Para el correcto trabajo en equipo, compartir de
conocimientos entre desarrolladores y buen clima laboral, esta
metodología ha centrado su atención como una clave en el éxito de
los proyectos. (Darío, 2014)

XP se basa en la sencillez, producción de entregables que no
superan las 2 o 3 semanas y con una relación directa con los jefes
de proyecto y del negocio.

Para entender su correcto funcionamiento, se parte de 4
pensamientos:

Diseño simple: El valor real del producto se basa en la
entrega de un programa simple que cumpla con las necesidades
inmediatas del cliente. Esto elimina redundancias y agiliza los
entregables, rediseñado los modelos para futuros usos.
Metáfora: Los programadores crean supuestos y formas de
funcionamiento del sistema que se enfocan en la realización de los
procesos y su cumplimiento de un fin, en vez de usar diagramas,
todo como contar “una historia”.
Propiedad colectiva del código: No existe un solo dueño del
código, sino que todos aportan para el desarrollo y bien colectivo.
Estándar de codificación: Define las normas para escribir y
documentar el código, así como la comunicación entre ellas. Esto
hace que el código en el sistema parezca que fue escrito por una
sola persona. (Procesos de Software, 2017)

Figura 2: Buenas prácticas de XP

 SCRUM
Si bien su utilidad es diversa, se trata de un instrumento
principalmente ventajoso en lugares donde los grupos de trabajo
tienen obstáculos para llevar a cabo las acciones necesarias para
cumplir sus objetivos. (Barcelona, s.f.)
Beneficios:
 Cumple expectativas.
 Flexible.
 Reduce el tiempo de trabajo.
 Mejor calidad de producto final
 Aumenta la relación de producción-esfuerzo
 Disminuye las inversiones
 Controla y predice tiempos
 Riesgos mínimos.
(Softeng, s.f.)

El Sprint es la unidad básica de trabajo de un equipo en
Scrum. Sus iteraciones deben tener resultados enteros, un
producto modular listo para usar, así el cliente pueda hacer uso
íntegro del producto desarrollado cuando lo requiera y sin detalles
engorrosos. (Proyectos Ágiles.org, s.f.)

 Crystal
No necesariamente debe ser mencionada como una sola
metodología, sino como una familia que se caracteriza por tener
una por cada tipo de proyecto y en categorías según la escala de
Cockburn (creador de Crystal).

Los colores empleados en los tipos de equipos indican la
complejidad del proyecto; son puntos importantes a considerar para
el inicio del mismo y el esfuerzo necesario.
 Amarillo, equipos de entre 10 y 20 personas.
 Clear, de 8 o menos personas.
 Naranja, grupos constituidos de 20 a 50 personas.
 Roja, grupos constituidos de 50 a 100 personas.

(Garzás, 2012)

Metodologías tradicionales

Estas metodologías manejan una mayor cantidad de
documentos y tienen como propósito cumplir con toda la
planificación del proyecto, de inicio a fin.
(Avante, 2016)

Metodologías Tradicionales Metodologías Ágiles
- Rigidez frente los cambios, ya sea
lento o rápido.
- Al hacer reuniones, el equipo de
trabajo interactúa con el cliente.
- Grupos grandes que muchas veces
están organizados en lugares
diferentes.
- Los modelos rigen la arquitectura
del software.
- Poca retroalimentación, eso alarga
el tiempo de presentación.
- Pocos roles.
- Es flexible ante los cambios del
proyecto.
- Los clientes están inmersos en el
equipo de trabajo.
- Grupos pequeños de máximo 10
personas en un mismo lugar.
- La arquitectura del software no
tiene casi nada de dependencia.
- La retroalimentación es continua,
acortando el tiempo de
presentación.
- Muchos roles.
41

- Ya tienen normas para desarrollar.
- Las normas y protocolos de la
metodología controla los procesos.
- El desarrollo debe basarse en el
plan inicial, necesariamente.
- Se basan en la heurística de
trabajos parecidos.
- Las normas y los protocolos de la
metodología no controlan mucho
los procesos.
- Los cambios son permitidos de
manera flexible.

Tabla 1: Metodologías Tradicionales VS Ágiles
(Darío, 2014)

RUP (Rational Unified Process o Proceso Unificado de
Rational) es una secuencia de pasos necesarios que ayuda en la
realización de cualquier tipo de proyecto en distintas áreas de
aplicación, medios de competencia y tamaños de proyectos (pues
no necesariamente debe ser uno grande). Asigna
responsabilidades a los diferentes participantes del proyecto,
teniendo en cuenta las actividades y los plazos del mismo, con el
objetivo de que se obtenga un software de buena calidad y que
cumpla las peticiones del (los) usuarios finales, dentro del plazo y
tiempo establecido. (Equipo1, 2012)

2.3 DEFINICIÓN DE TÉRMINOS

Base de datos: es un conjunto de datos organizados con una
estructura que facilita su acceso, gestión y actualización. (Diccionario
de términos informáticos, s.f.)

Data: datos, información. (Diccionario de términos informáticos,
s.f.)

Frontend: Parte visual del diseño de un software que interactúa
con el usuario. (Wikipedia, Wikipedia, s.f.)

Hipertexto: Presentación de información que ayuda a crear y
compartirla, desde diferentes orígenes, haciendo uso de enlace que
relacionan. (Wikipedia, Wikipedia, 2017)

HTML: Acrónimo de Hyper Text Mark-up Language. (Diccionario
de términos informáticos, s.f.)

Hosting: Servicio que ofrecen determinadas empresas para alojar
sitios web y aplicaciones diversas (Diccionario de términos
informáticos, s.f.)

Internet: Gran red mundial de ordenadores interconectados entre
sí, red de redes, con el fin de compartir información. (Diccionario de
términos informáticos, s.f.)
43

Java: Lenguaje de programación orientado a objetos, basado en
C++, útil para el desarrollo de programas y diversos aplicativos.
(Diccionario para informáticos, s.f.)

Javascript: Es un lenguaje que se usa para desarrollar pequeños
programas a insertarse en una página web. Los programas creados
en este lenguaje son compilados en los navegadores. (Valdés, 2007)

Ministerio: Nombre que se le da a los grupos de trabajo dentro de
la iglesia.

Plausible: Admisible, recomendable (Wordreference, s.f.)

Script: Pequeños programas informáticos que necesitan de un
programa principal para ser ejecutados. (Culturación, s.f.)

Servidor: Computadora madre en medio de una red que presta
servicios a los demás nodos de la red. (Diccionario de términos
informáticos, s.f.)

Servlet: Porción de código escrito en el lenguaje de programación
Java, el cual procesa una petición de otra dirección y devuelve un
resultado. (Los Teatinos, 2014)

Software: Término dado a la parte lógica de una computadora, así
como a los programas y aplicativos utilizados en ella. (Diccionario de
términos informáticos, s.f.)

2.4 HIPÓTESIS

2.4.1 Hipótesis General

La tecnología JEE 6 Web mejora la gestión de membresía y
logística interna de la Iglesia Evangélica Pentecostal Misionera “El
Tabernáculo”.

2.4.2 Hipótesis Específicas

Ha1.- Los actores, procesos y requerimientos juegan un papel
muy importante en la gestión de membresía y logística interna de
la Iglesia Evangélica Pentecostal Misionera “El Tabernáculo”

Ha2.- La creación de un estándar de membresía común inter-
congregacional simplifica las actividades de cambio de membresía
o de un nuevo miembro entre la Iglesia Evangélica Pentecostal
Misionera “El Tabernáculo” y sus anexos.

Ha3.- El uso de la tecnología JEE 6 Web que gestiona los
registros de almacén reduce el tiempo de verificación de inventario.

Ha4.- La creación de un sistema informático web interconecta
los registros de miembros de la Iglesia Evangélica Pentecostal
Misionera “El Tabernáculo” y sus anexos.
45

2.5 VARIABLES

Independiente
Tecnología JEE 6 Web
Dependiente
Gestión de Membresía y Logística Interna
Interviniente
Iglesia Evangélica Pentecostal Misionera “El Tabernáculo”

2.5.1 Definición conceptual

Tecnología JEE 6 Web.- Esta es la solución al problema
encontrado como una limitación al realizar las actividades de cambio de
membresía y logística básica, ya que el uso de tecnología existente
puede ser adaptable a la situación en la que se encuentra la Iglesia,
eliminando así obstáculos y tiempo perdido.

Gestión de membresía y logística interna.- Son los procesos
que se ven afectados en el tiempo por factores relacionados al uso de
medios físicos que pueden ser reemplazados por tecnología aplicable a
la situación. Estos procesos son piedras angulares en las actividades
humanas de la congregación, pues definen parte de la estructura y
activos de la organización.

Iglesia Evangélica Pentecostal Misionera “El Tabernáculo”.-
Nombre de la organización objeto de estudio donde se realizó el
proyecto.

2.5.2 Definición operacional

Figura 3: La tecnología JEE 6 Web es aplicada para la mejora de la gestión de
Membresía y Logística Interna de la Iglesia Evangélica Pentecostal Misionera
“El Tabernáculo”

2.5.3 Operacionalización de las variables

Tabla 2: Tecnología JEE 6 Web
Dimensiones Indicadores
 Inicio  Tamaño de la información
 Elaboración  Adaptabilidad
 Construcción  Navegabilidad
 Transición  Eficacia
 Eficiencia

Tabla 3: Gestión de Membresía y Logística Interna
Dimensiones Indicadores
 Registro de miembros  Número de miembros de la Iglesia.
 Proceso de consulta de estado
eclesiástico
 Tiempo de respuesta inter-
congregacional.
 Registro de inventario  Número de elementos en inventario.
 Proceso de inventariado  Tiempo empleado en el proceso de
inventariado.
 Control de inventario  Tiempo empleado en las búsquedas
y/o verificaciones de inventario.
47

CAPÍTULO III

METODOLOGÍA DE LA INVESTIGACIÓN

3.1 DEFINICIÓN DEL TIPO Y NIVEL DE LA INVESTIGACIÓN

3.1.1 Tipo de la investigación

Según Barrantes (2002):

Investigación Aplicada.- Para la resolución del problema
identificado en la Iglesia Evangélica Pentecostal Misionera “El
Tabernáculo” se hace uso de tecnología ya existente, pero se
aplican los conocimientos adquiridos para adaptarlos a la realidad
de la organización.
Este tipo de investigación busca solucionar problemas observables
con el uso de técnicas ya establecidas, no aportar al área científica.
(Barrantes, 2002)

3.1.2 Nivel de la investigación

Según Barrantes (2002):

Descriptiva.- “Usa la observación, estudios correlacionales y de
desarrollo.” (Barrantes, 2002).
Describe los fenómenos ocurrentes en la organización cristiana
para poder obtener las variables y factores que se consideraron al
ejecutar el proyecto y desarrollar el sistema.

3.2 DESCRIPCIÓN DEL ÁMBITO DE LA INVESTIGACIÓN

3.2.1 Método de investigación

Método Analítico - Sintético.- Estudia cada parte del objeto
materia de investigación (análisis) y luego los une para formar un
todo y estudiarlas de manera integral (síntesis). (Bernal Torres,
2010)

3.2.2 Diseño de investigación

Pre-prueba y Post-prueba.- Este diseño, también llamado pre-test
y post-test, ha sido el escogido por su usabilidad en el contraste de
resultados antes y después de la aplicación de una alternativa de solución.
Con el uso de una técnica de recolección de datos se obtendrá la
información necesaria a evaluar para las etapas anterior y posterior a la
posible solución.

Figura 4: Tipos de diseños experimentales y elección del modelo adecuado.

La representación del diseño basada en la muestra experimental
(M) es la siguiente:
𝑀 ∶ 𝑅1 → 𝑋 → 𝑅2
Donde:
M: Muestra experimental o grupo experimental
R1: Resultados de la medición de la Variable Dependiente
“Gestión de membresía y logística interna” (pre-test).
X: Intervención de la Variable Independiente “Tecnología JEE
6 Web” sobre la Variable Dependiente.
R2: Resultados de la medición de la Variable Dependiente tras
la aplicación de la propuesta de solución (post-test).
50

La técnica utilizada para la recolección de los datos se basa en los
indicadores y guarda relación con la situación antes y después de la
aplicación de la posible solución sobre la Variable Dependiente.

3.3 POBLACIÓN Y MUESTRA

3.3.1 Población de investigación

La población para el estudio considera a los líderes y
sublíderes de los distintos ministerios de la Iglesia Evangélica
Pentecostal Misionera “El Tabernáculo”, pues son los usuarios
claves (key users) que manejan la información necesaria para el
uso del sistema.
10 miembros

3.3.2 Muestra de investigación

La muestra para el presente proyecto se estimó siguiendo los
estándares que ofrece la estadística, por ello se hizo uso del
Método No Probabilístico que incluye el Muestreo por
Conveniencia, en el cual, cuando la “población es menos de 50
personas, entonces la muestra será igual que la población”.
(Castro, 2003)

𝒏 = 𝟏𝟎

3.4 RECURSOS PARA LA RECOLECCIÓN DE DATOS

3.4.1 Fuentes de recaudo de información.

Primarias:

Iglesia Evangélica Pentecostal Misionera “El Tabernáculo”

Secundarias:

Internet, libros e informes.

3.4.2 Técnicas de recolección de información.

Primaria:

Encuesta.-

Es una técnica que nos ayuda a obtener datos necesarios
para la medición de factores derivados de una problemática tras la
concepción de una investigación, todo hecho sistemáticamente.
(López Roldán & Fachelli, 2015)

Secundaria:

Búsqueda y análisis de documentación

3.4.3 Instrumentos para recolectar información.

Primaria:

Cuestionario.-

Recurso para recoger datos de manera protocolar a una
determinada muestra o población anónima, con el objetivo de
realizar un análisis posterior. (López Roldán & Fachelli, 2015)

Secundaria:

Fichas de resumen y elementos tecnológicos (computadora,
tablets, software especializado, etc.)

- Excel.-

Software de computadora que nos ayuda a realizar
cálculos gracias al empleo de funciones internas y
organización de la información por filas y columnas.
(Excel Total, 2019)

- IBM® SPSS® Statistics.-

Software especializado utilizado para el cálculo de datos
estadísticos y la interpretación de los mismos. (Guardiola
Jiménez, 2004)

3.5 CONFIABILIDAD Y VALIDEZ DEL INSTRUMENTO

Para realizar la validación del instrumento de recolección de
datos, se tomó en cuenta criterios que ayudaron a darle una mayor
certeza de confiabilidad al mismo. Estos métodos serán aplicados
en el capítulo V, apartado en el que se analizan los resultados de
las encuestas pre-test y post-test.

3.6 PROGRAMA DE RECOLECCIÓN Y PROCESAMIENTO DE DATOS

3.6.1 Programa de recolección de datos.

1.- Objetivo

Ejecutar el proceso de recolección de datos para la tesis de
tecnología JEE 6 web para la gestión de membresía y logística
interna de la Iglesia Evangélica Pentecostal Misionera “El
Tabernáculo”.

2.- Estrategias

Utilización de los recursos.- En la obtención de los datos
necesarios para saber la utilidad y cumplimiento de los objetivos
del trabajo se hizo uso de la técnica de la Encuesta, usando el
cuestionario como herramienta física para recolectar la
información.

Se aplicó los cuestionarios al total de miembros líderes
indicados en la muestra (10), de los cuales se extrajo y analizaron
los datos para obtener los resultados de la aplicación de la tesis.

Recolección de información.- La encuesta se hizo por
grupos seleccionados de líderes indiscriminadamente (10
encuestados en total), siendo éstos convocados por el pastor de la
Iglesia de acuerdo a sus disponibilidades de tiempo y respondiendo
conscientemente, viendo la realidad de la congregación.

 La encuesta se programó en días de la mayor
asistencia de los usuarios participantes a la iglesia.
 El horario de aplicación se estableció después de las
reuniones.
 Sólo se necesitó la presencia del encuestador
(tesista), pastor de la congregación y público de
interés (encuestados).

Al utilizar el diseño de la investigación con resultados pre y
post aplicación, fue necesario considerar 2 períodos de recolección
de información.

Recursos logísticos.- Para la ejecución de la encuesta fue
necesario emplear sólo 10 cuestionarios y algunos lapiceros como
recursos personales.

Primera encuesta (pre test):

Mes Julio 2017
Días 22 23
Horas 9:30 p.m. - 10:00 p.m. 12:00 p.m. - 12:30 p.m.

Tabla 4: Programación de recolección de datos – Pre Test

Figura 5: Programación de recolección de datos – pre test

Segunda encuesta (post test):

Mes Marzo 2019
Días 16 17
Horas 9:30 p.m. - 10:00 p.m. 12:00 p.m. - 12:30 p.m.

Tabla 5: Programación de recolección de datos – Post Test

Figura 6: Programación de recolección de datos - post test

3.6.2 Programa de procesamiento de información.

1.- Objetivo

Realizar el procesamiento de información para la tesis de
tecnología JEE 6 web para la gestión de membresía y logística
interna de la Iglesia Evangélica Pentecostal Misionera “El
Tabernáculo”.

2.- Estrategias

Utilización de los recursos.- Se hizo uso de un ordenador,
digitador (tesista) y el software IBM® SPSS® Statistics 23 para el
procesamiento de la información.

Recolección de información.- Se cumplieron en total 10
cuestionarios rellenados en su totalidad por cada período, los
cuales pasaron a ser tratados en el programa IBM® SPSS®
Statistics 23 para poder obtener los datos estadísticos necesarios
en la evaluación de la tesis.

 Se recolectaron los cuestionarios físicos.
 Se diseñó el área de trabajo en el SPSS para la
introducción de los resultados (digitación de
preguntas, variables y parámetros).
 Se digitalizó los resultados de la encuesta en el
software SPSS.
 Se procedió a generar la información resultante de la
encuesta (alfa de Cronbach), cuadros y gráficos.
 Se analizaron los resultados.
 Se documentaron los resultados.

Mes Marzo 2019
Día 17
Horas 2:00 p.m. – 6:00 p.m.

Tabla 6: Programación de procesamiento de datos
58

CAPÍTULO IV

PROCESOS DE GESTIÓN DE MEMBRESÍA Y LOGÍSTICA
INTERNA DE LA IGLESIA

4.1 SITUACIÓN DEL TRABAJO EN LA IGLESIA

4.1.1 Descripción de los procesos

4.1.1.1 Proceso de membresía

Definición.-

La membresía de la iglesia evangélica pentecostal
misionera “El Tabernáculo” es un permiso con el cual una
determinada persona justifica su pertenencia a la
congregación y, por ende, a la asociación de la iglesia.
Esta, a su vez, conlleva unas determinadas actividades que
convierten al término como un conjunto de procesos
necesarios para el cumplimiento de la misma.
59

Objetivos.-

 Registrar a una persona como miembro de la
congregación.
 Documentar a los miembros para los respectivos
trámites requeridos por el gobierno local.
 Justificar a un miembro para su participación en las
actividades internas de la congregación.
 Brindar información a entidades interesadas sobre
los miembros de la asociación.
 Mantener la información que se requiere de un
miembro en determinados procesos eclesiásticos
intercongregacionales cuando se soliciten
traspasos.
 Mantener un control de los asistentes constantes.
 Información de apoyo para la administración
económica de la iglesia.
 Utilizar la información registrada para generar
reportes estadísticos a conveniencia comunitaria.

Al momento de llevar a cabo el estudio, la
congregación cristiana realizaba sus labores
administrativas con el registro manual en libros físicos. Esto
incluye la gestión de las membresías, las cuales eran
tratadas manualmente y por asistencia de una secretaria.
La asistencia manual no ha cambiado, puesto que siempre
es necesario que una persona se encargue del registro
directo en el medio con el que se cuente.

Actividades del proceso.-

1. Acogida del nuevo asistente:

Se recibe con una bienvenida amistosa a cada
persona nueva que visita la iglesia.

2. Invitación a visitar la iglesia:

Se invita al nuevo visitante a que pueda regresar
a la iglesia para que siga conociendo a Cristo y
comparta gratos momentos en comunión.

3. Conocimiento del asistente:

Se busca conocer más de la persona asistente,
(si es cristiano o no, si asiste a otra iglesia, etc.)
y tener información sobre sus intereses y
deseos en la iglesia.

4. Apreciación y testimonio del asistente:

Se verifica la realidad del asistente con su
testimonio personal, esto es, sus actitudes
dentro y fuera de la iglesia, observando incluso
su disposición de servicio en bien de la
congregación.

5. Cumplimiento de requisitos espirituales:

La iglesia maneja ciertos requisitos previos para
que un asistente se convierta en miembro oficial.

Estos requisitos son el haber aceptado a Cristo
en su corazón como Señor y Salvador y ser
bautizado por inmersión en agua.

En caso de que el asistente haya sido miembro
de otra iglesia antes de llegar a la presente,
debe entregar su carta de recomendación de la
anterior locación eclesiástica.

6. Registro en libro:

Para poder llegar a este punto, el asistente a la
congregación debe haber pasado por un
periodo de evaluación, el cual lo llevan a cabo
los líderes de los ministerios incumbidos en el
proceso.

Si el paso anterior se ha cumplido y verificado
satisfactoriamente, se procede al registro del
nuevo miembro en los libros oficiales de
membresía.

Cuando el nuevo miembro ya es registrado en el
libro, debe adjuntar fotografías y copia de su documento
nacional de identidad (DNI) como un adicional para el
registro, formando parte de la Iglesia y pudiendo realizar
labores internas.

Los pasos 5 y 6 son los únicos que requieren de
documentación e intervención directa de la secretaria.

Los datos a registrar de un nuevo miembro son:

 Nombre del asistente.
 Apellido Paterno.
 Apellido Materno.
 Edad.
 Fecha de nacimiento.
 Número de DNI.
 Ciudad Natal.
 Distrito, provincia y departamento.
 Ocupación.
 Grado de Instrucción.
 Estado Civil.
 Esposo (a) o pareja.
 Nombres y apellidos de los hijos que viven en casa.
 Nombres y apellidos de otros miembros del hogar.
 Dirección de domicilio.
 Observaciones.

Todos estos datos son plasmados en un formulario
que se pega manualmente en un libro. Cada iglesia anexo
tiene un formato propio, el cual se trata de manera
independiente, pero con la aplicación de la tecnología web
esto se resume a un solo modelo estándar.

El registro total es un reporte que puede ser usado
para tener una estadística de los miembros activos, la
cantidad total, información completa de la persona para
poder apoyarlo en necesidades, convocar a actividades,
etc.

Agentes en el proceso de membresía.-

 Secretario (a) de la asamblea.

 Nuevo asistente.

 Pastor.

 Congregación (interviniente, no directa)

 Grupo de ancianos (intervinientes, no directos)

 Pastor de anterior iglesia del asistente
(interviniente, no directo)

Recursos empleados.-

 Los libros físicos en los que se registra la
membresía son del tipo cosido, los que cuentan
con aproximadamente 200 hojas cada uno.

 Impresora, para obtener el modelo a pegar en el
libro de actas.

 Hojas y lapiceros, para registrar los datos en los
formularios.

 Tiempo, recurso intangible no recuperable.

 Personal encargado.

Reglamentación interna.-

 Una persona puede ser miembro de la
congregación si es bautizado, cuenta con una carta
de transferencia, testimonio de ser bautizado en
una iglesia evangélica o tener frutos de
arrepentimiento. (El Tabernáculo, Acta de
Constitución y Aprobación de Estatuto, 2016, pág.
4)

 Un miembro reconocido ya puede cumplir con sus
derechos y deberes dentro de la congregación. (El
Tabernáculo, Acta de Constitución y Aprobación de
Estatuto, 2016, pág. 6)

 Son miembros ordinarios los que pertenecen a
anexos de la Iglesia. (El Tabernáculo, Reglamento
Interno, 2018, pág. 42)

Diagrama de flujo del proceso de membresía.-

Figura 7: Flujo de proceso de membresía

4.1.1.2 Proceso de inventariado

Definición.-

El inventariado de la Iglesia Evangélica
Pentecostal Misionera “El Tabernáculo” es una actividad
que se lleva a cabo una (1) vez al año, al inicio de cada
uno. Esta considera procesos de conteo y verificación,
incluyendo su sustentación en las asambleas llevadas a
cabo en ese mismo período. Trata, principalmente, del
conteo y registro de los activos materiales de la iglesia,
organizado por ministerios y considerado como la logística
interna de la congregación, pues de ella se sirve para las
necesidades materiales en determinadas actividades.

Objetivos.-

 Guardar un registro de los activos materiales de la
congregación.
 Llevar un control de los materiales de cada
ministerio.
 Verificar qué materiales aún son útiles.
 Verificar qué materiales han sido dados de baja.
 Verificar el estado de los artículos en el almacén.
 Generar un reporte de inventario anual de los
materiales.
 Justificar ante la asamblea los materiales
disponibles de la iglesia.

Actividades del proceso.-

En el caso del proceso de inventariado, las labores
para el control de inventario se llevan por fases, ya que el
líder de cada ministerio de la Iglesia presenta un informe
de los materiales bajo su poder, tanto los nuevos como los
ya existentes.

1. Recepción de artículo:

Se hace la recepción del bien (de manera
pública o privada) en el local de la iglesia, ya
sea por donación o por compra.

2. Almacenamiento del artículo:

Se procede a guardar el nuevo bien en el
espacio de almacenamiento perteneciente al
ministerio que lo tendrá a cargo.

3. Conteo de artículos por ministerio:

Trata el conteo físico de los artículos existentes
en el almacén de cada ministerio. Este
bosquejo se apunta en hojas de papel y se hace
una (1) vez al año, a vísperas de la Asamblea
anual.

4. Inventariado de artículos por ministerio:

Cada ministerio registra su conteo anterior en
un documento digital haciendo uso de un
68

programa informático (Word o Excel) para su
posterior impresión; sólo el documento impreso
es el recurso válido para el registro.

Los datos necesarios por cada artículo que se
deben incluir en el reporte final son:

 Nombre del artículo.
 Cantidad
 Categoría
 Marca
 Material
 Color
 Tamaño
 Modelo
 Serie
 Situación física
 Observación

5. Presentación del inventario en asamblea anual:

Cada ministerio hace la sustentación de su
inventario en la reunión de Asamblea anual.

6. Archivamiento de reportes de inventario:

La secretaria de la Iglesia se encarga de
guardar los documentos impresos en un
archivador físico o en fólderes de manila,
ubicados posteriormente en los armarios de la
oficina principal.

Agentes en el proceso de inventariado.-

 Líder de ministerio.

 Secretario (a) de asamblea.

 Asamblea.

 Apoyo (opcional).

Recursos empleados.-

 Fólderes de manila.

 Archivadores de documentos.

 Hojas y lapiceros, para registrar los bosquejos de
inventario y entregar los documentos oficiales.

 Tiempo, recurso intangible no recuperable.

 Personal encargado.

Reglamentación interna.-

 El patrimonio de la Iglesia se puede obtener como
donación o comprado. (El Tabernáculo,
Reglamento Interno, 2018, pág. 5)

Diagrama de flujo del proceso de inventariado.-

Figura 8: Flowchart del proceso de inventariado
71

4.1.2 Deficiencias en los procesos

4.1.2.1 Proceso de membresía

En el flujo que se lleva a cabo en el registro de un nuevo
miembro a la congregación (sea nuevo o ya perteneciente a otra
iglesia) hay tiempos de demora que han sido el punto de interés
para esta tesis:
 Para el proceso de cambio de membresía de iglesia a
iglesia, el tiempo empleado puede verse alterado por
las consultas que se hacen para verificar la
autenticidad de los documentos, comprobaciones de
asistencia, evaluación, etc. Todo esto ocurre pues la
información viaja, de manera física, entre
congregaciones y no existe un medio fiable.

 El registro manual en los libros ha producido ciertos
errores por la escritura del encargado (a).

 Los documentos extra ocupan espacio físico en la
oficina de la congregación, siendo innecesaria cierta
documentación.

 El peligro de pérdida de los libros por factores
externos siempre estará presente (incendios, lluvias,
etc.).

 Los factores económicos (compra de libros) pueden
hacer un pequeño diferencial de gasto a evitar.

 La búsqueda de los datos de un miembro se vuelve
tediosa y ocupa mucho tiempo con una realización
manual.
72

 La información es estática y no es tratable para
reportes.

 No existe un registro de miembros de otros anexos de
la iglesia (congregaciones adjuntas).

4.1.2.2 Deficiencias de inventariado

Este proceso trajo problemas leves anteriormente,
cuando no se supo con exactitud los cambios que hubo en los
haberes del almacén, pues la búsqueda se hacía de forma
manual y no existía un control exacto.

 Tiempo de verificación de errores de inventario.-
Cuando se controla el inventario, es necesario
tomar como referencia los datos anteriores y ver si
existen errores en el nuevo conteo. Esto, al ser
manual, toma un tiempo adicional del que se
espera.

 Registro físico.- El registro de inventario se hacía
en libros físicos que pueden ser reemplazados por
la digitalización.

 El peligro de pérdida de los libros por factores
externos siempre estará presente.

 Los factores económicos (compra de libros)
pueden hacer un pequeño diferencial de gasto que
es bueno evitar.

 La búsqueda de los reportes.- Cuando la
información está sistematizada, es más fácil
conseguir lo requerido.

 Información estática y no disponible para generar
futuros reportes.
74

CAPÍTULO V

RESULTADOS DE LA INVESTIGACIÓN

5.1 Resultados de la investigación

5.1.1 Resultados del Pre - test

 ¿Qué tan manejable considera la información de los miembros
por la cantidad existente en la congregación?

Tabla 7: Frecuencias – Pregunta 1 Cuestionario Pre Test

¿Qué tan manejable considera la información de los miembros por la cantidad
existente en la congregación?

Frecuencia Porcentaje
Porcentaje
válido
Porcentaje
acumulado
Válidos Muy Poco 2 20,0 20,0 20,0
Poco 3 30,0 30,0 50,0
Normal 3 30,0 30,0 80,0
Bastante 2 20,0 20,0 100,0
Total 10 100,0 100,0

Fuente: IBM SPSS
75

Figura 9: Porcentajes de pregunta 1 - Test Previo

Interpretación de resultados: En la tabla, de las 10 personas
encuestadas, un 20% considera que la información de los
miembros es muy poco manejable, otro 30% cree que no hay
inconvenientes y es normal su uso, mientras que un 20% lo
considera bastante manejable. El otro 30% restante cree que se
puede mejorar el uso, pues piensa que es poco manejable, pero
no es tan malo.

 ¿Qué tan rápido es el proceso de cambio de membresía?
Tabla 8: Frecuencias – Pregunta 2 Cuestionario Pre Test

Fuente: IBM SPSS

Figura 10: Porcentajes de pregunta 2 - Test Previo

Interpretación de resultados: Según la tabla de resultados, un
40% de los encuestados considera que el proceso de cambio de
membresía es poco rápido, un 30% cree que es menos rápido
aun, mientras que un 30% lo considera normal.
77

 ¿Qué tan manejable considera la información de elementos de
patrimonio de la iglesia?

Tabla 9: Frecuencias – Pregunta 3 Cuestionario Pre Test

Fuente: IBM SPSS

Figura 11: Porcentajes de pregunta 3 - Test Previo
78

Interpretación de resultados: El valor porcentual más
relevante (50% de la muestra) indica que la mitad de los
encuestados considera poco manejable la información existente
del inventario y sólo un 10% se encuentra en el extremo inferior
de considerarlo muy poco manejable y otro 10% bastante
manejable.

 ¿Qué tan rápido es el proceso de inventariado de elementos de
la iglesia?

Tabla 10: Frecuencias – Pregunta 4 Cuestionario Pre Test

Fuente: IBM SPSS
79

Figura 12: Porcentajes de pregunta 4 - Test Previo

Interpretación de resultados: Un 40% de los encuestados
considera que el proceso de inventariado se lleva a cabo a una
velocidad normal, mientras que el resto se divide
equitativamente con un 30% que piensa que es poco rápido y
otro 30% que lo considera bastante rápido.

 ¿Qué tan rápida es la búsqueda o comprobación de bienes de
la iglesia en el inventario?
Tabla 11: Frecuencias – Pregunta 5 Cuestionario Pre Test

Fuente: IBM SPSS
80

Figura 13: Porcentajes de pregunta 5 - Test Previo

Interpretación de resultados: Según los resultados de la
encuesta, las opiniones están repartidas equitativamente entre
que la velocidad de búsqueda o comprobación de bienes de la
iglesia conforme a la distribución de la logística del inventario es
Muy poco, Poco y Normal con un 30% para cada uno, mientras
que sólo el 10% (1 persona) cree que es Bastante rápida.

 ¿Cuánto cree que soporte un sistema informático toda la
información?

(Siguiente página)

Tabla 12: Frecuencias – Pregunta 6 Cuestionario Pre Test

Fuente: IBM SPSS

Figura 14: Porcentajes de pregunta 6 - Test Previo

Interpretación de resultados: La mitad de los encuestados
considera que un sistema informático soportará con normalidad
toda la información de membresía y logística interna de la iglesia,
un 30% cree que lo soportará bastante, un 10% cree que será
poca su capacidad y otro 10% cree mucho en el potencial de un
sistema.
82

 ¿Qué tanto cree que se adapte un sistema informático a la
realidad de la iglesia?
Tabla 13: Frecuencias – Pregunta 7 Cuestionario Pre Test

Fuente: IBM SPSS

Figura 15: Porcentajes de pregunta 7 - Test Previo

Interpretación de resultados: El 60% de los encuestados
consideran que el sistema se adaptará de forma normal a la
realidad de la iglesia, mientras que un 20% lo considera con
poca capacidad y otro 20% que se adaptará bastante.

 ¿Qué tan fácil considera que será el uso de un sistema
informático?
Tabla 14: Frecuencias – Pregunta 8 Cuestionario Pre Test

Fuente: IBM SPSS

Figura 16: Porcentajes de pregunta 8 - Test Previo

Interpretación de resultados: Tras la encuesta, un 30% de las
personas cree que será poco fácil manejar el sistema, 40% cree
que será fácil sin inconvenientes y 30% que será bastante fácil.

 ¿Qué tanto cree que cumpla con su propósito un sistema
informático?

Tabla 15: Frecuencias – Pregunta 9 Cuestionario Pre Test

Fuente: IBM SPSS

Figura 17: Porcentajes de pregunta 9 - Test Previo

Interpretación de resultados: El 30% de las encuestas señala
que esa cantidad cree que el sistema cumplirá poco con su
propósito, 40% cree que su cumplimiento será normal y otro 40%
cree que cumplirá bastante su propósito. Buena proyección.
85

 ¿Qué tanto cree que un sistema informático mejore la rapidez
de la búsqueda de información?
Tabla 16: Frecuencias – Pregunta 10 Cuestionario Pre Test

Fuente: IBM SPSS

Figura 18: Porcentajes de pregunta 10 - Test Previo

Interpretación de resultados: La mitad de las personas (50%)
cree que el sistema mejorará un tanto la rapidez de búsqueda
de información y aunque las menores cantidades son Poco y
Bastante (10% c/u), un 30% cree que la rapidez de búsqueda
mejorará demasiado.
86

5.1.2 Resultados del Post - test

 ¿Qué tan manejable considera la información de los miembros
por la cantidad existente en la congregación?
Tabla 17: Frecuencias – Pregunta 1 Cuestionario Post Test

Fuente: IBM SPSS

Figura 19: Porcentajes de pregunta 1 - Test Posterior
Interpretación de resultados: La mitad de los encuestados
(50%) considera que la información es normalmente manejable
y el porcentaje resultante se direcciona positivamente, pues un
30% cree que es Bastante manejable y un 20% Demasiado
manejable.
87

 ¿Qué tan rápido es el proceso de cambio de membresía?
Tabla 18: Frecuencias – Pregunta 2 Cuestionario Post Test

Fuente: IBM SPSS

Figura 20: Porcentajes de pregunta 2 - Test Posterior

Interpretación de resultados: Tras la demostración del uso del
sistema, el 40% de los resultados indica que el proceso de
cambio de membresía se considera Normal, 30% lo considera
Bastante rápido, 20% Demasiado rápido y sólo un 1 persona
(10%) lo considera poco rápido aún.
88

 ¿Qué tan manejable considera la información de elementos de
patrimonio de la iglesia?
Tabla 19: Frecuencias – Pregunta 3 Cuestionario Post Test

Fuente: IBM SPSS

Figura 21: Porcentajes de pregunta 3 - Test Posterior

Interpretación de resultados: De las 10 personas
encuestadas, la mitad de ellos considera que la información es
Bastante manejable, 2 personas Demasiado y 3 que es Normal.
La orientación es favorable desde la demostración de la
aplicación.
89

 ¿Qué tan rápido es el proceso de inventariado de elementos de
la iglesia?
Tabla 20: Frecuencias – Pregunta 4 Cuestionario Post Test

Fuente: IBM SPSS

Figura 22: Porcentajes de pregunta 4 - Test Posterior

Interpretación de resultados: Un 50% de los encuestados aún
ven que el proceso de inventariado se lleva con una velocidad
Normal, un 20% creen que es Bastante rápido y otro 30%,
Demasiado.

 ¿Qué tan rápida es la búsqueda o comprobación de bienes de
la iglesia en el inventario?
Tabla 21: Frecuencias – Pregunta 5 Cuestionario Post Test

Fuente: IBM SPSS

Figura 23: Porcentajes de pregunta 5 - Test Posterior

Interpretación de resultados: El 50% de la muestra considera
Normal la velocidad de la búsqueda y comprobación de
información de los bienes según la logística del inventario de la
iglesia. 30% cree que ha mejorado a Bastante y 20%,
Demasiado.
91

 ¿Cuánto cree que soporte un sistema informático toda la
información?
Tabla 22: Frecuencias – Pregunta 6 Cuestionario Post Test

Fuente: IBM SPSS

Figura 24: Porcentajes de pregunta 6 - Test Posterior

Interpretación de resultados: De los resultados, el 50% de
personas creen que el sistema soporta Bastante la información
de membresía y logística interna; 30% cree que soporta
Demasiado y un 30% no ve mayor impacto, sino que es Normal.

 ¿Qué tanto cree que se adapte un sistema informático a la
realidad de la iglesia?
Tabla 23: Frecuencias – Pregunta 7 Cuestionario Post Test

Fuente: IBM SPSS

Figura 25: Porcentajes de pregunta 7 - Test Posterior

Interpretación de resultados: La adaptación del sistema se
considera Normal por un 50% de encuestados, mientras que el
40% cree que se adapta Bastante y una persona (10%) lo ve
muy adaptable.

 ¿Qué tan fácil considera que será el uso de un sistema
informático?
Tabla 24: Frecuencias – Pregunta 8 Cuestionario Post Test

Fuente: IBM SPSS

Figura 26: Porcentajes de pregunta 8 - Test Posterior

Interpretación de resultados: De las 10 personas muestra de
la investigación, 6 consideran fácil el uso del sistema, 3 lo
consideran Bastante fácil y 1 tiene la mayor facilidad de uso con
el puntaje de Demasiado a este indicador.

 ¿Qué tanto cree que cumpla con su propósito un sistema
informático?
Tabla 25: Frecuencias – Pregunta 9 Cuestionario Post Test

Fuente: IBM SPSS

Figura 27: Porcentajes de pregunta 9 - Test Posterior

Interpretación de resultados: Un mayor porcentaje le dio un
puntaje alto de Bastante al cumplimiento de propósito del
software desarrollado, siendo este del 60%. Por otro lado, hay
equidad entre considerarlo Normal y que sea Demasiado eficaz,
con un 20% cada uno.
95

 ¿Qué tanto cree que un sistema informático mejore la rapidez
de la búsqueda de información?
Tabla 26: Frecuencias – Pregunta 10 Cuestionario Post Test

Fuente: IBM SPSS

Figura 28: Porcentajes de pregunta 10 - Test Posterior

Interpretación de resultados: La mitad de personas
encuestadas creen que el sistema mostrado mejora Demasiado
la rapidez de la búsqueda de información, 40% no se aleja de su
valoración, indicando que lo hace “Bastante” y sólo 1 persona
(10%) lo ve Normal.

5.2 Verificación de Hipótesis

5.2.1 Formulación de valores cuantitativos para los indicadores

Para realizar la prueba de hipótesis y validar los resultados
fue necesario determinar un valor cuantitativo para los indicadores
de acuerdo a un rango establecido con referencia a la escala de
Likert, la cual va de un valor mínimo a uno máximo y determina un
dato numérico para cada uno de ellos.

El cuadro de valores es el siguiente:

Figura 29: Adaptación de escala de Likert del proyecto.

El diseño de la investigación fue determinado por el modelo
de Pre Prueba y Post Prueba señalado en el capítulo III, el cual
maneja un grupo de control o grupo experimental que será producto
de los resultados iniciales afectados por la intervención de la
variable independiente de la investigación, dando un segundo
grupo de resultados. El modelo es el siguiente:

1
2
3
4
5
Bastante
Demasiado
Muy Poco
Poco
Normal
97

𝑀 ∶ 𝑅1 → 𝑋 → 𝑅2

Donde:
M: Muestra experimental o grupo experimental
R1: Resultados de la medición de la Variable Dependiente
“Gestión de membresía y logística interna” (pre-test).
X: Intervención de la Variable Independiente “Tecnología JEE
6 Web” sobre la Variable Dependiente.
R2: Resultados de la medición de la Variable Dependiente tras
la aplicación de la propuesta de solución (post-test).

Una vez realizada la aplicación del instrumento a la muestra
a evaluar, se procedió a contrastar los resultados de ambas
encuestas con el uso de la estadística para evaluar la aprobación
o rechazo de la hipótesis principal, lo cual niega o aprueba la
hipótesis nula, respectivamente.

5.2.2 Supuestos de la prueba de hipótesis

1.- La muestra fue seleccionada por el método no probabilístico,
por conveniencia, obteniendo un total de 10 personas que son las
encargadas de las labores de gestión de membresía y logística
interna de la Iglesia Evangélica Pentecostal Misionera “El
Tabernáculo”. Así mismo, se formularon 10 preguntas en un
cuestionario basadas en los indicadores determinados en el
capítulo II.

2.- Un porcentaje de 95% (0.95) se consideró como nivel de
confianza y 5% (0.05) como rango de relevancia o significación.

3.- La hipótesis nula viene a ser la negación de la relación entre
la Variable Dependiente y la Variable Independiente, mientras que
la hipótesis alternativa es aquella determinada en la investigación
que la afirma.

𝐻0: “La tecnología JEE 6 Web no mejora la gestión de membresía
y logística interna de la Iglesia Evangélica Pentecostal Misionera
“El Tabernáculo””

4.- La hipótesis nula 𝐻0 se acepta sólo si el valor calculado 𝑇𝑐 es
menor que el valor en tabla de 𝑇𝑡, de lo contrario se niega y se
acepta la hipótesis alternativa 𝐻𝑎.

Al no conocerse la desviación estándar de la población y
trabajar con la muestra, la cual es menor a 30, se optó por realizar
la validación con la distribución T de Student.

5.2.3 Cálculo del valor crítico y la función de prueba

Tras la aplicación del instrumento y obtener los resultados
de los indicadores en la etapa previa (R1) y la posterior (R2), se
observó que hay una diferencia después de la aplicación de la
tecnología JEE 6 Web a la situación inicial de la variable
dependiente. En el siguiente cuadro se muestran los resultados
obtenidos con los valores necesarios para los siguientes cálculos:

Nº Preguntas R1 R2 𝑫𝒊 𝑫 − ?̅? (𝑫 − ?̅?)
𝟐
P1
¿Qué tan manejable considera la información de los
miembros por la cantidad existente en la
congregación?
2,5 3,7 1,2 0,22 0,0484
P2
¿Qué tan rápido es el proceso de cambio de
membresía?
2 3,6 1,6 0,62 0,3844
P3
¿Qué tan manejable considera la información de
elementos de patrimonio de la iglesia?
2,4 3,9 1,5 0,52 0,2704
P4
¿Qué tan rápido es el proceso de inventariado de
elementos de la iglesia?
3 3,8 0,8 -0,18 0,0324
P5
¿Qué tan rápida es la búsqueda o comprobación de
bienes de la iglesia en el inventario?
2,2 3,7 1,5 0,52 0,2704
P6
¿Cuánto cree que soporte un sistema informático
toda la información?
3,4 3,9 0,5 -0,48 0,2304
P7
¿Qué tanto cree que se adapte un sistema
informático a la realidad de la iglesia?
3 3,6 0,6 -0,38 0,1444
P8
¿Qué tan fácil considera que será el uso de un
sistema informático?
3 3,5 0,5 -0,48 0,2304
P9
¿Qué tanto cree que cumpla con su propósito un
sistema informático?
3,2 4 0,8 -0,18 0,0324
P10
¿Qué tanto cree que un sistema informático mejore
la rapidez de la búsqueda de información?
3,6 4,4 0,8 -0,18 0,0324
Total (∑) 9,8 1,676

Tabla 27: Resumen de resultados de los valores Pre Test y Post Test

Donde:

R1: Media de los indicadores de la Pre Prueba
R2: Media de los indicadores de la Post Prueba
𝑫𝒊: Diferencia entre los indicadores Pre y Post Prueba
𝒏: Muestra de la población
100

Cálculo de la diferencia promedio (?̅?):

?̅? =
∑ 𝐷𝑖
𝑛
=
9.8
10
= 0.98

Cálculo de la desviación estándar de la muestra (𝑺):

𝑆 = √
∑(𝐷𝑖 − ?̅?)2
(𝑛 − 1)
= √
1.676
(10 − 1)
= 0.4315

Cálculo de la función de prueba (𝑻𝒄):

𝑇𝑐 =
?̅?
𝑆
√𝑛
=
0.98
0.4315
√10
= 𝟕. 𝟏𝟖𝟐

1) Hipótesis estática

𝐻0 = 𝑅1 − 𝑅2 ≥ 0
𝐻𝑎 = 𝑅2 − 𝑅1 > 0

2) Nivel de confianza: 95%

𝛼 = 0.05
(1 − 𝛼) = 𝟎. 𝟗𝟓 = 𝟗𝟓%
101

3) Determinación del valor crítico (valor de T Student en tabla)

𝑇𝑡(1 − 𝛼)(𝑛−1)
𝑇𝑡(1 − 0.05)(10−1)
𝑇𝑡(0.95)(9) = 𝟏. 𝟖𝟑𝟑

4) Regiones de confianza y significancia.

Figura 30: Determinación de regiones aceptable y rechazable.

Por lo tanto:

El resultado final del valor de 𝑇𝑐 es 7.182, el cual es mayor
que el valor 𝑇𝑡 de la tabla Student, 1.833, y cumple la condición
de rechazar la hipótesis nula 𝐻0 y aceptar la hipótesis alternativa
𝐻𝑎.
Tras la ejecución del diseño de investigación y el desarrollo
de los cálculos estadísticos, se determina que la tecnología JEE
6 Web mejora la gestión de membresía y logística interna de la
Iglesia Evangélica Pentecostal Misionera “El Tabernáculo, con un
nivel de confianza del 95%.
Región de
rechazo
Región de
aceptación
1.833
Tt
7.182
Tc
102

CAPÍTULO VI

DESARROLLO DE SOLUCIÓN

6.1 EJECUCIÓN DEL PLAN DE DESARROLLO DE LA SOLUCIÓN

6.1.1 Definición de la metodología de desarrollo de software

En la presente tesis se hizo uso de la metodología
tradicional RUP gracias a las fases que se acomodaron al trabajo
y su aplicación de UML en cada una de ellas. Las iteraciones y
su documentación hicieron de esta metodología la opción
adecuada para el desarrollo del software.

Las fases para la elaboración de un proyecto de software
con RUP son las siguientes:

 Fase de Inicio
 Fase de Elaboración
 Fase de Construcción
 Fase de Transición
103

Dentro de cada fase se plantea la documentación de los
artefactos del avance del proyecto, mientras se consideran las
iteraciones de los usuarios finales para posibles cambios en el
producto final.

Tabla 28: Entregables del proyecto
104

6.1.1.1 Fase de inicio

6.1.1.1.1 Generalidades

 Ubicación Geográfica

La Iglesia Evangélica Pentecostal Misionera “El
Tabernáculo” se ubica en el Jr. Iparía Nº 211, al
costado del Restaurante “El Tuyuyo”

 Misión

“Llevar el evangelio de nuestro Señor Jesucristo a
toda la población ucayalina por medio de la prédica
de la Palabra de Dios”

 Visión

“Sembrar la Buena Semilla de la Fe, a fin de que
todo hombre crea en el Señor Jesucristo y tenga
vida eterna según dice el libro de Juan 3:16
<<Porque de tal manera amó Dios al mundo, que
ha dado a su Hijo unigénito, para que todo aquel
que en él cree, no se pierda, más tenga vida
eterna>>”

105

 Organigrama

Figura 31: Organigrama de la Iglesia

 Análisis FLOR
POSITIVO NEGATIVO
FACTORES INTERNOS
FORTALEZAS LIMITACIONES
 Miembros comprometidos con la
iglesia.
 Compromiso grupal con la
sociedad.
 Documentación legal de acuerdo a
reglamentos gubernamentales.
 Organización y funciones
definidas.
 Autonomía económica.
 Unidad de compromiso (un solo
pensamiento).
 Diferencia en pensamientos de
algunos miembros.
 Fondos económicos fluctuantes.
106

FACTORES EXTERNOS
OPORTUNIDADES RIESGOS
 Defensa de derechos por el
gobierno.
 Aumento de personas creyentes
en Dios.
 Autorizaciones para evangelismos
en público.
 Grandes gremios en contra del
cristianismo.
 Vecinos intolerantes.

Tabla 29: Matriz FLOR

6.1.1.1.2 Cálculo de esfuerzo para el desarrollo del
proyecto

Tipo de Actor Descripción Factor
Simple Interfaz del programa 1
Promedio
Interactivo y manejador
de interfaz con
funciones adicionales
2
Complejo
Interfaz gráfica con
permisos completos
3

Tabla 30: Factores de valoración de los actores

Se asigna a cada Usuario su tipo de actor:
 Super usuario o usuario maestro – Complejo
 Administrador de Iglesia – Promedio
 Líder de ministerio y Pastor – Simple

107

El modelo piloto se aplicó a dos iglesias locales
(iglesia de estudio y 1 anexo), las que cuentan con un
administrador, un pastor y un mínimo de 2 líderes de
ministerio (en el caso de la iglesia anexo; el
Tabernáculo cuenta con 10 líderes). En el caso de la
iglesia El Tabernáculo, se cuenta con un pastor y un
co-pastor, que hace labores similares a las del
principal, pero en sujeción a este.

Por lo tanto:

 (1) Super usuario * 3 = 3
 (2) Administradores de Iglesia * 2 = 4
 (12) Líderes de ministerios * 1 = 12
 (3) Pastores * 1 = 3
Peso de los actores: 3 + 4 + 12 + 3 = 22

6.1.1.1.3 Peso de los Casos de Uso

Fuente: Metodología RUP – Cálculo del esfuerzo de Use Case

Tabla 31: Factores de valoración de los Use Case

108

Se asigna a cada caso de uso su tipo:

Nº Código Caso de Uso Factor
1 C.U.A. Inicio de sesión Simple
2 C.U.B. Registro de usuarios Promedio
3 C.U.C. Control de parámetros de membresía e
inventario
Promedio
4 C.U.D. Control de iglesias Simple
5 C.U.E. Control de artículos Promedio
6 C.U.F. Control de membresía Complejo
7 C.U.G. Solicitud de traspaso Simple
8 C.U.H. Respuesta a solicitud de traspaso Promedio
9 C.U.I. Generación de inventario Promedio
10 C.U.J. Modificar contraseña Simple
11 C.U.K. Reportes de membresía Promedio
12 C.U.L. Reportes de inventario Promedio

Tabla 32: Asignación de tipo de proceso de Use Case

109

Por lo tanto:

 (4) Simples * 5 = 20
 (7) Promedios * 10 = 70
 (1) Complejos * 15 = 15

Total de peso de los Use Case: 20 + 70 + 15 = 105

6.1.1.1.4 Cálculo del UUCP

El Ajuste de Puntos de los Case Use (UUCP,
por sus siglas en inglés) indica qué tan complejo es el
proyecto y se determina con la suma de los pesos de
los actores con los de los casos de uso.

Peso de actores + Peso de casos de uso = UUCP
22 + 105 = 127 = UUCP

6.1.1.1.5 Cálculo del TCF

Factor Técnico de Complejidad (TCF). Nos
indica qué tan complejo es el proyecto desde un punto
de vista técnico.

Para calcular el TFC se llenó la siguiente tabla
con valores de 0 a 5. 0 significa que el factor no es
relevante, mientras que un puntaje de 5 significa que
el factor es realmente importante para el proyecto:
110

Tabla 33: Factor Técnico de Complejidad

111

TFactor = ∑ (Peso del Factor) * (TValoresAsignados)
TFactor = 52
TFC = 0.6 + (0.01 * TFactor)
TFC = 0.6 + (0.01 * 52) = 1.12

6.1.1.1.6 Cálculo del EF

Se calculó el nivel de experiencia de las
personas responsables del proyecto; a esto se llama
el Factor Environment, el cual resulta en base a ítems
indicados en la posterior tabla, teniendo en cuenta los
siguientes aspectos:

 De F1 hasta F4: escala de 0 a 5 que indica la
experiencia de menos a más.
 F5: escala de 0 a 5 que indica la motivación en el
proyecto de menos a más.
 F6: escala de 0 a 5 que indica la estabilidad de los
requerimientos de menos a más.
 F7: escala de 0 a 5 que indica en promedio la
existencia o no de personal de medio tiempo.
 F8: escala de 0 a 5 que indica la facilidad de la
programación hasta su dificultad.

En el siguiente cuadro se evaluó el peso de los
factores:

112

Tabla 34: Factor Environment

EFactor = ∑ (Valor Asignado * Peso del Factor)
EFactor = 23.5
EF = 0.35 + (0.03 * EFactor)
EF = 0.35 + (0.03 * 23.5) = 1.055

6.1.1.1.7 Cálculo del UCP

Ahora se hizo uso de la ecuación de los Use
Case Points:

113

UCP = UUCP * TCF * EF
UCP = 127 * 1.12 * 1.055 = 150.0632

6.1.1.1.8 Calculando el Factor Hombre/Horas

Luego de haber obtenido los valores anteriores
sobre los casos de usos, el factor hombre/horas se
determinó de la siguiente forma, usando la tabla de
EF:

De F1 a F6, cantidad de factores menores que 3: 2
De F7 a F8, cantidad de factores mayores que 3: 0

Si el resultado es menor o igual a 2, se
considera para el cálculo un valor de 20 hombres/hora
* UCP; caso contrario, 28 hombres/hora * UCP.

En este caso, al ser la cantidad de factores de
2, el cálculo se hizo con la referencia de 20
hombres/hora * UCP:

20 hombres/hora * 150.0632 UCP = 3001.264
Por lo tanto, 3001.264 unidades es el esfuerzo
que necesitó el proyecto.

114

Con este valor fue posible calcular el tiempo
aproximado para la realización del trabajo, en el que
se considera un total de 54 horas laborales a la
semana (6 días * 9 horas):

3001.264 / 54 = 55.5789 semanas
Que en meses sería un aproximado de:
55.5789 / 4 = 13.894725 o 14 meses aprox.

Este cálculo fue una referencia sujeta a
cambios de acuerdo a las necesidades que se
presenten o factores favorables.

6.1.1.1.9 Costo del proyecto

RECURSOS

Para la realización del proyecto fue necesario
contar con recursos humanos y materiales, pues son
la fuente principal para su ejecución concreta (sin
considerar los recursos de información). Esto, a su
vez, implica una distinción por el tipo de rol que jugará
cada uno de ellos, en especial los recursos humanos,
pues cumplieron una función importante como
usuarios claves para la aplicación de la tecnología
como solución al problema encontrado.

115

 Humanos
De la Iglesia Del proyecto
 Pastor
 Secretaria general
 Líderes de ministerios:
 Tesista:
 Director de proyecto
 Analista de sistema
 Diseñador de sistema
 Programador
 Administrador de base de
datos
 Jóvenes
 Caballeros
 Damas
 Alabanza
 Escuela
dominical
 Diáconos
 Cuerpo de
ancianos

.
Tabla 35: Recursos humanos

 Materiales
De la Iglesia Del proyecto
Físicos Virtuales Físicos Virtuales
 Computadora
de Escritorio
 Módem con
conexión a
Internet
 Navegador
Web
 Hosting
local (o de
alquiler, si
se da el
caso)
 Computadora
personal
 Módem con
conexión a
Internet
 Hojas de
papel
 Lapiceros
 Celular con
cámara
 Software de
desarrollo y pruebas:
 Plataforma IDE
 Motor y gestor de
base de datos
 Navegador Web
 Servidor local

.
Tabla 36: Recursos materiales

116

PRESUPUESTO

Partiendo de los cuadros anteriores en los que
se mencionan los recursos necesarios para la
ejecución del proyecto, se calculó un estimado del
costo del mismo para designar el presupuesto
requerido.

 Humanos
Recursos Costo Mensual (S/.)
De la Iglesia: 0.00
 Pastor 0.00
 Secretaria 0.00
 Líderes de ministerio 0.00
Del Proyecto: 0.00
 Tesista 0.00

Tabla 37: Presupuesto de mano de obra

Al no tener un sueldo o pago para los
participantes del proyecto, ya que hay un acuerdo de
entrega de información a cambio de la realización del
proyecto, el costo por esfuerzo humano resulta con la
cantidad de 0.00 soles.

117

 Materiales
Recursos Costo (S/.)
De la Iglesia: 2160.00
 Computadora de Escritorio 1500.00
 Conexión a internet (S/. 30 * 22 meses) 660.00
 Navegador web 0.00
Del Proyecto: 4784.00
 Computadora personal 2000.00
 Conexión a Internet (S/. 65 * 22 meses) 1430.00
 Hojas de papel (S/. 5 * 22 meses) 110.00
 Lapiceros (S/. 2 * 22 meses) 44.00
 Celular con cámara 1200.00
 Software de desarrollo y pruebas 0.00

Tabla 38: Presupuesto de materiales

En el caso de las computadoras mencionadas
en la tabla y el celular con cámara son recursos ya
disponibles en la congregación, motivo por el cual han
sido marcados pero considerados en el cálculo del
costo total, así como aquellos que fueron necesarios
al finalizar el proyecto.
Entidad Costo total (S/.)
De la Iglesia 2160.00
Del proyecto 4784.00
TOTAL S/. 6944.00

Tabla 39: Total presupuesto de materiales
118

6.1.1.1.10 Plan de desarrollo del software
 Estructura del desglose del trabajo

Figura 32: EDT del proyecto
119

 Cronograma de actividades

Figura 33: Diagrama de Gantt de desarrollo del proyecto
120

6.1.1.1.11 Posicionamiento del producto

Para La Iglesia Evangélica Pentecostal Misionera “El
Tabernáculo”.
Quienes Tienen limitaciones de tiempo y procesos con
errores al momento de realizar sus actividades de
gestión.
Nombre del Producto Sistema Unificado de Membresía y Logística
“SUMO”.
Que Almacena y procesa la información concerniente
a membresía y logística interna para su posterior
uso.
No como Los métodos manuales y almacenamiento físico
de la información sin respaldo y con limitaciones.
El Producto Se encarga de gestionar la membresía y la
logística interna de la congregación cristiana para
tener un mejor control de la información, con
posibilidades de aprovechamiento a futuro con la
implementación de nuevas funcionalidades.

Tabla 40: Definición estratégica del producto.

6.1.1.1.12 Descripción de Stakeholders

Para poder tener una idea más clara de los
roles y responsabilidades de los usuarios dentro del
sistema, es necesario definir las actividades,
permisos y procesos que siguen éstos al hacer uso
del sistema. A continuación, se muestra un resumen
de sus labores organizados en cuadros:

121

 Perfil de Stakeholders

Super User (Usuario maestro)
Descripción
Usuario maestro; maneja todos los
permisos dentro del sistema.
Representantes Juan Manuel Pinto Vela (Actual)
Participación
Es el encargado de administrar los
usuarios del sistema.
Gestiona los miembros iniciales para
crear usuarios.
Administra configuraciones internas
del sistema.
Otorga permisos a los usuarios del
sistema.
Puede administrar la membresía de
su propia iglesia.

Tabla 41: Perfil SuperUser

Secretario (a)
Descripción
Secretario (a) de Asamblea de la
congregación.
Representantes (Por definir en la iglesia y anexo)
Participación
Encargado de crear, modificar y
realizar traspasos de los miembros.
Encargado de revisar los reportes de
los miembros de la congregación.
Encargado de revisar los reportes del
inventario de la iglesia.
122

Administra valores intermedios del
sistema (familias y ministros de
bautizo).

Tabla 42: Perfil Secretario
Líder de ministerio
Descripción
Líder de ministerio, 2 como mínimo
en cada iglesia.
Representantes (Por definir en las iglesias)
Participación
Visualiza los reportes de miembros.
Registra los artículos adquiridos en el
sistema.
Genera el inventario anual de la
congregación.
Visualiza los reportes de inventario.

Tabla 43: Perfil Líder de ministerio

Directiva
Descripción
Conformado por el pastor, co-pastor,
tesorero (a) y presidente de la
Asamblea.
Representantes (Por definir en las iglesias)
Participación
Visualiza los reportes de miembros.
Visualiza los reportes de inventario.

Tabla 44: Perfil Directiva

123

6.1.1.1.13 Elección del diseño de arquitectura del
software

MODELO – VISTA – CONTROLADOR

El diseño comprende tres etapas de la lógica del funcionamiento del
software, los cuales mantienen el orden y la utilización de funciones más
eficientes al momento de reutilizar código o realizar modificaciones al mismo. No
necesariamente funcionan en el orden propuesto, sino que se separan los
componentes de acuerdo a las tareas que cumple cada uno de ellos. Esto es
utilizado para la aplicación de la Orientación a Objetos en la programación del
software.

La orientación a objetos es un paradigma de programación que hace uso
de modelos o plantillas de entidades llamados Objetos para un uso organizado
y estructurado de los datos. Éstos cuentan con atributos que pueden ser
manejados con el uso de métodos y funciones en el código, ayudando a
mantener la integridad de los datos.

124

Para la aplicación de este paradigma se hizo uso del lenguaje de
programación JAVA en su versión Web JEE 6, el cual permite hacer uso de
código del lenguaje para las actividades de procesamiento de información,
dando dinamismo a las páginas y pudiendo desarrollar consultas, inserciones,
modificaciones, entre otros, sin dejar de lado la interfaz de usuario con el
Lenguaje de Marcas de Hipertexto (HTML).

Los elementos involucrados o componentes funcionales en la lógica de
programación del sistema se organizaron en:
 Archivos JSP (Java Server Pages)
 Clases JDBC (Java DataBase Connectivity)
 Clases Java (Orientación a Objetos)
 Servlets

Su organización en la estructura del software es la siguiente:

La representación física del modelo se graficó en la Fase de Construcción.
MODELO:
- Base de datos
- Clases JDBC
CONTROLADOR:
- Servlets
VISTA:
- Ficheros JSP
- CSS
125

6.1.1.1.14 Modelo de Casos de Uso del Negocio

Diagrama 1: Casos de Uso del Negocio

Reseña de símbolos:

Símbolo Descripción

ACTOR
Entidad o rol que participa en el
caso de uso.
En este diagrama:
- Super User
- Secretario (a)
- Líder de ministerio
- Directiva
SuperUser
126

CASO DE USO
Actividad que conlleva
procesos en el funcionamiento
del sistema.
En este diagrama:
- Gestión de registros.
- Proceso de cambio de
iglesia.
- Control de membresía.
- Reportes.
- Control de artículos.
- Generación de
inventario.
RELACIÓN
Une actores y casos de usos
para indicar el tipo de relación
que llevan. Puede ser
unidireccional o bidireccional.

GENERALIZACIÓN
Indica la herencia de un actor
hacia otro. El actor mayor es la
representación de los menores,
que son sintetizados en uno
solo por tener las mismas
características.
En este diagrama:
- Pastor
- Co – pastor
- Tesorero (a)
- Presidente de Asamblea

Tabla 45: Reseña de símbolos en casos de uso
Registro y control de membresía
127

6.1.1.1.15 Modelo de Objetos del negocio

Diagrama 2: Modelo de Objetos - Gestión de registros

Descripción: El SuperUser se encarga de gestionar los registros de usuarios y
algunos parámetros del sistema. El secretario, por otro lado, puede gestionar
sólo parámetros relacionados a la membresía de su iglesia. El líder de ministerio
añade artículos al sistema para luego ser tratados en el inventariado.
128

Diagrama 3: Modelo de Objetos - Control de membresía

Descripción: El Secretario cumple la función principal de registrar a los
miembros en la congregación. Puede también actualizar su información y
visualizarlas. El SuperUser también puede realizar aquellas labores, pero sólo
de su congregación.
129

Diagrama 4: Modelo de Objetos - Proceso de cambio de iglesia

Descripción: El secretario es el responsable principal de los trámites de
aceptación o negación de un miembro nuevo en la congregación. También se
hace la lectura para validación de otras entidades.
130

Diagrama 5: Modelo de Objetos - Control de artículos

Descripción: Los líderes de cada ministerio interno de la iglesia son los
responsables de registrar los nuevos artículos adquiridos por la iglesia y que
pertenecerán a su dominio.

131

Diagrama 6: Modelo de Objetos - Generación de inventario

Descripción: Los líderes de cada ministerio generan los reportes de inventario
anualmente, haciendo uso de los registros de artículos disponibles en su
ministerio. Éstos se pueden actualizar (validar los artículos en el inventario)
mientras la fecha sea vigente.

132

Diagrama 7: Modelo de Objetos – Reportes de Membresía

Descripción: Los usuarios Secretario, Directiva y SuperUser tienen acceso a los
reportes de miembros, solicitado previamente por el pastor o por interés de
labores propio. La entidad Eliminados contiene información anterior de los
miembros que han sido modificados.

133

Diagrama 8: Modelo de Objetos - Reportes de Traspasos

Descripción: Los usuarios Secretario, Directiva y SuperUser tienen acceso a los
reportes de traspasos, los cuales contienen la información de los miembros que
se solicitaron trasladar de anexo, tanto aceptados, negados y los que aún están
en proceso.

134

Diagrama 9: Modelo de Objetos - Reportes de Artículos e Inventarios

Descripción: Todos los usuarios tienen acceso a los módulos de reporte de los
inventarios y artículos registrados, en el apartado de inventario. Cuando se
modifica la cantidad de un artículo al generar un nuevo inventario anual, este
pasa a un listado de modificaciones.
135

Reseña de símbolos:
Símbolo Descripción

BUSINESS WORKER
Actor propio del negocio, interactúa
de manera directa con el sistema
En estos diagramas:
- Super User
- Secretario (a)
- Líder de ministerio
- Directiva

BUSINESS ENTITY
Entidad del negocio. Objeto que
bosqueja la información a almacenar.
RELACIÓN
Une actores y casos de usos para
indicar el tipo de relación que llevan.
Puede ser unidireccional o
bidireccional.

BUSINESS ACTOR
Actor del sistema que solicita un
cambio de su información o reporte
del sistema. No interactúa
directamente con el software, sino
con el actor del negocio.

Tabla 46: Reseña de símbolos - Modelo de Objetos del Negocio
SuperUser
(from GESTION DE REGISTROS)
Miembros
Miembro
136

6.1.1.1.16 Modelo de dominio del proyecto

Diagrama 10: Modelo de Dominio

Descripción: El modelo de dominio del proyecto es la representación física de
cómo se mueve la información en la organización. Este es, a su vez, un bosquejo
de lo que posteriormente será la base de datos del sistema y se puede considerar
un modelo entidad – relación de la misma.

137

6.1.1.2 Fase de elaboración

En esta fase se determinaron los requerimientos del
sistema y se aplicaron los funcionales como requisitos
indispensables para el funcionamiento del software. Los
gráficos mostrados contienen luego las especificaciones de
los casos de uso principales y sus respectivas
dependencias.

6.1.1.2.1 Requerimientos

Especificación de requerimientos de software

 Funcionales:

 El sistema debe disponer de los módulos de
membresía y logística interna.
 El ordenador debe tener instalado el servidor
local Tomcat.
 El sistema debe instalarse de manera local en la
computadora.
 Debe existir, por lo menos, un registro de
usuario en el sistema.
 Debe existir, por lo menos, un registro de iglesia
en el sistema.
 Se requiere de conexión a internet para la carga
de los menús y base de datos.
 Se requiere de un navegador web.

138

 No funcionales:
 Una computadora con altas capacidades de
procesamiento de información.
 Una conexión a internet de alta velocidad.
 Gráficos de estadística.
 Logotipo de las iglesias.

Los requerimientos funcionales fueron
considerados a nivel de software.

139

6.1.1.2.2 Modelo de casos de uso de requerimientos

Mantenimiento de usuarios

Diagrama 11: CUR – Mantenimiento de usuarios
C.U.A
..
C.U.J.
140

Gestión de Registros
Diagrama 12: CUR – Gestión de Registros

C
.U
.C
.1

C
.U
.D
.1
.
C
.U
.C
.2

C
.U
.D
.2
.
C
.U
.E
.
C
.U
.B
.
141

Control de membresía

Diagrama 13: CUR – Control de membresía

C.U.F.1
C.U.F.2
C.U.F.3
142

Cambio de iglesia

Diagrama 14: CUR – Proceso de Cambio de Iglesia

C
.U
.G
.
C
.U
.H
.1

C
.U
.H
.2

143

Generación de inventario

Diagrama 15: CUR – Generación de inventario

C.U.I.
144

Reportes

Diagrama 16: CUR – Reportes

C.U.K.1
C.U.K.2
C.U.K.3
C.U.K.4
C.U.L.1
C.U.L.2
C.U.L.3
C.U.L.4
145

Reseña de símbolos:
Símbolo Descripción

ACTOR
Entidad o rol que participa en el caso
de uso.
En este diagrama:
- Super User
- Secretario (a)
- Líder de ministerio
- Directiva

CASO DE USO
Actividad que conlleva procesos en el
funcionamiento del sistema.
En este diagrama:
- Mantenimiento de usuarios.
- Gestión de registros.
- Control de membresía.
- Cambio de iglesia.
- Generación de inventario.
- Reportes.
RELACIÓN
Une actores y casos de usos para
indicar el tipo de relación que llevan.
Puede ser unidireccional o
bidireccional.

RELACIONES ADICIONALES
Include
Indica la relación interna entre casos
de uso. El caso de uso apuntado con
una relación include será siempre
necesaria para la ejecución del caso
de uso principal.
SuperUser
(from CUR)
C.U.C. - Gestión de registros
(from CUR)
146

Extend
Indica la relación interna entre casos
de uso. El caso de uso que apunta a
otro por medio de la relación extend
puede llevarse a cabo de acuerdo a
los permisos de los usuarios o
actividades únicas.

147

6.1.1.2.3 Especificación de los Use Case

CASO DE USO C.U.A. – Inicio de sesión
BREVE DESCRIPCION Validación de usuario para ingreso al sistema.
ACTORES SuperUser, Secretario, Líder de ministerio, Directiva
PRE CONDICIONES El usuario debe contar con una cuenta en el sistema.
POST CONDICIONES Se obtiene acceso al sistema.
REFERENCIAS C.U.B. – Registro de usuarios
CURSO NORMAL 1. El actor ingresa su usuario y contraseña en los
campos requeridos.
2. El actor presiona el botón “Entrar”.
3. El actor ingresa al sistema.

CURSO ALTERNATIVO 1. Si el usuario y la contraseña no son correctos,
muestra un mensaje de error “Datos
incorrectos”.
2. Si existe un inventariado vencido, se cierra
automáticamente.
PROBLEMAS/COMENTARIOS ---

Tabla 47: Especificación CU - Login
CASO DE USO C.U.B. – Registro de usuarios
BREVE DESCRIPCION Crea, modifica y visualiza los usuarios para acceso al
sistema.
ACTORES SuperUser
PRE CONDICIONES - En la creación: El usuario debe estar registrado
como miembro en el sistema.
- En la modificación: El usuario debe estar registrado
en el sistema
POST CONDICIONES Se crea o actualizan los datos del usuario, incluyendo
su contraseña y permisos.
REFERENCIAS C.U.F. – Control de membresía
CURSO NORMAL El SuperUser ingresa a la pestaña de
Ajustes>Usuarios
En la creación:
1. El SuperUser crea un nuevo usuario haciendo
clic en el botón “Crear”, eligiendo al miembro
correspondiente; sólo se muestran los
miembros con cargo.
En la modificación:
1. El SuperUser selecciona el usuario a
modificar.
148

2. El SuperUser modifica los parámetros del
usuario, como su contraseña y permisos.
En la visualización:
1. Los usuarios se muestran en la vista principal
de la ventana.

CURSO ALTERNATIVO En la modificación:
1. Si las contraseñas no coinciden, el sistema no
permite guardar cambios.

PROBLEMAS/COMENTARIOS Existe la posibilidad de crear un nuevo SuperUser
otorgándole el permiso correspondiente, pero se
recomienda no hacerlo a menos que haya
autorización superior.

Tabla 48: Especificación CU - Control de usuarios

CASO DE USO C.U.C. – Control de parámetros de membresía e
inventario
BREVE DESCRIPCION Crea y visualiza las familias, ministros de bautizo,
categorías y marcas como parámetros del sistema en
la iglesia.
ACTORES Secretario y SuperUser
PRE CONDICIONES El usuario debe tener activado el módulo de
Membresía e Inventario.
POST CONDICIONES Se crean los registros solicitados.
REFERENCIAS ---
CURSO NORMAL El actor ingresa a la pestaña de Ajustes>Membresía y
escoge la opción
>>“Familias”
En la creación:
1. El actor elige la pestaña Familias, llena el
formulario y crea la familia.
En la visualización:
1. Las familias se muestran en la vista principal
de la ventana.
>>“Ministros de bautizo”
En la creación:
1. El actor elige la pestaña Ministros, llena el
formulario y crea el ministro de bautizo.
En la visualización:
1. Los ministros se muestran en la vista principal
de la ventana.
149

El actor ingresa a la pestaña de Ajustes>Inventario y
escoge la opción
>>”Categorías”
En la creación:
1. El actor elige la pestaña Categorías, llena el
formulario, escoge el ministerio y crea el
registro.
En la visualización:
1. Las categorías se muestran en la vista
principal de la ventana.
>>”Marcas”
En la creación:
1. El actor elige la pestaña Marcas, llena el
formulario, escoge el ministerio y crea el
registro.
En la visualización:
1. Las marcas se muestran en la vista principal
de la ventana.
CURSO ALTERNATIVO ---
PROBLEMAS/COMENTARIOS Se debe tener cuidado al momento de digitar los
parámetros pues el guardado es irreversible.
El SuperUser sólo puede crear la información de su
propia iglesia.

Tabla 49: Especificación CU - Control de parámetros de membresía e
inventario

CASO DE USO C.U.D. – Control de iglesias
BREVE DESCRIPCION Crea, visualiza y modifica las iglesias.
ACTORES SuperUser
PRE CONDICIONES El usuario debe ser SuperUser. Debe existir al menos
un miembro registrado como pastor para actualizar
la iglesia.
POST CONDICIONES Se crea una nueva iglesia o se actualiza la
información del pastor encargado de la iglesia.
REFERENCIAS C.U.F. – Control de membresía
CURSO NORMAL El actor ingresa a la pestaña de Ajustes>Iglesias
En la creación:
1. El actor llena el formulario, carga una imagen
como logo y crea la iglesia.
En la modificación:
1. El actor selecciona una de las iglesias de la
lista disponible.
150

2. Puede modificar la dirección, la resolución de
creación y el pastor encargado.
En la visualización:
1. Las iglesias se muestran en la vista principal
de la ventana.
CURSO ALTERNATIVO ---
PROBLEMAS/COMENTARIOS La imagen a cargar debe ser de extensión .jpg o .png
y no debe tener caracteres especiales en el nombre
del archivo.

Tabla 50: Especificación CU - Control de iglesias
CASO DE USO C.U.E. – Control de artículos
BREVE DESCRIPCION Crea y muestra los artículos.
ACTORES Líder de ministerio
PRE CONDICIONES El usuario debe tener activado el módulo de
inventario. Deben existir registros de marcas y
categorías.
POST CONDICIONES Se registra un nuevo artículo en el sistema.
REFERENCIAS C.U.C. – Control de parámetros de membresía e
inventario
CURSO NORMAL 1. El actor ingresa a la pestaña de Inventario y
presiona en el botón de acción lateral
izquierdo.
2. Elige la opción Artículos>Listado.
3. Clic en el botón “Nuevo artículo”.
4. Llena el formulario y presiona el botón
“Registrar”.
En la visualización:
1. Los artículos se muestran en la vista principal
de la ventana.
CURSO ALTERNATIVO Si el artículo a registrar ya se encuentra en la base de
datos (esto es coincidiendo determinados campos),
el sistema mostrará un mensaje de error y no
guardará el artículo.
PROBLEMAS/COMENTARIOS ---

Tabla 51: Especificación CU – Control de artículos

151

CASO DE USO C.U.F. – Control de membresía
BREVE DESCRIPCION Crea, muestra, modifica e imprime la lista de
miembros en la iglesia.
ACTORES Secretario y SuperUser
PRE CONDICIONES El usuario debe tener activado el módulo de
membresía. Deben existir, al menos, una iglesia
registrada en el sistema.
POST CONDICIONES Se crea un nuevo miembro en la iglesia
REFERENCIAS C.U.D. – Control de iglesias
CURSO NORMAL En la creación:
1. El actor ingresa a la pestaña Membresía y
hace clic en el botón “Nuevo Miembro”
2. Ingresa sus nombres y apellidos, tipo de
documento y carga una foto.
3. Llena el formulario de un nuevo miembro.
4. Hace clic en el botón Registrar y se crea un
nuevo miembro.
En la modificación:
1. La lista de miembros se muestra en la interfaz
principal.
2. Se selecciona un nombre de miembro.
3. Se hace clic en el botón Modificar de algunos
campos.
4. Se modifica los parámetros disponibles.
5. Se hace clic en el botón Actualizar.
6. Miembro modificado.
En la visualización:
1. La lista de miembros se muestra en la interfaz
principal de la ventana.
2. Se selecciona un nombre de miembro.
3. El sistema muestra la ficha de registro del
miembro seleccionado.
En la impresión:
1. Se hace clic en el botón con imagen de
impresora.
2. El sistema abre una ventana de impresión.
3. Se configura la hoja de impresión
4. El usuario imprime la hija haciendo clic en el
botón Imprimir.
CURSO ALTERNATIVO Si el miembro ya existe, se rechaza la creación del
miembro.
Sólo el SuperUser tiene la opción de elegir la iglesia
del nuevo miembro.
Si se tiene los permisos adecuados, se puede editar
un miembro haciendo clic en el botón del lápiz.
152

PROBLEMAS/COMENTARIOS La foto cargada debe ser de extensión .jpg o .png y
no contener caracteres especiales en el nombre de
archivo.

Tabla 52: Especificación CU – Control de membresía

CASO DE USO C.U.G. – Solicitud de traspaso
BREVE DESCRIPCION Realiza la solicitud de traspaso de un miembro de
una iglesia a otra.
ACTORES Secretario y SuperUser
PRE CONDICIONES El usuario debe tener activado el módulo de
membresía. El miembro no debe tener una solicitud
en proceso.
POST CONDICIONES Se realiza la solicitud de traspaso de un miembro de
una iglesia a otra.
REFERENCIAS C.U.F. - Control de membresía
CURSO NORMAL 1. El actor ingresa a la pestaña Membresía y
elige un miembro haciendo clic en el nombre.
2. El actor hace clic en el botón inferior derecho
de color carmesí.
3. El actor selecciona la iglesia de destino y
especifica el motivo del traspaso.
4. Hace clic en el botón “Enviar solicitud”
CURSO ALTERNATIVO Si el miembro ya tiene una solicitud en proceso de
respuesta, no se visualiza el botón de solicitud.
PROBLEMAS/COMENTARIOS ---

Tabla 53: Especificación CU - Solicitud de traspaso

CASO DE USO C.U.H. - Respuesta a solicitud de traspaso
BREVE DESCRIPCION Acepta o rechaza la solicitud de traspaso de un
miembro de una iglesia a otra.
ACTORES Secretario y SuperUser
PRE CONDICIONES El usuario debe tener activado el módulo de
membresía. Debe existir una solicitud de traspaso
pendiente.
POST CONDICIONES Un nuevo miembro es registrado en la iglesia o se
rechaza una solicitud de traspaso.
REFERENCIAS C.U.F. - Control de membresía
CURSO NORMAL 1. El actor ingresa a la pestaña Membresía.
153

2. El actor hace clic en el botón inferior derecho
de color verde.
3. El actor selecciona la solicitud a atender.
4. El actor lee el motivo del traspaso de la otra
congregación.
5. El actor revisa la información del otro
miembro.
- El actor acepta el traspaso haciendo clic
en Aceptar.
- El actor niega la solicitud haciendo clic en
Rechazar y llena el campo de Motivo.
CURSO ALTERNATIVO ---
PROBLEMAS/COMENTARIOS ---

Tabla 54: Especificación CU – Respuesta a solicitud de traspaso

CASO DE USO C.U.I. - Generación de inventario
BREVE DESCRIPCION Crea o actualiza el registro de un artículo
inventariado. Muestra los inventarios existentes.
ACTORES Líder de ministerio
PRE CONDICIONES El usuario debe tener activado el módulo de
inventario. Deben existir artículos registrados en el
sistema. El mes actual debe ser enero.
POST CONDICIONES Artículo registrado en el inventariado y reporte
general disponible.
REFERENCIAS C.U.E. - Control de artículos
CURSO NORMAL En la creación:
1. El actor ingresa a la pestaña de Inventario y
presiona en el botón de acción lateral
izquierdo.
2. Elige la opción Nuevo inventario y acepta la
condición de crear un nuevo inventario.
3. Selecciona el artículo a registrar,
especificando su estado actual y la cantidad
disponible del artículo.
4. Hace clic en el botón “+”
5. Se repite el proceso con otros artículos.
6. Una vez finalizados los registros, se cierra el
inventario haciendo clic en el botón
“Generar”.

154

En la modificación:
1. El actor ingresa a la pestaña de Inventario y
presiona en el botón de acción lateral
izquierdo.
2. Elige la opción de Continuar inventario.
3. Selecciona el artículo a registrar,
especificando su estado actual y la cantidad
disponible del artículo.
4. Hace clic en el botón “+”
5. Se repite el proceso con otros artículos.
6. Una vez finalizados los registros, se cierra el
inventario haciendo clic en el botón
“Generar”.
En la visualización:
1. El actor selecciona el año del inventario a
revisar.
CURSO ALTERNATIVO Si el usuario desea, puede dejar el inventariado y
continuarlo hasta el siguiente día, luego de ello se
cierra automáticamente el inventario.
PROBLEMAS/COMENTARIOS ---

Tabla 55: Especificación CU – Generación de inventario

CASO DE USO C.U.J. – Modificar contraseña
BREVE DESCRIPCION Cambia la contraseña de un usuario.
ACTORES SuperUser, Secretario, Líder de ministerio, Directiva
PRE CONDICIONES El actor debe tener un usuario en el sistema.
POST CONDICIONES Se modifica la contraseña de un usuario.
REFERENCIAS C.U.B. - Registro de usuarios
CURSO NORMAL 1. El usuario ingresa a la pestaña
Perfil>Contraseña
2. El usuario ingresa su antigua contraseña.
3. El usuario ingresa la nueva contraseña y a
repite en el siguiente campo.
4. Clic en “Modificar”
CURSO ALTERNATIVO 1. Si la contraseña actual no es la correcta, no
se realiza ningún cambio.
2. Si las contraseñas nuevas no coinciden, no se
permite realizar ningún cambio.
PROBLEMAS/COMENTARIOS ---

Tabla 56: Especificación CU - Cambio de contraseña
155

CASO DE USO C.U.K. - Reportes de membresía
BREVE DESCRIPCION Muestra la lista de miembros registrados en el
sistema, así como los considerados como eliminados
al modificar parámetros avanzados de un miembro.
Muestra las solicitudes de traspaso realizadas y
recepcionadas.
ACTORES SuperUser, Secretario, Directiva
PRE CONDICIONES El actor debe tener activado el módulo de reportes.
POST CONDICIONES Se muestran los resultados solicitantes.
REFERENCIAS C.U.F. - Control de membresía
CURSO NORMAL Lista de miembros:
1. El usuario ingresa a la pestaña
Reportes>Membresía.
2. El usuario selecciona la opción Miembros.
3. El sistema muestra los miembros registrados
en el sistema.
Miembros eliminados:
1. El usuario ingresa a la pestaña
Reportes>Membresía.
2. El usuario selecciona la opción Eliminados.
3. Se muestran los miembros eliminados.
Solicitudes de traspaso:
1. El usuario ingresa a la pestaña
Reportes>Membresía.
2. El usuario selecciona la opción Traspasos.
- El usuario selecciona Enviados
- El usuario selecciona Recepcionados
3. El sistema muestra las solicitudes registradas.
CURSO ALTERNATIVO ---
PROBLEMAS/COMENTARIOS Sólo el SuperUser puede visualizar los registros de
miembros eliminados.

Tabla 57: Especificación CU – Reportes de membresía

CASO DE USO C.U.L. - Reportes de inventario
BREVE DESCRIPCION Muestra los artículos, inventarios y modificaciones
de cantidades de inventario de la iglesia.
ACTORES SuperUser, Secretario, Líder de ministerio, Directiva
PRE CONDICIONES El actor debe tener activado el módulo de reportes.
POST CONDICIONES Se muestran los registros de artículos, inventarios y
modificaciones de cantidades de inventario de la
iglesia.
REFERENCIAS C.U.E. - Control de artículos
156

C.U.I. - Generación de inventario
CURSO NORMAL Muestra de artículos:
1. El usuario ingresa a la pestaña
Reportes>Inventario.
2. El usuario selecciona la opción
Artículos>Listado.
3. Se muestran los artículos registrados.
Muestra de inventarios:
1. El usuario ingresa a la pestaña
Reportes>Inventario.
2. El usuario selecciona la opción
Inventarios>Por año.
3. Se muestran los inventarios generados de los
artículos.
Modificaciones de cantidades:
1. El usuario ingresa a la pestaña
Reportes>Inventario.
2. El usuario selecciona la opción
Artículos>Modificaciones.
3. Se muestran las modificaciones de
cantidades.
CURSO ALTERNATIVO Se puede visualizar los mismos resultados de
artículos en el módulo Inventario.
PROBLEMAS/COMENTARIOS Sólo el SuperUser y Secretario pueden elegir el
ministerio del que desea revisar los inventarios y
artículos.

Tabla 58: Especificación CU – Reportes de inventario

6.1.1.2.4 Análisis y diseño

En la elaboración de los requerimientos del
software es necesario definir cuáles son los elementos
de los casos de uso que se involucran en los distintos
procesos internos del sistema solución. Estos son
plasmados en dos tipos de diagramas, los cuales indican
la manera interna de trabajar del sistema y su
comunicación entre elementos (clases, funciones y
tablas, por ejemplo) que luego son transformados en
157

código que agrega dinamismo al sistema. En esta parte
se muestran los diagramas de colaboración (o de
comunicación) y los diagramas de secuencia. Por motivo
de sintetizar la información, se pasa a mostrar ambos
tipos de diagramas de los casos de uso más relevantes
en el sistema y algunos de ellos agrupados en uno solo.
 Diagramas de Colaboración
Diagrama 17: Diagrama de Colaboración - Login
Diagrama 18: Diagrama de Colaboración - Registro de usuarios
158

Diagrama 19: Diagrama de Colaboración - Registro de Iglesias
159

Diagrama 20: Diagrama de Colaboración - Registro y control de membresía
160

Diagrama 21: Diagrama de Colaboración - Solicitud de cambio de membresía

Diagrama 22: Diagrama de Colaboración - Respuesta a solicitud de cambio de
membresía
161

Diagrama 23: Diagrama de Colaboración - Registro de Artículo

162

Diagrama 24: Diagrama de Colaboración – Generación de Inventario

163

Diagrama 25: Diagrama de Colaboración - Reportes

164

 Diagrama de clases

Diagrama 26: Diagrama de Clases
165

 Diagramas de Secuencia vs Interfaz

Diagrama 27: Diagrama de Secuencia - Login
166

167

168

Diagrama 28: Diagrama de Secuencia - Registro de usuarios

169

170

Diagrama 29: Diagrama de Secuencia - Registro de iglesia

171

172

Diagrama 30: Diagrama de Secuencia - Registro y control de membresía
173

174

175

Diagrama 31: Diagrama de Secuencia - Solicitud de traspaso
176

177

Diagrama 32: Diagrama de Secuencia - Respuesta a traspaso

178

179

Diagrama 33: Diagrama de Secuencia – Crear inventario
180

181

Diagrama 34: Diagrama de Secuencia - Registro de artículo

182

183

Diagrama 35: Diagrama de Secuencia – Reportes
184

185

186

 Diagrama de paquetes del software

Diagrama 36: Diagrama de paquetes del software
187

6.1.1.3 Fase de Construcción

6.1.1.3.1 Análisis y Diseño

 Diseño de Base de Datos

a) Diccionario de datos de tablas principales
Nombre de tabla tarticulo
Descripción Almacena la información básica de un artículo
Nombre de campo Tabla FK Tipo de dato Descripción
IdArticulo (PK) Varchar(10) Código de un artículo
Articulo Varchar(100) Nombre del artículo
Cantidad Int(5) Cantidad de artículos
Estado

Int(1)
Disponibilidad del articulo (activo
o en desuso)
Observacion Varchar(45) Observación del artículo
IdCategoria (FK) tcategoria Varchar(3) Id de categoría del artículo
IdMarca (FK) tmarca Varchar(4) Id de marca del artículo
Serie Varchar(30) Serie del artículo
IdColor (FK) tcolor Varchar(3) Id de color del artículo
IdMaterial (FK) tmaterial Varchar(3) Id del tipo de material del artículo
IdTamanio (FK) ttamanio Varchar(2) Id de tamaño del artículo
Modelo Varchar(30) Modelo del artículo
IdMinIgle (FK)

Varchar(2)
Id del ministerio e iglesia del
artículo
FechaReg Date Fecha de registro del artículo
UsuarioReg (FK) tusuarios Varchar(3) Usuario que registró el artículo
Situacion (FK) testado Int(1) Id de situación del artículo

Tabla 59: Descripción de tabla - TARTICULO
188

Nombre de tabla tcargo
Descripción Contiene los cargos de las autoridades en una iglesia
Nombre de campo Tipo de dato Descripción
IdCargo (PK) Varchar(2) Código de un cargo
Cargo Varchar(45) Cargo

Tabla 60: Descripción de tabla - TCARGO

Nombre de tabla tcategoria
Descripción Almacena las categorías en que se organizan los artículos
Nombre de campo Tabla FK Tipo de dato Descripción
IdCategoria (PK) Varchar(3) Código de una categoría
Categoria Varchar(45) Categoría
IdMinisterio (FK)
tministerio
Varchar(2)
Id del ministerio al que
pertenece.

Tabla 61: Descripción de tabla - TCATEGORIA

Nombre de tabla testado
Descripción
Contiene los datos de estados de un artículo y al
inventariar
Nombre de campo Tipo de dato Descripción
IdEstado (PK) Int(1) Código de estado
Estado Varchar(10) Estado

Tabla 62: Descripción de tabla - TESTADO

189

Nombre de tabla tfamilia
Descripción
Almacena los nombres de las familias a considerar en cada
iglesia.
Nombre de campo Tabla FK Tipo de dato Descripción
IdFamilia (PK) Varchar(4) Código de familia
Familia Varchar(50) Familia
IdIglesia (FK) tiglesia Varchar(2) Id de iglesia de la familia

Tabla 63: Descripción de tabla - TFAMILIA

Nombre de tabla tiglesia
Descripción Almacena la información de las iglesias participantes
Nombre de campo Tabla FK Tipo de dato Descripción
IdIglesia (PK) Varchar(2) Código de iglesia
Iglesia Varchar(100) Nombre de iglesia
Direccion Varchar(100) Dirección de iglesia
ResCrea Varchar(100) Resolución de creación
Pastor (FK) tmiembros Varchar(8) Id de miembro pastor de la iglesia
Logo Varchar(100) Directorio del archivo logo
Estado

Int(1)
Estado de la iglesia (activo o
inactivo)

Tabla 64: Descripción de tabla - TIGLESIA

Nombre de tabla tinvanio
Descripción Almacena los inventarios generados anualmente.
Nombre de campo Tabla FK Tipo de dato Descripción
IdMinIgleAnio (PK) Varchar(5) Código de Inventario
190

IdMinIgle (FK) tmin_igle Varchar(2) Id de ministerio de iglesia
Anio Varchar(4) Año del inventario
Estado

Int(1)
Estado del inventario (abierto o
cerrado)
FechaInicio Date Fecha de inicio del inventariado
UsuarioReg (FK) tusuarios Varchar(3) Usuario que creó el inventario.

Tabla 65: Descripción de tabla - TINVANIO

Nombre de tabla tinventario
Descripción Almacena los registros en un inventario.
Nombre de campo Tabla FK Tipo de dato Descripción
IdInventario (PK) Varchar(10) Código de registro de inventario
IdArticulo (FK) tarticulo Varchar(10) Id de artículo
IdMinIgleAnio (FK) tinvanio Varchar(5) Id de Inventario
IdEstado (FK)
testado
Int(1)
Id de estado de artículo en ese
inventario
Observacion

Varchar(45)
Observaciones del artículo
registrado
Cantidad Int(5) Cantidad actual del artículo

Tabla 66: Descripción de tabla - TINVENTARIO

191

Nombre de tabla tmarca
Descripción Almacena las marcas de los artículos
Nombre de campo Tabla FK Tipo de dato Descripción
IdMarca (PK) Varchar(4) Código de una marca
Marca Varchar(30) Marca
IdMinisterio (FK) tministerio Varchar(2) Id del ministerio al que pertenece.

Tabla 67: Descripción de tabla - TMARCA

Nombre de tabla tmiembros
Descripción Almacena la información de cada miembro
Nombre de campo Tabla FK Tipo de dato Descripción
IdMiembro (PK) Varchar(8) Código del miembro
Nombre Varchar(50) Nombre del miembro
ApePat Varchar(20) Apellido Paterno
ApeMat Varchar(20) Apellido Materno
FechaNac Date Fecha de nacimiento
Localidad Varchar(20) Localidad de nacimiento
Distrito (FK) districts Int(6) Id de Distrito de nacimiento
Provincia (FK) provinces Int(6) Id de Provincia de nacimiento
Departamento (FK)
regions
Int(6)
Id de Departamento de
nacimiento
Ocupacion (FK) tocupacion Varchar(4) Id de Ocupación del miembro
Instrucción (FK)
Tgrado_inst
Varchar(2)
Id de Grado de instrucción
(estudios)
EstCivil (FK) testcivil Int(1) Id de estado civil
TipoDoc (FK)
ttipo_doc
Varchar(2)
Id de Tipo de documento de
identidad
Doc

Varchar(15)
Número de documento de
identidad del miembro
192

RUC Varchar(11) Número de RUC (Opcional)
Pareja

Varchar(100)
Nombre completo de la pareja
del miembro
Direccion Varchar(100) Dirección de casa del miembro
Observaciones Varchar(100) Observaciones hacia el miembro
Familia (FK) tfamilia Varchar(4) Id de familia del miembro
Telefono Varchar(15) Número de teléfono del miembro
Celular Varchar(9) Número de celular del miembro
Email Varchar(60) Correo electrónico del miembro
Bautizo Varchar(7) Confirmación de bautizo
FachaBau Date Fecha de bautizo del miembro
MinBau (FK) tminbau Varchar(3) Id del ministro que lo bautizó
Clase (FK)
tclase
Varchar(2)
Id de la clase a la que asiste el
miembro
Maestro (FK) tmiembros Varchar(8) Id del maestro de la clase
Cargo (FK) tcargo Varchar(2) Id de cargo
FechaReg

Date
Fecha en que se registró al
miembro
UsuarioReg (FK) tusuarios Varchar(3) Usuario que lo registró
IdIglesia (FK) tiglesia Varchar(2) Id de iglesia del miembro
Foto Varchar(100) Directorio de archivo de foto
Oficial Int(1) Oficial o Menor de edad
Estado

Int(1)
Estado de actividad del miembro
(activo o pasivo)
Creado

Int(1)
Confirmación para la creación de
un nuevo miembro.
Eliminado

Int(1)
Validación de actualización de
miembro
IdMiembroNuevo
(FK)

Varchar(8)
Id del miembro referente en la
actualización

Tabla 68: Descripción de tabla - TMIEMBROS
193

Nombre de tabla tmin_igle
Descripción Enlaza un ministerio con la iglesia a la que le pertenece.
Nombre de campo Tabla FK Tipo de dato Descripción
IdMinIgle (PK) Varchar(2) Código del ministerio específico
IdMinisterio (FK) tministerio Varchar(2) Id del ministerio
IdIglesia (FK) tiglesia Varchar(2) Id de iglesia

Tabla 69: Descripción de tabla - TMINIGLE

Nombre de tabla tminbau
Descripción Almacena los ministros de la iglesia u otra que bautizan
Nombre de campo Tipo de dato Descripción
IdMinBau (PK) Varchar(3) Código del ministro
Nombre Varchar(45) Nombre del ministro
ApePat Varchar(45) Apellido Paterno
ApeMat Varchar(45) Apellido Materno
Iglesia Varchar(45) Nombre de la iglesia

Tabla 70: Descripcion de tabla - TMINBAU

Nombre de tabla tministerio
Descripción
Contiene la información de los ministerios genéricos de las
iglesias
Nombre de campo Tabla FK Tipo de dato Descripción
IdMinisterio (PK) Varchar(2) Código del ministerio
Ministerio Varchar(30) Nombre del ministerio
IdCargo (FK)
tcargo
Varchar(2)
Id del cargo del líder
perteneciente al ministerio

Tabla 71: Descripción de tabla - TMINISTERIO
194

Nombre de tabla tregcantidad
Descripción
Almacena las modificaciones de cantidades de los artículos en
el inventariado.
Nombre de campo Tabla FK Tipo de dato Descripción
IdRegCantidad (PK) Int(11) Código del registro
IdArticulo (FK) tarticulo Varchar(10) Id del artículo
Cantidad Int(5) Cantidad antigua del artículo
Fecha Date Fecha de modificación
IdMinIgleAnio (FK) tinvanio Varchar(5) Id de inventario anual.
Tabla 72: Descripción de tabla - TREGCANTIDAD

Nombre de tabla ttraspaso
Descripción Almacena los registros de traspasos de miembros.
Nombre de campo Tabla FK Tipo de dato Descripción
IdTraspaso (PK) Varchar(8) Código de traspaso (PK)
IdMiembro (FK) tmiembros Varchar(8) Id del miembro
SustentoT Varchar(100) Motivo del traspaso
SustentoN

Varchar(100)
Motivo de la negación (en caso
de hacerlo)
Estado

Int(1)
Estado del traspaso (0 – negado,
1 – en espera, 2 – aceptado)
Tabla 73: Descripción de tabla - TTRASPASO

Nombre de tabla ttrasp_emision
Descripción Almacena los registros de traspasos solicitados
Nombre de campo Tabla FK Tipo de dato Descripción
IdTrasp_Emision (PK) Int(8) Código del registro(PK)
IdTraspaso (FK) ttraspaso Varchar(8) Id del traspaso
IdUserE (FK) tusuarios Varchar(3) Id del usuario solicitante
IdIglesiaE (FK) tiglesia Varchar(2) Id de la iglesia solicitante
FechaEmision Date Fecha de la solicitud
Tabla 74: Descripción de tabla - TTRASP_EMISION
195

Nombre de tabla ttrasp_recepcion
Descripción Almacena los registros de traspasos destino y/o aceptados
Nombre de campo Tabla FK Tipo de dato Descripción
IdTrasp_Recepcion (PK) Int(8) Código del registro
IdTraspaso (FK) ttraspaso Varchar(8) Id del traspaso
IdUserR (FK) tusuarios Varchar(3) Id del usuario aceptante
IdIglesiaR (FK) tiglesia Varchar(2) Id de la iglesia destino
FechaRecepcion Date Fecha de recepción

Tabla 75: Descripción de tabla - TTRASP_RECEPCION

Nombre de tabla tusuarios
Descripción Almacena los datos de usuarios del sistema.
Nombre de campo Tabla FK Tipo de dato Descripción
IdUser (PK) Varchar(3) Código del usuario
User Varchar(12) Nombre de usuario
Pass Varchar(32) Contraseña
IdMember (FK) tmiembros Varchar(8) Id del miembro del usuario
Estado

Int(1)
Estado del miembro (1 – activo, 0
– inactivo)
EMMem Int(1) Estado del módulo de membresía
EMInv Int(1) Estado del módulo de inventario
EMLista Int(1) Estado del módulo de reportes
EMEditor Int(1) Estado de permiso de editor
EMaster Int(1) Estado de permiso de SuperUser

Tabla 76: Descripción de tabla - TUSUARIOS

196

Nombre de tabla testcivil
Descripción Contiene los diferentes tipos de estado civil
Nombre de campo Tipo de dato Descripción
IdEstCivil (PK) Int(1) Id de estado civil
EstadoCivil Varchar(12) Estado Civil

Tabla 77: Descripción de tabla - TESTCIVIL

b) Modelo de base de datos

(Siguiente página)
197

Diagrama 37: Modelo de Base de Datos
198

 Clase Conexión de base de datos

package Conexion;

import java.sql.Connection;
import java.sql.DriverManager;

public class ConexionBD {

private String url;
private String driver;
private String error;
private String usuario;
private String contrasena;

public ConexionBD() {

this.url =
"jdbc:mysql://127.0.0.1:3306/sumodb?zeroDateTimeBehavior=convertToNull";
this.driver = "com.mysql.jdbc.Driver";
this.error = "";
this.usuario="root";
this.contrasena="superroot";
}
199

public Connection getConectar() {
try {
Class.forName(driver).newInstance();
return DriverManager.getConnection(url, usuario, contrasena);
} catch (Exception e) {
error = e.getMessage();
System.out.println("error al conectar " + error);
}
return null;
}

public void setConectar(Connection con) {
try {
con.close();
} catch (Exception e) {
error = e.getMessage();
System.out.println("error al desconectar " + error);
}
}

public String getUrl() {
return url;
}
200

public void setUrl(String url) {
this.url = url;
}

public String getDriver() {
return driver;
}

public void setDriver(String driver) {
this.driver = driver;
}

public String getError() {
return error;
}

public void setError(String error) {
this.error = error;
}
}

201

 Representación física de la estructura MVC
(Modelo - Vista - Controlador)
Organización general de ficheros:

Clases por paquetes (Controlador = Servlet):

202

Ficheros Web (Vista)

Modelo:
Representado por el diagrama de base de datos.
203

 Estructura del código por paquetes

Modelo de fichero JSP – MembresiaRep.jsp:
<%@page import="JDBC.jTrasp_Recepcion"%>
<%@page import="JDBC.jUsuario"%>
<%@page import="Clases.cUsuario"%>
<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<%
String idUser = (String) session.getAttribute("idUser");
cUsuario cusuariovali = new cUsuario();
jUsuario jusuariovali = new jUsuario();
cusuariovali = jusuariovali.BuscarxId(idUser);
if (cusuariovali != null && cusuariovali.getEstado() == 1 && cusuariovali.getEMLista() == 1) {
String Iglesia = jusuariovali.BIglesiaxUsuario(cusuariovali.getIdUser());
%>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="viewport" content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-
scale=1.0, minimum-scale=1.0">
<link type="text/css" rel="stylesheet" href="materialize/css/materialize.min.css" media="all"/>
<link type="text/css" rel="stylesheet" href="materialize/css/colores.css" media="all"/>
<link href="https://fonts.googleapis.com/icon?family=Material+Icons" rel="stylesheet">
<link rel="shortcut icon" href="logo/ico.png">
<title>.::SUMO::.</title>
</head>
<body>
<style type="text/css" media="print">
@page { size: landscape; }
</style>
<%@include file="NavBar.jsp"%>
<div class="container">
<h4>Listado de Miembros</h4>
<br>
<br>
<input type="text" id="txtUsuario" name="txtUsuario" value="<%=cusuariovali.getIdUser()%>"
hidden>
<div class="row col s12 right-align"><button class="btn-floating btn-large waves-effect waves-light
blue darken-4" onclick="printDiv('mytable')"><i class="material-icons right">print</i></button></div>
<div class="row">
204

<div class="input-field col s6 offset-s3"><i class="material-icons prefix">search</i><input
type="text" id="buscar" name="buscar" onkeypress="return soloLetras(event)" onkeyup="doSearch()"
autocomplete="off"><label for="buscar">Buscar</label></div>
</div>
<br>
</div>
<div class="row center-align" style="width: 1200px" id="mytable">
<table class="centered bordered highlight" style="border:1px solid #d0d0d0" id="datos">
<thead style="background-color: #e0e0e0">
<tr>
<th rowspan="2">Nº</th>
<th rowspan="2">Nombres</th>
<th rowspan="2">Apellido Paterno</th>
<th rowspan="2">Apellido Materno</th>
<th rowspan="2" style="border:1px solid #d0d0d0">Nº DNI/C.E.</th>
<th colspan="4" style="border:1px solid #d0d0d0">Personales</th>
</tr>
<tr> <th style="border:1px solid #d0d0d0">
<p>
<input type="checkbox" class="filled-in" name="cbcargo" id="cbcargo"
onchange="comprueba()" value="1" />
<label for="cbcargo">Cargo</label>
</p>
</th>
<th style="border:1px solid #d0d0d0">Celular</th>
<th style="border:1px solid #d0d0d0">Membresía</th>
<th style="border:1px solid #d0d0d0">Estado</th>
</tr>
</thead>
<tbody>
</tbody>
</table>
</div>
<script type="text/javascript" src="materialize/jquery-3.2.1.min.js"></script>
<script type="text/javascript" src="materialize/js/materialize.min.js"></script>
<script type="text/javascript" src="materialize/scripts.js"></script>
<script type="text/javascript" src="js/BuscadorTabla.js"></script>
<script type="text/javascript" src="js/usedScripts.js"></script>
<script type="text/javascript" src="js/ajaxInicioRep.js"></script>
</body>
</html>
<%} else {%>
<center><br>Su sesión ha caducado<br><br><a href="sLogin?txtPara=O"><button class="btn waves-
effect waves-light blue darken-4">Ingresar</button></a></center><%}%>
205

Modelo de fichero Clase – cInvAnio.java:
package Clases;
public class cInvAnio {

private String IdMinIgleAnio;
private String IdMinIgle;
private String Anio;
private int Estado;
private String FechaInicio;
private String IdUser;

public cInvAnio(){}

public cInvAnio(String IdMinIgleAnio, String IdMinIgle, String Anio, int Estado, String FechaInicio, String
IdUser){
this.IdMinIgleAnio = IdMinIgleAnio;
this.IdMinIgle = IdMinIgle;
this.Anio = Anio;
this.Estado = Estado;
this.FechaInicio = FechaInicio;
this.IdUser = IdUser;
}

/**
* @return the IdMinIgleAnio
*/
public String getIdMinIgleAnio() {
return IdMinIgleAnio;
}

/**
* @param IdMinIgleAnio the IdMinIgleAnio to set
*/
public void setIdMinIgleAnio(String IdMinIgleAnio) {
this.IdMinIgleAnio = IdMinIgleAnio;
}

public String getIdMinIgle() {
return IdMinIgle;
}

public void setIdMinIgle(String IdMinIgle) {
this.IdMinIgle = IdMinIgle;
}
206

public String getAnio() {
return Anio;
}

public void setAnio(String Anio) {
this.Anio = Anio;
}

public int getEstado() {
return Estado;
}

public void setEstado(int Estado) {
this.Estado = Estado;
}

public String getFechaInicio() {
return FechaInicio;
}

public void setFechaInicio(String FechaInicio) {
this.FechaInicio = FechaInicio;
}

public String getIdUser() {
return IdUser;
}

public void setIdUser(String IdUser) {
this.IdUser = IdUser;
}
}

207

Modelo de fichero JDBC – jInvAnio.java:
package JDBC;

import Clases.cInvAnio;
import Conexion.ConexionBD;
import com.google.gson.Gson;
import com.google.gson.JsonArray;
import com.google.gson.JsonObject;
import java.sql.CallableStatement;
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import javax.naming.NamingException;

public class jInvAnio {

JsonObject JInvAnio;
JsonArray JArray = new JsonArray();
String InvAnio = "";
private ConexionBD dbm = new ConexionBD();
private Connection con = null;
private CallableStatement cs = null;
private ResultSet rs = null;
private boolean resp = false;
private cInvAnio ob;

public String GenerarCodigo() {
String vcorre = "";
int vco = 1;
String sql, vCeros = "";
try {
System.out.println("Conectando");
con = dbm.getConectar();
sql = "SELECT IdMinIgleAnio FROM tinvanio ORDER BY IdMinIgleAnio";
PreparedStatement st = con.prepareStatement(sql, 1005, 1007);//desplazarte
rs = st.executeQuery();
rs.afterLast();
if (rs.previous()) {
vcorre = rs.getString("IdMinIgleAnio");
System.out.println(vcorre);
vco = Integer.parseInt(vcorre);
vco++;
}
208

for (int i = 0; i < 5 - String.valueOf(vco).length(); i++) {
vCeros = vCeros + "0";
}
rs.close();
st.close();
con.close();
} catch (Exception e) {
e.getMessage();
System.out.println(e.getMessage());
}
return (vCeros + vco);
}

public cInvAnio Comprobar(String anio, String idmini) {
cInvAnio obj1 = null;
try {
con = dbm.getConectar();
cs = con.prepareCall("{CALL PA_INVANIO_COMPROBAR(?,?)}");
cs.setString(1, anio);
cs.setString(2, idmini);
rs = cs.executeQuery();
if (rs.next()) {
obj1 = new cInvAnio(rs.getString("IdMinIgleAnio"),
rs.getString("IdMinIgle"),
rs.getString("Anio"),
rs.getInt("Estado"),
rs.getString("FechaInicio"),
rs.getString("UsuarioReg"));
}
} catch (SQLException sqle) {
sqle.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
} finally {
}
return obj1;
}

public String BuscarxId(String id) {
try {
con = dbm.getConectar();
cs = con.prepareCall("{CALL PA_INVANIO_BxID(?)}");
cs.setString(1, id);
rs = cs.executeQuery();
209

if (rs.next()) {
JInvAnio = new JsonObject();
JInvAnio.addProperty("IdMinIgleAnio", rs.getString("IdMinIgleAnio"));
JInvAnio.addProperty("IdMinIgle", rs.getString("IdMinIgle"));
JInvAnio.addProperty("Anio", rs.getString("Anio"));
JInvAnio.addProperty("Estado", rs.getInt("Estado"));
JInvAnio.addProperty("FechaInicio", rs.getString("FechaInicio"));
JInvAnio.addProperty("UsuarioReg", rs.getString("UsuarioReg"));
}
InvAnio = new Gson().toJson(JInvAnio);
} catch (SQLException sqle) {
sqle.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
} finally {
}
return InvAnio;
}

public cInvAnio BuscarxIdObj(String id) { //Lo mismo que el anterior, pero lo guarda en objetos.
cInvAnio obj1 = null;
try {
con = dbm.getConectar();
cs = con.prepareCall("{CALL PA_INVANIO_BxID(?)}");
cs.setString(1, id);
rs = cs.executeQuery();
if (rs.next()) {
obj1 = new cInvAnio(rs.getString("IdMinIgleAnio"),
rs.getString("IdMinIgle"),
rs.getString("Anio"),
rs.getInt("Estado"),
rs.getString("FechaInicio"),
rs.getString("UsuarioReg"));
}
} catch (SQLException sqle) {
sqle.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
} finally {
}
return obj1;
}

public String BuscarxAnio(String anio) {
210

try {
con = dbm.getConectar();
cs = con.prepareCall("{CALL PA_INVANIO_BxANIO(?)}");
cs.setString(1, anio);
rs = cs.executeQuery();
while (rs.next()) {
JInvAnio = new JsonObject();
JInvAnio.addProperty("IdMinIgleAnio", rs.getString("IdMinIgleAnio"));
JInvAnio.addProperty("Ministerio", rs.getString("Ministerio"));
JArray.add(JInvAnio);
}
InvAnio = new Gson().toJson(JArray);
} catch (SQLException sqle) {
sqle.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
} finally {
}
return InvAnio;
}

public boolean Crear(cInvAnio obj) throws NamingException, SQLException {
try {
ob = obj;
con = dbm.getConectar();
cs = con.prepareCall("{call PA_INVANIO_N(?,?,?,?,?,?)}");
cs.setString(1, ob.getIdMinIgleAnio());
cs.setString(2, ob.getIdMinIgle());
cs.setString(3, ob.getAnio());
cs.setInt(4, ob.getEstado());
cs.setString(5, ob.getFechaInicio());
cs.setString(6, ob.getIdUser());
resp = !cs.execute();//el comando cs.execute devuelve true si falló, por eso se niega
} catch (SQLException sqle) {
sqle.printStackTrace();
} finally {
}
return resp;
}

public String Todos(String idminigle) {
try {
con = dbm.getConectar();
cs = con.prepareCall("{CALL PA_INVANIO_TTCERRADO(?)}");
211

cs.setString(1, idminigle);
rs = cs.executeQuery();
while (rs.next()) {
JInvAnio = new JsonObject();
JInvAnio.addProperty("IdMinIgleAnio", rs.getString("IdMinIgleAnio"));
JInvAnio.addProperty("IdMinIgle", rs.getString("IdMinIgle"));
JInvAnio.addProperty("Anio", rs.getString("Anio"));
JInvAnio.addProperty("Estado", rs.getInt("Estado"));
JInvAnio.addProperty("FechaInicio", rs.getString("FechaInicio"));
JInvAnio.addProperty("UsuarioReg", rs.getString("UsuarioReg"));
JArray.add(JInvAnio);
}
InvAnio = new Gson().toJson(JArray);
} catch (SQLException sqle) {
sqle.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
} finally {
}
return InvAnio;
}

public String TodosArticulosInv(String idinvanio) {
try {
con = dbm.getConectar();
cs = con.prepareCall("{CALL PA_INVANIO_BARTICULOS(?)}");
cs.setString(1, idinvanio);
rs = cs.executeQuery();
while (rs.next()) {
JInvAnio = new JsonObject();
JInvAnio.addProperty("IdInventario", rs.getString("IdInventario"));
JInvAnio.addProperty("IdArticulo", rs.getString("IdArticulo"));
JInvAnio.addProperty("Articulo", rs.getString("Articulo"));
JInvAnio.addProperty("Categoria", rs.getString("Categoria"));
JInvAnio.addProperty("Marca", rs.getString("Marca"));
JInvAnio.addProperty("Material", rs.getString("Material"));
JInvAnio.addProperty("Color", rs.getString("Color"));
JInvAnio.addProperty("Tamanio", rs.getString("Tamanio"));
JInvAnio.addProperty("Cantidad", rs.getString("Cantidad"));
JInvAnio.addProperty("Estado", rs.getString("Estado"));
JInvAnio.addProperty("Modelo", rs.getString("Modelo"));
JInvAnio.addProperty("Serie", rs.getString("Serie"));
JInvAnio.addProperty("Observacion", rs.getString("Observacion"));
JInvAnio.addProperty("Observ", rs.getString("Observ"));
212

JArray.add(JInvAnio);
}
InvAnio = new Gson().toJson(JArray);
} catch (SQLException sqle) {
sqle.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
} finally {
}
return InvAnio;
}

213

Modelo de fichero servlet – sIglesia.java:
package Servlets;

import Clases.cIglesia;
import JDBC.jIglesia;
import JDBC.jUsuario;
import java.io.IOException;
import java.io.PrintWriter;
import java.sql.SQLException;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.naming.NamingException;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.swing.JOptionPane;

@WebServlet(name = "sIglesia", urlPatterns = {"/sIglesia"})
public class sIglesia extends HttpServlet {

/**
* Processes requests for both HTTP
* <code>GET</code> and
* <code>POST</code> methods.
*
* @param request servlet request
* @param response servlet response
* @throws ServletException if a servlet-specific error occurs
* @throws IOException if an I/O error occurs
*/
protected void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException, NamingException, SQLException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();

jIglesia jig = new jIglesia();
jUsuario jus = new jUsuario();
cIglesia cig = new cIglesia();

String IdIglesia = "", Iglesia = "", Direccion = "", ResCrea = "", Pastor = "", Logo = "";

String Respuesta = "";
214

char para = request.getParameter("txtPara").charAt(0);

switch (para) {

case 'C':

IdIglesia = request.getParameter("txtIdIglesia");
Iglesia = new String(request.getParameter("txtIglesia").getBytes("ISO-8859-1"), "UTF-8");
Direccion = new String(request.getParameter("txtDireccion").getBytes("ISO-8859-1"), "UTF-8");
ResCrea = new String(request.getParameter("txtResCrea").getBytes("ISO-8859-1"), "UTF-8");
Pastor = "00000000";
Logo = request.getParameter("txtLogo");

cig = new cIglesia(IdIglesia, Iglesia, Direccion, ResCrea, Pastor, Logo);

if (jig.Crear(cig)) {
response.sendRedirect("Churches.jsp?mensaje=creado");
} else {
response.sendRedirect("Churches.jsp?mensaje=nocreado");
}

break;

case 'M':

IdIglesia = request.getParameter("txtIdIglesia");

cig = jig.BuscarxIdObj(IdIglesia);

Iglesia = cig.getIglesia();
Direccion = new String(request.getParameter("txtDireccion").getBytes("ISO-8859-1"), "UTF-8");
ResCrea = new String(request.getParameter("txtResCrea").getBytes("ISO-8859-1"), "UTF-8");
Pastor = request.getParameter("txtIdMiembro");
Logo = cig.getLogo();

cig = new cIglesia(IdIglesia, Iglesia, Direccion, ResCrea, Pastor, Logo);

if (jig.Actualizar(cig)) {
response.sendRedirect("Churches.jsp?mensaje=creado");
}else{
response.sendRedirect("Churches.jsp?mensaje=nocreado");
}

215

break;

case 'T':

Respuesta = jig.Todos();

response.getWriter().write(Respuesta);

break;

case 'U':

String igle = request.getParameter("igle");

Respuesta = jig.BuscarxId(igle);

response.getWriter().write(Respuesta);

break;

case 'I':

String us = request.getParameter("us");

Respuesta = jus.BIglesiaxUsuario(us);

response.getWriter().write(Respuesta);

break;
}
}

// <editor-fold defaultstate="collapsed" desc="HttpServlet methods. Click on the + sign on the left to edit
the code.">
/**
* Handles the HTTP
* <code>GET</code> method.
*
* @param request servlet request
* @param response servlet response
* @throws ServletException if a servlet-specific error occurs
* @throws IOException if an I/O error occurs
*/
@Override
216

protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
try {
processRequest(request, response);
} catch (NamingException ex) {
Logger.getLogger(sIglesia.class.getName()).log(Level.SEVERE, null, ex);
} catch (SQLException ex) {
Logger.getLogger(sIglesia.class.getName()).log(Level.SEVERE, null, ex);
}
}

/**
* Handles the HTTP
* <code>POST</code> method.
*
* @param request servlet request
* @param response servlet response
* @throws ServletException if a servlet-specific error occurs
* @throws IOException if an I/O error occurs
*/
@Override
protected void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
try {
processRequest(request, response);
} catch (NamingException ex) {
Logger.getLogger(sIglesia.class.getName()).log(Level.SEVERE, null, ex);
} catch (SQLException ex) {
Logger.getLogger(sIglesia.class.getName()).log(Level.SEVERE, null, ex);
}
}

/**
* Returns a short description of the servlet.
*
* @return a String containing servlet description
*/
@Override
public String getServletInfo() {
return "Short description";
}// </editor-fold>
}

217

6.1.1.3.2 Implementación

 Diagrama de Red

Diagrama 38: Diagrama de Red

El diagrama de red presentado muestra la distribución de los
componentes dentro de la entidad. Los ordenadores adicionales que se unen a
la red acceden por medio de internet a la base de datos del sistema e instalan el
servidor localmente. Esto se detalla en el diagrama de despliegue.
218

 Diagrama de Componentes

Diagrama 39: Diagrama de Componentes
219

 Diagrama de Despliegue

Diagrama 40: Diagrama de Despliegue lógico del sistema

El sistema SUMO hace uso de la plataforma Java Enterprise Edition en
su 6ta versión, para lo cual corre sus servicios en el servidor Tomcat. Esto
requiere que se cuente con el servicio y se optó por instalarlo localmente en la
computadora a usar, ya que un servidor que soporte JSP en la nube significaba
un costo aún no necesario para la cantidad de iglesias a usarlo (esto está sujeto
a cambios posteriores conforme a la necesidad). La base de datos, por el
contrario, se subió a un servicio del motor MySQL gratuito en la nube, esto hace
que los datos a manejar estén disponibles para todas las máquinas cliente.

220

6.1.1.4 Fase de transición

Esta fase contiene la comprobación y
validación de los distintos procesos por caso de uso
del sistema. Por medio de cuadros de creación y
elaboración propia se validó el correcto uso de los
módulos del sistema con respecto a los
requerimientos funcionales y restricciones propias del
mismo.

Los artefactos de esta fase no necesariamente
fueron entregables en el desarrollo, pero sí
documentados para efectos de justificación y calidad
del software.

 Manual de usuario.
 Validación de restricciones.
 Prueba de use case.

Manual de usuario

Contiene las pautas y consideraciones de uso
del sistema, así como las restricciones de datos
internos del mismo. Se acompaña con ilustraciones,
pasos e indicaciones para un mejor entendimiento.

221

Validación de restricciones

El sistema cumple ciertas restricciones
internas, aparte de los requerimientos funcionales
considerados en el proyecto y desarrollo. Estos
nacieron por la necesidad de tener un mejor control
de los datos y darle la calidad requerida al software,
así como las validaciones internas del sistema,
permisos de usuario, caracteres válidos, etc. A
continuación se presentan las validaciones por medio
de un cuadro.

 : Aprobado
 : Con observación
 : No aprueba

222

Nº Restricción Validez Observaciones
1
Limitación de uso de caracteres especiales en
los campos de formulario.

Sólo se permiten las vocales con
tildes en los nombres de artículos e
iglesias.
2
Limitación de uso de caracteres especiales en
la carga de archivos.

La restricción se indica en el manual
de usuario, mas no se bloquea en el
sistema.
3
Una iglesia sólo puede desactivarse, no
eliminarse.

Se debe informar y documentar en
un acta.
4
El SuperUser crea datos como parámetros del
sistema, excepto las familias, sólo son para su
congregación.

5
Un usuario del sistema mantiene su ID de
miembro aunque se actualice este último, por
integridad de datos.

Se muestra un mensaje en la parte
inferior del detalle de miembro de
usuario si se ha cambiado.
6
Los registros en el sistema no se eliminan, sólo
se cambia su estado de disponibilidad.

7
Se registra el cambio de cantidad de un artículo
cuando se genera un registro de inventario de
este.

El registro se guarda en la tabla
TREGCANTIDAD.
8 Sólo se listan los inventarios cerrados, 
9
Un artículo registrado en el inventariado como
“malo” se da de baja automáticamente.

Se modifica el estado del artículo a
0 (“desuso”) en el campo
correspondiente.
10
Al solicitar un traspaso, se verifica internamente
si existe otro en proceso.

11
Se valida la notificación de nueva solicitud de
traspaso.

Se muestra un botón en la esquina
inferior izquierda de la vista principal
del módulo Membresía,
12
Restricción de edición y visualización de
miembros de otras iglesias.

13
Restricción de edición de miembros
“eliminados” por actualización.

El “Eliminado” es un estado de un
miembro.

Tabla 78: Validación de restricciones del sistema

Prueba de Use Case
Las pruebas de use case son las validaciones
del correcto funcionamiento de los módulos del
sistema con respecto a los requerimientos
funcionales, siendo necesario que cumplan con los
requisitos mínimos. Se muestra los resultados
obtenidos en el siguiente cuadro:
223

Nº Requerimiento funcional Validez Observaciones
1
El sistema debe ser capaz de rechazar un
Login erróneo.

2
El sistema debe ser capaz de diferenciar
entre los tipos de usuarios.

Genera las interfaces y módulos
dependiendo del tipo de usuario.
3
El sistema debe disponer de los módulos
de membresía y logística interna.

4
Los miembros mayores y menores de edad
deben ser registrados en el sistema y ser
diferenciados por un campo.

Un miembro mayor se muestra como
“Oficial”.
5
En el sistema se debe guardar, por lo
menos, la información básica registrada de
un miembro en los libros físicos.

6
Los traspasos deben ser confirmados sólo
por el secretario de Asamblea o por el
creador del sistema.

El SuperUser sólo puede confirmar los
traspasos de su congregación, previa
autorización.
7 Debe existir un registro de los traspasos. 
8
Cada nuevo artículo debe registrarse en el
sistema.

9
El inventariado sólo debe hacerse una vez
al año y en el mes de enero. Este tiene un
plazo de 2 días hábiles como máximo para
culminarse desde que se comienza.

El usuario que crea un inventario de su
ministerio dispone de 2 días para
terminarlo, pues el 3er día se cierra
sistemáticamente al iniciar sesión.
10
Por lo menos debe funcionar el sistema en
la congregación.

11
Se requiere de conexión a internet para el
correcto funcionamiento del sistema.

Los íconos se cargan de un repositorio
online. La base de datos podrá subirse
en un hosting web.
12
Los usuarios deben tener acceso sólo a los
módulos activados.

13
El sistema debe administrar los usuarios de
tal manera que los active o desactive
dependiendo de las políticas internas de las
congregaciones.

14
El sistema debe ser de aspecto amigable y
sencillo de manejar.

15 Debe usarse el navegador Opera o Chrome  También se ejecuta con Firefox

Tabla 79: Prueba por Use Case - Requerimientos funcionales

224

CAPÍTULO VII

DISCUSIÓN DE LOS RESULTADOS

1.1 Contrastación de los resultados

Para comprobar los cambios en los resultados antes y después de
la aplicación de la solución, se hizo uso de un Cálculo de Puntaje propio
para evaluar dichas mejoras de la siguiente manera:
∑ 𝐹𝑖 𝑥 𝑖
5
𝑖=1

Donde: F = Frecuencia del indicador, i = Número de indicador, valor
del mismo.

Luego, se comparan los valores resultantes de ambos momentos de
la encuesta y se obtienen las conclusiones favorables (cuando el
resultado post test es mayor al pre test). Sólo se usó en determinados
casos, en otros se explica con los porcentajes de los resultados.

225

 ¿Qué tan manejable considera la información de los miembros
por la cantidad existente en la congregación?
Resultados Pre – Test

Resultados Post - Test

Discusión: La comparación de ambos cuadros reflejó la
tendencia de opiniones sobre del manejo de información en la iglesia
en cada momento, siendo menor en el pre test con un cálculo de
(2x1) + (3x2) + (3x3) + (2x4) = 25, mientras que en el post test se
direccionan hacia los indicadores mayores con un cálculo de (5x3) +
(3x4) + (2x5) = 37, siendo la diferencia positiva de 12.
226

 ¿Qué tan rápido es el proceso de cambio de membresía?
Resultados Pre - Test

Resultados Post - Test

Discusión: En la prueba previa, predominaba el pensar que
el proceso de cambio de membresía era Poco rápido, con un 40%
de los resultados; en la prueba posterior, aunque predominó el
pensar que se llevaba con una rapidez Normal (40%), la mayoría de
encuestados optaron por respuestas positivas a favor de la mejora
(30% Bastante, 20% Demasiado).
227

 ¿Qué tan manejable considera la información de elementos de
patrimonio de la iglesia?
Resultados Pre - Test

Resultados Post – Test

Discusión: La mitad de los líderes encuestados consideraba
que la información de los miembros y el inventario en la distribución
logística de ellos era manejable a un nivel medio, antes de la
demostración del sistema, mientras que en la prueba posterior se
determinó que la mitad notó una gran mejora, pues la votación
mayoritaria fue de 50% con la elección “Bastante” y sin puntajes de
la escala menor (Poco y Muy Poco)
228

 ¿Qué tan rápido es el proceso de inventariado de elementos de
la iglesia?
Resultados Pre - Test

Resultados Post - Test

Discusión: Como se puede observar en los gráficos, en los
resultados post test aparece el indicador Demasiado con un 30%
mientras desapareció el indicador “Poco” del pre test, con 30%, pero
existe un valor Normal predominante, con un mayor porcentaje en la
nueva prueba. Pre-test: (3x2) + (4x3) + (3x4) = 30; Post-test: (5x3) +
(2x4) + (3x5) = 38. El proceso ha mejorado.
229

 ¿Qué tan rápida es la búsqueda o comprobación de bienes de
la iglesia en el inventario?
Resultados Pre - Test

Resultados Post - Test

Discusión: La búsqueda o comprobación de inventario es
más rápida luego de la aplicación de la variable independiente, pues
el cálculo promedio de satisfacción en la encuesta pre, considerando
la cantidad de elecciones de un indicador por el valor de este (3x1)
+ (3x2) + (3x3) + (1x4) + (0x5) es 22, inferior al de la encuesta post
que resulta (0x1) + (0x2) + (5x3) + (3x4) + (2x5) = 37.
230

 ¿Cuánto cree que soporte un sistema informático toda la
información?
Resultados Pre - Test

Resultados Post - Test

Discusión: Sobre la capacidad de soportar la información, los
resultados indicaron que las personas tuvieron un cambio de
pensamiento después de la aplicación de la solución, inclinándose
todos hacia resultados positivos (los indicadores menores Poco y
Muy Poco no figuraron), lo cual indica que notaron los beneficios del
sistema.
231

 ¿Qué tanto cree que se adapte un sistema informático a la
realidad de la iglesia?
Resultados Pre - Test

Resultados Post - Test

Discusión: Antes de la aplicación de la solución, las personas
no consideraban que un sistema informático podría manejar la
información real de la iglesia sobre gestión de miembros e inventario;
sin embargo, luego de éste, vieron que sí lo hacía y, aunque
predomina el pensar que su adaptación es común de un software,
dejaron los preceptos negativos (Poco) y lo vieron beneficioso.
232

 ¿Qué tan fácil considera que será el uso de un sistema
informático?
Resultados Pre - Test

Resultados Pos - Test

Discusión: Como en toda implementación de software, el
miedo al cambio suele ser un factor muy importante puesto a que no
todas las personas tienen los conocimientos básicos para manejar
una computadora, pero luego de la demostración y uso del sistema,
los usuarios finales se adaptaron al funcionamiento con resultados
positivos en su mayoría.
233

 ¿Qué tanto cree que cumpla con su propósito un sistema
informático?
Resultados Pre - Test

Resultados Post - Test

Discusión: Aunque el pronóstico de los encuestados fue que
el sistema cumpliría satisfactoriamente su propósito (pues esa era la
razón de ser del proyecto), notaron los resultados al finalizarlo y eso
se refleja con los datos obtenidos en la prueba posterior. Pre test:
(2x4) + (4x3) + (4x4) = 32; Post test: (2x3) + (6x4) + (2x5) = 40.

234

 ¿Qué tanto cree que un sistema informático mejore la rapidez
de la búsqueda de información?
Resultados Pre - Test

Resultados Post - Test

Discusión: Hay una gran diferencia entre lo que se pensaba
antes de aplicar la solución y después de hacerlo, pues la
satisfacción fue grande al notar que el sistema proporcionaba de
manera más rápida la información requerida a los líderes, ya sea
propia (líderes de ministerio) y reportes de otros (pastores y
miembros de la Asamblea).
235

CAPÍTULO VIII

ANÁLISIS CRÍTICO Y APORTE A LA ENTIDAD

8.1 Análisis crítico

El estudio aplicado a la problemática sobre la inadecuada gestión
de membresía y logística interna de la iglesia dio lugar al siguiente
planteamiento principal:

¿En qué medida la tecnología JEE 6 Web mejora la gestión de
membresía y logística interna de la Iglesia Evangélica Pentecostal
Misionera “El Tabernáculo”?

Siendo la tecnología JEE 6 Web el medio por el cual se buscó
determinar en qué medida se mejoraba el problema planteado
inicialmente. Este, a su vez, trajo consigo la necesidad de solucionar
otros factores relevantes que apuntaban al problema principal, los cuales
se analizaron individualmente para luego concluir con la aprobación de
la hipótesis principal.

236

1.- ¿Cuáles son los principales actores, procesos y
requerimientos que participan en la gestión de membresía y
logística interna de la Iglesia Evangélica Pentecostal Misionera “El
Tabernáculo”?

Para responder a esta interrogante se planteó como objetivo
identificar los principales actores, procesos y requerimientos que
participan en la gestión de membresía y logística interna de la iglesia,
los cuales se determinaron mientras se realizaba el desarrollo de la
solución, esto es, el software. Para concebir la idea de un producto
solución fue necesario determinar los factores que se involucrarían en
todo el proceso de la aplicación de una metodología de desarrollo de
software, en este caso RUP.

Parte del análisis y abstracción de la realidad de la entidad fue la
identificación de los actores involucrados, los cuales son los líderes de
la congregación. Ellos cumplen roles de acuerdo al cargo que tienen y el
ministerio al que pertenecen, habiéndose organizado de la siguiente
manera:
 Super User
 Secretario (a)
 Líder de ministerio
 Directiva
El Super User sólo es uno general que administra los servicios del
sistema.
El secretario (a) es la persona que gestiona la membresía de su iglesia
y puede visualizar reportes.
El líder de ministerio es el encargado de un área en específica de la
iglesia.
237

La directiva son los miembros representantes que conforman la
asociación de la iglesia.
Por otra parte, cada uno de los procesos que se llevan a cabo en
las labores de gestión de membresía y el control de los inventarios son
determinados por los casos de uso, los cuales ordenan los
procedimientos a seguir en cada actividad y la información que interactúa
en ella. Estos fueron identificados mediante la observación de la
situación de la congregación y los indicadores evaluados en la
investigación. Para más detalles se puede consultar el capítulo VI.

Finalmente, los requerimientos principales son los mismos que los
requisitos funcionales del sistema, los cuales determinan la calidad de
los procesos y su correcto funcionamiento de acuerdo a la normatividad
interna. Estos también se pueden consultar en el capítulo VI.

Todo el análisis presentado también confirma la hipótesis
alternativa secundaria “Los actores, procesos y requerimientos juegan
un papel muy importante en la gestión de membresía y logística interna
de la Iglesia Evangélica Pentecostal Misionera ‘El Tabernáculo’”, dado
que los factores mencionados son vitales en el correcto funcionamiento
del producto solución.

2.- ¿De qué manera se puede reducir el tiempo que tarda el
cambio de membresía entre la Iglesia Evangélica Pentecostal
Misionera “El Tabernáculo” y sus anexos?

Para este planteamiento se propuso realizar el estudio del proceso
de cambio de membresía o de un nuevo miembro entre la iglesia y sus
anexos, elaborando un estándar de membresía común inter-
congregacional.
238

Fue necesario conocer el proceso de cambio de membresía y
creación de un nuevo miembro para poder luego pasar a la identificación
de una alternativa de optimización del aprovechamiento del tiempo
empleado. La investigación arrojó como resultados de la encuesta que
la gente inicialmente no consideraba muy rápido el proceso de cambio
de membresía (pregunta 2 de cuestionario en la encuesta pre test,
capítulo V) pues de las 10 personas encuestadas, 40% considera que el
proceso de cambio de membresía es poco rápido, un 30% cree que es
menos rápido aun, mientras que un 30% lo considera normal.

Según el cálculo establecido en el capítulo VII:

3x1 + 4x2 + 3x3 = 20

Esto impulsó la idea de la creación de un nuevo estándar de
membresía común inter-congregacional entre la iglesia El Tabernáculo y
sus anexos, ya que la información no se consideraba muy manejable
(valores mayoritarios por debajo de Bastante) debido a la forma en que
se llevaba el control de la membresía.

Los resultados de la encuesta después de la implementación de la
solución arrojaron valores positivos: el 40% de los resultados indica que
el proceso de cambio de membresía se considera Normal, 30% lo
considera Bastante rápido, 20% Demasiado rápido y sólo un 1 persona
(10%) lo considera poco rápido aún.

Según el cálculo:

1x2 + 4x3 + 3x4 + 2x5 = 36
239

Este último valor, superior al primero antes de la encuesta de
contrastación, aprueba también la hipótesis alternativa al confirmarse la
mejora:

La creación de un estándar de membresía común inter-
congregacional simplifica las actividades de cambio de membresía o de
un nuevo miembro entre la Iglesia Evangélica Pentecostal Misionera “El
Tabernáculo” y sus anexos.

3.- ¿En qué medida se reducirá el tiempo de verificación y
errores de inventario de la Iglesia Evangélica Pentecostal Misionera
“El Tabernáculo”?

El objetivo apunta a reducir el tiempo de verificación y los errores
del inventario de la iglesia, pero éstos debían ser comprobados con
resultados cuantitativos y así validar la aplicación de la solución. Para
esto, se optó por el cálculo de puntaje determinado en el capítulo VII,
donde cada indicador cuenta con un valor según la escala de Likert y se
multiplica con la frecuencia de cada uno, obteniendo el puntaje total de
la suma de estos productos.

Así, el puntaje obtenido en el pre - test fue:
(3x1) + (3x2) + (3x3) + (1x4) + (0x5) = 22

Mientras el puntaje del post – test fue:
(0x1) + (0x2) + (5x3) + (3x4) + (2x5) = 37

240

Determinados los valores, se tiene que la población encuestada
valoraba la rapidez del proceso de cambio de membresía con 22 puntos.
Hay una diferencia de 15 puntos con respecto a la prueba posterior y
para saber cuánto mejoró el proceso con la implementación del sistema,
se considera el resultado anterior como el 100% y el nuevo será el
porcentaje mejorado. Esto es:
22 → 100%
37 → 𝑥%
=> 𝑋 =
37𝑥100
22
= 168.181818

Siendo entonces 37 el equivalente al 168.18% de 22, el porcentaje
de mejora es de 68.18% (el total menos el porcentaje inicial, 100%). De
esa manera se responde al planteamiento secundario y se acepta la
hipótesis alternativa:

El uso de la tecnología JEE 6 Web que gestiona los registros de
almacén reduce el tiempo de verificación de inventario

4.- ¿De qué manera se pueden interconectar los registros de
miembros de la Iglesia Evangélica Pentecostal Misionera “El
Tabernáculo” con sus anexos?

Resolver este planteamiento requirió de la observación de la
realidad de la iglesia y proponer incluir el registro de membresías
propias y de sus anexos en un sistema informático web. Como todo el
trabajo está enfocado en el desarrollo de un software para mejorar la
gestión de miembros y la logística interna, la inclusión de los miembros
en un sistema y la distribución de usuarios por iglesias anexadas son
241

parte de los requerimientos del software, considerado también con la
aceptación de la hipótesis anterior sobre el cambio de membresía.

Así, la cuarta hipótesis alternativa es aceptada:

La creación de un sistema informático web interconecta los
registros de miembros de la Iglesia Evangélica Pentecostal Misionera
“El Tabernáculo” y sus anexos.

Finalmente, para el problema general, el objetivo de la
investigación es determinar que la tecnología JEE 6 Web mejora la
gestión de membresía y logística interna de la Iglesia Evangélica
Pentecostal Misionera “El Tabernáculo”, para lo cual también se necesitó
realizar el cálculo de puntaje general de las preguntas tras la realización
de las encuestas pre-test y post-test:
∑ 𝐹𝑖 𝑥 𝑖
5
𝑖=1

Pre Test:
Valor del
Indicador
Frecuencia de las preguntas
1º 2º 3º 4º 5º 6º 7º 8º 9º 10º
1 2 3 1 0 3 0 0 0 0 0
2 3 4 5 3 3 1 2 3 2 1
3 3 3 3 4 3 5 6 4 4 5
4 2 0 1 3 1 3 2 3 4 1
5 0 0 0 0 0 1 0 0 0 3 ∑
∑ 25 20 24 30 22 34 30 30 32 36 283
Tabla 80: Cálculo de puntaje – Pre Test

Los resultados obtenidos dan como puntaje final un valor de 283,
estándar de la situación de la gestión de miembros y logística interna de
la iglesia antes de la implementación de la solución.
242

Post Test:
Valor del
Indicador
Frecuencia de las preguntas
1º 2º 3º 4º 5º 6º 7º 8º 9º 10º
1 0 0 0 0 0 0 0 0 0 0
2 0 1 0 0 0 0 0 0 0 0
3 5 4 3 5 5 3 5 6 2 1
4 3 3 5 2 3 5 4 3 6 4
5 2 2 2 3 2 2 1 1 2 5 ∑
∑ 37 36 39 38 37 39 36 35 40 44 381
Tabla 81: Cálculo de puntaje – Post Test

Los resultados obtenidos dan como puntaje final un valor de 381,
teniendo este un exceso de 98 puntos sobre el primer resultado, lo cual
indica que sí hubo una mejora de los procesos de control de miembros
e inventario de acuerdo a la perspectiva de la población encuestada.

Culminando esto, se responde de manera cuantitativa al objetivo
de “Determinar que la tecnología JEE 6 Web mejora la gestión de
membresía y logística interna de la Iglesia Evangélica Pentecostal
Misionera ‘El Tabernáculo’”, teniendo la validación de hipótesis ya
realizada en el capítulo V, apartado 5.2.3.

243

8.2 Aporte técnico

TECNOLOGÍA JEE 6 WEB PARA LA GESTIÓN DE MEMBRESÍA Y
LOGÍSTICA INTERNA DE LA IGLESIA EVANGÉLICA PENTECOSTAL
MISIONERA “EL TABERNÁCULO”

 Determina roles en la iglesia.- El software permite que un miembro
líder cuente con un usuario específico en el sistema y se tenga un
mejor control de la información por áreas.

 Reduce costos, tiempo y esfuerzo.- El empleo de documentación
física se reduce al utilizar recursos virtuales, así como el tiempo
empleado en los procesos de registro y control de la información y por
ende el esfuerzo empleado, ya sea físico o mental, al tener la
información almacenada en un solo sistema que facilita lo requerido.

 Simplifica proceso de cambio de membresía.- Con un sistema
unificado, la verificación de información de miembros de una
congregación a otra se hace con sólo revisarla en el sistema, no
siendo necesaria la visita física de los encargados al anexo de la
iglesia.

 Reduce el tiempo de verificación de inventario.- Al tener los datos
históricos de los inventarios anuales, no es necesario crear una nueva
lista del patrimonio de la iglesia, sino que se pueden generar reportes
y trabajar con esa información. De la misma forma, se corroboran
datos anteriores para comprobar el estado de los actuales.

 Facilita información.- Cuando la información de miembros de la
iglesia e inventario se encuentra en una base de datos del sistema,
ésta es accesible para los usuarios registrados y permite contar con
los reportes para cada uno, dependiendo de sus permisos en éste.
244

CAPÍTULO IX

CONCLUSIONES Y RECOMENDACIONES

9.1 Conclusiones

Tras la culminación de la presente tesis, se concluyó que la hipótesis
principal propuesta inicialmente fue aceptada tras rechazar la hipótesis nula; esto
tras determinar el valor de “T” en tabla de 1.833 y resultar el valor de “T” calculado
en 7.182, siendo éste mayor y cumpliendo con el supuesto inicial de rechazar la
hipótesis nula sólo si el valor de T en tabla es menor que el valor de T calculado.
También se concluyó lo siguiente con respecto a los objetivos de la
investigación:

1) Se identificaron los principales actores, procesos y requerimientos
que participan en la gestión de membresía y logística interna de la
iglesia, siendo estos:

Actores: Cada uno de los líderes encuestados que son la muestra y
a la vez población de la investigación. Ellos cumplen roles de acuerdo
al cargo que tienen y el ministerio al que pertenecen. En el capítulo VI
se identifican los actores de acuerdo a la metodología de desarrollo
de software utilizada y el sistema SUMO los diferencia.
245

Procesos: Estos son determinados en el capítulo VI en los casos de
uso, los cuales ordenan los procedimientos a seguir en cada actividad
y la información que interactúa en ella. Estos fueron identificados
mediante la observación de la situación de la congregación y los
indicadores evaluados en la investigación.

Requerimientos: Cada uno de los requisitos funcionales del sistema
fue identificado de acuerdo a la necesidad de las actividades de
gestión de membresía e inventariado, los cuales son tratados en el
capítulo VI.

2) Se realizó el estudio del proceso de cambio de membresía o creación
de un nuevo miembro entre la Iglesia Evangélica Pentecostal
Misionera “El Tabernáculo” y sus anexos en los capítulos IV y VI,
determinando los factores relevantes del proceso e implementándolos
en el sistema, y se elaboró un estándar de membresía común inter-
congregacional como formulario de registro.

3) Se redujo el tiempo de verificación de inventario en un 68.18%, de
acuerdo a lo comprobado en el capítulo VII de la discusión de
resultados, en la pregunta ¿Qué tan rápida es la búsqueda o
comprobación de bienes de la iglesia en el inventario?, con una
ventaja de 15 puntos de la post encuesta sobre los 22 de la pre
encuesta (post = 37), representando ese valor el porcentaje mejorado;
se diseñó una base de datos de los haberes en almacén, necesario
para el desarrollo del sistema implementado.

4) Se incluyó el registro de membresías de la Iglesia Evangélica
Pentecostal Misionera “El Tabernáculo” y sus anexos en el sistema
informático web SUMO.

246

9.2 Recomendaciones

1) Los líderes encargados de cada ministerio de la iglesia deben llevar a
cabo las responsabilidades asignadas de acuerdo a sus roles con el
uso del sistema, respetando los procesos determinados en el mismo
y los requerimientos funcionales establecidos.

2) Debe respetarse los procedimientos de creación de un miembro así
como las restricciones de cambio de membresía. Aunque estos son
validados en el sistema, se recomienda revisar los manuales creados
con el fin de llevar a cabo correctamente las actividades. El estándar
de membresía constituye el medio común de información básica a
registrar de un miembro, motivo por el cual se debe considerar la
información a solicitar al nuevo miembro y lo que se requiera en una
nueva iglesia a añadir.

3) Para la eficiencia en el proceso de verificación de inventario se debe
aprovechar el módulo proporcionado por el sistema para el registro de
los haberes del almacén y su correcta distribución interna, de acuerdo
a las necesidades de cada ministerio. También respetar los tiempos
determinados en la creación de un inventario anual dará como
resultado la eficacia del propósito del producto de la investigación.

4) Los líderes encargados (secretaria y miembros de la directiva de la
asociación) deben usar el sistema para los fines propios en la gestión
de membresía, pudiendo revisar la información de los miembros y
actualizando la información de ellos, de ser necesario. También deben
considerar que algunos cambios requieren de permisos especiales
otorgados por el administrador maestro del software.
247

REFERENCIAS BIBLIOGRÁFICAS

Álvarez, M. Á. (05 de Junio de 2017). Desarrollo Web. Obtenido de
https://desarrolloweb.com/articulos/831.php
Anillo Farello, J., & Pájaro Martínez, E. E. (2014). SISTEMA DE INFORMACIÓN
PARA LA GESTIÓN DE LA MEMBRESÍA DE IGLESIAS CRISTIANAS.
UNIVERSIDAD DE CARTAGENA. Cartagena: UNIVERSIDAD DE
CARTAGENA. Recuperado el 25 de Mayo de 2017, de
http://docplayer.es/1379983-Sistema-de-informacion-para-la-gestion-de-
la-membresia-de-iglesias-cristianas.html
Avante. (27 de Enero de 2016). Obtenido de http://www.avante.es/comparativa-
metodologias-agiles-vs-tradicionales/
Baez, S. (20 de Octubre de 2012). KnowDo. Obtenido de
http://www.knowdo.org/knowledge/39-sistemas-web
Barcelona, U. d. (s.f.). OBS. Obtenido de https://www.obs-edu.com/int/blog-
project-management/scrum/que-es-scrum-y-cuales-son-las-partes-del-
proceso-de-trabajo
Barrantes, R. (2002). Investigacion : un camino al conocimiento. San Jose:
Universidad Estatal a Distancia.
Bernal Torres, C. A. (2010). Metodología de la investigación. Tercera edición (3ra
ed.). (O. F. Palma, Ed.) Bogotá, Colombia: PEARSON EDUCACIÓN.
Recuperado el Junio de 2017
Canali de Rosi, L. (s.f.). MasterNewMedia. Obtenido de
http://es.masternewmedia.org/aplicaciones_web/temas_de_aplicaciones
_web/Beneficios_De_Las_Aplicaciones_Basadas_En%20_Web_Y_El_A
nuncio_De_Microsoft_De_La_Era_En_Vivo.htm
Castillo Asencio, P. L. (2016). Desarrollo e implementación de un sistema web
para generar valor en una pyme aplicando una metodología ágil. Caso de
estudio: Manufibras Perez SRL. Universidad Nacional Mayor de San
Marcos. Lima: Universidad Nacional Mayor de San Marcos. Recuperado
el 25 de Mayo de 2017, de
http://cybertesis.unmsm.edu.pe/handle/cybertesis/4668
Castillo, C. F., & Sicacha, J. (2014). Software de Registro y control de Membresía
y Aportes para la Iglesia Cruzada Cristiana Casa de Restauración Cali.
Informe de Proyecto, Cali. Recuperado el 25 de Mayo de 2017, de
https://prezi.com/1u4xkts14eki/software-de-registro-y-control-de-
membresia-y-aportes-para-l/
Castro. (2003). El proyecto de investigación y su esquema de elaboración. (Vol.
II). Caracas, Venezuela.
248

CEFIRE. (Desconocido de Desconocido de Desconocido). CEFIRE. Recuperado
el 08 de Junio de 2017, de
http://cefire.edu.gva.es/file.php/1/Comunicacion_y_apertura/B3_Pagina
Web/pgina_web_esttica_vs_dinmica.html
Chacón Campos, P. (2015). SISTEMA EXPERTO APLICADO AL PROCESO DE
ORIENTACIÓN VOCACIONAL EN LAS ESCUELAS PROFESIONALES
DE INGENIERÍA DE LA UNIVERSIDAD NACIONAL DE UCAYALI.
Universidad Nacional de Ucayali. Pucallpa: Universidad Nacional de
Ucayali. Recuperado el 06 de Junio de 2017
Cruz Flores, E. (2019). DESARROLLO DE UNA APLICACIÓN WEB PARA LA
GESTIÓN ACADÉMICA EN UN CENTRO DE NIVELACIÓN. Quito:
Escuela Politécnica Nacional. Recuperado el junio de 2019
Culturación. (s.f.). Obtenido de http://culturacion.com/que-son-los-scripts/
Darío, R. (20 de Marzo de 2014). Rubén Darío. Obtenido de
http://rdsoporteymantenimientodepc.blogspot.pe/2014/03/metodologias-
de-desarrollo-agiles-vs.html
Díaz Sevilla, M. J., & Sarcos Vargas, W. D. (2017). DESARROLLO DE UN
SOFTWARE EN AMBIENTE WEB PARA EL CÁLCULO DE HUELLA DE
CARBONO, QUE PERMITA DETERMINAR LA CANTIDAD DE CO2 QUE
PRODUCEN LOS AUTOBUSES DE TRANSPORTE URBANO DE LA
COOPERATIVA “CIUDAD DE MILAGRO”. Milagro: Universidad Estatal
de Milagro. Recuperado el junio de 2019
Diccionario de términos informáticos. (s.f.). Obtenido de
https://upload.wikimedia.org/wikipedia/commons/a/a0/Glosario_Informáti
co.pdf
Diccionario para informáticos. (s.f.).
Edu4Java. (s.f.). Obtenido de http://www.edu4java.com/es/servlet/servlet1.html
El Tabernáculo, I. (21 de marzo de 2016). Acta de Constitución y Aprobación de
Estatuto. Acta de Constitución y Aprobación de Estatuto. Pucallpa,
Coronel Portillo, Perú.
El Tabernáculo, I. (2018). Reglamento Interno. Reglamento Interno de la
Asosiación Religiosa de la Iglesia Evangélica Pentecostal Misionera "El
Tabernáculo". Pucallpa, Coronel Portillo, Perú.
Equipo1, R. U. (08 de Diciembre de 2012). Rational Unified Process Equipo 1.
Obtenido de http://rupequipo1.blogspot.pe/2012/12/que-es-rup.html
Esteban Santamaría, J. Y., & Valega Marquina, J. R. (2015). SISTEMA MÓVIL
BASADO EN GEOLOCALIZACIÓN PARA MEJORAR LA GESTiÓN DE
RECLAMOS Y AVERÍAS EN TELEFÓNICA DEL PERÚ. Universidad
Nacional de Ucayali. Pucallpa: Universidad Nacional de Ucayali.
Recuperado el 06 de Junio de 2017
249

Excel Total. (2019). Excel Total. Obtenido de https://exceltotal.com/que-es-excel/
Fisteus, J. A. (2008). Universidad Carlos III de Madrid. Obtenido de
http://www.it.uc3m.es/labttlat/2007-08/material/jsp/
Freire Vargas, E. J. (2014). Sistema informático basado en software libre para la
gestión documental en la facultad de ciencia e ingeniería en alimentos.
Tesis, Universidad Técnica de Ambato, Ambato. Recuperado el 08 de
Junio de 2017, de http://repositorio.uta.edu.ec/handle/123456789/6978
Fuentes Manzano, G. (2015). DESARROLLO DE UN SISTEMA WEB QUE
APOYE LA COORDINACIÓN DE APROBACIÓN, SEGUIMIENTO DE
EJECUCIÓN Y CIERRE DE PROYECTOS EN LA JEFATURA DE
INVESTIGACIÓN, INNOVACIÓN Y TRANSFERENCIA DE
TECNOLOGÍA DE LA UNIVERSIDAD DE LAS FUERZAS ARMADAS
ESPE EXTENSIÓN LATACUNG. Latacunga: Universidad de las Fuerzas
Armadas. Recuperado el enero de 2019
Garzás, J. (25 de Septiembre de 2012). Javier Garzas. Obtenido de
http://www.javiergarzas.com/2012/09/metodologias-crystal.html
Guanoluisa Andagua, G., & Maldonado Moyolema, C. (2016). DESARROLLO
DE UN SISTEMA WEB QUE OPTIMICE LA GESTIÓN DE FLOTAS DE
TRANSPORTE TERRESTRE ASIGNADO AL ÁREA DE LOGÍSTICA DE
LA UNIVERSIDAD DE LAS FUERZAS ARMADAS ESPE EXTENSIÓN
LATACUNGA. Latacunga: Universidad de las Fuerzas Armadas.
Recuperado el enero de 2019
Guardiola Jiménez, P. (2004). Universidad de Murcia. Obtenido de
https://www.um.es/docencia/pguardio/documentos/spss_1.pdf
Huamanciza Gironda, C. (2018). DESARROLLO DE UNA APLICACIÓN WEB Y
MÓVIL PARA LA GESTIÓN DE ENCUESTAS DINÁMICAS APLICANDO
UN MODELO DE BASE DE DATOS NOSQL ORIENTADO A GRAFOS.
Lima: Universidad Nacional Mayor de San Marcos. Recuperado el junio
de 2019
Hurtado Samaniego, D. F. (2019). APLICACIÓN WEB ADMINISTRATIVA PARA
RESERVA DE SERVICIOS DE TRANSPORTE Y ENVÍO DE
ENCOMIENDAS PARA LA EMPRESA ROMERO Y ASOCIADOS
(AMBASEUR) DE LA CIUDAD DE AMBATO. Ambato: Universidad
Técnica de Ambato. Recuperado el junio de 2019
Instituto Fomento Ocupacional. (s.f.). Obtenido de
http://www.foc.es/2013/04/11/988-razones-por-la-que-utilizar-mysql.html
Jiménez Bazán, G. (2018). SISTEMA WEB DE CONTROL DE ASISTENCIA
BASADO EN WEB SERVICES Y LA BIOMETRÍA DE HUELLA DACTILAR
PARA LAS INSTITUCIONES EDUCATIVAS. Lima: Universidad Nacional
Mayor de San Marcos. Recuperado el mayo de 2019, de
250

http://cybertesis.unmsm.edu.pe/bitstream/handle/cybertesis/10179/Jimen
ez_bg.pdf?sequence=1&isAllowed=y
Learning, D. (27 de Marzo de 2012). Digital Learning. Recuperado el Noviembre
de 2017, de http://www.digitallearning.es/blog/que-es-ajax/
López Roldán, P., & Fachelli, S. (2015). Metodología de la Investigación Social
Cuantitativa. Bellaterra: Dipòsit Digital de Documents, Universitat
Autònoma de Barcelona. Obtenido de
https://ddd.uab.cat/pub/caplli/2016/163567/metinvsoccua_a2016_cap2-
3.pdf
Los Teatinos. (Agosto de 2014). Obtenido de
http://losteatinos.com/servlets/servlet.html
Luján Mora, S. (2002). Programación de aplicaciones web: historia, principios
básicos y clientes web. Alicante.
Marcacuzco Polanco, Y., & Trigueros Vela, K. S. (2014). SISTEMA ERP T&G-
INFORMÁTICA. Universidad Ricardo Palma. Lima: Universidad Ricardo
Palma. Recuperado el 06 de Junio de 2017, de
http://cybertesis.urp.edu.pe/handle/urp/409
Obando Mosquera, D. (2015). DESARROLLO DE UN SITIO WEB BAJO EL
PATRÓN DE DISEÑO MODELO, VISTA, CONTROLADOR, QUE
PERMITA LA GESTIÓN DEL REGISTRO DE VOLUNTARIOS Y
DONACIONES PARA DAR SOPORTE E INFORMACIÓN A LA
FUNDACIÓN CONSTRUYAMOS UN SUEÑO, UBICADA EN LA CIUDAD
DE LATACUNGA. Latacunga: Universidad de las Fuerzas Armadas.
Recuperado el enero de 2019
Oracle. (s.f.). Recuperado el 03 de Octubre de 2017, de
https://www.oracle.com/es/mysql/index.html
Otzen, T., & Manterola, C. (19 de diciembre de 2016). Técnicas de Muestreo
sobre una Población a Estudio. (C. Manterola, Ed.) Temuco, Chile.
Obtenido de https://scielo.conicyt.cl/pdf/ijmorphol/v35n1/art37.pdf
Pairuna, L. (11 de Mayo de 2017). Code Dimension. Recuperado el 03 de
Octubre de 2017, de http://www.codedimension.com.ar/noticias-sobre-
tecnologia/noticias/-que-es-y-para-que-sirve-un-sitio-web-/1
Pastrana, O. (s.f.). Intelligence2Business. Obtenido de
http://www.i2btech.com/blog-i2b/tech-deployment/5-beneficios-de-
aplicar-metodologias-agiles-en-el-desarrollo-de-software/
Portugal Legua, Y. G. (2017). ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DE UN
SISTEMA PARA LA GESTIÓN DE PROMOCIONES DE DOCENTES DE
UNA UNIVERSIDAD. Pontificia Universidad Católica del Perú. Lima:
Pontificia Universidad Católica del Perú. Recuperado el 07 de Julio de
2017
251

Procesos de Software. (21 de Junio de 2017). Obtenido de
https://procesosdesoftware.wikispaces.com/METODOLOGIA+XP
Proyectos Ágiles.org. (s.f.). Obtenido de https://proyectosagiles.org/ejecucion-
iteracion-sprint/
Quishpe Guanotásig, C. (2018). DESARROLLO DE UNA APLICACIÓN WEB
QUE MEJORE LA GESTIÓN DE LOS PRODUCTOS EXPERIMENTALES
EN INGENIERÍA DE SOFTWARE APLICANDO EL PARADIGMA DE
LÍNEA DE PRODUCTO SOFTWARE EN EL GRUPO DE
INVESTIGACIÓN GITBIO. Latacunga: Universidad de las Fuerzas
Armadas. Recuperado el enero de 2019
Reátegui Macedo, R. E., & Trujillo Romero, H. R. (2017). SISTEMA
INFORMATICO CON TECNOLOGIA J2EE DE EVALUACION DE
DOCENTES EN LA ESCUELA PROFESIONAL DE INGENIERtA DE
SISTEMAS DE LA UNIVERSIDAD NACIONAL DE UCAYALI. Pucallpa:
Universidad Nacional de Ucayali. Recuperado el enero de 2019
RODRÍGUEZ, A. E. (s.f.). Geeky Theory. Obtenido de
https://geekytheory.com/json-i-que-es-y-para-que-sirve-json/
Romero Gutiérrez, C. (2017). GESTIÓN DE LA INFORMACIÓN
ADMINISTRATIVA DE LA ACADEMIA PERSONAL CLASS MEDIANTE
LA IMPLEMENTACIÓN DE UN SOFTWARE. Huancayo: Universidad
Nacional del Centro del Perú. Recuperado el junio de 2019, de
http://repositorio.uncp.edu.pe/bitstream/handle/UNCP/3369/Romero%20
Guti%C3%A9rrez.pdf?sequence=1&isAllowed=y
Softeng. (s.f.). Obtenido de https://www.softeng.es/es-
es/empresa/metodologias-de-trabajo/metodologia-scrum.html
Tanaka Terukina, R. (2016). Sistema de gestión de fuerza de ventas web y móvil,
utilizando el estilo arquitectónico Rest, metodología Scrum y la
geolocalización. Universidad Nacional Mayor de San Marcos. Lima:
Universidad Nacional Mayor de San Marcos. Recuperado el 25 de Mayo
de 2017, de http://cybertesis.unmsm.edu.pe/handle/cybertesis/5532
Valdés, D. P. (03 de Julio de 2007). Maestros del web. Obtenido de
http://www.maestrosdelweb.com/que-es-javascript/
Wikipedia. (05 de Junio de 2017). Wikipedia. Obtenido de
https://es.wikipedia.org/wiki/Log%C3%ADstica
Wikipedia. (05 de Junio de 2017). Wikipedia. Obtenido de
https://es.wikipedia.org/wiki/Hipertexto
Wikipedia. (02 de Mayo de 2017). Wikipedia. Obtenido de
https://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software
Wikipedia. (29 de Septiembre de 2017). Wikipedia, Página Web. Obtenido de
https://es.wikipedia.org/wiki/Página_web
252

Wikipedia. (s.f.). Wikipedia. Obtenido de https://es.wikipedia.org/wiki/Front-
end_y_back-end
Wordreference. (s.f.). Wordreference.com. Obtenido de
http://www.wordreference.com/definicion/plausible

253

ANEXOS

Anexo 1: Matriz de Identificación del Problema:
“Inadecuada gestión de membresía y logística interna de la iglesia”
Nº Síntomas Causas Consecuencias Pronóstico
1
Problemas en el
almacenamiento y búsqueda de
información personal de un
miembro de la Iglesia
El registro de miembros se tiene
en libros físicos
Pérdida de tiempo en la
búsqueda y/o extravío de
información personal
Registro único virtual de los
miembros de la Iglesia que
permitirá realizar búsquedas
más rápidas
2
Demora en el proceso de
registro de membresía interna
El registro de miembros se hace
de forma manual en libros
físicos
Pérdida de tiempo para realizar
acciones que no requieren
mucho el recurso mencionado
Registro único virtual
simplificado de los miembros de
la Iglesia en un sistema
informático
3
Demora en el proceso de
cambio de membresía
Cada Iglesia tiene un formato de
membresía y debe confirmar la
solicitud con el líder o Pastor de
la Iglesia emisora
Trámites largos innecesarios,
pérdida de tiempo y
truncamiento en la
participación del nuevo
miembro de la Iglesia
Creación de un estándar único
de membresía entre
congregaciones y plasmarlo en
un sistema informático
4
Problemas en el control de
inventario del templo
El registro de materiales en
almacén se hace de manera
manual
Mal control de inventario y
hasta posibles pérdidas de
materiales
Creación de un módulo de
logística básica en un sistema
informático que ayude a tener
un mejor control de inventario
5
Exceso de papeles y libros
físicos que contienen
información interna de la Iglesia
Toda la información de registros
de la Iglesia se tienen en físico
Archivamiento excesivo de
documentación y posible
pérdida de los mismos
Sistematización de la
información

Anexo 2: Hoja de Ruta de las Variables

PENSAMIENTO SISTÉMICO
TECNOLOGÍA JEE 6
WEB
Variable Independiente
GESTIÓN DE MEMBRESÍA Y
LOGÍSTICA INTERNA
Variable Dependiente
Java Server Page – Netbeans 7.2.1
SQL – PHPMyAdmin MySQL 5.1.X
Tecnologías a usar
TRADICIONALES:
RUP
Enterprise Unified Process
Microsoft Operation Framework
ÁGILES:
XP
SCRUM
Método de Desarrollo de Sistemas Dinámicos
Agile Unified Process
Crystal
Metodologías disponibles
Aplicación de
Metodología
Iglesia Evangélica
Pentecostal Misionera
“El Tabernáculo”

Anexo 3: Operacionalización de Variables

TECNOLOGÍA JEE 6 WEB
Dimensiones Indicadores
 Inicio  Tamaño de la información
 Elaboración  Adaptabilidad
 Construcción  Navegabilidad
 Transición
 Eficacia
 Eficiencia

GESTIÓN DE MEMBRESÍA Y LOGÍSTICA INTERNA

Dimensiones Indicadores
 Registro de miembros  Número de miembros de la Iglesia.
 Proceso de consulta de estado
eclesiástico
 Tiempo de respuesta inter-
congregacional.
 Registro de inventario  Número de elementos en inventario.
 Proceso de inventariado
 Tiempo empleado en el proceso de
inventariado.
 Control de inventario
 Tiempo empleado en las búsquedas
y/o verificaciones de inventario.
Anexo 4: Matriz de Consistencia Sistémica

Anexo 5: Instrumento de recolección de datos

Cuestionario

En el presente cuestionario se le han formulado 10 preguntas agrupadas en 2 bloques, cuya
finalidad es conocer el estado actual de determinados procesos internos de la congregación,
considerando también la aplicación de un sistema informático y los resultados de su uso.
Consideraciones al responder:
- Sólo marque una opción por pregunta.
En una escala del 1 al 5, donde 1 es Muy Poco y 5 es Demasiado, por favor responda:
Pregunta Muy Poco Poco Normal Bastante Demasiado
Gestión de membresía y logística interna - Situación de la iglesia
1.- ¿Qué tan manejable considera la información de los
miembros por la cantidad existente en la congregación?

2.- ¿Qué tan rápido es el proceso de cambio de
membresía?

3.- ¿Qué tan manejable considera la información de
elementos de patrimonio de la iglesia?

4.- ¿Qué tan rápido es el proceso de inventariado de
elementos de la iglesia?

5.- ¿Qué tan rápida es la búsqueda o comprobación de
bienes de la iglesia en el inventario?

Tecnología JEE 6 Web
6.- ¿Cuánto cree que soporte un sistema informático toda
la información?

7.- ¿Qué tanto cree que se adapte un sistema informático
a la realidad de la iglesia?

8.- ¿Qué tan fácil considera que será el uso de un sistema
informático?

9.- ¿Qué tanto cree que cumpla con su propósito un
sistema informático?

10.- ¿Qué tanto cree que un sistema informático mejore la
rapidez de la búsqueda de información?

Anexo 6: Validación por el Alfa de Cronbach

La fuente de validación fue hecha por medio del programa SPSS para
ambos momentos de la encuesta, tanto para el Pre – Test como para el Post –
Test.

 Comprobación Pre – Test

Capturas de uso del SPSS

Al dar un valor de alfa de 0.857, se acepta el instrumento como VÁLIDO
al superar el mínimo esperado de 0.8

 Comprobación Post – Test

Capturas de uso del SPSS

Al dar un valor de alfa de 0.862, se acepta el instrumento como VÁLIDO al
superar el mínimo esperado de 0.8