PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ 
FACULTAD DE CIENCIAS E INGENIERÍA 
 
 
 
 
 
 
Diseño e implementación de una aplicación móvil para la 
presentación de estadísticas del módulo de incidencias de un 
Sistema de Gestión de Servicios 
 
 
Tesis para optar el Título de Ingeniero de las Telecomunicaciones, que presenta el 
bachiller: 
 
Luis Carlos Gamarra Muro 
 
 
  
ASESOR: Ing. Arturo Díaz Rosemberg 
 
Lima, Diciembre del 2013 
  
 
 
RESUMEN 
 
 El crecimiento y desarrollo de las tecnologías de la información han 
influenciado en gran manera el mercado durante los últimos 15 años. Con la aparición 
de hardware más poderoso, software más versátil y redes de alta velocidad, hemos 
pasado de la Era Industrial a la Era de la Información. El cambio acelerado del 
mercado de tecnología e información ha generado un nuevo enfoque horizontal de 
procesos de negocio en las empresas de TI (Tecnología e Información). 
 
Justamente, en el contexto anterior se da lugar a la Gestión de Servicios de 
Información (GSI), que se encarga de velar por la correcta operación de todos los 
procesos involucrados en la gestión de la información de la empresa como, por 
ejemplo, el proceso de gestión de incidencias, gestión de cambios, gestión de 
requerimientos, entre otros. De esta manera se asegura que la información sensible e 
importante para el negocio este siempre disponible, protegida y respaldada. 
 
Por lo general la gestión de procesos se lleva a cabo con la asistencia de una 
herramienta diseñada para llevar a cabo la administración de cada uno de los 
procesos mencionados en el párrafo anterior. Uno de los módulos que compone la 
herramienta de GSI es el módulo de Gestión de Incidencias, en donde se lleva a cabo 
el registro, atención, documentación y cierre de incidencias. 
 
Para tener una visión general del proceso de Gestión de Incidencias se usan métricas, 
medidas e indicadores, de tal manera que éstas muestren, a medida de resumen, los 
datos más importantes del proceso como, por ejemplo: número de incidencias 
generadas mensualmente, incidencias resueltas en el primer nivel de atención, 
número de incidencias gestionadas por la mesa de ayuda, número de incidencias 
derivadas a los niveles superiores de atención, entro otros. Estos indicadores son 
conocidos como KPI [1]. 
 
Estas métricas e indicadores son mostrados en cuadros de resumen a través de 
gráficos o tablas generadas en herramientas de cálculo, utilizando como fuente la 
información almacenada en las tablas correspondientes al proceso de Gestión de 
Incidencias de la base de datos de Gestión de Servicios. Limitadas son las 
herramientas existentes que ejecuten todo el proceso de generación y presentación de 
cuadros resumen de forma automática, y en consecuencia, las empresas deciden 
ii 
 
asignar a un recurso para la ejecución de las tareas necesarias y así obtener las 
métricas. Tareas como, ejecución de filtros, conteos y creación de tablas dinámicas. 
Generando así una serie de inconvenientes inherentes como susceptibilidad a errores 
humanos, uso ineficiente de recursos humanos, información no centralizada, no 
actualizada ni disponible desde fuera de la red corporativa. Para abordar esta serie de 
problemas la presente tesis emprende la construcción de una herramienta que pueda 
deslindar de estas dificultades. 
 
La herramienta planteada en la presente tesis es una aplicación para dispositivos 
móviles como tabletas o teléfonos celulares que posean las prestaciones suficientes. 
La arquitectura de la aplicación estará compuesta por una base de datos donde se 
encontrará la información de autenticación de usuarios e información correspondiente 
al proceso de Gestión de Incidencias como por ejemplo, la tabla que contiene 
información sobre el registro de las incidencias en el sistema. Esta información será 
consultada a través de web services que tendrán la función de encapsular la estructura 
de la base de datos del aplicativo. Luego se tendrá el cliente de la aplicación que será 
ejecutada desde el dispositivo móvil, el mismo se comunicará con las web services a 
través de protocolos que protegerán los datos transmitidos a través de la red. 
 
Finalmente se ha logrado implementar una aplicación móvil que puede ser ejecutada 
desde un dispositivo móvil que posea conexión a Internet, ya sea, a través de un 
Access Point o a través de la red celular que cuente con el servicio de datos. También 
se ha alcanzado automatizar el proceso de generación de cuadros de resumen del 
proceso de Gestión de Incidencias, transmitiendo de forma segura los datos de 
autenticación y la información respectiva a los indicadores del proceso. De esta 
manera se ha implementado una herramienta que permite coadyuvar a tener una 
mejor gestión del proceso de incidencias, abarcando uno de los procesos necesarios 
para validar la certificación de ISO 20000 en una empresa dedicada al sector TI 
(Tecnología e Información) [1]. 
 
iii 
 


 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
DEDICATORIA 
 
A Dios, a mis padres y hermanos por su apoyo  
incondicional en todo momento de mi carrera. 
A mi asesor Arturo Díaz y al profesor Enrique Larios por 
compartir su conocimiento para la realización de este trabajo.
vi 
 
INDICE 
RESUMEN .................................................................................................................... ii 
DEDICATORIA ............................................................................................................. vi 
GLOSARIO .................................................................................................................. 1 
Introducción.................................................................................................................. 2 
CAPÍTULO I ................................................................................................................. 5 
GENERALIDADES ....................................................................................................... 5 
1.1. Marco Conceptual ............................................................................................. 5 
1.1.1. Gestión de Servicios ................................................................................... 6 
1.1.2. Gestión de incidencias ................................................................................ 7 
1.1.3. Indicadores del proceso de Gestión de Incidencias ...................................10 
1.2. Definición del problema ....................................................................................11 
1.2.1. Planteamiento del problema ......................................................................12 
1.2.2. Objetivo General ........................................................................................16 
1.2.3. Objetivos Específicos ................................................................................17 
1.2.4. Resultados Esperados ...............................................................................19 
1.3. Plan de Proyecto ..............................................................................................19 
1.3.1. Métodos y procedimientos .........................................................................19 
1.4. Estado del Arte .................................................................................................22 
1.4.1 Aplicaciones Existentes ..............................................................................22 
1.4.2. Evaluación de Requerimientos de la aplicación Incident Dashboard Mobile
 ............................................................................................................................28 
CAPÍTULO II ...............................................................................................................31 
ANÁLISIS ....................................................................................................................31 
2.1 Identificación de Requerimientos .......................................................................31 
2.1.2 Requerimientos Funcionales.......................................................................32 
2.1.2 Requerimientos No Funcionales .................................................................33 
2.2. Análisis de la solución ......................................................................................34 
2.2.1. Evaluación de viabilidad y consideraciones sobre el sistema .....................35 
2.2.2 Análisis Técnico ..........................................................................................36 
2.2.3 Definición del Sistema ................................................................................38 
2.2.4. Requisitos Específicos: Especificación de Casos de Uso ..........................40 
2.2.5. Requisitos Específicos: Diagrama de Clases de Análisis ...........................42 
CAPÍTULO III ..............................................................................................................45 
DISEÑO ......................................................................................................................45 
3.1 Arquitectura de la solución ................................................................................45 
3.1.1. Metas Arquitectónicas y Restricciones .......................................................46 
3.1.2 Arquitectura ................................................................................................48 
 
 
3.2 Diseño de Interfaz Gráfica .................................................................................53 
3.2.1. Pantalla de Inicio de Sesión .......................................................................53 
3.2.2 Pantalla de Lista de Cuadros de Resumen .................................................55 
CAPÍTULO IV ..............................................................................................................58 
IMPLEMENTACIÓN Y PRUEBAS ...............................................................................58 
4.1 Implementación .................................................................................................58 
4.1.1 Patrones de Diseño ....................................................................................58 
4.1.2 Tecnología ..................................................................................................59 
4.1.3 Prácticas Recomendadas por Android Developers .....................................61 
4.1.4 Estándares de Programación......................................................................61 
4.2. Pruebas ............................................................................................................62 
4.2.1. Estrategia de Pruebas ...............................................................................62 
4.2.2 Pruebas de Aceptación ...............................................................................63 
4.2.3 Pruebas de Seguridad ................................................................................63 
CONCLUSIONES .......................................................................................................65 
RECOMENDACIONES ...............................................................................................67 
BIBLIOGRAFÍA ...........................................................................................................68 
 
  
viii 
 
ÍNDICE DE FIGURAS 
 
Figura 1: Árbol de Problemas ......................................................................................14 
Figura 2: Árbol de Objetivos ........................................................................................18 
Figura 3: Incidencias resueltas a tiempo .....................................................................23 
Figura 4: Remedy ITSM 8: Back Log de Incidencias ...................................................24 
Figura 5: HP – Incidencias por categoría .....................................................................25 
Figura 6: HP - Incidencias por servicio ........................................................................26 
Figura 7: OTRS - Incidencias según estado ................................................................27 
Figura 8: Requerimientos por Categoría y Violaciones de SLA ...................................28 
Figura 9: Número de requerimientos fuera de SLA......................................................28 
Figura 10: Caso de uso – Elección del cuadro resumen a mostrar ..............................39 
Figura 11: Diagrama de clases ....................................................................................43 
Figura 12: Vista Lógica de la aplicación ......................................................................48 
Figura 13: Vista de implementación de la aplicación ...................................................51 
Figura 14: Vista de despliegue de la aplicación ...........................................................52 
Figura 15: Pantalla de Inicio de Sesión .......................................................................54 
Figura 16: Pantalla de lista de cuadros de resumen ....................................................55 
Figura 17: Incidencias Resueltas enviadas directamente al nivel 2 o 3 .......................56 
Figura 18: Incidencias Resueltas enviadas directamente al nivel 2 o 3 .......................57 
 
  
ix 
 
ÍNCIDE DE CUADROS 
 
Cuadro 1: Descripción de procesos de la Gestión de Servicios .................................... 6 
Cuadro 2: Pasos del proceso de gestión de una incidencia .......................................... 8 
Cuadro 3: Etapas de desarrollo de la aplicación ..........................................................21 
Cuadro 4: Comparación de herramientas de Gestión de Incidencias ..........................29 
Cuadro 5: Lista de requerimientos funcionales ............................................................32 
Cuadro 6: Lista de requerimientos funcionales ............................................................33 
Cuadro 7: Caso de uso de la aplicación ......................................................................40 
Cuadro 8: Descripción del caso de uso .......................................................................41 
Cuadro 9: Descripción de plan de prueba ...................................................................63 
x 
 
GLOSARIO 
 
Credenciales.- conjunto de palabras 
claves que permiten la identificación y 
autenticación de una persona o 
sistema. Por lo general se componen 
de un usuario y clave. 
 
Cuadro resumen.- gráfico o tabla que 
muestra la evolución o estado actual de 
un indicador de tal manera que su 
interpretación sencilla. 
 
Dashboard.- tablero que muestra 
cuadros de resumen de la situación 
actual y evolución en el tiempo de los 
indicadores de los procesos de 
negocio. 
 
Incidencia.- interrupción no planificada 
de un servicio TI o la reducción de la 
calidad del servicio. Así mismo la falla 
de alguno de los activos de una 
empresa [1]. 
 
Indicador.- parámetro para concretizar 
la medición y muestra de la magnitud 
del logro de un objetivo [1]. 
 
ITIL.- (Information Technology 
Infrastructure LibraryTM) es una 
colección de mejores prácticas para el 
aprestamiento servicios TI [1]. 
 
KPI.- Son parámetros clave para medir 
el progreso relativo a los objetivos de la 
organización [1]. 
 
Línea de soporte.- conjunto de 
personas organizadas en niveles que 
registran, solucionan y cierran 
incidencias. 
 
Mesa de Ayuda.- conjunto de 
personas organizadas en el primer 
nivel de atención de una incidencia. Se 
encarga del registro, derivación y 
seguimiento de una incidencia. 
 
Red corporativa.- red de 
computadoras y servidores que se 
encuentra bajo la gestión de una 
organización y que, por lo general, se 
encuentra aislada de Internet. 
 
SDK.- (Software development kit) 
conjunto de librerías, clases y 
herramientas que permiten y facilitan la 
creación, modificación y depuración de 
aplicaciones o programas [5]. 
 
Servicio IT.- organización y personal 
destinado a satisfacer las necesidades 
tecnológicas y necesidades de 
disponibilidad y manipulación de 
información [1]. 
 
UML.- (Unified Modeling Language) es 
un lenguaje multipropósito utilizado en 
ingeniería software que provee un 
estándar para la visualización del 
diseño de sistemas [16]. 
 
Web-Service.- servicio brindando a 
través de un servidor web. Por lo 
general se programan en algún 
lenguaje script [5]. 
 
Zona desmilitarizada (DMZ).- red local 
que se ubica entre la red interna de una 
empresa y la red externa (Internet) de 
tal manera que las conexiones desde la 
red interna o externa hacia la DMZ 
están permitidas, pero desde la DMZ 
hacia la red interna están restringidas. 
 
1 
 
Introducción 
 
 La industria de la Tecnología e Información ha tenido un crecimiento 
