Avance Bruno 11 06 2019 C1

FACULTAD DE INGENIERÍA
ESCUELA ACADÉMICO PROFESIONAL DE INGENIERIA DE SISTEMAS
SISTEMA WEB PARA LA GESTIÓN DE INCIDENCIAS DEL AREA DE

TI DE LA EMPRESA BELCORP
PROYECTO DE INVESTIGACION
AUTOR:
ASESOR:
LÍNEA DE INVESTIGACIÓN:
Sistemas de Información
LIMA – PERU
2019
GENERALIDADES
TÍTULO:
Sistema Web para la gestión de incidencias del área de TI de la empresa Belcorp
AUTOR:
Bruno
ASESOR:
TIPO DE INVESTIGACIÓN:
Experimental
LÍNEA DE INVESTIGACIÓN:
Sistemas de Información
LOCALIDAD:
Empresa – Belcorp
Av.
DURACIÓN DE LA INVESTIGACIÓN:
2
I. INTRODUCCIÓN
I.1. Realidad Problemática
En la actualidad, las TI se encuentran más presentes en las empresas, dando
soporte a los servicios y procesos. Sin embargo, es visible que las áreas de TI no
cumplen con las expectativas que espera el negocio con respecto a la atención de
las incidencias producidas en las TI, una incidencia es una interrupción no
planificada del servicio, las cuales producen grandes pérdidas económicas ya que
estas incidencias provocan la paralización de los procesos del negocio. (1)
A lo largo de todo el mundo, muchas de las organizaciones proporcionan a sus
usuarios que tienen contacto con su plataforma de datos, una unidad de disco
remoto en atención a las pérdidas de datos que se producen constantemente por
no tener un respaldo de datos locales propios de las empresas. Siendo esta una
medida tomada por las mismas empresas para solucionar incidencias que se
presentan en sus plataformas. (2)
Existen diversos factores que perjudican la gestión de incidentes en distintas
organizaciones, como es el caso de una entidad que brinda el servicio de TI a
organismos del estado peruano; dentro de estos se encuentran los factores
externos (políticos), la alta rotación del personal a cargo, condiciones técnicas
limitadas y déficit de buenas prácticas estandarizadas, haciendo de esta manera
difícil reponer el servicio de una manera rápida y disminuir el impacto
desfavorable sobre las operaciones de la organización. (3)
Belcorp es una empresa dedicada al rubro de cuidado personal, la cual se
encarga de ofrecer productos de belleza por medio de consultoras encargadas de
la venta de productos de las marcas L’Bel, Ésika y Cyzone. Cada una de las
3
consultoras se propone lo que quiere vender y de acuerdo a esa cantidad recibirá
una retribución económica, las consultoras registran cada uno de sus pedidos
mediante la plataforma digital de la empresa. Sin embargo, al igual que en
muchas plataformas digitales, existe una saturación de la página por distintos
motivos, dicha incidencia perjudica directamente a las consultoras, pues no
realizarán el pedido a tiempo, generando incomodidad a las mismas.
El registro de dichos incidentes lo realiza el área de Tecnología e Investigación
(TI), la misma que se encarga de la gestión de monitoreo de las incidencias y
requerimientos de los servicios de la empresa Belcorp. La gestión de este servicio
es la que se busca optimizar, debido a que existe falta de un sistema que englobe
este servicio y se pueda tener una gestión rápida y eficiente frente a las distintas
incidencias y requerimientos presentados. El monitoreo de incidencias se realiza
con una aplicación conocida como HP open view, la cual es utilizada para el
control de ordenadores y servicios, con la cual se maneja el alertamiento de
incidencias y muchas veces tenemos alertas recurrentes o falsos positivos, las
cuales no son tratadas con una trazabilidad correcta para actuar adecuadamente
frente a esos eventos, así mismo no cuenta con una relación directa con un
sistema generador de tickets por eventos, este proceso se realiza con otra
herramienta llamada JIRA, la cual nos permite creación de tickets de incidentes o
requerimientos dependiente el evento presentado.
Otro problema referente a la gestión de incidencias es que los procesos de
requerimientos, son manejados de forma muchas veces incorrectas, por falta de
información del requerimiento, falta de comunicación con los involucrados,
problemas con el flujo correcto de atención, demoras en atención de trabajos
programados, generando incomodidad por parte de los solicitantes y los
4
encargados de la atención. Es por ello que en la presente investigación se planteó
la siguiente interrogante ¿La implementación de un sistema web optimizará la
gestión de incidencias del área de TI de la empresa Belcorp?
I.2. Trabajos previos
Internacionales:
Jiménez (2014), con su tesis “Diseño de un Sistema de Gestión y Análisis de
Incidencias” (Tesis de pregrado). Universidad Carlos III de Madrid. Madrid,
España. Propuso analizar y diseñar un sistema de gestión de incidencias que
afectan a los servicios prestados por una empresa, utilizando como base el marco
de referencia ITIL que presenta un conjunto de buenas prácticas para la gestión
de servicios TIC; y la norma ISO/IEC 20000; que define un sistema de gestión de
Servicios TI con un conjunto de especificaciones y buenas prácticas referente a la
gestión de incidencias. Se utilizó el lenguaje UML para la representación de los
casos. Siendo una investigación experimental. Se obtuvo que, gracias al sistema
diseñado, los distintos usuarios podrán generar incidencias y estas ser
gestionadas correctamente dando uso a todas las funcionalidades detalladas en
los requisitos del sistema.
El presente estudio tuvo como finalidad Implementar el sistema diseñado para su
uso en la gestión y análisis de incidencias. Con el fin de corroborar totalmente su
usabilidad y validez, lo cual nos va permitir lograr con el desarrollo de la tesis. (4)
5
Nacionales:
Tarazona (2017), con su tesis “Desarrollo e Implementación de un sistema web de
gestión de incidencias y entrega de documentos para la empresa Electrocentro
S.A. 2017” (Tesis de pregrado). Universidad Nacional “Hermilio Valdizán”.
Huánuco, Perú. Planteó desarrollar e implementar un sistema web que contribuya
a la mejora de la gestión de incidencias y entrega de documentos de
Electrocentro S.A., usando una metodología UML para el desarrollo del sistema, y
aplicando una investigación de tipo tecnológica, con un diseño no experimental.
Se aplicó instrumentos como cuestionario, entrevista y libreta de apuntes a 77
usuarios de las diferentes áreas de la empresa. Obteniendo como resultados la
implementación del sistema web permitiendo tener información almacenada y
centralizada de todo lo que se concierne a la gestión de incidencia y entrega de
documentos de la empresa, con fines de mejora de dicha gestión.
En la tesis anteriormente mencionada expone el desarrollo e implantación del
sistema web que permite a la empresa mejorar la gestión de incidencias, por lo
que para el análisis se dispone de diversas herramientas como la metodología
RUP; cuyo fin es promover el continuo y correcto uso del sistema desarrollado
para gestionar de manera adecuada las incidencias que pueden suscitar en el
desarrollo de las actividades cotidianas y disminuir el número del índice de
reclamos de los clientes. (5)
Locales:
Fernández (2017), en su tesis “Desarrollo de un sistema de información haciendo
uso de la metodología XP para la gestión de ventas, compras y almacén de la
6
empresa Agro Market Perú S.A.C” (Tesis de Pre Grado) de la Universidad
Nacional Pedro Ruiz Gallo, ubicada en la ciudad de Lambayeque, Perú, tiene
como objetivo principal desarrollar un sistema de información haciendo uso de la
Metodología XP, en la empresa Agro Market Perú S.A.C: para el desarrollo del
sistema de información se realizarón varios procedimientos como la recopilación
de información, revisión de archivos físicos de la empresa y entrevistas con el
personal involucrado en los procesos; con el procesamiento de la información se
obtuvo que la metodología XP permitió obtener documentos técnicos y de
requerimientos, lo que facilitó la realización de análisis y de acciones rápidas en
caso de presentarse modificaciones, también demostraron que la metodología XP
es eficiente debido a que le facilitó al desarrollador realizar la aplicación sin
detenerse en una extensa documentación y diagramación de los modelos,
propiciando agilizar de forma dinámica la gestión de diversas operaciones de las
áreas de logísticas como de ventas en la entidad de estudio (6)
Vásquez (2017), con su tesis “Sistema experto para el proceso de gestión de
incidentes de TI en la empresa Talma Servicios Aeroportuarios S.A.” (Tesis de
pregrado). Universidad César Vallejo. Lima, Perú. Se planteó determinar de qué
manera influye un sistema experto en el proceso y gestión de incidentes de TI en
la empresa Talma Servicios Aeroportuarios S.S., hizo uso de una metodología
MAS-CommonKads para el desarrollo del sistema experto. El tipo de investigación
utilizada es aplicado y utilizó un diseño Pre-Experimental y de enfoque
cuantitativo. Consideró 162 tickets como muestra. Utilizó un muestro probabilístico
aleatorio simple considerando como técnica de recolección de datos el fichaje. Se
obtuvo que el sistema experto permitió incrementar el grado de rendimiento de
0.91 unid. a 0.03 unid., del mismo modo, se incrementó la tasa de solución de
7
incidentes de 0.77 unid. a 1.00 unid.; por lo que se concluyó que el sistema
experto mejora el proceso de gestión de incidentes en la empresa Talma
Servicios Aeroportuarios S.A.
En la tesis expuesta se identifica la influencia del sistema experto en el proceso
de Gestión de Incidentes en la empresa Talma Servicios Aeroportuarios S.A., por
lo que, con ayuda del sistema experto, los usuarios podrán reportar incidentes
ocurridos con los servicios de TI, con el fin de reducir tiempos en la solución de
incidentes, así como también generar nueva información para poder enfrentar
problemas futuros. (7)
Huamán y Huayanca (2017), con sus tesis “Desarrollo e Implementación de un
Sistema de Información para mejorar los Procesos de compras y ventas en la
Empresa Humaju” (Tesis de pregrado). Universidad Autónoma del Perú. Lima,
Perú. Se planteó desarrollar e implementar un Sistema de Información con la
metodología Proceso Unificado Ágil (AUP) para mejorar los procesos de Compras
y Ventas en la Empresa Humaju, usando un diseño Pre Experimental, por lo que
aplicó la observación y una encuesta como técnicas de investigación,
considerando 30 procesos de compras y ventas como muestro, obteniéndose
como resultados que la implementación de un sistema de información disminuye
tiempos, mejorando los procesos de compra y ventas en la empresa Humaju.
La tesis anteriormente mencionada sobre el desarrollo e implementación de un
sistema de información para mejorar los procesos de compras y ventas en la
empresa Humaju, permite brindar soluciones con respecto a la demora de
atención, así como la falta de información en los procesos de compra y ventas de
la empresa Humaju. Es por ello que se dio un soporte adecuado a las áreas
8
involucradas, ya que los procesos serán más dinámicos y entendibles para el
usuario. (8)
Zegarra (2016), con su tesis “Sistema informático para la gestión de incidencias
en la empresa Terranorte S.A.C” (Tesis de pregrado). Universidad César Vallejo.
Lima, Perú. Se propuso determinar la influencia de un sistema informático para la
gestión de incidencias en la empresa Terranorte, como influye en la ratio de
resolución de incidencias y cómo influye en la ratio de incidencias reabiertas.
Utilizando la metodología SCRUM para el desarrollo del sistema informático para
la gestión de incidencias, así como un lenguaje de programación PHP. El tipo de
estudio fue Aplicada-Experimental, usando un diseño experimental. Se analizó 22
reportes de incidencias que fueron registradas por el departamento de sistemas
por el periodo de un mes. Los resultados de esta investigación muestran que un
sistema informático si influye en la gestión de incidencias, así como también se
identificó que el indicador ratio de resolución de incidencias aumentó un 24% y el
ratio de incidencias reabiertas aumentó un 36%.
El presente estudio expone como la metodología SCRUM y los componentes
informáticos son importantes para desarrollar un sistema para la gestión de
incidencias en la empresa Terranorte, con el fin de identificar como influye en el
ratio de resolución de incidencias y en el ratio de incidencias reabiertas. (9)
Alfaro y Paucar (2016), con su tesis “Construcción de un Datamart que apoye en
la toma de decisiones de la gestión de incidencias en una mesa de ayuda: Caso
Consorcio Peruano de Empresas” (Tesis de pregrado). Universidad Nacional
Mayor de San Marcos. Lima, Perú. Se planteó analizar, diseñar e implementar
9
una Herramienta Informática que apoye en la toma de decisiones en el proceso
de Gestión de Incidencias en la Mesa de Ayuda a través de un Datamart haciendo
uso de metodologías de Data Warehousing, usando un diseño experimental, con
una muestra de 12.062 incidencias. Obteniéndose como resultado una mejor
visualización de los indicadores de desempeño de la gestión de incidencias y
también permite que el usuario final pueda analizar más rápido la información y
tomar decisiones más efectivas.
La tesis antes mencionada expone la construcción de un Datamart que apoye en
la toma de decisiones de la gestión de incidencias en una mesa de ayuda, por lo
que se hace uso de herramientas informáticas para su desarrollo, con el fin de
obtener tendencias e indicadores de grandes cantidades de datos de los
incidentes reportados por los usuarios, para un análisis rápido y tomar acciones
correctivas. (10)
Santisteban (2016), con su tesis titulada “Sistema informático para la gestión de
incidencias en ENTERPRISE SOLUTIONS DEVELOPMENT S.A.C.” (Tesis de
pregrado). Universidad César Vallejo. Lima, Perú. Tuvo como objetivo determinar
la influencia de un Sistema informático en la gestión de incidencias en Enterprise
Solutions Development S.A.C. Utilizó una investigación tipo experimental –
aplicada, con un diseño pre-experimental y el enfoque cuantitativo. La muestra
estuvo conformada por 20 reportes para el indicador ratio de incidencias
reabiertas y 20 para el indicador ratio de resolución de incidencias. Los resultados
obtenidos en el pre-test para el indicador ratio de incidencias reabiertas fueron de
0.41 y en el post-test fue del 0.35, así también para el indicador ratio de
resolución de incidencias en el pre-test fue del 0.66 y en post-test fue de 0.80. Por
lo que se concluye que con el sistema informático disminuye el ratio de
10
incidencias reabiertas y para el segundo indicador el sistema informático aumenta
el ratio de resolución de incidencias.
El presente estudio expone la influencia de un sistema informático en la gestión
de incidencias en Enterprise Solutions Development S.A.C., con el fin de
disminuir el ratio de incidencias reabiertas y a fin de aumentar el ratio de
resolución de incidencias. (11)
Gonzáles (2016), con su tesis titulada “Desarrollo e implementación de un
Sistema de Información para el control del proceso de capacitación de una
Empresa del rubro de telecomunicaciones en el Perú” (Tesis de pregrado).
Universidad Católica Sedes Sapientiae. Lima, Perú. Se planteó como objetivo
implementar un sistema de información en web para el control de procesos de
capacitación que ejecuta La Academia Perú. Consideró una investigación de tipo
ex post facto transversal, utilizando un método empírico, aplicando una encuesta
a 28 trabajadores de La Academia Perú. Por ende, se concluyó que la
implementación de un sistema web controla eficientemente los procesos
ejecutados por La Academia Perú y aumenta la confiabilidad de los indicadores
de gestión, así como también optimiza tiempos de entrega de indicadores.
En tesis anteriormente mencionada el autor suscribe que, para implementar un
sistema de información en web para el control de procesos de capacitación, se
hizo uso de tecnologías como ASP.NET WebForms, HTML5, SQL Server 2008
R2 y otras tecnologías de vanguardia. Bajo el enfoque de la metodología Open
Unified Process. Con el fin de definir formalmente las vías de comunicación
adecuadas y evitar impactos negativos e imprevistos, manteniendo la integridad
de la información. (12)
11
Loayza (2015), con su tesis “Modelo de Gestión de Incidentes, Aplicando ITIL v3.0
en un organismo del Estado Peruano” (Tesis de pregrado). Universidad de Lima.
Lima, Perú. Se planteó diseñar un nuevo modelo de Gestión de incidentes
utilizando la Metodología ITIL V3.0, para la entidad gubernamental, de tal forma
que se superen las deficiencias y la pérdida de calidad del servicio que
actualmente presenta. Consideró una investigación de tipo experimental,
obteniendo como resultados que la atención de incidentes y la satisfacción del
usuario final mejoraron. Se logró establecer una línea base de indicadores que
permitirán el monitoreo de la gestión de incidentes y hacer los ajustes necesarios.
El presente estudio expone la aplicación del nuevo modelo de gestión de
incidentes implicando la formalización del proceso de gestión de incidentes, de tal
manera que se modificaron algunos procedimientos que se especifican en el
presente trabajo. Cuyo fin fue mejorar la calidad de los servicios de tecnologías
de la información ofrecidos por la entidad en estudio. (13).
I.3. Teorías Relacionadas al tema
I.3.1. Sistema Web
Según Caivano y Villoria (2012), los sistemas web son herramientas que son
manejadas a través de una conexión de red, en casos se usa la computadora
como acceso de una aplicación remota. (14)
Para Aguilar y Dávila (2013), un sistema web es una herramienta que emplea
la arquitectura cliente-servidor, en el que un navegador web cualquiera debe
ser el cliente para que pueda acceder a una aplicación, mediante la dirección
que está dentro del servidor web. (15)
12
Según García (2008), estos sistemas web funcionan a través de un cliente-
servidor, excepto los que son basados por la web o navegador, que por lo
general éstas son accedidas por los clientes mediante el internet. (16)
Según Equipo Vértice (2009), un sistema web es la generación de páginas
consecutivas que se podrían definir como aplicación cliente y sus interfaces
sean soportadas por navegadores web. (17)
Ventajas
Según Mora (2001), los sistemas web contienen las siguientes ventajas: (18)
a) Los servidores externos e internos aparecen de forma integrada,
facilitando el uso y el aprendizaje.
b) Cada plataforma web es independiente de otras.
c) Solo se necesita tener acceso a internet y un navegador web, no es
necesaria la compra ni instalar herramientas aparte.
Desventajas
Según Mora (2001), contienen las siguientes desventajas (18):
a) La programación web no es potente como las tradicionales, aunque en la
actualidad las tecnologías que están apareciendo hace desaparecer este
tipo de desventaja.
b) Mayormente se necesita una conexión a la red para tener un buen
funcionamiento, si se interrumpe esta conexión, no se puede usar más.
13
Arquitectura
Según Talledo (2015), el Modelo Vista Controlador (MVC), es una arquitectura
de software en la cual se procede a dividir los datos de la aplicación, la vista o
interfaz del usuario y la lógica del control en tres componentes. (19)
Componentes
Tenemos estos componentes:
a) Modelo
En este componente se representa todos los requerimientos que el cliente
desea visualizar.
b) Vista
Es el componente encargado de transformar el modelo en una interfaz
donde el usuario pueda visualizar a través de un cualquier navegador web.
c) Controlador
Es el componente encargado de atender cualquier evento que se
produzca, mayormente se porta como comunicador entre los componentes
de modelo y vista, logrando ser un intermediario entre ambos
componentes.
Herramientas
Según Talledo (2015), en la actualidad existen una gran variedad de
aplicaciones o diseños integrados que permiten realizar estos sistemas en
entorno web, por eso hay que tener en cuenta que herramienta se va a usar,
buscar sus ventajas y desventajas correspondientes, ya que no se puede decir
14
cuál es mejor que el otro, entre estas herramientas tenemos (19)
a) XHTML: es un lenguaje HTML pero mostrado por XML, presente un nivel
técnico que realiza algún tipo de modificación o también en encontrar
errores de manera rápida y eficaz.
b) PHP: es un lenguaje de programación de lado del servidor, creado para
realizar contenido dinámico en el desarrollo de aplicaciones web.
c) JSP: Java Server Pages, presenta similitudes al lenguaje PHP, pero con
ciertas características propias de la misma herramienta.
d) ASP: Active Server Page, tecnología que se orienta al lado del servidor
para crear y desarrollar paginas dinámicas.
e) ORACLE: herramienta cliente-servidor para la gestión de base de datos.
Patrones de Diseño
Según Tedeschi (2013), son el esqueleto de las soluciones a problemas
comunes en el proceso del desarrollo del software.
Los patrones de diseño son soluciones ya documentadas y probadas a
diferentes problemas de desarrollo de software (20).
Los patrones se clasifican en:
a) Patrones de comportamiento
Comunican clases y objetos.
b) Patrones creacionales
Se inicializan y configuran objetos.
c) Patrones estructurales
15
Existe una agrupación de objetos y clases en lo cual forman una
estructura más grande.
Tipos de Sistemas Web
Existen dos tipos de sistemas web:
a) Estático
Según García (2008), dice que los sitios web que no acceden o guardan
información en la base de datos, en esta tipología de sitio web se puede
mostrar información de la empresa, pero estaa información se coloca en la
propia página web. (16)
b) Dinámico
Según García (2008), son sitios web que almacenan su propia base de
datos en el cual se muestra la información que esté recuperada de la base
de datos. (16)
Diseño de Sistemas Web
Según Mateu (2004), el lenguaje HTML (hypertext markup language) es
utilizado para crear documentos que enseñen una estructura de hipertexto. El
documento de hipertexto se refiere a aquel que tiene información cruzada con
otros documentos, lo que nos permite pasar de un documento al documento
referenciado desde la misma aplicación con la que estamos visualizando.
HTML permite, poder crear documentos del tipo multimedia, es decir que
almacenen información más allá de lo textual, como, por ejemplo:
- Imágenes
16
- Video
- Sonido
- Subprogramas activos (plug-ins, applets)
El lenguaje HTML no es el único lenguaje que está determinado para crear
documentos de hipertexto. Existen otros lenguajes anteriores o posteriores a
HTML (SGML, XML, etc.), aunque HTML se ha convertido en el lenguaje
estándar en la creación de contenido para Internet.
HTML Básico
Según la Universidad de Murcia (2015), los documentos HTML están
conformados de documentos de texto plano (sin ningún tipo de formateo
especial), en los que el formato del texto se determina mediante marcas de
texto (etiquetas, tags), que delimitan los contenidos a los que está afectada la
etiqueta (contamos con etiquetas de inicio y de final de marcado).
Las etiquetas o también llamados tags son marcas de texto en las que
empiezan por el carácter <, continuando con el nombre de la etiqueta,
atributos adicionales y terminan con el carácter >, de la forma, para las
etiquetas de inicio:
<ETIQUETA>
Luego están las que se forman con el carácter <, continuando del carácter /, y
seguido con el nombre de la etiqueta y terminan con el carácter >, en la forma,
para las etiquetas de final de marcado.
</ETIQUETA>
17
Las etiquetas no son sensibles a mayúsculas y/o minúsculas (son case-
insensitive).
Los atributos de las etiquetas, que son las que determinan parámetros
adicionales a la etiqueta, son incluidos en la etiqueta de inicio de la siguiente
forma:
<ETIQUETA ATRIBUTO ATRIBUTO ...>
La forma de estos atributos será el nombre del atributo o el nombre del
atributo, seguido de =, continuando con el valor que se le quiere asignar
(generalmente entrecomillado).
Cabe señalar que HTML permite omitir en ciertos casos la etiqueta de final si
la etiqueta no debe contener ningún texto al que le afecte, como es en el caso
de IMG. Otro punto a mecionar es si el cliente WWW que usemos (el
navegador concreto que estemos usando) no comprende alguna etiqueta, la
ignorará y hará de la misma forma con todo el texto que esté afectado por
ésta.
Estructura de los documentos HTML
Según Gauchat (2012), todos los documentos HTML tienen en comparación la
misma estructura. Todo el documento debe estar contenido en una sola
etiqueta HTML, dividiéndose en dos partes: la cabecera, que contiene una
etiqueta HEAD y el cuerpo del documento (donde se encuentra la información
del documento), que está cubierto por una etiqueta BODY. La cabecera debe
contener algunas definiciones sobre el documento: el título, marcas extra de
18
formato, palabras clave, etc.
Un primer ejemplo sería:
<HTML>
<HEAD>
<TITLE>Título del documento</TITLE>
</HEAD>
<BODY>
Texto del documento
</BODY>
</HTML>
Si abrimos un documento con el contenido anterior en el navegador podremos
apreciar que lo que están en las etiquetas TITLE no se puede ver en el
documento, pero el navegador las visualiza dentro de la barra de título de la
ventana.
Comentarios
En HTML se cuenta con la capacidad de añadir comentarios en la página con
las marcas <!--y --!>. El navegador ignora lo que contenga que se encuentre
entre estas dos marcas y no lo muestra al usuario.
I.3.2. Gestión de Incidencias
Según Bon, Jan, Arjen Jong, Axel Kolthof, Mike Pieper, Ruby y
TienekeVerheijen. Tjassing (2008), este proceso abarca todo problema
encontrado o tipo de incidencias, ya sean fallos, preguntas o consultas
planteadas por los usuarios o clientes finales. Según ITIL, define a una
incidencia como un problema no identificado que tiene un nivel de
impacto o una observación al nivel de calidad del servicio que se está
brindando. El fallo de un elemento de configuración que no haya
afectado todavía el servicio también se considera una incidencia. (21
19
pág. 13)
Para Bauset (2012), “gestiona las peticiones de servicios e incidentes.
El propósito es devolver la entrega del servicio a los niveles definidos
en la SLA tan rápido como sea posible”. (22 pág. 8)
Según The Stationery Office (2011), el objetivo es restaurar la falla del
servicio lo más rápido posible, de forma que su impacto sobre el
negocio sea mínimo. (23)
Otro de los objetivos es dar solución de la manera más eficaz ante
cualquier problema del servicio que se presente en el instante menos
pensado.
La gestión de incidencias tiene como objetivo resolver cualquier suceso
que cause una interrupción en el servicio de la manera más rápida y
eficaz posible.
Para Bon, Jan, Arjen Jong, Axel Kolthof, Mike Pieper, Ruby y
TienekeVerheijen. Tjassing (2008), lo más importante de este concepto
es realizar una solución rápida y así que el impacto sea mínimo posible
en los procesos de negocio. (21)
Ciclo de Vida
Según ITIL, se sigue el siguiente proceso:
a) Identificación:
Una incidencia no se empieza a gestionar hasta que se sabe que
existe. La organización tiene que intentar monitorizar todos los
componentes importantes, el cual los fallos reales o potenciales se
puedan verificar con tiempo y puede aplicarse un plan de
contingencia o solución al problema. (23)
20
b) Registro:
Todas las incidencias deben quedar registradas con todos sus datos,
independientemente si son recibidas a través de una llamada
telefónica del Service Desk, detectado automáticamente por un
sistema de monitorización de eventos. (23)
Todas las incidencias deben quedar registradas con todos sus datos,
incluyendo fecha y hora. Se debe registrar, como mínimo:
a. Un número de referencia.
b. La categoría del incidente.
c. La urgencia del incidente.
d. La prioridad del incidente.
e. El nombre y/o grupo que registró la incidencia.
f. Comentarios de la incidencia.
g. Las actividades realizadas para resolver la incidencia.
c) Clasificación:
Se deben utilizar los códigos apropiados de clasificación de
incidencias para registrar las diferentes incidencias que se puedan
suscitar. Esto será importante más adelante, cuando se analicen los
tipos y frecuencia de incidencias para identificar tendencias que se
puedan usar en otras actividades de la Gestión de Servicios de TI.
(23)
d) Priorización:
La priorización depende de la necesidad de la incidencia y el nivel de
impacto que causa en el negocio. (23)
21
Por lo tanto, cada registro de incidencias se debe acordar y asignar
un código de priorización adecuada para determinar la manera en
que la incidencia debe ser registrada y solucionada por los
trabajadores.
Esta priorización se puede estipular a partir de su:
a. Impacto: determina la importancia de la incidencia
dependiendo como ésta afecta a los usuarios finales y los
procesos o actividades del negocio.
b. Urgencia: depende del tiempo que demora en que el cliente
tiene para aceptar y dar las posibles soluciones al problema,
guiándose también del contrato definido de las SLAs.
e) Diagnóstico Inicial:
La mesa de ayuda debe tener apuntado todos los síntomas de la
incidencia para usarlo como primer diagnóstico. La información de
diagnóstico y la información de errores conocidos pueden ser
valiosos para permitir un diagnóstico temprano y preciso. (23)
f) Escalado:
En el escalado, en cuanto se hace evidente que en mesa de ayuda
no puede resolver la incidencia por sí mismo, […] la incidencia debe
ser escalada inmediatamente para solucionar el problema a un nivel
superior. (23)
Esto se puede realizar de dos maneras:
a. Escalado funcional: Si está claro que el Centro de Servicio
22
al Cliente no puede resolver (con la rapidez suficiente) la
incidencia, ésta debe ser escalada inmediatamente para
recibir un nivel de soporte más alto. Si la organización tiene
un grupo de segunda línea de soporte y el Centro de Servicio
al Cliente cree que ese grupo puede resolver la incidencia, se
envía la incidencia al nivel superior. Si se trata de un
problema que requiere de una solución más avanzada
entonces se escala al nivel superior inmediato.
b. Escalado Jerárquico: Los correspondientes gestores de TI
deben ser avisados de las incidencias más serias (de
prioridad 1, por ejemplo). También se utiliza el escalado
jerárquico si no se cuenta con los recursos adecuados para
resolver la incidencia. El escalado jerárquico consiste en ir
ascendiendo niveles en la empresa para que las personas
encargadas tengan conocimiento del problema y puedan
tener soluciones de contingencia, como asignar repuestos o
recurrir al apoyo de sus proveedores.
g) Investigación y diagnóstico:
Una incidencia reportada es probable que requiera algún grado de
investigación y diagnóstico. Cada uno de los grupos de apoyo que
participan en el manejo de incidencias investigará y diagnosticará lo
que ha salido mal. (23)
Cuando se trata de una incidencia, cada nivel del soporte que da a la
empresa busca lo que ha ocasionado el problema y realiza un
23
estudio de esta. Todas estas actividades deben quedar
documentadas en un registro de incidencias para disponer de una
imagen completa de las actividades realizadas.
Cuando el usuario solo está buscando información, el Centro de
Servicio al Cliente debe ser capaz de responder rápidamente y
resolver la petición de servicio.
h) Resolución y restauración:
Cuando una resolución potencial ha sido identificada, este debe ser
aplicado y probado. Las acciones específicas que deben realizarse y
las personas que van a participar en las acciones de recuperación
pueden variar. (23)
Usar una colección de información del conocimiento permitirá
obtener alternativas para solucionar la incidencia y poder restaurar el
servicio en un menor tiempo.
i) Cierre:
El Service Desk debe verificar que la incidencia está totalmente
resuelta y que los usuarios están satisfechos y dispuestos a aceptar
el cierre de la incidencia. (23)
La conformidad del cliente es una forma efectiva para evitar que las
incidencias sean reabiertas y se pueda cerrar adecuadamente, sin
prolongar por más tiempo la solución al problema registrado.
Beneficios y riesgos
Los principales beneficios de una correcta gestión de incidentes incluyen
(24):
24
- Mejorar la productividad de los usuarios.
- Mayor control de los procesos y monitorización del servicio.
- Optimización de los recursos disponibles.
- Mejora la satisfacción general de los usuarios finales.
Por otro lado, los riesgos que llevan una incorrecta gestión de
incidencias pueden ser:
a. Se derrochan valiosos recursos: demasiada gente o gente del
nivel inadecuado trabajando concurrentemente en la solución de
la incidencia.
b. Se pierde valiosa información sobre las causas y efectos de las
incidencias para futuras reestructuraciones y evoluciones.
c. Se crean clientes y usuarios insatisfechos por la mala y/o lenta
gestión de sus incidencias.
d. Reajustar de acuerdo a su nivel.
I.3.3. Acuerdos de Nivel de Servicio – SLA.
Los SLA consisten en un acuerdo entre el cliente final y los proveedores
con quienes trabajaran. El SLA nos indica de cómo va ser el contrato de
los servicios que se va a brindar al cliente, además de las
responsabilidades tanto del proveedor y del cliente final. Un único SLA
puede cubrir varios Servicios de TI o varios clientes. (23)
Por otro lado, el SLA debe recoger en un lenguaje no técnico, o cuando
menos comprensible para el cliente, todos los detalles de los servicios
brindados. (24)
25
Tras el acuerdo firmado, el contrato de la SLA debe tener en cuenta un
documento que indica la relación que hay entre el cliente final y el
proveedor, indicado los servicios que se van a brindar de manera clara
y definida en la documentación.
Atención al Usuario
A lo que se refiere sobre atención al usuario es aquel servicio brindado
por una empresa con la finalidad de relacionarse con los clientes y
solucionar sus problemas y satisfacer sus necesidades. Consiste en la
gestión que realiza cada trabajador de una empresa en contacto con el
cliente para brindar el asesoramiento y solución de calidad. (25)
I.3.4. Gestión del Nivel de Servicio (SLM)
Como parte de los Acuerdos de Nivel de Servicio (SLA), toda incidencia
debe ser resuelta dentro del tiempo acordado, la gestión de incidencias
permite que la SLM defina las medidas correspondientes que pueden
ser medibles para las incidencias.
Según Office of Government Commerce (2009) los cumplimientos de
los SLA se pueden medir en (23):
a. Porcentaje de Incidencias Asignadas
Según Office of Government Commerce (2009), es un conjunto
de datos mediante el cual se puede evidenciar el cumplimiento
de los SLA de asignación de tickets para la gestión de
incidencias.
%IAsig :CIAS/CTI
26
En donde:
%IAsig: % Incidencias asignadas.
CIAS: Cantidad de incidencias asignadas.
CTI: Cantidad total de incidencias.
b. Porcentaje de Incidencias Atendidas
Según Office of Government Commerce (2009), es un conjunto
de datos mediante el cual se documenta los detalles de la
incidencia desde su registro hasta su resolución.
%IAten :CIAS/CTI
En donde:
IAten: % Incidencias atendidas.
CIAS: Cantidad de incidencias atendidas.
CTI: Cantidad total de incidencias.
c. Tasa de Utilización del trabajo de Incidencias
Según Harold (2007), la tasa de utilización del trabajo en
incidencias es una medida que indica la cantidad de mano de
obra disponible utilizada para el manejo de incidencias. (26)
El presente indicador nos dará a conocer la capacidad del
personal para resolver las incidencias asignadas, tomando en
27
cuenta las horas que se invierte para la resolución de
incidencias.
HI
TTI = ∗100
HD
Dónde:
TTI: Tasa de Utilización del Trabajo en Incidencias.
HI: Horas de trabajo invertidas para resolver incidencias.
HD: Horas de trabajo disponibles para atender incidencias.
 Grado de satisfacción del usuario con la gestión de
