FACULTAD DE INGENIERÍA

ESCUELA PROFESIONAL DE INGENIERÍA DE

SISTEMAS

SISTEMA WEB PARA EL PROCESO DE GESTIÓN DE INCIDENCIAS

EN LA EMPRESA INDUSTRIAS LOO S.A.C

TESIS PARA OBTENER EL TÍTULO PROFESIONAL

DE INGENIERO DE SISTEMAS

AUTOR:
GABINO GUERE, YORDI

ASESOR:
DR. RODRIGUEZ BACA LISET SULAY

LÍNEA DE INVESTIGACIÓN:
SISTEMAS DE INFORMACIÓN TRANSACCIONALES

LIMA – PERÚ

2017
 DECLARATORIA DE AUTENTICIDAD

Yo YORDI ESAÚ GABINO GUERE alumno de la facultad de ingeniería de

sistemas, con DNI N° 47724240, con la tesis que tiene por título “SISTEMA WEB
PARA EL PROCESO DE GESTIÓN DE INCIDENTES EN LA EMPRESA
INDUSTRIAS LOO S.A.C.”, con el propósito de cumplir con las disposiciones
definidas en el reglamento de grados y títulos establecidos por la Universidad
Cesar Vallejo declaro que:

1. Toda la información que se presentan en la tesis es íntegramente de mi autoría.

2. He respetado las normas internacionales de citas y referencias para las fuentes

consultadas. Por lo cual, la presente tesis no tiene ninguna relación con el plagio
en forma parcial o total.

3. La tesis no ha sido publicada ni presentada anteriormente para obtener algún

grado académico previo o título profesional.

4. Los datos presentados en los resultados son reales, no han sido forzados, ni
copiados por tanto los resultados que se presenten en la tesis se constituirán en
aportes a la realidad investigada.

De identificarse la falta de fraude, plagio (sin citación a autores), auto plagio

(presentar como nuevo algún trabajo de investigación propio que ya ha sido
publicado), piratería (uso ilegal de información ajena) o falsificación (representar
falsamente las ideas de otros), asumo las consecuencias y sanciones que de mi
acción se deriven, sometiéndome a la normalidad vigente de la Universidad Cesar
Vallejo. Lima, 29 de Noviembre del 2017.

___________________________________________

YORDI ESAÚ GABINO GUERE

DNI: 47724240

i
 DEDICATORIA
Dedico este trabajo a mis padres Vilma
Dina Guere Luna y David Lorenzo García
por su constante apoyo durante toda mi
vida formándome con valores para ser una
persona con principios

ii
 AGRADECIMIENTO
Agradezco a mis padres por el apoyo
brindado durante toda la realización de
este trabajo sin su aliento no hubiera sido
posible mi formación como profesional y el
desarrollo del presente trabajo, así mismo
quiero agradecer a mi asesora Lizeth
Rodríguez por su constante asesoría y
apoyo durante esta fase de la tesis

iii
 PRESENTACIÓN

Señores miembros del jurado:

Ante ustedes expongo la tesis titulada “Sistema web para el proceso de gestión de
incidencias.”. El capítulo I detalló los principales datos como lo son el título de la
tesis, así mismo la problemática, los trabajos anteriores y el marco teórico
relacionado al tema, así mismo se formuló el problema, se planteó las hipótesis y
de la misma forma se definió nuestros objetivos para después definir la
metodología de desarrollo a emplear en la tesis. El capítulo II, se describe el tipo
y diseño de investigación del mismo modo la definición operacional y conceptual
de las variables con los correspondientes indicadores, seguidamente de esto se
seleccionó la población y la muestra a partir mediante el uso del muestreo
adecuado, finalizando este proceso se explicaron los instrumentos usados para la
recolección de datos, además del desarrollo de la metodología. El capítulo III se
muestra el resultado de la investigación, haciendo uso de la herramienta
estadística SPSS. El capítulo IV se detalla la discusión obtenida de la investigación.
El capítulo V se presenta las conclusiones resultantes de la investigación, el
capítulo VI describe las recomendaciones pertinentes, finalizando el capítulo VII se
expone las referencias bibliográficas que apoyaron la investigación.

iv
 ÍNDICE GENERAL

DECLARATORIA DE AUTENTICIDAD ........................................................................... I

DEDICATORIA ............................................................................................................... II

AGRADECIMIENTO ...................................................................................................... III

PRESENTACIÓN...........................................................................................................IV

ÍNDICE GENERAL .........................................................................................................V

ÍNDICE DE TABLAS ....................................................................................................VII

RESUMEN .................................................................................................................. XIV

ABSTRACT ................................................................................................................. XV

I. INTRODUCCIÓN ................................................................................................... 17

1.1. Realidad problemática ............................................................................. 18

1.2. Trabajos Previos ...................................................................................... 22

1.3. Limitaciones ............................................................................................... 29

1.4. Teorías Relacionadas al Tema ................................................................ 30

1.4. Formulación Del Problema ...................................................................... 53

1.5. Justificación Del Estudio ......................................................................... 53

1.6. Hipótesis ................................................................................................... 55

1.7. Objetivos................................................................................................... 56

II. MÉTODO ............................................................................................................... 57

2.1 Diseño De Investigación ............................................................................. 57

2.1.1 Tipo de Estudio ........................................................................................ 58

2.1.2 Diseño De Investigación .......................................................................... 58

2.1.3 Método de Investigación ......................................................................... 60

2.2 Variables, Operacionalización .................................................................... 60

v
 2.3 Población Y Muestra ................................................................................... 61

2.4 Técnica e Instrumentos de recolección de Datos, Validez Y

Confiabilidad ........................................................................................................ 63

2.5 Métodos De Análisis De Datos ................................................................... 68

2.6 Aspectos Éticos ........................................................................................... 72

III. RESULTADOS ..................................................................................................... 74

IV. DISCUSIÓN.......................................................................................................... 88

V. CONCLUSIÓN...................................................................................................... 91

VI. RECOMENDACIÓN ............................................................................................. 93

...................................................................................................................................... 94

VII. REFERENCIAS ................................................................................................ 95

VIII. REFERENCIAS .............................................................................................. 103

IX. ANEXOS ............................................................................................................ 104

vi
 ÍNDICE DE TABLAS

Tabla 01: Cruce entre Impacto y urgencia .................................................................. 37

Tabla 02 : Tabla de prioridad ....................................................................................... 37
Tabla 03: Comparativa de Metodologías .................................................................... 52
Tabla 04: Comparación de metodologías según expertos ........................................ 52
Tabla 05: Tabla de Operacionalización de variables.................................................. 61
Tabla 06: Población 1 y Población 2 ........................................................................... 62
Tabla 07: Resultado de los expertos –Instrumento para indicador
Porcentaje de incidencias resueltas dentro del SLA .................................................. 65
Tabla 08: Resultado de los expertos –Instrumento para indicador
Porcentaje de incidencias resueltas ............................................................................ 65
Tabla 09: Puntuación y Significado ............................................................................ 66
Tabla 10 : Medidas descriptivas del Pre-test y Post – test del
indicador Porcentaje de incidencias resueltas dentro del SLA ................................. 74
Tabla 11: Medidas descriptivas del Pre-test y Post – test del
indicador Porcentaje de incidencias resueltas ........................................................... 75
Tabla 12 : Prueba de normalidad para el Pre test y Post Test del
indicador Porcentaje de incidencias resueltas dentro del SLA (PRSLA) .................. 77
Tabla 13: Prueba de normalidad para el Pre test y Post Test del
indicador Porcentaje de incidencias resueltas (PIR) .................................................. 78
Tabla 14: Prueba T-Student para el Porcentaje de incidencias
resueltas dentro del SLA .............................................................................................. 83
Tabla 15: Prueba T- Student para el Porcentaje de incidencias
resueltas ........................................................................................................................ 85
Tabla 16: personas y roles del proyecto.................................................................... 126
Tabla 17: Plan de Colaboración ................................................................................ 134
Tabla 18: Épicas ......................................................................................................... 135
Tabla 19: Descripción De Usuarios Involucrados .................................................... 136
Tabla 20 : Riesgos ...................................................................................................... 137
Tabla 21: Criterios de Terminado .............................................................................. 138
Tabla 22: Historia de Usuario HU01 –Acceso al sistema ......................................... 141
Tabla 23: Historia de Usuario HU02 –Mantenimiento de Personal ......................... 142
Tabla 24: Historia de Usuario HU03 - Mantenimiento de Usuarios ............................... 143
Tabla 25: Historia de Usuario HU04 - Mantenimiento de Prioridades ..................... 144
Tabla 26: Historia de Usuario HU05 - Mantenimiento de Categorías ..................... 145

vii
Tabla 27: Historia de Usuario HU06 - Mantenimiento de incidencias ..................... 146
Tabla 28: Historia de Usuario HU07 - Cierre de incidencia...................................... 147
Tabla 29: Historia de Usuario HU08 - Escalado de Incidencias .............................. 148
Tabla 30: Historia de Usuario HU09 - Notificación ................................................... 149
Tabla 31: Historia de Usuario HU10 - Registro de conformidad ............................. 150
Tabla 32: Historia de Usuario HU11 - Reportes ........................................................ 151
Tabla 33: Product Backlog......................................................................................... 154
Tabla 34: Pila Del Sprint 1 .......................................................................................... 155
Tabla 35: Pila Del Sprint 2 .......................................................................................... 156
Tabla 36: Pila Del Sprint 3 .......................................................................................... 156
Tabla 37: Lista de Pendientes del Sprint 01 ............................................................. 159
Tabla 38: Estructura Tabla Empleado ...................................................................... 165
Tabla 39: Estructura Tabla Cargo............................................................................. 166
Tabla 40: Estructura Tabla Persona ......................................................................... 166
Tabla 41: Estructura Tabla Usuarios ........................................................................ 167
Tabla 42: Estructura Tabla Área ............................................................................... 168
Tabla 43: Estructura Tabla Prioridad ....................................................................... 169
Tabla 44: Estructura Tabla Estados ......................................................................... 169
Tabla 45: Estructura Tabla Categoría ...................................................................... 170
Tabla 46: Estructura Tabla Sub Categoría ............................................................... 171
Tabla 47: Estructura Tabla Incidencia...................................................................... 171
Tabla 48: Casos de pruebas sprint 01 ...................................................................... 204
Tabla 49: Resumen de sprint 01 ................................................................................ 204
Tabla 50: Retrospectiva Sprint 01 ............................................................................ 205
Tabla 51: Lista de Pendientes del Sprint 02 ............................................................. 208
Tabla 52: Casos de pruebas sprint 02 ...................................................................... 245
Tabla 53: Resumen de sprint 02 ................................................................................ 245
Tabla 54: Retrospectiva Sprint 02 ............................................................................ 246
Tabla 55: Lista de Pendientes del Sprint 03 ............................................................. 249
Tabla 56: Casos de pruebas sprint 03 ...................................................................... 262
Tabla 57: Resumen de sprint 03 ................................................................................ 262
Tabla 58: Retrospectiva Sprint 03 ............................................................................ 263

viii
 ÍNDICE DE FIGURAS

Figura 1 .......................................................................................................................... 20
Figura 2 .......................................................................................................................... 21
Figura 03 ........................................................................................................................ 31
Figura 04 ........................................................................................................................ 32
Figura 05 ....................................................................................................................... 36
Figura 06 ........................................................................................................................ 41
Figura 7 ......................................................................................................................... 42
Figura 08 ........................................................................................................................ 43
Figura 09 ........................................................................................................................ 44
Figura 10 ....................................................................................................................... 45
Figura 011 ...................................................................................................................... 50
Figura 12 ....................................................................................................................... 67
Figura 13 ....................................................................................................................... 68
Figura 14 ....................................................................................................................... 71
Figura 15 ....................................................................................................................... 71
Figura 16 ....................................................................................................................... 72
Figura 17 ....................................................................................................................... 75
Figura 18 ....................................................................................................................... 76
Figura 19 ....................................................................................................................... 79
Figura 20 ....................................................................................................................... 80
Figura 21 ....................................................................................................................... 81
Figura 22 ....................................................................................................................... 82
Figura 23 ....................................................................................................................... 84
Figura 24 ....................................................................................................................... 86
Figura 25 ..................................................................................................................... 157
Figura 26 ..................................................................................................................... 159
Figura 27 ..................................................................................................................... 160
Figura 28 ..................................................................................................................... 161
Figura 29 ..................................................................................................................... 162
Figura 30 ..................................................................................................................... 162
Figura 31 ..................................................................................................................... 163
Figura 32 ..................................................................................................................... 164
Figura 33 ..................................................................................................................... 174
Figura 34 ..................................................................................................................... 174

ix
Figura 35 ..................................................................................................................... 176
Figura 36 ..................................................................................................................... 177
Figura 37 ..................................................................................................................... 178
Figura 38 ..................................................................................................................... 178
Figura 39 ..................................................................................................................... 179
Figura 40 ..................................................................................................................... 179
Figura 41 ..................................................................................................................... 180
Figura 42 ..................................................................................................................... 180
Figura 43 ..................................................................................................................... 181
Figura 44 ..................................................................................................................... 181
Figura 45 ..................................................................................................................... 182
Figura 46 ..................................................................................................................... 182
Figura 47 ..................................................................................................................... 182
Figura 48 ..................................................................................................................... 183
Figura 49 ..................................................................................................................... 183
Figura 50 ..................................................................................................................... 184
Figura 51 ..................................................................................................................... 184
Figura 52 ..................................................................................................................... 185
Figura 53 ..................................................................................................................... 185
Figura 54 ..................................................................................................................... 186
Figura 55 ..................................................................................................................... 186
Figura 56 ..................................................................................................................... 187
Figura 57 ..................................................................................................................... 188
Figura 58 ..................................................................................................................... 188
Figura 59 ..................................................................................................................... 189
Figura 60 ..................................................................................................................... 190
Figura 61 ..................................................................................................................... 191
Figura 62 ..................................................................................................................... 191
Figura 63 ..................................................................................................................... 192
Figura 64 ..................................................................................................................... 192
Figura 65 ..................................................................................................................... 193
Figura 66 ..................................................................................................................... 193
Figura 67 ..................................................................................................................... 194
Figura 68 ..................................................................................................................... 195
Figura 69 ..................................................................................................................... 196
Figura 70 ..................................................................................................................... 197

x
Figura 71 ..................................................................................................................... 198
Figura 72 ..................................................................................................................... 199
Figura 73 ..................................................................................................................... 200
Figura 74 ..................................................................................................................... 201
Figura 75 ..................................................................................................................... 202
Figura 76 ..................................................................................................................... 203
Figura 77 ..................................................................................................................... 203
Figura 78 ..................................................................................................................... 205
Figura 79 ..................................................................................................................... 208
Figura 80 ..................................................................................................................... 209
Figura 81 ..................................................................................................................... 210
Figura 82 ..................................................................................................................... 210
Figura 83 ..................................................................................................................... 211
Figura 84 ..................................................................................................................... 211
Figura 85 ..................................................................................................................... 213
Figura 86 ..................................................................................................................... 214
Figura 87 ..................................................................................................................... 215
Figura 88 ..................................................................................................................... 216
Figura 89 ..................................................................................................................... 216
Figura 90 ..................................................................................................................... 217
Figura 91 ..................................................................................................................... 217
Figura 92 ..................................................................................................................... 218
Figura 93 ..................................................................................................................... 218
Figura 94 ..................................................................................................................... 219
Figura 95 ..................................................................................................................... 219
Figura 96 ..................................................................................................................... 220
Figura 97 ..................................................................................................................... 220
Figura 98 ..................................................................................................................... 221
Figura 99 ..................................................................................................................... 221
Figura 100 ................................................................................................................... 222
Figura 101 ................................................................................................................... 222
Figura 102 ................................................................................................................... 223
Figura 103 ................................................................................................................... 223
Figura 104 ................................................................................................................... 224
Figura 105 ................................................................................................................... 225
Figura 106 ................................................................................................................... 226

xi
Figura 107 ................................................................................................................... 227
Figura 108 ................................................................................................................... 228
Figura 109 ................................................................................................................... 228
Figura 110 ................................................................................................................... 229
Figura 111 ................................................................................................................... 230
Figura 112 ................................................................................................................... 231
Figura 113 ................................................................................................................... 231
Figura 114 ................................................................................................................... 232
Figura 115 ................................................................................................................... 233
Figura 116 ................................................................................................................... 234
Figura 117 ................................................................................................................... 235
Figura 118 ................................................................................................................... 236
Figura 119 ................................................................................................................... 237
Figura 120 ................................................................................................................... 238
Figura 121 ................................................................................................................... 239
Figura 122 ................................................................................................................... 240
Figura 123 ................................................................................................................... 241
Figura 124 ................................................................................................................... 242
Figura 125 ................................................................................................................... 243
Figura 126 .................................................................................................................... 244
Figura 127 .................................................................................................................... 246
Figura 128 ................................................................................................................... 249
Figura 129 ................................................................................................................... 250
Figura 130 ................................................................................................................... 251
Figura 131 ................................................................................................................... 251
Figura 132 .................................................................................................................... 252
Figura 133 .................................................................................................................... 252
Figura 134 ................................................................................................................... 253
Figura 135 ................................................................................................................... 253
Figura 136 ................................................................................................................... 254
Figura 137 ................................................................................................................... 254
Figura 138 ................................................................................................................... 255
Figura 139 ................................................................................................................... 256
Figura 140 ................................................................................................................... 257
Figura 141 ................................................................................................................... 258
Figura 142 ................................................................................................................... 259

xii
Figura 143 ................................................................................................................... 260
Figura 144 ................................................................................................................... 261
Figura 145 ................................................................................................................... 263

xiii
 RESUMEN

La actual investigación abarca la producción, puesta en funcionamiento

de un sistema web aplicada al proceso de gestión de incidentes en la
empresa Industrias Loo S.A.C dedicada a la fabricación y
comercialización de insumos escolar. El objetivo general de la presente
investigación fue determinar la influencia de un sistema web en el
proceso de gestión de incidencias en la empresa Industrias Loo S.A.C. y
así mismo como objetivos específicos tuvimos el, determinar la influencia
de un sistema web en el Porcentaje de incidencias resueltas dentro del
SLA y determinar la influencia de un sistema web en el porcentaje de
incidencias resueltas para el proceso de gestión en la empresa Loo
S.A.C.
Se empleó el tipo de investigación aplicada experimental de diseño pre-
experimental, con una población de 20 fichas de registro tanto para el
indicador porcentaje de incidencias resueltas dentro del SLA y el
indicador porcentaje de incidencias resueltas. En resumen se comprobó
que el sistema web incremento el porcentaje de incidencias resueltas
dentro del SLA en un 45.74% y porcentaje de incidencias resueltas en
un 33.6% para el proceso de gestión de incidentes en la empresa
Industrias Loo S.A.C.
La metodología empleada para el desarrollo del sistema web para el
proceso de gestión de incidentes en la empresa Industrias Loo S.A.C.
elegida fue SCRUM, por ser una metodología ágil y tener un enfoque
estratégico, táctico y adaptativo. De la misma forma, se utilizaron como
lenguaje de programación PHP y Javascript en conjunto con el lenguaje
de etiquetas HTML, se hizo uso del sistema gestor de bases de datos
denominado MySQL. Palabras clave: sistema web, gestión de
incidencias, proceso –SCRUM –MySQL.

xiv
 ABSTRACT

The current research covers the production, commissioning of a web

system applied to the process of incident management in the company
Industrias Loo S.A.C dedicated to the manufacture and marketing of
school supplies. The general objective of this research was to determine
the influence of a web system on the process of incident management in
the company Industrias Loo S.A.C. and also as specific objectives we
had, determine the influence of a web system on the percentage of
incidents resolved within the SLA and determine the influence of a web
system on the percentage of resolved incidents for the management
process in the company Loo S.A.C. The type of experimental applied
research of pre-experimental design was used, with a population of 20
record cards for both the indicator percentage of incidents resolved within
the SLA and the indicator percentage of resolved incidents. In summary
it was found that the web system increased the percentage of incidents
resolved within the SLA by 45.74% and percentage of incidents resolved
by 33.6% for the process of incident management in the company
Industrias Loo S.A.C. The methodology used for the development of the
web system for the process of incident management in the company
Industrias Loo S.A.C. chosen was SCRUM, for being an agile
methodology and having a strategic, tactical and adaptive approach. In
the same way, they were used as programming language PHP and
Javascript in conjunction with the HTML tag language, we used the
database management system called MySQL. Keywords: web system,
incident management, process -SCRUM -MySQL.

xv
 CAPÍTULO I

INTRODUCCIÓN
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

I. INTRODUCCIÓN
La empresa Industrias Loó S.A.C. es una fábrica de útiles escolares, en
el mercado peruano en diversas categorías de productos. Esta empresa
está conformada por cuatros áreas: administración, contabilidad,
almacén, producción y sistemas contando con un personal de 80
trabajadores distribuidos en dichas áreas.
En la actualidad existe una gran variedad de procesos en el área de
sistemas, pero la más importante es el soporte técnico de la
organización, la presente investigación tiene como finalidad atender los
problemas referentes a la resolución de las incidencias y si el tiempo de
resolución de las mismas se encuentra dentro del contrato SLA que tiene
la organización.
El actual proceso es deficiente ya que no se logran completar datos
importantes de las incidencias tales como el estado, descripción, y la
solución aplicada impactando en la resolución de la incidencia dado que
el registro es el primero de las fases de la gestión de incidencias.
De igual manera el porcentaje de incidencias resueltas la cual no se logra
aumentar dejando desatendidas un gran porcentaje de las mismas por
diversos motivos como la falta de una correcta asignación,
categorización, priorización. Por lo cual se tiene como objetivo
implementar un sistema web para el proceso de gestión de incidencias
en la empresa industrias LOO S.A.C.
El presente trabajo de investigación, constó de seis capítulos en los
cuales se detallaron el desarrollo de la misma. En el primer capítulo se
detalló el planteamiento del problema, la formulación, Justificación,
limitaciones, antecedentes y objetivos de la investigación, seguidamente
en el segundo capítulo se describió las variables que intervienen en la
investigación, las hipótesis, las variables, la metodología, la población y
muestra, el método a utilizar, las técnicas, instrumentos y el método de
análisis de la investigación luego en el tercer capítulo se abarcó los
resultados obtenidos. En el cuarto capítulo, se vio la discusión, en el
quinto se describió las conclusiones obtenidas del presente trabajo de