significativo en los últimos 15 años, haciendo que la gestión de la información sensible 
e importante para las empresas sea uno de los procesos fundamentales de la 
actividad económica de la empresa dedicada al sector TI. Es en este contexto de 
crecimiento y cambio constante que la Gestión de Servicios de Información (GSI) 
cobra un papel importante en mantener la seguridad, disponibilidad e integridad de la 
información y procesos que se valen de esta para generar ganancias  a la 
organización.  GIS se divide en distintos módulos de gestión como, por ejemplo, el 
módulo de gestión de incidencias, gestión de cambios, gestión de problemas, gestión 
de requerimientos, entre otros. 
 
La presente tesis se basará en la información generada por el módulo de gestión de 
incidencias que se encarga del registro, atención, resolución y cierre de incidencias 
que se puedan dar sobre las aplicaciones, herramientas, sistemas y servicios que la 
empresa brinda a sus clientes y que son necesarios para que la actividad económica 
de la empresa pueda ejecutarse con normalidad. 
 
Para tener una visión general del proceso de Gestión de Incidencias se utilizan 
indicadores y métricas que brindan información sobre las características más 
importantes de la gestión de incidencias dentro de la organización. Estos indicadores 
reciben el nombre de KPI (Key Performance Indicator), entre los indicadores más 
utilizados tenemos, el número de incidencias generadas por mes, cantidad de 
incidencias atendidas en el primer nivel de atención, número de incidencias 
gestionadas por la mesa de ayuda, número de incidencias derivadas a los niveles 
superiores de atención, entre otros. 
 
La presentación de indicadores, por lo general, se da través de cuadros de resumen 
que muestran de forma más amigable el estado de los indicadores en el presente así 
como su evolución en el tiempo. Sin embargo, la extracción de información, 
procesamiento y presentación no se da a través de un proceso automatizado y 
delimitado de acuerdo a las necesidades de las organizaciones, de tal manera que se 
asignan recursos dedicados por una o más jornadas para la construcción de estos 
2 
 
cuadros resumen dependiendo de la frecuencia de los mismos que puede ser diaria, 
semanal, mensual o según demanda de la corporación. 
 
Es por ello que la presente tesis mostrará una propuesta de solución a través del 
diseño e implementación de una aplicación móvil que automatizará, centralizará, y 
mantendrá disponible los cuadros de resumen anteriormente mencionados. La 
aplicación tendrá por nombre Incident Dashboard Mobile y consistirá de 3 interfaces 
que guiarán al usuario de forma directa a las presentaciones comenzando por la 
interfaz de inicio de sesión, pasando por la interfaz de elección de cuadro de resumen, 
y finalmente la aplicación mostrará el cuadro seleccionado por el usuario. 
 
En los capítulos que componen la presente tesis se describirá el trabajo realizado para 
implementar la aplicación Incident Dashboard Mobile. 
 
En el primer capítulo se presenta el marco teórico necesario con el objetivo de 
comprender los conceptos y definiciones con los cuales se ha trabajado. Estas 
definiciones están relacionadas a la Gestión de Servicios de Información (GSI) así 
como la utilización de indicadores para gestionar el módulo de Gestión de Incidencias, 
que es parte de la GSI. También describe el contexto que abarca el problema que fue 
motivo del desarrollo del presente proyecto. Este escenario está compuesto por los 
problemas encontrados en la situación actual de la generación de cuadros de resumen 
y la necesidad de emplear una herramienta que automatice y centralice el proceso. 
Por último se presenta la solución propuesta en la construcción de una aplicación 
móvil la cual cubrirá los problemas planteados. 
 
En el segundo capítulo se presenta el análisis de los requerimientos funcionales y no 
funcionales de la aplicación con el objetivo de dirigir los objetivos alcanzables de la 
tesis. También se presenta el análisis de la solución, en este se incluye la evaluación 
de la viabilidad y el análisis técnico de la aplicación. Finalmente se presenta la 
definición del sistema de acuerdo a los casos de uso existentes. 
 
En el tercer capítulo se muestran las metas arquitectónicas de la aplicación y la 
definición de la arquitectura de acuerdo estas. Se la arquitectura desde el punto de 
vista lógico, de despliegue y de implementación de la aplicación. Finalmente se 
3 
 
muestra las interfaces gráficas y pantallas que conformarán la aplicación y con las 
cuales el usuario interactuará. 
 
En el cuarto capítulo se presentan los patrones de diseño y estándares de 
programación seguidos por la presente tesis para el diseño y construcción de la 
aplicación. Así mismo se muestran un conjunto de mejores prácticas seguidas durante 
el desarrollo. Por último se muestra la secuencia de pruebas seguidas para certificar el 
correcto funcionamiento de la aplicación en un ambiente Pre-Productivo. 
 
En el quinto y último capítulo se señalan las conclusiones después de ejecutar el 
levantamiento de información, análisis, diseño e implementación de la aplicación. Se 
explican detalles a tomar en cuenta para la implementación en ambientes reales y 
para la realización de mejoras sobre la misma. También se señalan ciertas 
limitaciones y recomendaciones que se puedan encontrar al trabajar con la aplicación 
Incident Dashboard Mobile. 
  
4 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
CAPÍTULO I  
GENERALIDADES 
 
  
 Este capítulo presenta la descripción de los conceptos relacionados con la 
Gestión  de Servicios de Información. Se delimitará el alcance de la presente tesis al 
proceso de Gestión de Incidencias que es parte de la gestión de servicios, así mismo 
se definirán los indicadores de rendimiento del proceso. Se mostrará la importancia de 
los indicadores y la transcendencia de generación de cuadros resúmenes que 
muestren la situación actual y evolución en el tiempo de los mismos. 
 
1.1. Marco Conceptual 
 
 En esta sección se describirán los conceptos y definiciones que se han 
considerado para constituir el diseño e implementación de la aplicación Incident 
Dashboard Mobile. Entre los temas a precisar tenemos: los conceptos de Gestión de 
Servicios de Información y el proceso de Gestión de Incidencias, y cómo estos influyen 
en las empresas del sector de Tecnología e Información. También se trata la 
importancia de los indicadores del proceso de Gestión de Incidencias para una 
corporación. 
  
5 
 
1.1.1. Gestión de Servicios 
 
La Gestión de Servicios de Información (GSI) es la administración de todos los 
procesos que cooperan para asegurar la calidad de los servicios de información 
brindados por la empresa, siguiendo los compromisos adquiridos en los acuerdos de 
nivel de servicio con los clientes. La GSI abarca la concepción, diseño, organización, 
administración, aprovisionamiento, soporte, y mejoras sobre los servicios de 
información para suplir las necesidades de la empresa. 
 
Existen estándares como ITIL (Information Technology Infrastructure LibraryTM) e ISO 
20000 que son un conjunto de mejores prácticas para la gestión de servicios TI 
(Tecnología e Información). A continuación se muestra el cuadro que describe 
aquellos procesos que conforman la gestión de servicios TI [1]: 
 
Cuadro 1: Descripción de procesos de la Gestión de Servicios 
Proceso Descripción 
Gestión Financiera 
(Financial Management) 
Permite que la organización provea 
completa justificación de los gastos y 
relacionarlos con determinado servicio. 
Gestión del Catálogo de Servicios 
(Service Catalogue Management) 
Permite el desarrollo y mantenimiento 
del catálogo de servicio que contiene 
precisos detalles sobre los servicios 
brindados por la empresa y las 
relaciones entre estos 
Gestión de Nivel de Servicio 
(Service Leve Management) 
Permite la gestión de acuerdos de nivel 
de servicio tanto para proveedores 
como para clientes de la empresa. 
Gestión de Cambios 
(Change Management) 
Permite administrar los cambios que se 
dan sobre los servicios, aplicaciones e 
infraestructura de la organización 
Gestión de la Configuración y 
Activos 
(Service Asset and Configuration 
Management) 
Tiene el propósito de proveer un 
modelo lógico de la infraestructura TI 
de la empresa. De tal manera que se 
relacionen los servicios con los activos 
de la empresa. 
6 
 
 Proceso Descripción 
Gestión del conocimiento 
(Knowledge Management) 
Tiene el propósito de mejorar la calidad 
del proceso de toma de decisiones 
asegurando que la información sea 
confiable durante el ciclo de vida del 
servicio. 
Gestión de Incidencias 
(Incident Management) 
Se encarga de atender todas las 
incidencias reportadas en la organización, 
con el propósito de resolver lo más pronto 
posible cada una de estas. 
Gestión de Problemas 
(Problem Management) 
Controla el ciclo de vida de un problema, 
que por definición es la causa 
desconocida de una o más incidencias. 
 
Fuente: IT Service Management – An Introduction 
 
La presente tesis se ha enfocado en el proceso de gestión de incidencias el cuál será 
descrito con mayor detalle en la siguiente sección. 
 
1.1.2. Gestión de incidencias 
 
La Gestión de Incidencias maneja todas las incidencias que se pueden generar 
en los servicios brindados por la organización. Las incidencias pueden ser fallas, 
preguntas o consultas reportadas por los usuarios, personal técnico, o herramientas de 
monitoreo que detectan fallas o comportamientos anómalos. 
 
Según ITIL una incidencia es cualquier interrupción o reducción de la calidad de 
servicio no planificada de un servicio TI. De esta manera que el objetivo principal de la 
Gestión de Incidencias es reanudar la operación normal de los servicios que pueden 
ser afectados por las incidencias, como, por ejemplo, el reinicio urgente del servidor 
que gestiona el registro de las ventas de un operador de telecomunicaciones [1]. 
 
7 
 
La gestión de incidencias ofrece valor, desde el punto de vista de negocio, desde que 
ofrece: 
- La posibilidad de rastrear y resolver incidencias reduciendo así el tiempo que el 
servicio no se encuentra disponible; esto resulta en el mejoramiento del 
porcentaje de disponibilidad del servicio. 
- La posibilidad de alinear las operaciones IT a las necesidades de negocio, ya 
que permite identificar las prioridades del negocio y redistribuir los recursos de 
forma dinámica. 
- La posibilidad de establecer potenciales mejoras en los servicios ofrecidos por 
la empresa 
 
En el siguiente cuadro se muestra la secuencia y descripción de los pasos de la 
gestión de una incidencia: 
 
Cuadro 2: Pasos del proceso de gestión de una incidencia 
Actividad Descripción 
1. Identificación En esta etapa se identifica si la incidencia es 
propiamente una incidencia que es necesario 
reportar. 
2. Registro En esta etapa se lleva a cabo el registro de la 
incidencia en el Sistema de Mesa de Ayuda o 
de Gestión de Servicios 
3. Clasificación Esta etapa tiene el propósito de realizar la 
clasificación de la incidencia según la criticidad 
y urgencia de la misma. 
4. Priorización Una vez clasificada la incidencia la misma es 
priorizada por los canales de atención 
siguiendo los parámetros definidos por la 
empresa 
5. Diagnóstico El personal técnico asignado para resolver la 
incidencia busca realizar el diagnóstico del 
problema de acuerdo a los datos de registro. 
8 
 
6. Escalamiento Si es que la incidencia necesita ser escalada a 
un grupo técnico con mayor pericia en el 
problema entonces en esta etapa se realizan 
las reasignaciones. 
Actividad Descripción 
7. Investigación y Diagnosis El grupo técnico asignado a la incidencia 
realiza una investigación de las posibles 
causas, y brinda, entonces, un diagnóstico 
más acertado de la incidencia. 
8. Resolución En esta etapa se llevan a cabo las tareas para 
el restablecimiento del servicio y lo necesario 
para resolver la incidencia. 
9. Cierre Finalmente, si el cliente se encuentra 
satisfecho con la resolución de la incidencia 
entonces esta es cerrada, lo que significa que 
no podrá ser modificada o reabierta después 
de que haya pasado a este estado. 
 
Fuente: IT Service Management – An Introduction 
 
Para lograr un control sobre todas las actividades ejecutadas por este proceso se 
construyen cuadros de resumen, como los mencionados anteriormente, con diferentes 
frecuencias (diaria, semanal, mensual) y temática que muestran la evolución o estado 
actual de los diferentes indicadores que el proceso de Gestión de Incidencias posee. 
Estos serán atendidos con mayor profundidad en la siguiente sección. 
 
  
9 
 
1.1.3. Indicadores del proceso de Gestión de Incidencias 
 
Un indicador, en el contexto de Gestión de Servicios, es básicamente una 
métrica que permite evaluar y controlar un proceso de gestión, como la gestión de 
incidencias, cambios o problemas. Los indicadores son construidos de acuerdo a los 
requerimientos del cliente, de tal manera que estos puedan indicar cuan alineados 
están los servicios ofrecidos por la empresa con las necesidades de sus clientes. 
Estos son monitoreados con frecuencia para poder identificar oportunidades de mejora 
en los servicios brindados por la corporación. 
 
Estos indicadores mayormente conocidos como “KPIs”, por sus siglas en inglés “Key 
Performance Indicators” (Indicadores de Rendimiento), se pueden definir para cada 
uno de los procesos indicados en la tabla 1; sin embargo, no es objetivo de la presente 
tesis identificar los indicadores de cada uno de los procesos descritos en la tabla, sino 
se concentrará en el proceso de Gestión de Incidencias por ser el proceso que es foco 
de investigación para el logro de los objetivos de la presente tesis [15]. 
 