incidencias.
En el presente indicador se verificará el grado de satisfacción
que tiene el usuario con respecto a la gestión de incidencias:
¿US
GSU =
TUE
Dónde:
GSU: Grado de satisfacción del usuario
#US: Número de usuarios satisfechos
TUE: Total de usuarios encuestados
I.3.5. Metodologías de desarrollo de Software
Proceso Unificado de Desarrollo (RUP)
Según Torossi, el proceso unificado es un proceso de desarrollo de
28
software: “conjunto de actividades necesarias para transformar los
requisitos del usuario en un sistema software”. RUP es un marco
genérico que puede especializarse para diversos tipos de sistemas,
organizaciones y tamaños de proyectos. RUP está basado en
componentes, el cual nos indica que el software está formado por
componentes software interconectados a través de las interfaces
realizadas. RUP está dirigido por diferentes componentes como casos
de uso, centrado en la arquitectura, es además iterativo y a la vez
incremental. Hay que tener en cuenta que el RUP a nivel comercial está
distribuido por Rational Software. (27)
Fases del RUP
La metodología RUP se divide en 4 fases (28):
- Inicio: la idea de esta fase es ver y entender cómo funciona el
negocio, además de verificar los procesos que formar parte de la
estructura para que la implementación sea más fácil de cualquier
software.
- Elaboración: en esta fase se realiza la comprensión del dominio
del problema, el cual se establece un marco de trabajo, el plan de
desarrollo del proyecto y se puede identificar los diferentes
riesgos del proyecto. El resultado que se busca en esta fase es
tener un modelo de requerimientos del sistema, además de la
arquitectura del sistema y un plan de desarrollo de software.
- Construcción: en esta fase se realiza el diseño, programación y
las pruebas del sistema, además que se realiza la integración de
29
todas las partes del sistema. El objetivo final de esta fase es tener
un software ya funcionando con su documentación realizar y lista
para el uso del usuario final.
- Transición: es la fase final en el cual se tendrá que instalar el
software desarrollado a un entorno real, el cual se busca como
objetivo final un sistema operativo y funcionando de manera
correcta y adecuada.
Metodología XP
La programación extrema o también conocida como Extreme
Programing, es un enfoque realizado que apunta a la ingeniería del
software formulado por Kent Beck, el cual es considerado el más
adecuado y destacado de los procesos ágiles del desarrollo de
software. (29)
La programación extrema se difiera de los demás ya que presenta más
énfasis en la forma de adaptabilidad que en la previsibilidad.
XP busca simplificar el desarrollo del software, además de reducir el
costo de los proyectos.
Extreme Programing apunta como objetivo potenciar las interrelaciones
dentro del equipo del proyecto a través del aprendizaje continuo, trabajo
en equipo y el buen clima de trabajo.
Esta metodología pone mucho énfasis en la retroalimentación continua
entre el cliente y el equipo de desarrollo, el cual es ideal para proyectos
con requisitos no bien definidos y sobre todo cambiantes.
Valores XP
30
Define un conjunto de valores que establecen el fundamento para todo
trabajo realizado como parte de XP. Cada uno de los siguientes valores
se usa como un motor para las actividades, acciones y tareas
específicas de XP. (30)
Características:
 Tiene una rápida respuesta a los cambios.
 Planificación flexible y abierta.
 Interacción constante entre el cliente y el equipo del proyecto.
 Software que funciona por encima de una buena documentación.