17
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

investigación y finalmente en el sexto capítulo se detallaron las

recomendaciones a futuras investigaciones.

1.1. Realidad problemática

“La gestión de los incidentes ITIL durante mucho tiempo han ayudado a
las empresas de todo el mundo para hacer frente eficientemente a los
eventos de TI no deseados” (SGSI, 2015, ‘Utilizar el ITIL junto a la norma
ISO 27001 para la gestión de incidentes’)

"Las organizaciones dependen de la tecnología, lo que hace que la

atención al cliente y la ITSM sean fundamentales para aprovechar al
máximo la retención de clientes, la productividad, la satisfacción laboral,
la ventaja competitiva y la disponibilidad de servicios de TI", declaró Wai
Wong, consejero delegado de ServiceAide. "La única forma de aumentar
de forma continua la eficacia y el valor comercial para todos los
involucrados en la cadena de soporte técnico era desprenderse de los
procesos tradicionales de gestión de incidencias y proporcionar una
solución de gestión de servicios integrada holísticamente y que funcione
con IA". (Gourvenec, 2017, ‘ServiceAide crea una experiencia completa
de servicios para la gestión de incidencias con Inteligencia Artificial’)

La empresa industrias Loo S.A.C se dedica principalmente a la

producción de útiles escolares dentro del mercado peruano, conformada
por diversas áreas en las cuales el recurso informático es de gran apoyo
en las tareas como empresa y su influencia en los procesos de la misma.
Sin embargo, la empresa cuenta con un proceso de gestión de incidentes
ineficaz que no es el adecuado para la gestión de las mismas y trae
consigo muchas irregularidades, entre las cuales se encuentran la
perdida de la información, incidentes no resueltos e inconformidad por
parte de los usuarios de la empresa.

18
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

El actual proceso el cual se realiza de la siguiente forma los usuarios de

diversas áreas llaman al anexo del área de soporte o envían un correo al
área y como en muchos caso de forma verbal, solicitan apoyo con
respecto a sus equipos de cómputo, explicando brevemente lo sucedido,
se recolectan algunos datos del usuario la hora de la llamada y el
problema en un archivo excel. Asignando aleatoriamente un técnico
dependiendo la disponibilidad de los mismos para la solución del
incidente el cual se acerca al área donde se realizó la llamada realizando
un diagnostico básico de lo sucedido verificando si el incidente yace en
el hardware o software, con esos detalles el técnico procede a dar
solución al incidente, luego de solucionada la incidencia esta se cierra de
forma verbal con el personal y se actualiza en la hoja excel el estado de
la incidencia, campos como el asunto de la incidencia, quien el reporto la
incidencia y actualizando el estado de la incidencia en el archivo como
cerrada. El problema principal en el actual proceso de gestión de
incidencias es en la fase del registro es que muchas veces los datos de
las incidencias no se registran correctamente siendo estos de gran
importancia a lo largo de la resolución de la incidencia o en casos estos
campos son omitidos por el personal y muchas veces los datos son
alterados, o en algunas ocasiones los archivos son borrados por no
contar con los niveles de seguridad adecuados.

Además al no contar con un sistema de asignación eficiente que permita

una mejor designación de los recursos muchas incidencias se asignan a
personal inexperto el cual al solicitar el apoyo de un personal más
adiestrado en esos temas retrasa la resolución de las demás incidencias
en cola por lo que muchas de estas incidencias al finalizar el día quedan
sin solución postergándose para el día siguiente y en muchos caso no se
les da una solución, perjudicando la productividad de la empresa y de las
áreas involucradas.

Como consecuencia se evidencia que el porcentaje de incidencias

resueltas es menor al número que se reporta y esto se debe a que

19
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

muchas de las incidencias reportadas no puedan ser solucionadas

debido a que el técnico no cuenta con la información completa de la
incidencia por lo que se necesita de un sistema que nos permita realizar
esta gestión de una manera eficaz.
Figura 1
Fuente: Elaboracion propia

Estadísticas Porcentaje de incidencias resueltas

Tal como se puede apreciar en el gráfico el porcentaje máximo de

incidencias resueltas suele alcanzar valores cercanos al 62% esto quiere
decir que hay cerca del 38 % de incidencias que no resuelves en la
organización retrasando a los usuarios en sus labores y afectando las
operación de la empresa.
De la misma forma la actual gestión de incidencias impacta en el
porcentaje de incidencias resueltas dentro del SLA, que a su vez refleja
el nivel de servicio del área respecto a los usuarios dado que no se cuenta
con un sistema de priorización de incidencias de acuerdo al impacto y
urgencia de las mismas muchas incidencias no son tratadas de acuerdo
a la prioridad correspondiente, aumentando el grado de insatisfacción del
usuario final debido a que su incidencia puede ser resuelta pero no en el
tiempo acordado dentro del SLA.

20
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 2
Fuente: Elaboracion propia

Estadísticas Porcentaje de incidencias resueltas dentro del SLA

Tal como se puede evidenciar en las imágenes el porcentaje de

incidencias resueltas dentro del SLA es inferior al 50% esto nos da a
conocer que muchas de las incidencias no son resueltas en el tiempo
estipulado en el contrato SLA así mismo el grado de satisfacción del
usuario final con respecto al servicio de soporte prestado por el área.

De igual manera es de gran necesidad del área de sistemas contar con

reportes que muestren los datos de las incidencias tales como fechas
áreas y técnicos asignados los cuales no son de gran precisión dado que
el actual proceso no brinda los datos requeridos para la emisión de los
mismos.

Para poder definir de manera concisa el problema principal se llevó a

cabo una entrevista al Coordinador del área de sistemas (Ver Anexo
N°2), el cual indica que no existe actualmente un sistema informático que
pueda realizar todas estas actividades de manera eficaz y ágil,
indicándonos además se recalca la deficiencia en cuanto al registro de

21
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

los datos de una incidencia en la cual al no existir control sobre los datos
,los datos perdidos o incompletos de las incidencias ocasionan que no
puedan ser atendidos y una necesidad de contar con un sistema de
asignación que les permita asignar a un técnico a una incidencia de
acuerdo a su categoría, urgencia y prioridad reduciendo el tiempo de la
atención de la misma , así como contar con reportes que les permita
conocer más de las incidencias reportadas por área por usuario o por
fechas .

Si no se le da solución a esta problemática la productividad de la empresa

se ve afectada ya que hoy en día los equipos de cómputo constituyen
una de las herramientas más usadas en las operaciones del personal
para cumplir con las labores asignadas además tomando cuenta la
información almacenada en estos equipos puede comprometerse si no
se cuenta con un adecuado sistema de gestión de incidencias que pueda
dar solución rápida y eficaz a las incidencias que suscitan en la
organización.

1.2. Trabajos Previos

• En el Perú, Vilma Palli Apaza (2014, p. 11) en la tesis “Modelo de gestión
de incidencias basada en ITIL para reducir el tiempo de diagnóstico de
incidentes del servicio de soporte técnico en la universidad Nacional del
Altiplano Puno-2014” desarrollada en la Universidad del Altiplano de la
Escuela Profesional de Ingeniería de Sistemas, Puno- Perú. Se
identificó la problemática en la deficiencia de la gestión de incidentes
ya que la notificación de una incidencia se realiza mediante correos
dirigidos al jefe de TI o de forma verbal y estos no se resuelven de forma
puntual desconociéndose el tiempo exacto de resolución de los mismos,
haciendo énfasis en la falta de un mecanismo de gestión de incidencias
estos no son debidamente canalizados de esta forma se ve afectado el
tiempo de respuesta de parte de los técnicos. Los objetivos la
investigación fueron el desarrollo de un modelo de gestión de
incidencias fundamentado en ITIL con el objetivo de minimizar el tiempo

22
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

de diagnóstico en los incidentes del servicio de soporte técnico. El tipo

de investigación es de tipo experimental,” la población fue constituida
por los incidentes reportados, la muestra fueron 54 incidentes que
fueron reportados entre mayo y junio del 2014.de la investigación
mencionada se logró concluir que el modelo de gestión de incidencias
fundamentado en ITIL permitió minimizar notablemente el tiempo de
diagnóstico de las incidencias en la cifra de 77% del servicio de soporte
técnico de igual forma logro incrementar el ratio de incidencias
atendidas de 45. 36 % a 91.32% del servicio de soporte técnico,
además que el proceso de gestión de incidencias actual de acuerdo a
el grado de madurez propuesto por ITIL se encuentra en nivel inicial y
que el modelo de gestión de incidencias definió nuevos procesos, roles
y políticas. Con la puesta en funcionamiento del nuevo modelo se logró
el desarrollo de una herramienta que minimiza el tiempo de diagnóstico
de las incidencias, prueba de hipótesis dio como resultado que el
actual modelo minimiza significativamente el tiempo de diagnóstico”.
De la investigación expuesta se tomó como referencia el modelo de
trabajo en el desarrollo del sistema web para el proceso mencionado.
Así mismo se tomó como aporte de aprendizaje, las dimensiones con las
cuales cuenta gestión de incidencias, además como se lleva a cabo el
análisis del proceso de creación de incidencias finalizando en las
conclusiones y como llevar a cabo la puesta en funcionamiento de un
sistema de gestión de incidencias en una organización.

• En Perú , Janett Aracely Gonzales ( 2015, p. 10) en la tesis

“Implementación Del Marco De Trabajo ITIL V.3.0 Para El Proceso De
Gestión De Incidencias En El Área Del Centro De Sistemas De
Información De La Gerencia Regional De Salud Lambayeque”
desarrollada en la universidad Católica Santo Toribio De Mogrovejo
Planteó como problemática la deficiencia de la actual gestión de
incidencias que no apoya en la solución de las mismas y la calidad del
servicio brindado a los usuarios , se obtuvo que el 67 % de los
trabajadores afirman que cuando se contactan al CSI (Centro de solución

23
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

de incidencias ) por una incidencia, esta es resuelta satisfactoriamente

solo algunas veces, es por ello que el 100% dice que frente a una
incidencia la solución que brinda no es por completo, por consiguiente el
servicio que brinda el CSI (Centro de sistemas de información ) no es
beneficioso para el 100% de los trabajadores, además de no llevarse un
control documentado sobre las incidencias y soluciones a menudo, esto
en un 100%.Tuvo como objetivo aumentar el número de incidencias
resueltas, reducir el tiempo destinado a la atención de las incidencias de
las TI, reducir los tiempos de solución de las incidencias de las TI
aumentar la satisfacción de los usuarios respecto al servicio de atención
y solución de incidencias. Para la tesis en mención se tuvo como
población a los trabajadores de la gerencia regional de salud y con esta
investigación se concluyó que con la implementación de las
herramientas basadas en el marco de trabajo ITIL v3.0, para la gestión
de incidencias de TI, como resultados se logró aumentar el porcentaje
de incidencias resueltas de 45.25% a 85.48% , de la misma forma se
logró incrementar el nivel de servicio del área del CSI de 56.12% a
89.12% , esto gracias a que se desarrollaron procedimientos
estandarizados y fáciles de entender que apoyaron la agilidad en la
atención, logrando así que los encargados responsables de TI del área
del Centro de Sistemas de Información (CSI) brindaran y cumplieran con
todos los servicios que solicitaban los trabajadores de las diferentes
áreas que conforman, a través de la incorporación de ITIL, se redujo los
tiempos de solución de las incidencias de las TI, esto se logró gracias a
que los encargados responsables de TI del área del CSI gestionaron de
la mejor manera posible las incidencias de TI que reportaban los
trabajadores.

De este antecedente se tomó en cuenta como aporte el marco teórico ya

que tiene una buena fundamentación además de contar con conceptos
de importantes autores.

24
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

• En el Perú , Frank Raúl Ruiz Zavaleta (2014, p. 13) en la tesis “Itil V3

Como Soporte En La Mejora Del Proceso De Gestión De Ias Incidencias
En La Mesa De Ayuda De La Sunat Sedes Lima Y Callao” desarrollada
en la Universidad Peruana De Integración Global. Encontró como
problemática que “la mesa de ayuda no contaba con un marco de
referencia para la gestión de servicios de ti, por ende la forma de
manejar la gestión de incidencias, sumado a la falta de cultura
informática por parte de los usuarios, ocasionaba lo siguiente:
Incumplimiento de los indicadores impuestos por la alta dirección, la
creación de usuarios insatisfechos por la mala y/o lenta gestión de sus
incidencias, los tiempos de atención aumenten, que no se registre las
incidencias, que no existan una clasificación de incidencias y el
desconocimiento sobre las causas y efectos de las incidencias para
futuras reestructuraciones y evoluciones.
El objetivo de la investigación fue “Mejorar del proceso de gestión de
incidencias en la mesa de ayuda de la SUNAT sedes Lima y Callao así
mismo a) Lograr la satisfacción del usuario soportada por el tiempo de
resolución en la mesa de ayuda. b) Conseguir el cumplimiento de
indicadores soportado por la cantidad de incidencias atendidas en la
mesa de ayuda c) Mejorar la calidad del servicio a través de la eficiencia
mostrada en la mesa de ayuda. d) Optimizar la productividad a través
de la resolución por niveles en la mesa de ayuda de la SUNAT sedes
Lima y Callao– 2014.Como población estuvo conformada por la
cantidad de usuarios de Lima y Callao, incluido el personal de mesa de
ayuda. El tamaño de la población es: 8000.Como resultados se obtuvo
de las encuestas, el 45% de los usuarios finales concluyen que la Mesa
de Ayuda tiene una calidad de servicio excelente y el 50% de lo califican
como buena, la calificación va en relación a la eficiencia mostrada en
las soluciones de las incidencias reportadas”.

De este antecedente se tomó en cuenta el aporte conceptual al presente

trabajo de investigación así como el marco teórico.

25
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

• En Perú, Luis Carlos Gamarra Muro (2013, p. 23) en la tesis

"Implementación de un sistema de gestión de incidencias para la
empresa Creditex S.AC " desarrollada en la Pontificia Universidad
Católica Del Perú, Lima-Perú. Planteó como problemática en la falta de
calidad de atención a los usuarios en el área de soporte la cual es la
encargada del mejoramiento de la calidad de los servicios de apoyo a las
labores operativas de soporte, ayudando a mantener buen estado los
equipos de cómputo, evaluar y supervisar el buen funcionamiento de
estos y atender los problemas que los usuarios tengan con respecto a
estos. Se halló mediante una encuesta que solo el 14.29% de los
usuarios se encuentra conforme con respecto al servicio del área de
soporte técnico, lo cual fue una cifra preocupante. También se encontró
que el tiempo de atención es de aproximadamente 8:54 horas sumando
las horas de espera 2 horas y las horas de atención 6:54 , por lo cual el
principal inconvenientes es que el área no cuenta con estándares
definidos para llevar a cabo las actividades ofrecidas por el área,
pudiendo esta ser más rápida y ágil. Los objetivos de la investigación
fueron definir la influencia de la reingeniería de gestión operativa aplicada
al área de soporte técnico en el servicio de atención a usuarios de la
organización, el tipo de investigación fue Experimental y el diseño Pre-
Experimental, como población para el indicador 1 se tuvo a los usuarios
internos de la institución los cuales sumaron 442 ,y para el indicador 2 se
tomó la atención al usuario en un periodo de 20 días .Con esta
investigación se concluyó que, después de la reingeniería aplicada el
nivel de atención a usuarios paso de 36.29% a 79.29%, se observó una
mejora en la eficacia en el servicio de atención a usuarios. Se redujo el
tiempo de atención que inicialmente estaba en 534 minutos pasos a ser
de 55 minutos aumentando la efectividad en un 871%.
De este antecedente se tomó en cuenta como aporte el marco teórico ya
que se considera que cuenta con conceptos solidos sobre el tema.

26
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

• En Venezuela Añez Araujo Arnaldo José (2014, p. 26) en la tesis

“Implementación Sistema web gestión de incidencias para la empresa
Servicios Fv Venezuela 2014” desarrollada en la Universidad Nueva
Esparta de la Facultad de Ciencias de la Informática –Venezuela.
Identifica que la problemática en el proceso de gestión de incidencias se
llevaban los registros de ingresos, almacenamientos y monitorización de
los equipos de cómputo, de todos los clientes que solicitaron el servicio
para la reparación de su equipo o dispositivo, el personal técnico
realizaba el registro que son de forma manual mediante creando nuevos
archivos en hojas de cálculo. Lo expuesto represento un problema para
la empresa ya que son varios archivos creados y que son modificados
muchas veces son compartidas entre otros equipos de cómputos de los
distintos cliente lo cual genera deficiencias en la información y perdida de
registro de los clientes. Tuvo como objetivo principal implementar un
sistema de gestión de incidencias para la empresa Servicios Fv
Venezuela 2014, teniendo como objetivos específicos la determinación
de los requerimientos de información necesarios para la gestión de
incidencias. En la fase de desarrollo del sistema Web se hizo uso de la
metodología RUP por ser una entidad de estado y además ser la
herramienta que permite producir un software de calidad, la arquitectura
tecnológica del software está compuesta por el motor de base de datos
MySQL y el lenguaje de programación PHP. Para efectuar la
investigación y cumplir los objetivos planteados se empleó la
investigación pre experimental donde se tomó una muestra de 50
registros de incidencias para ser utilizados como objetos de estudio,
utilizando la prueba de normalidad de Alfa de Cronbach. Se concluyó que
el porcentaje de incidencias resueltas dentro del plazo acordado en el
proceso de gestión de incidencias de la empresa Servicios Venezuela FV
incrementa considerablemente, ya que previa a la implementación del
sistema fue de 18,02 % y luego de la implantación se tiene 88,02 %, la
cual significó un aumento de 70% en el porcentaje de incidencias
resueltas en el plazo acordado, así mismo el porcentaje de incidencias
resueltas en el proceso de gestión de incidencias aumentaron

27
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

notablemente , puesto que previo a la implementación del sistema fue de

50,15 % y luego de la implantación se obtuvo 90,58 % lo cual significa
un aumento de 40,43 % en el porcentaje de incidencias resueltas.

De la presente investigación se tomó en cuenta como referencia el

modelo usado para el desarrollo de software modelo, vista, controlador,
así como la importancia de la aplicación del mismo en el desarrollo del
sistema web de gestión de incidencias.

• En Finlandia Antti Korhonen (2013, p.25) en la tesis "Role-specific Critical

Success Factors in Incident Management" desarrollada en la Universidad
de Jyvaskyla en el Departamento de Ciencias de la Computación y
Sistemas de Información- Finlandia. Mencionó la siguiente problemática
el cambio del modelo de negocios a un modelo de negocios basado en
servicios El autor hace mención en cómo se describe un servicio de
modelo de negocios, también comenta los grandes gestores individuales
de revestimiento definen que el desafío en los países desarrollados del
mundo se encuentra en elevar la productividad de los conocimientos y
de servicio. El autor hace énfasis en que el servicio de atención al cliente
se ha centrado en torno a la gestión de servicios de TI, además describe
que se debe contar con los marcos de gestión como ITIL y COBIT para
poder atender a las incidencias. Las empresas se ven cada vez más
interesadas en la gestión de los servicios ofrecidos por el departamento
de TI tanto a clientes externos e internos, un modo de ver la diferencia es
que antes se veían en forma de información perdida hoy en día son los
SLAs los que definen en términos de objetivos de negocio. El principal
objetivo de la tesis fue proporcionar un conocimiento de la gestión de
incidentes y sus factores críticos de éxito(CSF) , experimentadas por los
diversos actores que participan en este proceso, el objetivo final se centra
en producir diferentes CSF a cada función en que participa en proceso
de gestión de incidentes.

28
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

De esta investigación se tomó en cuenta las definiciones de gestión de

incidencias así como el uso de modelos de negocios basados en gestión
de servicios de TI., usando como referencia la librería de buenas
prácticas ITIL y COBIT como guía para el proceso de gestión de
incidencias y mejorar la atención a los clientes externos e internos.

• En Noruega Bimal Raj (2014, p.29) en la tesis de maestría “Indicators for

ICT security incident management” desarrollada en la Norwegian
University of Science and Tecnology en el Departamento de Telematics
– Noruega. La cual nos habló sobre las vulnerabilidades a que se ve
expuesta la información a atacantes informáticos denominados
técnicamente hackers .Estos sustraen información por distintos motivos,
algunos buscan lucrar con ello, otros generar incomodidad en las
organizaciones y sus valores y otro por el simple hecho de filtrar la
información secreta. No obstante definición de la seguridad de la
información ha sido tema de debate, y la explicación más acertada es
que la seguridad de la información es, Seguridad de la información es el
modo de garantizar la confidencialidad, integridad y disponibilidad (CIA)
de una información. Los sistemas de información son activos críticos en
toda empresa pero apoyan a la organización, esencialmente para
protegiendo la información crítica, es ahí donde entra en juego la
seguridad de la información. La solución que propone la investigación fue
establecer metas definidas, con este poder cuantificar la información y
los indicadores del sistema, en diferentes procesos financiero, salud,
comunicación, ingeniería, redes, seguridad entre otros.
De esta investigación se tomó el marco teórico referente a seguridad
aplicada a los sistemas de información.

1.3. Limitaciones
En la presente investigación cuyo título es: sistema web para el proceso
de gestión de incidencias en la empresa industrias Loo S.A.C, como
variable dependiente se consideró al proceso de gestión de incidencias,
de acuerdo a la investigación realizada se encontró la limitación en la

29
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

búsqueda y alcance de la definición de la variable dependiente, ya que