Los indicadores de rendimiento pueden ser métricas porcentuales o escalares según 
la definición de los mismos para mostrar de forma más directa la métrica realizada. 
Entre los indicadores más importantes del proceso de Gestión de Incidencias tenemos: 
 
- Porcentaje de incidencias resueltas por la primera línea de soporte 
En el proceso de Gestión de incidencias se tienen varios niveles de 
atención, a mayor nivel mayor pericia técnica en el tratamiento de la 
incidencia. El primero nivel de atención se encuentra conformado por el 
personal de Mesa de Ayuda que realiza las primeras tareas de diagnóstico y 
resolución. Si es que estas tareas no son suficientes para restablecer el 
servicio entonces la incidencia es asignada al siguiente nivel de atención. 
 
- Tiempo de llamada promedio sin escalamiento 
Este indicador señala el tiempo de promedio de duración de las llamadas a 
Mesa de Ayuda siempre y cuando la incidencia haya sido resuelta en el 
transcurso de esta llamada. 
 
  
10 
 
- Porcentaje de incidencias erróneamente asignadas 
Relación porcentual de aquellas incidencias que han sido erróneamente 
asignadas durante su tiempo de vida. Por ejemplo, una incidencia en el 
servidor de base de datos, fue asignada al grupo técnico que atiende 
incidencias generadas en el sistema operativo de los servidores de la 
empresa. 
 
- Número de incidencias gestionadas 
Número de incidencias que han sido gestionadas durante un periodo de 
tiempo, esta es la suma de aquellas incidencias pendientes al iniciar el 
periodo y las incidencias que fueron registradas en el mismo periodo. 
 
- Número de incidencias resueltas por Mesa de Ayuda 
Número de incidencias resueltas por la Mesa de Ayuda ya sea en la primera 
asignación o porque la incidencia fue reasignada a Mesa de Ayuda para 
seguir instrucciones enviadas por los niveles superiores de atención. 
 
- Número de incidencias gestionadas por el segundo nivel o tercer de 
atención 
Indica el número de incidencias que en algún momento de su ciclo de vida 
fueron asignadas a los niveles superiores de atención, ya sea el segundo o 
tercer nivel de atención. 
 
- Porcentaje de incidencias resueltas el segundo o tercer nivel de atención 
Relación entre la cantidad de incidencias resueltas en segundo o tercer nivel 
de atención y el total de incidencias resueltas. 
 
1.2. Definición del problema 
 
Esta sección pretende enmarcar y delimitar el problema principal tratado en la 
presente tesis y los problemas específicos que el anterior pueda generar. También se 
fija el objetivo general y los objetivos específicos que permitirán evaluar el avance de 
la tesis como trazar la línea de acción para el logro de los mismos. Finalmente se 
ofrecen los resultados que se esperan de proyecto planteado en la presente tesis. 
 
  
11 
 
1.2.1. Planteamiento del problema 
 
 Los cuadros resumen, que muestran la situación actual y el cambio en el 
tiempo de los indicadores del proceso de Gestión de Incidencias, son necesarios para 
definir las prioridades de atención de incidencias, encontrar aquellos servicios que 
generan la mayor cantidad de incidencias, localizar los grupos de atención de 
incidencias que responden con mayor rapidez en la resolución de las incidencias, 
hallar las posibles causas de incidencias y en donde se generan las mismas, encontrar 
si las incidencias están disminuyendo o aumentando a través del tiempo, entro otros 
aspectos que son evaluables a partir de los indicadores de rendimiento (KPIs). 
 
La problemática principal tratada en la presente tesis consiste en, si es que se da el 
caso de que la empresa no posee una herramienta que automatice, centralice y ponga 
a disposición los cuadros de resumen; entonces la generación de los mismos se 
vuelve tediosa, laboriosa e ineficiente, ya que implica tener un recurso1 dedicado a la 
elaboración, interpretación y distribución de los mismos. 
 
Al tener un recurso dedicado a la elaboración de estos cuadros resumen se pueden 
dar los siguientes inconvenientes: 
- Errores humanos en el procesamiento de los datos del proceso de Gestión de 
Incidencias. 
- Dedicación de una jornada o más jornadas de trabajo exclusivamente para la 
generación de los cuadro resumen. 
- Falta de actualización en los indicadores mostrados en los cuadros. 
- Falta de control sobre los clientes o usuarios de los cuadros de resumen. 
 
Para realizar una evaluación más organizada y detallada sobre los problemas que 
originan no poseer una herramienta de generación y presentación de cuadros resumen 
del proceso de Gestión de Incidencias; se decidió utilizar la técnica del árbol de 
problemas. 
 
La Técnica de Árbol de Problemas consiste en una técnica que ayuda a desarrollar 
ideas para identificar el problema central y organizar la información recolectada, 
generando un modelo de relaciones causales que lo explican. Esta técnica facilita el 
1 En el contexto de la presente tesis se considera como recurso a un empleado de la empresa 
o perteneciente a una empresa colaboradora. 
12 
 
                                               
reconocimiento y organización de las causas y efectos de un problema. El tronco del 
árbol es el problema centra, las raíces son las causas y las ramas los efectos. A 
continuación, en la Figura 1, se presenta el Árbol de Problemas referente a la 
generación de cuadros resumen sin que la empresa posea una herramienta dedicada 
a esta tarea [2]. 
 
Del Árbol de Problemas mostrado en la Figura 1 se puede identificar que en la parte 
inferior se encuentran las “Causas”, y en la parte superior los “Efectos”, de la 
existencia del problema central. 
13 
 
Desorganización, descontrol e indisponibilidad parcial de la 
generación y presentación de cuadros de resumen de 
métricas e indicadores del proceso de gestión de 
incidencias
La herramienta de gestión 
de incidencias no cuenta con 
un módulo de presentación 
de cuadros resumen
Los informes ofrecidos por 
la herramienta de gestión de 
incidencias no satisfacen las 
necesidades de la 
organización
Los cuadros de 
resumen son enviados 
vía correo electrónico 
u otros medios sin 
control de versionado
Los cuadros de resumen 
son generados de forma 
manual por recursos 
asignados a la 
construcción de los 
mismos
Los informes son 
generados por diferentes 
personas y áreas
Información suceptible a 
errores manuales
Información no 
necesariamente 
actualizada
Discordancia entre los datos 
generados por diferentes 
áreas o personas
Insatisfacción por 
parte de los clientes 
de la información
Incumplimiento de 
tiempos por parte de los 
recursos asignados
 
Figura 1: Árbol de Problemas 
Fuente: Elaboración propia
14 
 
Entre las causas mostradas en la Figura 1 se detallan las siguientes: 
- En ocasiones las herramientas de gestión de incidencias se concentran en la 
operatividad del proceso pero, en lo que respecta a generación de cuadros de 
resumen no ofrecen muchas opciones o ninguna para poder representar la 
situación actual o la evolución del proceso de Gestión de Incidencias. 
- Los cuadros de resumen generados distribuidos por correo electrónico o 
dispositivos de almacenamiento como, memorias flash USB o discos portables; 
o también por gestores documentales como SharePoint de Microsoft. Esto 
causa desorden al hacer consolidaciones de los indicadores ya que, en 
ocasiones, no se sabe cuál es la última versión del cuadro de resumen, o se 
debe rebuscar en la bandeja de correos electrónicos recibidos o enviados. 
- Los cuadros resumen son generados de forma manual por el personal que 
pertenece al proceso de Gestión de Incidencias, haciendo la manipulación de 
los datos susceptible a errores humanos. 
- Los cuadros resumen son generados por personas diferentes, en áreas 
diferentes o hasta en empresas diferentes, todas con distintos enfoques y 
maneras diversas de filtra la información, de tal manera que se aumenta la 
probabilidad de encontrar diferencias entre cuadros generados por diferentes 
fuentes, ya sea porque se hizo un filtro diferente de la información o porque los 
criterios de búsqueda y presentación no son los mismos en todos los casos. 
 
Entre los efectos señalados anteriormente se detallan los siguientes: 
- La información mostrada en los cuadros es susceptible  a errores manuales si 
es que no existe una herramienta que automatice el proceso de construcción 
de cuadros de resumen. 
- La información no necesariamente se encuentra actualizada en cada cuadro 
construido de forma manual, ya que el proceso de Gestión de Incidencias es un 
proceso que genera información día a día, y dependiendo de los errores que se 
generen en los servicios, esta información puede cambiar de manera dinámica. 
Por lo anterior, la probabilidad de que un cuadro ya no se encuentre 
actualizado es igual a la probabilidad de que se genere una incidencia en los 
diferentes servicios que la empresa gestione. Por ejemplo, el cuadro que un 
empleado hizo el día de hoy, podría estar desactualizado al día de mañana, la 
próxima semana o hasta el próximo mes, haciendo que la construcción de los 
informes sea una constante en la organización. 
15 
 
- Generalmente la información del proceso de Gestión de Incidencias es 
explotada por una o más áreas dentro de la empresa como, por ejemplo, puede 
ser usada por el área que gestiona a la Mesa de Ayuda y por el área que 
gestiona las aplicaciones de la empresa, o también puede ser usada por los 
proveedores de soporte2. De esta manera se generan discordancias en los 
diferentes informes ya sea porque se usaron diferentes filtros, conteos, y 
promedios de una misma fuente de información. 
- Los cuadros de resumen, según su frecuencia, tienen un determinado tiempo 
de entrega, es decir la fecha límite en el que los cuadros tiene que estar listos 
para ser presentados al personal cliente de esta información. De esta manera, 
si el recurso asignado a la generación de los informes está sobrecargado de 
trabajo entonces, es probable, que los tiempos de presentación de informe no 
se cumplan si es que estos llevan la ejecución de filtros complejos y tediosos 
de realizar desde la herramienta de cálculo que se utiliza para la construcción 
de los cuadros. Haciendo así que los tiempos de entrega no sean cumplidos en 
el cien por ciento de los casos. 
- Finalmente, de acuerdo a los efectos anteriormente detallados, existe un efecto 
más que tiene relación con la percepción del cliente que es el usuario final de 
estos cuadros. Ya que, al no tener los cuadros actualizados y a tiempo se 
genera cierto grado de insatisfacción ante el cliente interno o externo de la 
empresa. 
 
De acuerdo a los puntos anteriormente descritos, surge la necesidad de poder 
organizar, simplificar, automatizar y centralizar el proceso de generación de cuadros 
resumen y poner a disponibilidad de los clientes de la información. En respuesta a esta 
necesidad la presente tesis entrega una propuesta para lograr todos estos objetivos 
proponiendo una solución para dispositivos móviles. 
 
1.2.2. Objetivo General 
 
 El objetivo central de la presente tesis es coadyuvar al proceso de Gestión de 
Incidencias a través del mejoramiento del proceso de construcción y presentación de 
cuadros de resumen que muestren métricas e indicadores de la gestión de incidencias. 
 
2 Se conoce como proveedores de soporte a aquellas empresas que proveen servicios de 
mantenimiento o atención de incidencias a la empresa cliente. 
16 
 
                                               
1.2.3. Objetivos Específicos 
 
 Se ha decidido utilizar la Técnica de Árbol de Objetivos para realizar la 
evaluación de los objetivos específicos de la presente tesis. 
 
La Técnica de Árbol de Objetivos viene a ser la visión positiva de la Técnica de Árbol 
de Problemas. Esta permite determinar las áreas de intervención que plantea el 
proyecto. Para su elaboración se parte del Árbol de Problemas. Es necesario revisar 
cada problema y convertir el mismo en un objetivo realista y deseable. De tal manera 
que las causas se convierten en medios y los efectos en fines. En la Figura 2 (página 
siguiente), se presenta el Árbol de Objetivos de la presente tesis. 
 
Del Árbol de Objetivos exhibido en la Figura 2 se puede identificar que en la parte 
superior se encuentran los “Fines” del objetivo principal. Los “Fines” son la 
representación positiva de los “Efectos” del problema principal presentado en el Árbol 
de Problemas de la Figura 1. 
 
En la parte inferior del Árbol de Objetivos se encuentra los “Medios” para poder cumplir 
con el objetivo central. Los “Medios” buscan dar remedio a las “Causas” presentadas 
en el Árbol de Problemas de la Figura 1. Es a partir de estos “Medios” que se accede a 
identificar más detalladamente los objetivos específicos del objetivo central. 
 
De acuerdo a lo anteriormente mencionado, según el Árbol de Objetivos mostrado en 
la Figura 2, los objetivos específicos de la presente tesis son: 
 
- Elaborar el análisis y diseño de una herramienta que permita la presentación 
de indicadores y métricas del proceso de Gestión de Incidencias que pueda ser 
utilizada desde dispositivos móviles. 
- Elaborar una Arquitectura que permita que la aplicación marche en dispositivos 
móviles con conexión a Internet. 
- Elaborar una herramienta que centralice y automatice la construcción de 
cuadros de resumen del proceso de Gestión de Incidencias. 
- Elaborar una herramienta que no necesite de la intervención manual para el 
procesamiento, filtrado y presentación de los datos. 
  
17 
 
 Figura 2: Árbol de Objetivos 
Fuente: Elaboración propia
18 
 