Roles en XP:
 Clientes: responsable de definir y conducir el proyecto, así como
sus objetivos.
 Programadores: programan el proyecto y realizan estimación de
tiempos de desarrollo por actividad.
 Coach: Guía y orienta al equipo.
 Tracker: Es el encargado de seguimiento.
 Tester: es el encargado de las pruebas cotidianas.
 Big Boss: es el gerente del proyecto, gestor del proyecto., es
aquel que tiene una idea general del proyecto.
Procesos de XP:
 Planeación
También llamada juego de planeación, el cual inicia escuchando
cada actividad para recabar requerimiento que permite que los
miembros técnicos de XP entiendan el contexto de negocio a
nivel de software.
31
Según Pressman, R (2000), escuchar lleva a la creación de
historias de usuarios, están son registradas por los
desarrolladores para realizar la modelación de los requisitos. (31)
En este proceso, tanto los desarrolladores y el clientes trabajan
en equipo para poder agrupar las historias de usuarios en la
siguiente entrega que desarrollara el equipo XP., una vez
acordada sobre la entrega el cual abarca la fecha de entrega, las
historias de usuario a incluir y otros aspectos del proyecto, el
equipo ordena las historias que serán desarrolladas en sus tres
formas:
A medida que se avanza en el desarrollo del proyecto, el cliente
puede ir agregando historias, cambiar el valor de una historia ya
existente, descomponer o eliminarlas. Entonces el equipo del
proyecto XP reconsidera todas las entregas faltantes y modifica
los planes de consecuencia.
 Diseño