no existe los procesos de gestión ni no gestión de procesos. Según la
ISO 9000:2000, define “la Gestión por Procesos se basa en la
modelización de los sistemas como un conjunto de procesos
interrelacionados mediante vínculos causa-efecto. El propósito final de la
Gestión por Procesos es asegurar que todos los procesos de una
organización se desarrollan de forma coordinada, mejorando la
efectividad y la satisfacción de todas las partes interesadas (clientes,
accionistas, personal, proveedores, sociedad en general).” (Novelo,
2002, p. 245 ).

Por lo tanto, de acuerdo con la definición de la ISO, en la presente

investigación se determinó a la variable dependiente: gestión de
incidencias.

1.4. Teorías Relacionadas al Tema

Sistema Web:
“Un sistema web se describen como aquellas aplicaciones que los
usuarios pueden hacer uso ingresando a un servidor web por internet
a través del protocolo HTTP (protocolo de transferencia de hipertexto)
utilizando un navegador web tales como Internet Explorer de Microsoft,
Google Crome, etc.” (Berzal, 2005, p. 315)
“La implementación de un sistema web apoyan a la gestión de procesos
más importantes, dando respuestas rápidas a las necesidades del
negocio y brindando un mejor servicio” (Maza, 2009, p.386)
“Un sistema web está formado por clientes y servidores que se encargan
de manejar información, utilizan un protocolo de transferencia de
hipertexto desarrollado específicamente para la web”(Romero, 1998, p.
112)

30
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 03
Fuente: Lujan 2002

Arquitectura Cliente servidor

Componentes De Un Sistema Web

“Un sistema web es un conjunto de componentes que se relacionan entre
sí.
• Framework:
Estructura de software integrada de diferentes elementos
personalizables e intercambiables para la construcción de una aplicación.
Se considera como aplicación genérica incompleta y configurable la que
podemos añadirle más piezas para lograr una aplicación completa.

• Servidor web:
Un servidor web participa como contenido estático a un explorador web,
recibe peticiones del usuario y le envía el archivo solicitado
transmitiéndolo a través de la red al navegador web del usuario.
Este intercambio entre el navegador y el servidor se realiza gracias al
protocolo HTTP (protocolo de transferencia de hipertexto).

• Base de datos:
Es un sistema informático gracia al cual se guardan registros, descrito
como un contenedor de una colección de archivos de datos, es capaz de
almacenar miles de registros, para su posterior uso. Entre las diferentes

31
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

acciones que se pueden realizar dentro de una base de datos se

encuentran agregar, eliminar, modificar, actualizar etc.
• Cliente:
El cliente web se define como la aplicación con la cual interactúa el
usuario para poder solicitar al servidor web ciertos recursos que desea
obtener.

Arquitectura de un sistema web

Modelo Vista Controlador (MVC)
Se describe como el patrón de diseño de software que tiende a
independizar los elementos de una aplicación en tres partes que serán
explicadas brevemente en el siguiente punto.

Figura 04
Fuente: Sánchez 2012

Modelo Vista Controlador

• Modelo:
Representa la parte que especifica la lógica del negocio, quiere decir que
se encarga del tratamiento de datos así como la validación y le
procesamiento de los mismos, transformándolos en conceptos
significativos para el sistema.

32
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

• Vista:
Hace referencia a la representación de los datos de la capa del modelo,
trabajando de forma independiente al mismo, su tarea es producir
interfaces con la información solicitada de acuerdo a las peticiones del
usuario.
• Controlador:
Responsable de atender las peticiones de los usuarios con la información
solicitada, apoyándose en las capas de modelo y vista para lograr su
tarea, la capa de controlador recibe peticiones y responde a las mismas
de acuerdo al nivel de autorización o autenticación.” (Lujan, 2002, p. 156)

Gestión de incidencias
“la gestión de incidencias es el proceso que tiene como objetivo
resolver, de la manera más rápida y eficaz posible, cualquier incidente
que cause una interrupción en el servicio” (Klosterboer, 2008, p. 129)

“cubre cualquier evento que interrumpa o pueda interrumpir un servicio.

Esto significa que incluye eventos comunicados directamente por los
usuarios, ya sea a través del Centro de Servicio al Usuario o con las
diversas herramientas disponibles.” (ITIL V3, 2009, p. 166)

“La gestión de incidencias es un proceso ITIL enmarcado en la fase de

Operación del Servicio que se encarga de gestionar las incidencias del
servicio. Las incidencias pueden incluir fallos o consultas reportadas por
los usuarios, el equipo del servicio o por alguna herramienta de
monitorización de eventos” (Desongles, 2006, p. 566)

Incidencia

“Una incidencia es una interrupción no planificada o una reducción de

calidad de un servicio de TI. El fallo de un elemento de configuración que

33
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

no haya afectado todavía al servicio también se considera una incidencia”

(De Jong, Kolthof, Van, Pieper, Tjassing, Verheijen, 2008, p. 129)

• Fases de la gestión de incidencias

Se comenzará a describir las fases involucradas a lo largo de la gestión
de incidencias fundamentándonos en el libro de las buenas prácticas
para TI, ITIL V3, específicamente en su cuarto libro llamado “Service
Operation” el cual define las siguientes fases:

• Identificación de la incidencia
“El Trabajo no puede comenzar a tratar con una incidencia hasta que no
se detecte .Normalmente es inaceptable, desde una perspectiva de
negocio, esperar hasta que un usuario se vea afectado y se ponga en
contacto con el centro de servicio al Usuario. Siempre que sea posible,
todos los componentes clave deben monitorizarse para detectar
anticipadamente fallos reales o potenciales para que la gestión de
incidencias pueda comenzar rápidamente. Idealmente, las incidencias
deben resolverse antes de que tengan impacto en el usuario” (ITIL V3,
2009, p. 167)
• Registro de la incidencia
“Todas las incidencias deben registrar en su totalidad y marcarse con una
fecha/hora independientemente de si salieron a la luz a través de una
llamada telefónica al Centro de Servicio al Usuario o si se detectaron
automáticamente a través de una alerta de eventos.
Deberá registrarse toda la información relevante asociada a la naturaleza
de la incidencia para que se mantenga un registro histórico completo y
para que si fuera necesario remitir la incidencia a otros grupos de soporte
tengan la información relevante a mano para ayudarles.
La información necesaria para cada incidencia probablemente incluirá:

• Número de referencia único

• Categorización de Incidentes (a menudo dividido en entre dos y
cuatro niveles de subcategorías)

34
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

• Urgencia de Incidentes
• Impacto de incidentes
• Priorización de Incidentes
• Fecha / hora grabada
• Nombre / ID de la persona y / o grupo a grabar el incidente
• Método de la notificación (teléfono, email automático, en
• persona, etc.)
• Nombre / departamento / teléfono / ubicación del usuario
• Callback método (teléfono, correo, etc.)
• Descripción de los síntomas
• Estado de Incidentes (activo, a la espera, cerrado, etc.)
• CI Relacionados
• Grupo de Apoyo a la persona a la que se asigna / el incidente
• Problemas relacionados / Error Conocido” (ITIL V3, 2009, p. 168)

• Categorización de la incidencia
“Parte del registro inicial deberá asignar una codificación adecuada para
la categorización de incidencias para que se registre el tipo exacto de la
llamada. Esto será importante posteriormente al analizar
frecuencias/tipos de incidencias para establecer tendencias de uso en
Gestión de Problemas, Gestión de Proveedores y otras actividades de
ITSM” 1 (ITIL V3, 2009, p. 169)

35
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 05
Fuente ITIL V3.Operacion del servicio, 2009

Categorización de incidencias multinivel

• Priorización
“Otro aspecto importante del registro cada incidente es estar de acuerdo
y asignar un código de prioridad apropiada - ya que esto determinará la
forma en que se gestiona el incidente, tanto por las herramientas de
apoyo y personal de soporte.
La priorización normalmente se puede determinar teniendo en cuenta
tanto la urgencia del incidente (la rapidez con la empresa necesita una
resolución) y el nivel de impacto que está causando. Una indicación de
impacto es a menudo (pero no siempre) el número de usuarios se vea
afectado. Sin embargo, hay que señalar que habrá ocasiones en las que,
debido a la conveniencia particular, de negocios o lo que sea, los niveles
de prioridad normal tienen que ser anulado. Cuando un usuario está
convencido de que el nivel de prioridad de un incidente debe exceder
pautas normales, el Centro de Servicio debe cumplir con una solicitud de
este tipo. .” (ITIL V3, 2009, p. 170)

36
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Tabla 01: Cruce entre Impacto y urgencia

Fuente: ITIL V3.Operacion del servicio, 2009

Tabla 02 : Tabla de prioridad

Fuente: ITIL V3.Operacion del servicio, 2009

• Diagnóstico inicial
“Si el incidente se ha encaminado a través del área de soporte técnico,
debe llevar a cabo el diagnóstico inicial, normalmente el usuario está
todavía en el teléfono si la llamada se eleva de esta manera – tratar de
descubrir los sistemas completos del incidente y determinar exactamente
lo que se ha salido mal y corregirlo en esta parte el técnico hará dicha
labor.
En esta etapa las secuencias de comando de diagnóstico y la información
de error conocido pueden ser más valiosas permitiendo el diagnóstico
preciso. El técnico debe informar al usuario de sus intenciones, dar al

37
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

usuario el incidente el número de referencia y tratar de encontrar una

solución.” (ITIL V3, 2009, p. 170)

• Escalamiento
“Escalado funcional. Tan pronto como se pone de manifiesto que el
Centro de Servicio es incapaz de resolver el incidente en sí (o cuando se
han superado los tiempos objetivos para la resolución de primer punto -
lo que ocurra primero) el incidente debe ser escalada inmediatamente
para obtener más ayuda. Si la organización tiene un grupo de apoyo de
segundo nivel y el Centro de Servicio cree que el incidente puede ser
resuelto por dicho grupo, se debe remitir el incidente a ellos. Si es obvio
que el incidente necesitará más profunda técnico conocimiento - o
cuando el grupo de segundo nivel no ha sido capaz de resolver el
incidente dentro de los tiempos acordados objetivo (lo que ocurra
primero), el incidente debe ser escalado de inmediato al grupo de soporte
de tercer nivel apropiado. Tenga en cuenta que los grupos de apoyo de
tercer nivel pueden ser internas - pero también pueden ser terceros,
como proveedores de software o fabricantes de hardware o personal de
mantenimiento. Las reglas para escalamiento y el manejo de incidentes
deben ser acordados en OLA y UC con grupos de soporte interno y
externo, respectivamente.” (ITIL V3, 2009, p. 171)

• Investigación y Diagnóstico
“En el caso de incidentes en los que el usuario está simplemente en
busca de información, el Centro de Servicio debe ser capaz de
proporcionar esta con bastante rapidez y resolver la solicitud de servicio
- pero si se está reportando un fallo, esto es un incidente y probablemente
requiera algún grado de investigación y el diagnóstico.
Cada uno de los grupos de apoyo que participan en el manejo de
incidentes investigará y diagnosticar lo que ha ido mal - y todas esas
actividades (incluyendo detalles de todas las medidas adoptadas para
tratar de resolver o volver a crear el incidente) deben estar totalmente

38
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

documentados en el registro de incidentes por lo que un registro histórico

completo de todas las actividades se mantiene en todo momento.
Esta investigación es probable que incluya acciones tales
Como:
• Establecer exactamente lo que ha salido mal o lo que está buscando
el usuario.
• Entender el orden cronológico de los acontecimientos
• Confirmar el impacto total de la incidencia, incluyendo el número y
rango de los usuarios afectados.
Buscar información sobre las ocurrencias previas.” (ITIL V3, 2009, p. 172)

• Resolución y recuperación
“Cuando una resolución potencial ha sido identificado, este debe
aplicarse y probado. Las acciones específicas deben realizarse y las
personas que estarán involucradas en la toma de las acciones de
recuperación puede variar, dependiendo de la naturaleza de la avería. El
usuario podrá llevar a cabo actividades dirigidas por su propia cuenta
escritorio o equipos de cómputo. Los técnicos dan una resolución de
forma manual para tomar el control de forma remota mediante un
software para tomar el control del usuario/escritorio para diagnosticar e
implementar una resolución.” (ITIL V3, 2009, p. 173)

• Cierre de la incidencia
“El técnico de soporte de TI debe comprobar que el incidente está
totalmente resuelto y que los usuarios están satisfechos y dispuestos a
aceptar el incidente se puede cerrar. El técnico también debe comprobar
lo siguiente: Categorización Clausura: Comprobar y confirmar que el
incidente inicial categorización era correcto o, en la categorización
posteriormente resuelto ser incorrecto categorización se registra por el
incidente como resolver. Encuesta de satisfacción del usuario: llevar a
cabo una satisfacción de los usuarios de devolución de llamada o correo
electrónico encuesta para el porcentaje acordado de incidentes.
Documentación de incidentes: persigue detalles pendientes y garantizar

39
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

que el registro de incidentes está completamente documentado de

manera que un registro histórico completo en un suficiente nivel de
detalle es completa Clausura Oficial: formalmente cerrar el registro de
incidentes” (ITIL V3, 2009, p. 173)

40
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Fuente: ITIL V3.Operacion del servicio, 2009 Figura 06

Fases de la Gestión de incidencias

41
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Dimensión: Resolución y recuperación

Indicador 01: Porcentaje de Incidencias resueltas dentro del SLA

Porcentaje de Incidencias Resueltas dentro del SLA

Fórmula:

Figura 7
Fuente : Klosterboer, 2008

Fórmula Porcentaje de Incidencias Resueltas dentro del SLA

Dónde:
PRSLA: Porcentaje de incidencias resueltas dentro del SLA
CRSLA: Cantidad de incidencias resueltas dentro del SLA
TIR: Total de incidencias resueltas

42
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Dimensión: Resolución y recuperación

Indicador 02: para la gestión de incidencias
Porcentaje de Incidencias Resueltas
Fórmula:

Figura 08
Fuente: Juárez, 2014

Fórmula Porcentaje de Incidencias Resueltas

Dónde:
PIR: Porcentaje de incidencias resueltas
CCR: Cantidad de incidencias resueltas
TIR: Total de incidencias registrados

Metodologías de Desarrollo
RUP (PROCESO UNIFICADO RACIONAL)
“RUP es un Proceso de Ingeniería de Software que ofrece una
metodología disciplinada para la asignación de tareas y
responsabilidades en una organización de desarrollo de software”
(Jimenez, 2012, p. 215)
La metodología RUP es “más que un único método de desarrollo, el UP
pretende ser un marco de trabajo […] general que se pueda especializar
según las necesidades de cada empresa” (Galindo, 2013, p. 203)
“RUP se describe normalmente desde tres perspectivas:
• Una perspectiva dinámica que muestra las fases del modelo
sobre el tiempo.

43
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

• Una perspectiva estática que muestra las actividades del proceso

que se representan.
• Una perspectiva práctica que sugiere buenas practicas a utilizar
durante el proceso.(Sommeville, 2005, p. 254)

Figura 09
Fuente: Jiménez, 2016

Rational Unified Process

Sus principales características son:
• Método dirigido por requisitos del sistema.
• Iterativo e incremental.
• Importancia de definir la arquitectura de software.
• Uso de un lenguaje de modelización visual.
• Integración de la gestión, configuración y cambios en el
proyecto.” (Sommeville, 2005, p. 255)

Perspectiva Dinámica
“El RUP es un modelo en fases que identifica cuatro fases diferentes en
el proceso del software […] Las fases en el RUP están mucho más
relacionadas con asuntos de negocio más que técnicos”. (Sommeville,
2005, p. 256)

44
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 10

Fuente: Rumbaugh, 2000

Fases de RUP

• Inicio:
“El objetivo de la fase de inicio es el de establecer un caso de negocio
para el sistema. Se deben identificar todas las entidades que
interactuarán con el sistema y definir estas interacciones”.17

Esta información es usada para evaluar el aporte que el sistema realiza

al negocio. En esta fase si las aportaciones son de poca relevancia, se
puede dar por cancelado el proyecto. (Sommeville, 2005, p. 255)

• Elaboración:
“los objetivos de la fase de elaboración son desarrollar una comprensión
del dominio del problema, establecer un marco de trabajo arquitectónico
para el sistema, desarrollar el plan del proyecto e identificar los riesgos
clave del proyecto”. (Sommeville, 2005, p. 256)

En dicha fase, se logra alcanzar un modelo de los requerimientos del

sistema.

• Construcción:
“Esta fase comprende el diseño del sistema, la programación y las
pruebas. Durante esta fase, se desarrollan e integran las partes del
sistema. Al terminar esta fase, se debe tener un sistema operativo y con
la documentación respectiva para la entrega a los usuarios” (Sommeville,
2005, p. 257)

45
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

• Transición:
“La fase final de RUP se ocupa de mover el sistema desde la comunidad
d desarrollo a la comunidad del usuario y hacerlo trabajar en un entorno
real”. (Sommeville, 2005, p. 258)

Al finalizar esta etapa, contaremos con un software operativo que

trabaje eficientemente en su entorno.

Perspectiva Estática
“el ciclo de vida de la metodología RUP desarrollada en cada iteración,
se realiza bajo la guía combinada de dos disciplinas

Disciplina de desarrollo:

o Inteligencia de Negocios: Consiste en entender las necesidades del

negocio.

o Análisis de Requerimientos: Traslada las necesidades del negocio a un

sistema de información.

o Análisis y Diseño: Traslada los requerimientos dentro de la arquitectura

de software.

o Implementación: Crear un software de acuerdo a la arquitectura y el

comportamiento deseado.

o Pruebas: Asegurar que el comportamiento requerido es el correcto y que

todo lo solicitado está presente. ”. (Sommeville, 2005, p. 259)

• Disciplina de soporte:
o Configuración y administración del cambio: Guarda todas las
versiones del proyecto.

o Administración del proyecto: Administra horarios y recursos.

o Ambiente: Administra el ambiente de desarrollo.

o Distribución: Hacer todo lo necesario para la salida del

proyecto.

46
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Perspectiva Práctica
RUP describe buenas prácticas de la Ingeniería del Software
que son aconsejables en el desarrollo de sistemas. Se
recomiendan seis buenas prácticas (Sommeville, 2005, p. 260)

• Desarrolle el software de forma interactiva.

• Gestiones los requerimientos.
• Utilice arquitecturas basadas en componentes.
• Modele el software visualmente.
• Verifique la calidad del software.
• Controle los cambios del software

XP (Extreme Programming)
"XP es una metodología ágil centrada en potenciar las relaciones
interpersonales como clave para el éxito en desarrollo de software,
promoviendo el trabajo en equipo, preocupándose por el aprendizaje de
los desarrolladores, y propiciando un buen clima de trabajo. XP se basa
en realimentación continua entre el cliente y el equipo de desarrollo,
comunicación fluida entre todos los participantes, simplicidad en las
soluciones implementadas y coraje para enfrentar los cambios. XP se
define como especialmente adecuada para proyectos con requisitos
imprecisos y muy cambiantes, y donde existe un alto riesgo técnico

Las principales características de la metodología XP están divididas en

los siguientes elementos: historias de usuario, roles, proceso y
prácticas:”(Letelier, 2006, p. 236)

• Historias de Usuario
“Son la técnica utilizada para especificar los requisitos del software. Se
trata de tarjetas de papel en las cuales el cliente describe brevemente las
características que el sistema debe poseer, sean requisitos funcionales
o no funcionales. El tratamiento de las historias de usuario es muy
dinámico y flexible. Cada historia de usuario es lo suficientemente
comprensible y delimitada para que los programadores puedan
implementarla en unas semanas” (Letelier, 2006, p. 237)

47
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

• Roles XP
“Los roles de acuerdo con la propuesta original de Beck son:

o Programador. El programador escribe las pruebas unitarias y produce el

código del sistema.

o Cliente. Escribe las historias de usuario y las pruebas funcionales para

validar su implementación. Además, asigna la prioridad a las historias de
usuario y decide cuáles se implementan en cada iteración centrándose
en aportar mayor valor al negocio.

o Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas

funcionales. Ejecuta las pruebas regularmente, difunde los resultados en
el equipo y es responsable de las herramientas de soporte para pruebas.

o Encargado de seguimiento (Tracker). Proporciona realimentación al

equipo. Verifica el grado de acierto entre las estimaciones realizadas y el
tiempo real dedicado, para mejorar futuras estimaciones. Realiza el
seguimiento del progreso de cada iteración.

o Entrenador (Coach). Es responsable del proceso global. debe proveer

guías al equipo de forma que se apliquen las prácticas XP y se siga el
proceso correctamente.

o Consultor. Es un miembro externo del equipo con un conocimiento

específico en algún tema necesario para el proyecto, en el que puedan
surgir problemas.

o Gestor (Big boss). Es el vínculo entre clientes y programadores, ayuda a

que el equipo trabaje efectivamente” (Letelier, 2006, p. 239)

• Proceso XP
“El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes
pasos:

o El cliente define el valor de negocio a implementar.

48
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

o El programador estima el esfuerzo necesario para su

implementación.

o El cliente selecciona qué construir, de acuerdo con sus

prioridades y las restricciones de tiempo.

o El programador construye ese valor de negocio.

o Vuelve al paso 1

En todas las iteraciones de este ciclo tanto el cliente como el

programador aprenden. No se debe presionar al programador a realizar
más trabajo que el estimado, ya que se perderá calidad en el software o
no se cumplirán los plazos. De la misma forma el cliente tiene la
obligación de manejar el ámbito de entrega del producto, para asegurarse
que el sistema tenga el mayor valor de negocio posible con cada
iteración. Él ciclo de vida ideal de XP consiste de seis fases: Exploración,
Planificación de la entrega (Reléase), Iteraciones, Producción,
Mantenimiento y Muerte del Proyecto” (Letelier, 2006, p. 240)