1.2.4. Resultados Esperados 
 
 Luego de definir los cuatro objetivos específicos planteados en la sección 
anterior. De la presente tesis se esperan los siguientes resultados: 
 
- La presentación de una aplicación móvil compatible con dispositivos cuyo 
sistema operativo esté basado en Android3. Esta aplicación alcanzará la lectura 
de los datos necesarios para la presentación de indicadores y métricas 
correspondientes al proceso de Gestión de Incidencias. 
- El diseño de una arquitectura que permita el funcionamiento de la aplicación 
desde un dispositivo conectado a Internet a través de un punto de acceso o a 
través la red de datos celular. 
- La presentación de una aplicación que permita la autenticación del usuario y 
proteja los datos transmitidos o recibidos desde el servidor de aplicación a 
través de Internet. 
- La presentación de una aplicación que minimice la cantidad de datos 
transmitidos entre el servidor de aplicación y el dispositivo móvil. 
- La presentación de una aplicación que permita visualizar a través de cuadros 
resumen las estadísticas de los indicadores y métricas del proceso de Gestión 
de Incidencias definidos por ITIL. 
 
1.3. Plan de Proyecto 
 
1.3.1. Métodos y procedimientos 
 
 Para el tratamiento de la presente tesis se empleó la metodología RUP 
(Rational Unified Process). A continuación, se describirá en forma breve esta 
metodología y la justificación de su uso. 
 
Descripción 
 El Proceso Unificado Racional o RUP es un proceso de desarrollo de software 
y junto con el Lenguaje Unificado de Modelado, UML por sus siglas en inglés, 
constituye una de las metodologías más extendidas y conocidas debido a su amplia 
difusión comercial [14]. 
 
3 Android es un sistema operativo desarrollado por Android, Inc., que fue adquirido por Google 
en julio del 2005. Este es usado en gran cantidad de teléfonos inteligentes y tabletas [5]. 
19 
 
                                               
RUP es un producto creado por RATIONAL (IBM). Se caracteriza por ser iterativo e 
incremental, se concentra en la arquitectura y se orienta en los casos de uso. 
Incorpora artefactos (productos palpables del proceso como, por ejemplo, el modelo 
de casos de uso, el código fuente, entre otros) y roles (papel que ejerce una persona 
en determinado momento, esta puede desempeñar diferentes roles a lo largo del 
proceso). 
 
Por qué se optó por RUP 
La presente tesis buscó ejecutar la implementación de una aplicación móvil a 
mediano plazo. Por esta razón, para poder administrar la totalidad del desarrollo se 
requirió de una metodología que posibilite ordenar las etapas del proyecto, mantener 
documentación básica para la persistencia y asegurar el manejo de todas las variables 
que podrían afectar al proyecto. 
 
Ya que RUP es una metodología esquematizada específicamente para el desarrollo de 
software, el ciclo de vida que plantea es ordenado en cuanto a sus fases y por ser 
iterativo e incremental, proporciona la posibilidad de ajustar el producto de forma 
precisa a los requerimientos planteados cada vez que se hace una revisión sobre los 
mismos. Ya que considera la utilización de requisitos y el proceso entero depende de 
estos, entonces el cliente podrá recibir lo que necesita. RUP también permite una 
conveniente trazabilidad de los requisitos, hace sencillo el mantenimiento y la 
realización de posibles innovaciones o correcciones en el software desarrollado. 
 
Etapas del desarrollo de software según RUP 
La metodología RUP distribuye el desarrollo del software en cuatro pasos [14]: 
 
• Concepción: En este paso se define el alcance y la visión del proyecto de 
acuerdo al análisis de los requerimientos de la aplicación. Se han elaborado los 
siguientes documentos: Documento de visión, Catálogo de requisitos, 
Especificaciones de requerimientos de software y Documento de análisis. 
 
• Elaboración: Este paso consiste en precisar el diseño y la arquitectura para el 
despliegue de la aplicación. Se elaboran los siguientes documentos: Documento 
de arquitectura, Prototipo de la solución, Plan de pruebas unitarias y de 
integración. 
20 
 
 
• Construcción: En este paso se construirá el sistema y se realizarán los 
exámenes necesarios para certificar el funcionamiento correcto de la aplicación y 
el cumplimiento de los requerimientos. Se construirán las versiones 1.0, Beta y 
Final. 
 
• Transición: Se pondrá a disposición del usuario la versión de la aplicación móvil 
para la realización de pruebas finales. 
 
El desarrollo de la aplicación Incident Dashboard Mobile se llevó a cabo mediante la 
realización de las cuatro etapas anteriormente mencionadas, las cuales fueron 
divididas en iteraciones. A continuación, en el siguiente cuadro se detalla lo ejecutado 
en cada etapa, así también el número de iteraciones elaboradas. 
 
Cuadro 3: Etapas de desarrollo de la aplicación 
Etapa Descripción Iteraciones 
Concepción 
En esta etapa se ejecutó el levantamiento de información 
y las investigaciones necesarias para la solución del 
problema. Así mismo, se realizó el análisis e identificación 
de requerimientos según el cual se construye un avance 
previo de la especificación de requisitos de software 
(ERS4). 
2 
Elaboración 
En esta etapa se completó la especificación de requisitos 
de software en base a los resultados obtenidos en la fase 
de concepción. 
Además se inició el análisis y diseño de la aplicación, 
presentación de prototipo de la aplicación y se especificó 
la arquitectura de software que se utilizará en el desarrollo 
de la misma. 
3 
Construcción 
En esta etapa se realizó el diseño y la programación de la 
aplicación. Además se concretizó el plan de pruebas. 
8 
Transición 
Esta etapa no se desarrolló en la presente  
tesis. 
0 
Fuente: Elaboración propia  
4 Especificación de los requerimientos del software a desarrollar y el comportamiento del 
mismo. 
21 
 
                                               
1.4. Estado del Arte 
 
 A continuación se describirán las aplicaciones que tratan de cubrir las 
necesidades anteriormente mencionadas así como los alcances dependiendo de 3 
características principales: disponibilidad, centralización, fidelidad y confiabilidad de los 
datos mostrados en los cuadros de resumen generados por estas aplicaciones y 
herramientas. 
 
1.4.1 Aplicaciones Existentes 
 
 En esta sección se describirán las aplicaciones existentes que son utilizadas 
actualmente para resolver el problema propuesto en secciones anteriores. Para 
efectos de la presente tesis se ha focalizado la inspección de las características del 
módulo de Gestión de Incidencias de cada herramienta mencionada a continuación, 
más específicamente sobre las funcionalidades que ofrecen para  
 
A. Remedy ITSM 8 
Remedy ITSM 8 es una solución para la Gestión de Servicios TI construida por 
BMC Software Inc., con más de 20 años de experiencia en el mercado. Conecta y 
automatiza los procesos ITIL como: gestión de incidencias, gestión de problemas, 
gestión de cambios, gestión de activos, gestión de niveles de servicio, gestión del 
catálogo de servicio, gestión de requerimientos, entre otros procesos de la gestión 
de servicios. 
 
Remedy ITSM 8 cuenta con el módulo de Gestión de Incidencias que, como su 
nombre lo señala, brinda las funcionalidades necesarias para ejecutar el proceso 
de Gestión de Incidencias. Respecto a estas últimas podemos destacar: 
 
- Presenta cuadros de resumen alineados a los indicadores de rendimiento 
recomendados por ITIL 
- Estos cuadros sólo pueden ser consultados a través de un navegador web 
- Presenta tanto información actual como histórica 
- Son generados automáticamente sin intervención directa del usuario 
- Es necesario estar autenticado para poder acceder a los cuadros de 
resumen 
 
22 
 
A continuación se muestran ejemplos de los cuadros de resumen del proceso de 
Gestión de Incidencias generados en Remedy ITSM 8: 
 
 
Figura 3: Incidencias resueltas a tiempo 
Fuente: Remedy ITSM 8 
  
23 
 
 
Figura 4: Remedy ITSM 8: Back Log de Incidencias 
Fuente: Remedy ITSM 8 
  
24 
 
B. HP Service Manager 
HP Service Manager es una herramienta construida por Hewllet-Packard Conpany 
que ofrece las mimas funcionalidades mencionadas en el primer ejemplo; con la 
diferencia de ofrecer soluciones de almacenamiento de datos en servidores 
distribuidos en Internet. Respecto a los cuadros de resumen del proceso de 
Gestión de Incidencias que esta herramienta ofrece se puede destacar lo 
siguiente: 
 
- Presenta cuadros de resumen alineados a los indicadores de rendimiento 
recomendados por ITIL 
- Estos cuadros sólo pueden ser consultados a través de un navegador web 
- No presenta información histórica del proceso 
- Son generados de forma automática 
- Es necesario estar autenticado para acceder a los cuadros 
 
A continuación se muestran ejemplos de los cuadros de resumen del proceso de 
Gestión de Incidencias generados en HP Service Manager: 
 
 
Figura 5: HP – Incidencias por categoría 
25 
 
 
Figura 6: HP - Incidencias por servicio 
C. OTRS:ITSM 3.3 
OTRS:ITSM 3.3 es la solución para Gestión de Servicios TI ofrecida por OTRS 
Inc. (Open Technology Real Services) que ofrece también las funcionalidades 
necesarias para la gestión de incidencias. Respecto a los cuadros de resumen de 
del proceso de gestión de incidencias se puede destacar: 
 
- No posee cuadros de resumen instalados por defecto en la herramienta 
- Los datos son mostrados en tablas y no en cuadros resumen 
- Presenta información actual o histórica 
- Las tablas pueden ser descargados en formato csv (datos separados por 
comas) o PDF (portable document format) 
- Es necesario estar autenticado para acceder o descargar los reportes 
- Las tablas son generadas de forma automática 
 
A continuación se muestra un ejemplo de las tablas que pueden ser descargadas 
desde OTRS:ITSM 3.3: 
26 
 
 
Figura 7: OTRS - Incidencias según estado 
 
D. Service Desk Plus 8.2 
Service Desk Plus 8.2 es la herramienta de Gestión de Incidencias ofrecida por 
Zoho Corporation y contiene las funcionalidades anteriormente mencionadas. Los 
cuadros de resumen se caracterizan por: 
 
- Presenta cuadros de resumen alineados a los indicadores de rendimiento 
recomendados por ITIL 
- Presenta información actual y no histórica 
- Es necesario estar autenticado para acceder a los cuadros 
- Los cuadros son generados de forma automática 
- Estos cuadros sólo pueden ser consultados a través de un navegador web 
 
A continuación se muestra un ejemplo de cuadro de resumen que pueden ser 
analizados desde Service Desk Plus 8.2: 
27 
 
 
Figura 8: Requerimientos por Categoría y Violaciones de SLA 
 
Figura 9: Número de requerimientos fuera de SLA 
 
1.4.2. Evaluación de Requerimientos de la aplicación Incident Dashboard 
Mobile 
 
En la presente sección se evaluarán las características de las soluciones descritas 
en la sección anterior (1.4.1), las cuales cubre algunos de los requerimientos 
necesarios para la generación y presentación de cuadros de resumen del proceso de 
Gestión de Incidencias. Para efectuar la evaluación, se tomarán en consideración las 
siguientes funcionalidades: 
 
- Disponibilidad de los cuadros de resumen desde fuera de la red corporativa 
28 
 
- Generación automática de los cuadros de resumen del proceso de Gestión de 
Incidencias 
- Debe soportar autenticación de usuarios 
- Las métricas e indicadores mostrados en los cuadros de resumen deben seguir 
los lineamientos de ITIL 
- Los cuadros de resumen pueden ser accedidos desde un dispositivo móvil 
- La presentación debe ser a través de gráficos como, por ejemplo, gráfico de 
barras, gráfico de columnas, gráfico de líneas, entro otros. 
 
En el Cuadro 4 se realiza la comparación de funcionalidades de cada una de las 
soluciones presentadas en la sección anterior: 
 
Cuadro 4: Comparación de herramientas de Gestión de Incidencias 
 Remedy 
ITSM 8 
HP Service 
Manager 
OTRS:ITSM 
3.3 
Service Desk 
Plus 8.2 
Disponibilidad 
desde fuera de la 
red Corporativa     
Generación 
automática 
    
Autenticación de 
usuarios 
    
Lineamientos ITIL 
    
Cliente móvil 
    
Utilización de 
gráficos 
    
Fuente: Elaboración Propia 
 
Del cuadro anterior se puede observar lo siguiente: 
 
• Ninguna de las herramientas ofrece disponibilidad desde fuera de la red 
corporativa como una funcionalidad fundamental de la aplicación, sino que es 
necesario hacer adecuaciones en la arquitectura de la solución para ofrecer 
29 
 
esta funcionalidad. Por ejemplo, sería necesario agregar un servidor web en la 
zona desmilitarizada de la red corporativa con las restricciones necesarias. 
• Ninguna de las soluciones ofrece una aplicación móvil o ha adaptado su 
servicio web para dispositivos móviles para la presentación de cuadros de 
resumen que muestren los indicadores del proceso de Gestión de Incidencias. 
• Es necesario que los cuadros resumen sigan los lineamientos de ITIl ya que 
esto se ha vuelto prácticamente un estándar en la construcción de reportes, 
informes o cuadros de resumen de los procesos de Gestión de Servicios TI. 
 