Un diseño sencillo siempre se prefiere sobre una representación
más compleja. Este proceso guía la implementación de una
historia conforme ha sido descrita por el cliente.
Según Pressman, R (2010), la metodología XP estimula el uso
de tarjetas CRC como un mecanismo eficaz para pensar en el
software en un contexto orientado a objetos. Las tarjetas CRC
(clase, responsabilidad, colaborador), identifican y organizan las
clases orientadas a objetos que son relevantes para el
incremento actual del software. Estas tarjetas CRC son el único
32
producto del trabajo de diseño que se genera como parte del
proceso de la metodología XP. (31)
 Codificación
Según López, P y Francisco, R. (s/f), un concepto clave durante
la actividad de codificación es la programación en parejas. La
metodología XP recomienda que dos personas trabajen juntas en
una estación con el objetivo de crear código para una historia de
usuario. A medida que las parejas de programadores terminan su
trabajo, el código que desarrollan se va integrando con el trabajo
de los demás. En algunos casos, esto se lleva a diario por parte
de un equipo de integración, en otros la misma pareja
programada tiene la responsabilidad de realizar la integración.
Esta estrategia de integración continua ayuda a evitar los
problemas de compatibilidad de interfaces y brinda un ambiente
que ayuda a descubrir a tiempo los errores. (30)
 Pruebas
La creación de pruebas unitarias antes de que comience la
codificación es un elemento clave en la metodología XP, ya que
esta asegura la calidad del software.
Continuamente se han de efectuar una serie
de pruebas automatizadas en base a los requisitos del cliente
para comprobar que todo funcione correctamente. Éstas han de
hacerse de forma periódica y automática.
33
Herramientas
 Historias de Usuarios: no da un breve concepto del
comportamiento del sistema y son usadas para cumplir con el
tiempo estimado y el plan de lanzamientos.
 Tareas de Ingeniería: describen las actividades o trabajos que
deben realizar en cada historia del usuario, esta fase está
vinculada al programador ya que va de la mano del código del
software a desarrollar.
 Pruebas de Aceptación: Es de vital importancia para el éxito de
una iteración y el comiendo de la siguiente iteración, por lo cual
el cliente puede conocer como están avanzando el sistema y
además el desarrollar podrá saber lo que le falta hacer. Esta fase
también es conocida como las pruebas de cliente. (32)
 Tarjetas CRC: permite conocer todas las clases que componen