Metodología SCRUM
“Scrum es una metodología ágil de gestión de proyectos cuyo objetivo
primordial es elevar al máximo la productividad de un equipo. Reduce al
máximo la burocracia y actividades no orientadas a producir software que
funcione y produce resultados en periodos muy breves de tiempo. Como
método, Scrum enfatiza valores y prácticas de gestión, sin pronunciarse
sobre requerimientos, prácticas de desarrollo, implementación y demás
cuestiones técnicas. Más bien delega completamente en el equipo la
responsabilidad de decidir la mejor manera de trabajar para ser lo más
productivos posibles .
Se utiliza un proceso ágil iterativo e incremental que respeta las cinco
etapas tradicionales de un proyecto que facilitan su gestión y control;
ellas son: planificación, análisis, diseño, construcción y prueba, e
implementación. Cómo el objetivo final de la metodología es llegar al éxito
del proyecto se definen, en forma clara, los entregables de cada etapa y

49
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

el alcance global, reflejando estos puntos en la planificación de todas las

tareas involucradas.”(Citon, 2006, p. 316)

Scrum se basa en principios agiles: “

• Privilegiar el valor de la gente sobre el valor de los procesos.
• Entregar software funcional lo más pronto posible.
• Predisposición y respuesta al cambio.
• Fortalecer la comunicación y la colaboración.
• Comunicación verbal directa entre los implicados en el proyecto.
• Simplicidad; supresión de artefactos innecesarios en la gestión del
proyecto” 22.
Figura 011
Fuente: Citon, 2006

Flujo de Scrum

Elementos:

• Roles:
o “La dimensión del equipo total de Scrum no debería ser superior a veinte
personas. Si hay más, lo más recomendable es formar varios equipos.
Scrum tiene una estructura muy simple. Todas las responsabilidades del
proyecto se reparten en 3 roles.

o Product owner (Dueño del producto): Representa a todos los interesados

en el producto final. Es el responsable oficial del proyecto, gestión, control
y visibilidad de la lista de acumulación o lista de retraso del producto

50
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

(Product Backlog). Toma las decisiones finales de las tareas asignadas

al registro y convierte sus elementos en rasgos a desarrollar.

o Scrum Master (Líder del proyecto): Responsable del proceso Scrum, de

cumplir la meta y resolver los problemas. Así como también, de
asegurarse que el proyecto se lleve a cabo de acuerdo con las prácticas,
valores y reglas de Scrum y que progrese según lo previsto.

o Team (Equipo): Responsable de transformar el Backlog de la iteración

en un incremento de la funcionalidad del software. Tiene autoridad para
reorganizarse y definir las acciones necesarias o sugerir remoción de
impedimentos.” (Citon, 2006, p. 317)

• Poda de requerimientos:
o “La primera actividad es armar una lista exhaustiva de los requerimientos
originales del sistema. Luego se procede a ver qué requerimientos son
realmente necesarios, cuáles pueden posponerse y cuáles eliminarse.
Para ello debe identificarse un representante con capacidad de decisión,
priorizar los requerimientos en base a su importancia y acordar cuáles
son los prioritarios para la fecha de entrega.” (Citon, 2006, p. 318)

• Product Backlog:
“Con la priorización de los requerimientos y podados podemos proceder
a armar el Backlog de Producto. Este el cual es un modo de organizar
y registrar el trabajo restante para el producto (actividades y
requerimientos).

o es un documento dinámico que incorpora constantemente las

necesidades del sistema. Por lo tanto, nunca llega a ser una lista
completa y definitiva. Se mantiene durante todo el ciclo de vida (hasta la
retirada del sistema) y es responsabilidad del Product Owner.” (Citon,
2006, p. 350)

• Sprint:
o “Un Sprint es el periodo de tiempo durante el que se desarrolla un
incremento de funcionalidad. Constituye el núcleo de Scrum, que divide de

51
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

esta forma el desarrollo de un proyecto en un conjunto de pequeñas

“carreras” .19

Tabla 03: Comparativa de Metodologías

Fuente: Pressman, 2015

Se observó que la metodología recomendada por los expertos, para la
presente investigación es SCRUM, por poseer el mayor porcentaje
promedio en relación con otras metodologías.

Con los resultados de las evaluaciones hechas a través de los juicios de

expertos (ver anexo 03), se obtuvo un cuadro comparativo de las
metodologías de desarrollo de software definido en la Tabla N° 4.

Tabla 04: Comparación de metodologías según expertos

Los Expertos Metodología

RUP XP SCRUM
Cueva Villavicencio Juanita 15 14 16
Villegas Flores Iván 11 11 17
Bello Gómez Luis German 13 12 15
Resultados 39 37 48
Fuente: Elaboracion Propia

52
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Finalmente se puede agregar que la presente metodología elegida es

favorable al investigador, por ser flexible al desarrollo de un sistema en
un plazo corto de tiempo y se puede trabajar de una manera más rápida.

1.4. Formulación Del Problema

Problema General:
¿De qué manera influye el sistema web en la gestión de las incidencias
en la empresa Loo S.A.C.?

Problemas Secundarios:
¿De qué manera influye el sistema web en el en el Porcentaje de
incidencias resueltas dentro del SLA en la gestión de incidencias en la
empresa Loo S.A.C.?

¿De qué manera influye el sistema web en el porcentaje de incidencias

resueltas en la gestión de incidencias en la empresa Loo S.A.C.?

1.5. Justificación Del Estudio

Tecnológica

“Las empresas se enfrentan continuamente al reto de la competencia

global, existe un creciente reconocimiento del papel central de la
tecnología como determinante de su éxito. Como resultado de esto, se
ha acelerado la adopción de nuevas tecnologías y, también, la
introducción de productos tecnológicamente sofisticados. Así, quienes
estén alerta acerca de la necesidad de desarrollar estrategias
tecnológicas deben tener en cuenta que las mismas deben ser
consistentes y estar integradas en sus estrategias generales de negocio.”
(Ciceri, 2013, p.135)

53
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

La presente investigación brindo una solución tecnológica para la gestión

de incidencias haciendo uso de las tecnologías de información
permitiendo el registro de estas mediante una interfaz web logrando una
mejora en el proceso que se verá reflejada en la rapidez de respuesta
frente a los incidentes presentados.

Económica
La justificación económica se puede observar en la reducción del costo
de llamadas ya que estas ascienden a un promedio de 20 a 40 llamadas
diarias en algunos casos la duración es de aproximadamente más de 5
minuto por llamada de usuario que según un cálculo por el costo actual
de minutos y los 20 días laborables al mes se puede estimar
que es el costo que gasta la organización para que los usuarios puedan
llamar a reportar sus incidencias y preguntar por la atención de estas
cuando los técnicos no acuden a resolver la misma, costo que se reduce
dado que al contar con sistema que nos permita dar seguimiento e
identificar los solicitantes no será necesario llamar innecesariamente ya
que datos como el correo esta presentes a lo largo del registro.

Institucional

Con la presente investigación se vio beneficiada la organización en

general en lo que representa al proceso de gestión de incidencias, ya
que al aplicarse un sistema eficaz de gestión de incidencias sus
incidencias se resolverán de manera rápida y oportuna ,brindando al
usuario el seguimiento de la misma generando un ambiente de
productividad a su vez un mejor desenvolvimiento del proceso que se
verá revelado en el ahorro de tiempo de la resolución de las incidencias
reportadas, así como la calidad del servicio prestada a los usuarios
internos ya que al brindar un servicio eficiente redujo el impacto de las
incidencias en sus operaciones .
Operativa

54
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

“Existe redundancia de operaciones y esfuerzos innecesarios de los

procesos, esto ayudara en la fluidez de las incidencias para que no se
vuelvan a repetir o hacer doble trabajo, la mejora del servicio, en la
percepción y satisfacción de los clientes y usuarios por contar con un
punto único de contacto. Mejora la calidad y capacidad de respuesta a
las peticiones de los clientes y usuarios. Las solicitudes serán enviadas a
la persona correcta y resuelto en menor tiempo”. (Zeguel, 2012, p. 196)

Esta implementación permitió la correcta gestión de las incidencias

desde su creación hasta el seguimiento y cierre de la misma, además de
ser una herramienta de gran apoyo para el proceso permitió la creación
de diversos reportes que son de gran utilidad en el área de sistemas ,de
la misma forma optimizará el tiempo de registro y resolución de
incidencias permitió una mejor asignación de recursos y la disponibilidad
de la información sobre una incidencia cuando sea necesaria, se define
justificación operativa por que el sistema beneficio la gestión de
incidentes por ende a la organización como tal.

1.6. Hipótesis

Hipótesis General:
El sistema web mejora la gestión de incidencias en la empresa Industrias
Loo S.A.C.

Hipótesis Específicas:
• El sistema web incrementa el porcentaje de incidencias resueltas
dentro del SLA en la gestión de incidencias en la empresa Loo
S.A.C.
• El sistema web incrementa el porcentaje de incidencias resueltas
en la gestión de incidencias en la empresa Loo S.A.C.

55
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

1.7. Objetivos
Objetivo General:
Determinar la influencia de un sistema web en la gestión de las
incidencias en la empresa Loo S.A.C

Objetivo Específicos:
• Determinar la influencia de un sistema web en el porcentaje de
incidencias resueltas dentro del SLA en la gestión de incidencias
en la empresa Loo S.A.C.

• Determinar la influencia de un sistema web en el porcentaje de

incidencias resueltas en la gestión de incidencias en la empresa Loo
S.A.C

56
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

CAPÍTULO II

MÉTODO

II. MÉTODO

2.1 Diseño De Investigación

57
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

2.1.1 Tipo de Estudio

“este tipo de estudio, también conocido como activo o dinámico,
corresponde a la asimilación y aplicación de la investigación a
problemas definidos en situaciones y aspectos específicos. La
investigación aplicada está muy relacionada con la
investigación pura, pues de cierta forma, la aplicada depende
de sus hallazgos y aportaciones teóricas.”(Abarza, 2012, p. 245)

En ellos el investigador desea comprobar los efectos de una

intervención específica, en este caso el investigador tiene un
papel activo, pues lleva a cabo una intervención.
En los estudios experimentales el investigador manipula las
condiciones de la investigación. Hernández, Fernández y
Baptista, 2006, p. 260)

La presente investigación fue de naturaleza aplicada –

experimental , debido a que se implementó un sistema web
para la gestión de incidencias con ellos solucionando a
problemática en la empresa industrias Loo S.A.C. , a su vez se
realizó la aplicación de una evaluación previa y posterior a la
implementación de sistema mencionado.

2.1.2 Diseño De Investigación

“EI termino diseño se refiere al plan o estrategia concebida para

obtener la información que se desea. En el enfoque cuantitativo,
el investigador utiliza su o sus diseños para analizar la certeza
de las hipótesis fórmula das en un contexto en particular o para
aportar evidencia respecto de los lineamientos de la
investigación” (Hernández, Fernández y Baptista, 2006, p. 125)

58
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Pre-experimental

“Diseño de un solo grupo cuyo grado de control es mínimo.

Generalmente es útil como un primer acercamiento al problema
de investigación en la realidad“(Hernández, Fernández y
Baptista, 2006, p. 156)

Dentro de una sub categoría de diseño pre-experimental

encontramos el diseño de preprueba-postprueba con un único
grupo, que se define de la siguiente manera:

“A un grupo se Ie aplica una prueba previa al estímulo o

tratamiento experimental, después se Ie administra el
tratamiento y finalmente se le aplica una prueba posterior al
estímulo“(Hernández, Fernández y Baptista, 2006, p. 245)

Diseños de medición de Pre-prueba y Post-prueba

G1->O1-> X -> O2

G1: Grupo experimental: Pre-Test.

O1: Pre-Test

Los resultados obtenidos antes del desarrollo del sistema web

para la gestión de incidencias en la empresa Industrias Loo S.A.C.

X: Experimento

En este caso el desarrollo del sistema web para la gestión de

incidencias en la empresa Industrias Loo S.A.C.

O2: Post-Test

59
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Los resultados obtenidos después del desarrollo del sistema web

para la gestión de incidencias en la empresa Industrias Loo S.A.C.

2.1.3 Método de Investigación

Hipotético deductivo

Es el procedimiento o camino que sigue el investigador para hacer de

