UNIVERSIDAD PRIVADA ANTENOR ORREGO FACULTAD DE INGENIERÍA ESCUELA PROFESIONAL DE INGENIERÍA DE COMPUTACIÓN Y SISTEMAS “SISTEMA INFORMÁTICO WEB DE GESTIÓN DE INCIDENCIAS USANDO EL FRAMEWORK ANGULARJS Y NODEJS PARA LA EMPRESA REDTEAM SOFTWARE LLC” TESIS PARA OBTENER EL TÍTULO PROFESIONAL DE INGENIERO DE COMPUTACIÓN Y SISTEMAS LÍNEA DE INVESTIGACIÓN: INGENIERÍA WEB AUTOR: Br. JULIO LUIS TACILLA LUDEÑA ASESOR: Ing. JORGE PIMINCHUMO FLORES TRUJILLO - PERÚ 2016 ACREDITACIONES TÍTULO: “SISTEMA INFORMÁTICO WEB DE GESTIÓN DE INCIDENCIAS USANDO EL FRAMEWORK ANGULARJS Y NODEJS PARA LA EMPRESA REDTEAM SOFTWARE LLC” AUTOR: Br.Julio Luis Tacilla Ludeña APROBADO POR: Ing. Walter Aurelio Lazo Aguirre PRESIDENTE N° CIP 36034 Ing. Heber Gerson Abanto Cabrera SECRETARIO N° CIP 106421 Ing. Silvia Ana Rodriguez Aguirre VOCAL N° CIP 107615 Ing. Jorge Piminchumo Flores ASESOR N° CIP 137153 i PRESENTACIÓN Señores Miembros del Jurado: Dando cumplimiento y conforme a las normas establecidas en el Reglamento de Grados y Títulos y Reglamento de la Facultad de Ingeniería de la Universidad Privada Antenor Orrego, para obtener el título profesional de Ingeniero de Computación y Sistemas, se pone a vuestra consideración el Informe del Trabajo de Investigación Titulado “SISTEMA INFORMÁTICO WEB DE GESTIÓN DE INCIDENCIAS USANDO EL FRAMEWORK ANGULARJS Y NODEJS PARA LA EMPRESA REDTEAM SOFTWARE LLC”, con la convicción de alcanzar una justa evaluación y dictamen, excusándome de antemano de los posibles errores involuntarios cometidos en el desarrollo del mismo. Trujillo, 15 de Julio de 2016. Br.Julio Luis Tacilla Ludeña ii DEDICATORIA “A mis padres quienes en todo momento me dieron su apoyo y motivación lo que me permitió crecer personalmente y como profesional. A mi Abuelita Angélica por gran cariño y amor A mi familia por su apoyo“ iii AGRADECIMIENTOS A Dios por haberme dado la fuerza y salud que me permite continuar y cumplir con mis objetivos A mis Padres por el sacrificio y esfuerzo que realizaron constantemente para poder tener una buena formación profesional. A todos mis familiares que confiaron en mí y me dieron su apoyo en todo momento Gracias a todos. iv RESUMEN SISTEMA INFORMÁTICO WEB DE GESTIÓN DE INCIDENCIAS USANDO EL FRAMEWORK ANGULARJS Y NODEJS PARA LA EMPRESA REDTEAM SOFTWARE LLC Por: Br. Julio Luis Tacilla Ludeña La presente tesis se desarrolla bajo la realidad problemática identificada en el proceso de gestión de incidencias de la empresa RedTeam Software LLC, en la cual se identificó como principal problema la demora o falta de atención de incidencias y la necesidad de tener una mayor satisfacción del cliente en la solución de incidencias reportadas. El presente trabajo tiene como objetivo brindar una solución mediante el desarrollo de un sistema de información web utilizando los Frameworks AngularJS y NodeJS para la gestión de Incidencias de la empresa RedTeam Software LLC, para esto se analizó la situación actual del proceso de gestión de incidencias con la finalidad de identificar los requerimientos principales que luego serían base para el desarrollo de este trabajo. Para el desarrollo se usó la metodología ICONIX lo que permitió tener un desarrollo ágil y rápido mostrando el análisis, diseño e implementación del sistema de información web. v ABSTRACT INFORMATIC SYSTEM WEB TO MANAGEMENT INCIDENT USING THE FRAMEWORKS ANGULARJS AND NODEJS FOR THE COMPANY REDTEAM SOFTWARE LLC By: Br. Julio Luis Tacilla Ludeña This thesis is developed under the problematic identified in the process of incident management of the company RedTeam Software LLC, in which was identified how main problem a delay or inattention incidents and the need of increment the customer satisfaction with reported incidents solution. The present work has as purpose offer a solution with a development of information system web using the frameworks AngularJS and NodeJs to management incidents for the Company Redteam Software LLC, for this the current situation of the incident management process was analyzed for the purpose of identify the main requirements which then will be the base for the development of this work For Development was used the methodology ICONIX, this permitted have a development agile and fast showing the analysis, design and implementation of the informatics system web. vi ÍNDICE GENERAL ACREDITACIONES .............................................................................................................. i PRESENTACIÓN .................................................................................................................. ii DEDICATORIA .................................................................................................................... iii AGRADECIMIENTOS ......................................................................................................... iv RESUMEN ............................................................................................................................. v ABSTRACT .......................................................................................................................... vi ÍNDICE GENERAL ............................................................................................................. vii ÍNDICE DE TABLAS ............................................................................................................ x ÍNDICE DE FIGURAS ......................................................................................................... xi 1. INTRODUCCIÓN .......................................................................................................... 1 1.1. Realidad problemática ................................................................................................. 1 1.2. Delimitación del problema .......................................................................................... 1 1.3. Características y análisis del problema ........................................................................ 1 1.4. Formulación del Problema........................................................................................... 2 1.5. Formulación de la Hipótesis ........................................................................................ 2 1.6. Objetivos del estudio ................................................................................................... 3 1.7. Justificación del Estudio .............................................................................................. 3 1.8. Limitaciones del estudio .............................................................................................. 4 2. MARCO TEÓRICO ........................................................................................................ 4 2.1. Antecedentes ................................................................................................................ 4 2.2. Bases teóricas .............................................................................................................. 6 2.2.1. Gestión de Servicios ................................................................................................ 6 2.2.2. ITIL - Biblioteca de Infraestructura de Tecnologías de Información ...................... 6 2.2.3. Gestión de Incidencias ............................................................................................. 7 2.2.4. Metodología ICONIX .............................................................................................. 9 2.2.5. AngularJS ............................................................................................................... 13 2.2.6. Node.js ................................................................................................................... 14 2.3. Definición de términos .............................................................................................. 15 3. MATERIAL Y MÉTODOS .......................................................................................... 16 3.1. Material ...................................................................................................................... 16 vii 3.1.1. Población ............................................................................................................... 16 3.2. Muestra ...................................................................................................................... 16 3.2.1. Unidad de Análisis ................................................................................................. 17 3.3. Método ....................................................................................................................... 17 3.3.1. Nivel de Investigación ........................................................................................... 17 3.3.2. Diseño de Investigación ......................................................................................... 18 3.3.3. Variables de estudio y operacionalización ............................................................. 19 3.3.4. Técnicas e Instrumentos de recolección de datos .................................................. 20 3.3.5. Técnicas de Procesamiento de datos ...................................................................... 20 3.3.6. Técnicas de análisis de datos ................................................................................. 20 4. RESULTADOS ............................................................................................................. 21 4.1. Modelo de Negocio ................................................................................................... 21 4.1.1. Empresa ................................................................................................................. 21 4.1.2. Proceso de Atención de Incidencias ...................................................................... 21 4.1.3. Problema ................................................................................................................ 23 4.1.4. Solución ................................................................................................................. 23 4.2. Análisis de Requisitos ............................................................................................... 24 4.2.1. Requerimientos ...................................................................................................... 24 4.2.2. Diseño de Prototipos .............................................................................................. 24 4.2.3. Casos de Usos ........................................................................................................ 32 4.2.4. Modelo de dominio ................................................................................................ 33 4.3. Análisis y Diseño Preliminar ..................................................................................... 34 4.3.1. Especificaciones de Caso de Uso ........................................................................... 34 4.3.2. Diagrama de Robustez ........................................................................................... 43 4.4. Diseño Detallado ....................................................................................................... 50 4.4.1. Diagrama de Secuencia .......................................................................................... 50 4.4.2. Diagrama de Clases ............................................................................................... 57 4.4.1. Diagrama de Base de Datos ................................................................................... 58 4.4.2. Diseño de Interfaces ............................................................................................... 59 4.5. Implementación ......................................................................................................... 69 4.5.1. Diagrama de Componentes .................................................................................... 69 4.5.2. Diagrama de Despliegue ........................................................................................ 69 viii 5. DISCUSIÓN DE RESULTADOS ................................................................................ 70 5.1. Hipótesis .................................................................................................................... 70 5.2. Variables .................................................................................................................... 70 5.3. Operacionalización de Variables ............................................................................... 70 5.4. Contrastación de la Hipótesis .................................................................................... 71 5.4.1. Indicador Tiempo en dar solución a cada incidencia. ............................................ 71 5.4.2. Indicador Porcentaje de incidencias solucionadas ................................................. 73 5.4.3. Indicador Grado de Satisfacción del cliente .......................................................... 75 6. CONCLUSIONES ........................................................................................................ 77 7. RECOMENDACIONES ............................................................................................... 78 8. REFERENCIAS BIBLIOGRÁFICAS .......................................................................... 79 9. ANEXOS ....................................................................................................................... 81 ix ÍNDICE DE TABLAS Tabla 1: Población ................................................................................................................ 16 Tabla 2: Operacionalización de Variables ............................................................................ 20 Tabla 3: Especificación de Caso de Uso – Registro de Usuarios ......................................... 34 Tabla 4: Especificación de Caso de Uso - Registro Tipo de Incidencias ............................ 35 Tabla 5: Especificación de Caso de Uso - Registro Ubicaciones ......................................... 35 Tabla 6: Especificación de Caso de Uso - Registro de Incidencias...................................... 36 Tabla 7: Especificación de Caso de Uso - Registro de Información Adicional .................. 37 Tabla 8: Especificación de Caso de Uso – Asignar Incidencias para su solución................ 38 Tabla 9: Especificación de Caso de Uso – Registrar Cambio de estado de la Incidencia .... 39 Tabla 10: Especificación de Caso de Uso – Registrar Solución de Incidencias.................. 40 Tabla 11: Especificación de Caso de Uso – Listar Incidencias por criterio de búsqueda .... 41 Tabla 12: Especificación de Caso de Uso – Reporte Resumen de Incidencias Reportadas y Solucionas por fecha ............................................................................................................. 42 Tabla 13: Operacionalidad de Variables .............................................................................. 70 Tabla 14: Prueba de Muestras Independientes - Indicador de Tiempo ................................ 72 Tabla 15: Comparación de Incidencias Reportadas vs Incidencias Atendidas .................... 73 Tabla 16: Prueba de Muestras Independientes - Indicador de Porcentaje ............................ 74 Tabla 17: Niveles de Satisfacción del Cliente ...................................................................... 75 x ÍNDICE DE FIGURAS Figura 1: Ciclo de Vida – ITIL ............................................................................................... 7 Figura 2: Fases de la Metodología Iconix ............................................................................ 12 Figura 3: MVC de AngularJS .............................................................................................. 14 Figura 4: Muestra ................................................................................................................. 17 Figura 5: Proceso de Atención de Incidencias...................................................................... 22 Figura 6: Diagnostico del Problema ..................................................................................... 23 Figura 7: Solución del Problema .......................................................................................... 23 Figura 8 : Prototipo - Registro de Usuarios .......................................................................... 25 Figura 9: Prototipo - Registro de Tipo de Incidencias ......................................................... 26 Figura 10: Prototipo - Registro de elementos del sistema (Ubicaciones) ............................ 26 Figura 11: Prototipo - Registro de Incidencias .................................................................... 27 Figura 12: Prototipo - Registro de Información Adicional ................................................. 28 Figura 13: Prototipo - Asignar Incidencias para su Solución ............................................... 29 Figura 14: Prototipo - Registrar cambio de estado de la Incidencia ..................................... 29 Figura 15: Prototipo - Registrar solicitud de Incidencias .................................................... 30 Figura 16: Prototipo – Listar Incidencias por criterio de búsqueda ..................................... 30 Figura 17: Prototipo – Reporte Resumen ............................................................................. 31 Figura 18: Casos de Uso ....................................................................................................... 32 Figura 19: Modelo de Dominio ............................................................................................ 33 Figura 20: Diagrama Robustez – Registro de Usuarios ....................................................... 43 Figura 21: Diagrama Robustez – Registro de Tipo de Incidencias ...................................... 43 Figura 22: Diagrama Robustez – Registro de Elementos (Ubicaciones) ............................. 44 Figura 23: Diagrama Robustez – Registro de Incidencias ................................................... 44 Figura 24: Diagrama Robustez – Registro de Información Adicional ................................. 45 Figura 25: Diagrama Robustez – Asignar Incidencias para su Solución ............................ 46 Figura 26: Diagrama Robustez – Registro cambio de estado de incidencia ........................ 47 Figura 27: Diagrama Robustez – Registro de Solución de Incidencias ............................... 48 Figura 28: Diagrama Robustez – Listar Incidencias por criterio de búsqueda ..................... 48 Figura 29: Diagrama Robustez – Reporte resumen de Incidencias reportadas y solucionadas por fecha.......................................................................................................... 49 Figura 30: Diagrama Secuencia – Registro de Usuarios ...................................................... 50 Figura 31: Diagrama Secuencia – Registro de Tipo de Incidencias ..................................... 51 Figura 32: Diagrama Secuencia – Registro de elementos (Ubicaciones) ............................. 51 Figura 33: Diagrama Secuencia – Registro de Incidencias .................................................. 52 Figura 34: Diagrama Secuencia – Registro de Información Adicional ................................ 53 Figura 35: Diagrama Secuencia – Asignar Incidencias para su solución ............................. 54 Figura 36: Diagrama Secuencia – Registrar cambio de estado de Incidencias .................... 55 Figura 37: Diagrama Secuencia – Registrar Solución de Incidencias .................................. 55 Figura 38: Diagrama Secuencia – Listar Incidencias por criterio de búsqueda .................. 56 Figura 39: Diagrama Secuencia – Reporte Resumen ........................................................... 56 Figura 40: Diagrama de Clases ............................................................................................. 57 Figura 41: Diagrama de Base de Datos ................................................................................ 58 Figura 42: Interfaz Registro de Usuario ............................................................................... 59 Figura 43: Interfaz Registro de Tipo de Incidencias ............................................................ 60 xi Figura 44: Interfaz Registro de elementos del Sistema ........................................................ 61 Figura 45: Interfaz Registro de Incidencias .......................................................................... 62 Figura 46: Interfaz Registro de Información Adicional ....................................................... 63 Figura 47: Interfaz Asignar Incidencias ............................................................................... 64 Figura 48: Interfaz Cambiar de Estado ................................................................................. 65 Figura 49: Interfaz Registrar Solución ................................................................................. 66 Figura 50: Interfaz Listar Incidencias ................................................................................... 67 Figura 51: Interfaz Reporte resumen de incidencias ............................................................ 68 Figura 52: Diagrama Componentes ...................................................................................... 69 Figura 53: Diagrama Despliegue .......................................................................................... 69 Figura 54: Incidencias Reportadas vs Incidencias Solucionadas ......................................... 74 Figura 55: Datos de Nivel de Satisfacción del cliente .......................................................... 76 xii 1. INTRODUCCIÓN 1.1. Realidad problemática ReadTeam Software LLC es una empresa norteamericana dedicada a proveer un servicio de software de Gestión de proyectos y contabilidad para empresas del sector construcción, durante el pasado año 2015 hasta la fecha debido a múltiples factores tecnológicos , comerciales y de marketing se dio un crecimiento de nuevos clientes, con esto también hubo un incremento del número de incidencias de parte de los nuevos clientes que presentaban problemas o necesitaban conocer las funcionalidades del sistema adquirido. El incremento de los nuevos clientes dio a conocer que el proceso de gestión de incidencias que actualmente tiene la empresa presenta problemas como son la demora o no atención de las incidencias, y la necesidad de funcionalidades tecnológicas para poder mejorar el servicio que se brinda. 1.2. Delimitación del problema Para el estudio se va tomar en cuenta solo el proceso de gestión de incidencias de la empresa RedTeam Software LLC el cual inicia cuando el cliente dentro del sistema registra una incidencia y termina cuando el cliente da conformidad a la solución de la incidencia. 1.3. Características y análisis del problema Se lograron identificar las siguientes características problemáticas las cuales definirán el problema objeto de investigación de la presente tesis.  Demora o Falta de Atención de las incidencias, mediante la observación directa por el responsable de esta investigación, se pudo identificar incidencias registradas que llevan más de 6 meses sin ser atendidas y de las cuales no se ha dado ningún tipo de información al cliente, en otros casos se ha notado incidencias que por una escasa descripción del problema se ha teniendo que pedir mayor información al cliente con esto ocasionando una mayor demora en la solución de la incidencia. Estos problemas están ocasionando el aumento del número de quejas y la posible causa que el cliente deje de usar el servicio de software. 1  No hay un seguimiento detallado de la incidencia, La empresa actualmente maneja estados internos para la incidencia desde el registro hasta el cerrado de la incidencia, pero no es lo mismo con los clientes, ellos no tienen la información del estado de su incidencia registrada, y la única forma es la de tener que llamar o enviar correos preguntando el estado y si la incidencia está siendo trabajada.  Falta de Información resumida, La empresa al no tener una buena organización en el manejo de las incidencias no cuenta con una información resumida de las incidencias solucionadas por cada cliente, por este motivo las personas encargadas en el área de atención al cliente no tienen la capacidad de informar al cliente de cuál fue el problema y la solución que se le dio a su incidencia.  Incidencias repetidas, debido a la falta de registro de la solución dada a cada incidencia trabajada y la demora en la atención de incidencias, es común tener incidencias con el mismo problema esto lleva a un aumento innecesario del número de incidencias. Basados en este contexto existe una realidad problemática que está presente en la gestión de incidencias de la empresa, lo cual se resume en la demora o falta de atención, falta de seguimiento detallado, una falta de información resumida de las incidencias registradas y la necesidad de tener una mayor satisfacción del cliente en la solución de incidencias reportadas. 1.4. Formulación del Problema ¿Cómo mejorar el proceso de Gestión de incidencias en la Empresa RedTeam Software LLC con el uso de tecnologías de información? 1.5. Formulación de la Hipótesis Un sistema web utilizando el framework AngularJs y Node.js mejora la gestión de incidencias en la empresa RedTeam Software LLC. 2 1.6. Objetivos del estudio Desarrollar un sistema informático web de gestión de incidencias utilizando el framework AngularJS y Node.js para la empresa RedTeam Software LLC. Objetivos Específicos Analizar el proceso actual de gestión de incidencias para lograr identificar las necesidades de funcionalidad del sistema. Realizar el análisis y diseño del proceso de gestión de incidencias utilizando la metodología de desarrollo ICONIX. Construir el sistema informático web de gestión de incidencias usando el Framework AngularJs y Node.js 1.7. Justificación del Estudio En empresas proveedoras de servicios de TI, la gestión de incidencias tiene cada vez un rol más importante porque permite garantizar la disponibilidad y continuidad de los servicios ofrecidos al cliente, los beneficios de una correcta gestión de incidencias son:  Mejora de la satisfacción general de clientes y usuarios.  Da un soporte muy importante para el área de atención al cliente  Aumenta la productividad y atención a los usuarios.  Optimiza los recursos disponibles La implementación de un sistema de información web permitirá agilizar el proceso de gestión de incidencias y así obtener los beneficios antes mencionados dándole un valor agregado a la empresa ya que podrá usar este sistema como una posible fuente para la toma de decisiones estratégicas de la empresa. También es necesario mencionar los beneficios que ofrece el uso de Frameworks de JavaScript en el desarrollo de sistemas web, uno de los beneficios más importantes es que tiene grandes características para agilizar el desarrollo del proyecto, estas características son la reusabilidad, la rapidez en el testeo del código, la seguridad y la compatibilidad con diferentes navegadores, etc. Otro beneficio que destaca es la gran capacidad de 3 aprendizaje debido a que existe mucha documentación y una extensa comunidad con la cual interactuar. En esta investigación se tratara de demostrar los beneficios antes mencionados y apreciar la importancia que tendría una mejoraría del proceso de gestión de incidencias mediante el análisis de la situación actual y el uso de nuevas tecnologías web como son el framework AngularJS y Node.js. 1.8. Limitaciones del estudio No se encontraron limitaciones relevantes que impidan el desarrollo de esta investigación. 2. MARCO TEÓRICO 2.1. Antecedentes Según Luzuriaga (2015), en su Tesis “Diseño de los procesos de gestión de incidencias y Service Desk, alineado a las buenas prácticas de ITIL, aplicado a la empresa Delltex industrial S.A.” Tiene como objetivos presentar una propuesta de diseño y mejora de los procesos de gestión de incidencias y Service Desk mediante el estudio de las buenas prácticas en gestión de servicios. Como resultados brinda la alineación de los procesos de gestión de incidencias con las buenas prácticas de ITIL. El aporte de esta tesis a la investigación son las recomendaciones brindadas para poder asegurar el mejoramiento continuo aplicando buenas prácticas en la gestión de incidencias. Según Casas y Chirca (2014), en su Tesis “Mejora de los procesos de gestión de incidencias y cambios aplicando ITIL en la facultad de administración – USMP.” Se propuso como objetivos mejorar los procesos de la Gestión de Incidencias y Gestión de cambios usando ITIL con la finalidad de mejorar el proceso de atención y calidad del servicio. Como resultados obtenidos dio a conocer una reducción del tiempo la atención de incidencias, llevar un adecuado control de todos los cambios solicitados y contar con indicadores que permitan conocer el desempeño y comportamiento del área de Administración de la USMP. , si bien esta investigación no está alineada a las buenas prácticas de ITIL, El aporte principal que esta tesis brinda a esta investigación es la de 4 conocer el rediseño del proceso de gestión de incidencias para permitir una rápida atención y solución de incidencias. Según Apaza (2014), en su tesis “Modelo de gestión de incidencias basado en ITIL para reducir el tiempo de diagnóstico de incidentes del servicio de soporte técnico en la universidad nacional del altiplano puno – 2014” tiene por objetivo desarrollar un modelo de gestión de incidencias para reducir el tiempo de diagnóstico de incidentes. Y mejorar el actual proceso de gestión de incidencias estandarizándolo según el modelo propuesto por ITIL, como resultado de esta propuesta se obtiene una reducción del 77% en el tiempo de diagnóstico de incidencias del servicio de soporte técnico. Además brinda recomendaciones y sugerencias para seguir investigando e implementando trabajos relacionados a la gestión de incidencias y al marco de referencia que propone ITIL para la gestión del servicio. Según Muro (2013), en la Tesis “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” tiene como objetivo la presentación de estadísticas a través de dispositivos móviles basados en la información generada por el módulo de gestión de incidencias encargada del registro, atención, resolución y cierre de incidencias para la automatización de procesos y toma de decisiones. Como resultado se logró la automatización del proceso de generación de cuadros de resumen del proceso de Gestión de Incidencias y así poder obtener información detallada, el aporte principal al trabajo de investigación es que una buena gestión de las incidencias puede ser una fuente de información para luego poder ser analizada y usada para la toma de decisiones. Según Cadavieco, Pérez y Fernández (2012), en su artículo “Gestión de incidencias informáticas: el caso de la Universidad de Oviedo y la Facultad de Formación del Profesorado” tiene como objetivo identificar las incidencias informáticas más representativas de la facultad de Formación del Profesorado y Educación en la Universidad de Oviedo con la finalidad de aportar pautas para tomar mejores decisiones en la gestión de incidencias. Como resultado identificaron que los problemas encontrados en su mayoría estaban relacionados con el software y propusieron la implementación de 5 servicios centralizados de actualización y mantenimiento de los programas. El aporte brindado a esta investigación es conocer cómo identificar las principales incidencias realizando una agrupación de los problemas encontrados para luego poder tratar la fuente del problema, también da a conocer que la gestión de incidencias debe mostrar una comunicación fluida con las personas afectadas. 2.2. Bases teóricas 2.2.1. Gestión de Servicios Es una disciplina basada en procesos que cooperan para asegurar la calidad de servicios conectados y vivos, de acuerdo a los niveles de servicios acordados con el cliente. Contempla a los dominios de gestión como pueden ser: gestión de sistemas, gestión de redes y desarrollo de sistemas, y a otros muchos dominios de procesos como por ejemplo: gestión de los cambios, gestión de activos y gestión de los problemas. (Lobos, Baquinzay y Bustos, 2008, p.14) Los objetivos de una buena gestión de servicios son proporcionar una adecuada gestión de la calidad, Alinear los procesos de negocio y la infraestructura TI y reducir los riesgos asociados a los Servicios TI. Para cumplir estos objetivos tenemos que hablar de un conjunto de buenas prácticas llamado ITIL. 2.2.2. ITIL - Biblioteca de Infraestructura de Tecnologías de Información Es un marco de trabajo de las mejores prácticas destinadas a facilitar la entrega de servicios de tecnologías de la información (TI) de alta calidad. ITIL resume un extenso conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI. (Sandoval y mejia, 2011, p.13) ITIL es un conjunto de libros donde se encuentran documentados todos los procesos referentes a la provisión de servicios de tecnología de información hacia las organizaciones. ITIL tiene un ciclo de vida que consta de 5 fases, estas son: Estrategia del Servicio, Diseño del Servicio, Transición del Servicio, Operación del Servicio, Mejora 6 Continua del Servicio. En la siguiente figura podemos observar de manera gráfica este ciclo de vida. Figura 1: Ciclo de Vida – ITIL Fuente: (Luzuriaga, 2015) 2.2.3. 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. (Muro, 2013,p.17) La Gestión de Incidentes tiene como principal objetivo resolver cualquier incidente que cause una interrupción en el servicio de la manera más rápida y eficaz posible, no se preocupa de investigar y buscar las mínimas causas a un 7 determinado incidente sino exclusivamente a restaurar el servicio lo más pronto posible, minimizando el impacto negativo en las operaciones del negocio, entre las incidencias se puede incluir fallos o consultas reportadas por los usuarios, el equipo del servicio o por alguna herramienta de monitorización de eventos. (Luzuriaga, 2015) Procesos de gestión de incidentes Osiatitis (2012) sugiere tener estos procesos como parte de la gestión de incidencias. Registro: Las incidencias pueden provenir de diversas fuentes tales como usuarios, gestión de aplicaciones, el mismo Centro de Servicios o el soporte técnico, entre otros. Se debe comprobar que ese incidente aún no ha sido registrado y de esta forma evitar duplicaciones innecesarias.  Asignación de referencia: al incidente se le asignará una referencia que le identificará unívocamente tanto en los procesos internos como en las comunicaciones con el cliente.  Registro inicial: se han de introducir en la base de datos asociada la información básica necesaria para el procesamiento del incidente (hora, descripción del incidente, sistemas afectados...).  Información de apoyo: se incluirá cualquier información relevante para la resolución del incidente que puede ser solicitada al cliente a través de un formulario específico  Notificación del incidente: en los casos en que el incidente pueda afectar a otros usuarios estos deben ser notificados para que conozcan como esta incidencia puede afectar su flujo habitual de trabajo. Clasificación La clasificación de un incidente tiene como objetivo principal el recopilar toda la información que pueda ser de utilizada para la resolución del mismo. El proceso de clasificación debe implementar, al menos, los siguientes pasos: 8  Categorización: se asigna una categoría (que puede estar a su vez subdividida en más niveles) dependiendo del tipo de incidente o del grupo de trabajo responsable de su resolución. Se identifican los servicios afectados por el incidente.  Establecimiento del nivel de prioridad: dependiendo del impacto y la urgencia se determina, según criterios preestablecidos, un nivel de prioridad.  Asignación de recursos: si el Centro de Servicios no puede resolver el incidente en primera instancia designara al personal de soporte técnico responsable de su resolución (segundo nivel).  Monitorización del estado y tiempo de respuesta esperado: se asocia un estado al incidente (por ejemplo: registrado, activo, suspendido, resuelto, cerrado) Análisis, Resolución y Cierre de Incidentes Si la resolución del incidente se escapa de las posibilidades del Centro de Servicios éste redirecciona el mismo a un nivel superior para su investigación por los expertos asignados. Si estos expertos no son capaces de resolver el incidente se seguirán los protocolos de escalado predeterminados. Durante todo el ciclo de vida del incidente se debe actualizar la información almacenada en las correspondientes bases de datos para que los agentes implicados dispongan de cumplida información sobre el estado del mismo. Cuando se haya solucionado el incidente se:  Confirma con los usuarios la solución satisfactoria del mismo.  Incorpora el proceso de resolución a la Base de Conocimiento  Reclasifica el incidente si fuera necesario.  Cierra el incidente. 2.2.4. Metodología ICONIX Es una metodología pesada-ligera de desarrollo del Software que se halla a medio camino entre un RUP (Rational Unified Process) y un XP (eXtreme Programming). Es una metodología simplificada en comparación a otras más tradicionales, la cual unifica un conjunto de métodos de orientación a objetos con el objetivo de tener un control estricto sobre todo el ciclo de vida del producto a realizar, 9 cuenta con una secuencia de pasos que se deben seguir y determina claramente las actividades a desarrollar en cada etapa del ciclo de vida del proyecto que la utilice. (EcuRed, 2013) Características de ICONIX ICONIX deriva directamente de la Metodología RUP y su fundamento es el hecho de que un 80% de los casos pueden ser resueltos tan solo con un uso del 20% del UML, con lo cual se simplifica muchísimo el proceso sin perder documentación al dejar solo aquello que es necesario. Esto implica un uso dinámico del UML de tal forma que siempre se pueden utilizar otros diagramas además de los ya estipulados si se cree conveniente. Iconix se guía a través de casos de uso y sigue un ciclo de vida iterativo e incremental. El objetivo es que a partir de los casos de uso se obtenga el sistema final. ICONIX cuenta con tres características fundamentales: Iterativo e Incremental: durante el desarrollo del modelo del dominio y la definición de los casos de uso se producen varias iteraciones. El ciclo de vida incremental consiste en desarrollar por partes el producto de manera que puedas integrarlas funcionalmente. Ciclo de vida Iterativo, en cada ciclo de iteración se revisa y mejora el producto. El desarrollo se organiza en series de mini- proyectos cortos, llamados iteraciones. Trazabilidad: Cada paso que se realiza está definido por un requisito, se define la trazabilidad como la capacidad de seguir una relación entre los diferentes artefactos de software producidos. Dinámica del UML: Ofrece un uso dinámico del UML porque utiliza algunos diagramas UML, sin exigir la utilización de todos, como en el caso de RUP (Rational Unified Process). 10 Fases de ICONIX Revisión de los requisitos/ Análisis de Requisitos En esta fase se deben analizar todos los requisitos que formaran parte del sistema y con estos construir el diagrama de clases, que representa las agrupaciones funcionales que estructuraran el sistema en desarrollo. Para esta fase se utilizan 3 herramientas: Modelo de Dominio: esto se refiere a identificar objetos y cosas del mundo real que intervienen con nuestro sistema. Modelo de Casos de Uso: describe las acciones o el comportamiento que un usuario realiza dentro del sistema. Comprende de actores, casos de uso y el sistema. Prototipo de Interfaz de Usuario: implica la creación de un modelo o modelos operativos del trabajo de un sistema, en el que analistas y clientes deben estar de acuerdo. (Dinámico/ los usuarios se hacen participantes activos en el desarrollo). Revisión del diseño preliminar /Análisis y Diseño Preliminar En esta fase a partir de cada caso de uso se obtendrán una ficha de caso de uso, está formada por un nombre, una descripción, una precondición que debe cumplir antes de iniciarse, una post-condición que debe cumplir al terminar si termina correctamente. Realizar Diagrama de Robustez: es un híbrido entre un Diagrama de Clases y un Diagrama de Actividades. Es una herramienta que nos permite capturar el Que hacer y a partir de eso él Como hacerlo. Facilita el reconocimiento de objetos y hace más sencilla la lectura del sistema. El diagrama de Robustez se divide en: Objetos fronterizos: usado por los actores para comunicarse con el sistema. Objetos entidad: son objetos del modelo del dominio. Objetos de Control: es la unión entre la interfaz y los objetos de entidad. 11 Diagrama de Clases: describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Revisión crítica del Diseño/Diseño Detallado En esta fase se registran todos los elementos que forman parte de nuestro sistema. Diagramas de Secuencia: muestra los métodos que llevaran las clases de nuestro sistema. Muestra todos los cursos alternos que pueden tomar todos nuestros casos de uso. Se debe terminar el modelo estático, añadiendo los detalles del diseño en el diagrama de clases y verificar si el diseño satisface todos los requisitos identificados. Implementación Después de tener el diseño se creara el software; que posteriormente se entregara. Se debe utilizar el diagrama de componentes si fuera necesario para apoyar el desarrollo, es decir mostrar una distribución física de los elementos que componen la estructura interna del sistema. Así como escribir y generar el código. (Rosen/Scott, 2001 , p.1) Figura 2: Fases de la Metodología Iconix Fuente: (Reyes, 2009) 12 2.2.5. AngularJS AngularJS es un framework MVC de JavaScript para el Desarrollo Web Front End que permite crear aplicaciones SPA (Single-Page Applications). Es un proyecto de código abierto, realizado en Javascript que contiene un conjunto de librerías útiles para el desarrollo de aplicaciones web y propone una serie de patrones de diseño para llevarlas a cabo. En pocas palabras, es lo que se conoce como un framework para el desarrollo, en este caso sobre el lenguaje Javascript con programación del lado del cliente. (Basalo & Alvarez, 2014) Angular promueve y usa patrones de diseño de software con el cual se implementa la arquitectura MVC, estos patrones nos marcan la separación del código de los programas. Eso permite repartir la lógica de la aplicación por capas, lo que resulta muy adecuado para aplicaciones de negocio y para las aplicaciones SPA (Single Page Aplication). Arquitectura de AngularJS Modelo Vista Controlador (MVC) es un estilo de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. (Universidad de Alicante, 2015) Vistas: Es la representación visual de los datos, será el HTML y todo lo que represente datos o información. Controladores: Se encargarán de la lógica de la aplicación, recibe las órdenes del usuario y se encarga de solicitar los datos al modelo y de comunicárselos a la vista. Modelo: Se encarga de los datos, consultando la base de datos. Actualizaciones, consultas, búsquedas, etc. En la siguiente figura se puede observar de forma gráfica la arquitectura modelo vista controlador usado por AngularJS. 13 Figura 3: MVC de AngularJS Fuente: (angularjstutorials, 2015) 2.2.6. Node.js Node.js es un entorno JavaScript del lado del servidor, basado en eventos. Node ejecuta javascript utilizando el motor V8, desarrollado por Google para uso de su navegador Chrome. Aprovechando el motor V8 permite a Node proporcionar un entorno de ejecución del lado del servidor que compila y ejecuta javascript a velocidades increíbles. El aumento de velocidad es importante debido a que V8 compila Javascript en código de máquina nativo, en lugar de interpretarlo o ejecutarlo como bytecode. Node es de código abierto, y se ejecuta en Mac OS X, Windows y Linux. (NetConsulting, 2015,p.2) La principal característica de NodeJS es la conexión asíncrona, es decir que no tiene un intervalo de tiempo constante entre cada evento esto hace que Node sea muy rápido. El asincronismo es una característica de cualquier sistema de comunicación en el que el transmisor puede enviar datos sin previo aviso. El receptor debe estar preparado para aceptar datos en cualquier momento. 14 2.3. Definición de términos Servicios Un servicio es un medio para entregar valor a los clientes facilitándoles un resultado deseado sin la necesidad de que estos asuman los costes y riesgos específicos asociados. (Osiatitis, 2012) Incidencia Es la Interrupción no planificada de un servicio TI o la reducción de la calidad del servicio, entre las incidencias se puede incluir fallos o consultas reportadas por los usuarios, el equipo del servicio o por alguna herramienta de monitorización de eventos. (Osiatitis, 2012) Framework Es un conjunto de componentes (por ejemplo clases en java y descriptores y archivos de configuración en XML) que componen un diseño reutilizable que facilita y agiliza el desarrollo de sistemas Web (Gutierrez 2015, p.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.(Muro, 2013,p.1) SPA (Single-Page Application) Aplicación de página única es una aplicación web o es un sitio web que cabe en una sola página con el propósito de dar una experiencia más fluida a los usuarios como una aplicación de escritorio. (Amador, 2015,p.20) 15 3. MATERIAL Y MÉTODOS 3.1. Material 3.1.1. Población Par el desarrollo de esta tesis la población de estudio, está constituida por: Número promedio de incidencias registradas en el sistema en el año 2015. Y el número de clientes que tiene la empresa y usan el sistema. Población Nro. Promedio (2015) Número de incidencias 1554 Número de clientes 114 Tabla 1: Población Fuente: Elaboración Propia 3.2. Muestra La muestra está constituida por los clientes y las incidencias reportadas en el mes de Mayo a Junio del 2016 con un total de 26 Clientes y de 54 incidencias reportadas, esta muestra coincide si aplicamos la fórmula para el cálculo de muestra de poblaciones finitas. Donde: N = Total de la población Zα= 1.96 al cuadrado p = proporción esperada (en este caso 5% = 0.05) q = 1 – p (en este caso 1-0.05 = 0.95) d = precisión (0.05) Como resultado de la formula usada obtenemos como resultado un total de 54 incidencias. 16 Figura 4: Muestra Fuente: Elaboración Propia 3.2.1. Unidad de Análisis La unidad de análisis de esta investigación son los usuarios del Sistema de gestión de incidencias, los clientes de la Empresa y las incidencias registradas 3.3. Método 3.3.1. Nivel de Investigación Por el propósito de esta investigación es una investigación Tecnológica o profesional por el hecho que se aplicó técnicas y herramientas propias de la carrera profesional para dar solución al problema identificado, por la clase de medios es una investigación de campo por el hecho de que las características problemáticas son obtenidas de la empresa y por el alcance el nivel de investigación es explicativo porque explica el comportamiento de la variable independiente en función de la variable dependiente. 17 3.3.2. Diseño de Investigación En esta investigación con la finalidad de responder al problema planteado se llevó a cabo los siguientes pasos o etapas: Planeación: El propósito de esta etapa fue tener un plan de trabajo formal para desarrollar el sistema web de gestión de incidencias. El plan de trabajo es un conjunto de documentos que se utilizó para guiar y evaluar el desarrollo correcto de la investigación. Implementación: En esta etapa se llevaron a cabo los siguientes pasos basados en la metodología ICONIX:  Análisis de Requisitos: Se identificó los requerimientos del sistema, y se realizó el Modelo de Dominio, Prototipado, Modelos de Casos de Uso.  Análisis y Diseño Preliminar: Se realizó la Descripción de los Casos de Uso y Diagramas de Robustez.  Diseño: Se realizó los Diagramas de Secuencia, el diagrama de clases, diagrama de base de datos y el diseño de las interfaces.  Implementación: Se realizó el diagrama de componentes, el diagrama de despliegue y se escribió el código. Recolección de Datos: Con el apoyo de las técnicas de observación y encuestas realizadas a los usuarios se obtuvo la información necesaria para lograr los objetivos de la investigación. Análisis de Datos: Con los datos obtenidos se logró obtener información útil con el propósito de sugerir conclusiones en base a los objetivos planteados. Elaboración del Informe: este proceso final comprendió en resumir todo lo realizado en las etapas anteriores en un formato establecido, con las mejoras y correcciones recomendadas. 18 3.3.3. Variables de estudio y operacionalización Variable dependiente: Proceso de gestión de incidencias de la empresa RedTeam Software. Definición Conceptual: Proceso en el cual se da atención a las incidencias registradas para llegar a su solución. Definición Operacional: Tiempo de Atención, la demora en la solución a cada incidencia. Cantidad de Incidencias, porcentaje de incidencias solucionadas en un mes. Variable Independiente: Sistema web utilizando el framework AngularJs y Node.js Definición Conceptual: Software que se codifica en un lenguaje soportado por los navegadores web, que los usuarios pueden utilizar accediendo a un servidor web a través de Internet o de una intranet utilizando el framework angularjs para el lado del cliente y nodejs para el lado del servidor. Definición Operacional: Grado de Satisfacción de los clientes, nivel de satisfacción del cliente con el uso del sistema de gestión de incidencias y en la solución de incidencias Variable Dimensiones Indicadores Unidad de Instrumento de Medida Investigación Independiente (VI): X1: Satisfacción Grado de Niveles de Encuestas X: Sistema web utilizando Satisfacción de los Satisfacción el framework AngularJs y clientes. del cliente Node.js 19 Dependiente (VD): Y1 : Cantidad Porcentajes de Incidencias Observación Y: Proceso de gestión de de Incidencias incidencias directa incidencias de la empresa solucionadas RedTeam Software. Y2 : Tiempo Tiempo en dar Horas Observación solución a cada directa incidencia. Tabla 2: Operacionalización de Variables Fuente: Elaboración Propia 3.3.4. Técnicas e Instrumentos de recolección de datos La técnica utilizada es la observación, mediante esta técnica se pudo recolectar la información de los requerimientos que necesita la empresa para mejorar la gestión de incidencias. Así como también esta técnica se pudo tener el número de incidencias atendidas y solucionadas. Otra técnica de recolección de datos es la encuesta que fue realizada a los clientes con el fin de valorar su nivel de satisfacción con el uso del sistema de gestión de incidencias y con la solución a sus incidencias. 3.3.5. Técnicas de Procesamiento de datos Para el procesamiento de datos se usó la técnica de codificación y tabulación la cual consiste en asignar una identificación a los datos obtenidos de la observación y encuestas realizadas al cliente y luego representarlas a través de tablas para su posterior análisis. 3.3.6. Técnicas de análisis de datos Para el análisis de datos se usó la técnica de prueba de medias con la cual se realizó la contratación de la hipótesis. 20 4. RESULTADOS 4.1. Modelo de Negocio 4.1.1. Empresa RedTeam Software LLC, empresa norteamericana se encuentra ubicada en la ciudad de Orlando – Estados Unidos, está dedicada a proveer un software de gestión de Proyectos y Contabilidad para empresas del sector construcción. El software ofrece como principales características: Desarrollo de negocios: proporciona un Customer Relationship Management (CRM) construido específicamente para la industria de la construcción. Pre Construcción: proporciona estimación de costos, comparación de licitaciones, comunicación eficiente con los ofertantes y proveedores. Programación: permite crear y mantener los programas de tiempo y la ruta crítica de proyectos. Contratación: facilita la creación de formas personalizadas de los compromisos contractuales para cada propósito de negocio de la construcción. Gestión del rendimiento: permite a los clientes, empleados y proveedores poder colaborar en tiempo real en línea. Contabilidad: Ofrece la integración con sistemas de contabilidad basados en la nube. 4.1.2. Proceso de Atención de Incidencias El proceso de atención de incidencias empieza cuando un cliente mediante el software o por medio de correos o llamadas telefónicas, envía una incidencia a la empresa que puede ser un error o una falta de conocimiento del sistema, luego de esto el área de soporte administrativo se encarga de analizar y priorizar la incidencia, después la incidencia es asignada para los responsables de su solución que puede ser el área de desarrollo o el área de atención al cliente dependiendo del tipo de incidencia, los tipos de incidencias se clasifican en : 21 Oops: Incidencias Reportadas por errores en el sistema. Help me: Incidencias reportadas por falta de conocimiento del sistema o por ayuda. Data Changes: Incidencias reportadas para realizar cambios en los datos del cliente. Quickies: Incidencias reportadas para solucionar problemas lo antes posible. Ideas: Incidencias reportadas que el cliente necesita en un futuro. Mobile oops: Incidencias Reportadas por errores en la aplicación móvil Mobile Idea: Incidencias reportadas por falta de conocimiento del aplicativo móvil o por ayuda. Si los responsables de la incidencia es el área de atención al cliente, estos dan mayormente solución mediante una respuesta por email o por llamadas por teléfono. Si los responsables de la incidencia es el área de desarrollo, entonces el desarrollador encargado realiza los cambios necesarios para dar solución a la incidencia, esto se documenta en un archivo interno que maneja la empresa, y cuando se soluciona se informa que la incidencia fue corregida. Después de dar solución a la incidencia se notifica al cliente mediante email o llamada telefónica que su incidencia fue resuelta. El el siguiente grafico se resume el proceso de atención de una incidencia. Error encuentra Área de Atención al Cliente Cliente Informa o crea Soporte Administrativo Incidente Cliente requiere Ayuda Da solución Área de Desarrollo Documento de Registro Figura 5: Proceso de Atención de Incidencias Fuente: Elaboración Propia 22 4.1.3. Problema El modelo visual diagnostico describe la causa de la realidad problemática descrita en los párrafos anteriores. Atención de Incidencias Falta de seguimiento detallado de la incidencia Medios de Atención al Cliente Comunicación Falta de Información resumida Análisis y Cliente piorizacion Incidencias Incidencia Demora o Falta de Atención Soporte Administrativo Incidencias repetidas Cambios y Área de Desarrollo Soluciones Figura 6: Diagnostico del Problema Fuente: Elaboración Propia 4.1.4. Solución A continuación se describe el modelo visual que se centra en la propuesta de la solución conforme a lo analizado en la realidad problemática, la cual permitirá la mejora del proceso de gestión de incidencias de la empresa RedTeam Software LLC. Cliente Sistema Web de Base de Datos Gestión de Incidencias Incidencias Usuario Figura 7: Solución del Problema Fuente: Elaboración Propia 23 4.2. Análisis de Requisitos A continuación se detallan los requerimientos asociados al proceso de gestión de incidencias identificados en la recolección de datos: 4.2.1. Requerimientos Para el proceso de gestión de incidencias es necesario que el sistema tenga las siguientes funcionalidades:  Registro de Usuarios  Registro de Incidencias  Registro de Tipo de Incidencias  Registro de elementos del sistema(Ubicaciones)  Registro de Información Adicional  Asignar Incidencias para su solución  Registrar cambio de estado de la Incidencia  Registrar Solución de Incidencias  Listar Incidencias por criterio de búsqueda  Reporte resumen de incidencias reportadas y solucionadas por fecha 4.2.2. Diseño de Prototipos A continuación se presentan los prototipos de diseño del sistema, los cuales muestran de forma simulada como sería el sistema de información web propuesto como solución a la problemática de esta investigación: 24 4.2.2.1. Registro de Usuarios Figura 8 : Prototipo - Registro de Usuarios Fuente: Elaboración Propia 25 4.2.2.2. Registro de Tipo de Incidencias Figura 9: Prototipo - Registro de Tipo de Incidencias Fuente: Elaboración Propia 4.2.2.3. Registro de elementos del sistema (Ubicaciones) Figura 10: Prototipo - Registro de elementos del sistema (Ubicaciones) Fuente: Elaboración Propia 26 4.2.2.4. Registro de Incidencias Figura 11: Prototipo - Registro de Incidencias Fuente: Elaboración Propia 27 4.2.2.5. Registro de Información Adicional Figura 12: Prototipo - Registro de Información Adicional Fuente: Elaboración Propia 28 4.2.2.6. Asignar Incidencias para su solución Figura 13: Prototipo - Asignar Incidencias para su Solución Fuente: Elaboración Propia 4.2.2.7. Registrar cambio de estado de la Incidencia Figura 14: Prototipo - Registrar cambio de estado de la Incidencia Fuente: Elaboración Propia 29 4.2.2.8. Registrar Solución de Incidencias Figura 15: Prototipo - Registrar solicitud de Incidencias Fuente: Elaboración Propia 4.2.2.9. Listar Incidencias por criterio de búsqueda Figura 16: Prototipo – Listar Incidencias por criterio de búsqueda Fuente: Elaboración Propia 30 4.2.2.10. Reporte resumen de incidencias reportadas y solucionadas por fecha Figura 17: Prototipo – Reporte Resumen Fuente: Elaboración Propia 31 4.2.3. Casos de Usos Figura 18: Casos de Uso Fuente: Elaboración Propia 32 4.2.4. Modelo de dominio Figura 19: Modelo de Dominio Fuente: Elaboración Propia 33 4.3. Análisis y Diseño Preliminar 4.3.1. Especificaciones de Caso de Uso 4.3.1.1. Caso de Uso: Registro de Usuarios Caso de Uso Registro de Usuarios Actores Administrador Descripción Este caso de uso permite registrar los usuarios del sistema que tendrán acceso al sistema de gestión de incidencias. Precondición Correo por parte del jefe de desarrollo para agregar un nuevo usuario desarrollador. Secuencia Paso Acción Normal 1 Consultar si el usuario está registrado 2 Se ingresa los datos del nuevo usuario 3 Se hace click en la opción guardar PostCondición Se muestra mensaje de confirmación. Flujos Ninguno Alternativos Tabla 3: Especificación de Caso de Uso – Registro de Usuarios Fuente: Elaboración Propia 4.3.1.2. Caso de Uso: Registro de Tipo de Incidencias Caso de Uso Registro de Tipo de Incidencias Actores Administrador Este caso de uso permite registrar los tipos de Descripción incidencias. Correo por parte del jefe de desarrollo para agregar un Precondición nuevo tipo de incidencia. Paso Acción 1 Consultar si el tipo de incidencias está registrado Secuencia Normal 2 Se ingresa los datos del nuevo tipo de incidencia. 3 Se hace click en la opción guardar PostCondición Se muestra mensaje de confirmación. 34 Flujos Ninguno Alternativos Tabla 4: Especificación de Caso de Uso - Registro Tipo de Incidencias Fuente: Elaboración Propia 4.3.1.3. Caso de Uso: Registro de elementos del sistema (Ubicaciones) Caso de Uso Registro de elementos del sistema (Ubicaciones) Actores Administrador Descripción Este caso de uso permite registrar los elementos del sistema (ubicaciones) que serán parte de las incidencias registradas. Precondición Correo por parte del jefe de sistemas para agregar un nuevo elemento del sistema. Secuencia Paso Acción Normal 1 Consultar si el elemento del sistema está registrado 2 Se ingresa los datos del nuevo elemento del sistema 3 Se hace click en la opción guardar PostCondición Se muestra mensaje de confirmación. Flujos Ninguno Alternativos Tabla 5: Especificación de Caso de Uso - Registro Ubicaciones Fuente: Elaboración Propia 35 4.3.1.4. Caso de Uso: Registro de Incidencias Caso de Uso Registro de Incidencias Actores Usuario del Sistema Descripción Este caso de uso permite registrar las incidencias reportadas del sistema Precondición Registro en el sistema RedTeam o correo por parte los empleados del cliente reportando su problema o duda en el sistema Secuencia Paso Acción Normal 1 Click en la Opción de agregar incidencia 2 Consultar Tipos de Incidencia 3 Consultar el cliente al que pertenece la incidencia 4 Consultar el empleado que reporto la incidencia 5 Consultar el elemento del sistema (Ubicación) para la incidencia 6 Ingresar la información de la incidencia 7 Click en la opción guardar PostCondición Se muestra mensaje de confirmación. Se envía un correo al empleado del cliente informándole la creación de su incidencia Flujos Agregar Información adicional Alternativos Asignar Incidencias para su solución Tabla 6: Especificación de Caso de Uso - Registro de Incidencias Fuente: Elaboración Propia 36 4.3.1.5. Caso de Uso: Registro de Información Adicional Caso de Uso Registro de Información Adicional Actores Usuario del Sistema Descripción Este caso de uso permite registrar información adicional a la incidencia registrada Precondición Se debe tener registrada la incidencia Secuencia Paso Acción Normal 1 Click en la opción agregar información adicional por cada incidencia 2 Consultar Incidencia 3 Consultar Tipos Incidencia 4 Consultar Elementos del Sistema 2 Consultar prioridades de Incidencias 3 Cambiar o verificar datos de la incidencia Agregar información adicional (notas, documentos 4 adjuntos) 5 Se hace click en la opción guardar PostCondición Se muestra mensaje de confirmación. Flujos Ninguno Alternativos Tabla 7: Especificación de Caso de Uso - Registro de Información Adicional Fuente: Elaboración Propia 37 4.3.1.6. Caso de Uso: Asignar Incidencias para su solución Caso de Uso Asignar Incidencias para su solución Actores Usuario del Sistema Descripción Este caso de uso permite asignar los responsables de dar solución a la incidencia reportada. Precondición Se debe tener registrada la incidencia Secuencia Paso Acción Normal 1 Consultar Incidencias no Asignadas 2 Consultar usuarios con el rol de Analistas ,quien será el responsable de dar seguimiento a la incidencia hasta su solución 3 Consultar usuarios con el rol de Desarrollador , quien dará solución a la incidencia 4 Se hace click en la opción guardar PostCondición Se muestra mensaje de confirmación. Envía correo al Desarrollador con los datos de la incidencia asignada Flujos Ninguno Alternativos Tabla 8: Especificación de Caso de Uso – Asignar Incidencias para su solución Fuente: Elaboración Propia 38 4.3.1.7. Caso de Uso: Registrar cambio de estado de la Incidencia Caso de Uso Registrar cambio de estado de la Incidencia Actores Usuario del Sistema Descripción Este caso de uso permite registrar los cambios de estado de la incidencia Precondición Se debe tener registrada la incidencia Secuencia Paso Acción Normal 1 Consular Incidencias 2 Consultar estados de incidencia 3 Ingresar Acción realizada para poder cambiar de estado la incidencia 4 Se hace click en la opción guardar PostCondición Se muestra mensaje de confirmación. Flujos Ninguno Alternativos Tabla 9: Especificación de Caso de Uso – Registrar Cambio de estado de la Incidencia Fuente: Elaboración Propia 39 4.3.1.8. Caso de Uso: Registrar Solución de Incidencias Caso de Uso Registrar Solución de Incidencias Actores Usuario del sistema Descripción Este caso de uso permite registrar la solución dada a cada incidencia Precondición La incidencia debe haber sido reportada como completada y haber sido validada por quien reporto la incidencia Secuencia Normal Paso Acción 1 Consultar Incidencias 2 Se ingresa la información de la solución dada a la incidencia. 3 Se hace click en la opción guardar PostCondición Se muestra mensaje de confirmación. Flujos Alternativos Ninguno Tabla 10: Especificación de Caso de Uso – Registrar Solución de Incidencias Fuente: Elaboración Propia 40 4.3.1.9. Caso de Uso: Listar Incidencias por criterio de búsqueda Caso de Uso Listar Incidencias por criterio de búsqueda Actores Usuario del sistema Descripción Este caso de uso permite listar todas las incidencias reportadas en el sistema de acuerdo a criterios de búsqueda por el usuario Precondición Secuencia Paso Acción Normal 1 Click en opción de Ver Incidencias 2 Seleccionar criterio de búsqueda y Listar incidencias. PostCondición Flujos Registrar Incidencias Alternativos Reporte resumen de incidencias reportadas y solucionadas por fecha Tabla 11: Especificación de Caso de Uso – Listar Incidencias por criterio de búsqueda Fuente: Elaboración Propia 41 4.3.1.10. Caso de Uso: Reporte resumen de incidencias reportadas y solucionadas por fecha Caso de Uso Reporte resumen de incidencias reportadas y solucionadas por fecha Actores Usuario del sistema Descripción Este caso de uso permite ver el reporte de incidencias reportadas y solucionadas por fecha , y por cada responsable de dar solución a las incidencias(desarrollador) Precondición Tener Incidencias Solucionadas Secuencia Paso Acción Normal 1 Click en opción de Ver Reporte 2 Mostrar Reporte PostCondición Ninguno Flujos Ninguno Alternativos Tabla 12: Especificación de Caso de Uso – Reporte Resumen de Incidencias Reportadas y Solucionas por fecha Fuente: Elaboración Propia 42 4.3.2. Diagrama de Robustez 4.3.2.1. Registro de Usuarios Figura 20: Diagrama Robustez – Registro de Usuarios Fuente: Elaboración Propia 4.3.2.2. Registro de Tipo de Incidencias Figura 21: Diagrama Robustez – Registro de Tipo de Incidencias Fuente: Elaboración Propia 43 4.3.2.3. Registro de elementos del sistema (Ubicaciones) Figura 22: Diagrama Robustez – Registro de Elementos (Ubicaciones) Fuente: Elaboración Propia 4.3.2.4. Registro de Incidencias Figura 23: Diagrama Robustez – Registro de Incidencias Fuente: Elaboración Propia 44 4.3.2.5. Registro de Información Adicional Figura 24: Diagrama Robustez – Registro de Información Adicional Fuente: Elaboración Propia 45 4.3.2.6. Asignar Incidencias para su solución Figura 25: Diagrama Robustez – Asignar Incidencias para su Solución Fuente: Elaboración Propia 46 4.3.2.7. Registrar cambio de estado de la Incidencia Figura 26: Diagrama Robustez – Registro cambio de estado de incidencia Fuente: Elaboración Propia 47 4.3.2.8. Registrar Solución de Incidencias Figura 27: Diagrama Robustez – Registro de Solución de Incidencias Fuente: Elaboración Propia 4.3.2.9. Listar Incidencias por criterio de búsqueda Figura 28: Diagrama Robustez – Listar Incidencias por criterio de búsqueda Fuente: Elaboración Propia 48 4.3.2.10. Reporte resumen de incidencias reportadas y solucionadas por fecha Figura 29: Diagrama Robustez – Reporte resumen de Incidencias reportadas y solucionadas por fecha Fuente: Elaboración Propia 49 4.4. Diseño Detallado 4.4.1. Diagrama de Secuencia 4.4.1.1. Registro de Usuarios Figura 30: Diagrama Secuencia – Registro de Usuarios Fuente: Elaboración Propia 50 4.4.1.2. Registro de Tipo de Incidencias Figura 31: Diagrama Secuencia – Registro de Tipo de Incidencias Fuente: Elaboración Propia 4.4.1.3. Registro de elementos del sistema (Ubicaciones) Figura 32: Diagrama Secuencia – Registro de elementos (Ubicaciones) Fuente: Elaboración Propia 51 4.4.1.4. Registro de Incidencias Figura 33: Diagrama Secuencia – Registro de Incidencias Fuente: Elaboración Propia 52 4.4.1.5. Registro de Información Adicional Figura 34: Diagrama Secuencia – Registro de Información Adicional Fuente: Elaboración Propia 53 4.4.1.6. Asignar Incidencias para su solución Figura 35: Diagrama Secuencia – Asignar Incidencias para su solución Fuente: Elaboración Propia 54 4.4.1.7. Registrar cambio de estado de la Incidencia Figura 36: Diagrama Secuencia – Registrar cambio de estado de Incidencias Fuente: Elaboración Propia 4.4.1.8. Registrar Solución de Incidencias Figura 37: Diagrama Secuencia – Registrar Solución de Incidencias Fuente: Elaboración Propia 55 4.4.1.9. Listar Incidencias por criterio de búsqueda Figura 38: Diagrama Secuencia – Listar Incidencias por criterio de búsqueda Fuente: Elaboración Propia 4.4.1.10. Reporte resumen de incidencias reportadas y solucionadas por fecha Figura 39: Diagrama Secuencia – Reporte Resumen Fuente: Elaboración Propia 56 4.4.2. Diagrama de Clases Figura 40: Diagrama de Clases Fuente: Elaboración Propia 57 4.4.1. Diagrama de Base de Datos Rol Incidencia Estado Column Name Condensed Type Column Name Condensed Type Column Name Condensed Type Rol_ID int IncidenciaID int EstadoID int Nombre varchar(50) Descripcion varchar(500) Nombre varchar(100) Description varchar(150) Fecha_Creacion datetime Descripcion varbinary(250) UsuarioCreador int Cliente int Tipo int Estado int Ubicacion int ArchivoAdjunto varchar(100) Usuarios Nota varchar(500) Column Name Condensed Type Ubicacion AnalistaResponsable int Column Name Condensed Type UsuarioID int DesarrolladorResponsable int UbicacionID int UserName varchar(50) Solucion varchar(100) Nombre varchar(100) Nombre varchar(50) Fecha_Solucion datetime Descripcion varchar(250) Apellido varchar(50) Email varchar(50) Contraseña varchar(50) Rol int Cliente EmpleadoCliente Column Name Condensed Type Column Name Condensed Type Acciones ClienteID int EmpleadoID int Column Name Condensed Type Nombre varchar(150) AccionID int Nombre varchar(50) Telefono varchar(50) IncidenciaID int Apellido varchar(50) Email varchar(50) TipoAccion varchar(50) Email varchar(50) Direccion varchar(100) Descripcion varchar(250) Telefono varchar(50) Fecha datetime Figura 41: Diagrama de Base de Datos Fuente: Elaboración Propia 58 4.4.2. Diseño de Interfaces 4.4.2.1. Registro de Usuarios Figura 42: Interfaz Registro de Usuario Fuente: Elaboración Propia 59 4.4.2.1. Registro de Tipo de Incidencias Figura 43: Interfaz Registro de Tipo de Incidencias Fuente: Elaboración Propia 60 4.4.2.2. Registro de elementos del sistema (Ubicaciones) Figura 44: Interfaz Registro de elementos del Sistema Fuente: Elaboración Propia 61 4.4.2.3. Registro de Incidencias Figura 45: Interfaz Registro de Incidencias Fuente: Elaboración Propia 62 4.4.2.4. Registro de Información Adicional Figura 46: Interfaz Registro de Información Adicional Fuente: Elaboración Propia 63 4.4.2.5. Asignar Incidencias para su solución Figura 47: Interfaz Asignar Incidencias Fuente: Elaboración Propia 64 4.4.2.6. Registrar cambio de estado de la Incidencia Figura 48: Interfaz Cambiar de Estado Fuente: Elaboración Propia 65 4.4.2.7. Registrar Solución de Incidencias Figura 49: Interfaz Registrar Solución Fuente: Elaboración Propia 66 4.4.2.8. Listar Incidencias por criterio de búsqueda Figura 50: Interfaz Listar Incidencias Fuente: Elaboración Propia 67 4.4.2.9. Reporte resumen de incidencias reportadas y solucionadas por fecha Figura 51: Interfaz Reporte resumen de incidencias Fuente: Elaboración Propia 68 4.5. Implementación 4.5.1. Diagrama de Componentes Figura 52: Diagrama Componentes Fuente: Elaboración Propia 4.5.2. Diagrama de Despliegue Figura 53: Diagrama Despliegue Fuente: Elaboración Propia 69 5. DISCUSIÓN DE RESULTADOS En este capítulo se evaluara si la hipótesis planteada da solución al problema por resolver, esto se realizara mediante la contrastación de la hipótesis planteada en nuestra investigación, basada en los indicadores como: satisfacción del usuario, cantidad de incidencias y porcentaje incidencias atendidas; usando el método de Pre-Test y Post-Test. 5.1. Hipótesis Un sistema web utilizando el framework AngularJs y Node.js mejora la gestión de incidencias en la empresa RedTeam Software LLC. 5.2. Variables Variable Dependiente: Proceso de gestión de incidencias de la empresa RedTeam Software. Variable Independiente: Sistema web utilizando el framework AngularJs y Node.js 5.3. Operacionalización de Variables Variable Dimensiones Indicadores Independiente (VI): X1: Satisfacción Grado de Satisfacción X: Sistema web utilizando el de los clientes. framework AngularJs y Node.js Dependiente (VD): Y1 : Cantidad de Porcentajes de Y: Proceso de gestión de Incidencias incidencias incidencias de la empresa RedTeam solucionadas Software. Y2 : Tiempo Tiempo en dar solución a cada incidencia. Tabla 13: Operacionalidad de Variables Fuente: Elaboración Propia 70 La inferencia de la validez de la hipótesis será comprobada si del total de indicadores medidos (satisfacción del cliente, porcentaje de incidencias atendidas y tiempo en data solución a cada incidencias), por lo menos dos de estos son aceptados. 5.4. Contrastación de la Hipótesis Para todos los Indicadores Cuantitativos se procederá de la siguiente manera: Paso 1: Definición de la variable a evaluar. Paso 2: Planteamiento de la hipótesis estadística. Paso 3: Definición del nivel de significancia, para todos será del 5%. Por lo tanto el Nivel de Confianza (1-α = 0.95) será del 95%. Paso 4: Definición del tipo de prueba a aplicar, para todos será la prueba de T-Student para muestras independientes. Paso 5: Tabulación de valores obtenidos antes y después de la implementación del sistema de información web de gestión de incidencias Paso 6: Búsqueda del Valor de Estadístico T y el Valor de P. Paso 7: Redacción de la conclusión de la prueba estadística. 5.4.1. Indicador Tiempo en dar solución a cada incidencia. Se mide el tiempo que toma en dar solución a una incidencia reportada.  Test (T1): Medición previa de la variable dependiente a ser utilizada.  Post-Test (T2): Corresponde a la nueva medición de la variable dependiente a ser utilizada. Dónde: T1_X_T2 T1: Tiempo que toma dar solución a las incidencias con el proceso anterior. X: (Aplicación de la variable independiente) Sistema web utilizando el framework AngularJS y Node.JS T2: Tiempo que toma dar solución a las incidencias con el uso del sistema web. 71 Se realizó la tabulación de los datos con dos muestras, las Incidencias reportadas en las meses de Mayo a Junio del 2015 con un total de 183 incidencias y una muestra de incidencias reportadas en los meses de Mayo a Junio del 2016 con un Total de 54 incidencias, estos datos se pueden ver los anexos (B. Tiempo en dar solución a las Incidencias - (Mayo a Junio 2015) y C. Tiempo en dar solución a las Incidencias - (Mayo a Junio 2016) ) .Se utilizó la herramienta de análisis estadístico SPSS para realizar la prueba de muestras independientes; obteniéndose los siguientes resultados. Prueba de muestras independientes prueba t para la igualdad de medias 95% de intervalo de confianza de la diferencia Sig. Diferencia de Diferencia de t gl (bilateral) medias error estándar Inferior Superior 3.233 235 .001 6.72010 2.07847 2.62529 10.81490 Tabla 14: Prueba de Muestras Independientes - Indicador de Tiempo Fuente: Elaboración Propia Hipótesis estadística: Hipótesis H0: El tiempo que toma dar solución a las incidencias antes de la Implementación del Sistema web de gestión de incidencias es igual que el tiempo que toma dar solución a las incidencias después de la implementación del Sistema web antes mencionado. Hipótesis Hi: El tiempo que toma dar solución a las incidencias antes de la Implementación del Sistema web de gestión de incidencias es diferente que el tiempo que toma dar solución a las incidencias después de la implementación del Sistema web antes mencionado. 72 Conclusión De acuerdo a los resultados obtenidos, el valor de P es menor al nivel de significancia = 0.0010, por lo cual se rechaza la Hipótesis Nula H0 y se acepta la Hipótesis Alternativa, por lo que se demuestra una diferencia significativa en los en Tiempos que toma dar solución a las incidencias utilizando el Sistema web de gestión de incidencias. 5.4.2. Indicador Porcentaje de incidencias solucionadas Se mide el porcentaje de incidencias reportadas que fueron solucionadas  Test (T1): Medición previa de la variable dependiente a ser utilizada.  Post-Test (T2): Corresponde a la nueva medición de la variable dependiente a ser utilizada. Dónde: T1_X_T2 T1: porcentaje de incidencias solucionadas con el proceso anterior. X: (Aplicación de la variable independiente) Sistema web utilizando el framework AngularJS y Node.JS T2: porcentaje de incidencias solucionadas con el uso del sistema web. En la siguiente tabla y grafico se muestra una comparación de los datos de las incidencias reportadas con las incidencias solucionadas para las dos muestras realizadas Periodo Incidencias Incidencias Reportadas Solucionadas Mayo - 2015 101 56 Junio - 2015 82 62 Mayo - 2016 34 30 Junio - 2016 20 26 Tabla 15: Comparación de Incidencias Reportadas vs Incidencias Atendidas Fuente: Elaboración Propia 73 Figura 54: Incidencias Reportadas vs Incidencias Solucionadas Fuente: Elaboración Propia Se realizó la tabulación de los datos con dos muestras, las Incidencias solucionadas en el año 2015 en los meses de Mayo a Junio y una muestra de incidencias solucionadas en el año 2016 en los meses de Mayo a Junio del . Se utilizó la herramienta de análisis estadístico SPSS para realizar la prueba de muestras independientes; obteniéndose los siguientes resultados. Prueba de muestras independientes prueba t para la igualdad de medias 95% de intervalo de confianza de la diferencia Diferencia Sig. Diferencia de error t gl (bilateral) de medias estándar Inferior Superior 8.598 2 .013 31.00000 3.60555 15.48656 46.51344 Tabla 16: Prueba de Muestras Independientes - Indicador de Porcentaje Fuente: Elaboración Propia 74 Hipótesis estadística: Hipótesis H0: La cantidad de incidencias solucionadas antes de la Implementación del Sistema web de gestión de incidencias es igual que el que la cantidad de incidencias solucionadas después de la implementación del Sistema web antes mencionado. Hipótesis Hi: La cantidad de incidencias solucionadas antes de la Implementación del Sistema web de gestión de incidencias es diferente que la cantidad de incidencias solucionadas después de la implementación del Sistema web antes mencionado. Conclusión De acuerdo a los resultados obtenidos, el valor de P es menor al nivel de significancia = 0.013, por lo cual se rechaza la Hipótesis Nula H0 y se acepta la Hipótesis Alternativa, por lo que se demuestra una diferencia significativa en las cantidades de incidencias solucionadas utilizando el Sistema web de gestión de incidencias. 5.4.3. Indicador Grado de Satisfacción del cliente Se mide el grado de satisfacción del cliente, para lo cual utilizamos una encuesta dirigida al cliente para ver su nivel de satisfacción luego de dar solución a sus incidencias a continuación se muestra el resultado de las encuestas: Satisfacción Grado Muy Baja (MB) 1 Baja (B) 2 Media (M) 3 Alta (A) 4 Muy Alta (MA) 5 Tabla 17: Niveles de Satisfacción del Cliente Fuente: Elaboración Propia 75 Figura 55: Datos de Nivel de Satisfacción del cliente Fuente: Elaboración Propia Conclusión De acuerdo a los porcentajes obtenidos en los resultados de las encuestas, estos demostraron que el grado de satisfacción de los clientes se encuentra entre Muy Alta o Alta o Media, lo que indica que el sistema web mejora el nivel de satisfacción del cliente. 76 6. CONCLUSIONES  Se recopiló información propia de la empresa y de su proceso de gestión de incidencias, esto nos permitió identificar la realidad problemática del proceso de gestión de incidencias con la finalidad de obtener los principales requerimientos que fueron la base para el desarrollo del sistema.  Se concluye que se obtuvieron todos los artefactos necesarios de acuerdo a la metodología de desarrollo ICONIX en la etapa de análisis, diseño e implementación obteniéndose así, lo siguiente:  1 Diagrama de Modelado de Negocio, 1 Pictograma Actual y 1 Solucionador.  10 Requerimientos y 10 diseños de prototipos  1 Diagrama de Modelo de Dominio , 1 Diagramas de Casos de Uso  10 Especificaciones de Casos de Uso, 10 Diagramas de Robustez y 10 Diagramas de Secuencia  10 Prototipos de Pantalla  1 Diagrama de Clases con 9 Clases de Análisis  1 Diagrama de Base de Datos  1 Diagrama de Componentes  1 Diagrama de Despliegue  Se logró la implementación del sistema de gestión de incidencias y como consecuencia de la investigación realizada, se ha llegado a la conclusión de que el proyecto es tecnológicamente factible y mejora el proceso de gestión de incidencias.  Con la implementación del sistema web de gestión de incidencias se logró reducir el tiempo en dar solución a las incidencias reportadas de 129.46 horas (100%) a 69.83 horas (53.93) % con lo que se consigue una reducción del tiempo de 59.63 horas. Que en porcentaje es de 46.06 %, se logró aumentar el porcentaje de atención de incidencias en un 43.59%, además se aumentó el nivel de satisfacción del cliente. 77 7. RECOMENDACIONES  Se recomienda estar en constante investigación e identificación de requerimientos para mejorar el proceso de gestión de incidencias a fin de seguir aumentando la satisfacción del cliente.  Esta tesis está desarrollada bajo los requerimientos y necesidades de la empresa por lo cual se recomienda enfocar el proceso de gestión de incidencias bajo el enfoque de ITIL debido a que es un marco de buenas prácticas en la gestión de servicios.  Se recomienda utilizar metodologías agiles con ICONIX, dado que ofrece un desarrollo más ágil y se adapta a muchos tipo de desarrollo.  Se recomienda a la empresa RedTeam Software capacitar al personal para el buen uso del sistema de gestión de incidencias desarrollado.  Se recomienda seguir investigando los Frameworks Angularjs y Nodejs debido al rápido crecimiento de estas tecnologías y su constante actualización. 78 8. REFERENCIAS BIBLIOGRÁFICAS Amador, D. A. (2015). Diseño e implementación de una aplicación web para una tienda virtual. Obtenido de http://repositorio.upct.es/bitstream/handle/10317/5199/tfg735.pdf?sequence=1&isA llowed=y angularjstutorials. (2015). angularjstutorials.net. Obtenido de http://www.angularjstutorials.net/angularjs_mvc.html Apaza, V. C. (2014). Modelo de gestión de incidencias basado en ITIL para reducir el tiempo de diagnóstico de incidentes del servicio de soporte técnico en la universidad nacional del altiplano puno – 2014. Universidad Nacional Del Altiplano. Obtenido de http://repositorio.unap.edu.pe/bitstream/unappuno/104/1/Modelo%20de%20Gesti% C3%B3n%20de%20Incidencias%20Basado%20en%20ITIL.pdf Basalo, A., & Alvarez, M. A. (2014). Qué es AngularJS. Obtenido de http://www.desarrolloweb.com/articulos/que-es-angularjs-descripcion-framework- javascript-conceptos.html Cadavieco, J. F., Pérez, C. R., & Fernández, C. B. (2012). Gestión de incidencias informáticas: el caso de la Universidad de Oviedo y la Facultad de Formación del Profesorado. Obtenido de http://www.raco.cat/index.php/RUSC/article/viewFile/284627/372853 Casas, J. Á., & Chircca, L. D. (2014). Mejora de los procesos de gestión de incidencias y cambios aplicando ITIL en la facultad de administración – USMP. Universidad Privada San Martin de Porres – USMP. Obtenido de http://www.repositorioacademico.usmp.edu.pe/bitstream/usmp/1158/1/evangelista_ c.pdf EcuRed. (2013). Ecured Conocimiento con todos y para todos. Recuperado el 15 de Abril de 2016, de Iconix: http://www.ecured.cu/ICONIX Gutierrez, J. (s.f.). ¿Qué es un framework web? Recuperado el 27 de 05 de 2016, de http://www.lsi.us.es/~javierj/investigacion_ficheros/Framework.pdf Lobos Anfuso, D. d., Baquinzay, M., & Bustos Aguiar, M. S. (2008). GESTION DE SERVICIOS TIC (Tecnología de la información y las comunicaciones) – ITIL . REVISTA DE DIVULGACIÓN CIENTÍFICA DE CIENCIA Y TECNOLOGÍA DE LA UNCa. , 26. Luzuriaga, M. (2015). Diseño de los procesos de gestión de incidencias y Service Desk, alineado a las buenas prácticas de ITIL, aplicado a la empresa Delltex industrial S.A. Pontificia Universidad Católica del ecuador. Obtenido de http://repositorio.puce.edu.ec/handle/22000/8522 Muro, L. C. (2013). 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. Lima: Pontifica Universidad Catolica del Peru. Obtenido de http://tesis.pucp.edu.pe/repositorio/bitstream/handle/123456789/5471/GAMARRA_ LUIS_DISE%C3%91O_APLICACION_MOVIL_MODULO_INCIDENCIAS_SIS TEMA_GESTION_SERVICIOS.pdf?sequence=1 NetConsulting. (30 de Septiembre de 2015). Blog de NetConsulting. Obtenido de Node.js: ¿Qué es y para que sirve NodeJS?: http://www.netconsulting.es/blog/nodejs/ 79 Osiatitis. (2012). ITIL®-Gestión de Servicios TI. Recuperado el Mayo de 2016, de ITIL®- Gestión de Servicios TI: http://itil.osiatis.es/Curso_ITIL/ Reyes, J. C. (2009). ICONIX - Metodologías ágiles. Obtenido de http://es.slideshare.net/juliozet/iconix-2578166 Rosen/Scott. (2001 de Octubre de 2001). INFORMIT. Obtenido de INFORMIT: http://www.informit.com/authors/bio/ac65029f-c618-4a71-b0a5-51ddaf61b3d9 Sandoval, F. L., & Mejia, K. R. (2011). Modelo para la implementación de ITIL en una institución universitaria. Santiago de Cali. Universidad de Alicante. (2015). Servicio de Informatica ASP.NET MVC 3 Framework. Obtenido de http://si.ua.es/es/documentacion/asp-net-mvc-3/1-dia/modelo-vista- controlador-mvc.html 80 9. ANEXOS A. Matriz de Consistencia PROBLEMA OBJETIVOS HIPÓTESIS VARIABLES Problema: Objetivo General: Hipótesis: Variables de estudio: ¿Cómo mejorar el Desarrollar un sistema informático web Un sistema web Variable Independiente: Sistema proceso de Gestión de de gestión de incidencias utilizando el utilizando el framework web utilizando el framework incidencias en la framework AngularJS y Node.js para la AngularJs y Node.js AngularJs y Node.js Empresa RedTeam empresa RedTeam Software LLC. mejora la gestión de Indicadores: Software LLC con el uso Objetivos Específicos: incidencias en la  Grado de Satisfacción de los de tecnologías de  Analizar el proceso actual de gestión de empresa RedTeam clientes. información? incidencias para lograr identificar las Software LLC. necesidades de funcionalidad del Variable Dependiente: Proceso sistema. de gestión de incidencias de la  Realizar el análisis y diseño del proceso empresa RedTeam Software. de gestión de incidencias utilizando la Indicadores metodología de desarrollo ICONIX.  Porcentajes de incidencias  Construir el sistema informático web solucionadas de gestión de incidencias usando el  Tiempo en dar solución a cada Framework AngularJs y Node.js incidencia. 81 B. Tiempo en dar solución a las Incidencias - (Mayo a Junio 2015) Datos históricos de las incidencias atendidas por su tipo en los meses de Mayo y Junio del 2015. Tiempo Solución Numero Incidencia Tipo (horas) 1 Quickie 9 2 Data Changes 4 3 Mobile Idea 23 4 Oops 18 5 Mobile Oops 14 6 Help me 6 7 Oops 14 8 Oops 12 9 Mobile Idea 57 10 Mobile Idea 48 11 Oops 8 12 Quickie 8 13 Oops 20 14 Mobile Oops 20 15 Oops 11 16 Quickie 14 17 Mobile Oops 12 18 Help me 14 19 Ideas 27 20 Mobile Idea 60 21 Mobile Oops 19 22 Help me 13 23 Ideas 40 24 Data Changes 2 25 Ideas 34 26 Help me 13 27 Mobile Oops 17 28 Mobile Oops 10 29 Mobile Idea 33 30 Mobile Idea 29 31 Data Changes 3 32 Quickie 5 33 Mobile Oops 14 34 Mobile Oops 18 35 Mobile Oops 10 82 36 Ideas 38 37 Help me 16 38 Quickie 6 39 Oops 16 40 Quickie 15 41 Mobile Idea 53 42 Oops 12 43 Data Changes 3 44 Quickie 16 45 Oops 8 46 Quickie 10 47 Mobile Oops 13 48 Mobile Idea 28 49 Ideas 58 50 Ideas 34 51 Ideas 46 52 Data Changes 4 53 Data Changes 3 54 Data Changes 2 55 Oops 13 56 Help me 12 57 Help me 15 58 Mobile Oops 12 59 Quickie 7 60 Mobile Idea 24 61 Quickie 12 62 Quickie 16 63 Help me 9 64 Quickie 10 65 Oops 10 66 Mobile Idea 28 67 Oops 15 68 Mobile Idea 53 69 Mobile Idea 24 70 Ideas 56 71 Help me 15 72 Help me 8 73 Data Changes 2 74 Oops 8 75 Mobile Idea 43 76 Ideas 40 83 77 Mobile Oops 14 78 Quickie 9 79 Help me 12 80 Mobile Oops 15 81 Ideas 36 82 Oops 15 83 Mobile Oops 19 84 Help me 9 85 Mobile Oops 15 86 Oops 17 87 Oops 13 88 Oops 10 89 Ideas 37 90 Mobile Oops 11 91 Oops 13 92 Ideas 58 93 Mobile Oops 10 94 Oops 13 95 Data Changes 4 96 Help me 6 97 Mobile Idea 48 98 Mobile Oops 13 99 Quickie 4 100 Oops 14 101 Oops 15 102 Ideas 41 103 Quickie 4 104 Mobile Oops 13 105 Help me 13 106 Data Changes 2 107 Data Changes 3 108 Ideas 35 109 Oops 8 110 Mobile Oops 15 111 Mobile Idea 42 112 Help me 7 113 Mobile Idea 34 114 Help me 14 115 Ideas 48 116 Oops 15 117 Data Changes 2 84 118 Oops 15 119 Ideas 20 120 Oops 15 121 Quickie 7 122 Mobile Oops 18 123 Data Changes 4 124 Quickie 9 125 Oops 10 126 Mobile Oops 10 127 Mobile Idea 28 128 Data Changes 3 129 Mobile Oops 16 130 Quickie 4 131 Mobile Idea 18 132 Help me 6 133 Ideas 19 134 Oops 11 135 Ideas 22 136 Data Changes 2 137 Mobile Idea 39 138 Mobile Idea 38 139 Quickie 16 140 Quickie 4 141 Ideas 48 142 Mobile Oops 17 143 Mobile Idea 27 144 Quickie 7 145 Mobile Oops 19 146 Mobile Oops 14 147 Mobile Oops 19 148 Ideas 48 149 Quickie 5 150 Oops 14 151 Quickie 16 152 Mobile Oops 10 153 Mobile Idea 24 154 Ideas 52 155 Data Changes 4 156 Quickie 12 157 Help me 14 158 Ideas 37 85 159 Ideas 50 160 Data Changes 2 161 Help me 13 162 Help me 10 163 Data Changes 3 164 Ideas 57 165 Quickie 16 166 Help me 9 167 Data Changes 4 168 Data Changes 3 169 Data Changes 3 170 Quickie 12 171 Ideas 23 172 Help me 17 173 Help me 15 174 Mobile Oops 10 175 Mobile Idea 57 176 Quickie 13 177 Quickie 8 178 Quickie 14 179 Data Changes 4 180 Data Changes 4 181 Data Changes 4 182 Mobile Oops 18 183 Quickie 9 86 C. Tiempo en dar solución a las Incidencias - (Mayo a Junio 2016) Datos históricos de las incidencias atendidas por su tipo en los meses de Mayo y Junio del 2016. Numero Tiempo Solucion Tipo Incidencia (horas) 1 Mobile Idea 24 2 Mobile Idea 20 3 Quickie 7 4 Help me 4 5 Ideas 34 6 Quickie 5 7 Mobile Idea 13 8 Mobile Oops 5 9 Data Changes 1 10 Mobile Oops 6 11 Quickie 9 12 Ideas 23 13 Quickie 6 14 Oops 8 15 Data Changes 1 16 Mobile Oops 4 17 Oops 8 18 Oops 4 19 Ideas 28 20 Help me 3 21 Oops 6 22 Oops 7 23 Quickie 10 24 Ideas 23 25 Data Changes 3 26 Oops 7 27 Ideas 25 28 Mobile Idea 14 29 Quickie 4 30 Mobile Idea 13 31 Ideas 20 32 Mobile Idea 17 33 Help me 6 34 Mobile Idea 26 87 35 Quickie 5 36 Mobile Idea 23 37 Mobile Idea 22 38 Mobile Oops 6 39 Data Changes 2 40 Mobile Idea 26 41 Data Changes 3 42 Mobile Oops 7 43 Mobile Idea 16 44 Help me 3 45 Ideas 16 46 Mobile Idea 19 47 Quickie 8 48 Help me 4 49 Mobile Idea 17 50 Mobile Oops 8 51 Mobile Oops 7 52 Oops 7 53 Help me 7 54 Quickie 10 D. Tiempo Promedio en dar solución a las Incidencias Tiempo promedio en dar solución a las incidencias en los meses de Mayo a Junio de los años 2015 y 2016 Tiempo Promedio (Horas) Tipos de Incidencias Mayo-Junio Mayo-Junio (2015) (2016) Oops 12.96 6.71 Help me 11.56 4.5 Data Changes 3.08 2 Ideas 40.16 24.14 Mobile Idea 37.3 19.23 Quickie 9.9 7.11 Mobile Oops 14.5 6.14 TOTALES 129.46 69.83 88 E. Encuesta a clientes Esta encuesta fue enviada a los clientes cuando sus incidencias reportadas fueron solucionadas 89