los sistemas y cuales interactúan entre sí, se dividen en tres
secciones: Nombre de la clase, responsabilidades y
colaboradores. (32)
Metodología Scrum
Esta metodología está diseñada para proyectos que realicen diferentes
cambios de requisitos en el momento que se requiera.
Una de sus principales características es que se usa el sprint para
realizar las iteraciones con una duración de 30 días, el cual cada sprint
tiene un resultado que es un incremento ejecutable que se muestra al
cliente final y la otra característica importante son las reuniones que se
34
debe realizar a lo largo que dura el proyecto. (33)
Con esta metodología el cliente se entusiasma y se compromete con el
proyecto ya que lo vera crecer iteración a iteración. Asimismo, le
permite en cualquier momento realinear el software con los objetivos de
negocio de su empresa, ya que puede registrar cambios funcionales o
de prioridad en el inicio de cada nueva iteración sin ningún problema.
Usar esta metodología nos da los siguientes beneficios:
a. Cumplimiento de expectativas.
b. Predicciones de tiempos.
c. Reducción de riesgos.
d. Mayor productividad.
e. Mayor calidad de software.
f. Flexibilidad a cambios.
g. Maximiza el retorno de la inversión (ROI).
Según Arteaga Herrera, Sergio (2017), la metodología Scrum tiene
ventajas y desventajas (34)
Ventajas
a. Se puede enviar los entregables al cliente mientras se va
desarrollando los objetivos más sencillos, eso hace ganar tiempo
para luego desarrollos los objetivos más complejos.
b. El Scrum Master tiene los conocimientos necesarios para lograr
los objetivos primarios y secundarios por lo cual puede ir
controlando el proyecto y asignando roles.
c. Cada persona que tiene asignado un rol, sabe lo que tiene que
35
hacer y no es necesario ir reorganizando nuevamente los tracks
por cada persona.
d. Se involucra desde un principio y se da un rol a cada persona
que va a participar en el proyecto y también se incluye el cliente
final.
Desventajas
a. Si una persona renuncia o hay algún cambio, es complicado
reemplazar el rol asignado a esa persona que se lleva el
conocimiento específico y afecta a todo el proyecto.
b. Algunos miembros del equipo pueden realizar saltos importantes
en el camino rápido para llegar al sprint final.
c. Demasiadas reuniones para poco avance del proyecto, algunos
van perdiendo interés en el proyecto.
d. El cliente siempre espera los avances e informes en la fecha
exacta, y en algunos casos lo pide antes de la fecha, cuando aún
no se ha avanzado nada del proyecto.
Procesos de la Metodología SCRUM
El proceso se desarrolla en forma iterativa e incremental. Cada
iteración, denominada Sprint, tiene una duración preestablecida entre 2
y 4 semanas, obteniendo como resultado una versión del software con
nuevas prestaciones listas para ser usadas. En cada nuevo sprint, se va
ajustando la funcionalidad ya construida y se añaden nuevas
prestaciones priorizándose siempre aquellas que aporten mayor valor
36
de negocio. (35)
Dentro de los procesos tenemos:
a. Product Backlog
Conjunto de requisitos denominados historias descritos en un
lenguaje no técnico y priorizados por valor de negocio. Los
requisitos y prioridades se revisan y ajustan durante el curso del
proyecto e intervalos regulares.
b. Sprint Planning
Reunión que el Product Owner presenta las historias de backlog
por orden de prioridad. El equipo del proyecto determina la
cantidad de historias que puede comprometerse a completar en
ese sprint, para en una segunda parte de la reunión, decidir y
organizar como lo va a conseguir.
c. Sprint
Es la iteración de duración prefijada durante la cual el equipo
trabaja para convertir las historias del Product Backlog a las que
se ha comprometido, en una nueva versión del software
totalmente operativo.
d. Sprint Backlog
Lista de tareas necesarias para llevar a cabos las historias del
sprint.
e. Daily Sprint meeting
Reunión diaria que se da como máximo 15 minutos, en la que el
equipo se sincroniza para trabajar de forma coordinada. Cada
miembro comenta que hizo el día anterior, que hará hoy y si hay
37
impedimentos.
f. Demo y retrospectiva
Reunión que se celebra al final del sprint y en la que el equipo
presenta las historias conseguidas mediante una demostración
del producto.
Roles
En la metodología Scrum, el equipo se focaliza en construir software de
calidad. La gestión de un proyecto Scrum se centra en definir cuáles
son las características que debe tener el producto a construir y vencer
cualquier obstáculo que pudiera entorpecer la tarea del equipo de
desarrollo. (35)
Está formado por los siguientes roles:
 Scrum Master
Persona que lidera al equipo guiándolo para que cumpla las
reglas y procesos de la metodología. Gestiona la reducción de
impedimentos del proyecto y trabaja con el Product Owner para
maximizar el ROI
 Product Owner (PO)
Representante de lso accionistas y clientes que usan el software.
Se focaliza en la parte de negocio y el es responsable del ROI
del proyecto (entregar un valor superior al dinero invertido).
Traslada la visión del proyecto al equipo, formaliza las
prestaciones en historias a incorporar en el Product Backlog y las
reprioriza de forma regular.
38
 Team
Grupo de profesionales con los conocimientos técnicos
necesarios y que desarrollan el proyecto de manera conjunta
llevando a cabo las historias a las que se comprometen al inicio
de cada sprint.
Etapas de la Metodología SCRUM
a. Planificación del Sprint
Sprint: es como un proyecto menor dentro del proyecto principal,
el cual cada uno de ellos contienen un objetivo en particular.
En la primera reunión que se realiza con el equipo se definen
aspectos como la funcionalidad, objetivos, los riesgos que tienen
los sprints, plazos de entregas u otros temas. Posteriormente se
realizará una junta entre el equipo y el jefe del proyecto para
explicar cómo se irá desarrollando cada punto para lograr los
objetivos.
Se definen la toma de decisiones, mejoras y se evalúan los
cambios, etc.
b. Etapa de Desarrollo
Cuando el desarrollo de sprint está en pleno curso, los
encargados deben garantizar que no se generaran cambios de
último momento ya que pueden afectar los objetivos del mismo
sprint, además de esto se debe asegurar el cumplimiento de los
plazos establecidos en los términos del contrato.
c. Revisión del Sprint
Al final del desarrollo de cada sprint, es posible analizar y evaluar
39
los resultados. Acá todo el equipo de proyecto puede participar
para saber qué aspectos necesitan ser cambiados.
En esta etapa se fomenta la colaboración y retroalimentación
entre todos los participantes del proyecto.
d. Retroalimentación
En esta etapa, los resultados pueden ser entregados para dar el
visto bueno por parte del jefe del proyecto y también por parte de
las personas que utilizaran directamente lo que se desea lograr,
ósea los clientes finales.
Tabla N° 01: Cuadro Comparativo de Metodologías
Metodología Descripción Características
Marco de trabajo  El proceso de
genérico que puede desarrollo es más
especializarse para una detallado.
gran variedad de  Se realiza una
sistemas software, para definición de
diferentes áreas de arquitectura,
aplicación, diferentes diseño visual y se

Proceso
tipos de organizaciones, utiliza herramientas
Unificado de
diferentes niveles de para el desarrollo
Software (RUP)
aptitudes y diferentes del software.
tamaños de proyecto.
Es una metodología ágil  No necesita
40
para el desarrollo de documentación.
software de manera  Iteraciones son

Extreme eficiente y altamente más cortas.
Programing (XP) efectivo.  Los requerimientos
pueden ser
cambiados.
Scrum Metodología está  Se realiza un
diseñada para seguimiento del
proyectos que realicen proceso de
diferentes cambios de desarrollo.
requisitos en el  Los requerimientos
momento que se realizados ya no
requiera. pueden ser
cambiados.
 Se orienta a la
realización de una
planeación
iterativa.
Fuente: Elaboración propia.
I.4. Formulación del Problema
¿La implementación de un sistema web optimizará gestión de incidencias del área
de TI de la empresa Belcorp?
41
I.4.1. Problemas específicos
a) ¿Cómo influye el sistema web en el control de incidencias
asignadas de la Empresa Belcorp, 2019?
b) ¿Cómo influye el sistema web en la atención de incidencias
en el área de TI de la Empresa Belcorp, 2019?
c) ¿Cómo influye el sistema web en la capacidad del personal
para resolver las incidencias asignadas de la de la Empresa
Belcorp, 2019?
d) ¿Cómo influye el sistema web en satisfacción del usuario
frente al uso de los servicios de TI de la Empresa Belcorp,
2019?
I.5. Justificación de estudio
I.5.1. Justificación Tecnológica:
La implementación del sistema web para la gestión de
incidencias del área de TI de la empresa Belcorp, generará uso
de herramientas informáticas y conocimientos teóricos, para
obtener un sistema de calidad que permita resolver los
problemas de la entidad.
I.5.2. Justificación Económica:
El estudio se enfoca en la implementación de un sistema web
que corrobora en minimizar ciertos costos que afecten la
rentabilidad de la empresa, lo cual permitirá acrecentar las
42
utilidades de la mismas para continuar con el crecimiento de la
empresa en el rubro involucrado.
I.5.3. Justificación Social:
La finalidad del estudio concierne a la implementación de un
sistema web que pretende reducir el nivel de incidencias
derivadas del servicio de tecnología de información, a fin de
beneficiar a los clientes, trabajadores y a la misma empresa,
pues se encamina a conceder un control preventivo a los
ordenadores para prescindir de complicaciones que afecten en
demasía la continuidad de las actividades empresariales como
su competitividad ante entidades rivales.
I.6. Hipótesis
I.6.1. Hipótesis General:
La implementación de un sistema web optimizará la gestión de
incidencias del área de TI de la empresa Belcorp, 2019.
I.6.2. Hipótesis Específicas:
a) El sistema web influye de manera negativa en la gestión de
incidencias asignadas de la Empresa Belcorp, 2019.
b) El sistema web influye de manera negativa en la atención de
incidencias en el área de TI de la Empresa Belcorp, 2019.
c) El sistema web influye de manera negativa en la capacidad de
personal para la atención de incidencias de la Empresa
43
Belcorp, 2019.
d) El sistema web influye de manera negativa en la satisfacción
de los clientes respecto al uso de los servicios de TI de la
Empresa Belcorp, 2019.
I.7. Objetivos
I.7.1. Objetivo General:
Implementar un sistema web para la gestión de incidencias del
área de TI de la empresa Belcorp, 2019.
I.7.2. Objetivos Específicos:
a) Diagnosticar la efectividad de las herramientas informáticas
empleadas en el control de ordenadores como servicios de la
b) Analizar la gestión de incidencias producidas en el área de TI
de la Empresa Belcorp, 2019.
c) Diseño de un sistema web para la gestión de incidencias del
área de TI de la Empresa Belcorp, 2019.
d) Evaluar el costo - beneficio de la implementación de un sistema
web para la gestión de incidencias del área de TI de la
44
II. MÉTODO
II.1. Diseño de investigación
II.1.1. Tipo de Estudio
Según Rodríguez la investigación aplicada es el tipo en el cual el
problema está establecido y es conocido por el investigador, por
lo que se utiliza la investigación para dar respuesta a preguntas
específicas, (36) por esa razón esta investigación Tipo Aplicada.
II.1.2. Diseño de Estudio
Según Hernández, Fernández y Baptista, manifiestan que el
diseño Pre-Experimental administra un estímulo o tratamiento a
un determinado grupo, para después aplicar una medición de una
o más variables, con el fin de observar cual es el nivel del grupo
en éstas. En ciertas ocasiones los diseños pre-experimentales
sirven como estudios exploratorios, pero sus resultados deben
observarse con precaución. (37)
Se utilizará el diseño Pre-Experimental, puesto que se desea
implementar un sistema web para la gestión de incidencias del
área de TI de la empresa Belcorp, 2019., realizando un Pre-test y
Post –Test.
45
G O1 X O2
Figura 1. Diseño de estudio