Según lo señalado en las observaciones anteriores, se puede observar que las cuatro 
herramientas proveen cierto grado de automatización, centralización y se encuentran 
alineadas a las recomendaciones de ITIL. Sin embargo no ofrecen la movilidad, 
simplificación y disponibilidad que una aplicación móvil ofrece a sus usuarios. De esta 
manera, se plantea la necesidad de creación de una aplicación móvil (Incident 
Dashboard Mobile) que tenga como objetivo incorporar las funcionalidades que 
ofrecen estas herramientas y además integre las ventajas ofrecidas por una aplicación 
móvil mencionadas en la oración anterior. 
 
1.4.3. Requisitos de la aplicación móvil Incident Dashboard Mobile 
En la presente sección se precisará las funcionalidades mínimas que deberá 
satisfacer la aplicación móvil Incident Dashboard Mobile. Estas se listan a 
continuación: 
 
- El usuario podrá instalar y acceder a la aplicación desde un dispositivo móvil 
- La información transmitida a través de Internet entre el servidor de la aplicación 
y el dispositivo móvil debe viajar de manera protegida 
- El usuario deberá autenticarse para poder ingresar a la aplicación 
- La aplicación no deberá demorar más de diez segundos en mostrar el informe 
escogido por el usuario 
- La aplicación deberá ser accedida desde el exterior de la red corporativa 
  
30 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
CAPÍTULO II  
ANÁLISIS 
 
 
 En este capítulo, se presentan las herramientas y soluciones de software que 
se han empleado para el diseño e implementación de la presente tesis. Por último se 
presentará el análisis a alto nivel de la aplicación mediante el Diagrama de clases, el 
catálogo de actores que intervienen, y la presentación del caso de uso. 
 
2.1 Identificación de Requerimientos 
 
En esta sección se exhibirán los requerimientos funcionales y no funcionales 
de la aplicación Incident Dashboard Mobile. A cada uno de los requerimientos se ha 
asignado un nivel de prioridad, con la finalidad de priorizar todos aquellos que sean los 
más primordiales y que contribuyan a lograr los objetivos de la presente tesis 
(Prioridad 1); para luego proseguir con aquellos requerimientos que puedan dar un 
valor agregado a la aplicación (Prioridad 2). 
 
  
31 
 
2.1.2 Requerimientos Funcionales 
 
Por definición, un requerimiento funcional es aquel que determina el 
comportamiento interno de la aplicación. Este delinea principalmente los detalles 
técnicos, cálculos, manipulación de datos y otras funcionalidades específicas. La 
definición de estos requerimientos es importante para demostrar el avance del 
proyecto y focalizar el esfuerzo para tener una aplicación funcional como producto 
final. 
 
En el siguiente cuadro se detallan los requerimientos funcionales de la aplicación: 
 
Cuadro 5: Lista de requerimientos funcionales 
 Requerimiento Prioridad 
1 
La información debe ser transmitida de forma segura a través 
de Internet. 
1 
2 
La aplicación debe solicitar credenciales a los usuarios para 
poder hacer uso de la misma. 
1 
3 
La aplicación debe presentar como mínimo cuatro cuadros de 
resumen de en la versión 1. 
1 
4 
La aplicación debe brindar la posibilidad de ser accedida desde 
Internet. 
1 
5 
La aplicación podrá ser instalada y ejecutada desde un 
dispositivo móvil 
1 
6 
El tiempo de respuesta para presentación de cada cuadro de 
resumen una vez elegido debe de ser menor a diez segundos 
1 
7 
Los indicadores y métricas mostrados por la aplicación deben 
seguir los lineamientos definidos por ITIL. 
1 
8 
La aplicación ejecutará la generación y presentación de los 
cuadros de resumen de forma automática sin mayor 
participación del usuario 
1 
Fuente: Elaboración propia 
 
 
  
32 
 
Respecto a los requerimientos señalados en el cuadro anterior es necesario señalar: 
 
Se eligen cuatro cuadros como mínimo para levantar la versión 1.0 de la aplicación 
para poder brindar una visión general del proceso de Gestión de Incidencias y verificar 
la satisfacción del cliente en la presentación de los cuadros de resumen. Y según los 
resultados poder realizar ajustes y mejoras al formato de los cuadros. 
 
Señalar que la participación del usuario debe ser mínima significa que el usuario no 
tendrá acceso a la información fuente, no procesará esta información, sino se limitará 
a elegir el cuadro resumen que desea observar y así la aplicación se encargará del 
procesamiento y presentación de los cuadros. 
 
2.1.2 Requerimientos No Funcionales 
 
Por definición, un requerimiento no funcional es una propiedad requerida del 
sistema, del proceso de desarrollo, del servicio prestado o de cualquier otro aspecto 
del desarrollo que no se satisface añadiendo código, sino agregando esta 
característica como si fuese una limitación. 
 
En la sección anterior, los requerimientos funcionales de la aplicación abarcaron los 
requerimientos necesarios para que la aplicación automatice y centralice la ejecución y 
presentación de los cuadros de resumen que esta entregará. De esta manera se 
cubren dos de los objetivos específicos señalados en la sección 1.2.3. Finalmente la 
definición de los requerimientos no funcionales tiene como meta definir las 
características necesarias de la aplicación para lograr los dos objetivos restantes que 
señalan el camino a seguir respecto a la arquitectura de la solución y que la aplicación 
debe ser ejecutada en dispositivos móviles. A continuación en el Cuadro 6  se señalan 
los requerimientos no funcionales: 
 
Cuadro 6: Lista de requerimientos funcionales 
REQUERIMIENTOS NO FUNCIONALES 
1 La aplicación utilizará MySQL como motor de base de datos. 
2 La aplicación utilizará como plataforma el sistema operativo Android 
3 
La construcción de la aplicación asumirá que el proceso de integración de 
bases de datos ya sido ya diseñado y desarrollado. 
33 
 
4 
La aplicación utilizará en lenguaje de programación Java específicamente las 
librerías adaptadas el sistema operativo Android para el desarrollo del cliente 
de la aplicación. 
5 
La aplicación utilizará el lenguaje PHP 5.3 para el desarrollo de las web 
services. 
6 
La aplicación utilizará las librerías de Google Charts5 para el desarrollo de los 
cuadros de resumen propiamente dichos. 
7 
La aplicación buscará transmitir la menor cantidad de datos entre el dispositivo 
móvil y el servidor de aplicación. 
8 La aplicación buscará reducir el número de consultas a servidor de aplicación. 
Fuente: Elaboración propia 
 
Según la información listada anteriormente, la aplicación utilizará el motor de base de 
datos MySQL por ser una base de datos de rápida instalación y de distribución 
gratuita. El cliente móvil de la aplicación será ejecutado sobre la plataforma Android 
esto excluye a aquellos dispositivos que tienen otros sistemas operativos como: IOS 
de la empresa Apple Inc., Windows Phone de la empresa Microsoft Corporation, entre 
otros sistemas operativos con menos participación en el mercado de los dispositivos 
Móviles. 
 
También se han elegido las librerías Google Charts ofrecidas por Google Inc. ya que 
su distribución es gratuita y ofrecen las funcionalidades suficientes para efectos de la 
presente tesis. Mayores detalles acerca de los lenguajes de programación preferidos 
para el desarrollo de la presente tesis pueden ser consultados en la sección 4.1. 
 
2.2. Análisis de la solución 
 
 En esta sección se presentará el análisis de las tareas ejecutadas por los 
usuarios de la aplicación Incident Dashboard Mobile. Este análisis permitirá sustentar 
la viabilidad de la solución propuesta en la presente tesis. Finalmente se realizará el 
análisis tecnológico sobre las tecnologías que fueron seleccionadas para ser utilizadas 
durante el desarrollo de la aplicación. 
 
  
5 Google Charts es un conjunto de librerías creado por Google Inc., para la creación de gráficos 
estadísticos y la visualización de los mismos en un cliente web. 
34 
 
                                               
2.2.1. Evaluación de viabilidad y consideraciones sobre el sistema 
 
 Los indicadores y métricas son necesarios para evaluar el buen estado de los 
servicios brindados por la organización, ya que permite verificar que se cumplen los 
límites fijados en los acuerdos de servicio pactados entre proveedores de servicio y 
clientes de la empresa. De esta manera, si los indicadores son positivos o negativos la 
empresa podrá tener el conocimiento necesario para focalizar recursos y esfuerzos  
hacia aquellos servicios que lo requieran. 
 
Sin embargo, los reportes de indicadores de rendimiento (KPIs), que se dan a través 
de cuadros de resumen, por lo general son generados de forma manual por algún 
recurso asignado por la empresa, lo que da a lugar a posibles errores manuales, 
discordancias en los resultados finales, los cuadros resumen pueden encontrarse 
desactualizados en el tiempo y otros errores mencionados en secciones anteriores 
(sección 1.2). 
 
Por lo mencionado anteriormente, la presente tesis plante al desarrollo de una 
aplicación móvil que automatice, centralice y ponga a disposición los cuadros de 
resumen de los indicadores para el proceso de Gestión de Incidencias. Esta aplicación 
ofrecerá las siguientes ventajas respecto a las soluciones mencionadas en la sección 
1.4.: 
 
• Incident Dashboard Mobile ofrecerá la capacidad de acceder a los cuadros de 
resumen desde cualquier lugar, siempre y cuando se cuente con acceso a 
Internet, ya sea a través de un punto de acceso o utilizando la red de datos 
celular. 
• Incident Dashboard Mobile ofrecerá una alternativa de automatizar y centralizar 
la construcción de cuadros de resumen de los indicadores del proceso de 
Gestión de incidencias. 
• La aplicación será una de ahorro de recursos y tiempo, lo que se deriva en 
ahorro de dinero en el costo de la generación de los cuadros de resumen. El 
ahorro equivaldría al costo de una jornada de trabajo del recurso dedicado a 
generar los cuadros.  
• La aplicación ofrecerá una alternativa de eliminación de errores manuales y 
discordancias en los cuadros generados por personas, áreas, o empresas 
diferentes. 
35 
 
De acuerdo a las ventajas, el desarrollo de la aplicación Incident Dashboard Mobile 
tiene como objeto cumplir con los siguientes atributos de calidad: 
 
• Performance: El tiempo de generación y presentación no deberá ser mayor a 
5 segundos. 
• Disponibilidad: La aplicación estará disponible las 24 horas del día, los 7 días 
de la semana. 
• Utilidad: La aplicación presentará una interfaz visual y amigable, guiando 
directamente al usuario hacia los cuadros de resumen sin tener que ingresar a 
demasiadas opciones. 
• Escalabilidad: La aplicación estará diseñada de forma que se puedan sumar 
nuevas funcionalidades sin que esto afecte de manera drástica el código. 
• Seguridad: El acceso a la aplicación estará restringido a los usuarios que 
cuenten con las credenciales necesarias y, los datos transmitidos entre cliente 
y servidor viajarán de forma protegida. 
 
2.2.2 Análisis Técnico 
 
 Para realizar la elección de las tecnologías y herramientas que se han 
empleado en el desarrollo de la aplicación Incident Dashboard Mobile se han 
considerado los siguientes criterios: 
 
• Que las tecnologías a emplear presenten una curva de aprendizaje no muy 
extensa. 
• Que las tecnologías a emplear tengan suficiente documentación y soporte 
técnico disponible. 
• Que el motor de base de datos presente rapidez en la lectura, ejecución de 
conteos y administración de datos. 
• Que el motor de base de datos soporte concurrencias de consultas al mismo 
tiempo. 
• Que el servidor de aplicación presente facilidad en su configuración y 
administración. 
• Que el servidor de aplicación presente documentación y soporte técnico 
disponible. 
 
36 
 
Teniendo en cuenta estos criterios se procedió a la elección de las siguientes 
tecnologías: 
 
Motor de base de datos MySQL 
MySQL es un motor de base de datos “open source” (sin costo de licencia para fines 
académicos) muy veloz en la ejecución de operaciones y de gran rendimiento. 
Además soporta concurrencia de consultas al mismo tiempo6, este último factor es 
importante a tomar en cuenta en la implementación de la presente tesis ya que se 
estima que uno o más clientes podrían usar la aplicación simultáneamente. También, 
el bajo consumo de este motor de base de datos lo hace ideal para equipos de bajos 
recursos de procesamiento y almacenamiento, con la opción de poder ser instalada, 
para efectos de pruebas, en una computadora personal. Entre las ventajas que 
presenta esta base de datos tenemos: 
 
- Bajo costo en requerimientos para la instalación y construcción de la base de 
datos, ya que debido a su bajo consumen puede ser desplegada en una 
computadora personal o un servidor de bajos recursos. 
- Presenta un uso sencillo para su manejo y administración; además de poseer 
mayor documentación y soporte técnico que otras soluciones “open source” 
(por ejemplo: mongoDB o PostgreSQL). 
 
Servidor Web IIS 
IIS (Internet Information Services) es un servidor web fabricado por Microsoft 
Corporation que es de fácil implementación en ambientes cuyo sistema operativo es 
Windows 7 Professional Edition o Ultimate Edition. En estos dos sistemas el servidor 
IIS viene por defecto como una de las características de Windows. Entre las ventajas 
que presenta este servidor tenemos: 
 