su actividad una práctica científica. El método hipotético-deductivo
tiene varios pasos esenciales: observación del fenómeno a estudiar,
creación de una hipótesis para explicar dicho fenómeno, deducción de
consecuencias o proposiciones más elementales que la propia
hipótesis, y verificación o comprobación de la verdad de los
enunciados deducidos comparándolos con la experiencia. Este
método obliga al científico a combinar la reflexión racional o momento
racional (la formación de hipótesis y la deducción) con la observación
de la realidad o momento empírico (la observación y la verificación.
(Hernández, Fernández y Baptista, 2006, p. 65)

Fases:

Planteamiento del problema

Creación de hipótesis

Deducciones de consecuencias de la hipótesis

Contrastación: Refutada o aceptada21

2.2 Variables, Operacionalización

Variable Dependiente: Sistema Web

“Un sistema web se describen como aquellas aplicaciones que los
usuarios pueden hacer uso ingresando a un servidor web por internet
a través del protocolo HTTP (protocolo de transferencia de hipertexto)

60
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

utilizando un navegador web tales como Internet Explorer de Microsoft,

Google Crome, etc.” (Berzal, 2005, p. 315)

Variable Independiente: Gestión de Incidentes

“El libro de buenas prácticas ITIL V3 describe que la gestión de incidentes
tiene como objetivo resolver, de la manera más rápida y eficaz posible,
cualquier incidente que cause una interrupción en el servicio”
(Klosterboer, 2008, p. 129)
Operacionalización de variables
Tabla 05: Tabla de Operacionalización de variables
VARIABLE DIMENSIÓN INDICADOR DESCRIPCIÓN
Porcentaje de Se evaluó el
incidencias porcentaje de
resueltas dentro del incidencias
SLA resueltas dentro del
SLA
Gestión de Resolución y
Porcentaje de Se evaluó la
incidencias diagnostico
incidencias porcentaje de
resueltas incidencias
resueltas

Fuente: Elaboración Propia

2.3 Población Y Muestra

La población y muestra para la presente investigación esta se describe

de la siguiente forma:
Población

61
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

“La población es un conjunto de elementos que poseen una

característica. En el proceso investigativo la población corresponde al
conjunto de referencia sobre el cual se va a desarrollar la investigación o
estudio, se entiende por población al conjunto finito o infinito de
elementos con características comunes, para los cuales serán extensivas
las conclusiones de la investigación. Esta queda limitada por el problema
y por los objetivos del estudio“(De la Puente, 1995, p. 59)

Entonces la población será de 20 Fichas de registro de incidencias

Para el indicador Porcentaje de incidencias resueltas dentro del SLA, se
tendrá la cantidad total de incidencias resueltas dentro del SLA entre el
total de incidencias resueltas, teniendo de esta forma el resultado en
porcentaje en un periodo de tiempo de 20 días dentro de un mes.
Para el indicador Porcentaje de incidencias resueltas se tendrá la
sumatoria de incidencias resueltas entre el total de incidencias
registradas, obteniendo de esta manera un resultado en el periodo de
20 días dentro de un mes.

Tabla 06: Población 1 y Población 2

Población Tiempo Indicador

20 Fichas de registro 1 Mes Porcentaje de
de incidencias incidencias resueltas
dentro del SLA
20 Fichas de registro 1 Mes Porcentaje de
de incidencias incidencias resueltas
Fuente: Elaboración Propia

En la tabla N°6 se visualiza la población para los indicadores Porcentaje

de incidencias resueltas y Porcentaje de incidencias resueltas dentro del
SLA, y estableciendo que se emplearon 20 fichas de registro en el
transcurso de 1 mes

62
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Muestra
“Se considera como muestra un subconjunto o parte de la población o
universo en el cual se llevó a cabo la investigación” (Evans, 2005, p.152)

“La muestra es un subgrupo de la población de interés (sobre el cual se

recolectaran datos, y que tiene que definirse o delimitarse de antemano
con precisión), este deberá ser representativo de la población.” (Pineda,
1994, p. 112)

”Si la población es menor a cincuenta (50) individuos, la población es

igual a la muestra” (Hernández, Fernández y Baptista, 2006, p. 165)

Según lo descrito al tratarse de poblaciones pequeñas no requieren el

uso de fórmulas para hallar la muestra ya que esta es equivalente a la
población mencionada.
Por consiguiente nuestra muestra es la misma cifra que nuestra
población la cual es igual a 20 fichas de registro.
Tanto para el indicador Porcentaje de incidencias resueltas dentro del
SLA y el indicador Porcentaje de incidencias resueltas.

2.4 Técnica e Instrumentos de recolección de Datos, Validez

Y Confiabilidad

Técnica

“La técnica se entiende como el conjunto de reglas y procedimientos que

le permiten al investigador establecer la relación con el objeto o sujeto de
la investigación.”(Pineda, 1994, p. 114)

Fichaje:
“El fichaje es una técnica auxiliar de todas las demás técnicas empleadas
en la investigación científica, consiste en registrar los datos que se van
obteniendo de los instrumentos llamados fichas, las cuales debidamente
elaboradas y ordenadas contienen la mayor parte de la información que

63
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

se recopila en una investigación por lo cual constituye un valioso

instrumento auxiliar en esta tarea.” (Huamán, 2005, p. 265)

En la presente investigación según lo expuesto se hizo uso de la técnica

del fichaje.

Instrumento

“El instrumento es el mecanismo que utiliza el investigador para

recolectar y registrar la información: Entre estos se encuentran los
formularios, las pruebas psicológicas, las escalas de opinión y de
actitudes, las listas u hojas de control, entre otros” (Pineda, 1994, p. 121)

Fichas de registro
“Las fichas de registro son instrumentos de la investigación documental
que permiten registrar los datos significativos de las fuentes consultadas.
Las fichas de registro orientan el sentido de la búsqueda, favorecen la
anotación de los hechos observados y, posteriormente, facilitarán la labor
del analista” (Huamán, 2005, p. 274)

En el presente trabajo de investigación se utilizó el instrumento de

recolección de datos denominado Fichas de registro dado que las
incidencias diarias se registran en fichas haciendo esto posible el uso de
este instrumento en el presento trabajo.

Validez

“La validez es el grado en que el instrumento proporciona datos que

reflejen realmente los aspectos que interesan estudiar.” (Pineda, 1994, p.
158)

64
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Juicio de expertos
“El juicio de expertos reside en consultar personas especializadas en el
dominio de los temas de investigación, las cuales apoyaran a medir los
instrumentos para la creación de una prueba y así verificar su validez”.
(De la Puente, 1995, p. 178)
Tabla 07: Resultado de los expertos –Instrumento para indicador Porcentaje
de incidencias resueltas dentro del SLA
Experto Resultado Promedio de
Valoración
Mg. Villegas Flores , Iván Excelente 80
Mg. Bello Gómez, Luis Excelente 83
Mg. Cueva Villavicencio, Excelente 80
Juanita
Resultados de los Excelente 81
expertos
Fuente: Elaboración Propia

La tabla N7° nos muestra la evaluación de expertos con respecto al

instrumento de medición del indicador Porcentaje de incidencias
resueltas dentro del SLA (ver anexo Nº 4) el promedio de evaluación
está por encima del 80% la cual nos muestra de acuerdo a nuestra tabla
de expertos que es excelente.

Tabla 08: Resultado de los expertos –Instrumento para indicador Porcentaje

de incidencias resueltas
Experto Resultado Promedio de
Valoración
Mg. Villegas Flores , Iván Excelente 90
Mg. Bello Gómez, Luis Excelente 83
Mg. Cueva Villavicencio, Excelente 88
Juanita

65
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Resultados de los Excelente 87

expertos
Fuente: Elaboración Propia

La tabla N8° nos muestra la evaluación de expertos con respecto al

instrumento de medición del indicador Porcentaje de incidencias
resueltas (ver anexo Nº 5) el promedio de evaluación está por encima
del 80% la cual nos muestra de acuerdo a nuestra tabla de expertos que
es excelente.

Tabla 09: Puntuación y Significado

Puntuación Significado
0-20% Deficiente
21-50 % Regular
51-70% Bueno
71-80 % Muy bueno
81-100 % Excelente
Fuente: Elaboración Propia

Confiabilidad

“La confiabilidad de un instrumento de medición se refiere al grado en

que su aplicación repetida al mismo sujeto u objeto produce resultados
iguales. Existen diversos procedimientos para calcular la confiabilidad de
un instrumento de medición. Todos utilizan fórmulas que producen
coeficientes de confiabilidad La mayoría de estos coeficientes pueden
oscilar entre cero y uno, donde un coeficiente de cera significa nula
confiabilidad y uno representa un máximo de confiabilidad (confiabilidad
total). Cuanto más se acerque el coeficiente a cero (0), mayor error habrá
en la medición.
Los procedimientos más utilizados para determinar la confiabilidad
mediante un coeficiente son:

• Medidas de estabilidad (confiabilidad por test-retest). En este

procedimiento un mismo instrumento de medición (ítems o indicadores)

66
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

es aplicado dos o más veces a un mismo grupo de personas, después

de un periodo de tiempo. Si la correlación entre los resultados de las
diferentes aplicaciones es altamente positiva, el instrumento se
considera confiable”. (Baez, 2007, p. 215)

• Para medir el nivel de confiabilidad del Porcentaje de incidencias

resueltas dentro del SLA, se utilizó el Test y Retest (Ver Anexo N° 6 y 8),
llenado en los meses de Octubre y Noviembre del 2016, obteniendo
una correlación positiva muy alta.

Figura 12
Fuente: Elaboración propia

Resultados de Test-Retest para el indicador: porcentaje de

incidencias resueltas dentro del SLA

• Para medir el nivel de confiabilidad del Porcentaje de incidencias

resueltas, se utilizó el Test y Retest (Ver Anexo N° 7 y 9), llenado en los
meses de Octubre y Noviembre del 2016, obteniendo una correlación
positiva muy alta.

67
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Fuente: Elaboración propia Figura 13

Resultados de Test-Retest para el indicador: porcentaje de

incidencias resueltas

2.5 Métodos De Análisis De Datos

Método de Análisis de Datos

“El análisis de datos es la manipulación de hechos y números para lograr ciertas

informantes en una técnica que ayudara al administrador a tomar una decisión
apropiada. La idea principal de cualquier estudio es, lograr cierta información
valida y confiable.”(Naghi, 2005, p. 254)

La presente investigación utilizó el método de análisis de datos cuantitativo debido

a que es pre-experimental se obtendrán resultados estadísticos que ayudan
corroborando si la hipótesis es verdadera.

La presente investigación tuvo como objetivo la comparación de los actuales

resultados (Pre-Test) con los resultados obtenidos posterior a la implementación
del sistema web (Post Test).

Prueba de Hipótesis

Hipótesis de Investigación 1

H1: El sistema web incrementa el Porcentaje de incidencias resueltas dentro del

SLA para el proceso de gestión de incidencias en la empresa Loo S.A.C.

Indicador: Porcentaje de incidencias resueltas dentro del SLA

68
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Hipótesis Estadísticas

Dónde:

NEa: Porcentaje de incidencias resueltas dentro del SLA previo al uso del
sistema web

NEd: Porcentaje de incidencias resueltas dentro del SLA posterior al uso del
sistema web

Hipótesis H10: El sistema web no incrementa el Porcentaje de incidencias

resueltas dentro del SLA para el proceso de gestión de incidencias en la
empresa Loo S.A.C.

H10: NEd - NEa < =0

Hipótesis H1a: El sistema web incrementa el Porcentaje de incidencias resueltas

dentro del SLA para el proceso de gestión de incidencias en la empresa Loo
S.A.C.

H1a: NEd - NEa > 0

Hipótesis de Investigación 2

H2: El sistema web incrementa el porcentaje de incidencias resueltas en la

empresa Loo S.A.C.

Indicador: porcentaje de incidencias resueltas

Hipótesis Estadísticas

Dónde:

NSa: porcentaje de incidencias resueltas previo al uso del sistema web

NSd: porcentaje de incidencias resueltas posterior al uso el sistema web

69
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Hipótesis H20: El sistema web no incrementa el porcentaje de incidencias

resueltas en la empresa Loo S.A.C.

H20: NSd - NSa < =0

Hipótesis H2a: El sistema web incrementa el porcentaje de incidencias resueltas

en la empresa Loo S.A.C.

H2a: NSd - NSa > 0

Nivel de Significancia y Nivel de Confianza

Nivel de Significancia

“Es un valor de certeza que fija el investigador a priori, en cuanto a no

equivocarse, antes de probar hipótesis inferenciales.”(Ortiz, 2005, p. 346)

Nivel de significancia (α):0.05

Estadístico de prueba

“Para el presente trabajo de investigación hizo uso el análisis paramétrico llamado

“prueba T” debido a que la muestra es menor a 30.

La prueba T es una prueba estadística para evaluar si dos grupos difieren entre sí
de manera significativa respecto a sus medias

Esta distribución es identificada, los cuales constituyen el diferente

Número de veces como datos que pueden variar. Son determinantes, ya que
indican qué valor se debe esperar de “t” dependiendo del tamaño de los grupos que
se hagan la comparan. Entre mayor número de grados de libertad se tengan, la
distribución “t” de Student se acerca más a ser una distribución normal y,
usualmente, si los grados de libertad exceden los 120, la distribución normal se

70
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

utilizada como una gran aproximación adecuada dentro la distribución T de

Student.” (Naghi, 2005, p. 289)

Figura 14

Fuente: Hernández ,2010

Fórmula de T Student

Región De Rechazo

“La región de rechazo puede considerarse como el conjunto de valores de la

estadística de prueba que no tienen posibilidad de presentarse si la hipótesis nula
es verdadera. Por otro lado, estos valores no son tan improbables de presentarse
si la hipótesis nula es falsa. El valor crítico separa la región de no rechazo de la
de rechazo.” (Naghi, 2005, p. 295)

Figura 15
Fuente: Martin y De Paz ,2007

La fórmula del promedio

71
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

La fórmula del promedio de los resultados de la prueba de hipótesis del sistema

Fuente: Martin y De Paz ,2007

Figura 16

Fórmula de la desviación estándar

Se aprecia la fórmula de la desviación estándar de la fórmula matemática donde

se medirá la muestra y media de la desviación

2.6 Aspectos Éticos

La presente investigación se está realizando en la empresa Industrias

LOO S.A.C, para el cual se cuenta con la autorización de la Gerente
General que nos brinda las facilidades en cuanto a la información,
obtenida durante el tiempo de esta investigación, para poder realizar el
pre-test se tomó el tiempo de un mes verificado de lunes a viernes para
poder contabilizar las incidencias y aplicarlo en las fichas, asimismo, la
información es utilizada para fines académicos de la presente
investigación, por lo cual, el investigador se compromete a salvaguardar
la información que tiene en su poder, teniendo como objetivo generar un
proyecto que automatice su proceso.

72
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

CAPÍTULO III

RESULTADOS

73
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

III. RESULTADOS
Análisis Descriptivo

En la investigación se hizo uso de un sistema web con el fin de calcular el

porcentaje de incidencias resueltas dentro SLA y porcentaje de incidencias
resueltas, para lo cual se aplicó un análisis Pre test que facilite comprender las
condiciones originales para cada indicadores. Los resultados de naturaleza
descriptiva de las medias se encuentran en las siguientes tablas N° 10 y N° 11.

Indicador: Porcentaje de incidencias resueltas dentro del SLA (PRSLA)

Los resultados descriptivos del indicador (PRSLA), se encuentra en la Tabla N°

10.

Tabla 10 : Medidas descriptivas del Pre-test y Post – test del indicador

Porcentaje de incidencias resueltas dentro del SLA

Fuente: Elaboración Propia

En el caso del indicador (PRSLA), en el pre test se alcanzó un valor de 46,82%, en

tanto que en el post test conseguimos un valor de 92,56% (Ver Figura 17) en la
imagen nos muestra que existe una diferencia notable previo y posterior a la
implementación del sistema web.

74
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 17

Fuente: Elaboración propia

Comparativa del Porcentaje de incidencias resueltas dentro del SLA.

Tal como se puede evidenciar en la figura 17 existe una notable diferencia previa
y posterior a la implementación del sistema web para la gestión de incidencias.

Indicador: Porcentaje de incidencias resueltas (PIR)

Los resultados descriptivos del indicador (PIR), se encuentra en la Tabla N° 11

Tabla 11: Medidas descriptivas del Pre-test y Post – test del indicador
Porcentaje de incidencias resueltas

Fuente: Elaboración Propia

75
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

En el caso del indicador (PIR), en el pre test se alcanzó un valor de 63,17%, en

tanto que en el post test se consiguió el valor de 96,77% (Ver Figura 18) en la
imagen nos muestra que hay una notable diferencia previo y posterior a la
implementación del sistema web.

Figura 18
Fuente: Elaboración propia

Comparativa del Porcentaje de incidencias resueltas

Tal como se puede evidenciar en la figura 18 existe una notable diferencia previa y
posterior a la implementación del sistema web para la gestión de incidencias.

Análisis Inferencial

Prueba de Normalidad

Se llevó a cabo el test de normalidad para el indicador Porcentaje de Incidencias

resueltas dentro del SLA (PRSLA) a través del método denominado Shapiro –
Wilk, dado que el tamaño de la muestra empleada es inferior a 50. Así también se
utilizó el mismo método para el indicador Porcentaje de Incidencias resueltas
(PIR) ya que esta tiene la misma cantidad de muestra que el indicador anterior,
dicha prueba se realizó a través del software de naturaleza estadística SSPSS
23.0, para un nivel de confiabilidad del 95 %, con las siguientes condiciones:

Si:

76
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Sig. < 0.05 adopta una distribución no normal.

Sig. > 0.05 adopta una distribución normal.

Donde:

Sig. : p- Valor o nivel crítico del contraste

Los resultados obtenidos fueron los siguientes:

Indicador: Porcentaje de Incidencias resueltas dentro del SLA (PRSLA)

Con la intención de identificar la prueba de hipótesis, se sometieron los datos a

la comprobación de su distribución, para corroborar si los datos poseen una
distribución normal. En este caso se toma en cuenta los resultados de la prueba
de Shapiro Wilk por ser la muestra menor a 50

H0 =Los datos tienen un comportamiento normal

H1a =Los datos no tienen un comportamiento normal

Tabla 12 : Prueba de normalidad para el Pre test y Post Test del indicador
Porcentaje de incidencias resueltas dentro del SLA (PRSLA)

Fuente: Elaboración Propia

De tal manera como se exhibe en la tabla precedente del indicador (PRSLA), el

valor Sig. Del Pre test y post test es mayor a 0.05, por lo que hace indicar que es
una distribución normal.

77
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Indicador: Porcentaje de Incidencias resueltas (PIR)

Con la intención de identificar la prueba de hipótesis, se sometieron los datos a

la comprobación de su distribución, para corroborar si los datos poseen una
distribución normal. En este caso se toma en cuenta los resultados de la prueba
de Shapiro Wilk por ser la muestra menor a 50

H0 =Los datos tienen un comportamiento normal

H1a =Los datos no tienen un comportamiento normal

Tabla 13: Prueba de normalidad para el Pre test y Post Test del indicador
Porcentaje de incidencias resueltas (PIR)

Fuente: Elaboración Propia

De tal manera como se exhibe en la tabla del indicador (PRSLA), el valor Sig. Del
Pre test y post test es mayor a 0.05, por lo que hace indicar que es una
distribución normal

78
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Estadístico Descriptivo

Indicador (PRSLA)

Figura 19
Fuente: Elaboración propia

Pretest _ Porcentaje de incidencias resueltas dentro del SLA

En la figura 19 se muestra en el indicador Porcentaje de incidencias resueltas

dentro del SLA en el Pre Test, alcanzando una media de 46,83 y una desviación
estándar de 9,8

79
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 20

Fuente: Elaboración propia

Postest _ Porcentaje de incidencias resueltas

En la figura 20 se muestra en el indicador Porcentaje de incidencias resueltas

dentro del SLA en el PostTest, alcanzando una media de 92,57 y una desviación
estándar de 3,0.

Tal como se presentaron los resultados de las figuras anteriores, se puede apreciar
que se halla un incremento en el indicador Porcentaje de incidencias resueltas
dentro del SLA de 46,83 hasta 92,57.

80
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Indicador (PIR)

Figura 21
Fuente: Elaboración propia

Pretest _ Porcentaje de incidencias resueltas

En la figura 21 se muestra en el indicador Porcentaje de incidencias resueltas en el

PretTest, alcanzando una media de 63,17 y una desviación estándar de 8,7.

81
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 22

Fuente: Elaboración propia

PosTest_ Porcentaje de incidencias resueltas

En la figura 22 se muestra en el indicador Porcentaje de incidencias resueltas en el

PostTest, alcanzando una media de 92,37 y una desviación estándar de 2,7.

Tal como se presentaron los resultados de las figuras anteriores, se puede apreciar
que se halla un incremento en el indicador Porcentaje de incidencias resueltas de
63,17 hasta 92,37.

Prueba de Hipótesis

En la prueba de hipótesis tenemos el siguiente escenario de los resultados de

pruebas de normalidad que se realizaron a nuestros indicadores, presentan una
distribución normal, ya que tienen un valor mayor Sig. < 0.05, utilizándose para la
misma prueba T Student.

82
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Definición de variables

Ia = Indicador propuesto medido sin el sistema web

Ip = Indicador propuesto medido con el sistema web

Indicador 1: Porcentaje de incidencias resueltas dentro del SLA

H10: El uso de un sistema web no incrementa en el porcentaje de incidencias

resultas dentro del SLA para la gestión de incidencias en la empresa Industrias
Loo S.A.C.

H10: Ip - Ia <=0

H1a: El uso de un sistema web incrementa en el porcentaje de incidencias

resueltas dentro del SLA para la gestión de incidencias en la empresa Industrias
Loo S.A.C.

H1a: Ip - Ia >0

Para la constatación de la hipótesis se aplicó la prueba T Student Sig. < 0.05).

En las siguientes tablas se muestran los resultados obtenidos de la prueba

Student

Tabla 14: Prueba T-Student para el Porcentaje de incidencias resueltas

dentro del SLA

Fuente: Elaboración Propia

83
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Tal como se exhibe en la tabla N° 14, la cifra T alcanzada es -18.981. Por lo tanto
debemos llevar a cabo el contraste con la cifra que nos ofrece la tabla de T-Student
(para este caso) de acuerdo a su muestra, (Ver Anexo 10). En el caso de este
indicador el grado de libertad como indica la tabla 14 , conforme la tabla T Student
la cifra que será el punto de comparación es: 1.7291 entonces el valor T obtenido
es inferior se encuentra en la región de rechazo como se aprecia En la siguiente
figura , así mismo la significancia bilateral es 0,000 es menor al nivel de
significancia de 0.05 por lo tanto y según lo expuesto se rechaza la hipótesis nula,
se acepta la hipótesis alterna dando como resultado que el sistema web si
incrementa el Porcentaje de incidencias resueltas dentro del SLA.

Figura 23
Fuente: Elaboración propia

Región de rechazo de Porcentaje de incidencias resueltas dentro del SLA.

En el grafico 23 se puede observar la ilustración de la zona de rechazo de la misma

forma evidenciamos que el valor T ofrecido por la tabla se encuentra en la misma
por lo cual se rechaza la hipótesis nula y se acepta la hipótesis alterna

84
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Indicador 2: Porcentaje de incidencias resueltas (PIR)

H10: El uso de un sistema web no incrementa el porcentaje de incidencias

resueltas en la empresa Loo S.A.C.

H10: Ip - Ia <=0

H1a: El uso de un sistema web incrementa el porcentaje de incidencias resueltas

en la empresa Loo S.A.C.

H1a: Ip - Ia >0

Tabla 15: Prueba T- Student para el Porcentaje de incidencias resueltas

Fuente: Elaboración Propia

Tal como se presenta en la tabla N° 15, la cifra T alcanzada es -12,335. Por lo tanto
debemos comparar con la cifra proporcionada por la tabla de T-Student (para este
caso) de acuerdo a su muestra, (Ver Anexo). En el caso de este indicador el grado
de libertad como indica la tabla 15 es de 19 , conforme la tabla la cifra que será
el punto de contraste es: 1.7291 Por lo cual el valor T hallado es inferior se
encuentra en la región de rechazo como se aprecia En la siguiente figura, así
mismo la significancia bilateral es 0,000 es inferior al nivel de significancia de 0.05
por lo tanto y según lo expuesto se rechaza la hipótesis nula, se acepta la hipótesis
alterna dando como resultado que el sistema web si incrementa el Porcentaje de
incidencias resueltas.

85
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 24

Fuente: Elaboración propia

Región de rechazo de Porcentaje de incidencias resueltas

En el grafico 24 se puede observar la ilustración de la zona de rechazo de la misma

forma evidenciamos que el valor T ofrecido por la tabla se encuentra en la misma
por lo cual se rechaza la hipótesis nula y se acepta la hipótesis alterna

86
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

CAPÍTULO IV

DISCUSIÓN

87
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

IV. DISCUSIÓN

De acuerdo a los resultados se halló en la actual investigación se evidencia

una comparativa sobre el porcentaje de incidencias resueltas y el porcentaje
de incidencias resueltas dentro del SLA en la gestión de incidencias para la
empresa Industrias Loo S.A.C.

El porcentaje de incidencias resueltas dentro del SLA, de acuerdo con el Pre-

test, se obtuvo un 46.82 % y mediante la puesta en funcionamiento de un
sistema web se logró incrementar el porcentaje de incidencias resueltas
dentro del SLA a 92.56 %. Los resultados alcanzados señalan que hubo un
crecimiento del 45.74 % en el porcentaje de incidencias resueltas dentro del
SLA en la empresa Industrias Loo S.A.C.

En la realización de la investigación se encontró semejanza en referencia al

antecedente del año 2014 de Arnaldo Añez con la investigación titulada:
“Implementación Sistema web de gestión de incidencias para la empresa
Servicios Fv Venezuela 2014” en donde se menciona como parte del
resultado el indicador: porcentaje de incidencias resueltas en el plazo
acordado en el cual se incrementó en un 70% con el apoyo de un sistema
informático de gestión de incidencias.

En la realización de la investigación se halló semejanza en referencia al

antecedente del año 2013 de Luis Carlos Gamarra con la investigación
titulada: “Implementación de un sistema de gestión de incidencias para la
empresa Creditex S.AC” en donde se menciona como parte del resultado el
indicador: nivel de atención al usuario en el cual se incrementó en un 43 %
con el apoyo de un sistema web para la gestión de incidencias.

Todo ello se fundamenta en que los Sistemas de Información se construyen

para mejorar la Organización y habitan en la estructura de las mismas. La
mejora de la organización receptora de los Sistemas de Información es el
fin último que justifica su puesta en marcha. (De Pablos, 2008, p.526)

El porcentaje de incidencias resueltas, de acuerdo al Pre-test, se obtuvo un

63.17 % y mediante la implementación de un sistema web se logró

88
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

incrementar el porcentaje de incidencias resueltas a 96.77 %. Los resultados

alcanzados señalan que hubo un incremento del 33.6 % en el porcentaje de
incidencias resueltas en la empresa Industrias Loo S.A.C. En la realización
de la investigación se encontró semejanza en referencia al antecedente
del año 2015 de Janett Aracely con la investigación titulada:
“Implementación Del Marco De Trabajo ITIL V.3.0 Para El Proceso De
Gestión De Incidencias En El Área Del Centro De Sistemas De Información
De La Gerencia Regional De Salud Lambayeque” en donde se menciona
como parte del resultado el indicador: porcentaje de incidencias resueltas
en el cual se incrementó en un 40.23 % con el apoyo de un sistema
informático de gestión de incidencias.

En la realización de la investigación se encontró coincidencia con los

resultados del antecedente del año 2014 de Vilma Palli Apaza con la
investigación titulada: “Modelo de gestión de incidencias basada en ITIL para
reducir el tiempo de diagnóstico de incidentes del servicio de soporte técnico
en la universidad Nacional del Altiplano Puno-2014” en donde se menciona
como parte del resultado el indicador: ratio de incidencias resueltas en el
cual se incrementó en un 45.96 % con el apoyo de un modelo basado en
ITIL.

“Por lo expuesto se apoya el siguiente enunciado que afirma que los

sistemas de información efectivos agregan valor a los datos para crear
información útil para la toma de decisiones.” (Laudon y Laudon, 2004, p. 325)

89
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

CAPÍTULO V

CONCLUSIÓN

90
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

V. CONCLUSIÓN

• Se llega a la conclusión que el Sistema Web mejora la gestión de incidencias

en la empresa Industrias Loo S.A.C. Pues permitió el incremento del porcentaje
de incidencias resueltas dentro del SLA y el porcentaje de incidencias resueltas,
lo que permitió alcanzar los objetivos de esta investigación por lo que se
concluye a manera general que un sistema que un sistema web si influye en la
gestión de incidencias en la empresa Industrias Loo S.A.C. , a su vez también
se llega a las siguiente conclusiones :

• El Sistema Web incrementó el porcentaje de incidencias resueltas dentro del

SLA en un 45.74 % Por lo tanto se afirma que el Sistema Web incrementa el
porcentaje de incidencias resueltas dentro del SLA en la empresa Industrias Loo
S.A.C.
• El Sistema Web incrementó porcentaje de incidencias resueltas 33.6 %. Por lo
tanto, se afirma que el Sistema Web el porcentaje de incidencias resueltas en
la empresa Industrias Loo S.A.C.

91
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

CAPÍTULO VI

RECOMENDACIÓN

92
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

VI. RECOMENDACIÓN

Se sugiere plantear posteriores investigaciones o ampliar la ya existente, con

el propósito de mejorar la gestión de incidentes y otros involucrados con este.

Para investigaciones similares se recomienda tomar como indicador e

porcentaje de incidencias resueltas dentro del SLA ya que estas reflejan el
cumplimiento del contrato de nivel servicio entre el área y la organización
dando como resultado la conformidad de los usuarios en referencia al
proceso de gestión de incidencias. De la misma forma se recomienda tomar
en cuenta el indicador porcentaje de incidencias resueltas ya que estas son
una visión más general del trabajo realizado por el personal con respecto a
las incidencias reportadas por los usuarios.

93
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

CAPÍTULO VII

REFERENCIAS

94
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

VII. REFERENCIAS
ABARZA, Francisco. Investigación aplicada vs investigación
pura (básica) [en línea] 01, Julio 2012 [fecha de consulta: 15 de
septiembre 2016].Disponible en:
https://abarza.wordpress.com/2012/07/01/investigacion-aplicada-vs-
investigacion-pura-basica/

AÑEZ, Arnaldo. Implementación Sistema web gestión de incidencias

para la empresa Servicios Fv Venezuela 2014.Tesis de pregrado.
Venezuela: Universidad Nueva Esparta, 2010.
.Disponible en:
http://www.miunespace.une.edu.ve/jspui/bitstream/123456789/1190/1/T
G4678.pdf

BAEZ, Juan. Investigación cualitativa. 2da ed. Madrid: ESIC, 2007. 215
pp.

ISBN: 978-84-7356-599-8

BARAY, Ávila. Introducción a la metodología de la investigación [en

línea].1ª ed. México, 2006[fecha de consulta 20 Octubre 2016].
Disponible en:
https://books.google.com.pe/books?id=r93TK4EykfUC&printsec=frontco
ver#v=onepage&q&f=false

ISBN: 84-690-1999-6

BERZAL, Fernando, CORTIJO, José, CUBERO, Carlos. Desarrollo

profesional de aplicaciones web con ASP. NET. 1ra ed. Argentina: Nexus,
2005. 315 pp.

95
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ISBN 84-609-4245-7.