Fuente: Hernández, Fernández y Baptista, 2014
G: Muestra
O1: Observación Pre-Test.
X: Sistema web
O2: Observación Post-Test
II.2. Variables, operacionalización
II.2.1. Definición Conceptual
Variable Independiente (VI): Sistema Web
Según Aguilar y Dávila (2013), un sistema web es una
herramienta que emplea la arquitectura cliente-servidor,
accediendo mediante la dirección que está dentro del servidor
web. (15)
Variable Dependiente (VD): Gestión de Incidencias
Según ITIL, un incidente concierne a una interrupción no planeada
del servicio o una falla del componente de un servicio que todavía
no ha impactado a este. Respecto a la gestión de incidencias se
conceptúa como un desarrollo que se encarga de brindar la
confianza, seguridad y garantía de los métodos adecuados y
estandarizados para una gestión o control continuo sobre los
incidentes presentados manejándose de manera efectiva.
46
II.2.2. Definición Operacional
Variable Independiente (VI): Sistema Web
Un sistema web posee un nivel interno que permite cualquier
cambio en cualquiera de sus subsistemas e incluso en el mismo
sistema, por lo cual permite obtener mejores resultados.
Variable Dependiente (VD): Gestión de Incidencias
Es aquella transformación que permite controlar que todas las
incidencias reportadas por los usuarios, sean asignadas de
manera correcta y resueltas cumpliendo con los reglamentos o
parámetros que maneja la empresa para mantener el servicio
disponible
47
Tabla Nº02: Cuadro de operacionalización de variables
Variables Definición conceptual Definición operacional Dimensiones Indicadores Instrumentos
Según Aguilar y Dávila Posee un nivel interno
Variable (2013), un sistema web que permite cualquier
independiente: es una herramienta que cambio en cualquiera de
Sistema Web emplea la arquitectura sus subsistemas e
cliente-servidor, incluso en el mismo
accediendo mediante la sistema, por lo cual
dirección que está permite obtener mejores
dentro del servidor web. resultados.
(15)
Según ITIL, “un Transformación que Porcentaje de Ficha de
Variable incidente un incidente permite controlar todas Nivel de Servicio incidencias asignadas Registros
dependiente: es una interrupción no las incidencias (SLA) %IAsig :CIAS/CTI
Gestión de planeada del servicio o reportadas, asignadas y Porcentaje de Ficha de
48
Incidencias. una falla del resueltas cumpliendo con incidencias atendidas Registros
componente de un los reglamentos o