- Puede ser instalado en cualquier computadora personal que tenga los sistemas 
operativos mencionados anteriormente. 
- Su instalación es sencilla y existe documentación abundante acerca de las 
configuraciones que se pueden realizar. 
6 Concurrencia de consultas hace referencia al momento en el dos o más clientes de la 
aplicación realizan consultas a la base de datos al mismo tiempo. 
37 
 
                                               
- La habilitación del servidor para poder recibir consultas y ejecutar código en 
PHP es sencilla. Este último es un factor importante en la presente tesis ya que 
las “web services” a utilizar están escritas en lenguaje PHP. 
 
Servidor web Apache 
Servidor de licenciamiento “open source”, que será utilizado para desplegar la 
aplicación en un ambiente prototipo para realizar pruebas de tiempo de respuesta en 
un entorno real junto a pruebas de concurrencia de usuarios. Sobre este servidor 
también se levantarán las “web services” que responderán a la versión 1.0 del cliente 
de la aplicación. Entre las ventajas que presenta este servidor tenemos: 
 
- Es un servidor de licenciamiento “open source” lo que significa que la 
adquisición e instalación del servidor es gratis. 
- Puede ser configurado para soportar consultas que exijan la ejecución de 
código PHP. Esto será útil para la ejecución de las “web-services” que se 
comunicarán con el cliente de la aplicación. 
 
Android SDK 
Android SDK es el kit de desarrollo de software distribuido por Google Inc. que provee 
librerías y herramientas de desarrollo de aplicaciones móviles como: depurador de 
aplicaciones, emuladores de dispositivos móviles, documentación, códigos de ejemplo 
y tutoriales. Estos representan una herramienta adecuada para el desarrollo de 
aplicaciones móviles sobre el sistema operativo Android. 
 
2.2.3 Definición del Sistema 
 
 En esta sección se presentará una descripción a alto nivel de la aplicación. A 
continuación se presenta el modelo de casos de uso (modelo que mostrará la 
funcionalidad de la aplicación), el catálogo de actores y el diagrama de clases al final. 
 
A. Modelo de Casos de Uso 
En la presente sección se mostrará el diagrama  de cas de uso de la aplicación el cual 
permitirá mostrar a alto nivel la funcionalidad de la aplicación. En primer lugar se 
definirá el actor que interactuará con la aplicación, luego se mostrará el diagrama de 
caso de uso respectivo al actor definido. 
 
38 
 
El Caso de Uso es una técnica para la especificación de requisitos funcionales que, en 
la actualidad, forma parte de la propuesta de UML. El caso de uso es la descripción de 
una secuencia de interacciones entre la aplicación y uno o más actores en la que se 
considera a la aplicación como una caja negra y en la que los actores obtienen 
resultados observables. 
 
A.1. Catálogo de Actores 
Los actores son usuarios u otras aplicaciones que interactúen con la aplicación. Para 
el caso de la aplicación desarrollada en la presente tesis se tomará en cuenta un solo 
actor, que será el usuario de la aplicación, el cuál es el único que interactuará con el 
cliente de la aplicación desde el dispositivo móvil. 
 
A.2. Casos de Uso 
A continuación se presentará el diagrama del único caso de uso que existe para el 
desarrollo de la aplicación Incident Dashboard Mobile. Existe sólo un caso de uso ya 
que la aplicación sólo cuenta con un paquete central que gestiona la construcción y 
presentación de los cuadros de resumen del proceso de Gestión de Incidencias. 
 
 
Elección del 
cuadro resumen a 
mostrar
 
Figura 10: Caso de uso – Elección del cuadro resumen a mostrar 
Fuente: Elaboración propia 
 
En la Figura 10 podemos apreciar la simplicidad de la aplicación que consiste en la 
elección de un cuadro resumen por el usuario. A continuación la descripción de este 
único caso de uso: 
 
  
39 
 
Cuadro 7: Caso de uso de la aplicación 
CASO DE USO DESCRIPCIÓN 
Elección del cuadro resumen El usuario elige de una lista de cuadros 
resumen mostrados por la aplicación. 
De esta manera la aplicación genera y 
presenta al usuario el gráfico 
estadístico correspondiente. 
Fuente: Elaboración propia 
 
 
2.2.4. Requisitos Específicos: Especificación de Casos de Uso 
 
En la presente sección se detallará la funcionalidad y restricciones de la aplicación de 
las principales funcionalidades de la aplicación. El detalle de la funcionalidad se define 
con la especificación del caso de uso señalado anteriormente: 
  
40 
 
Cuadro 8: Descripción del caso de uso 
Nombre Elección de cuadro de resumen 
Actor Usuario de la aplicación 
Breve descripción Este caso de uso permite al usuario elegir un cuadro 
resumen para ser presentado por la aplicación. 
Precondiciones El usuario se ha autenticado en el sistema 
Flujo Básico 1. El usuario ingresa a la interfaz de inicio de sesión 
de la aplicación e ingresa sus credenciales. 
2. La aplicación presenta la lista de cuadros de 
resumen disponibles para ser elegidos por el 
usuario. 
3. El usuario elige el cuadro resumen que desea 
consultar. 
4. La aplicación guía al usuario hacia la interfaz de 
visualización de cuadros de resumen. 
Flujo Alterno Elegir otro cuadro de resumen 
1. El usuario vuelve a la interfaz en que se listan los 
cuadros de resumen. 
2. El usuario elige nuevamente un cuadro de 
resumen de la lista disponible. 
3. La aplicación guía al usuario hacia la interfaz de 
visualización de cuadro de resumen. 
Flujo Excepcional Volver hacia la interfaz de inicio de sesión 
1. El usuario se encuentra actualmente en la interfaz 
de presentación de cuadros de resumen. 
2. El usuario vuelve a la interfaz en la que se listan 
los cuadros de resumen disponibles. 
3. El usuario retorna a la interfaz de inicio de sesión. 
4. El usuario ingresa credenciales y retorna a alguno 
de los flujos señalados anteriormente. 
Post-condición: No se presentan flujos de post-condición. 
Puntos de extensión: No se presentan Puntos de Extensión. 
Fuente: Elaboración propia 
  
41 
 
2.2.5. Requisitos Específicos: Diagrama de Clases de Análisis 
 
En esta sección se precisará el Diagrama de Clases de la aplicación Incident 
Dashboard Mobile. El Diagrama de Clases de Análisis es un tipo de diagrama estático 
UML que detalla la estructura de la aplicación mostrando sus clases, atributos y 
relaciones entre ellas [16]. 
 
El Diagrama de Clases es utilizado durante el proceso de diseño y análisis de las 
aplicaciones, donde se crea el bosquejo conceptual de la información que se manejará 
en la aplicación, y los componentes que se encargarán de la articulación del sistema y 
la relación entre uno y otro. 
 
En la siguiente figura se muestra el Diagrama de Clases para la aplicación Incident 
Dashboard Mobile: 
42 
 
MainActivity
-dni
-password
ListaCuadrosActivity
-asset_folder
JsonParser
-InputStream
-JSONObjectTesis
-url_user_validation
-json
-SSLContext
Atributos
Métodos
-Ingresar()
Métodos
Atributos
-EXTRA_URL
-Incidencias_por_mes_chart()
-Inc_res_lvl2_4_chart()
GraficadorActivity
Métodos
-OnCreate()
-OnCreate()
-OnCreate()
JsonObjectTesis
Métodos
-getStringTesis()
-getIntTesis()
Métodos
Atributos
-MakeHttpsRequest()
-GetQuery()
E
j
e
c
u
t
a
E
j
e
c
u
t
a
Posee
Posee
Posee
Posee
Posee
-IsOnline()
-CalculateInSampleSize
 
Figura 11: Diagrama de clases 
Fuenta: Elaboración propia 
43 
 
De la figura anterior se puede señalar lo siguiente: 
 
Existen tres actividades principales que son ejecutadas de forma secuencial. Tenemos 
la primera clase, MainActivity cuyo método OnCreate es ejecutado al iniciar la 
aplicación, de esta manera es creada la interfaz de inicio de sesión. Luego si el 
usuario ingresa las credenciales correctas entonces se ejecuta el método OnCreate de 
la clase ListaCuadrosActivity, que genera la interfaz donde se muestra la lista de los 
cuadros disponibles en la aplicación. Finalmente, cuando el usuario elige uno de los 
cuadros se ejecuta el método OnCreate de la clase GraficadorActivity que grafica el 
cuadro de resumen elegido. 
 
La clase JSONParser se encarga de las comunicaciones con el servidor de la 
aplicación haciendo consultas HTTPS y creando e instanciando la clase 
JSONObjecttesis desde la trama JSON7 recibida desde el servidor. De esta manera se 
pueden leer y recibir los datos enviados por el servidor hacia el cliente de la aplicación 
que está siendo ejecutado sobre el dispositivo móvil. 
  
7 JSON (JavaScript Object Notation) es un estándar abierto para formatear objetos y estos 
puedan ser transmitidos entre diferentes sistemas o aplicaciones [5]. 
44 
 
                                               
  
 
 
 
 
 
 
 
 
 
 
 
 
 
CAPÍTULO III 
DISEÑO 
 
 En el presente capítulo se explicará la etapa de diseño de la aplicación la cual 
se enfoca en la arquitectura de la aplicación y el boceto de interfaz gráfica. 
 
La primera parte del capítulo tratará la arquitectura de la aplicación desde diferentes 
perspectivas, restricciones y metas a nivel técnico a los que estará comprometido el 
proyecto. Luego, se detallarán las vistas de la arquitectura a utilizar en el desarrollo de 
la aplicación según las bases que define RUP. 
 
El segunda y última parte del capítulo, se hará un recorrido por las principales 
interfaces de la aplicación, se describirá el diseño y la distribución de cada una. 
 
3.1 Arquitectura de la solución 
 
 Esta sección provee una apreciación general de alto nivel del desarrollo de la 
arquitectura para la aplicación Incident Dashboard Mobile. La necesidad de definir la 
arquitectura se cimenta en lo siguiente: 
 
45 
 
• Eventualmente, en toda arquitectura se pueden presentar modificaciones, 
ampliaciones o mantenimientos en la aplicación en el futuro. Por lo tanto, la 
arquitectura deberá estar preparada para facilitar estas acciones. 
• Tener una estructura definida de las partes que conformarán la infraestructura 
de la aplicación facilitará las tareas del programador. 
 
La arquitectura será mostrada a través de vistas que permitirán mostrar tanto el 
aspecto técnico como el funcional de la aplicación. Las vistas que se presentarán en 
este capítulo serán la vista lógica, la vista de despliegue y la vista de implementación. 
 
3.1.1. Metas Arquitectónicas y Restricciones 
 
 Una de las metas de la aplicación  Incident Dashboard Mobile es que opere 
sobre un dispositivo móvil cuyo sistema operativo sea Android. Para que esto sea 
posible es necesario tomar en cuenta tres aspectos fundamentales: seguridad, 
performance y convergencia. Estas metas serán explicadas más adelante. 
 
La presente tesis cuenta con un servidor web IIS y el motor de base de datos MySQL 
para el entorno de desarrollo. También se cuenta con un servidor web Apache y el 
motor de base de datos MySQL para el entorno pre-productivo que estarán disponibles 
las 24 horas del día. El mantenimiento físico de los componentes de cada ambiente se 
encuentra fuera del alcance del proyecto, por lo cual no se tendrá en cuenta este 
aspecto. 
 
Plataforma Técnica 
La base técnica para el desarrollo de la aplicación fue concebida e instalada con fines 
del presente proyecto. A continuación se detallan las características técnicas de cada 
ambiente: 
 
 Ambiente de Desarrollo 
o Servidor Web IIS 7.5 
o Sistema Operativo Windows 7 Ultimate 
o Base de datos MySQL 5.6 
 
  
46 
 
Ambiente Pre-Productivo 
o Servido Web Apache 2.2.22 
o Sistema Operativo Linux 
o Base de datos MySQL 5.1.70 
 
Seguridad 
Una de las metas principales de la aplicación, pues la información transmitida entre el 
servidor y la aplicación es información perteneciente al proceso de gestión de 
incidencias de la corporación que instale la aplicación. Por lo tanto todos los usuarios 
de la misma manejarán credenciales para acceder a la misma, la información deberá 
viajar de forma encriptada a través del protocolo HTTPS. 
 
Performance 
Rendimiento  es una de las metas necesarias para la satisfacción del cliente al 
momento de hacer uso de la aplicación. Señalado esto, se ha definido que la 
presentación de los cuadros de resumen no debe tomar más de cinco segundos 
después de que el usuario ha realizado su elección. Para lograr este objetivo las 
presentaciones de la base de datos y el servidor web deben ser las suficientes en el 
ambiente Pre-Productivo, ya que es el ambiente más cercano a la realidad del 
ambiente productivo. Estos factores se tomarán en cuenta en la fase de pruebas para 
poder validar la elección de la base de datos y el servidor web del ambiente Pre-
Productivo. 
 
Convergencia 
Se pronostica que la aplicación puede ser usada por varios usuarios, ya que los 
clientes a los cuales se destina esta misma pueden equivaler a todos los empleados 
que pertenecen a la empresa o a los que pertenecen al área de Gestión de Servicios, 
en cualquiera de los casos se puede observar que existirá multiplicidad de usuarios. 
 
