Laura Nakaya Italo Sanchez Tesis Titulo Profesional 2019

Facultad de Ingeniería
Carrera de Ingeniería de Sistemas e Informática
“Desarrollo de un Sistema de Control de

incidencias y problemas en el área de TI
de una Universidad Privada en Lima”
Autores:
Nakaya Tello, Laura Fiorella
Sánchez Sancho, Italo Osmar
Para obtener el Título Profesional de
Ingeniero de Sistemas e Informática
Asesor: Quiñones Nieto, Yamil Alexander
{Lima, Octubre 2019

DEDICATORIA
Dedicado a aquellas personas que nos

apoyaron en el transcurso de nuestra
formación profesional y que nos
animaron a seguir luchando para lograr
el objetivo.
2
AGRADECIMIENTOS
A la UTP, por todo lo aprendido a lo largo de nuestra carrera profesional.
A nuestras familias, por confiar siempre en nosotros y apoyarnos de manera

incondicional.
A nuestros profesores que compartieron su conocimiento y experiencias.
3
RESUMEN
Este trabajo de investigación llamado “Desarrollo de un sistema de control de incidencias

y problemas en el área de TI de una Universidad Privada en Lima”, busca brindar una
solución tecnológica que se base en las recomendaciones que nos da ITIL v3 2011 para
gestionar las incidencias y problemas.
Como marco de trabajo se ha utilizado “Scrum” el cual cuenta con diversos procesos ágiles
que fueron adaptados para este proyecto de investigación y fue fundamental para el
análisis de requerimientos, así como también para la priorización de tareas.
En el Capítulo 1, se describe la problemática que nos sirvió como base para poder realizar
el análisis de requerimientos. Así mismo, se crean los objetivos que se esperan lograr al
finalizar el proyecto, se describe el alcance, las limitaciones y la justificación.
En el Capítulo 2, se presentan 5 antecedentes nacionales y 5 internacionales relacionados

al tema de investigación que nos sirvió como base para este proyecto, además se colocó
el marco teórico y marco conceptual, los cuales nos ayudan a entender los diferentes
términos que se utilizaron a lo largo del proyecto. Adicional a ello se muestra el marco
metodológico, en el cual se definen las fases y tareas a desarrollar.
En el Capítulo 3, se describe cómo se desarrolló el proyecto, dividido en las fases

establecidas en el marco metodológico.
Y por último, en el Capítulo 4 se presentan las recomendaciones y conclusiones que

surgieron al culminar el proyecto de investigación.
4
ABSTRACT
This research work called “Development of an incident and problem control system in the
IT area of a Private University in Lima”, seeks to provide a technological solution that is
based on the recommendations given by ITIL v3 2011 to manage incidents and problems.
As a framework, “Scrum” has been used, which has several agile processes that were
adapted for this research project and was essential for the analysis of requirements, as well
as for the prioritization of tasks.
In Chapter 1, we describe the problem that served us as a basis to perform the requirements
analysis. Likewise, the objectives that are expected to be achieved at the end of the project
are created, the scope, limitations and justification are described.
In Chapter 2, 5 national and 5 international antecedents related to the research topic that
served as the basis for this project are presented, in addition to the theoretical framework
and conceptual framework, which help us understand the different terms that were used to
throughout the project. Additionally, the methodological framework is shown, in which the
phases and tasks to be developed are defined.
Chapter 3 describes how the project was developed, divided into the phases established in
the methodological framework.
And finally, Chapter 4 presents the recommendations and conclusions that came up at the
end of the research project.
5
Tabla de contenidos
CAPÍTULO 1 ASPECTOS GENERALES ............................................................................... 11

1. Formulación del problema ................................................................................................ 11
2. Definición del problema general ....................................................................................... 12
3. Definición del objetivo ....................................................................................................... 12
3.1. Objetivo general ............................................................................................................. 12
3.2. Objetivos específicos .................................................................................................... 12
4. Definición de indicadores .................................................................................................. 13
5. Alcance y limitaciones ....................................................................................................... 13
5.1. Alcance ........................................................................................................................... 13
5.2. Limitaciones ................................................................................................................... 14
6. Justificación........................................................................................................................ 14
6.1. Justificación tecnológica ............................................................................................... 15
CAPÍTULO 2 FUNDAMENTO TEÓRICO ............................................................................... 16
1. Antecedentes ..................................................................................................................... 16
1.1. Antecedentes Nacionales ............................................................................................. 16
1.2. Antecedentes Internacionales ...................................................................................... 18
2. Marco Teórico .................................................................................................................... 21
2.1. ITIL .................................................................................................................................. 21
2.2. ISO 20000 ...................................................................................................................... 23
2.3. Gestión de incidencias .................................................................................................. 24
2.4. SCRUM........................................................................................................................... 26
3. Marco Conceptual ............................................................................................................. 30
4. Marco metodológico .......................................................................................................... 32
4.1. Inicio ................................................................................................................................ 34
4.2. Planificación ................................................................................................................... 35
CAPÍTULO 3 DESARROLLO DEL PROYECTO.................................................................... 40
1. Inicio ................................................................................................................................... 40
1.1. Investigación de soluciones existentes........................................................................ 40
1.2. Establecer la solución ................................................................................................... 40
1.3. Definición de épicas ...................................................................................................... 41
2. Planificación ....................................................................................................................... 41
2.1. Establecer el cronograma del proyecto ....................................................................... 41
2.2. Creación de historias de usuarios por épicas ............................................................. 42
6
2.2.1. Historias de usuario por épicas: ............................................................................... 44
2.3. Definición del Product Backlog ..................................................................................... 47
2.5. Diseño de interfaces de usuario ................................................................................... 53
2.6. Definición de arquitectura ............................................................................................. 70
2.7. Configuración de los ambientes de desarrollo ............................................................ 73
2.8. Definición de Reuniones Scrum a utilizar .................................................................... 73
2.9. Establecer la estrategia de control de riesgos ............................................................ 74
3. Desarrollo ........................................................................................................................... 74
4. Pruebas .............................................................................................................................. 85
CAPÍTULO 4 RESULTADOS DE LA INVESTIGACIÓN ...................................................... 101
1. CONCLUSIONES ............................................................................................................ 101
2. RECOMENDACIONES ................................................................................................... 101
BIBLIOGRAFÍA........................................................................................................................ 103
7
Lista de tablas
Tabla 1: Cuadro de Indicadores de mejora para la gestión de incidencias y problemas.
Tabla 2: Cuadro comparativo entre la ISO/IEC 20000 e ITIL v3 2011.
Tabla 3: Cronograma del Proyecto ASSDESK.
Tabla 4: Persona Analista de Mesa de Ayuda.
Tabla 5: Persona RRHH.
Tabla 6: Historia de Usuario 1 de ASSDESK.
Tabla 21: Product Backlog ASSDESK.
Tabla 22: Tabla de Sprints.
8
Lista de Figuras
Figura 1: API REST
Figura 2: Proceso de Gestión de incidencias
Figura 3: Proceso SCRUM
Figura 4: Desarrollo de Sprint Planning
Figura 5: Roles de SCRUM
Figura 6: Épicas
Figura 7: Product Backlog
Figura 8: Arquitectura de microservicios
Figura 9: Ciclo de desarrollo de Software
Figura 10: Pruebas de Software
Figura 11: Épicas ASSDESK
Figura 12: Product Backlog – ASSDESK
Figura 13: Sprint 1 – ASSDESK
Figura 16: Flujo usuario ASSDESK – Figma
Figura 17: Flujo analista ASSDESK – Figma
Figura 18: Flujo administrador ASSDESK (Login y consulta de incidencias) – Figma
Figura 19: Flujo administrador ASSDESK (Gestión de activos) – Figma
Figura 20: Flujo administrador ASSDESK (Gestión de usuarios) – Figma
Figura 21: Flujo administrador ASSDESK (Gestión de bitácora y reportes) – Figma
Figura 22: Diseño de arquitecturas de niveles – ASSDESK
Figura 23: Arquitectura Back – Capas
Figura 24: Diagrama de Base de Datos
9
Figura 25: ASSDESK Inicio de Sesión
Figura 26: ASSDESK Registro de incidencias – Perfil Cliente
Figura 27: ASSDESK Consulta de incidencias – Perfil Cliente
Figura 28: ASSDESK Registro de incidencias – Perfil Analista
Figura 29: ASSDESK Consulta de incidencias (Dashboard) – Perfil Analista
Figura 30: ASSDESK – Burndown Chart Sprint 1
Figura 31: ASSDESK Consultar la bitácora de soluciones
Figura 32: ASSDESK Registro de Solución (Actualizar incidencia)
Figura 33: ASSDESK Registro de usuarios – Clientes
Figura 34: ASSDESK Servicio de notificación de correo
Figura 35: ASSDESK Registro de soluciones en la bitácora
Figura 37: ASSDESK Actualización de soluciones en la bitácora
Figura 38: ASSDESK Actualizar usuarios
Figura 39: ASSDESK Registro de activos de TI
Figurar 40: ASSDESK Actualización de activos de TI
Figurar 41: ASSDESK – Generación de reportes estadísticos
10
CAPÍTULO 1
ASPECTOS GENERALES
1. Formulación del problema

En la presente investigación nos enfocaremos en la ciudad de Lima, que, según la
SUNEDU, en el siglo XX contaba solo con 19 Universidades Privadas, cifra que aumentó
a 45 para el siglo XXI; debido a la alta demanda de escolares que cuentan con la estabilidad
económica para acceder a una educación privada.
Como sabemos, la educación es el pilar esencial para el crecimiento de todo país, desde
muchas décadas atrás las Universidades Privadas vienen trabajando para ofrecer servicios
de alta calidad a los estudiantes, docentes y personal administrativo, sin embargo; la gran
mayoría de ellas no cuenta con el soporte adecuado de las Tecnologías de Información,
como por ejemplo: Soporte técnico para software y hardware, aplicaciones ofimática,
correo electrónico, redes, entre otros; los cuales son atendidos para el área de mesa de
ayuda encargada de anotar las incidencias y problemas que ocurren diariamente.
Todos estos servicios deben ser gestionados de manera eficiente para ofrecer la mejor
solución a los usuarios afectados; sin embargo, muchas de las universidades privadas
manejan un flujo engorroso en sus procesos de gestión de incidencias, como por ejemplo:
duplicidad de registros, manipulación de datos sin un control adecuado, entre otros; esto
genera un retraso significativo en el flujo de atención a los usuarios, lo cual impacta de
manera negativa en el presupuesto del área de TI y además de ello causa insatisfacción,
desconfianza y una mala imagen del servicio brindado.
Adicionalmente, se observa que no se está documentando la solución de las incidencias

atendidas, lo que ocasiona en muchas oportunidades que el tiempo de atención se extiende
más de lo debido, ya sea por falta de conocimiento o instrucción del personal de mesa de
ayuda.
11
Así mismo se ha identificado que no se generan indicadores de calidad del servicio; como
por ejemplo la cantidad de incidencias atendidas por un analista de mesa de ayuda o el
tiempo máximo de atención de una incidencia, entre otros; esto ocasiona que la mayoría
de decisiones que se toman no llegan a cumplir el objetivo esperado, como por ejemplo
evaluar si la cantidad de mesa de ayuda que tenemos es la ideal para llevar un proceso
óptimo o caso contrario si se necesita más personal. Contar con dichos indicadores nos
ayudarán para optimizar recursos (personas, tiempo, dinero, etc) y/o para mejorar algún
proceso que se esté ejecutando de manera ineficiente.
Por último se ha observado que no se lleva un control oportuno de activos de TI que utilizan
los usuarios de las diversas áreas de la Universidad, lo que ocasiona pérdida de la
visibilidad de activos sin garantía o fuera de estándar, así como también falta de
conocimiento de la asignación de activos por usuarios que en muchas oportunidades puede
generar algún robo o pérdida de dichos activos, ya sean Laptops, monitores, teclados, etc.
Frente a la problemática que se describe, se plantea elaborar un Sistema Informático que

de soporte al control de incidencias y problemas, permitiendo mejorar el trabajo de los
analistas que conforman la mesa de ayuda y de esa manera elevar el grado de satisfacción
de los usuarios.
2. Definición del problema general

¿Es posible desarrollar un sistema de control de incidencias y problemas en el área de TI
de una Universidad Privada de Lima?
3. Definición del objetivo
3.1. Objetivo general

Desarrollar un sistema de control de incidencias y problemas en el área de TI de una
Universidad Privada en Lima.
3.2. Objetivos específicos

 Disminuir los tiempos de atención de incidencias y problemas de TI.
 Generar reportes dinámicos que sirvan como indicadores para tomar decisiones.
 Mejorar el control y seguimiento de activos de TI.
12
4. Definición de indicadores
Tabla 1: Cuadro de indicadores de mejora para la gestión de incidencias y problemas
5. Alcance y limitaciones
5.1. Alcance
Este proyecto de investigación consiste en desarrollar un sistema web para el control de
incidencias y problemas en el área de TI para una Universidad Privada en Lima, que llevará
el nombre de “ASSDESK”, el cual permitirá al personal de ésta área mejorar la gestión y
resolución de incidencias, problemas y fallas que puedan reportar los usuarios finales como
alumnos, docentes y administrativo, utilizando como referencia las recomendaciones de
ITIL v3 2011.
El sistema soportará estos procesos de negocio:
 Registro, escalamiento y resolución de incidencias y problemas.

 Seguimiento y control de incidencias reportadas.
 Consulta de soluciones en la base de conocimientos.
 Registro y seguimiento de los activos.
13
Las tareas más importantes que se realizarán son:
 Se definirán las historias de usuario basadas en la problemática encontrada y con ellas

se elaborará el “Product Backlog”, separado en 3 Sprints.
 Se realizará el desarrollo de ASSDESK apoyado en el marco de trabajo Scrum, para
los componentes backend se trabajará con el lenguaje “Java” y para la base de datos
“SQL server”; así mismo para los componentes frontend utilizaremos JavaScript, HTML
y CSS bajo el framework Angular Js.
 Se realizarán las pruebas unitarias para que se lleve a producción un sistema de
calidad.
5.2. Limitaciones
Se tienen las siguientes condiciones:
 ASSDESK sólo soportará procesos de incidencias y problemas de mesa de ayuda, no

soportará la gestión de requerimientos.
 Como base de utilizarán las recomendaciones de ITIL v3 2011, no utilizaremos ITIL v4,
debido a que actualmente no existe mucha información sobre ello.
 Para poder ingresar a ASSDESK, el equipo deberá contar con una conexión a internet.
 ASSDESK será de uso exclusivo en computadoras, no tendrá resolución de equipos
móviles.
6. Justificación
Debido al flujo engorroso que se tiene en la atención de incidencias y problemas, se genera
una pérdida de tiempo significativa impactando así, el costo y el grado de satisfacción de
los usuarios.
Los beneficios que se obtendrán con ASSDESK son los siguientes:
 Reducirá los costos y tiempos de atención, que se verán reflejados en un ahorro

significativo para la organización.
 Se registrarán las soluciones de incidencias recurrentes en una bitácora que pueda ser
consultada por los analistas para incidencias similares futuras.
 Se elaborará reportes estadísticos para medir la productividad de cada analista con el
fin de realizar un correcto seguimiento y control de las incidencias y problemas
reportados, ayudando así a tomar mejores decisiones.
 Se registrarán todos los activos de TI para tener un control oportuno de los
responsables de cada activo, así como también de los equipos que estén fuera de
estándar o garantía.
14
6.1. Justificación tecnológica
Para el desarrollo de ASSDESK nos basaremos en una arquitectura de servicios
modulares, es decir enfocada en el desarrollo de pequeños servicios que se ejecutarán de
manera autónoma y que se comunicarán entre sí a través de peticiones REST.
REST “Representational State Transfer”, es una forma de arquitectura de software que

utiliza HTTP para adquirir datos y/o realizar procedimientos sobre ellos en algún formato
como XML o JSON. Las operaciones que más se utilizan en cualquier sistema REST son:
POST, GET, PUT y DELETE. REST es una alternativa con menos complejidad en
comparación a otros protocolos como SOAP “Simple Object Access Protocol”.
En cuanto al modelo de arquitectura se trabajará en capas, lo cual nos ayuda en la

reutilización de clases y métodos, así como también facilita la resolución de problemas
específicos de manera más centralizada.
Así mismo, utilizaremos la programación orientada a aspectos (POA), de manera que

podamos encapsular conceptos y agruparlos en funcionalidades comunes que puedan ser
usados para diferentes componentes de la aplicación.
Para los componentes backend utilizaremos como framework base Spring Boot y JPA y
para los componentes frontend utilizaremos Angular Js.
Para el despliegue y administración de cada servicio utilizaremos Docker y Kubernetes y

los recursos de infraestructura serán de Azure (SQL Database, AKS, ACR, etc).
Figura 1: API REST
Nota: “What is REST API”, 2018. Recuperado de: “https://phpenthusiast.com/blog/what-is-

rest-api”
15
CAPÍTULO 2
FUNDAMENTO TEÓRICO
1. Antecedentes
1.1. Antecedentes Nacionales

 “Desarrollo de una Aplicación Web para la mejora de la Gestión de incidencias
en la Empresa Nacional de Telecomunicaciones”
Milton Calisin (2018), en Perú, realizó una investigación cuyo objetivo fue desarrollar una
aplicación web utilizando la metodología RUP con el fin de mejorar la gestión de incidencias
y a su vez recuperar el nivel de funcionamiento óptimo, sin descuidar la calidad y
disponibilidad del servicio. Como conclusión de dicha investigación, el sistema se optimizó
considerablemente para el proceso de gestión de incidencias:
 Eficiencia en la aplicación web, respecto al período en la carga de contenidos y

respuesta de peticiones de los usuarios.
 Usabilidad en la aplicación web, respecto a las facilidades de navegación y compra;
además una atractiva presentación de contenido, cuyas características están definidas
por este mismo indicador.
 Por último confiabilidad en la aplicación, respecto al grado de satisfacción del usuario
final al tener un sistema seguro y sin fallas.
El aporte que nos brinda esta investigación de Milton Calision es tomar como referencia
sus indicadores de nivel de eficiencia, usabilidad, confiabilidad y funcionalidad para
aplicarlo y así poder alcanzar mejores resultados en la gestión de incidencias y problemas
a través de nuestro sistema.
 “Implementación de un Sistema Informático para automatizar el proceso de

Gestión de Ocurrencias en ISOSYSTEM Perú”
16
La investigación realizara por Carmen Sáenz y Jorge Tacuche (2017), en Perú, tuvo como
propósito implementar un sistema de información que les permitió reducir el tiempo y costo
en la atención a los clientes; con lo que consiguieron mejorar el proceso de gestión de
ocurrencias en Isosystem Perú. Sus principales metodologías utilizadas fueron SCRUM
para el desarrollo del aplicativo e ITIL v3 2011 para las funcionalidades del software. Como
conclusiones de dicha investigación se puede rescatar que el software pudo optimizar la
eficiencia y el tiempo de atención de las incidencias mejorando la calidad de los servicios
que se ofrecen a los clientes. Además contiene una base de conocimientos centralizada y
genera indicadores para realizar el seguimiento correspondiente y el control del proceso
tanto para el usuario como el cliente.
La contribución que nos da la investigación de Carmen Sáenz y Jorge Tacuche, es tomar

como referencia para el marco de trabajo SCRUM para el desarrollo del sistema.
 “Sistema web de Generación de ticket de atención de incidencias para el Área de

Ceuci Universidad Nacional Federico Villareal 2017”
Rosa Álvarez y Edward Mondragón (2017), en Perú, desarrollaron una investigación con el
fin de implementar un sistema web para la generación de tickets donde los propios usuarios
de la institución tengan la facilidad de reportar sus incidencias tanto de software como de
hardware, de manera que logren incrementar la satisfacción de los clientes y disminuir el
tiempo de atención. El sistema en mención cuenta con un módulo de estadísticas que
permite alcanzar métricas para poder evaluar el trabajo de los técnicos del Área de Ceuci
y conocer las sedes con mayores incidencias para una mejor toma de decisiones. Como
conclusiones de dicha investigación, el sistema facilitó una mejor atención sobre las
incidencias reportadas al Área de Ceuci, minimizando los tiempos de resolución ya que la
información está documentada y registrada en el sistema de ticket web.
La contribución de esta investigación de Rosa Álvarez y Edward Mondragón es poder tomar

como referencia su módulo de estadísticas y añadir a nuestro sistema una idea similar para
poder generar indicadores para la tomar de decisiones.
 “Desarrollo de un Sistema Help Desk para la Gestión y Control de incidencias en

Agroexportaciones MANUELITA SAC”
El trabajo desarrollado por Leonardo Fuentes (2016), en Perú, tuvo como propósito
desarrollar un sistema automatizado para brindar un mayor control, agilidad y seguridad en
el proceso de registro de las atenciones reportadas por clientes internos y externos; así
17
como también la asignación de dichas incidencias a un personal técnico que pueda dar
una solución al respecto.
El sistema da la facilidad también para almacenar problemas y soluciones alternativas, esto

agiliza la solución de incidencias y además permitió que usuarios no experimentados
puedan utilizar la herramienta para dar posibles soluciones e incidencias que se presenten.
Como conclusiones de dicha investigación tenemos: el sistema facilitó y agilizó la
resolución de incidencias manejando una base de conocimientos, la misma que se alimenta
conforme las necesidades de los usuarios.
El aporte que nos brinda la investigación de Leonardo Fuentes es la implementación de

una Base de Conocimientos en nuestro sistema para que ayude al personal a reducir el
tiempo de sus atenciones.
 “Aplicación Web para automatizar la Gestión de incidentes en la Cooperativa de

Ahorro y Crédito San Cristóbal de Huamanga”
Yannet Yance (2016), en Perú, realizo una investigación cuyo objetivo fue desarrollar una
aplicación web mediante técnicas e instrumentos con metodología de desarrollo ágil de
programación extrema, así como también un gestor de datos relacional, tecnologías de
internet, y un software para el modelado y automatización de procesos con base en ITIL
v3 2011; con la intención de automatizar el proceso de gestión de incidencias. Como
conclusiones de dicha investigación tenemos: el sistema cuenta con la asignación de
código de referencia del incidente, generación de data y notificación del incidente. Además
cuenta con campos para la categorización, nivel de prioridad, monitoreo del estado y
tiempo de resolución del incidente.
El aporte que nos brinda la investigación de Yannet Yance es utilizar como referencia la
metodología de ITIL v3 2011 para mejorar nuestros procesos de gestión de incidencias y
problemas.
1.2. Antecedentes Internacionales

 “Sistema web para la Gestión de servicios de TI y Control de responsabilidades
para la Multinacional TIGRE S.A”
Investigación realizada por Raúl Rosero y Jorge Conde (2017), en Ecuador, cuyo objetivo
fue implementar un aplicativo web que facilitara un mayor control de asignación de
responsabilidades y disminuir el tiempo de respuesta en la atención de los clientes.
Respecto al desarrollo del software han utilizado la metodología SCUM y para la eficiencia
del aplicativo las pruebas de calidad y aceptación. Por otro lado se podrá generar métricas
18
que midan el nivel de satisfacción de los clientes. Los autores llegaron a la conclusión que
utilizando la metodología SCRUM fue una ventaja debido a que les permitió organizar el
proyecto en actividades y formar un equipo de trabajo, además de llevar un registro de las
pruebas e incidencias presentadas para poder así tomar las medidas correctivas. Así
mismo las pruebas realizadas están alineadas con el software Agile Testing, lo cual
permiten validar el avance del proyecto que esté acorde a los requerimientos del usuario
final.
El aporte que rescatamos de esta investigación de Raúl Rosero y Jorge Conde es tomar
como referencia la metodología SCRUM para nuestro sistema y también realizar pruebas
correspondientes del software para tener un producto de calidad y con garantía.
 “Sistema de Gestión de Errores Conocidos”
La investigación realizada por Gonzalo Martin, Ignacio Scuro y Rodrigo López (2016), en
Uruguay, tuvo como propósito implementar un sistema de gestión de errores conocidos
que sirva como apoyo en la resolución de incidencias y problemas presentados en las
empresas o instituciones. Además presenta una interfaz interactiva para el usuario, la
compatibilidad con otras herramientas empresariales permitiendo así una facilidad en la
integración y la captura en la gestión del conocimiento. Como conclusiones de dicha
investigación se tiene que gracias al sistema lograron un adecuado trabajo en equipo, así
como también la interacción y compromiso de cada miembro del equipo, incorporando un
menú para búsquedas que facilite las consultas para un mayor grado de eficiencia.
El aporte que brinda la investigación de Gonzalo Martin, Ignacio Scuro y Rodrigo López es
poder tomar como modelo las herramientas implementadas en el Sistema de errores
conocidos que sirvan para mejorar el tiempo de atención de las incidencias y problemas,
entre ellas; una base de conocimientos a la que nosotros llamaremos bitácora de
soluciones.
 “Desarrollo de un Sistema Web orientado a una Mesa de Servicio para el Registro,

Gestión y Control de Incidencias Técnicas”
Proyecto realizado por Edison Alfonso (2016), en Ecuador, cuyo objetivo fue analizar,
diseñar y llevar a cabo todo el desarrollo de un sistema de información web para una Mesa
de servicios que pueda ser utilizado e implementado en cualquier institución o empresa,
con el fin de poder automatizar los procesos de gestión, registro y seguimiento de
incidencias solicitadas por nuestros usuarios o clientes. Como conclusiones de dicha
investigación tenemos: con el sistema se optimizará tiempos y mejorará la
19
intercomunicación entre los cliente y el personal de la mesa para poder aumentar la
satisfacción en el servicio.
Así mismo dicho sistema cuenta con una bitácora de conocimientos lo cual brindará un
apoyo para el personal respecto a fallas frecuentes y toma de decisiones en la parte
operativa, además contará con una interfaz interactiva para los usuarios que le permitirá
saber el estado de su incidencia; así como el personal que lo está atendiendo, brindando
indicadores de mejora en la calidad del servicio.
El aporte que brinda la investigación de Edison Alfonso, es tomar como referencia el flujo
de seguimiento de la solicitud del usuario final y la base de conocimientos incorporada que
nos permitirá reducir considerablemente el tiempo de atención.
 “Implementación de un Sistema de Mesa de Ayuda Informático (Help Desk) para

el control de incidencias que se presentan en el Gobierno Autónomo
Descentralizado de la Provincia de Esmeraldas”
Trabajo realizado por Fabián López (2014), en Ecuador, el cual tuvo el propósito de
implementar un sistema de Información para el área de Help Desk, fue desarrollado en
software libre. Dicho sistema tiene la función de automatizar los procesos de gestión a nivel
operativo y tecnológico generando indicadores o reportes que muestren a los usuarios el
estado de su incidencia, así como también los tiempos de respuesta y la calidad del servicio
que se ha brindado. Este sistema tuvo un impacto positivo a nivel económico, tecnológico
y administrativo.
Como conclusiones tenemos que el sistema ayudó para optimizar los procesos de gestión
de incidencias permitiendo reducir el tiempo de atención obteniendo como resultado que
más del 99% de clientes fueran atendidos.
El aporte que brinda la investigación de Fabián López, es tomar como referencias las
herramientas utilizadas para poder generar reportes estadísticos y automatizar los
procesos.
 “Diseño de un Sistema de Gestión y Análisis de Incidencias”
Investigación realizada por Sara Jiménez (2014), en España, que tuvo como finalidad
diseñar un sistema de gestión y análisis de incidencias que permita disminuir el tiempo de
atención de la incidencia, reducir los costos y aumentar el grado de satisfacción del usuario
final.
20
Además el sistema permite optimizar la resolución de incidencias para reducir o ser
atendido en menos tiempo, minimizando el efecto que pueda ocasionar tanto para los
usuarios internos como externos. Como conclusiones tenemos que el sistema permitirá
realizar un seguimiento de todo el ciclo de una incidencia y brindará KPIs como indicadores
(cantidad de incidencias, tiempo de atención, cumplimiento del SLA, entre otros) para la
toma de decisiones.
El aporte que brinda la investigación de Sara Jiménez, es la incorporación de KPIs como

indicadores de calidad para poder tomar decisiones mejorando la satisfacción de los
usuarios finales.
2. Marco Teórico
2.1. ITIL
Hoy en día existen muchas empresas que utilizan marcos como referencia para poder
mejorar sus procesos al momento de gestionar sus servicios de TI, entre ellos tenemos a:
ITIL siglas de Information Technology Infraestructure Library que en español significa
Biblioteca de Infraestructura de Tecnología de Información, que según Van Bon et al.
(2008) apareció en los años 80 a raíz de una labor realizada por la Agencia Central de
Telecomunicaciones, que actualmente es el Ministerio de Comercio de Reino Unido, con
el fin de garantizar servicios eficientes al gobierno británico. (p.9)
Para Moyano et al. (como se citó en Baca y Vela, 2015, p.7) ITIL es un marco de referencia
muy utilizado a nivel mundial que se basa en buenas prácticas para brindar servicios de
alta calidad en las cuales se involucran las tecnologías de información. En este marco de
trabajo se da importancia al “qué” y “cómo” se deben realizar las actividades, facilitando la
adaptación a las peticiones de cada empresa y llevando la gestión de servicio a un nivel
más independiente (p.210).
ITIL nos enseña lo que realmente se debe tener en cuenta al momento de brindar un
servicio de TI; además motiva al personal a comprometerse con los objetivos de la
compañía creando un buen clima laboral y cultura organizacional logrando que se
identifiquen con la organización.
Todas estas recomendaciones nos ayudarán para lograr una mejora continua en la gestión
de servicios de TI y captar los objetivos establecidos por la compañía para poder alcanzar
la meta trazada.
Según Van Bon et al. (2008) ITIL contiene 5 fases las cuales tienen un ciclo de vida por
cada servicio y las describiremos a continuación:
21
 Estrategia del Servicio: Tiene como propósito diseñar, desarrollar e efectuar la
gestión de servicios con el fin de ser una ventaja estratégica para la compañía.
 Diseño del Servicio: Tiene como objetivo que la compañía cumpla con lo que requiera
lo cual engloba procesos, políticas, documentos y arquitectura.
 Transición del Servicio: Tiene como objetivo desplegar y mejorar los contenidos en
la producción de servicios modificados o nuevos.
 Operación del Servicio: Tiene como objetivo velar por el soporte de los servicios
brindados garantizando su efectividad y eficiencia con el fin de satisfacer a sus clientes
generando valor agregado.
 Mejora Continua: Tiene como propósito conversar el importe agregado para el
usuario, sosteniéndose las etapas anteriores. (pp. 17-18).
Las etapas mencionadas nos brindarán una visión macro de los procesos que se quieren
mejorar en la Universidad.
La Gestión de Incidencias y Gestión de Problemas forman parte de la fase de operación,

las cuales son independientes, sin embargo están relacionadas debido a que pueden usar
los mismos aplicativos o sistemas para atender incidencias o problemas reportados
reduciendo los tiempos de atención y solución.
 Proceso de Gestión de Incidencia. Tiene como función ofrecer una solución óptima
y rápida al momento de ser registrada. Así mismo debe cumplir los SLA’s establecidos
por el cliente para poder minimizar el impacto que pueda tener la pérdida de continuidad
del negocio.
 Proceso de Gestión de problemas. Tiene como compromiso brindar una solución al
problema presentado a partir de las incidencias recurrentes cuya finalidad es reducir el
efecto de las incidencias controladas y eliminar aquellas que son recurrentes.
Como sabemos en una Universidad como en cualquier centro laboral se generan

incidencias diarias, que muchas veces pueden atrasar el trabajo, porque no se ha
documentado correctamente la solución inmediata de la misma.
La Gestión de Incidencias tiene como finalidad llegar a reducir el número de incidencias

que se reportan, así como también el impacto que puedan tener en los servicios de TI.
Según Van Bon (como se citó en Evangelista y Uquiche, 2014, p.19) el proceso de gestión
de incidencias contiene diversos tipos de incidencias, entre ellas: consultas, preguntas o
fallas reportadas por los usuarios o por los mismos analistas de mesa de ayuda. (p.140)
22
Finalmente el fin primordial es mantener y reponer el servicio lo más antes posible para
que el impacto sea mínimo.
2.2. ISO 20000

Adicionalmente, para garantizar la calidad de los servicios de TI que brindemos, nos
debemos apoyar en la ISO 20000 que según Van Bon et al. (2008) “la Organización
Internacional de Normalización la publicó el 15 de diciembre de 2005, la cual cambiaba la
Norma Británica 15000 a una norma internacional”. (p.44) y la definen como: un estándar
internacional que sirve para la administración y gestión de los servicios de TI.
La ISO 20000 está fundamentado en versiones de documentos BS15000-1/2 que fueron

anunciados en el año 2002 y 2003. La norma ISO 20000 se alinea con el marco de
referencia establecido por ITIL (pp.44-48).
La ISO 20000 para el Arquitecto de Gestión de Servicios Van Bon (2008), tiene como
propósito “Recoger el planteamiento de procesos integrados y ponerlos en práctica
garantizando que los servicios brindados sean correctamente gestionados con el fin de
cumplir los objetivos del negocio y los clientes”. (p.33)
Con la certificación en ISO 20000, se obtiene servicios y procesos más eficientes y de

mayor calidad; de tal manera que los clientes queden mucho más satisfechos.
ITIL facilita una guía de buenas prácticas para brindar un buen servicio de TI hacia nuestros
clientes y poder sobrellevar las necesidades del negocio. Existen las certificaciones de ITIL,
las cuales se realizan para personas y no para compañías que están implementando ITIL
(Kolthof 2008:15). Esta certificación es un logro personal y profesional para cada persona
de TI ya que adquiere mayor conocimiento del marco de trabajo de ITIL lo cual pondrá en
práctica en beneficio de la empresa donde labore.
En la tabla 2, se puede apreciar un cuadro comparativo entre ITIL v3 2011 y la ISO 20000.
Tabla 2: Cuadro comparativo entre ISO/IEC 20000 e ITIL v3 2011
23
Por esta razón se programa la implementación de un sistema web que nos permita tener
un mayor control de todas las incidencias y problemas que reportan los usuarios.
2.3. Gestión de incidencias

Incidencia es cualquier acontecimiento que cause perturbación del servicio hacia el cliente
o usuario (Moyano et al., 2010, p.224)
La Great Britain: Cabinet Office (2011), asevera que la gestión de incidencias brinda un
valor agregado a la organización ya que permite resolver y detectar incidencias, la destreza
para alinear las Tecnologías de Información con los objetivos de la empresa permitiendo
equilibrar las propuestas de mejora de los servicios brindados (Oltra y Roig, 2014, p.219)
24
Las actividades que se desarrollan en la Gestión de incidencias, según OSIATIS (s.f) son:
 Registro de incidencias: ésta es la primera actividad, en la cual se procede a recibir

y registrar la incidencia que reporta el usuario o cliente con el fin de ser atendido en
el momento para poder evitar demora en la atención del proceso y que puedan
aparecer nuevos reportes de incidencias.
 Calificación de incidencias: Al finalizar el registro, se anota todos los datos
necesarios con el fin de solucionar la incidencia presentada siguiendo estos pasos:
categorización de la incidencia (depende del tipo que se presente), nivel de
prioridad (la cual está relacionada con el impacto que pueda ocasionar y la urgencia
en ser resuelta); es necesario contar con los recursos para poder atenderla o en
todo caso derivar al siguiente nivel y como último paso monitorear el estado de la
incidencia y el tiempo de solución que depende del SLA establecido.
 Análisis, Resolución y Cierre: Previamente a resolver la incidencia, se debe
identificar en la base de conocimientos si hay una en común y aplicar la solución
registrada. En caso contrario derivar a un nivel superior, y de no poder resolver, se
realiza el escalamiento correspondiente. No olvidar que al ser resuelto una
incidencia se tiene que confirmar la solución al cliente o usuario que lo ha reportado,
luego se procede a guardar la solución en el SKMS, actualizar la data en la CMDB
y por último cerrar la incidencia.
En la Figura 2 se explican las actividades que forman parte del proceso de Gestión de
Incidencias:
Figura 2: {Proceso de Gestión de Incidencias

Nota: Baca y Vela (2015, p19). Recuperado de
“http://www.repositorioacademico.usmp.edu.pe”
25
2.4. SCRUM
2.4.1. Proceso Scrum
Scrum consiste en la manera como cada miembro del proyecto es capaz de adaptarse con
el fin de transformar un producto en base a los requerimientos de los usuarios. Es por eso
que se realizan iteraciones en un tiempo determinado para incrementar el producto y dar
mayor valor, tal como se muestra en la figura 3.
Por tal motivo se realizan ceremonias que las cuales deben participar todos los miembros
del equipo incluyendo el Product Owner.
Se denomina Sprint a cada iteración con una duración entre dos y cuatro semanas, el
tiempo puede variar dependiendo del proyecto, la cantidad de semanas se establece en la
etapa inicial del proyecto.
Al finalizar un Sprint se obtiene un entregable absolutamente eficaz y preparado para pasar

las pruebas correspondientes (Rosero y Conde, 2017, p.11)
Figura 3: Proceso Scrum
Nota: Caudevilla (2010). Recuperado de

“http://developing.frogtek.org/2010/07/29/waterfall-vs-scrum-kanban-ii/”
26
2.4.2. Eventos de Scrum
 Planning
Esta ceremonia se realiza antes de iniciar el Sprint es la etapa de planificación en la que el

Product Owner presenta las preferencias que tiene el negocio en relación al sistema final,
así como también resuelve dudas que el equipo pueda tener, de esta manera se reduce la
incertidumbre a lo largo del proyecto.
Ésta etapa se caracteriza por la estimación de esfuerzo de cada prioridad y por la

elaboración del Sprint Backlog, tal como se observa en la figura 4.
“Una mala ejecución de un planning puede desmantelar todo el Sprint” (Kniberg, 2007)
Figura 4: {Desarrollo del Sprint Planning}
Nota: Rosero y Conde (2017, p13). Recuperado de

“http://200.24.220.94/bitstream/33000/8098/1/UDLA-EC-TIS-2017-15.pdf”
 Daily
Scrum mide su evolución a través de ceremonias breves en las que se realiza seguimiento
del trabajo realizado en la reunión anterior y lo que se dispone a realizar durante el día
hasta la siguiente reunión, en diga reunión participa todo el equipo de trabajo.
El daily es básico para la agilidad del proyecto y debe tener una duración de 15 minutos
aproximadamente, lo ideal es que sea encaminada por el Scrum Master. La finalidad de
esta reunión es dar una rápida revisión del progreso de cada tarea y se responden
preguntas como: ¿Qué se avanzó ayer?, ¿Qué trabajo se hará hoy? ¿Qué impedimentos
se tiene? (Rosero y Conde, 2017, p.13)
27
 Review
Esta ceremonia es simplemente informativa, no debe durar más de 4 horas y es dirigida

por el Scrum Master, en ella se muestra el avance del proyecto, tareas acabadas y por
acabar, así como también se realizar un feedback para lograr un mejor desarrollo. (Rosero
y Conde, 2017, p.14)
 Retrospectiva
Es la ocasión que el equipo tiene para realizar una autocrítica del avance que se ha tenido
y para planificar mejoras para el siguiente Sprint. Debe durar 3 horas al mes como máximo,
el propósito de dicha ceremonia es identificar mejoras y posibilidades para aumentar la
eficiencia del equipo. (Rosero y Conde, 2017, p.14)
 Refinamiento
Reunión en la cual se evalúan las historias que se van a trabajar en el Sprint siguiente para
poder llegar a la reunión del planning con el alcance totalmente claro para cada miembro
del equipo y agilizar la estimación y priorización de cada historia de usuario.
2.4.3. {Roles de Scrum}
Figura 5: {Roles de Scrum}

Nota: Scrumalliance, s.f. Recuperado de “https://www.scrumalliance.org/agile-
resources/scrum-roles-demystified”
28
En la figura 5 podemos observar los roles que forman parte del desarrollo de Scrum y a
continuación se describe cada uno de ellos:
 Scrum Master
Líder y facilitador que está al servicio de todos los miembros del equipo para garantizar
que todos los procesos funcionen correctamente, además debe realizar el seguimiento de
cada historia con el fin de culminar con éxito cada Sprint.
 Product Owner
Persona con conocimientos del negocio, así como también de la visión del producto.
Es encargado de representar a todos los Stakeholders y de gestionar y mantener el Product

Backlog, adicional a ello, es la persona que busca tener el mejor valor para los usuarios
finales.
 Team
Grupo de personas que tienen diversas habilidades que son necesarias para desarrollar
un producto de calidad y que cumpla los requerimientos del cliente. (Palacio, 2007). Para
este proyecto el equipo de desarrollo está conformado por: Laura Nakaya e Italo Sánchez.
2.4.4. Artefactos de Scrum

 {Product Backlog}
Es una lista de todas las funcionalidades priorizadas según las necesidades del cliente.
(Palacio, 2007).
 {Sprint Backlog}
Lista de funcionalidades que se desarrollarán en un Sprint, que en conjunto componen un

incremento del producto.
 Burndown Chart
Herramienta que sirve al equipo para realizar un seguimiento del avance de cada Sprint y
muestra de manera temprana las posibles desviaciones que puedan presentarse a diario.
(Palacio, 2007).
29
3. Marco Conceptual
 Incidencia
Según Van Bon es una paralización sin planificar o una disminución de la calidad de un
servicio de TI. (p.82)
 Problema
Los investigadores Kolthof et al. (Como se citó en Bances, 2015, p.10) la definen como el
origen desconocido de un incidente o un conjunto de ellos que por lo general no se conoce
la causa en el momento del registro.
 Servicio
Según Van Bon et al. (2008), es el medio por el cual se entrega valor a los usuarios
facilitando los efectos que esperan alcanzar, sin contar con riesgos y costos. Los resultados
depende de cómo se realizan las tareas y están sujetos a diversas restricciones. (p.21)
 Bitácora
Por lo general se refiere a un blog que compila información de algún tema que ha sido
escrito por uno y más autores.
 SLA – Acuerdo de Nivel de Servicio
Son acuerdos entre un proveedor y el cliente y son medidos de manera cualitativa y/o
cuantitativa.
 OLA – Acuerdo de Nivel de Servicio
Son acuerdos en los cuales se definen los recursos y servicios que son ofrecidos por otra
área de una misma organización.
 IDE – Entorno de Desarrollo Integrado
Programa conformado por un conjunto de herramientas que son utilizadas en el desarrollo

de Sistemas de información.
 Java
Lenguaje de programación que utiliza un compilador para traducir el código ejecutable,

aunque también tiene la característica de ser un lenguaje interpretado; se basa en la
orientación a objetos.
 JavaScript
30
Lenguaje de programación interpretado y basado en prototipos.
 CSS
Lenguaje de diseño gráfico que sirve para crear la presentación de un documento

estructurado.
 HTML
Lenguaje de marcado para construir diversas páginas web.
 SQL
Lenguaje estándar ANSI/ISO que sirve para definir, manipular y controlar las bases de
datos relacionales.
 JSON
Formato que se basa en texto estándar que sirve para representar datos estructurados en
una coordinación de objetos de JavaScript.
 Spring Boot
Framework para el desarrollo de aplicaciones en lenguaje Java.
 Angular Js
Framework de JavaScript para desarrollar o mantener aplicaciones web.
 Kubernetes
Plataforma para administrar aplicaciones en contenedores a través de múltiples hosts.

Proporciona mecanismos básicos para desplegar, mantener y escalar aplicaciones.
 Docker
“Docker es una herramienta que promete encapsular fácilmente el proceso de creación de

un artefacto distribuible.
Para cualquier aplicación. Con él viene el fácil despliegue de una aplicación a escala en
cualquier entorno y agilizando el flujo de trabajo y la capacidad de respuesta de las
organizaciones de software ágil”.
 Definition of Ready
Son aplicados a las historias de usuario para asegurar que están en condiciones para ser
parte del siguiente Sprint.
31
 Definition of Done
Criterios de aceptación que sirven para comprobar que una funcionalidad desarrollada está
lista para ser usada.
 Épicas
Grandes cantidades de trabajo que se pueden desglosar en un número de tareas más

pequeñas (llamadas “historias”).
 Burndown Chart
Diagrama de la combustión de las tareas (Burndown chart). La combinación “Burn Down”

se traduce literalmente como <<arderse hacia abajo>> y en efecto es así. El gráfico dado
es el medio básico para la observación de las tareas cumplidas en el Sprint o en todo el
proyecto.
 Planning poker
Técnica espontánea, entretenida y poderosa en la cual todos los miembros del equipo de
desarrollo dan su opinión para estimar el esfuerzo de cada historia de usuario del Sprint.
 Azure API Management
Permite realizar una publicación de APIs de manera confiable y con posibilidades de

escalamiento.
4. Marco metodológico
Para el desarrollo de este proyecto nos basaremos en el marco de trabajo SCRUM, el cual
nos ayudará a generar valor de una manera más eficiente y eficaz. A través de cada
iteración (Sprint) podremos obtener una funcionalidad completa.
Las fases del presente proyecto son: Inicio, planificación, desarrollo y pruebas.
32
33
4.1. Inicio
En esta etapa inicial se realizarán los preparativos previos para comenzar el desarrollo
del proyecto:
4.1.1. Investigación de soluciones existentes (Antecedentes):
Se realizará una investigación y revisión de soluciones similares a la propuesta de este

proyecto, lo cual nos servirá de guía para la definición de actividades y selección de
herramientas.
4.1.2. Establecer la solución:
En base a las investigaciones realizadas se establecerá la solución más óptima basada

en el marco de trabajo Scrum, se definirá el alcance y las limitaciones.
4.1.3. Definición de épicas:
Se definirán las épicas a desarrollar, las cuales nos sirven para agrupar las historias de
usuario según un objetivo específico.
Figura 6: Épicas
Nota: “Épicas, historias, temas e iniciativas”. Recuperado de “https://es.atlassian.com”
34
4.2. Planificación
Se definirá la eficacia del proyecto a través de la priorización y estimación de
actividades.
4.2.1. Establecer el cronograma del proyecto
Se establecerá un cronograma para detallar qué fases se llevarán a lo largo del proyecto
y qué actividades se desarrollarán en cada una de ellas, así mismo se colocará una
fecha de duración de cada actividad.
4.2.2. Creación de historias de usuarios por épicas
Se definirán qué historias de usuario serán trabajadas para este proyecto, apoyándonos
en algunos datos recopilados de dos usuarios, como por ejemplo personalidad,
frustraciones, metas, motivaciones, entre otros. Esta información nos servirá para
entender más la necesidad de los usuarios y poder definir las tareas a desarrollar
agrupándolas en las épicas definidas en la fase anterior.
4.2.3. Definición del Product Backlog
Se plasmarán todas las historias de usuario que hemos determinado en el Product

Backlog, para ello utilizaremos la herramienta Trello, la cual nos permitirá administrar
las historias, hacer seguimiento a errores e incidencias y tener visibilidad de la
operatividad del proyecto.
Figura 7: Product Backlog
Nota: “Product Backlog Items”, 2016. Recuperado de: “https://www.quickscrum.com”
35
4.2.4. Priorización y estimación de historias de usuario y la duración de
cada Sprint (Iteración)
En esta fase se establecerá las puntuaciones y prioridad por cada historia de usuario;
es decir, definir cuánto tiempo en esfuerzo nos tomará realizar cada historia por Sprint
y cuál debe ser el orden de desarrollo de las mismas.
Esta puntuación nos ayudará a medir la efectividad del equipo y a tener un tiempo
aproximado de duración del proyecto.
Para realizar dicha priorización y estimación nos basaremos en la técnica del planning
poker.
4.2.5. Diseño de interfaces de usuario
Se diseñarán las interfaces de ASSDESK con la ayuda de la herramienta Figma, la cual

servirá de input para el desarrollo frontend.
4.2.6. Definición de arquitectura
Para el desarrollo del sistema utilizaremos una arquitectura de servicios modulares, es

decir enfocada en el desarrollo de pequeños servicios que se ejecutarán de manera
autónoma y que se comunicarán entre sí a través de peticiones REST.
Para el modelo de la plataforma se trabajará en capas, patrón que nos ayudará en la

reutilización de clases y métodos, así como también facilitará la resolución de problemas
específicos de manera más centralizada.
Como paradigma de programación utilizaremos POA (Programación orientada a

aspectos), la cual se basa en agrupar funcionalidades comunes que pueden ser usados
por diferentes componentes de la aplicación.
Así mismo para la estructura del sistema se utilizarán 3 niveles (Front, Back y Base de
datos), se trabajará por separado backend y frontend, para los componentes back se
utilizará Spring Boot y JPA como framework base y para los componentes front
utilizaremos Angular Js.
En cuanto a plataforma de despliegue y administración de cada servicio se utilizará

Docker, Kubernetes y los recursos de infraestructura serán de Azure (SQL Database,
AKS, ACR, etc).
36
Figura 8: Arquitectura de Microservicios
Nota: “Arquitectura de MicroServicios”, Colombia 2018. Recuperado de

“https://smartsoftcolombia.com/portal/index.php/blog/59”
4.2.7. Configuración de los ambientes de desarrollo
Se creará el clúster y el contenedor de registro en Azure para poder realizar los

despliegues de las funcionalidades utilizando docker para la creación de imágenes y
Kubernetes para la administración de las mismas.
4.2.8. Definición de reuniones Scrum a utilizar
En esta fase se establecerán las reuniones Scrum que utilizaremos en el desarrollo del
proyecto y cómo se llevarán a cabo cada una de ellas.
Entre esas reuniones tenemos como ejemplo: Refinamiento, Retrospectiva, Planning,

etc.
4.2.9. Establecer la estrategia de control de riesgos
En todo proyecto es importante conocer los riesgos que se pueden dar a lo largo del
desarrollo de las actividades, es por eso que nosotros nos apoyaremos en las reuniones
que Scrum nos ofrece para poder llevar un control adecuado de los posibles riesgos que
pueden ocurrir.
37
4.3. Desarrollo
Esta etapa es la más extensa del proyecto, la cual tiene por objetivo llevar todas las
historias de usuario a funcionalidades específicas del sistema.
Se dividirán las historias de usuario en 3 Sprints, cada uno con 3 semanas de duración:
al culminar cada Sprint se realizará una revisión para demostrar que se haya cumplido
con los criterios de aceptación.
El ciclo de desarrollo de Software apoyado en la agilidad de Scrum lo trabajaremos por

cada historia de usuario de la siguiente manera:
 Desarrollo backend, pruebas unitarias respectivas y despliegue.

 Desarrollo frontend, pruebas unitarias respectivas y despliegue.
 Integración de servicios back y front
 Pruebas funcionales
Figura 9: Ciclo de desarrollo de Software
Nota: “Metodologías ágiles, objetivos, características, ventajas”, 2015. Recuperado de

“https://comunidad iebschool.com”
4.4. Pruebas
Esta es la etapa final del proyecto, en la cual se realizarán pruebas funcionales y no

funcionales al sistema ya terminado, de manera que se pueda validar la eficiencia del
sistema.
Las pruebas a realizar serán:
38
 Pruebas de caja negra.
 Pruebas de Performance – Jmeter
 Pruebas de seguridad – OWASP ZAP
Figura 10: Pruebas de Software
Nota: “Pruebas no funcionales Parte I”, 2017. Recuperado de

“https://campusvirtual.edu.co”
39
CAPÍTULO 3
DESARROLLO DEL PROYECTO
1. Inicio
1.1. Investigación de soluciones existentes

Se investigaron otras tesis similares las cuales nos han sido de gran ayuda para poder
tomarlo como referencia y añadirlo a nuestro sistema como: Indicadores de eficiencia,
usabilidad, confiabilidad y funcionalidad para tomar decisiones que nos permitan
mejorar la gestión de incidencias y problemas, además de la ejecución de unas base de
conocimientos que ayude al personal a disminuir el tiempo de atención de las
incidencias y problemas reportados.
Así mismo nos hemos basado en Scrum para realizar la metodología del proyecto, de
manera que podamos tener entregas que generan valor en un periodo de tiempo más
corto. Para la parte de procesos nos apoyaremos en ITIL v3 2011, con el propósito de
acrecentar la satisfacción del cliente final.
1.2. Establecer la solución

En base a los antecedentes encontrados, se planteó desarrollar un sistema web para
controlar las incidencias y problemas para el área de TI de una Universidad Privada en
Lima llamado “ASSDESK”, que permita a los analistas de mesa de ayuda mejorar sus
procesos y optimizar la resolución de incidencias, fallas o problemas que se reporten
por los usuarios finales.
Los módulos que forman parte de este sistema son:
 Gestión de incidencias y problemas.

 Gestión de usuarios
 Gestión de activos
 Gestión de bitácora
40
 Módulo de Reportes
1.3. Definición de épicas

Las historias de usuario que se desarrollaron se agruparon en 5 épicas: Autorización,
Incidencias, Activos, Personas y Bitácora:
Figura 11: Épicas ASSDESK
Nota: Propio
2. Planificación
2.1. Establecer el cronograma del proyecto

El proyecto se desarrolló en 4 fases y tuvo una curación de 103 días:
Tabla 3: Cronograma del Proyecto ASSDESK
41
2.2. Creación de historias de usuarios por épicas
Se analizaron algunos datos recopilados de 2 posibles usuarios de ASSDESK; lo cual
nos ayudó para definir qué historias de usuario se desarrollarían:
Tabla 4: Persona Analista de Mesa de Ayuda:
42
43
Tabla 5: Persona RRHH
2.2.1. Historias de usuario por épicas:

 ÉPICA I – Autorización:
Tabla 6: Historia de Usuario 1 de ASSDESK
44
 ÉPICA II – Incidencias:
45
 ÉPICA III – Activos:
 ÉPICA IV – Personas:
46
 ÉPICA V - Bitácora
2.3. Definición del Product Backlog

La elaboración del Product Backlog nos sirvió para tener visibilidad de todas las historias
de usuario que debíamos desarrollar. La herramienta que utilizamos fue Trello:
47
Figura 12: Product Backlog – ASSDESK
Nota: Propio
48
Tabla 21: Product Backlog ASSDESK
49
2.4. Priorización y estimación de Historia de Usuario y la duración de cada
Sprint (Iteración):
Para la priorización y estimación de las historias que se trabajará se utilizó la técnica del
planning poker:
 Se juntó a los miembros del equipo en una mesa y se repartieron cartas

numeradas del 1 al 8.
 El Product Owner leyó cada historia y usuario para que todos los miembros del
equipo tuvieran claridad sobre el alcance de cada una de ellas.
 Para estimar el tiempo de cada historia se realizaron los siguientes pasos:
o Cada miembro del equipo seleccionó una carta y la colocó boca abajo
sobre la mesa. Luego de que cada uno haya seleccionado su carta, se
les pidió que las coloquen boca arriba.
o Se descartaron las valoraciones mínimas y máximas y se eligió el
promedio de ellas, cada persona dio su motivo y de puntuación y se llegó
a un acuerdo unánime para estimar la historia.
o Este proceso se repitió para cada historia del Product Backlog.
Luego de la sesión de planning poker se estableció que cada Sprint durará 3 semanas
y que la estimación de esfuerzo se llevaría de la siguiente manera:
 1 Punto = 2 días de esfuerzo

 2 Puntos = 1 semana de esfuerzo
 4 Puntos = 2 semanas de esfuerzo
 8 Puntos = 3 semanas de esfuerzo (Todo el Sprint)
Los resultados de la estimación realizada en la sesión del planning poker fueron los
siguientes:
Tabla 22: Tabla de Sprints
50
51
 Sprint 1 ASSDESK
Figura 13: Sprint 1 –ASSDESK
Nota: Propio
 Sprint 2 – ASSDESK
Nota: Propio
52
 Sprint 3 – ASSDESK
Nota: Propio
2.5. Diseño de interfaces de usuario

Para diseñar las interfaces hemos utilizado la herramienta Figma, la cual nos ayudó para
tener visión de los 3 flujos de ASSDESK: Flujo usuario, Flujo Analista y Flujo
Administrador:
53
 FLUJO USUARIO:
Figura 16: Flujo usuario ASSDESK – Figma
Nota: Propio
54
55
 FLUJO ANALISTA:
Figura 17: Flujo analista ASSDESK – Figma
Nota: Propio
56
57
58
59
60
 FLUJO ADMINISTRADOR:
Figura 18: Flujo administrador ASSDESK (Login y consulta de incidencias) – Figma
Nota: Propio
61
62
63
Figura 19: Flujo administrador ASSDESK (Gestión de activos) – Figma
Nota: Propio
64
65
Flujo 20: Flujo administrador ASSDESK (Gestión de usuarios) – Figma
Nota: Propio
66
67
Flujo 21: Flujo administrador ASSDESK (Gestión de bitácora y reportes) – Figma
Nota: Propio
68
69
2.6. Definición de arquitectura
ASSDESK es un sistema web desarrollado con el Framework Spring Boot y el lenguaje
de programación Java 8 para los componentes backend y para los componentes
frontend se utilizó el Framework de JavaScript Angular Js.
Figura 22: Diseño de arquitectura de niveles – ASSDESK
Nota: Propio
70
 Spring Boot brinda una arquitectura en capas, la cual nos sirvió de referencia
para el desarrollo de ASSDESK; de manera que dividimos los servicios en 4
capas principales:
Figura 23: Arquitectura Back – Capas

Nota: Propio
 Como gestor de base de datos para el almacenamiento de datos utilizamos SQL

Database de Azure.
71
Figura 24: Diagrama de Base de Datos
Nota: Propio
72
2.7. Configuración de los ambientes de desarrollo
Para el despliegue de los servicios modulares que se fueron desarrollando a lo largo del
proyecto se utilizó una cuenta free de Azure, que nos permitió implementar un clúster
para nuestro ambiente de desarrollo; así mismo se utilizó Azure Container Registry para
cargar las imágenes de nuestros servicios y se definió una instancia para cada uno de
ellos.
Para esta configuración se utilizó Kubernetes y docker.
Adicional a ello utilizaremos 3 recursos más de Azure:
 SQL Database para nuestra base de datos

 Azure API Management para publicar los endpoints (servicios) que fueron
usados por el frontend.
 Azure Service Bus para el servicio asíncrono de notificación de correo.
2.8. Definición de Reuniones Scrum a utilizar

Diariamente se realizaron daily meetings con una duración de 15 minutos y la estructura
fue la siguiente:
 ¿Qué hice ayer?

 ¿Qué haré hoy?
 ¿Qué impedimentos tengo?
Al finalizar cada Sprint se realizó un Sprint Review en el cual se revisó el avance del
proyecto y se evaluaron los indicadores del Burndown Chart.
Adicionalmente a ello se realizaron:
 Un refinamiento por cada Sprint (en la segunda semana) para revisar las
historias del siguiente Sprint, de manera que podamos eliminar las
dependencias.
 Una retrospectiva al finalizar cada Sprint para evaluar el trabajo positivo y
negativo que se ha realizado durante esas 3 semanas.
 Un planning antes de iniciar cada Sprint en el cual se busca dar una última
revisada a las historias que se trabajarán en el Sprint actual y se definen los
objetivos.
73
2.9. Establecer la estrategia de control de riesgos
Las ceremonias de Scrum nos ayudaron a identificar y controlar los riesgos que se
presentaron en el proyecto:
Daily Meeting: Reunión en la cual se comunica al equipo el avance de cada historia de

usuario, así como también los impedimentos que se tienen para continuar el desarrollo
del proyecto: esto nos ayudó a tomar las medidas necesarias para no tener retrasos
significativos a lo largo de cada Sprint. El Scrum master es el encargado de ayudar al
equipo para solventar los impedimentos que se identifiquen en el desarrollo del Sprint.
Refinamiento: Reunión en la cual se revisa el avance de las historias de usuario en

desarrollo, así como también las historias que forman parte del Sprint siguiente. Se
evaluaron los riesgos de cada historia y se identificaron los criterios que deberían tener
cada historia para poder iniciarla (Definition of Ready) y culminarla (Definition of Done).
3. Desarrollo
Esta etapa fue la más extensa del proyecto, se llevó a cabo a lo largo de 3 Sprints, cada
uno con 3 semanas de duración:
 Sprint 1:
o Servicio de inicio de sesión:
Figura 25: ASSDESK Inicio de Sesión

Nota: Propio
74
o Registro de incidencias – Perfil Cliente:
Figura 26: ASSDESK Registro de incidencias – Perfil Cliente
Nota: Propio
o Consulta de incidencias – Perfil Cliente:
Figura 27: ASSDESK Consulta de incidencias – Perfil Cliente
Nota: Propio
75
o Registro de incidencias – Perfil Analista
Figura 28: ASSDESK Registro de incidencias – Perfil Analista
Nota: Propio
o Consulta de incidencias (Dashboard) – Perfil Analista
Figura 29: ASSDESK Consulta de incidencias (Dashboard) – Perfil Analista
Nota: Propio
76
ASSDESK – Burndown Chart Sprint 2

Nota: Propio
 Sprint 2:
o Consultar la bitácora de soluciones:
Figura 31: ASSDESK Consultar la bitácora de soluciones
Nota: Propio
77
o Registro de Solución (Actualizar incidencia)
Figura 32: ASSDESK Registro de Solución (Actualizar incidencia)
Nota: Propio
78
o Registro de usuarios – Clientes
Figura 33: ASSDESK Registro de usuarios – Clientes
Nota: Propio
o Servicio de notificación de correo
79
80
Figura 34: ASSDESK Servicio de notificación de correo
Nota: Propio
o Registro de soluciones en la bitácora
Figura 35: ASSDESK Registro de soluciones en la bitácora
Nota: Propio
81

Nota: Propio
 Sprint 3:
o Actualización de soluciones en la bitácora:
Figura 37: ASSDESK Actualización de soluciones en la bitácora

Nota: Propio
82
o Actualizar usuarios:
Figura 38: ASSDESK Actualizar usuarios

Nota: Propio
o Registro de activos de TI:
Figura 39: ASSDESK Registro de activos de TI

Nota: Propio
83
o Actualización de activos de TI:
Figura 40: ASSDESK Actualización de activos de TI
Nota: Propio
o Generación de reportes estadísticos:
Figura 41: ASSDESK Generación de reportes estadísticos

Nota: Propio
84
Nota: Propio
4. Pruebas
Las pruebas que se realizaron fueron de 3 tipos: Pruebas de caja negra para validar la
calidad del funcionamiento del sistema, pruebas de performance para validar la
disponibilidad del sistema y pruebas de seguridad para validar que el sistema cumpla
con los lineamientos de OWASP.
A continuación se detalla cada una de estas pruebas:
85
 Pruebas de caja negra
Stage 1: Creación de Incidencia:
86
87
88
Stage 2: Flujo Administrador:
89
90
 Pruebas de Performance – Jmeter
Stage 1: Creación de Incidencia:
91
92
93
94
Stage 2: Flujo de Administrador:
95
96
97
98
99
 Pruebas de seguridad – OWASP ZAP
100
CAPÍTULO 4
RESULTADOS DE LA INVESTIGACIÓN
1. CONCLUSIONES
Al finalizar el desarrollo del proyecto ASSDESK, podemos concluir lo siguiente:
 Se identificaron y analizaron los posibles problemas que se puedan presentar en

el área de TI de una Universidad Privada de Lima y posterior a ello se llevó a
cabo el desarrollo de un sistema web basado en el marco de trabajo ágil SCRUM
y las recomendaciones de ITIL v3 2011.
 El sistema lleva por nombre ASSDESK (Assistant Desk), es el ayudante ideal
para la gestión de incidencias y problemas de TI; el cual ayuda a disminuir el
tiempo de atención gracias a que cuenta con una bitácora de soluciones que
sirve de guía para resolver rápidamente las incidencias recurrentes, así como
también con una interfaz amigable y entendible para los usuarios.
 El módulo de reportes de ASSDESK es una herramienta poderosa para la toma

de decisiones, ya que permite conocer el tiempo de atención promedio por rango
de fechas, analistas, estados y usuarios; toda esta información es necesaria al
momento de planificar las estrategias del área de TI.
 El módulo de gestión de activos de ASSDESK nos permite tener un mejor control
de cada activo de TI que ingresa y/o que se da de baja por avería o caducidad
de garantía, así como también nos permite realizar el seguimiento de asignación
de activos a los diferentes usuarios de la Universidad.
2. RECOMENDACIONES
Las recomendaciones sobre el desarrollo de un sistema de control de incidencias y
problemas en el área de TI de una Universidad Privada en Lima son:
 En cuanto a la arquitectura, recomendamos realizar servicios modulares

orientados a aspectos, ya que te permite tener un sistema con más alto nivel de
101
escalabilidad y disponibilidad, debido a que son independientes y en caso se
desee modificar una parte del sistema, sólo será necesario implementar un
cambio en un servicio y los demás servicios seguirán funcionando
correctamente.
 En cuanto a metodología y marco de trabajo, recomendamos involucrar a todo
el personal sobre la importancia de su uso para que puedan cumplir con los
procedimientos automatizados y puedan tener siempre un feedback por parte
del Product Owner que les permita brindar un mejor servicio hacia el usuario
final.
 Para la implementación de ASSDESK, se recomienda realizar capacitaciones
continuas al personal, de manera que el aprendizaje sea progresivo y se pueda
aprovechar cada funcionalidad que brinda el sistema de la mejor manera.
 Tener claro los roles que utilizará cada personal y el encargado de la
administración del Sistema ASSDESK para que puedan garantizar una buena
gestión de incidencias y problemas, con el correcto escalamiento y así evitar
tiempos improductivos.
102
BIBLIOGRAFÍA
 Alfonso, E (2016). Desarrollo de un Sistema Web orientado a una Mesa de Servicio
para el Registro de Gestión y Control de incidencias técnicas. (Tesis de pregrado).
Universidad de Guayaquil, Guayaquil, Ecuador. Recuperado de
http://repositorio.ug.edu.ec/bitstream/redug/18820/1/TESIS%20LSI%EDICON%20
ANTHONY%20ALFONSO%20ARANA.pdf
 Álvarez, R., & Mondragón, E. (2017). Sistema web de generación de Ticket de
atención de incidencias para el Área de Ceuci. (Tesis de pregrado). Universidad
Peruana de las Américas, Lima, Perú. Recuperado de
http://repositorio.ulasamercias.edu.pe/bitstream/handle/upa/201/SistemaWeb_Tick
etsIncidencia_Emondragon_1503%20%283%29.pdf?sequence=1&isAllowed=y
 Baca, Y., & Vela, G. (2015). Diseño e implementación de procesos basados en ITIL
v3 para la Gestión de Servicios TI del área de Service Desk de la Facultad de
Ingeniería y Arquitectura. (Tesis de pregrado). Universidad San Martín de Porres,
Lima, Perú. Recuperado de
http://www.repositorioacademico.usmp.edu.pe/bitstream/usmp/2015/1/baca_vela.p
df
 Bances, M. (2015). Implementación del proceso de Gestión de Incidencias basadas
en las buenas prácticas de ITIL v3 para la Facultad de Salud. (Tesis de pregrado).
Universidad Peruana Unión, Lima. Perú. Recuperado de
http://repositorio.upeu.edu.pe/bitstream/handle/UPEU/577/Misael_Tesis_bachiller_
2015.pdf?sequence=1&isAllowed=y
 Calisin, M. (2018). Desarrollo de una aplicación web para la mejora de la gestión de
incidencias en la Empresa Nacional de Telecomunicaciones. (Tesis de pregrado).
Universidad Inca Garcilaso de la Vega, Lima, Perú. Recuperado de
http://repositorio.uigv.edu.pe/bitstream/handle/20.500.11818/3224/TESIS-
MILTON%20CALISIN%20VARGAS.%20PDF.pdf?sequence=2&isAllowed=y
 Evangelista Casas, J., & Uquiche Chircca, L. (2014). Mejora de los procesos de
gestión de incidencias y cambios aplicando ITIL en la Facultad de Administración
(Tesis de pregrado). Universidad San Martín de Porres, Lima, Perú. Recuperado de
103
http://www.repositorioacademico.usmp.edu.pe/bitstream/usmp/1158/1/evangelista_
c.pdf
 Florian B. (2017). Pruebas no funcionales Parte I. Técnicas de pruebas de software,
Universidad del Valle: Cali, Colombia. Recuperado de
https://campusvirtual.univalle.edu.co/moodle/pluginfile.php/1210928/mod_resource/
content/1/2017_PruebasNoFuncionales-ParteI.pdf
 Fuentes, L. (2016). Desarrollo de Sistema Help Desk para la gestión y control de
incidencias en Agroexportaciones MANUELITA S.A.C. (Tesis de pregrado).
Universidad Nacional San Luis Gonzaga, Ica, Perú. Recuperado de
http://repositorio.unica.edu.pe/bitstream/handle/UNICA/20896/17.pdf?sequence=1
&isAllowed=y
 Jiménez, S. (2014). Diseño de un Sistema de Gestión y Análisis de Incidencias.
(Tesis de pregrado). Universidad Carlos III, Madrid, España. Recuperado de
https://e-
archivo.uc3m.es/bitstream/handle/10016/22456/PFC_sara_jimenez_rodriguez_201
4.pdf?sequence=1&isAllowed=y
 López, F. (2014). Implementación de un Sistema de Mesa de Ayuda informático
(Help Desk) para el control de incidencias que se presentan en el Gobierno
Autónomo Descentralizado de la Provincia de Esmeraldas. (Tesis de pregrado).
Pontificia Universidad Católica, Esmeraldas Ecuador. Recuperado de
https://repositorio.pucese.edu.ec/bitstream/123456789/189/1/LOPEZ%20VERA%2
0FABIAN.pdf
 Martín G., Scuro I., y López, R. (2016). Sistema de Gestión de Errores conocidos.
(Tesis de pregrado). Universidad ORT, Montevideo, Uruguay. Recuperado de
https://dspace.ort.edu.uy/bitstream/handle/20.500.11968/3247/Material%20complet
o.pdf?sequence=-1&isAllowed=y
 Moyano, F. J., Bruque C. S., Mauqueira M. J., y Martinez, P. J. (2010). Gestión de
la Calidad en empresas tecnológicas de TQM a ITIL. Madrid: StarBook Editorial.
 Palacio, J. (2007). Flexibilidad con Scrum – Principios de diseño e implantación de
campos de Scrum. Safe Creative. Recuperado de
https://www.scrummanager.net//files/flexibilidad_con_scrum.pdf
 Rosero, R., & Conde, J. (2017). Sistema Web para la Gestión de servicios de TI y
Control de responsabilidades para la Multinacional TIGRE S.A. (Tesis de pregrado).
Universidad de las Américas, Quito, Ecuador. Recuperado de
http://200.24.220.94/bitstream/33000/8098/1/UDLA-EC-TIS-2017-15.pdf
104
 Sáenz, C., & Tacuche, J. (2017). Implementación de un Sistema informático para
automatizar el proceso de gestión de ocurrencias en ISOSYSTEM PERU. (Tesis de
pregrado). Universidad San Ignacio de Loyola, Lima, Perú. Recuperado de
http://repositorio.usil.edu.pe/bitstream/USIL/3547/1/2017_Saenz-Fuentes.pdf
 SUNEDU (2017). Recuperado de https://www.sunedu.gob.pe/lista-universidades/
 Van Bon, J. De Jong, A., Kolthof, A., Pieper, M., Tjassing, R., Van der Veen, A., y
Verheijen, T. (2008). Gestión de Servicios de TI basada en ITIL® v3 – guía de
bolsillo. Zaltbommel: Van Haren Publishing
Verheijen, T. (2008). Fundamentos de ITIL® v3 – guía de bolsillo. Zaltbommel: Van
Haren Publishing
Verheijen, T. (2008). Fundamentos de la Gestión de Servicios de TI basada en ITIL.
Zaltbommel: Van Haren Publishing
 Yance, Y. (2016). Aplicación web para automatizar la gestión de incidentes en la
Cooperativa de Ahorro y Crédito San Cristóbal de Huamanga. (Tesis de pregrado).
Universidad Nacional de San Cristóbal de Huamanga, Ayacucho, Perú. Recuperado
de
http://repositorio.unsch.edu.pe/bitstream/handle/UNSCH/1746/TESIS%20SIS46_Y
an.pdf?sequence?1&isAllowed=y
105

Laura Nakaya Italo Sanchez Tesis Titulo Profesional 2019

Cargado por

Copyright:

Formatos disponibles

Laura Nakaya Italo Sanchez Tesis Titulo Profesional 2019

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Laura Nakaya Italo Sanchez Tesis Titulo Profesional 2019

Cargado por

Copyright:

Formatos disponibles

Facultad de Ingeniería

Carrera de Ingeniería de Sistemas e Informática

“Desarrollo de un Sistema de Control de

Nakaya Tello, Laura Fiorella

Sánchez Sancho, Italo Osmar

Para obtener el Título Profesional de

Ingeniero de Sistemas e Informática

Asesor: Quiñones Nieto, Yamil Alexander

{Lima, Octubre 2019

Dedicado a aquellas personas que nos

A la UTP, por todo lo aprendido a lo largo de nuestra carrera profesional.

A nuestras familias, por confiar siempre en nosotros y apoyarnos de manera

A nuestros profesores que compartieron su conocimiento y experiencias.

Este trabajo de investigación llamado “Desarrollo de un sistema de control de incidencias

En el Capítulo 2, se presentan 5 antecedentes nacionales y 5 internacionales relacionados

En el Capítulo 3, se describe cómo se desarrolló el proyecto, dividido en las fases

Y por último, en el Capítulo 4 se presentan las recomendaciones y conclusiones que

CAPÍTULO 1 ASPECTOS GENERALES ............................................................................... 11

Tabla 1: Cuadro de Indicadores de mejora para la gestión de incidencias y problemas.

Tabla 2: Cuadro comparativo entre la ISO/IEC 20000 e ITIL v3 2011.

Tabla 3: Cronograma del Proyecto ASSDESK.

Tabla 4: Persona Analista de Mesa de Ayuda.

Tabla 5: Persona RRHH.

Tabla 6: Historia de Usuario 1 de ASSDESK.

Tabla 7: Historia de Usuario 2 de ASSDESK.

Tabla 8: Historia de Usuario 3 de ASSDESK.

Tabla 9: Historia de Usuario 4 de ASSDESK.

Tabla 10: Historia de Usuario 5 de ASSDESK.

Tabla 11: Historia de Usuario 6 de ASSDESK.

Tabla 12: Historia de Usuario 7 de ASSDESK.

Tabla 13: Historia de Usuario 8 de ASSDESK.

Tabla 14: Historia de Usuario 9 de ASSDESK.

Tabla 15: Historia de Usuario 10 de ASSDESK.

Tabla 16: Historia de Usuario 11 de ASSDESK.

Tabla 17: Historia de Usuario 12 de ASSDESK.

Tabla 18: Historia de Usuario 13 de ASSDESK.

Tabla 19: Historia de Usuario 14 de ASSDESK.

Tabla 20: Historia de Usuario 15 de ASSDESK.

Tabla 21: Product Backlog ASSDESK.

Tabla 22: Tabla de Sprints.

Figura 1: API REST

Figura 2: Proceso de Gestión de incidencias

Figura 3: Proceso SCRUM

Figura 4: Desarrollo de Sprint Planning

Figura 5: Roles de SCRUM

Figura 7: Product Backlog

Figura 8: Arquitectura de microservicios

Figura 9: Ciclo de desarrollo de Software

Figura 10: Pruebas de Software

Figura 11: Épicas ASSDESK

Figura 12: Product Backlog – ASSDESK

Figura 13: Sprint 1 – ASSDESK

Figura 14: Sprint 2 – ASSDESK

Figura 15: Sprint 3 – ASSDESK

Figura 16: Flujo usuario ASSDESK – Figma

Figura 17: Flujo analista ASSDESK – Figma

Figura 18: Flujo administrador ASSDESK (Login y consulta de incidencias) – Figma

Figura 19: Flujo administrador ASSDESK (Gestión de activos) – Figma

Figura 20: Flujo administrador ASSDESK (Gestión de usuarios) – Figma

Figura 21: Flujo administrador ASSDESK (Gestión de bitácora y reportes) – Figma