BIMAL, Raj. Indicators for ICT security incident management [.Tesis de

Maestría. Noruega: University of Science and Technology, 2012.
Disponible en:
https://brage.bibsys.no/xmlui/bitstream/handle/11250/262759/616125_F
ULLTEXT01.pdf?sequence=1&isAllowed=y

CICERI, German. Implementación de nuevas tecnologías en la empresa.

La Opinión AR [en línea].13 de enero de 2013 [Fecha de consulta: 10 de
octubre de 2017]. Disponible en:

http://thinkconsulting.com.ar/blog/implementacion-de-nuevas-
tecnologias-en-la-empresa/

CITON, M. Método Ágil Scrum aplicado al desarrollo de un software de

trazabilidad. Argentina: Tesis de pregrado. Universidad de Mendoza,
2006. Disponible en:
http://www.um.edu.ar/catedras/claroline/backends/download.php?url=L0
1ldG9kb3NfQWdpbGVzL01ldG9kb19BZ2lsX1NjcnVtLnBkZg%3D%3D&
cidReset=true&cidReq=II0162004

DE LA PUENTE, Carlos. SPSS/PC+: una guía para la investigación.1ª

ed. Madrid: Complutense, 1995.59 pp.

ISBN: 84-7491-432-9

DE PABLO HEREDERO, Carmen et al. Informática y Comunicaciones en

la empresa.1ra ed. Madrid: Esic, 2004. 287 pp.

ISBN 84-7356-375-1.

96
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

DIRECCIÓN y gestión de los sistemas de información en la empresa por

Carmen de Pablos H. [et al.].Madrid: Esic, 2008. 526 pp.

ISBN 84-7356-445-6

EVANS, Michael, ROSENTHAL, Jeffrey. Probabilidad y estadística.4tª

ed. Barcelona: Reverte S.A., 2005. 152 pp.

ISBN: 84-291-5034-X

GALINDO, María et al. Escaneando la Informática. 1 ra ed. Barcelona:

UOC ,2013. 203 pp.
ISBN 978-84-9788-110-4.

GAMARRA, Luis. Implementación de un sistema de gestión de

incidencias para la empresa Creditex S.AC. Tesis de pregrado. Lima:
Pontificia Universidad Católica Del Perú, 2013.

Disponible en: http://opac.pucv.cl/pucv_txt/txt-6500/UCD6592_01.pdf

GONZALES, Janett. Implementación Del Marco De Trabajo ITIL V.3.0

Para El Proceso De Gestión De Incidencias En El Área Del Centro De
Sistemas De Información De La Gerencia Regional De Salud
Lambayeque. Tesis de pregrado. Lambayeque: Universidad Católica
Santo Toribio de Mogrovejo, 2015.

Disponible en:
https://cazova.files.wordpress.com/2015/01/tesisv2_frank_ruiz_zavaleta.
pdf

97
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

GOURVENEC, Marc. ServiceAide crea una experiencia completa de

servicios para la gestión de incidencias con Inteligencia Artificial [en
línea].La Vanguardia.31 de octubre del 2017. [Fecha de consulta: 10 de
Noviembre de 2017].

http://www.lavanguardia.com/vida/20171031/432512645565/comunicad
o-serviceaide-crea-una-experiencia-completa-de-servicios-para-la-
gestion-de-incidencias-con-inteligencia-artificial.html

HERNANDEZ, Roberto, FERNANDEZ, Carlos, BAPTISTA, Pilar.

Metodología de la Investigacion.4ta ed. México: McGRAWHILL, 2006.
125 pp.
ISBN 970-10-5753-8

HUAMÁN, Econ. Manual De Técnicas De Investigación Conceptos Y

Aplicaciones [en línea].2da ed. Perú: IPLADEES, 2005[fecha de consulta
20 Octubre 2016]. Disponible en:
https://books.google.com.pe/books?id=OEHABAAAQBAJ&pg=PA45&lp
g=PA45&dq=#v=onepage&q&f=false

ITIL V3.Operacion del servicio. Londres ,2009. 166 pp.

ISBN 978-011-331150-7.

DESONGLES, Juan. Técnico de soporte Informático ITIL y

Soluciones.2da ed. España: Editorial Mad, 2006. 566 pp.
ISBN 988-031-389990-8.

JUÁREZ, Héctor. Implantación de ITIL en empresa de TI [en línea].

Estados Unidos: Wiley Publishing, Inc., 2015 [fecha de consulta: 15 de
septiembre 2016].Disponible en:
https://www.google.com.pe/url?sa=t&rct=j&q=&esrc=s&source=web&cd

98
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

=1&cad=rja&uact=8&ved=0CBsQFjAAahUKEwiVjK6TpYTJAhXKJCYKH
fBOCXc&url=https%3A%2F%2Fptop.only.wip.la%3A443%2Fhttp%2FImplantacion?+de+ITIL+triola&usg=AFQj
CNHASgHqAZJZiuwDYqDhD1EijDNrgQ&sig2

ISBN: 8466551042.

JIMENEZ MURILLO, K. Roció, Propuesta De metodología y estándares

para la administración de proyectos en las pequeñas y medianas
empresas de software con base en los estándares del PMI. Tesis
doctoral. Costa Rica: Universidad para la Cooperación Internacional,
2012. Disponible en:
http://www.uci.ac.cr/Biblioteca/Tesis/PFGMAP1147.pdf

KORHONEN, Antti. Role-specific Critical Success Factors in Incident

Management. Tesis de Maestría. Finlandia: Universidad Jyväskylä, 2013.
354 pp.
ISBN 973-0-43-815041-9.

KLOSTERBOER, Larry. Implementing ITIL Change and Release

Management.1ra ed. USA: Pearson plc, 2008.129 pp.
ISBN 978-0-13-815041-9.

LANDEAU, Rebeca. Elaboración de trabajos de investigación .1ª ed.

Venezuela: Alfa, 2007. 316 pp.

ISBN: 980-354-214-1

LAUDON, Kenneth y LAUDON, Jane. Sistemas de información gerencial:

administración de la empresa digital. México: Pearson Educación de
México, 2004. 325 pp.

ISBN 970-26-0528-8

99
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

LETELIER, Patricio, Penades, Carmen. Metodologías ágiles para el

desarrollo de software: eXtreme Programming (XP).Técnica
Administrativa [en línea].Barcelona: 2006, abril-junio, 26. [Fecha de
consulta 15 setiembre 2016].

Disponible en:

http://www.cyta.com.ar/ta0502/b_v5n2a1.html

ISSN 1666-1680.

LUJAN, Sergio. Programación en Aplicaciones Web. 1 ra ed. España:

Editorial Club Universitario, 2002. 156 pp.
ISBN 84-8454-206-8.

MAZA, Gina. Análisis, diseño e implementación de un sistema de

Información como soporte a la gestión académica para la escuela
Tecnológica de la universidad nacional de Piura. Tesis de pregrado.
Piura: Universidad Nacional De Piura, 2009. 386 pp.

MORLES, Víctor. Planteamiento y análisis de investigaciones. 5ta ed.

Caracas: El Dorado, 1992. 508 pp.
ISBN 980-6004-73-6

NAGHI, Mohammad. Metodología de la investigación.1ª ed. México:

Limusa, 2005. 254 pp.

ISBN: 968-18-5517-5

ORTIZ, Gisela. Diccionario de metodología de la investigación

cientifica.1ª ed. México: Limusa, 2005. 346 pp.

ISBN: 968-18-6433-6

PALLI, Vilma. Modelo de gestión de incidencias basada en ITIL para

reducir el tiempo de diagnóstico De incidentes del servicio de soporte
técnico en la universidad Nacional del Altiplano Puno-2014.Tesis de

100
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

pregrado. Puno: Universidad Nacional del Altiplano Puno, 2014.

Disponible en: https://es.scribd.com/document/261947667/Modelo-de-
Gestion-de-Incidencias-Basado-en-ITIL-pdf

PINEDA, Elia, DE ALVARADO, Eva, H., Francisca. Metodología de

Investigación. 2da ed. Washington: PALTEX, 1994. 114 pp.

ISBN: 92-75-92135-3

PUCHOL, Luis. El libro de la entrevista de trabajo.5ta ed. España:

Edígrafos, 2010. 341 pp.
ISBN 978-84-7978-960-2

ROMERO, Fernando. Publicar en Internet: guía práctica para la creación

de documentos .1ra ed. HTML. Cantabria: Publicaciones de la
Universidad de Cantabria, 1998. 112 pp.
ISBN 84-8102-179-2

RUIZ, Frank. ITIL V3 Como Soporte En La Mejora Del Proceso De

Gestión De Ias Incidencias En La Mesa De Ayuda De La Sunat Sedes
Lima Y Callao. Tesis de pregrado. Lima: Universidad Peruana De
Integración Global, 2014.

Disponible en:
https://cazova.files.wordpress.com/2015/01/tesisv2_frank_ruiz_zavaleta.
pdf

NOVELO, Sergio. El Mito de La ISO 9000:200.1ra ed. México: Panorama,

2002. 245 pp.

ISBN: 96B-38-1082-9

SOMMEVILLE, Ian. Ingeniería del Software.7ma ed. Madrid: Pearson,

2005. 254 pp.

101
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ISBN: 84-7829-74-5.

Utilizar el ITIL junto a la norma ISO 27001 para la gestión de incidentes

[Publicación en un blog].España: Madrid, F., (17 noviembre del 2015).
[Fecha de consulta: 15 de Noviembre de 2017]. Recuperado de
http://www.pmg-ssi.com/2015/11/utilizar-el-itil-junto-a-la-norma-iso-
27001-para-la-gestion-de-incidentes/

VAN, Jan.et al. Operación del Servicio Basada en ITIL® V3 - Guía de

Gestión.1ra ed. Holanda: Van Haren, 2008. 129 pp.
ISBN .9789087531522.

VLADIMIROVNA, Olga. Fundamentos de Probabilidad y Estadística.1 ra

ed. México: Mc Graw Hil, 2005. 354 pp.

ISBN 968-835-867-6

ZEGEL, Barbara. Running an effective helpdesk.2da ed. California:

Wiley, 2012. 196 pp.
ISBN 968-422-931-3

102
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

CAPÍTULO VIII

ANEXO

VIII. REFERENCIAS

103
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

IX. ANEXOS
ANEXO NO 01: MATRIZ DE CONSISTENCIA

104
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ANEXO NO 02: ENTREVISTA PARA DETERMINAR LA PROBLEMÁTICA EN

LA EMPRESA INDUSTRIAS LOO S.A.C

105
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

106
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ANEXO NO 03: JUICIO DE EXPERTOS PARA LA ELECCIÓN

DE LA METODOLOGÍA

107
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

108
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

109
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ANEXO NO 04: JUICIO DE EXPERTOS PARA EL INDICADOR PORCENTAJE

DE INCIDENCIAS RESUELTAS DENTRO DEL SLA

110
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

111
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

112
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ANEXO NO 05: JUICIO DE EXPERTOS PARA EL INDICADOR PORCENTAJE

DE INCIDENCIAS RESUELTAS

113
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

114
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

115
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ANEXO NO 06: FICHA DE REGISTRO PRE TEST PARA EL INDICADOR

PORCENTAJE DE INCIDENCIAS RESUELTAS DENTRO DEL SLA

116
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ANEXO NO 07: FICHA DE REGISTRO PRE TEST PARA EL INDICADOR

PORCENTAJE DE INCIDENCIAS RESUELTAS

117
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ANEXO NO 08: FICHA DE REGISTRO RE-TEST PARA EL INDICADOR

PORCENTAJE DE INCIDENCIAS RESUELTAS DENTRO DEL SLA

118
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ANEXO NO 09: FICHA DE REGISTRO RE-TEST PARA EL INDICADOR

PORCENTAJE DE INCIDENCIAS RESUELTAS

119
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ANEXO NO 10: FICHA DE REGISTRO POST TEST PARA EL INDICADOR

PORCENTAJE DE INCIDENCIAS RESUELTAS DENTRO DEL SLA

120
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ANEXO NO 11: FICHA DE REGISTRO POST TEST PARA EL INDICADOR

PORCENTAJE DE INCIDENCIAS RESUELTAS

121
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ANEXO NO 82: Tabla de distribución T Student

122
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ANEXO 13 ACTA DE IMPLEMENTACIÓN DE SISTEMA

123
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ANEXO NO 94: DESARROLLO DE LA METODOLOGÍA PARA EL SISTEMA

WEB PARA LA GESTIÓN DE INCIDENCIA EN LA EMPRESA INDUSTRIAS
LOO S.A.C

ÍNDICE

INTRODUCCIÓN ........................................................................................................ 125

PROPÓSITO DEL DOCUMENTO ........................................................................ 125
ALCANCE ........................................................................................................... 125
DESCRIPCIÓN GENERAL DE LA METODOLOGÍA.................................................. 125
Fundamentación: ............................................................................................... 125
Valores del Trabajo ............................................................................................ 125
PERSONAS Y ROLES DEL PROYECTO .................................................................. 126
ENTREGABLES POR FASE ...................................................................................... 127
DECLARACIÓN DE VISIÓN DEL PROYECTO ................................................... 133
PLAN DE COLABORACIÓN ............................................................................... 134
ÉPICAS................................................................................................................ 135
DESCRIPCIÓN DE USUARIOS INVOLUCRADOS ............................................. 136
Riesgos ............................................................................................................... 137
Criterios de Terminado ...................................................................................... 138
HISTORIAS DE USUARIO .................................................................................. 141
PRODUCT BACKLOG ........................................................................................ 153
PILA DEL SPRINT ............................................................................................... 155
PLANIFICACIÓN DEL PROYECTO – CRONOGRAMA ...................................... 157
EJECUCIÓN DEL PROYECTO .................................................................................. 158
Desarrollo Del Sprint 1 ....................................................................................... 158
Desarrollo Del Sprint 2 ....................................................................................... 207
Desarrollo Del Sprint 3 ....................................................................................... 248
PRESUPUESTO ......................................................................................................... 265

124
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

DESCRIPCIÓN DE LA METODOLOGÍA DE TRABAJO

INTRODUCCIÓN

Este documento describe la implementación de la metodología de trabajo Scrum

en el trabajo de investigación “Sistema web para la gestión de incidencias en la
empresa industrias Loo S.A.C” Incluye junto con la descripción de este ciclo de vida
iterativo e incremental para el proyecto, los artefactos y documentos, así como
define las responsabilidades y compromisos de los participantes en el proyecto.

PROPÓSITO DEL DOCUMENTO

Brindar la información de referencia necesaria a las personas implicadas en el

desarrollo del sistema web para la gestión de incidencias en la empresa industrias
Loo S.A.C.

ALCANCE

Personas y procedimientos implicados en el desarrollo del sistema web de gestión

de incidencias en la empresa industrias Loo S.A.C.

DESCRIPCIÓN GENERAL DE LA METODOLOGÍA

Fundamentación:

Las principales razones por las que se eligió la metodología Scrum son:

-Entregas frecuentes hacen posible la satisfacción del cliente

-Retroalimentación continúa a través de las continuas reuniones para mostrar y

validar los entregables.

-Flexibilidad de cambio, en cada entregable se pueden definir nuevas

funcionalidades o seguir las ya definidas

Valores del Trabajo

125
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Los valores que deben ser adoptados por los miembros que participan en el
desarrollo son:

• Autonomía del equipo

• Respeto en el equipo

• Responsabilidad y auto-disciplina

• Foco en la tarea

• Información transparencia y visibilidad.

PERSONAS Y ROLES DEL PROYECTO

Tabla 16: personas y roles del proyecto

PERSONA ROL

Luis Loo Cho Dueño del producto

Frank Ayala R. Scrum Master

Yordi Gabino Guere Analista Programador

Yordi Gabino Guere Administrador de Base de

datos

Yordi Gabino Guere Pruebas e implementación

Fuente: Elaboración propia

126
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ENTREGABLES POR FASE

INICIO

Project Charter

Declaración de la visión del proyecto

Plan de colaboración

Épicas

Descripción de usuarios involucrados

Riesgos

Criterios de terminado

PLANIFICACIÓN Y ESTIMACIÓN

Historia de usuario

Product Backlog

Pila de Sprint

Planificación del proyecto

IMPLEMENTACIÓN

Acta de inicio por cada fase

Lista de pendientes del Sprint

Planificación del Sprint

Diseño de Base de Datos

Diseño de interfaces

Implementación de los prototipos

Código

127
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Validación del Sprint

Resumen del Sprint

Burndown Chart

Retrospectiva

LANZAMIENTO

Envió de entregables

Acta de cierre por cada fase

128
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

PROJECT CHARTER

129
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

130
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

131
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

132
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

DECLARACIÓN DE VISIÓN DEL PROYECTO

En este cuadro se menciona la necesidad del negocio, los objetivos del proyecto y
en medio en el cual se va a dar solución a la necesidad presentada.

Nombre del proyecto

Sistema web para la gestión de incidencias en la empresa Industrias Loo S.A.C

Acerca del Negocio

Industrias Loo S.A.C dedicada a la fabricación de útiles escolares ubicada en el

distrito de los Olivos, las áreas que constituyen la empresa son las de
administración, logística, contabilidad, RRHH, sistemas y producción.

Necesidad del Negocio

El actual proceso presenta deficiencias que interfieren con la labor que

desempeñan el área de sistema el cual es de apoyo para las principales
operaciones de la organización, dado que se desea contar con información
concisa y mayor control sobre el proceso que ayude a tomar decisiones dentro
del área a fin de mejorar el servicio

Objetivos del Proyecto

• Determinar la influencia de un sistema web en el Porcentaje de incidencias

resueltas dentro del SLA para el proceso de gestión de incidencias en la
empresa Loo S.A.C.
• Determinar la influencia de un sistema web en el porcentaje de incidencias
resueltas para el proceso de gestión en la empresa Loo S.A.C.
Zona de aplicación

El proyecto se aplicara para la empresa Industrias Loo S.A.C y será utilizado por
las personas involucradas en la gestión de incidencias.

Declaración de la visión del proyecto

El proyecto tiene como visión el desarrollo de un sistema que apoye en la

optimización de la gestión de incidencias en la empresa Industrias Loo S.A.C

133
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

PLAN DE COLABORACIÓN
En el siguiente cuadro se describe el plan de colaboración del proyecto que
contiene a las personas que toman decisiones, miembros del equipo que
se apoyan y participan en conjunto.

Tabla 17: Plan de Colaboración

Nombre del proyecto

Sistema web para la gestión de incidencias en la empresa Industrias Loo S.A.C

Personas Involucradas en el proyecto

Analista Programador Yordi Gabino

Administrador de Base de datos Yordi Gabino

Pruebas e implementacion Yordi Gabino

Supervisor de Sistemas Frank Ayala E.

Gerente General Luis Loo Cho

Herramientas que se utilizaran en el proyecto

• Sublime Text
• Atom
• WAMP
• Mysql
• Actas de reunión
• Dropbox

Fuente: Elaboración propia

134
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ÉPICAS

Una épica no es más que un nivel de agrupación por encima de las historias de
usuario que permite clasificar las mismas por funcionalidades, módulos,
subsistemas, etc… Es decir, se tiene en mente una imagen abstracta de lo que se
quiere obtener con la épica (que se desarrollará probablemente en varias
iteraciones), pero son las historias de usuario, su implementación en los sprints y
el feedback los que terminan de darle finalmente la forma.
Tabla 18: Épicas

Nombre del proyecto

Sistema web para la gestión de incidencias en la empresa Industrias Loo S.A.C

Épicas

• Registro de incidencias
• Asignación de incidencias
• Edición de incidencias
• Generación de reportes
• Creación de incidencias
• Aviso de asignación de incidencias
• Cierre de incidencias
• Identificación de incidencias

Fuente: Elaboración propia

135
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

DESCRIPCIÓN DE USUARIOS INVOLUCRADOS

Tabla 19: Descripción De Usuarios Involucrados

Nombre del proyecto

Sistema web para la gestión de incidencias en la empresa Industrias Loo S.A.C

Personas

Gerente General Luis Loo Cho es el gerente de la empresa y vela porque

las operaciones de la empresa se den de manera correcta
, actualmente se muestra inconforme con la gestión de
incidencias debido a que estas afectan a sus empleados y
retrasan sus labores por horas obstruyendo el desempeño
de los mismos

Supervisor de Sistemas Frank Ayala E. es el superviso de sistemas el cual se

encuentra disconforme al no poder elaborar reportes que
le indiquen con mayor exactitud las incidencias realizadas
durante un periodo de tiempo, así mismo no puede
asignar eficientemente al personal encargado de
solucionar los incidentes

Técnico Soporte Leonidas Tapay es el técnico de soporte que presenta

inconvenientes al no poder registrar de manera correcta las
incidencias y no poder darles el correcto seguimiento o
atenderlas a tiempo

Fuente: Elaboración propia

136
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Riesgos
A continuación se muestran los riegos clasificados por tipo

Tabla 20 : Riesgos

Nombre del proyecto

Sistema web para la gestión de incidencias en la empresa Industrias Loo S.A.C

Identificación de Riesgos

Producto Desarrollo incorrecto de las funcionalidades del software

Producto
Complejidad de los usuarios en el uso del software
Producto El sistema no se encuentra disponible cuando se requiere
acceder
Personal con experiencia abandona el proyecto antes de
Proyecto que finalice
Indisponibilidad del hardware, pues este es esencial para
Proyecto el proyecto no será entregado a tiempo
Proyecto Falta de personal calificado
Los miembros del equipo no se implican en el proyecto, y
Proyecto por lo tanto no alcanzan el nivel de rendimiento deseado
Fuente: Elaboración propia

137
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Criterios de Terminado
Los criterios de terminado es un conjunto de reglas que se aplican a todas las
historias de usuarios. A continuación se redacta los criterios de terminado.

Tabla 21: Criterios de Terminado

Nombre del Proyecto

Sistema web para el la gestión de incidencias en la empresa Industrias Loo

S.A.C

Criterios de Terminado

• El diseño del sistema es aprobado por el gerente Angel Loo Choo

• Debe de ser realizado bajo una metodología para darle veracidad.

• El sistema debe restringir el acceso al aplicativo web empleando un usuario y

contraseña

• Cada perfil tiene un nivel de acceso, no puede ingresar a las funcionalidades

de otro perfil

• El navegador a utilizar será Chrome

• El sistema debe pasar por pruebas de testeo

• Al culminar cada Sprint se realizará reuniones con los usuarios

Fuente: Elaboración propia

138
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ACTA DE REUNIÓN SOBRE EL PROJECT CHARTER

139
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ACTA DE REUNIÓN SOBRE LA LISTA PRIORIZADA DE PENDIENTE DEL

PRODUCTO

140
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

HISTORIAS DE USUARIO

Las historias de usuario representan las necesidades del usuario referente a las
funcionalidades del sistema, explicadas de forma sencilla y corta.

Tabla 22: Historia de Usuario HU01 –Acceso al sistema

HISTORIA DE USUARIO

Numero : HU01 Usuario: Supervisor - Técnico

Nombre de Historia: Acceso al sistema

Prioridad en negocio: 1 Riesgo en Desarrollo: Medio

Estimación:5 Sprint Asignado : 1

Desarrollador Responsable : Yordi Gabino

Descripción :

Como usuario debería ingresar al sistema mediante un usuario y clave

Criterios de aceptación :

• El usuario debe ingresar al sistema

• Se debe rechazar los usuarios no registrados indicando que no se
correcto su Login

Fuente: Elaboración propia

141
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Tabla 23: Historia de Usuario HU02 –Mantenimiento de Personal

HISTORIA DE USUARIO

Numero : HU02 Usuario: Coordinador

Nombre de Historia: Mantenimiento de personal

Prioridad en negocio: 2 Riesgo en Desarrollo: Medio

Estimación:5 Sprint Asignado : 1

Desarrollador Responsable : Yordi Gabino

Descripción :

Como Coordinador debería consultar, registrar, modificar y dar de baja los

datos del personal con la finalidad de administrar la información de los mismos.

Criterios de aceptación :

• Lista personal registrado

• Registra personal
• Valida los campos de entrada
• Búsqueda de personal
• Edición de personal
• Eliminación de personal

Fuente: Elaboración propia

142
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Tabla 24: Historia de Usuario HU03 - Mantenimiento de Usuarios

HISTORIA DE USUARIO

Numero: HU03 Usuario: Coordinador

Nombre de Historia: Mantenimiento de Usuarios

Prioridad en negocio: 2 Riesgo en Desarrollo: Medio

Estimación:3 Sprint Asignado : 1

Desarrollador Responsable : Yordi Gabino

Descripción :

Como Coordinador debería consultar, registrar, modificar y dar de baja los

datos de los usuarios, con la finalidad de mantener a salvo la seguridad del
sistema.

Criterios de aceptación :

• Lista usuarios registrados

• Registra usuarios
• Valida los campos de entrada
• Edición de usuarios
• Eliminación de usuarios

Fuente: Elaboración propia

143
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Tabla 25: Historia de Usuario HU04 - Mantenimiento de Prioridades

HISTORIA DE USUARIO

Numero : HU04 Usuario: Coordinador

Nombre de Historia: Mantenimiento de Prioridades

Prioridad en negocio: 3 Riesgo en Desarrollo: Medio

Estimación:5 Sprint Asignado : 1

Desarrollador Responsable : Yordi Gabino

Descripción :

Como supervisor, debería listar, registrar, modificar y eliminar los datos de las
prioridades, con la finalidad de mantener actualizadas las prioridades las cuales
juegan un papel importante en la resolución de una incidencia.

Criterios de aceptación :

• Lista prioridades registrado

• Registra prioridades
• Valida los campos de entrada
• Edición de prioridades
• Eliminación de prioridades

Fuente: Elaboración propia

144
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Tabla 26: Historia de Usuario HU05 - Mantenimiento de Categorías

HISTORIA DE USUARIO

Numero : HU05 Usuario: Coordinador

Nombre de Historia: Mantenimiento de Categorías

Prioridad en negocio: 3 Riesgo en Desarrollo: Medio

Estimación:5 Sprint Asignado : 2

Desarrollador Responsable : Yordi Gabino

Descripción :

Como supervisor, debería listar, registrar, modificar y eliminar los datos de las
categorías con el fin de mantener un registro eficaz de la incidencia.

Criterios de aceptación :

• Lista categorías registradas

• Registra categorías
• Valida los campos de entrada
• Edición de categorías
• Eliminación de categorías

Fuente: Elaboración propia

145
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Tabla 27: Historia de Usuario HU06 - Mantenimiento de incidencias

HISTORIA DE USUARIO

Numero : HU06 Usuario: Coordinador -Técnico

Nombre de Historia: Mantenimiento de incidencias

Prioridad en negocio: 4 Riesgo en Desarrollo: Muy Alto

Estimación:5 Sprint Asignado : 2

Desarrollador Responsable : Yordi Gabino

Descripción :

• Como Coordinador debería registrar incidencias, y seleccionar un técnico

asignado a dicha incidencia, visualizarlas de acuerdo a fechas, así mismo la
edición y filtrado de las mismas por número, prioridad, técnico asignado, estado y
fecha, así mismo poder reasignar una incidencia .
• Como técnico solo se necesita poder visualizar las incidencias asignadas al
mismo
Criterios de aceptación :

• Lista incidencias registradas por fecha

• Registra incidencias
• Valida los campos de entrada
• Edición de incidencias abiertas
• Asignación de técnico
• Filtrado de incidencias por estado
• Inserción de imagen en el registro
• Lista técnicos con número de incidencias asignadas
• Lista prioridades con tiempo de atención
• Lista incidencias asignadas al técnico

Fuente: Elaboración propia

146
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Tabla 28: Historia de Usuario HU07 - Cierre de incidencia

historia DE USUARIO

Numero : HU07 Usuario: Supervisor-Técnico

Nombre de Historia: Cierre de incidencia

Prioridad en negocio: 4 Riesgo en Desarrollo: Muy Alta

Estimación: 4 Sprint Asignado : 2

Desarrollador Responsable : Yordi Gabino

Descripción :

• Como técnico debería cerrar las incidencias asignadas dando una solución y
editando los campos de categorías y subcategorías
• Como técnico debería listar las incidencias que haya cerrado
• Como Coordinador debería cerrar las incidencias escaladas a mi nivel dando una
solución y editando los campos de categorías y subcategorías
Criterios de aceptación :

• Visualización de incidencias
• Cierre de incidencias
• Escalado de incidencia
• Inserción de imagen de cierre
• Inserción de descripción de la solución

Fuente: Elaboración propia

147
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Tabla 29: Historia de Usuario HU08 - Escalado de Incidencias

HISTORIA DE USUARIO

Numero HU08 Usuario: Coordinador –Técnico

Nombre de Historia: Escalado de Incidencias

Prioridad en negocio: 5 Riesgo en Desarrollo: Alto

Estimación:6 Sprint Asignado : 2

Desarrollador Responsable : Yordi Gabino

Descripción :

Como técnico debería escalar las incidencias que no pueda resolver para ellos
contare con una función que me permita hacerlo.

Como Coordinador debo poder ver las incidencias que los técnicos me han
escalado y poder cerrarlas.

Criterios de aceptación :

• Escalado de incidencias al Coordinador que la registro

• Cambia estado de incidencia a escalado
• Asigna incidencia a Coordinador que la registro

Fuente: Elaboración propia

148
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Tabla 30: Historia de Usuario HU09 - Notificación

HISTORIA DE USUARIO

Numero : HU09 Usuario: Técnico-Personal

Nombre de Historia: Notificación

Prioridad en negocio: 5 Riesgo en Desarrollo: Muy Alto

Estimación:5 Sprint Asignado : 3

Desarrollador Responsable : Yordi Gabino

Descripción :

• Como empleado es necesario la emisión de una notificación con el

número de ticket asignado con el fin de mantener al usuario informado
sobre quien resolverá la incidencia.
• De igual manera cuando se reasigne una incidencia para mantener
actualizada la información con respecto al técnico asignado
• De la misma forma cuando el ticket sea escalado se deberá enviar una
notificación
• Así mismo durante el cierre es necesaria la recepción de un correo con
el fin de informarnos si nuestra incidencia fue cerrada y un link de
conformidad.
• Como técnico se necesita una notificación por correo cuando la
incidencia se me asigne, cuando cierre una incidencia
• Como Coordinador se deberá recepcionar un correo cuando se le
escale una incidencia y cuando esta sea cerrada
Criterios de aceptación :

• Envió de correo al solicitante y al técnico asignado

• Envió de correo al escalar la incidencia al solicitante y al Coordinador
• Envió de correo al cierre de la incidencia al solicitante y al técnico
asignado
• Envió de fórmula rio de conformidad

Fuente: Elaboración propia

149
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Tabla 31: Historia de Usuario HU10 - Registro de conformidad

HISTORIA DE USUARIO

Numero : HU10 Usuario: Supervisor-Técnico

Nombre de Historia: Registro de conformidad

Prioridad en negocio: 6 Riesgo en Desarrollo: Alto

Estimación:6 Sprint Asignado : 3

Desarrollador Responsable : Yordi Gabino

Descripción :

El sistema debe enviar una encuesta de conformidad al usuario que reporto el

incidente de esta forma poder reabrir el ticket en caso la conformidad sea
negativa

Criterios de aceptación :

• Listar conformidades
• Registro de conformidades de los solicitantes

Fuente: Elaboración propia

150
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Tabla 32: Historia de Usuario HU11 - Reportes

HISTORIA DE USUARIO

Numero : HU11 Usuario: Supervisor

Nombre de Historia: Reportes

Prioridad en negocio: 6 Riesgo en Desarrollo: Muy Alto

Estimación:12 Sprint Asignado :3

Desarrollador Responsable : Yordi Gabino

Descripción :

Como Coordinador se necesita la emisión de reportes de incidencias por área,

técnico ,estado ,prioridad, escaladas por área, escaladas por prioridad,
escaladas por estado, reporte del personal registrado, reportes de porcentaje de
incidencias resueltas, porcentaje de las incidencias resueltas dentro del SLA

Criterios de aceptación :

• Reportes por periodos de tiempo

• Reportes por técnico
• Reportes por estado
• Reportes por áreas
• Reportes por solicitante
• Reportes de personal registrado

Fuente: Elaboración propia

151
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

ACTA DE REUNIÓN SOBRE LAS HISTORIAS DE USUARIO

152
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

PRODUCT BACKLOG

Responsabilidades

Producto Owner

• Participar en la reunión de planificación de iteración, proponiendo los

requisitos más prioritarios a desarrollar, respondiendo a las dudas del
equipo y detallando los requisitos que el equipo se comprometer a hacer.
• Estar disponible durante el curso de la iteración para responder a las
preguntas que puedan aparecer.
• No cambiar los requisitos que se están desarrollando en una iteración, una
vez está iniciada.
• Participar en la reunión de demostración de la iteración, revisando los
requisitos completados.

Scrum Master

• Supervisión de la pila de producto, y comunicación con el Product Owner

para pedirle aclaración de las dudas que pueda tener, o asesorarle para la
subsanación de las deficiencias que observe.

Equipo Técnico

• Conocimiento y comprensión actualizada de la pila del producto.

• Resolución de dudas o comunicación de sugerencias con el Scrum
Manager.

153
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Tabla 33: Product Backlog

Nombre de Estimación Estimación

COD Iteración Prioridad
historia Aprox. Real

Acceso al 1 4
HU01 5 1
sistema

Mantenimiento 1 4
HU02 5 2
de Personal

Mantenimiento 1 4
HU03 3 2
de usuarios

Mantenimiento 1 4
HU04 5 3
de prioridades

Mantenimiento 2 4
HU05 5 3
de categorías

Mantenimiento 2 6
HU06 5 4
de incidencias

Cierre de 2 3
HU07 4 4
Incidencia

Escalado de 2 3
HU08 6 5
incidencias

HU09 Notificación 3 5 4 5

Registro de 3 4
HU10 6 6
Conformidad

HU11 Reportes 3 12 10 6

Fuente: Elaboración propia

154
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

PILA DEL SPRINT

Es el documento de registro de los requisitos detallados que va a desarrollar el

equipo técnico en la iteración

Desde la tabla 34 hasta la tabla 36 se detalla el número de sprints con sus

respectivas historias, prioridades y tiempos estimados.

PILA DEL SPRINT 1

Tabla 34: Pila Del Sprint 1

Nombre de Estimación Estimación

COD Prioridad Iteración
historia Aprox. Real

Acceso al
HU01 Baja 1 5 4
sistema

Mantenimiento
HU02 Alta 1 5 4
de Personal

Mantenimiento
HU03 Media 1 3 4
de usuarios

Mantenimiento
HU04 Alta 1 5 4
de prioridades

Fuente: Elaboración propia

155
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

PILA DEL SPRINT 2

Tabla 35: Pila Del Sprint 2

Nombre de Estimación Estimación
COD Prioridad Iteración
historia Aprox. Real

Mantenimiento 2
HU05 Alta 5 4
de categorías

Mantenimiento 2
HU06 Muy Alta 5 6
de incidencias

Cierre de 2
HU07 Muy Alta 4 3
Incidencia

Escalado de 2
HU08 Media 6 3
incidencias

Fuente: Elaboración propia

PILA DEL SPRINT 3

Tabla 36: Pila Del Sprint 3

Nombre de Estimación Estimación

COD Prioridad Iteración
historia Aprox. Real

HU09 Notificación Alta 3 5 4

Registro de 3
HU10 Alta 6 4
Conformidad

3
HU11 Reportes Alta 12 10

Fuente: Elaboración propia

156
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

PLANIFICACIÓN DEL PROYECTO – CRONOGRAMA

Figura 25
Fuente: Elaboración propia

Cronograma del proyecto

157
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

EJECUCIÓN DEL PROYECTO

Sprint

El Sprint es una lista de tareas que se ha elaborado para completar los objetivos y
requerimientos seleccionados para la iteración, al finalizar el Sprint o iteración se
presenta el producto preparado en forma de incremento.

Desarrollo Del Sprint 1

158
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Lista de Pendientes del Sprint

En la tabla 37 se muestra las historias que se desarrollaron en el Sprint 1

Tabla 37: Lista de Pendientes del Sprint 01

Nombre de Estimación Estimación
COD Prioridad Iteración
historia Aprox. Real

Acceso al
HU01 1 1 5 4
sistema

Mantenimiento
HU02 2 1 5 4
de Personal

Mantenimiento
HU03 2 1 3 4
de usuarios

Mantenimiento
HU04 3 1 5 4
de prioridades

Fuente: Elaboración propia

Planificación del Sprint

Figura 26
Fuente: Elaboración propia

Planificación Sprint 01

159
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Análisis

Módulo acceso al sistema

En las siguientes figuras se puede observar la relación entre el actor

“usuario” y los casos de uso del sistema

Figura 27
Fuente: Elaboración propia

Caso de uso Acceso al sistema

160
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Módulo mantenimiento del personal

En las siguientes figuras se puede observar la relación entre el actor

“Coordinador” y los casos de uso del sistema

Figura 28
Fuente: Elaboración propia

Caso de uso mantenimiento del personal

161
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Mantenimiento de usuarios

Figura 29
Fuente: Elaboración propia

Caso de uso Mantenimiento de usuarios

Mantenimiento de prioridades

Figura 30
Fuente: Elaboración propia

162
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Caso de uso Mantenimiento de prioridades

DISEÑO FÍSICO DE LA BASE DE DATOS

En la siguiente figura se presenta el diseño físico de la base de datos.

Figura 31
Fuente: Elaboración propia

Diseño Físico de la Base de Datos

163
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

DISEÑO LÓGICO DE LA BASE DE DATOS

En la siguiente figura se presenta el diseño lógico de la base de datos.

Figura 32
Fuente: Elaboración propia

Diseño Lógico de la Base de Datos

164
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

DICCIONARIO DE DATOS

Tabla Empleado
Tabla que almacena información del empleado dentro de la empresa.

Tabla 38: Estructura Tabla Empleado

TABLA CARGO

ESTRUCTURA

COLUMNA TIPO NULO DESCRIPCIÓN

cod_emp(PK) INT(5) NO Código del empleado

Código del área al que

area_cod_area(FK) INT(5) NO
pertenece el empleado

INT(5)
Código del cargo que le
cargo_cod_cargo(FK) NO
corresponde

INT(5) Código de la persona

Persona_cod_persona(FK) NO que contiene los datos
de este empleado

Estado del empleado

estado VARCHAR(8) SI
dentro del sistema

Fuente: Elaboración propia

165
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Tabla Cargo
Tabla que almacena información de los diversos cargos que conforman la
empresa.

Tabla 39: Estructura Tabla Cargo

TABLA CARGO

ESTRUCTURA

COLUMNA TIPO NULO DESCRIPCIÓN

cod_cargo(PK) INT(5) NO Código del cargo

descripcion VARCHAR(20) NO Describe el cargo

Fuente: Elaboración propia

Tabla Persona
Tabla que almacena información de las personas que forman parte de la
empresa.

Tabla 40: Estructura Tabla Persona

TABLA PERSONA

ESTRUCTURA

COLUMNA TIPO NULO DESCRIPCIÓN

cod_persona(PK) INT(5) NO Código de la persona

Especifica el estado de la
estado VARCHAR(8) NO persona dentro de la empresa si
se encuentra activo o inactivo

Nombres VARCHAR(8) NO Nombres de la persona

166
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Apellidospa VARCHAR(10) NO Apellidos Paternos de la persona

Apellidos Maternos de la
Apellidosma VARCHAR(10) NO
persona

DNI VARCHAR(8) NO DNI de la persona

Dirección VARCHAR(30) NO Dirección de la persona

Teléfono INT(8) SI Teléfono de la persona

Correo VARCHAR(20) NO Correo de la persona

Celular INT(9) SI Celular de la persona

Fuente: Elaboración propia

Tabla Usuario
Tabla que almacena información de los usuarios del sistema

Tabla 41: Estructura Tabla Usuarios

TABLA USUARIOS

ESTRUCTURA

COLUMNA TIPO NULO DESCRIPCIÓN

Código del usuario dentro del

cod_usuario(PK) INT(5) NO
sistema

cod_emp(FK) INT(5) NO Código del empleado

Describe el nombre del usuario

usuario VARCHAR(8) NO
dentro del sistema

167
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Almacena la contraseña que usa

pass VARCHAR(20) NO el usuario para logearse en el
sistema

Especifica el estado del usuario

Estado Usuario VARCHAR(8) SI
dentro del sistema

Fuente: Elaboración propia

Tabla Área
Tabla que almacena información de las áreas de la empresa

Tabla 42: Estructura Tabla Área

TABLA ÁREA

ESTRUCTURA

COLUMNA TIPO NULO DESCRIPCIÓN

Código del área a la que pertenece el

cod_area(PK) INT(5) NO
personal

área VARCHAR(20) NO Describe el área de la empresa

Describe el estado del área dentro de

estadoarea VARCHAR(8) NO
la empresa

Fuente: Elaboración propia

168
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Tabla Prioridad

Tabla que almacena información de la prioridad

Tabla 43: Estructura Tabla Prioridad

TABLA PRIORIDAD

ESTRUCTURA

COLUMNA TIPO NULO DESCRIPCIÓN

cod_prioridad
INT(5) NO Código de la prioridad
(PK)

prioridad VARCHAR(6) NO Describe el nombre de la prioridad

Registra las horas de resolución

hora VARCHAR(8) NO
máximas por prioridad

Permite guardar el documento que

documento VARCHAR(255) SI sustenta el registro de la prioridad
tal como el SLA

estado Describe el resultado de la

VARCHAR(8) NO
prioridad conformidad

Fuente: Elaboración propia

Tabla Estados
Tabla que almacena información de los estados de la incidencia

Tabla 44: Estructura Tabla Estados

TABLA ESTADOS

ESTRUCTURA

169
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

COLUMNA TIPO NULO DESCRIPCIÓN

cod_estados (PK) INT(5) NO Código del estado

Nombreestado VARCHAR(15) NO Descripción del estado

Estadoestados VARCHAR(8) SI Describe el estado del estado

Fuente: Elaboración propia

Tabla Categoría
Tabla que almacena información de la categoría

Tabla 45: Estructura Tabla Categoría

TABLA CATEGORÍA

ESTRUCTURA

COLUMNA TIPO NULO DESCRIPCIÓN

cod_categoria
INT(5) NO Código de la categoría
(PK)

categoría VARCHAR(20) NO Descripción de la categoría

Describe el estado de la
estadocategoria VARCHAR(8) SI
categoría

Fuente: Elaboración propia

170
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Tabla Subcategoría
Tabla que almacena información de la Sub categorías de las incidencias

Tabla 46: Estructura Tabla Sub Categoría

TABLA SUBCATEGORÍA

ESTRUCTURA

COLUMNA TIPO NULO DESCRIPCIÓN

cod_subcategoria Código de la sub

INT(10) NO
(PK) categoría

cod_categoria Código de la categoría a

INT(10) NO
(PK) la que pertenece

Descripción de la
subcategoría VARCHAR(50) NO
subcategoría

Describe el estado de la
estadosub VARCHAR(8) NO
subcategoría

Fuente: Elaboración propia

Tabla Incidencia
Tabla que almacena información de la incidencia

Tabla 47: Estructura Tabla Incidencia

TABLA INCIDENCIA

ESTRUCTURA

COLUMNA TIPO NULO DESCRIPCIÓN

INT(5) Código del ticket que identifica

cod_ticket(PK) NO
a la incidencia

171
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

INT(5)
cod_cordinador Código del usuario con perfil
NO
(FK) Coordinador

INT(5) Código del usuario con perfil

cod_tecnico(FK) NO
Coordinador

cod_prioridad INT(5)
NO Código de la prioridad
(FK)

INT(5)
cod_estados (FK) NO Código del estado

INT(5)
empleado(FK) NO Código del personal

cod_categoria INT(5)
NO Código de la categoría
(FK)

cod_subcategoria INT(5)
NO Código de la sub categoría
(FK)

Almacena la ruta la imagen

imagencierre VARCHAR(255) SI que acompaña el cierre de la
incidencia

Almacena el cálculo si el tiempo

de resolución está dentro del
cumplíosla VARCHAR(2) NO
contrato SLA estipulado según
el tipo de prioridad

descripción VARCHAR(100) NO Describe la incidencia

status VARCHAR(8) NO Estado de la incidencia

asunto VARCHAR(50) NO Asunto o título de la incidencia

172
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Fecha en la cual se registró la

fechaderegistro DATE NO
incidencia

Hora en la cual se cerró la

horaderegistro VARCHAR(20) NO
incidencia

fechadecierre DATE NO

Hora en la cual se cerró la

horadecierre VARCHAR(20) NO
incidencia

Medio de contacto para el

contacto VARCHAR(20) SI
registro de la incidencia

solución VARCHAR(500) NO Describe Solución brindada

Ruta de la imagen que

Imagen VARCHAR(255) SI acompaña el registro de la
incidencia

escalar VARCHAR(2) SI Estado del escalamiento

conformidad Estado de la conformidad del

VARCHAR(20) SI
personal personal atendido

Fuente: Elaboración propia

173
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Diseño de Interfaces

Se determinó para cada historia dos propuestas, y en coordinación con el dueño

del producto se seleccionó la mejor opción. A continuación se muestran las
propuestas desde la figura 33 hasta la figura 36

Interfaces para el módulo Acceso al sistema

Figura 33
Fuente: Elaboración propia

Prototipo Aceptado Prototipo Rechazado

Prototipos Login

Interfaces para el módulo Mantenimiento del personal

Figura 34
Fuente: Elaboración propia

Prototipo Aceptado Prototipo Rechazado

174
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Prototipo Aceptado Prototipo Rechazado

Fuente: Elaboración propia

Prototipo Aceptado Prototipo Rechazado

Prototipo Aceptado Prototipo Rechazado

Prototipo Aceptado Prototipo Rechazado

175
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Fuente: Elaboración propia

Prototipo Aceptado Prototipo Rechazado

Prototipo Aceptado Prototipo Rechazado

Prototipos Mantenimiento Personal

Interfaces para el módulo Mantenimiento de usuarios

Figura 35
Fuente: Elaboración propia

Prototipo Aceptado Prototipo Rechazado

Prototipo Aceptado Prototipo Rechazado

176
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Prototipo Aceptado Prototipo Rechazado

Prototipos Mantenimiento de Usuarios

Interfaces para el módulo Mantenimiento de prioridades

Figura 36

Prototipo Aceptado Prototipo Rechazado

Fuente: Elaboración propia

Prototipo Aceptado Prototipo Rechazado

Prototipo Aceptado Prototipo Rechazado

177
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Prototipos Mantenimiento de Prioridades

Implementación de los prototipos seleccionados

Se determinó por cada historia un conjunto de pantallas, las cuales fueron

implementadas. A continuación se muestran las imágenes de la implementación de
los prototipos seleccionados del Sprint 1, desde la figura 37 hasta la figura 54

Acceso al sistema

Figura 37
Fuente: Elaboración propia

Acceso al Sistema
Menú principal

Figura 38
Fuente: Elaboración propia

Inicio

178
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Mantenimiento Personal

Figura 39
Fuente: Elaboración propia

Listar Personal

Figura 40
Fuente: Elaboración propia

Registro de Personal

179
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Fuente: Elaboración propia Figura 41

Modificar de Personal

Figura 42
Fuente: Elaboración propia

Eliminar de Personal

180
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 43
Fuente: Elaboración propia

Listar Área

Figura 44
Fuente: Elaboración propia

Registrar Área

181
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Fuente: Elaboración propia Figura 45

Modificar Área

Figura 46
Fuente: Elaboración propia

Eliminar Área
Mantenimiento de Usuarios

Figura 47
Fuente: Elaboración propia

Interfaz Listar Usuarios

182
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 48
Fuente: Elaboración propia

Interfaz Registrar Usuarios

Figura 49
Fuente: Elaboración propia

Interfaz Modificar Usuarios

183
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Fuente: Elaboración propia Figura 50

Interfaz Eliminar Usuarios

Mantenimiento de Prioridades

Figura 51
Fuente: Elaboración propia

Interfaz Listar Prioridades

184
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Fuente: Elaboración propia Figura 52

Interfaz Registrar Prioridades

Figura 53
Fuente: Elaboración propia

Interfaz Modificar Prioridades

185
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Fuente: Elaboración propia Figura 54

Interfaz Eliminar Prioridades

Código
En este segmento se exhibe un fragmento del código utilizado en la realización
de historias que intervienen en el Sprint 1, desde la figura 55 hasta la figura 77

Módulo Login

Figura 55
Fuente: Elaboración propia

Vista Login

186
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 56
Fuente: Elaboración propia

Validar Usuario

187
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 57
Fuente: Elaboración propia

Cerrar sesión
Módulo Mantenimiento Personal
Modelo
Figura 58
Fuente: Elaboración propia

Modelo Mantenimiento Personal

188
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Controlador

Figura 59
Fuente: Elaboración propia

Controlador Mantenimiento Personal

189
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Vista

Figura 60
Fuente: Elaboración propia

Vista Listar Personal

190
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 61
Fuente: Elaboración propia

Vista Registrar Personal

Figura 62
Fuente: Elaboración propia

Vista Modificar Personal

191
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Módulo Área
Modelo
Figura 63
Fuente: Elaboración propia

Modelo Área
Controlador
Figura 64
Fuente: Elaboración propia

Controlador Área

192
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Vista
Figura 65
Fuente: Elaboración propia

Vista Listar Área

Figura 66
Fuente: Elaboración propia

Vista Registrar Área

193
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 67
Fuente: Elaboración propia

Vista Modificar Área

194
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Módulo Mantenimiento Usuarios

Modelo

Figura 68
Fuente: Elaboración propia

Modelo Mantenimiento Usuarios

195
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Controlador

Figura 69
Fuente: Elaboración propia

Controlador Mantenimiento Usuarios

196
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Vista

Figura 70
Fuente: Elaboración propia

Vista Listar Usuarios

197
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 71
Fuente: Elaboración propia

Vista Registrar Usuario

198
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 72
Fuente: Elaboración propia

Vista Modificar Usuario

199
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Módulo Mantenimiento Prioridades

Modelo

Figura 73
Fuente: Elaboración propia

Modelo Mantenimiento Prioridades

200
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Controlador

Figura 74
Fuente: Elaboración propia

Controlador Mantenimiento Prioridades

201
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Vista

Figura 75
Fuente: Elaboración propia

Vista Listar Prioridades

202
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 76
Fuente: Elaboración propia

Vista Registrar Prioridades

Figura 77
Fuente: Elaboración propia

Vista Modificar Prioridades

203
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Pruebas

En la tabla 48 se muestra el resumen de los casos de pruebas realizados en el

Sprint 1

Tabla 48: Casos de pruebas sprint 01

Casos de prueba 20
Exitosas 20
Observadas 0
Estado Completado
Fuente: Elaboración propia

Resumen del Sprint

Llegada la fecha de culminación del Sprint, en la tabla 49 se muestra el resumen

donde se detalla el total de historias que se planteó desarrollar en este Sprint, las
historias terminadas y las historias por terminar.

Tabla 49: Resumen de sprint 01

Total de historias 4
Historias Terminadas 4
Historias por terminar 0
Avance 100%
Estado Completado
Fuente: Elaboración propia

204
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Burndown Chart

El siguiente gráfico que representa el estado del progreso del trabajo del Sprint
desarrollado

Figura 78
Fuente: Elaboración propia

Burndownchart Sprint 01

Retrospectiva del Sprint

Al final del Sprint, el Equipo Scrum se reunió para recibir la respuesta del Scrum
master, para saber cómo le fue en la reunión con el Product Owner, resulta que el
producto se entregó sin problemas entregado y es el cliente quedo satisfecho.

Tabla 50: Retrospectiva Sprint 01

Aspectos Positivos Aspectos Negativos

Buen clima laboral Falta de coordinación
Integración del equipo Problemas con la energía eléctrica
Manejo de las herramientas de trabajo Intermitencias con la señal de
internet
Conocimiento del tema
Fuente: Elaboración propia

205
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

206
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Desarrollo Del Sprint 2

207
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Lista de Pendientes del Sprint

En la tabla 51 se muestra las historias que se desarrollaron en el Sprint 2

Tabla 51: Lista de Pendientes del Sprint 02

Nombre de Estimación Estimación

COD Prioridad Iteración
historia Aprox. Real

Mantenimiento
HU05 3 2 5 4
de categorías

Mantenimiento 2
HU06 4 5 6
de incidencias

Cierre de 2
HU07 4 4 3
Incidencia

Escalado de 2
HU08 5 6 3
incidencias

Fuente: Elaboración propia

Planificación del Sprint

Figura 79
Fuente: Elaboración propia

Planificación Sprint 02

208
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Análisis

En las siguientes figuras se puede observar la relación entre el actor

“Coordinador” y los casos de uso del sistema.

Módulo mantenimiento de categorías

Figura 80
Fuente: Elaboración propia

Caso de uso mantenimiento de categorías

209
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Mantenimiento de incidencias

Figura 81
Fuente: Elaboración propia

Caso de uso mantenimiento de incidencias

Módulo Cierre de incidencias

Figura 82
Fuente: Elaboración propia

Caso de uso Cierre de incidencias

210
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Módulo escalado de incidencias

Figura 83
Fuente: Elaboración propia

Caso de uso escalado de incidencias

Diseño de Interfaces

Se determinó para cada historia dos propuestas, y en coordinación con el dueño

del producto se seleccionó la mejor opción. A continuación se muestran las
propuestas desde la figura 84 hasta la figura 105.

Interfaces para el Mantenimiento de categorías

Figura 84

211
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Fuente: Elaboración propia Prototipo Aceptado Prototipo Rechazado

Prototipo Aceptado Prototipo Rechazado

Prototipo Aceptado Prototipo Rechazado

Prototipo Aceptado Prototipo Rechazado

Fuente: Elaboración propia

Prototipo Aceptado Prototipo Rechazado

212
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Prototipo Aceptado Prototipo Rechazado

Prototipos Mantenimiento de Categorías

Interfaces para el Mantenimiento de incidencias

Figura 85

Prototipo Aceptado Prototipo Rechazado

Fuente: Elaboración propia

Prototipo Aceptado Prototipo Rechazado

213
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Prototipo Aceptado Prototipo Rechazado

Prototipos para el Mantenimiento de incidencias

Fuente: Elaboración propia

Interfaces para el Módulo Cierre de Incidencias

Figura 86

Prototipo Aceptado Prototipo Rechazado

Fuente: Elaboración propia

Prototipo Aceptado Prototipo Rechazado

214
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Prototipo Aceptado Prototipo Rechazado

Prototipos Módulo Cierre de Incidencias

Interfaces para el Módulo Escalado de Incidencias

Figura 87
Fuente: Elaboración propia

Prototipo Aceptado Prototipo Rechazado

Prototipos Módulo Escalado de Incidencias

215
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Implementación de los prototipos seleccionados

Se determinó por cada historia un conjunto de pantallas, las cuales fueron

implementadas. A continuación se muestran las imágenes de la implementación de
los prototipos seleccionados del Sprint 2, desde la figura 88 hasta la figura 105.

Mantenimiento de Categorías

Figura 88
Fuente: Elaboración propia

Interfaz Listar Categorías

Fuente: Elaboración propia

Figura 89

Interfaz Registrar Categorías

216
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Fuente: Elaboración propia Figura 90

Interfaz Modificar Categorías

Figura 91
Fuente: Elaboración propia

Interfaz Eliminar Categorías

217
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Fuente: Elaboración propia Figura 92

Interfaz Listar Subcategorías

Figura 93
Fuente: Elaboración propia

Interfaz Registrar Subcategorías

218
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 94
Fuente: Elaboración propia

Interfaz Eliminar Subcategorías

Mantenimiento Incidencias

Listar Incidencias

Figura 95
Fuente: Elaboración propia

Interfaz Listar Incidencias

219
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 96
Fuente: Elaboración propia

Interfaz Listar Incidencias Escaladas Cerradas

Figura 97
Fuente: Elaboración propia

Interfaz Listar Incidencias Escaladas

220
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Fuente: Elaboración propia Figura 98

Interfaz Registrar Incidencia

Fuente: Elaboración propia

Figura 99

Interfaz Modificar Incidencia

221
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Fuente: Elaboración propia Figura 100

Interfaz Eliminar Incidencia

Cierre de Incidencias

Figura 101
Fuente: Elaboración propia

Interfaz de Cerrar Incidencia

222
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Fuente: Elaboración propia Figura 102

Lista Incidencias Cerradas

Escalado de Incidencias

Figura 103
Fuente: Elaboración propia

Interfaz Escalar Incidencia

223
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 104
Fuente: Elaboración propia

Interfaz Listar Incidencias Escaladas

224
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Código
En este segmento se exhibe un fragmento del código utilizado en la realización
de historias que intervienen en el Sprint 2, desde la figura 105 hasta la figura
126.

Módulo Mantenimiento Categorías

Modelo

Figura 105
Fuente: Elaboración propia

Modelo Mantenimiento Categorías

225
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Controlador

Figura 106
Fuente: Elaboración propia

Controlador Mantenimiento Categorías

226
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Vista

Figura 107
Fuente: Elaboración propia

Vista Listar Categorías

227
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 108
Fuente: Elaboración propia

Vista Registrar Categorías

Figura 109
Fuente: Elaboración propia

Vista Modificar Categorías

228
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Modulo Mantenimiento Sub-Categorías

Modelo
Figura 110
Fuente: Elaboración propia

Modelo Mantenimiento Sub-Categoría

229
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Controlador

Figura 111
Fuente: Elaboración propia

Controlador Mantenimiento Sub-Categoría

230
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Vista
Figura 112
Fuente: Elaboración propia

Vista Lista Sub-Categorías

Figura 113
Fuente: Elaboración propia

Vista Registrar Sub-Categorías

231
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 114
Fuente: Elaboración propia

Vista Modificar Sub-Categorías

232
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Módulo Mantenimiento Incidencias

Modelo

Figura 115
Fuente: Elaboración propia

Modelo Mantenimiento Incidencias

233
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Controlador

Figura 116
Fuente: Elaboración propia

Controlador Mantenimiento Incidencias

234
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Vista

Figura 117
Fuente: Elaboración propia

Vista Listar Incidencias

235
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 118
Fuente: Elaboración propia

Vista Listar Incidencias Escaladas

236
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 119
Fuente: Elaboración propia

Vista Listar Incidencias Escaladas Cerradas

237
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 120
Fuente: Elaboración propia

Vista Registrar Incidencias

238
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 121
Fuente: Elaboración propia

Vista Modificar Incidencias

239
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Módulo Cierre de Incidencias

Controlador
Figura 122
Fuente: Elaboración propia

Controlador Cierre de Incidencias

240
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Vista

Figura 123
Fuente: Elaboración propia

Vista Cierre de Incidencia

241
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 124
Fuente: Elaboración propia

Vista Listar Incidencias Cerradas

242
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Módulo Escalado de Incidencias

Controlador

Figura 125
Fuente: Elaboración propia

Controlador Escalado de Incidencias

243
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Vista

Figura 126
Fuente: Elaboración propia

Vista Listar Incidencias Escaladas

244
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Pruebas

En la tabla 52 se muestra el resumen de los casos de pruebas realizados en el

Sprint 2

Tabla 52: Casos de pruebas sprint 02

Casos de prueba 20
Exitosas 20
Observadas 0
Estado Completado
Fuente: Elaboración propia

Resumen del Sprint

Llegada la fecha de culminación del Sprint, en la tabla 53 se muestra el resumen

donde se detalla el total de historias que se planteó desarrollar en este Sprint, las
historias terminadas y las historias por terminar.

Tabla 53: Resumen de sprint 02

Total de historias 4
Historias Terminadas 4
Historias por terminar 0
Avance 100%
Estado Completado
Fuente: Elaboración propia

Burndown Chart

El siguiente gráfico que representa el estado del progreso del trabajo del Sprint
desarrollado

245
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 127
Fuente: Elaboración propia

Burndownchart Sprint 02

Retrospectiva Del Sprint

Al final del Sprint, el Equipo Scrum se reunió para recibir la respuesta del Scrum
master, para saber cómo le fue en la reunión con el Product Owner, resulta que el
producto se entregó sin problemas entregado y el cliente quedo satisfecho.

Tabla 54: Retrospectiva Sprint 02

Aspectos Positivos Aspectos Negativos

Apoyo permanente entre los miembros Problemas técnicos con los equipos
del equipo
Integración del equipo
Aporte de ideas entre los miembros
Comunicación permanente
Fuente: Elaboración propia

246
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

247
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Desarrollo Del Sprint 3

248
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Lista de Pendientes del Sprint

En la tabla 55 se muestra las historias que se desarrollaron en el Sprint 3

Tabla 55: Lista de Pendientes del Sprint 03

Nombre de Estimación Estimación

COD Prioridad Iteración
historia Aprox. Real

HU09 Notificación 5 3 5 4

Registro de 3
HU10 6 6 4
Conformidad

HU11 Reportes 6 3 12 10

Fuente: Elaboración propia

Planificación del Sprint

Figura 128
Fuente: Elaboración propia

Planificación Sprint 05

249
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Análisis

En las siguientes figuras se puede observar la relación entre el actor “usuario “,

“empleado” y los casos de uso del sistema.

Módulo Notificación

Figura 129
Fuente: Elaboración propia

Caso de uso Notificación

Diseño de Interfaces

Se determinó para cada historia dos propuestas, y en coordinación con el dueño

del producto se seleccionó la mejor opción. A continuación se muestran las
propuestas desde la figura 130 hasta la figura 137.

Interfaces para el módulo Registro de Conformidad

250
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 130
Fuente: Elaboración propia

Interfaz Registro Conformidad

Figura 131
Fuente: Elaboración propia

Interfaz Confirmación Conformidad

251
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Fuente: Elaboración propia Figura 132

Interfaz Reportes Post test

Figura 133
Fuente: Elaboración propia

Interfaz Reportes Pre test

252
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Fuente: Elaboración propia Figura 134

Interfaz Reportes por Área y prioridad

Figura 135
Fuente: Elaboración propia

Interfaz Reportes por Categoría y Subcategoría

253
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 136
Fuente: Elaboración propia

Interfaz Reportes por Técnico y Fechas

Figura 137
Fuente: Elaboración propia

Interfaz Reportes por Estado y Personal

254
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Código
En este segmento se exhibe un fragmento del código utilizado en la realización
de historias que intervienen en el Sprint 3, desde la figura 138 hasta la figura 144

Módulo Conformidad
Controlador
Figura 138
Fuente: Elaboración propia

Controlador Conformidad

255
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Vista
Figura 139
Fuente: Elaboración propia

Vista Conformidad

256
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Módulo Reportes
Figura 140
Fuente: Elaboración propia

Vista reportes por área y prioridad

257
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 141
Fuente: Elaboración propia

Vista reportes por categoría y subcategoría

258
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 142
Fuente: Elaboración propia

Vista reportes por técnico y fechas

259
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 143
Fuente: Elaboración propia

Vista reportes por Estado y personal

260
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Figura 144
Fuente: Elaboración propia

Vista reportes Pretest y PosTest

261
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Pruebas

En la tabla 56 se muestra el resumen de los casos de pruebas realizados en el

Sprint 03

Tabla 56: Casos de pruebas sprint 03

Casos de prueba 20
Exitosas 20
Observadas 0
Estado Completado
Fuente: Elaboración propia

Resumen del Sprint

Llegada la fecha de culminación del Sprint, en la tabla 57 se muestra el resumen

donde se detalla el total de historias que se planteó desarrollar en este Sprint, las
historias terminadas y las historias por terminar.

Tabla 57: Resumen de sprint 03

Total de historias 3
Historias Terminadas 3
Historias por terminar 0
Avance 100%
Estado Completado
Fuente: Elaboración propia

262
 Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

Burndown Chart

El siguiente gráfico que representa el estado del progreso del trabajo del Sprint
desarrollado

Figura 145
Fuente: Elaboración propia

Burndownchart Sprint 03

Retrospectiva Del Sprint

Al final del Sprint, el Equipo Scrum se reunió para recibir la respuesta del Scrum
master, para saber cómo le fue en la reunión con el Product Owner, resulta que el
producto se entregó sin problemas entregado y el cliente quedo satisfecho.

Tabla 58: Retrospectiva Sprint 03

Aspectos Positivos Aspectos Negativos

Apoyo permanente entre los miembros Problemas técnicos con los equipos
del equipo
Integración del equipo Problemas con la energía eléctrica
Aporte de ideas entre los miembros
Comunicación permanente
Fuente: Elaboración propia

263
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

264
Universidad Cesar Vallejo Escuela de Ingeniería de Sistemas

PRESUPUESTO
En la siguiente tabla se detalla el presupuesto empleado para la implementación
del sistema desarrollado líneas atrás.

Materiales de Oficina

Material c/u Cantidad Consto

Millar de Hojas S/. 9.00 5 S/. 40.0
bond
Lapiceros S/. 1.00 4 S/. 4.0
Copias S/. 0.05 750 S/. 37.5
Impresiones S/. 0.10 800 S/. 8.00
Total S/. 89.5

Hardware y Software empleado

Tabla 59: Materiales de Hardware y Software

Componente Modelo Costo
Servidor Web Servidor Lenovo S/. 6226.58
Thinkserver TD350,
Intel Xeon
Servidor Base de datos Servidor Lenovo S/. 4967.71
Thinkserver RD350

Router Router Ethernet S/.1.370

Mikrotik Routerboard
Rb1100ahx2

Centos Versión 5.8 S/. 0

Apache Versión 2.4 S/. 0
Mysql Versión 5.1 S/. 0
PHP Versión 5.3 S/. 0
Total S/. 13223.58
Fuente: Elaboración propia

265