De acuerdo a lo señalado en el párrafo anterior es necesario que el motor de base de 
datos soporte consultas simultáneas sobre una misma tabla de información. Así mismo 
el servidor web debe soportar también consultas simultáneas a las “web services” 
instaladas en el mismo. Estos requisitos son características de la base de datos 
MySQL y el servidor web Apache. 
 
47 
 
3.1.2 Arquitectura 
 
A continuación se delinea las vistas de la arquitectura a utilizar en el desarrollo 
de la aplicación como base en las disciplinas que define RUP. 
 
A. Vista Lógica 
La vista lógica es la encargada de presentar lo que la aplicación debe elaborar, las 
funciones y servicios que se han definido. Para detallar esta vista, la solución estará 
dividida en capas. El modelo se basa en una estrategia que federa una 
responsabilidad del funcionamiento de la aplicación Incident Dashboard Mobile a cada 
capa. Esta estrategia sigue el modelo Vista Controlador, que permite modular y aislar 
responsabilidades durante el desarrollo. 
 
A continuación en la Figura 12, se presenta el diagrama que representa esta vista: 
 
Capa
Cliente
Android App
WebView/Html
Capa Lógica de 
Negocio
Procesar la lógica 
de la aplicación
Capa de 
entidades de 
aplicación
Base de Datos 
MySQL
Entidades de la 
aplicación y 
acceso a datos
 
Figura 12: Vista Lógica de la aplicación 
Fuente: Elaboración propia 
  
48 
 
• Capa Cliente 
La capa cliente aloja las clases de la aplicación que se encargan de mostrar las 
configuraciones realizadas a través de las librerías de Google Charts. En específico, la 
aplicación utiliza la clase WebView que puede desplegar una página web como un 
elemento del “layout” de la aplicación web, esto hace posible que la aplicación puede 
representar los cuadros de resumen a través de las librerías de Google Charts. 
 
• Capa Lógica de Negocio 
La capa lógica está representada por las clases que se encargan de manipular la 
información mediante las reglas de negocio establecidas para la aplicación. En este 
caso, estas reglas contemplan el conteo de los indicadores de acuerdo a los 
lineamientos de ITIL. Esta capa tiene dependencia de las entidades de la aplicación. 
 
• Capa de Entidades de Aplicación 
La capa de entidades de la aplicación son aquellas que se encargan de extraer la 
información desde la base de datos y transmiten la misma hacia las clases de la lógica 
de negocio. 
 
• Capa de Base de Datos MySQL 
Esta capa contiene toda la información correspondiente a credenciales de usuario y 
las tablas que contengan los campos necesarios para realizar el conteo de métricas y 
estadísticas de los indicadores del proceso de Gestión de incidencias. 
 
B. Vista de Implementación 
La Vista de Implementación es la vista delegada a describir la asignación de paquetes 
y clases de la vista lógica, a los paquetes y módulos de la vista de implementación. 
Esta vista se puede apreciar en la Figura 13. 
 
• com.incidentdash.test1 
Contiene todos los componentes necesarios que permitirán al usuario interactuar 
con la aplicación. Está conformado por las clases tipo “Activity” que generan la 
interfaz gráfica que el usuario percibe al usar la aplicación. En el caso de 
GraficadorActivity se tiene una vista web embebida que utiliza las librerías de 
Google Charts para graficar los cuadros de resumen de la aplicación. 
 
49 
 
• com.incidentdash.test1.tesis 
Contiene las clases que manejan las llamadas a los “web services” embebidos en 
el servidor web de la aplicación. Estas ejecutan las llamadas, reciben los datos e 
interpretan la información. 
 
 
50 
 
Tablas y FuncionesMySQL
ValidaUsuario.phpInc_gestionadas_sd.php
Base de datos
Web Services
Inc_gestionadas_sd_6_meses.phpInc_res_2lvl_3lvl_serv.php
JSONParserJSONObject
com.incidentdash.test1.tesis
GraficadorActivity ListaCuadrosActivity MainActivity
main_layout.xmlListacuadros_layuot.xmlGraficador_layout.xml
HTMLs
WebView
com.incidentdash.test1
Librerías
Google Charts
 
 Figura 13: Vista de implementación de la aplicación 
Fuente: Elaboración propia 
51 
 
• Web Services 
Contiene las “web services” que realizan consultas a la base de datos, ejecución 
de funciones o procedimientos. Luego envían la información en formato JSON 
hacia el cliente en el dispositivo móvil. 
 
C. Vista de Despliegue 
 
Esta vista muestra la distribución física de los nodos que componen la infraestructura 
de la aplicación y la disposición de los componentes en cada nodo. A continuación se 
presenta el Diagrama que representa esta vista: 
 
Internet
GPRS UMTS
HSPA LTE
Estacion Base
Punto de
acceso
Dispositivos 
Móviles
Web
Services
BBDD
MySQL
Servidor Web
Apache
Red Celular
 
Figura 14: Vista de despliegue de la aplicación 
Fuente: Elaboración propia 
 
• Dispositivo Móvil 
Ejecuta la aplicación cliente, presenta las interfaces con las cuales el usuario 
interactúa. 
 
• Punto de Acceso 
Punto de acceso inalámbrico a Internet. Este permite que el dispositivo móvil tenga 
acceso a Internet y el usuario pueda utilizar la aplicación. 
 
52 
 
• Estación Base 
Levanta, administra y mantiene la comunicación entre el dispositivo móvil y la red 
celular. Si el dispositivo móvil cuenta con un plan de datos disponible entonces el 
usuario podrá conectarse a Internet y hacer uso de la aplicación. 
 
• Web Services 
Archivos de código que se encargan de interactuar con la base de datos de la 
aplicación y retorna la información solicitada en formato JSON para luego ser 
interpretada por el cliente de la aplicación. 
 
• Servidor Web Apache 
Servidor que puede ser accedido desde Internet, este administra las conexiones 
que se realizan a las “web services”. Es necesario que esté configurado para 
ejecutar los códigos del lenguaje de programación en el que están escritas las 
“web services”. En el caso específico de la presente tesis se ha configurado el 
servidor para ejecutar código escrito en PHP. 
 
• Base de Datos MySQL 
Repositorio donde reside la información del proceso de Gestión de Incidencias y 
los datos de autenticación de usuarios. 
 
3.2 Diseño de Interfaz Gráfica 
 
El diseño de la interfaz gráfica pretende ser directo y sin que el usuario tome 
mucho tiempo ni ejecuto muchos pasos para acceder a los cuadros de resumen del 
proceso de Gestión de Incidencias. Es por esto mismo que se tienen tres interfaces 
principales: Interfaz de inicio de sesión, donde el usuario ingresa las credenciales 
necesarias para ingresar al sistema; Interfaz de listado de cuadros, donde el usuario 
escoge uno de los cuadros estadísticos; Interfaz de visualización del cuadro de 
resumen, donde el usuario visualiza el resumen de indicadores y métricas del proceso 
de Gestión de Incidencias. 
 
3.2.1. Pantalla de Inicio de Sesión 
 
En la figura a continuación, se presenta el detalle de la interfaz de inicio de 
sesión de la aplicación Incident Dashboard Mobile. Esta pantalla contiene el formulario 
53 
 
donde el usuario ingresará las credenciales de acceso a la aplicación. Dos datos son 
requeridos, usuario y clave. 
 
1
 
Figura 15: Pantalla de Inicio de Sesión 
Fuente: Aplicación móvil Incident Management DashBoard 
 
Podemos apreciar en la sección 1 el título de la aplicación junto con los campos de 
“usuario” y “password” mencionados anteriormente con el objetivo de que la aplicación 
compruebe las credenciales y otorgue, o deniegue, el acceso a la aplicación.  
54 
 
3.2.2 Pantalla de Lista de Cuadros de Resumen 
 
 En esta pantalla la aplicación brinda al usuario una lista de cuadros de 
resumen que pueden ser elegidas presionando las imágenes en miniatura que 
representan el tipo de cuadro elegido. En la siguiente figura se muestra esta pantalla: 
 
 
Figura 16: Pantalla de lista de cuadros de resumen 
Fuente: Aplicación móvil Incident Management DashBoard 
55 
 
3.2.3 Pantalla de Visualización de Cuadro de Resumen 
Finalmente tenemos la pantalla donde el usuario podrá visualizar los datos de 
indicadores y métricas del proceso de Gestión de Incidencias según el cuadro de 
resume elegido. A continuación se muestran dos ejemplos de la visualización de estos 
cuadros: 
 
 
Figura 17: Incidencias Resueltas enviadas directamente al nivel 2 o 3 
Fuente: Aplicación móvil Incident Management DashBoard 
 
En la figura podemos apreciar el historial de incidencias resueltas directamente por el 
segundo y tercer nivel de atención y aquellas que fueron resueltas en estos niveles 
pero que antes pasaron por otro nivel de atención como, por ejemplo, la mesa de 
ayuda como primer nivel. 
 
56 
 
 
Figura 18: Incidencias Resueltas enviadas directamente al nivel 2 o 3 
Fuente: Aplicación móvil Incident Management DashBoard 
 
En la figura anterior podemos apreciar, en rojo, el porcentaje de incidencias que han 
sido resueltas en el segundo y tercer nivel de atención que fueron directamente 
asignadas a estos niveles. En azul, el porcentaje de incidencias que han sido resueltas 
en estos niveles pero no fueron asignadas en primera instancia a estos grupos de 
atención. 
  
57 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
CAPÍTULO IV 
IMPLEMENTACIÓN Y PRUEBAS 
 
 En el presente capítulo se presentarán las etapas finales del desarrollo de la 
aplicación que corresponden al diseño y la construcción del mismo. Se presentarán la 
selección del lenguaje de programación y herramientas empleadas para el desarrollo 
de la presente tesis. Finalmente se detallarán las especificaciones de diseño y la 
presentación del plan de pruebas que garantizará el correcto funcionamiento de la 
aplicación. 
 
4.1 Implementación 
 
Esta sección brinda la descripción de los patrones y tecnologías que se utilizaron para 
el desarrollo de la aplicación. Los patrones de programación son técnicas o soluciones 
sugeridas como mejores prácticas para afrontar problemas específicos que se podrían 
presentar durante el desarrollo de la aplicación. 
 
4.1.1 Patrones de Diseño 
 
Un patrón de diseño es una solución en términos generales que  se genera de 
la identificación de problemas comunes al diseñar una aplicación. Su enunciado no es 
58 
 
directamente transmitido en el código, sino que sirve de lineamiento para soluciones 
posibles dificultades que pueden presentarse en diferentes situaciones al programar. 
 
Singleton Pattern 
Patrón de diseño empleado para optimizar y controlar la creación de instancias de 
clase de objetos, invocadas principalmente por los métodos de aquellas clases 
principalmente de tipo “Activity”. De esta forma se busca la manera de limitar a lo 
esencial el uso de recursos y memoria del dispositivo. 
 
Este patrón se puede implementar creando una clase que posee un método que crea 
una nueva instancia de la clase si es que aún no existe. Si ya se tiene una instancia 
existente, entonces se retorna una referencia a dicho objeto. Para estar seguro de que 
el objeto no podrá ser instanciado de otra manera se define el constructor como 
private o protected. 
 
4.1.2 Tecnología 
 
En esta sección se detallará el conjunto de tecnologías utilizadas en la presente tesis y 
la razón por la cual se ha escogido cada una de estas. 
 
Plataforma Android 
Para mediados del 2011 se activaban alrededor de 500 000 dispositivos con Android 
como sistema operativo [5], en la actualidad es el sistema operativo ejecutado por el 
80 por ciento de los dispositivos móviles a nivel mundial [18]. Entre las razones por la 
cual se optó por Android a pesar de que existen otras plataformas para este tipo de 
dispositivos tenemos: 
 
• Plataforma Open Source (no requiere costo de licenciamiento) 
• Alrededor del 80 por ciento del mercado de dispositivos móviles a nivel mundial 
utiliza este sistema operativo 
• Actualización continua del sistema operativo que brinda nuevas funcionalidades 
con cada nueva versión 
• Numerosa documentación existente 
 
  
59 
 
Framework Java para Android 
Si bien Android es un sistema operativo, también existen un conjunto de librerías 
escritas en el lenguaje de programación Java que permiten utilizar las funcionalidades 
tanto del sistema operativo como del hardware ofrecido por el dispositivo móvil.  
Entre las principales librerías Java utilizadas en la presente tesis tenemos: 
 
• java.net.* 
Contiene clases necesarias para invocar a las URL8  (Uniform Resource Locator) 
que hacen referencia a las “web services” alojadas en el servidor web de la 
aplicación. 
 
• java.security.* 
Contiene las clases necesarias para que la aplicación puede aceptar certificados 
digitales privados y así la transmisión de datos pueda darse a través del protocolo 
HTTPS sin la necesidad de tener un certificado digital expedido por una entidad 
certificada. 
 
• android.webkit.* 
Contiene la interfaz JavascriptInterface que permite la incrustación de objetos java 
en archivos javascript. Este fue utilizado para incrustar la información de los 
objetivos tipo JSON recibidos desde las “web services” en los archivos html que 
contienen los cuadros de resumen mostrados en la aplicación. 
 