%IAten :CIAS/CTI
servicio que todavía no parámetros que maneja
Porcentaje de utilización
ha impactado a este”. la empresa.
del trabajo en Ficha de
Aumentar la
Restauración incidencias. Registros.
satisfacción de los
HI
TTI = ∗100
usuarios respecto al HD
servicio de atención y
Grado de satisfacción
solución de incidencias.
Servicio del usuario con la Encuesta
gestión de incidencias.
GSU =¿ US/TUE
49
II.3. Población y muestra
II.3.1. Población
La presente investigación se desarrollará en el área de Tecnología de
Investigación (TI) de la empresa Belcorp, para ello se considerarán las 7
personas que son encargadas de la gestión de incidencias, además 6
torres de especialistas para la solución de las incidencias, en las cuales
hay un aproximado de 3 personas por torre.
- Población de las incidencias: 12000 incidencias en TI por mes.
- Población de las consultoras Belcorp: 1000 consultoras a nivel
nacional.
II.3.2. Muestra
En la presente investigación se considerará como muestra a toda la
población de estudio, ya que ésta es muy pequeña, se trabajará con las
7 personas que gestionan las incidencias y las 6 torres de especialistas
para la solución de las incidencias, como son ORACLE, SAP, AWS,
ONPREMISE, BACKUP/STG, NETWORKING, existiendo 3 personas
aproximadamente por torre.
Para el cálculo de la muestra, se utilizó la fórmula de cálculo de muestra
para poblaciones finitas, la cuál es la siguiente:
2
N∗Z α p∗q
n= 2 2
d ∗( N−1 ) + Z α∗p∗q
Donde:
50
- N= Total de la población
- Zα= 1,96 al cuadrado
- p= proporción esperada (en este caso 50% =0,5)
- q= 1-p ( en este caso 1-0,5 = 0,5 )
- d= precisión ( en la investigación se usa un 5%)
En base a ello, se calculó una muestra para las incidencias y para las
consultoras de Belcorp Perú:
- Cálculo de muestra de incidencias:
2
12000∗1,96 ∗0,5∗0,5
n= 2 2
=372
0,05 ∗( 1200−1 )+1,96 ∗0,5∗0,5
- Cálculo de muestra de consultoras:
2
1000∗1,96 ∗0,5∗0,5
n= 2 2
=278
0,05 ∗( 100−1 )+1,96 ∗0,5∗0,5
II.3.3. Muestreo
Para la investigación se hará uso de un muestreo aleatorio simple;
según Ochoa (2015), es la técnica de muestreo en la que todos los
elementos que forman el universo y que están descritos en el marco
muestral, tienen idéntica probabilidad de ser seleccionados para la
muestra. (38)
51
II.4. Técnicas e instrumentos de recolección de datos, validez y
confiabilidad.
II.4.1. Técnica
En esta investigación se hará uso de un análisis documental;
según Corral (2015), el análisis documental se refiere al estudio
de un documento, independientemente de su soporte, ya sea
visual o escrito. (39)
Es por ello que el investigador hará uso de los tickets de
incidencias que reporta la herramienta JIRA.
Así mismo se hará uso también de la técnica de la encuesta, ya
que según De Aguiar (2016), menciona que la encuesta es una
técnica que consiste en obtener información acerca de una parte
de la población o muestra mediante el uso del cuestionario o de la
entrevista. (40)
II.4.2. Instrumento
Se trabajará con una guía de análisis documental donde se
registrará información de las incidencias que reporta la empresa
Belcorp.
Se hará uso de un cuestionario que será aplicado a los
encargados de la gestión de incidencias de la Empresa Belcorp;
según Ramos (2008), el cuestionario es un instrumento básico de
la elaboración en la encuesta y en la entrevista, puesto que se
52
formula una serie de preguntas que permiten medir una o más
variables. (41)
II.4.3. Validez y confiabilidad
Validez
En la presente investigación, se realizará la validez por contenido
ya que el instrumento será evaluado por 3 expertos, los cuales
harán sus aportes a la investigación y de la mano se verificarán si
el contenido del instrumento se ajusta a los objetivos de estudio
planteados.
Confiabilidad
Para fines de la investigación se hará uso del método Test- Re
Test, puesto que Oyoqui (2014) manifiesta que este método
consiste en administrar un estudio en dos oportunidades a la
misma muestra de sujetos, con un determinado intervalo entre las
dos administraciones, y calcular la correlación entre los puntajes
obtenidos en la primera y segunda evaluación. (42)
Por otro lado, se aplicará el Alfa de Cronbach al cuestionario que
será aplicado al área comercial; según Mendoza (2018) el Alfa de
Cronbach da una medida de la consistencia interna que tienen los
reactivos que forman una escala, puesto que, si esta medida es
alta, suponemos que los ítems están apuntando en la misma
53
dirección, es por esto, que el Alfa de Cronbach suele interpretarse
como una medida de unidimensionalidad de una escala, por tanto,
de que estamos midiendo de manera consistente algo con ella.
(43)
Aplicando el Alfa de Cronbach, se tomó una muestra piloto de 30
clientes. Mediante lo cual resultan las siguientes tablas.
Tabla Nº03: Resumen de procesamiento de casos
CASOS N %
Válido 30 100,0
Excluido 0 0,0
Total 30 100,0
Elaboración Propia.
Tabla Nº04: Estadísticas de fiabilidad
Alfa de Cronbach N de elementos
0,846 8
Elaboración Propia.
De acuerdo a los resultados obtenidos en el análisis de
confiabilidad, el alfa de Cronbach es 0.886 que es un valor que es
próximo a la unidad y que es superior a 0.60; por lo tanto,
podemos concluir diciendo que el instrumento para calidad de
servicio es confiable y que va producir resultados consistentes y
coherentes.
54
II.5. Métodos de análisis de datos.
En la presente investigación se utilizará el método de análisis de datos
cuantitativo, ya que es una investigación Pre-Experimental y puede
realizarse un análisis estadístico para comprobar la hipótesis
planteada.
En esta investigación se busca comparar los resultados actuales (Pre-
Test), con los resultados obtenidos después de implementar el sistema
web (Post-Test) mediante el contraste de las hipótesis planteadas para
tomar la decisión de “Aceptarlas o Rechazarlas”.
Prueba de Normalidad
Según Moriña, Utzet, Nedel, Martin y Navarro (2016), indicaron que
dentro de las pruebas de normalidad más utilizadas para comprobar la
normalidad está la prueba Kolgomorov-Smirnov (K-S), que es un test
genérico para evaluar la bondad del ajuste de unos datos a una
distribución concreta normal u otra. En el caso de la normalidad, se
recomendó el uso del test de Shapiro Wilk para muestras pequeñas
menores o iguales a 50 y el uso preferente del test de Kolgomorov-
Smirnov (K-S) cuando se dispone de un número mayor de
observaciones, así se pudo determinar si se aceptaba o se rechazaba
la muestra que se ha seleccionado para el estudio.
Si n>50 = Prueba de Kolgomorov-Smirnov (K-S)
Si n<50 = Prueba de Shapiro Wilk
Las pruebas se realizarán introduciendo los datos del Pre-Test y Post-
55
Test de cada indicador al software estadístico SPSS versión 22, con las
siguientes condiciones:
Si: Sig. < 0.05 = Adopta una distribución no normal
Si: Sig. >= 0.05 = Adopta una distribución normal (44)
II.6. Aspectos éticos.
La presente investigación se regirá en los siguientes principios éticos:
Discrecionalidad
En la investigación se reservará la identidad de los individuos y de los
objetos que participen en el estudio.
Neutralidad
Se busca la equidad durante el desarrollo de la investigación, es por
ello que no se busca beneficiar a ningún sujeto o grupo.
Confidencialidad
La investigación se realizará con fines académicos, es por ello que el
autor se compromete a respetar la veracidad de los datos y la
confiabilidad de ellos, los cuales serán brindados por la empresa
Belcop.
Respeto
Se cumplirá con el respeto a la propiedad intelectual y los horarios de
trabajo. Se citó a los autores que se utilizaron en este estudio,
haciendo uso de las normas ISO 690; los cuales fueron de gran ayuda
para el desarrollo de la presente investigación.
56
Autenticidad
La investigación muestra un enfoque original, ya que se empleará una
metodología innovadora para diseñar e implementar un sistema web
para el proceso de control de incidencias en el área de TI de la
empresa Belcorp, 2019.
57
Bibliografía
1. Valeriano, Y. Aplicación web de gestión de incidencias basado en ITIL para mejorar el servicio
de soporte técnico de TI en la empresa CISESAC. Ingeniería de sistemas, Universidad . Chimbote :
2017, 2017.
2. Cascado Caballero, Daniel y Yáñez Gómez, Rosa. Configuración, Implementación y
Mantenimiento de ssitemas informáticos. [En línea] 2016. https://rodas5.us.es/file/51cd89cb-
a495-4525-a65c-f006ce97e774/2/Tema1CIMSI.pdf.
3. Portal del estado peruano. [En línea] Octubre de 2015. https://www.peru.gob.pe/.
4. Jiménez Rodríguez, Sara. Diseño de un Sistema de Gestión y Análisis de Incidencias.
Departamento de Ingeniería de Telemática, Universidad Carlos III de Madrid. Madrid : s.n., 2014.
pág. 161, Tesis de pregrado.
5. Tarazona Nieto, Diego Eusebio. Desarrollo e Implementación de un Sistema Integrado de
Gestión de Incidencias y Entrega de documentos para la empresa ELECTROCENTRO S.A. 2017.
Facultad de Ingeniería y de Sistemas, Universidad Nacional Hermilio Valdizán. Huánuco : s.n.,
2017. pág. 144, Tesis de pregrado.
6. Altamirano, J. Desarrollo de un Sistema de Información haciendo uso de la Metodología XP
para la Gestión de Ventas, Compras y Almacén de la Empresa Agro Market Peru S.A.C.
Lambayeque : Universidad Nacional Pedro Ruíz Gallo, 2017.
7. Vásquez Samán, Edgar David. Sistema experto para el proceso de gestión de incidentes de TI en
la empresa Talma Servcios Aeroportuarios S.A. Facultad de Ingeniería, Universidad césar Vallejo.
Lima : s.n., 2017. pág. 153, Tesis de pregrado.
8. Huaman Varas, Joselyn Bonnie y Huayanga Quispe, Carlos. Desarrollo e Implementación de un
Sistema de Información para mejorar los procesos de compras y ventas en la Empresa Humaju.
Facultad de Ingeniería y Aquitectura, Universidad Autónoma del Perú. Lima : s.n., 2017. pág. 162,
Tesis de pregrado.
9. Zegarra Lozada, Jorge Alberto. Sistema informático para la gestión de incidencias en la
empresa Terronorte S.A.C. Facultad de Ingeniería, Universidad César Vallejo. Lima : s.n., 2016. pág.
130, Tesis de pregrado.
10. Alfaro Mendoza, Luis Alfonso y Paucar Moreya, Daphané Aurelia. Construcción de un
Datamart que apoye en la toma de decisiones de la gestión de incidencias en una mesa de ayuda:
caso Consorcio Peruana de Empresas. Facultad de Sistema e Informática, Universidad Nacional
Mayor de San Marcos. Lima : s.n., 2016. pág. 155, Tesis de pregrado.
11. Santisteban Necochea, Idelma Chabuca. Sistema informático para la gestión de incidencias en
ENTERPRISE SOLUTIONS DEVELOPMENT S.A.C. Facultad de Ingeniería, Universidad César Vallejo.
Lima : s.n., 2016. Tesis de pregrado.
12. Gonzáles López, Carlos Moisés. Desarrollo e Implementación de un Sistema de Información
para el control del proceso de capacitación de una empresa del rubro de las telecomunicaciones
en el Perú. Facultad de Ingeniería, Universidad Católica Sedes Sapientiae. Lima : s.n., 2016. pág.
145, Tesis de pregrado.
13. Loaysa Uyehara, Alexander Alberto. Modelo de gestión de incidentes, aplicando ITIL v30. en
un organismo del Estado Peruano. Ingeniería de Sistemas, Universidad de Lima. Lima : s.n., 2015.
14. VILLORIA, Liliana Noemi y CAIVANO, Romina Marcela. Aplicaciones web 2.0. Argentina -
Eduvim : Universitaria Villa María, 2012.
15. AGUILAR, Eduardo y DÁVILA, David. Análisis, diseño e implementación de la aplicación web
para el manejo del distributivo de la Facultad de Ingeniería. Cuenca - Ecuador : s.n., 2013.
58
16. García, Anthony. Managing Information System Through Information Technology. Manila: Rex
Book Store. 2008. 9789712350733.
17. Vértice, Equipo. Técnicas avanzadas de diseño web. España : Publicaciones Vértice S.L., 2009.
99978-89-9931-124-1.
18. Sergio, Mora Luján. Programación de servidores web con CGI, SSI e IDC. Alicante : Club
Universitario, 2003. 84-8454-136-3.
19. Talledo, José. Implantación de aplicaciones web en entornos internet, intranet y extranet.
2015.
20. Tedeshi, Nicolás. ¿Qué es un Patrón de Diseño? MSDN. [En línea] 2013. [Citado el: 25 de 5 de
2019.] https://moodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/04/Patron_de_diseno.pdf.
21. Bon, Jan, Arjen Jong, Axel Kolthof, Mike Pieper, Ruby y TienekeVerheijen. Tjassing.
Fundamentos de a Gestión de Servicios de TI basada en ITIL. Holanda : Van Haren Publishing,
2008.
22. Bauset Carbonell, María del Carmen. Modelo de aporte de valor de la implantación de un
sistema de gestión de servicios de TI (SGSIT), basado en los re, Tesis (Doctorado en Organización
de Empresas). Valencia : s.n., 201.
23. Office, The Stationery. ITIL Service Operation. ITIL Service Operation. [En línea] 2011. [Citado
el: 18 de 5 de 2019.] http://www.kornev-online.net/ITIL/04%20-%20ITIL
%20V3%202011%20Service%20Operation%20SO.pdf. 9780113313075.
24. Guzmán, Eugenio. Gestión de Incidencias. [En línea] 20 de 11 de 2014. [Citado el: 16 de 5 de
2019.] https://eualblog.wordpress.com/2014/11/20/gestion-de-incidencias/.
25. Porporatto, Mónica. Atención al Cliente. [En línea] 09 de 06 de 2015. [Citado el: 31 de 05 de
2019.] https://quesignificado.com/atencion-al-cliente/.
26. Herold, Rebecca. The Shortcut Guide To Improving IT Service Support Through ITIL. Estados
Unidos : Realtime Publishers, 2007. 9781931491747.
27. Torossi, A.U.S. Gustavo. El proceso Unificado de Desarrollo de Software. Diseño de Sistemas.
[En línea] http://dsc.itmorelia.edu.mx/~jcolivares/courses/pm10a/rup.pdf.
28. Sommerville, Ian. Ingeniería del software. 7a. ed. Madrid, España : s.n., 2005.
9788478290741.
29. Bautista Q, J. M. Programación Extrema XP. Bolivia : s.n., 2012.
30. Cevallos, Karla. Ingenieria del Software. Metodología de Desarrollo Ágil: XP y Scrum. [En línea]
08 de 05 de 2015. [Citado el: 15 de 05 de 2019.]
https://ingsotfwarekarlacevallos.wordpress.com/2015/05/08/metodologia-de-desarrollo-agil-xp-
y-scrum/.
31. Pressman, R. Ingeniería de Software - Un enfoque práctico. Connecticut. Estados Unidos de
Norteamérica : McGrawHill, 2010.
32. Chiluisa Pallo, A. P., & Loarte Cajamarca, B. G. Desarrollo e Implantación del Sistema de
Control de Inventarios y Gestión de Laboratorios para la Facultad de Ciencias de la Escuela
Politécnica Nacional. Quito : s.n., 2014.
33. Orjuela Duarte, A., & Rojas C, M. Las Metodologías de desarrollo Ágil como una oportunidad
para la Ingeniería del software educativo. Las Metodologías de desarrollo Ágil como una
oportunidad para la Ingeniería del software educativo. [En línea] 24 de 05 de 2008. [Citado el: 20
de 05 de 2019.] http://www.bdigital.unal.edu.co/15430/1/10037-18216-1-PB.pdf.
34. Arteaga Herrera, Sergio. Quora. ¿Cuáles son las ventajas y desventajas de agile/scrum? [En
línea] 14 de 03 de 2017. [Citado el: 25 de 05 de 2019.] https://es.quora.com/Cu%C3%A1les-son-
las-ventajas-y-desventajas-de-agile-scrum.
35. SOFTENG. SOFTENG. The internet development company. [En línea] [Citado el: 27 de 05 de
2019.] https://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologia-scrum/
proceso-roles-de-scrum.html.
36. Rodríguez, Daniela. lifider.com. [En línea] [Citado el: 10 de Mayo de 2019.]
https://www.lifeder.com/investigacion-aplicada/.
59
37. Hernández Sampieri, Roberto, Fernández Collado, Carlos y Baptista Lucio, María del Pilar.
Metodología de la Investigación. Sexta. México : MeGRAW-HILL / INTERAMERICANA EDITORES,
S.A. DE C.V. , 2014. pág. 634. ISBN: 978-1-4562-2396-0.
38. Ochoa, Carlos. netquest. [En línea] 8 de Abril de 2015. [Citado el: 10 de Mayo de 2019.]
https://www.netquest.com/blog/es/blog/es/muestreo-probabilistico-muestreo-aleatorio-simple.
39. Corral, Ana María. DOKUTEKANA. [En línea] 2 de Marzo de 2015. [Citado el: 10 de Mayo de
2019.] https://archivisticafacil.wordpress.com/2015/03/02/que-es-el-analisis-documental/.
40. De Aguiar, Marian. SaberMetodología. [En línea] 2016. [Citado el: 13 de Mayo de 2019.]
https://sabermetodologia.wordpress.com/2016/02/15/tecnicas-e-instrumentos-de-recoleccion-
de-datos/.
41. Ramos Chagoya, Ena. gestiopolis. [En línea] 2008. [Citado el: 10 de Mayo de 2019.]
https://www.gestiopolis.com/metodos-y-tecnicas-de-investigacion/.
42. Oyoqui, Alicia. Prezi. [En línea] 11 de Octubre de 2014. [Citado el: 10 de Mayo de 2019.]
https://prezi.com/qstod4pusmdv/metodos-para-verificar-la-confiabilidad/.
43. Mendoza Vega, Juan Bosco. Bosco Mendoza. [En línea] 17 de Noviembre de 2018. [Citado el:
13 de Mayo de 2019.] https://boscomendoza.com/alfa-de-cronbach-psicometria-con-r/.
44. Moriña, David, y otros. Introducción a la estadística para ciencias de la salud con R-
Commander. s.l. : Universitat Autónoma de Barcelona, 2016.
45. Cascardo, D. y Yáñez, R. Configuración, Implementación y Mantenimiento de ssitemas
informáticos. [En línea] 2016. https://rodas5.us.es/file/51cd89cb-a495-4525-a65c-
f006ce97e774/2/Tema1CIMSI.pdf.
46. Chipulina Puelles, Luigi. Sistema Web para la Gestión de Incidencias en la Empresa CONSULIT
S.A.C. Facultad de Ingeniería, Universidad César Vallejo. Lima : s.n., 2018. pág. 186, Tesis de
pregrado.
47. Álvarez Benites, Rosa Isabel y Mondragón Tantaléan, Edward Roger. Sistema Web de
generación de Ticket de atención de Incidencias para el área de CEUCI Universidad Nacional
Federico Villareal 2017. Escuela profesiona de Ingeniería de Computación y Sistemas, Universidad
Nacional Federico Villareal. Lima : s.n., 2017. pág. 149, Tesis de pregrado.
48. Farfan Correa, Gian Branco. Sistema web basado en ITIL y Tablero de control para la Gestión
de incidencias en SigloBPO. Facultad de Ingeniería, Universidad César Vallejo. Lima : s.n., 2017.
49. Catpo Chuchón, Roger Eduardo. Sistema Web para la gestión de incidencias en la empresa
SEDAPAL. Facultad de Ingeniería, Universidad César Vallejo. Lima : s.n., 2017. pág. 223, Tesis de
pregrado.
50. Castro Bernales, Luis Alfredo. Sistema web para el proceso de Gestión de Incidencias en el
Hospital Nacional Arzobispo Loayza. Facultad de Ingeniería, Universidad César Vallejo. Lima : s.n.,
2017. pág. 322, Tesis de pregrado.
51. Llalleri Cardenas, Nathaly María. Aplicación web basada en ITIL, EFQM y NTP-ISO/IEC
12207:2016 para la gestión de incidencias en Sistemas Inteligentes S.A.C. Facultad de Ingeniería,
Universidad César Vallejo. Lima : s.n., 2017. pág. 178, Tesis de pregrado.
52. Herrera Morán, Benjy Steven. Sistema web para la gestión de incidencias de la empresa CSD
Electrónica S.A.C. Facultad de Ingeniería, Universidad César Vallejo. Lima : s.n., 2017. pág. 222,
Tesis de pregrado.
53. Cegarra Sánchez, José. Los Métodos de Investigación. Madrid : Ediciones Díaz de Santos, 2012.
ISBN 978-84-9969-027-8.
54. Proactivanet. 2000.
55. Comercio, Cámara de. Commerce. 2019. 2.
56. Carmona, Miguel Ángel. 2008.
57. Santos, L. Aplicación móvil y web responsiva utilizando el algoritmo de planificación basado en
prioridades para apoyar en la atención de solicitudes del servicio delivery en la Lavandería Quin.
Chiclayo : Universidad Católica Santo Toribio de Mogrovejo, 2018.
60
58. Callao, R. Aplicación web basado en el programa de reaprovisionamiento continuo utilizando
la tecnología de códigos QR para mejorar los procesos de distribución, en una empresa
comercializadora de vehículos. Chiclayo : Universidad Católica Santo Toribio de Mogrovejo, 2015.
59. Alegsa.com.ar. Definición de Sistema integrado. [En línea] ALEGSA, 2016. [Citado el: 20 de
05 de 2019.] http://www.alegsa.com.ar/Dic/sistema integrado.php.
60. Rivero Caballero, Estefanía. Viabilidad e impacto de la implantación de sistemas de gestión.
Sistemas Integrados de Gestión. [En línea] 2014. [Citado el: 18 de 05 de 2019.]
http://bibing.us.es/proyectos/abreproy/70599/fichero/7.-+Sistemas+integrados+de+gesti
%C3%B3n.pdf.
61. Osiatis. Itil V3. Gestión de Servicios TI. [En línea] 2012. [Citado el: 25 de 05 de 2019.]
http://itilv3.osiatis.es/operacion_servicios_TI/gestion_problemas/control_problemas.php.
62. Calvo, Diego. Diego Calvo. Metodología XP Programación Extrema (Metodología ágil). [En
línea] 07 de 04 de 2018. [Citado el: 20 de 05 de 2019.] http://www.diegocalvo.es/metodologia-
xp-programacion-extrema-metodologia-agil/.
63. López, P y Francisco, R. INGENIERÍA DEL SOFTWARE. (En línea). INGENIERÍA DEL SOFTWARE.
(En línea). [En línea] [Citado el: 15 de 05 de 2019.]
http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-i/materiales-de-clase-1/is1-
t02-trans.pdf.
64. Conectart, Blog de. LA METODOLOGÍA SCRUM O SCRUM METHODOLOGY. [En línea] [Citado
el: 18 de 05 de 2019.] https://blog.conectart.com/la-metodologia-scrum-scrum-methodology/.
65. Garcia, Mirian. Coding or not. MVC (Modelo-Vista-Controlador): ¿qué es y para qué sirve?
[En línea] Mirian Garcia, 05 de 10 de 2017. [Citado el: 17 de 05 de 2019.]
https://codingornot.com/mvc-modelo-vista-controlador-que-es-y-para-que-sirve.
66. Mateu, C. Desarrollo de aplicaciones web. [En línea] Universidad Oberta de Catalunya, 2004.
https://libros.metabiblioteca.org/bitstream/001/591/1/004%20Desarrollo%20de
%20aplicaciones%20web.pdf.
67. Murcia, Universidad de. Manual Básico de Creación de Páginas Web. [En línea] Universidad
de Murcia, 2015. https://www.um.es/atica/documentos/html.pdf.
68. Gauchat, J. El gran libro de HTML5, CSS3 y Javascript. [En línea] Marcombo, 2012.
https://books.google.com.pe/books?
id=szDMlRzwzuUC&printsec=frontcover&dq=html+manual+pdf&hl=es&sa=X&ved=0ahUKEwjh-
ZOYpuLiAhVNj1kKHXhTCxMQ6AEIJzAA#v=onepage&q&f=false.
61

Avance Bruno 11 06 2019 C1

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Avance Bruno 11 06 2019 C1

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE INGENIERÍA

ESCUELA ACADÉMICO PROFESIONAL DE INGENIERIA DE SISTEMAS

SISTEMA WEB PARA LA GESTIÓN DE INCIDENCIAS DEL AREA DE

I.1. Realidad Problemática

En la actualidad, las TI se encuentran más presentes en las empresas, dando

las incidencias producidas en las TI, una incidencia es una interrupción no

estas incidencias provocan la paralización de los procesos del negocio. (1)

A lo largo de todo el mundo, muchas de las organizaciones proporcionan a sus

remoto en atención a las pérdidas de datos que se producen constantemente por

presentan en sus plataformas. (2)

Existen diversos factores que perjudican la gestión de incidentes en distintas

organizaciones, como es el caso de una entidad que brinda el servicio de TI a

organismos del estado peruano; dentro de estos se encuentran los factores

externos (políticos), la alta rotación del personal a cargo, condiciones técnicas

limitadas y déficit de buenas prácticas estandarizadas, haciendo de esta manera

difícil reponer el servicio de una manera rápida y disminuir el impacto

desfavorable sobre las operaciones de la organización. (3)

Belcorp es una empresa dedicada al rubro de cuidado personal, la cual se

encarga de ofrecer productos de belleza por medio de consultoras encargadas de

mediante la plataforma digital de la empresa. Sin embargo, al igual que en

muchas plataformas digitales, existe una saturación de la página por distintos

motivos, dicha incidencia perjudica directamente a las consultoras, pues no

realizarán el pedido a tiempo, generando incomodidad a las mismas.

El registro de dichos incidentes lo realiza el área de Tecnología e Investigación

(TI), la misma que se encarga de la gestión de monitoreo de las incidencias y

requerimientos de los servicios de la empresa Belcorp. La gestión de este servicio

incidencias y requerimientos presentados. El monitoreo de incidencias se realiza

control de ordenadores y servicios, con la cual se maneja el alertamiento de

incidencias y muchas veces tenemos alertas recurrentes o falsos positivos, las

herramienta llamada JIRA, la cual nos permite creación de tickets de incidentes o

requerimientos dependiente el evento presentado.

Otro problema referente a la gestión de incidencias es que los procesos de

requerimientos, son manejados de forma muchas veces incorrectas, por falta de

información del requerimiento, falta de comunicación con los involucrados,

problemas con el flujo correcto de atención, demoras en atención de trabajos

programados, generando incomodidad por parte de los solicitantes y los

la siguiente interrogante ¿La implementación de un sistema web optimizará la

gestión de incidencias del área de TI de la empresa Belcorp?

I.2. Trabajos previos

Jiménez (2014), con su tesis “Diseño de un Sistema de Gestión y Análisis de

Incidencias” (Tesis de pregrado). Universidad Carlos III de Madrid. Madrid,

España. Propuso analizar y diseñar un sistema de gestión de incidencias que

de referencia ITIL que presenta un conjunto de buenas prácticas para la gestión

de servicios TIC; y la norma ISO/IEC 20000; que define un sistema de gestión de

Servicios TI con un conjunto de especificaciones y buenas prácticas referente a la

gestión de incidencias. Se utilizó el lenguaje UML para la representación de los

casos. Siendo una investigación experimental. Se obtuvo que, gracias al sistema

diseñado, los distintos usuarios podrán generar incidencias y estas ser

gestionadas correctamente dando uso a todas las funcionalidades detalladas en

los requisitos del sistema.

El presente estudio tuvo como finalidad Implementar el sistema diseñado para su

uso en la gestión y análisis de incidencias. Con el fin de corroborar totalmente su

Tarazona (2017), con su tesis “Desarrollo e Implementación de un sistema web de

gestión de incidencias y entrega de documentos para la empresa Electrocentro

S.A. 2017” (Tesis de pregrado). Universidad Nacional “Hermilio Valdizán”.

Huánuco, Perú. Planteó desarrollar e implementar un sistema web que contribuya

a la mejora de la gestión de incidencias y entrega de documentos de

aplicando una investigación de tipo tecnológica, con un diseño no experimental.

Se aplicó instrumentos como cuestionario, entrevista y libreta de apuntes a 77

usuarios de las diferentes áreas de la empresa. Obteniendo como resultados la

implementación del sistema web permitiendo tener información almacenada y

centralizada de todo lo que se concierne a la gestión de incidencia y entrega de