• org.json.* 
Contiene las clases necesarias para el manejo de datos formateados según JSON. 
 
PHP 
Lenguaje de programación seleccionado para la programación de las “web services”. 
La razón principal de la elección de este lenguaje es que para efectos de la presente 
tesis representaba el programa con menor curva de aprendizaje y con extensa 
documentación. Se analizaron otros lenguajes del mismo tipo como Perl y Python, sin 
embargo la curva de aprendizaje de estos dos lenguajes eran mucho más extensas. 
 
8 URL  hace referencia a la dirección de Internet a la cual es necesaria consultar para obtener 
el recurso requerido. 
60 
 
                                               
 
 
4.1.3 Prácticas Recomendadas por Android Developers 
 
Conjunto de mejores prácticas y recomendaciones que se pueden encontrar en 
la documentación en línea provista por Google Inc. dueños y desarrolladores del 
Sistema Operativo Android. Entre las mejores prácticas implementadas la presente 
tesis tenemos: 
 
• Gráficos y Animación 
Se implementaron las recomendaciones sobre uso de imágenes en las 
aplicaciones de Android. Estas brindan soluciones para la compresión de 
imágenes y presentación de las mismas, de tal manera que estas no utilicen la 
menor cantidad de memoria RAM (Memoria de acceso aleatorio) del dispositivo y 
así ahorrar este recurso que es limitado en este tipo de dispositivos [17]. 
 
• Conectividad 
Se implementaron las recomendaciones sobre conectividad de la aplicación móvil 
con servidores web y de aplicación. Estos recomiendan el uso del protocolo 
HTTPS y certificados digitales para la transmisión de datos sensibles o 
corporativos a través de Internet [17]. 
 
4.1.4 Estándares de Programación 
 
Un Estándar de Programación consiste en convenciones para escribir código fuente en 
ciertos lenguajes de programación. En la presente tesis se utilizaron los siguientes: 
 
Notación de Web Services 
Las “web services” empleadas en la presente tesis siguen la siguiente sintaxis: 
 
<Resumen_informacion_solicitada>_serv.php 
Se emplea una descripción resumida de la información que provee la “web service” y 
se agrega el final sufijo “serv”. 
 
Notación de Clases 
Las clases empleadas en la presente tesis seguirán la siguiente sintaxis: 
61 
 
 <Descripcion_actividad>Activity.java 
Se emplea una descripción de la actividad realizada por la aplicación al utilizar esta 
clase. 
 
JSON<actividad o entidad> 
Si es que la clase hereda de la clase org.json.JSONObject o si es que la clase 
transmite, recibe información hacia las “web services” en formato JSON. 
 
Notación de Procedimientos 
El nombre de los procedimientos comenzará con la acción a tomar con la primera letra 
minúscula seguida de las demás palabras sin separación o símbolos intermedios con 
la primera letra en mayúscula. 
 
La sintaxis para los procedimientos es la siguiente: 
<verbo_acción><Palabras_descriptivas> 
 
Notación de Variables 
El nombre de las variables comenzará por el nombre de variable seguido del tipo de 
variable sin ninguna separación entre las palabras. La primera letra del nombre de la 
variable será minúscula y el resto de palabras comenzarán con mayúscula. 
 
La sintaxis para las variables es la siguiente: 
<nombre_de_variable><Tipo_variable> 
 
4.2. Pruebas 
 
En la presente sección suministra el detalle de la organización del proceso de pruebas 
que se realizaron en la presente tesis. 
 
4.2.1. Estrategia de Pruebas 
 
Los tipos de prueba que se detallarán son: 
• Pruebas de Aceptación: cuyo propósito es confirmar que la aplicación satisface los 
requerimientos planteados y brinda niveles aceptables de rendimiento. Se 
comprobará que la aplicación funcione correctamente. 
62 
 
 • Pruebas de Seguridad: cuyo propósito es verificar las funcionalidades de 
autenticación de usuarios y transmisión segura de datos a través de Internet. 
 
4.2.2 Pruebas de Aceptación 
 
En la presente sección se presentarán las pruebas según el caso de uso descrito en la 
sección 2.2.4. Estas verificaran la implementación correcta del flujo y funcionalidades 
de la aplicación. A continuación se muestra la descripción de esta prueba: 
 
Cuadro 9: Descripción de plan de prueba 
Objetivo: Comprobar el funcionamiento del flujo correspondiente 
al caso de uso “Elección de cuadro de resumen”. 
Precondición El usuario ha sido admitido por la aplicación. 
Descripción: • El usuario elegirá uno de los cuadros de resumen 
disponibles en la interfaz donde se listan los cuadros 
disponibles, justo después de iniciar sesión. 
• El usuario visualizará los datos mostrados en el cuadro de 
resumen. 
• El usuario volverá a la interfaz de lista de los cuadros de 
resumen a través de la tecla “volver” del dispositivo móvil. 
• El usuario elegirá nuevamente un cuadro resumen. 
• El usuario volverá a la interfaz de inicio de sesión 
presionando la tecla “volver” del dispositivo móvil dos 
veces consecutivas. 
Resultados 
Esperados: 
• El usuario podrá visualizar los cuadros de resumen sin 
importar las iteraciones realizadas entre la interfaz de lista 
de cuadros de resumen y la interfaz de visualización de 
cuadro de resumen. 
Fuente: Elaboración Propia 
 
4.2.3 Pruebas de Seguridad 
 
Se han realizado las siguientes pruebas de seguridad: 
 
• Verificar el control de acceso a la aplicación sólo a usuarios registrados. 
63 
 
• Verificar la transmisión segura de datos hacia el servidor web. 
• Verificar la transmisión segura de datos desde el servidor web. 
  
64 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
CONCLUSIONES 
 
 
 La presente tesis tuvo como objetivo analizar, diseñar e implementar una 
aplicación móvil con el propósito de coadyuvar al proceso de Gestión de Incidencias 
de la Gestión de Servicios en una empresa que cuenta con el mismo. Para lograr esto 
la aplicación se concentró en la automatización, centralización, presentación y 
disposición de cuadros de resumen de indicadores del proceso de Gestión de 
Incidencias. 
 
A continuación se presenta el listado de conclusiones a las cuales se ha llegado al 
final de la presente tesis: 
 
1. La aplicación ha logrado automatizar el proceso de generación de cuadros de 
resumen, ya que los datos del proceso de Gestión de Incidencias solamente son 
manipulados por la aplicación durante todo el proceso. El usuario sólo visualiza 
el resultado final a través de gráficos estadísticos. 
2. La aplicación es accesible desde cualquier ubicación con conexión a Internet, 
por lo que el objetivo de disponibilidad de la aplicación sin importar si el usuario 
está conectado a la red corporativa o no ha sido logrado. 
65 
 
3. La centralización de generación de cuadros de resumen se tiene que definir 
como una funcionalidad potencial de la aplicación. Pues depende también de la 
gestión interna por parte de la empresa para priorizar los cuadros generados a 
través de la aplicación sobre aquellos cuadros generados en la actualidad. Esto 
conlleva un tiempo de transición, adecuación y capacitación de los empleados. 
4. Es necesario anotar que la implementación de la aplicación en un ambiente de 
producción corporativo se tiene que dar como un proyecto. Pues para el 
funcionamiento de la aplicación debe existir una etapa de integración de bases 
de datos, entre la base de datos de la aplicación y la base de datos del proceso 
de Gestión de Incidencias que puede ser variable en diferentes empresa, pues 
cada una puede utilizar diferentes herramientas y estructuras de base de datos 
para propósitos de la Gestión de Servicios. 
5. Debido a limitaciones en el tiempo disponible para completar el proyecto de tesis 
no se han presentado cuadros de resumen de todos los indicadores posibles del 
proceso de Gestión de Incidencias. Por lo que se señala que es posible 
implementar mejoras en nuevas versiones en un futuro cercano. 
6. El concepto de la presente tesis puede ser extendida a los demás procesos de la 
Gestión de Servicios por lo que se puede convertir en una herramienta para la 
generación total de cuadros estadísticos de indicadores y métricas del proceso. 
Aumentando así, de forma considerable, el valor de negocio de la aplicación. 
Pues si la aplicación abarca el proceso completo de Gestión de Servicios podría 
convertirse en una herramienta que garantizaría cumplir los requisitos de control 
de indicadores que requiere la certificación ISO 20000. 
  
66 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
RECOMENDACIONES 
 
A continuación se presentan recomendaciones para implementaciones actuales y 
futuros trabajos relacionados con la presente tesis: 
 
1. Para implementaciones en ambientes corporativos se recomienda la evaluación 
del parque de dispositivos móviles y el sistema operativo de estos como uno de los 
primeros pasos de la implementación. Esta es una restricción importante para la 
implementación de la aplicación en ambientes de producción. 
2. Se recomienda utilizar una base de datos orientada a la inteligencia de negocios 
ya que esta se basa mayormente en conteo y resumen de indicadores. Esta no es 
una aplicación transaccional por lo que el uso de base de datos estándar podría 
ralentizar la aplicación si es que se tiene un gran volumen de registros (millones de 
registros). 
3. Se recomienda implementar un módulo de administración de la aplicación para 
configurar parámetros como el servidor a la cual apuntará la aplicación y el 
certificado digital que la aplicación usará para transmitir datos de forma segura a 
través de Internet. 
  
67 
 
BIBLIOGRAFÍA 
 
[1]   VAN, Jan, DE JONG, Arjen y otros 
 2007 IT Service Management – An Introduction. 
 
[2] VESELY, Arnost 
2008 Problem Tree: A Problem Structuring Heuristic. Praga: Facultad de 
Ciencias Sociales de la Universidad Charles. 
 
[3] UNIVERSIDAD NACIONAL DE COLOMBIA 
2013 “Taller de Ingeniería de Métodos”. Colombia. Consulta: 07 de diciembre 
de 2013.   
<http://www.virtual.unal.edu.co/cursos/sedes/manizales/4100002/index.
html> 
 
[4]  CHUNG PINZÁS, Gerardo Yatsen 
2013 Desarrollo de un Sistema Web para la enseñanza de Casos de Uso 
empleando la Técnica de Aprendizaje Cooperativo de Rompecabezas. 
Tesis de licenciatura en Ciencias e Ingeniería con mención en 
Ingeniería Informática. Lima: Pontificia Universidad Católica del Perú, 
Facultad de Ciencias e Ingeniería. 
 
[5]  DEITEL, Paul, DEITEL, Harvey y DEITEL, Abbey 
 2012 AndroidTM for Programmers an App-Driven Approach.  
 
[6]  GOOGLE Inc. 
2013 “Android, the world’s most popular mobile platform”. Estados Unidos de 
América. Consulta: 07 de diciembre de 2013. 
 <http://developer.android.com/about/index.html> 
 
[7] BMC Software Inc. 
2013 “Remedy ITSM Suite 8”. Descripción de la suite para la Gestión de 
Servicios TI. Estados Unidos de América. Consulta: 07 de diciembre de 
2013. 
 <http://www.bmc.com/products/remedy-itsm/> 
 
68 
 
[8]  Hewlett-Packard Company 
2013 “IT Service Managment”. Descripción de la suite para la Gestión de 
Servicios IT de Hewllet-Packar. Estados Unidos de América. Consulta: 
07 de diciembre de 2013. 
 <http://www8.hp.com/us/en/software-
solutions/software.html?compURI=1172196#.UqO4mOI1P1A> 
 
[9] OTRS Inc. 
2013 Descripción de la herramienta desarrollada por OTRS Inc., para la 
gestión de Servicios TI. Consulta: 07 de diciembre de 2013. 
 <http://www.otrs.com/software/> 
 
[10] Zoho Corporation 
2013 Descripción de la herramienta desarrollada por Zoho Corporation para 
la gestión de Servicios TI. Consulta: 07 de diciembre de 2013. 
 <http://www.manageengine.com/products/service-desk/> 
 
[11] Google Inc. 
2013 Descripción de las librerías Google Charts para la presentación de 
gráficos estadísticos en un cliente web. Consulta: 08 de diciembre de 
2013. 
 <https://developers.google.com/chart/> 
  
[12] Oracle Corporation 
2013 Descripción del motor de base de datos MySQL. Consulta: 09 de 
diciembre de 2013. 
 <http://www.mysql.com/> 
 
[13] Apache Software Foundation 
2013 Información del servidor web Apache. Consulta: 09 de diciembre de 
2013. 
 <http://httpd.apache.org/> 
 
[14] BARNES, Joshua 
2007 Implementing the IBM Rational Unified Process and Solutions 
69 
 
[15] BROOKS, Peter 
 2006 Metrics for IT Service Management 
 
[16] DEITEL, Paul y DEITEL, Harvey 
 2010 C# 2010 For Programmers 
 
[17] Google Inc. 
2013 Mejores prácticas para la programación en Android. Consulta: 11 de 
diciembre de 2013. 
 <http://developer.android.com/guide/practices/index.html> 
 
[18] Gartner Inc. 
2014 Información sobre el mercado de teléfonos inteligentes por sistema 
operativo. 
 <http://www.gartner.com/newsroom/id/2665715> 
70