1
Aplicación web para el control de incidencias en la Superintendencia Nacional
de los Registros Públicos
Tesis para optar el Título de Ingeniero de Sistemas y Cómputo
Braulio Esteban Perleche Moncada
Asesor
MSc. Héctor Hernán Henríquez Taboada
2 DEDICATORIA La presente investigación está dedicada a mis padres por su incondicional apoyo.
3
ÍNDICE
ÍNDICE DE FIGURAS ... 6
ÍNDICE DE TABLAS ... 7
RESUMEN ... 8
ABSTRACT ... 9
INTRODUCCIÓN ... 10
CAPÍTULO I: PLANTEAMIENTO DEL PROBLEMA ... 12
1.1. Situación Problemática ... 12
1.2. Formulación del Problema ... 14
- General - Específicos 1.3. Objetivos ... 14
- General - Específicos 1.4. Justificación ... 15
1.5. Alcances ... 16
CAPÍTULO II: MARCO TEÓRICO ... 17
2.1. Antecedentes de la investigación ... 17
2.2. Bases teóricas ... 19
2.3. Marco conceptual ... 34
CAPÍTULO III: MÉTODOLOGÍA DE LA INVESTIGACIÓN ... 35
3.1. Método ... 35
3.2. Técnicas ... 36
3.3. Herramientas ... 37
CAPÍTULO IV: DESARROLLO DE LA SOLUCIÓN TECNOLÓGICA ... 42
4.1. Modelo de caso de negocio ... 42
4.2. Diagrama de actividades AS-IS ... 47
4.3. Diagrama de actividades TO BE ... 50
4.4. Matriz de Proceso y Funcionalidades ... 53
4.5. Matriz de Requerimientos Adicionales ... 53
4.6. Flujo de Requerimientos ... 54
4.7. Diagrama de casos de uso ... 56
4.8. Especificaciones de caso de uso ... 57
4.9. Base de Datos ... 79
4.10. Relación de Entidades ... 83
4.11. Fase de Construcción ... 84
4
4.13. Diagrama de Despliegue ... 87
CAPÍTULO V: VALIDACIÓN DE LA SOLUCIÓN TECNOLÓGICA ... 88
CONCLUSIONES……….……….. 102
RECOMENDACIONES……….……….103
5
ÍNDICE DE FIGURAS
Figura 1.1: Actual Situación Problemática SUNARP. ... 14
Figura 2.1: Diagrama de Prioridades. ... .21
Figura 2.2: Arquitectura General de RUP. ... 23
Figura 2.3: Arquitectura de 03 capas en la aplicación web desde el punto de vista funcional. … ... 28
Figura 2.4: Detalle de la arquitectura de las 03 capas en una Aplicación Web. ... 30
Figura 2.5: Metodología PDCA aplicada a la gestión del servicio adaptado de 20000, I. I. (2011). … .. 33
Figura 2.6: Procesos de Gestión de Servicios Imagen recuperada de Certificación ... 33
Figura 4.1: Detalle casos de uso del negocio. ... 46
Figura 4.2: Diagrama de Actividades – Proceso de registro de las incidencias AS-IS. ... 47
Figura 4.3: Diagrama de Actividades – Proceso sobre la atención de las Incidencias AS-IS. ... 48
Figura 4.4: Diagrama de Actividades – Proceso de sobre el seguimiento de las incidencias AS-IS. …... 49
Figura 4.5: Diagrama de Actividades - Proceso de registro de las incidencias TO-BE. ... 50
Figura 4.6: Diagrama de Actividades - Proceso sobre atención de las incidencias TO-BE. ... 51
Figura 4.7: Diagrama de Actividades – Proceso sobre el seguimiento de las incidencias TO-BE. ... 52
Figura 4.8: Identificación sasos de uso. ... 55
Figura 4.9: Diagrama de Casos de Uso. ... 56
Figura 4.10: Modelo de Datos Parte 1. ... 79
Figura 4.11: Modelo de Datos Parte 2. ... 80
Figura 4.12: Modelo de Datos Parte 3. ... 81
Figura 4.13: Modelo de Datos Parte 4. ... 82
Figura 4.14: Relación de Entidades. ... 83
Figura 4.15: Diagrama de Arquitectura MVC de la Aplicación Web. ... 84
Figura 4.16: Diagrama de Componentes. ... 86
Figura 4.17: Diagrama de Despliegue. ... 87
Figura 5.1: Acceso a la aplicación web SUNARP. ... 88
Figura 5.2: Validación que la aplicación web reduce los tiempos de atención. ... 89
Figura 5.3: Validación que la aplicación web reduce los tiempos de atención. ... 90
Figura 5.4: Análisis de Tiempo Transcurrido – Estado, Grupo y Técnicos. ... 91
Figura 5.5: Validación que la aplicación web mejora el seguimiento de atenciones. ... 92
Figura 5.6: Seguimiento de atención de incidencias Estado Cerrado. ... 93
Figura 5.7: Seguimiento de atención de incidencias Estado En Proceso. ... 94
Figura 5.8: Seguimiento de atención de incidencias Estado En Espera. ... 95
Figura 5.9: Validación que la aplicación web presenta informes de atención ... 96
Figura 5.10: Cantidad de atención mensuales. ... 97
Figura 5.11: Cuadro de tickets comparativos por mes. ... 97
6
Figura 5.13: Registro de Tickets por día. ……….………...…..………..………98
Figura 5.14: Reporte de atención de incidencias. ………..…...……..………..………….99
Figura 5.15: Cumplimiento de los niveles de servicio y el nivel de servicio SLA ………100
Figura 5.16:Cumplimiento de tiempo máximo y reportes estadísticos de los tiempos de atención de
7
ÍNDICE DE TABLAS
Tabla 3.1: Adaptación de la Metodología RUP ... 36
Tabla 3.2: Técnica para el desarrollo de la investigación ... 37
Tabla 3.3: Herramientas empleadas para el desarrollo de la investigación ... 38
Tabla 3.4: Detalle de los artefactos sobre el flujo del modelado del negocio. ... 39
Tabla 3.5: Detalle de los artefactos comprendidos en flujo de requisitos ... 40
Tabla 3.6: Detalle de los artefactos sobre el flujo de análisis y diseño ... 40
Tabla 3.7: Detalle de los artefactos del flujo de construcción ... 41
Tabla 4.1: Descripción de los actores del negocio del proyecto ... 42
Tabla 4.2: Detalle sobre los trabajadores del Negocio ... 43
Tabla 4.3: Detalle CUN ... 44
Tabla 4.4: Detalle de las metas en la presente investigación ... 45
Tabla 4.5: Detalle de las entidades del Negocio ... 45
Tabla 4.6: Matriz sobre los proceso Servicio y Funcionalidades ... 53
Tabla 4.7: Matriz de los requerimientos adicionales ... 54
Tabla 4.8: CU01 Registro de incidencias ... 59
Tabla 4.9: CU02 Detalle del proceso de incidencia ... 62
Tabla 4.10: CU03 Consulta de Incidencia ... 64
Tabla 4.11: CU04 Inicio de Sección ... 66
Tabla 4.12: CU05 Catalogo de Servicio ... 68
Tabla 4.13: CU06 Registro de Usuario ... 70
Tabla 4.14: CU07 Gestionar Usuario ... 72
Tabla 4.15: CU08 Gestión Rol de Usuario ... 74
Tabla 4.16: CU09 Generar Dashboard ... 76
Tabla 4.17: CU10 General Ticket ... 78
8
RESUMEN
Las áreas de TI de las diferentes empresas del país, no cuentan con un adecuado procedimiento y/o herramienta que permita atender la gestión de incidencias, por lo cual el personal de soporte técnico no define los protocolos de atención, prioridad del caso, niveles de escalamiento como los tiempos de respuesta de las solicitudes, esto se refleja analizando las opiniones de los usuarios internos o externos.
Los servicios de TI, llegan a recuperarse, pero asimismo no se conoce las causas de los problemas por lo que se originaron, esto al no contar con procedimientos establecidos para su debida atención, los incidentes son resueltos de manera desordenada, lo cual afecta la imagen del área de TI, afectando la continuidad del negocio, ello al no realizar la documentación de las incidencias atendidas como una buena práctica del servicio. Teniendo en cuenta la necesidad de las áreas de Tecnologías de la Información de las diferentes organizaciones del país, se presenta la investigación realizada, la cual busca definir procedimientos para el control de incidentes y de problemas, con visión sobre sobre la mejora del servicio. Para el análisis de la presente investigación se basara en los procesos definidos de un sistema de gestión de servicios establecido en la norma ISO 20000, Asimismo, en la investigación realizada se analiza la problemática actual del área de soporte técnico de la Oficina General de Tecnología de Información de una entidad del gobierno dedicada a brindar seguridad jurídica sobre actos y bienes SUNARP, en la cual se implementara una herramienta que permita controlar gestión de incidencias, mostrando resultados que sean alineados a las estrategias del negocio. De igual manera los resultados se muestran mes por mes, buscando mejoras futuras.
9
ABSTRACT
The IT areas of the different companies in the country, do not have an adequate procedure and / or tool that allows to deal with the management of incidents, so the technical support staff does not define the protocols for care, case priority, levels of Scaling as the response times of the requests, this is reflected by analyzing the opinions of internal or external users.
The IT services, come to recover, but also the causes of the problems are not known for what originated, this by not having established procedures for proper attention, the incidents are resolved in a disorderly manner, which affects the image of the IT area, affecting business continuity, not to document the incidents attended as a good service practice. Taking into account the need of the Information Technology areas of the different organizations in the country, the research carried out is presented, which seeks to define procedures for the control of incidents and problems, with a view on the improvement of the service. For the analysis of the present investigation, it will be based on the defined processes of a service management system established in the ISO 20000 standard. Also, in the investigation carried out the current problem of the technical support area of the General Office of Technology of Information from a government entity dedicated to providing legal certainty about SUNARP acts and assets, in which a tool will be implemented to control incident management, showing results that are aligned to the business strategies. Similarly, the results are displayed month by month, looking for future improvements.
10
INTRODUCCIÓN
El continuo manejo sobre determinados números en volúmenes de información en relación sobre la vida cotidiana ha dado un crecimiento constante sobre las TI, lo que hace que exista una relación estrecha entre
(la información y la tecnología).
Con el uso constante sobre las TI abarca la innovación, el aprendizaje y la aceptación de diferentes tipos de herramientas, las que nos permiten poder realizar las funciones laborales de cada una de las persona de una determinada organización, de manera más sencilla y con mayor rapidez, por lo cual las organizaciones , ven como una necesidad el implantar TI que estén acorde sobre las necesidades, empero, es indispensable que se contemple en el personal que forma el equipo de la organización requiere brindar asesoría que corresponda y atención técnica para el manejo de diferente servicios servicios TI que se implementen
Las áreas de TI atienden requerimientos de fallas en hardware o requerimientos de software y otras solicitudes de servicios como realizar las altas, bajas y cambios sobre los empleados de la organización. Debemos tener en cuenta que si la labor sobre el apoyo no se planifica, dependerá mucho la capacidad de los técnicos que brindan la solución en forma rápida y con calidad sobre los problemas que son reportan por los usuarios, asimismo, no se reutiliza el total del conocimiento empleado para resolver pasadas incidencias.
Al contar con un sistema implementado que permita automatizar la administración de los incidentes del entorno informático, nos permite que la organización logre sus metas en determinado tiempo y forma establecida, empero en el uso de estos tipos de herramientas están sometidos sobre diferentes tipos de estándares existente (como ejemplo gestión de servicios ISO), lo que implicara que deba desarrollarse en razón de los necesarios conocimientos del estándar que se ha empleado, al no ser de esta forma, no se alcanzarán los objetivos primordiales: gestión de incidentes, provocando que el personal de la empresa se vea afectado en sus actividades laborales.
11 Al respecto al implementar una herramienta que permita controlar la gestión de incidencias, por niveles de escalamiento y necesidades del servicio, aplicando la metodología de desarrollo RUP, y basado en los procesos de la norma ISO 20000.
Asimismo se detalla los aspectos que describen los capítulos comprendidos en la presente investigación:
Capítulo I.-En el cual se detalla la actual situación sobre la problemática en el control de incidencias sobre el área de soporte técnico de la Oficina General de Tecnologías de la Información de la Superintendencia Nacional de los Registros Públicos, se identifican los problemas generales, definiendo objetivos, el alcance y la justificación.
Capitulo II.- En este capítulo se definen los antecedentes de investigación abarcando otras tesis sobre el tema a desarrollar, asimismo se definen las bases teóricas y marco conceptual de la presente investigación.
Capitulo III.- En este capítulo se describe la metodología con la cual se desarrollara la presente investigación, siendo la metodología de desarrollo RUP, la que se aplicara para la elaboración tecnológica, asimismo se definen las actividades, técnica, herramientas y artefactos que se requieren en la implementación.
Capitulo IV.- En este capítulo definimos lo siguiente: actores del negocio, casos de uso del negocio, los requerimientos, las matrices empleadas sobre el desarrollo en la presente investigación, el flujo de requerimiento, arquitectura del desarrollo, el diagrama de componentes, diagrama de despliegue.
Capítulo V.- En este capítulo se realiza la validación de los objetivos planteados en la presente investigación, al haber implementado la herramienta que permite controlar la gestion de incidencias en la Superintendencia Nacional de los Registros Públicos.
12
CAPÍTULO I: PLANTEAMIENTO DEL PROBLEMA
1.1. Situación Problemática
Los servicios de tecnología de la información se han incrementado constantemente, por ello es importante que los profesionales de servicios de TI combinen correctamente los conocimientos, prácticas y experiencias en atender tanto la infraestructura de tecnología de la información de una determinada organización como de las personas que lo utilizan, así mismo, con el constante avance de las TI, las organizaciones actualizan frecuentemente sus procesos, buscando satisfacer la necesidad de los clientes.
La gestión de incidencias, implica procedimientos tales como, la distribución de los casos, el registro de atención de los requerimientos, el control de los casos ingresantes, la gestión de los indicadores lo cual al no realizar el registro de manera adecuada por no contar con una herramienta que permita el control, ocasiona lo siguiente: produce las demoras e insatisfacción por parte de los usuario que requieren una solución sobre los problemas que reportan, esto al no realizar una gestión óptima sobre la distribución y definir niveles de prioridad para cada uno de los casos.
La Superintendencia Nacional de los Registros Públicos (SUNARP), es un organismo descentralizado autónomo del Sector Justicia, asimismo es ente rector del Sistema Nacional de los Registros Públicos, tiene entre sus principales funciones y atribuciones el de dictar las políticas y normas técnico - registrales de los registros públicos que integran el Sistema Nacional, planificar y organizar, normar, dirigir, coordinar y supervisar la inscripción y publicidad de actos y contratos en los Registros que conforman el Sistema. (ROF SUNARP)
BASE LEGAL: Mediante Ley N° 26366, se crea el Sistema de Nacional de Registros Públicos, y la Superintendencia Nacional de Registros Públicos – SUNARP, y por Resolución Suprema Nº 135-2002-JUS, se aprueba el Estatuto de la SUNARP. (ROF SUNARP)
La Superintendencia Nacional de los Registros Públicos (SUNARP), tiene su Sede Central que se encuentra ubicada en la Av. Primavera Nº 1878 Distrito de Santiago de Surco Lima, además cuenta con 14 Zonas Registrales que forman parte del sistema registral, las cuales se encargar de brindar seguridad jurídica sobre actos y bienes.
13 carpetas compartidas, acceso sobre los sistemas administrativos, permiso para el uso de acceso remoto, entre otros).
Las instituciones públicas, de nuestro país, presentan el constante aumento en la demanda de sistemas que brinden un soporte técnico que proporcione una consistencia operante para todos los usuarios de las distintas áreas o funciones de una determinada organización, esto al no tener implementado una herramienta para el control de reporte de incidencias técnicas, lo cual provoca pérdidas económicas.
El proceso de mejora sobre el control de incidencias por parte de una Mesa de Ayuda es habitualmente producido por circunstancias externas para esta área, como son: cambios sobre los recursos disponibles sobre la demanda (en la cual se incluye las modificaciones características sobre la tecnología) o sobre la percepción (real o de otra forma).
La Oficina General de Tecnologías de la Información de la Superintendencia Nacional de los Registros Públicos (SUNARP), a través del área de soporte técnico, ha observado que la gestión de incidencias que son atendidas por los técnicos de soporte, pero sin la debida eficiencia, esto se debe al no contar con procedimientos definidos, (los cuales requieren ser medidos con una herramienta de gestión de
servicio), a su vez esto produce gran pérdida de tiempo sobre el proceso de solución, por tanto el
proceso sobre el control de incidencias del área de soporte técnico no es eficiente , el reporte de incidencias se realiza de manera irregular (vía telefónica, correos electrónicos, entre otros), las cuales son atendidas de forma presencial o remotamente, asimismo, los requerimientos se registran de forma manual, esto produce demora en el nivel de atención, a diario se reportan un consolidado aproximado sobre 50 incidencias, de lo cual se producen un total de 1000 incidencias al mes, sobre las 50 incidencias que se reportan a diario 30 son reportes de incidencias sobre software y 20 son reportes de incidencias de hardware, pero las incidencias no son priorizadas, asimismo, no siempre son resueltas de la misma manera, por lo cual el tiempo en que se realiza la solución no siempre es el mismo. Debido a ello, se vio impactados los estándares de Calidad de Servicio, factores que conllevan a costos mayores, continuidad del negocio, pérdidas de información y el uso inadecuado de los servicios TI que cuenta la organización. Los usuarios de la SUNARP, requieren que el reporte de incidencias que se registran en el desarrollo de las funciones propias de las áreas sean resueltas en el menor tiempo posible. Siendo necesario que en el proceso de registro de incidencias se realice de manera adecuadas y permita realizar un seguimiento durante todo su ciclo de vida, a su vez, genere información que nos permita la evaluación sobre el desempeño y de la calidad del servicios que se brinda a los usuarios, debiendo contar con una debida aplicación que permita canalizar los niveles de atención de incidencias.
14 adecuado que permita obtener respuesta frente a estas situaciones, lo cual no facilita al personal que gestiona. Teniendo presente los casos y su distribución, existen un número de solicitudes que al ingresar se realizan mediante solución temporal por parte del personal o al no lograr concluir con la debida solución adecuada, lo cual aumenta el número de casos como el tiempo sobre su atención, tal como lo indica la figura 1.1.
Por lo cual, de acuerdo con la problemática descrita es de vital importancia el contar con un sistema de gestión de incidencias, el cual permita de manera rápida y eficiente la resolución de problemas tecnológicos de la organización, con el objeto de mantener la operatividad del negocio y el logro de los objetivos y metas institucionales.
Figura 1.1: Actual situación sobre la problemática de SUNARP (Fuente Propia).
1.2. Formulación del Problema
- General:
¿De qué manera la aplicación web influye en la mejora del control de incidencias en la Superintendencia Nacional de los Registros Públicos?
- Específicos:
¿De qué manera la aplicación web mejora el registro de atención en la gestión de incidencias en la Superintendencia Nacional de los Registros Públicos?
¿De qué manera la aplicación web reduce los tiempos de atención en la gestión de incidencias en la Superintendencia Nacional de los Registros Públicos?
¿De qué manera la aplicación web mejora el seguimiento de atenciones en la gestión de incidencias en la Superintendencia Nacional de los Registros Públicos?
1.3. Objetivos
15 Desarrollar una aplicación web para la mejora del control de incidencias en la
Superintendencia Nacional de los Registros Públicos. - Específicos:
Determinar la influencia de la reducción de tiempo de registro de atención mediante la aplicación web en la gestión de incidencias en la Superintendencia Nacional de los Registros Públicos.
Determinar la influencia de la reducción de tiempo de atención mediante la aplicación web en la gestión de incidencias en la Superintendencia Nacional de los Registros Públicos.
Determinar la influencia de la mejora de seguimiento de atenciones mediante la aplicación web en la gestión de incidencias en la Superintendencia Nacional de los Registros Públicos.
1.4. Justificación
Teórica
Al realizar la implementación de una Aplicación Web para el control de incidencias de la organización, mejorará las atenciones de requerimientos de servicios TI: por incidentes, asimismo, reducirá el tiempo, trabajo por horas hombre en dar soluciones temporales y se abocarán en la investigación de las causas para poder prevenirlas, asimismo tenderemos como resultados una mayor disponibilidad sobre la infraestructura tecnológica para que el negocio cumpla sus metas, como también no dejar de producir, definiendo políticas de atención, niveles de escalamiento y documentando las incidencias que se reportan como una buena práctica.
Practica
Permitirá implementar procedimientos de atención que estén orientados a brindar un soporte de calidad y solución a los incidentes, de igual manera permitirá la gestión de un conocimiento, esto durante el proceso de la prestación de los servicios TI cumpliendo con estándares de calidad, permitiendo minimizar los costos involucrados en la gestión de TI.
Social
Las razones para la realización de la presente investigación son:
Integridad sobre la información.
16 Claridad sobre la definición de procesos.
Confidencialidad y seguridad sobre la información. Facilidad para realizar la función de generar reportes. Estar disponible la información estadística.
Permita seguir indicadores sobre la gestión de calidad.
Siendo como vital importancia para la mejora de los servicios de TI, permitiendo ordenar los procedimientos y/o documentar toda actividad de atención como una buena práctica, buscando reducir los tiempos de atención.
Asimismo nos brinda la ventaja de controlar todo requerimiento que solicite cada usuario, ante alguna auditoria que se solicite posteriormente.
1.5. Alcance
El alcance de la presente investigación se realizará en la Sede Central de la Superintendencia Nacional de los Registros Públicos – SUNARP, dentro del área de soporte técnico de la Oficina General de Tecnologías de la Información, la cual brinda herramientas informáticas a las demás áreas que forman parte del sistema registral.
Se implementará una aplicación web que permita controlar los niveles incidencias, acorde con las necesidades del negocio, así mismo, se procederá con documentar los procesos de atenciones por especialista y/o técnico responsable, teniendo en cuenta la situación problemática considerada, la evolución constante de las TI y la instauración de éstas en las diversas organizaciones, de acuerdo con la Gestión de Servicios que incluya los procesos establecidos en la norma ISO 20000 que permita su optimización.
Se propone tener información actualizada y un enfoque que esté orientado a la administración de incidentes buscando reducir los tiempos de atención en los requerimientos técnicos y/o reporte de incidencias que esté base en las buenas prácticas, asimismo cumpla las características que se detallan:
Construir una base de datos cuyo fin sea registrar soluciones ante las fallas que sean reportadas. Se categorice los reportes permitiendo definir si las fallas reportadas corresponde a hardware,
software u otro requerimiento.
Permita la obtención de estadísticas, en las cuales indiquen el número de fallas y solicitudes que se registran.
17
CAPÍTULO II: MARCO TEÓRICO
2.1. Antecedentes de la investigación
En la actualidad es importante la implementación de nuevas herramientas para la solución de los problemas en la gestión de servicio, diversos autores a través de sus tesis, artículos, como publicaciones en general, han realizado la documentación de sus experiencias, de esta manera han motivado sobre aspectos de manera relevantes. Los estudios previos al tema de investigación llevaron a realizar el análisis de las siguientes fuentes y de esta manera retomar de ellos los aspectos que enriquecieron la presente investigación dando una visión amplia del trabajo a desarrollar.
Huerta, Lenin (2014), Implantación de un sistema Help Desk para el proceso de atención de
incidencias de hardware y software bajo la modalidad Open Source en la empresa Mixercon S.A.
Tesis para obtener el Título Profesional de Ingeniero de Sistemas e Informática – Facultad de
Ingeniería de Sistemas e Informática - Universidad Peruana de Integración Global - Lima Perú.
El autor sostiene que el área de sistemas de la empresa Mixercon S.A. no lleva el control de las incidencias ya que no cuentan con un sistema para la atención y soporte de recursos informáticos con eficiencia en el menor tiempo posible. Para resolver dicho problema se realizó el análisis, diseño e implementación de un sistema Help Desk para el proceso de atención de incidencias de hardware y software que permita la automatización de dichos procesos bajo la modalidad Open Source en la empresa Mixercon S.A. Se concluye que con la implementación del sistema Help Desk se brindó un mejor soporte, servicio y atención rápida a los usuarios, optimizando el tiempo de respuesta por parte del personal del área de sistemas de la empresa.
Fernández, Jorge (2014). Implantación de un sistema de gestión de incidencias. Tesis para optar el
Título Profesional de Ingeniero de Computación y Sistemas. Universidad Politécnica de Valencia,
España.
18
Rodríguez, Rody (2015). Tesis Desarrollo de un sistema web para el proceso de gestión de
incidencias en la empresa Inversiones Tobal S.A.C. – Boticas Inkasalud. Para obtener el título
profesional de Ingeniero de Sistemas – Facultad de Ciencias de Gestión – Escuela de Ingeniería de
Sistemas. Universidad Autónoma del Perú - Lima Perú.
En el proceso de Gestión de Incidencias se involucra el proceso de atención sobre las incidencias que se reportados por los colaboradores de la empresa Inversiones Tobal, tanto de su sede central y sus oficinas sucursales, esto por una mala gestión sobre el control de las Incidencias, las cuales presentan los siguientes problemas:
En la confiabilidad sobre la información que se detalla de cada incidente que se reporta al área de sistemas, asimismo, que estos registros serán útiles para la obtención de informes o reportes del control de incidencias, los cuales no deben tener ningún error durante el proceso del registro.
El tiempo tomado en brindar solución y registrar el proceso de incidencias, el cual a su vez es atendido siguiendo los procedimientos definiendo el tipo y categoría de las incidencias, utilizando el juicio experto de la persona que se encuentra encargada en brindar el soporte sobre cada una de las incidencias, lo cual no define haber brindado una correcta solución.
Para lo cual se requiere el desarrollo de una aplicación web que permita la mejora en el proceso de la gestión de incidencias de la Empresa Inversiones Tobal SAC- Boticas Inkasalud.
Lo que origino como solución la mejora en tiempos de registros y, atención de incidencias, permitiendo medir los niveles de satisfacción.
Asimismo, se concluyó que con la implementación de una aplicación web, permitió contar un mayor control sobre el proceso de gestión de las incidencias , a través de reportes que proporciona la herramienta, mejoró la comunicación con los usuarios del área de sistema y a su vez mejoró su nivel satisfacción del mismo, contribuyó a minimizar el tiempo empleado para el registro de incidencias reportadas, disminuyó el tiempo en el proceso de información, disminuyó el porcentaje de errores al momento de realizar el registro de incidencias, el porcentaje sobre la exactitud de la información ha superado al porcentaje inicial, asimismo, los niveles de satisfacción fue entre bueno y excelente, desplazando de esta manera la insatisfacción sobre los usuarios, la metodología de desarrollo RUP permitió mejorar la visión del negocio y determinar la oportunidad del mismo, y de esta manera realizar el planteamiento de posibles soluciones gracias a la elaboración de los distintos diagramas (UML) y artefactos propios de la metodología, gracias a que los reportes que muestra la herramienta permite al gestor del proceso la toma de decisiones , como también buscar soluciones sobre las incidencias que son más frecuentes,
Vargas, Jonathan & Landaburu, Michael (2016). Desarrollo de un sistema informático para la
administración, control y gestión de incidencias en el área de TI, permitiendo el ingreso de las
actividades realizadas mediante una APP desarrollada en Android. Tesis para optar el Título
19 Los autores sostienen que después de realizar encuestas a pequeñas y medianas empresas en la ciudad de Guayaquil, se pudo determinar que estas cuentan con un departamento de soporte para los usuarios mas no todas cuentan con un sistema de control de incidencias que permita agilizar los problemas presentados por los usuarios, lo que genera incomodidad y molestias que se convierten en reclamos al departamento de TI. Para resolver dicho problema se debe desarrollar un sistema informático, para el manejo y control de incidencias reportadas por los usuarios de una organización o departamento, integrándolo con una App móvil disponible en los sistemas operativos Androide e IOS que permita agilizar el proceso de solución de incidencias para que los técnicos puedan gestionar sus asignaciones e ingresar reportes desde cualquier ubicación. Se concluye que el sistema ayudó en la toma de decisiones ya que genera indicadores de cumplimiento y desempeño que facilitan el trabajo de administración al momento de medir los resultados del personal del área de TI.
Fernández, Edith (2018). Implementar una aplicación web para mejorar la gestión de
requerimientos e incidencias en el Hospital General. Tesis para optar el Título Profesional de
Ingeniero Empresarial y de Sistemas - Facultad de Ingeniería – Carrera de Ingeniería Empresarial
y de Sistemas - Universidad San Ignacio de Loyola. Lima – Perú.
Dentro de las actividades de la Oficina de Soporte Informático del Hospital es resolver las incidencias que se presenta con los equipos informáticos, estas pueden ser por falla de hardware o de software, acceso a los sistemas, etcétera, estas actividades en muchas ocasiones no son atendidas en un tiempo prudencial, así mismo se pierde datos con lo que se pueda saber el rendimiento del personal de TI, debido a que no se cuenta con un registro de solicitudes e incidencias, existe falta de control, demora de atención a las solicitudes, retrasando las actividades diarias del usuario y ocasionando insatisfacción.
Para lo cual se realizó la implementación de una aplicación web que permita mejorar la gestión de requerimientos en incidencias en el Hospital General.
De lo cual, luego de analizar las encuestas se obtuvo como resultado que mejoro la satisfacción de los usuarios, los tiempos de respuesta, costo beneficio.
Concluyendo, que después de las encuestas realizadas se pudo saber que es necesario contar con una herramienta de mesa de ayuda, el software libre utilizado fue el adecuado para resolver el problema, se logró contar con una gestión de conocimiento, para ser consultada por el usuario, la implementación de una Aplicación en la Web nos ha permitido, mejorar la gestión de servicios de requerimientos e incidencias del hospital.
2.2. Bases teóricas
2.2.1. Aplicación Web
20 motor capaz de usar alguna tecnología Web dinámica ejemplo: PHP, Java Servlets o ASP, ASP. NET, CGI, ColdFusion, embPerl, Python (programming language) o Ruby on Rails constituye la capa intermedia. Por último, una base de datos constituye la tercera y última capa. El navegador Web manda peticiones a la capa de media que ofrece servicios valiéndose de consultas y actualizaciones a la base de datos y a su vez proporciona una interfaz de usuario. (Caivano y Villoria, 2009).
2.2.2. Gestión de Incidencias
El proceso de Gestión de incidencias cubre todo tipo de incidencias, ya sean fallos, preguntas o consultas planteadas por usuarios o personal técnico. (Bon & otros 2008)
La Gestión de Incidencias tiene como objetivo resolver cualquier incidente que cause una interrupción en el servicio de la manera más rápida y eficaz posible. La Gestión de Incidencias no debe confundirse con la Gestión de Problemas, pues a diferencia de esta última, no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el servicio. Sin embargo, es obvio, que existe una fuerte interrelación entre ambas. (Osiatis 2011)
El principal objetivo del proceso de Gestión de Incidencias es volver a la situación normal lo antes posible y minimizar el impacto sobre los procesos del negocio. La Gestión de Incidencias cubre cualquier evento que interrumpa o pueda interrumpir un servicio. Bon & otros (2008),
La Gestión de Incidencias tiene en cuenta lo siguiente:
- Límites de tiempo
Se deben definir límites de tiempo para todas las fases y emplearlo como objetivos en Acuerdos de Nivel Operativo (OLA) y contratos de soporte.
- Modelos de incidencias
Un modelo de incidencia es una manera de determinar los pasos necesarios para ejecutar correctamente un proceso (en este caso, el procedimiento de ciertos tipos de incidencias), lo que significa que las incidencias estándar se gestionarán de forma correcta y en el tiempo establecido.
- Incidencias graves
Las incidencias graves requieren un procedimiento distinto, con plazos más cortos y mayor nivel de urgencia. Hay que definir qué es una incidencia grave y describir todo el sistema de prioridades para incidencias.
El proceso de Gestión de incidencias consta de los siguientes pasos:
a)Identificación
21
b) Registro
Todas las incidencias deben quedar registradas con todos sus datos, incluyendo fecha y hora. Se debe registrar, como mínimo: - Un número de referencia exclusivo. - La categoría de la incidencia. - La urgencia de la incidencia. - La prioridad de la incidencia. - El nombre/identificador de la persona y/o grupo que registró la incidencia. - Una descripción de síntomas. - Las actividades realizadas para resolver la incidencia.
c) Clasificación
Se deben utilizar los códigos apropiados de clasificación de incidencias para documentar los distintos tipos de llamadas. Esto tendrá importancia más adelante, cuando se analicen los tipos y frecuencias de incidencias para identificar tendencias que se puedan usar en la Gestión de Problemas, Gestión de Proveedores y otras actividades de la Gestión de Servicios de TI.
d) Priorización: es la asignación del código de prioridad correcto. Los agentes y herramientas de soporte utilizan este código para determinar cómo deben tratar la incidencia. Por lo general, la prioridad de una incidencia se puede determinar a partir de:
- Impacto
Determina la importancia de la incidencia dependiendo de cómo ésta afecta a los procesos de negocio y/o del número de usuarios afectados.
– Urgencia
Es la dependencia del máximo tiempo en que demora que el usuario acepte la solución de las incidencias y/o nivel de servicio que se encuentra acorde con los SLA.
En la Figura 2.1. Podemos observar el diagrama de prioridades, de acuerdo con la urgencia e impacto de las incidencias reportadas.
22
2.2.3. Metodología Rational Unified Process RUP
La metodología Rational Unified Process RUP (Proceso Unificado Racional) junto con el Lenguaje Unificado de Modelado (Unified Modeling Language, UML), es un marco de procesos de ingeniería de software que proporciona las mejores prácticas orientadas para el desarrollo exitoso de software y una disciplina para asignar tareas y responsabilidades dentro de una organización de desarrollo, teniendo como objetivo garantizar la producción de software de alta calidad, que satisfaga las necesidades de sus usuarios dentro del tiempo y presupuesto adecuados. (Edwards, Fernández, Mancin & Carroll, 2007)
a) Características de RUP
Regido a través de casos de uso
Los casos de uso es un modo de captura de requerimientos que fuerza con pensar en términos de importancia para el usuario y no sólo en términos de funciones. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor añadido. Los Casos de Uso representan los requisitos funcionales del sistema. En RUP los Casos de Uso no son sólo una herramienta para especificar los requisitos del sistema. También guían su diseño, implementación y prueba. Los Casos de Uso constituyen un elemento integrador y una guía del trabajo. (Ravindranath, 2006)
Proceso centrado en la arquitectura
Definimos que es la organización como también su estructura en sus partes que son de manera más relevantes, permitiendo lo que permite tener una visión (común) entre todos los involucrados (los usuarios y los desarrolladores) con un panorama claro sobre el sistema completo, lo que es necesario para el control del desarrollo. (Pressman, 2010)
23 Proceso iterativo e incremental
Contiene una iteración de secuencias. A cada una de las iteraciones se aborda una parte en razón de la total funcionalidad, pasando por cada uno de los relevantes flujos de trabajo además refinando la arquitectura. En cada iteración se analizara el momento en que termina. Podemos determinar si nuevos requisitos han aparecido como también si cambiaron los existentes, lo que afectara a las siguientes iteraciones. Mientras la planificación sobre los detalles en la iteración siguiente, igualmente el equipo procederá con examina la afectación de riesgos que aún quedan en curso al trabajo. En la totalidad de la retroalimentación de iteraciones pasadas se permitirá el reajuste de los objetivos para las iteraciones siguientes. Esta dinámica se continura hasta que por completo haya finalizado con la actual versión del producto. (Bruegge & Dutoit, 2002)
Los equilibrios correctos entre los Casos de Uso y la arquitectura son similares al equilibrio de la forma y la función en el desarrollo del producto, lo cual se consigue con el tiempo. Para ello, la estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo se divide en partes más pequeñas o mini proyectos. Teniendo el equilibrio entre el Caso de Uso y arquitectura así se vaya logrando durante cada mini proyecto, durante todo el proceso de desarrollo. Cada mini proyecto se puede ver como una iteración del cual se obtiene un incremento que produce un crecimiento en el producto. (Pressman, 2010)
b) Fases de RUP
En el RUP se repite a lo largo de los ciclos que constituyen la vida de un producto. Cada ciclo concluye con una generación del producto para los clientes. Cada ciclo consta de cuatro fases: Inicio, Elaboración, Construcción y Transición. Cada fase se subdivide a la vez en iteraciones, el número de iteraciones en cada fase es variable.
24
Figura 2.2: Arquitectura General de RUP. (Fuente: Kruchten, 2013)
Inicio
Refieren que en esta fase se define el modelo del negocio y el alcance del proyecto, se identifican todos los actores y Casos de Uso, y se diseñan los Casos de Uso más esenciales (aproximadamente el 20% del modelo completo). Se desarrolla, un plan de negocio para determinar que recursos deben ser asignados al proyecto. Edwards, Fernández, Mancin, Carroll. (2007).
Se definieron los siguientes objetivos para esta fase: Definir ámbito para el proyecto con sus límites.
Hallar casos de uso que sean críticos para el sistema, los marcos básicos que permitan definir su funcionalidad.
Nos muestre por lo menos una arquitectura que sea definida como candidata para principales escenarios.
Nos permita la estimación sobre el costo de recursos como el tiempo requerido para todo el proyecto.
Nos permita la estimación de riesgos, la incertidumbre en las fuentes. Se definieron los siguientes resultados para esta fase:
Documentar la visión: tener una general visión en requerimientos del proyecto, (características que sean clave y/o restricciones de carácter principal).
El inicial modelo en los casos de uso (10-20% al haber sido completado). Tener catalogo en el inicio: Término clave en el dominio.
caso del negocio.
Tener la lista de riesgos con su correspondiente contingencia.
25 Exploratorios prototipos que permitan probar los conceptos sobre la arquitectura que sea
candidata.
Cuando se concluya con la fase de inicio, debemos comprobar los criterios de la evaluación, con el objeto de lograr continuar
Quienes se encuentren interesados sobre el proyecto coincidirán con la definición sobre el ámbito en el sistema una estimación en agenda.
Tener una comprensión sobre los requisitos, siendo la fidelidad evidente sobre los principales casos de uso.
Para estimar el tiempo, los costos y el riesgo siempre es creíble.
Comprender de manera total cualquier prototipo sobre la arquitectura en que se desarrolló. Hasta el momento los gastos están asemejados con lo planeado
Además de no cumplir estos criterios tenemos que proceder con plantear abandonarlo o realizar el replanteamiento.
Elaboración
Definen como propósito para esta fase en realizar el análisis sobre el dominio de la problemática, estableciendo cimientos en la arquitectura, desarrollando un plan en el proyecto, también eliminando los riesgos mayores.
Además para esta fase se realizara construcción de un prototipo para la arquitectura, la cual debe realizar la evolución sobre sucesivas iteraciones hasta transformarse en el sistema final. El prototipo deberá contener los críticos casos de uso que han sido identificados al inicio de la fase. Además se debe demostrar que los riesgos más graves han sido evitados. Edwards, Fernández, Mancin, Carroll. (2007).
En esta fase se han definido los siguientes objetivos:
Definición, validación y asentamiento de la arquitectura. Visión Completada.
Construcción en la fase de construcción de un plan fiable. El cual en sucesivas interacciones podrá evolucionar, asimismo, deberá incluir si procede los costos.
Se demostrara que la arquitectura propuesta soportara con visión un costo de manera razonable sobre un tiempo determinado.
Cuando se concluya esta fase se tendrá los siguientes resultados:
El modelo de los casos de uso estará de manera completa por lo menos se encontrara en el 80%: el total de casos, actores que han sido identificados, los casos en su mayoría estarán desarrollados
Los requisitos adicionales que a su vez realizan la captura de requisitos no funcionales como un requisito cualquiera que no se encuentre asociado sobre algún específico caso de uso.
26 En la arquitectura estar ejecutable un prototipo.
Haber revisado los casos del negocio y/o lista de riesgos Para el proyecto tener el desarrollo de un plan.
Haber desarrollado un caso que se encuentre actualizado especificando el proceso que se v seguirá.
Contar con un formulario para usuarios de manera preliminar (opcional).
Para la fase tratara de abarca el total del proyecto profundizando solo en puntos críticos sobre la arquitectura o también los importantes riesgos, además, se realiza la actualización de los productos indicados en la fase de inicio.
Los criterios de evaluación de esta fase son los siguientes: Tener una visión estable del proyecto.
Tener estable la arquitectura.
Además mediante la ejecución de prototipos se han demostrado que los elementos de riesgo principales han sido resueltos y/o abordados.
Para esta fase el plan definido es preciso y detallado, son creíbles las estimaciones planteadas.
Coinciden los interesados que será alcanzada la visión actual, si seguimos los actuales planes en un contexto sobre la actual arquitectura.
Son aceptables los gastos, cuando son comparados con los previstos.
Al no superar los criterios de evaluación, tal vez sea necesario abandonar o replantear el proyecto.
Construcción
Se menciona como principal finalidad en esta fase que es el alcance de la capacidad operacional en el producto de manera incremental mediante interacciones sucesivas. Todos los componentes, las características y los requisitos en esta fase es necesario que sean implementados, probados e integrados de manera total, con el fin de obtener una aceptable versión del producto. (Edwards, Fernández, Mancin, Carroll. 2007),
La influencia de acuerdo con objetivos concretos es la siguiente:
Permite minimizar costos en el desarrollo a través de recursos optimizados, lo que evita el tener que proceder con rehacer algún trabajo como también desecharlo.
Permite lograr un nivel de calidad adecuado, de manera rápida en razón del aspecto práctico.
Permite tener versiones funcionales (alfa, beta, como otras versiones en prueba) de manera rápida en razón del aspecto práctico.
En la fase de construcción los resultados deben ser los siguientes:
27 Arquitectura integrada (mínimamente actualizada y/o mantenida)
Presentación de riesgos mitigados
Fase de la transición en el plan del proyecto.
Manual de usuario inicial (se encuentre suficientemente detallado) Prototipo operacional beta
Se encuentre actualizado los casos del negocio En esta fase se tiene los siguientes criterios de evaluación:
De manera estable y madura se debe encontrar el producto como para ser transmitido sobre la comunidad de los usuarios con el fin de ser probado.
Los usuarios que son expertos se encuentran listos para su transición sobre la comunidad de los usuarios.
Es aceptable los actuales gastos con los planeados gastos.
Transición
Se refiere que en esta fase la finalidad es proceder con colocar el producto en las manos de los usuarios finales, siendo necesario el desarrollo de actualizadas versiones del producto, manteniendo la documentación completa, capacitando al usuario en el manejo del producto, siendo el aspecto general las tareas que se encuentran relacionadas sobre el ajuste, la configuración, la instalación y la facilidad del uso del producto. (Edwards, Fernández, Mancin, Carroll. 2007).
En esta fase podemos incluir las siguientes cosas:
Realizar las prueba de versión Beta para realizar la validación del nuevo sistema frente con las expectativas de usuarios
El paralelo funcionamiento sobre sistemas que estén legados los cuales están siendo sustituidos por el proyecto.
Realice la conversión sobre bases de datos de manera operacional.
El entrenamiento sobre usuarios como de técnicos encargados del mantenimiento. El traspaso de los productos sobre equipos de marketing, venta y distribución. En la fase de transición los resultados son los siguientes:
Prototipos Operacionales
Documentación de carácter Legal. Completos casos del negocio.
Línea de la Base de los productos completa y estando corregida incluyendo el total sobre los modelos del sistema
La descripción sobre arquitectura de manera completa y corregida
Cada interacción de la fase irán regirán de manera normal con conseguir una versión nueva. Los siguientes criterios de evaluación se consideran en esta fase:
28 Se aceptara los actuales gastos con planificados gastos.
2.2.4. Arquitectura 3 capas
Es una de las más utilizadas para el desarrollo de sitios web. Esta arquitectura divide la creación de una aplicación en tres niveles: la capa de presentación, la capa de lógica del negocio, la capa de persistencia (datos almacenados) (Fowler. 2002).
Está basado en el concepto de que todos los niveles de una aplicación son la creación de componentes que se proporcionan servicios entre sí o a otros niveles adyacentes. El modelo de 3 capas está destinado a ayudar a construir componentes de software a partir de la división de los niveles lógicos. De esta manera, una de las de las decisiones de diseño que debemos tomar es que parte de la lógica de la aplicación se va a encapsular en cada uno de los componentes, así como como que componentes se va a encapsular en cada nivel. Un nivel puede estar conformado por varios componentes, por tanto, puede suplir varios servicios. La figura 2.3 muestra un esquema de una arquitectura de 03 capas. Los elementos que contienen cada una de las capas corresponden a componentes a componentes o funcionalidades manejados en dicha capa. (López & otros 2014).
Figura 2.3: Arquitectura de 03 capas en la aplicación web desde el punto de vista
funcional [Fuente: López & otros 2014]
A continuación realizaremos una breve explicación de cada una de las capas de esta arquitectura. Capa de presentación
Esta es la capa más cercana al usuario presentándole una interfaz gráfica del recurso solicitado y capturando la intersección entre el sistema y el usuario. A su vez es también se le conoce como capa de la interfaz gráfica. Esta capa se comunica con la capa de negocio y suele estar dividida entre los niveles del cliente y el servidor. (López & otros 2014).
29 ser visualizada correctamente por el usuario. En el caso de sistemas web, esta capa debe garantizar que la información sea accesible a través de recursos web claros y amigables de tal manera que dicha información sea accesible a través de un navegador web (IExplore, Chrone, Mozilla, Safari, etc.) en cualquier dispositivo de acceso (portátil, Tablet, Smartphone, etc.). (López & otros 2014). Algunas de las tareas específicas de la capa de presentación son: proveer las páginas web, garantizar que dichas páginas puedan ser visualizadas tanto en un ordenador como un dispositivo Smartphone, gestionar que todos los enlaces del sitio web sean válidos, garantizar que las páginas web tengan siempre la misma información actualizadas, etc. (López & otros 2014).
Capa de negocio
También denominada capa de lógica, capa de aplicación, capa media o capa de lógica del negocio. Se gestiona en esta capa las funcionalidades de la aplicación web y/o sistema (“lógica o reglas del negocio”). Asiduamente en esta capa recibe peticiones de los usuarios desde ella se realiza él envió de las apropiadas respuestas a razón de realizar el procesamiento de la información que es proporcionada por los clientes. Se denomina capa del negocio porque es aquí donde se establecen todas las reglas que deben cumplirse para que las funciones de la aplicación web sean ejecutadas correctamente. La implementación de dichas reglas se hace a través de desarrollos de software los cuales se ejecutan cuando llega la petición de un usuario. (López & otros 2014).
Al igual como en la capa de presentación, la programación de la lógica del negocio puede desarrollarse tanto en entorno cliente como también sobre el entorno servidor. Algunas de las tareas concretas de los componentes de esta capa son: coordinar la aplicación web, procesar los comandos, realizar la toma de decisiones, realizar los cálculos respectivos. Además esta capa es la encargada de mover y procesar los datos de sus dos capas adyacentes. Típicamente, la capa de negocio está conformada por uno o más módulos que se ejecutan en un equipo de cómputo denominado servidor de aplicaciones. (López & otros 2014).
Capa de persistencia
Esta capa es la encargada del acceso de datos. Aquí se encuentra toda la codificación necesaria tanto para el acceso a los datos como para el manejo y almacenamiento de los mismos. Normalmente está conformado por un conjunto de componentes que se encargan del acceso a los datos (p. ej. clases de conexión a la base de datos) los cuales se ejecutan en los servidores de aplicación y por algún gestor de la base de datos (SGBD) que se ejecutan en el nivel de datos (servidores de base de datos) los cuales se encargan del administración de procesos de los datos, ejecutando el almacenamiento de solicitudes, modificación o información recuperada dadas desde la capa de negocio. Los SGBD. (López & otros 2014).
30 y capas. Esto no es necesariamente así. Como hemos explicado, mucho de los componentes de la capa de presentación, por ejemplo, pueden estar distribuidos a niveles de cliente y otros a niveles de servidor. Asimismo, las utilidades del sistema, pueden estar distribuidos en varios servidores, es decir, las funcionalidades de la capa de negocio y por ende cada servidor construirá un nivel diferente. (López & otros 2014).
La Figura 2.4, muestra una comparación entre un modelo físico tradicional organizado en tres niveles y un modelo lógico de tres capas. En este caso el nivel 1 del modelo físico se encargara de algunas funcionalidades de navegación y presentación a través del browser. El nivel dos, corresponde al servidor de aplicaciones contiene todas las funcionalidades de la capa de negocio y algunas de la capa de presentación, como por ejemplo validación y control de conexiones. Por último el nivel 3 que contiene un servidor de base de datos, contiene una base de datos que se encarga de las funciones de servicios de datos, almacenamiento y seguridad descritos para esta capa.
Figura 2.4: Detalle de la arquitectura de las 3 capas en una Aplicación Web [Fuente: López &
otros 2014]
2.2.5. Modelo Vista Controlador (MVC)
Definido como patrón de la arquitectura del software que separa lo datos y lógica del negocio sobre alguna aplicación de interfaz de los usuarios y el encargado módulo de realizar la gestión de eventos y comunicaciones. Por ello el MVC plantea construcción de 03 distintos componentes los cuales son modelos, vistas y controladores, entonces decimos que por un lado definimos componentes para la información representada, y por el otro lado las interacciones de usuarios. Este patrón de diseños se basara en ideas sobre códigos reutilizados y separación de los conceptos, característica que buscara la facilitación de las tareas del desarrollo de las aplicaciones además de su mantenimiento posterior (Eslava. 2013).
31 MVC se introdujo en Smalltalk-76 por Trygve Reenskaug durante su la visita en Xerox Parc por los años de la década de los 70 y, posteriormente en la década de los años 80, Jim Althoff con otros realizaron la implementación de una versión MVC sobre la biblioteca de clases Smalltalk-80. Solo más tarde, en 1988, MVC fue expresado como concepto general dentro de un artículo. (Eslava. 2013).
Como primera definición del MVC se definía el controlador como “el modulo que se ocupa de la entrada” (similar forma como “se ocupa de la salida”). Esta descripción en las aplicaciones modernas no tendrá cabida en que las combinaciones de vistas son asumidas por la funcionalidad y además de un moderno framework para el desarrollo. En las modernas aplicaciones de la década del año 2000 su controlador, son módulos o alguna sección de código intermedio, que actua como intermediario de comunicación entre los modelos y las vistas, y procederá con unificar su validación (utilizando directas llamadas como el “observes” lo que permitirá desacoplar los modelos de las vistas en activos modelos). (Eslava. 2013).
De manera genérica, los componentes de MVC se podrían definir de la siguiente manera: El modelo
Es la representación de la información con la cual el sistema opera, por lo tanto gestiona todos los accesos a dicha información, tanto consultas como actualizaciones, implementando también los privilegios de accesos que se hayan descrito en las especificaciones de la aplicación (lógica del negocio). Envía a la vista aquella parte de la información que en cada momento se le solicita para que sea mostrada (típicamente a un usuario). Las peticiones de acceso o manipulación de información llegan al modelo a través del controlador. (Eslava. 2013).
El controlador
Responde a eventos (usualmente acciones del usuario) e invoca peticiones al modelo cuando se hace alguna solicitud sobre la información (por ejemplo, editar un documento o un registro de base de datos). También pueden enviar comandos a su vista asociada si se solicita un cambio en la forma en que se presenta de modelo (por ejemplo, desplazamiento o scroll por un documento o por diferentes registros de una base de datos), por tanto se podría decir que el controlador hace de intermedio entre la vista y el modelo. (Eslava. 2013).
La vista
Presenta el modelo (información y lógica del negocio) en un formato adecuado para interactuar (usualmente la interfaz de usuario) por tanto requiere de dicho modelo la información que debe representar como salida. (Eslava. 2013).
2.2.6. Norma ISO 20000
32 (ISO 20000. Es una guía completa sobre la aplicación para la gestión de servicios de las TI 2009). La principal tarea en relación a comités técnicos es la preparación de normas de carácter internacionales. La ISO/ 20000 en el mundo es primera norma de carácter específico que va enfocada sobre gestión de los servicios de las TI, basándose en la ITIL consistiendo sobre varios documentos (ISO 20000. Es la guía de carácter completo de la aplicación para la gestión de servicios de TI, 2009):
1. ISO 20000-1: 2011 Los requisitos sobre sistemas de la gestión de los servicios.
2. ISO/20000-2: 2012 La guía de la implementación sobre sistemas de la gestión de los servicios. 3. ISO 20000-3:2009 – La guía sobre definición de alcances y las aplicabilidades (informes técnicos)
4. ISO 20000-4:2010 – El modelo de los procesos de las referencias (informes técnicos) 5. ISO 20000-5:2010 – Los ejemplos de las implementaciones (informes técnicos)
En la presente investigación de la tesis únicamente tomamos en cuenta los primeros dos documentos.
La ISO 20000-1 incluye diseños, transiciones, provisiones, como mejora sobre servicios que permiten cumplir con requisitos de los servicios, además de aportar en valor tanto para los clientes como igual para proveedores de los servicios (ISO2000-1 2011: 7-10). Esta la parte sobre la norma ISO 20000 requiriendo que los proveedores de los servicios tengan enfoque que esté basado sobre integrados procesos cuando se planifica, se establezca, se implemente, se opere, se controle, se revise, se mantenga y mejore el sistema de la gestión de los servicios (ISO/ 2000-1 2011: 7-10). Para la presente norma se requiere la aplicación de la conocida metodología como “Planificar-Hacer-Verificar-Actuar” (PDCA, del inglés Plan-Do-Check-Act) En todas partes de los sistemas de gestión de los servicios (SGS) además de servicios. La metodología PDCA, tal como es aplicada en la presente parte sobre la 20000-1, se podrá describir de manera breve como sigue (ISO/ 20000. guía de carácter completo de la aplicación sobre gestión de servicios de TI, 2009: 38):
- Planificación: nos permita el establecimiento, documentación y/o el acorde al SGS. El SGS incluirá, las políticas, los objetivos, los planes y los procesos a fin de cumplir los requisitos de servicios.
- Hacer: implementación y operación del SGS paras los diseños, transiciones, provisiones y mejoras sobre servicios.
33 La figura 2.5 ilustra cómo se puede aplicar la metodología PDCA al SGS, incluidos los procesos de gestión del servicio. Cada elemento de la metodología PDCA es una parte vital para la implementación exitosa de un SGS (ISO/IEC 20000., 2009). El proceso de mejora utilizado en esta parte de la Norma ISO/IEC 20000 se basa en la metodología PDCA (ISO/IEC 2000-1 2011: 7-10).
Figura 2.5: Metodología PDCA aplicada a la gestión del servicio adaptado de 20000, I. I.
(2011). "Tecnologías de la Información - Gestión del Servicio." 1: 38
La ISO 20000-2, En referencia a tratarse de código de las buenas prácticas, tiene forma de guía y7o recomendaciones (ISO 20000-2:2012). La parte de la norma ISO 20000 detalla a mejores prácticas sobre procesos de la gestión de los servicios dentro de los alcances de la norma ISO 20000-1 (ISO 20000-1:2011). Las provisiones de los servicio adquieren una mayor importancia en la medida en que a cada uno de los clientes requieran los servicios sobre cada una de las veces más avanzadas (a un mismo costo) para la satisfacción de necesidades en sus negocios (AENOR, 2009). En este hecho se reconoce a su vez que en los servicios y en la gestión de estos comprendidos servicios son muy esenciales para la ayuda en organizaciones a fin de generar sus ingresos y ser más rentables (AENOR, 2009). La norma ISO 20000-1 nos especifica una serie de los procesos de la gestión de los servicios que están relacionados como se muestra en la figura 2.6.
Figura 2.6: Procesos de Gestión de Servicios Imagen recuperada de Certificación, A. E. d. N. y.
(2007). Une-iso-iec 20000-2: Tecnología de la Información, Gestión del servicio. Código de
34
2.3. Marco conceptual
Eficiencia. Es el conjunto de atributos que se encuentran relacionados entre nivel de desempeño del software y la cantidad de recursos necesitados bajo las condiciones que están establecidas, buscando atender las necesidades de los usuarios (ISO/IEC 9126-1:2001, pag.27).
Confiabilidad. Conjunto de atributos relacionados con la capacidad del software de mantener su nivel de rendimiento bajo condiciones establecidas durante un periodo establecido, siempre brindado seguridad al usuario (ISO/IEC 9126-1:2001, pag.13).
Funcionalidad. Es la relación de los atributos sobre la existencia de los conjuntos de funciones y sus propiedades específicas. Las funciones son aquellas que permiten satisfacer las necesidades implícitas o necesidades explícitas en todo sistema de información (ISO/IEC 9126-1:2001, pag.5). Cliente. Solicita el servicio al técnico, el técnico debe levantar un reporte del trabajo que va realizar. El técnico deberá llevar la herramienta necesaria para trabajar, verifica el equipo que prenda (Si esto no es así, informar al cliente y esperar para proceder a mantenimiento). Terminado el mantenimiento. El técnico entregara el equipo al cliente terminado todo, el técnico cerrara reporte y lo archivara. (Luc, 2016, pag.28).
Gestor de Ayuda. Es el operador del negocio que se encarga de atender las consultas y requerimientos de los usuarios.
Técnico. Es el encargado de soporte informático: son aquellos trabajadores que, contando con la obtención de grado de Bachiller, o estando en formación profesional, como también de algún otro grado de estudio superior con el equivalente, se les contrata con el fin de realizar, teniendo en cuenta el nivel académico, las propias funciones de las actividades informáticas, acorde con las Tecnologías de la Información. (Desongles & otros, 2006, pag.8).
Incidencia. En la administración del control de incidencias se debe permitir al administrador realizar el seguimiento de cada una de las acciones tomadas para realizar la solución de los problemas y de esta manera conocer el estado histórico y actual de las incidencia reportadas. Para cada incidencia debe mantenerse un registro de toda la información relacionada a las mismas pruebas de diagnóstico, como fue solucionado el problema. (Valdivia, 2015, pag.1).
Nivel de Incidencia.- Es la clasificación del grado de complejidad de los problemas que se presentan, generalmente los del nivel 1 lo puede ser resueltos por el cliente, los del nivel 2 es resuelto por el técnico encargado.
35
CAPÍTULO III: MÉTODOLOGÍA DE LA INVESTIGACIÓN
Hoy en día tener un centro de servicios de TI en las organizaciones que soporte tanto usuarios internos como clientes es factor determinante en la generación de valor.
Es importante destacar el esfuerzo que hacen muchas organizaciones al querer brindar servicios bajo el enfoque de calidad a través de las Mesas de Ayuda (helpdesk) para resolver cualquier problema que pueda surgir con las tecnologías de información que necesitan para realizar sus labores diarias. En la implementación es importante considerar la herramienta eficaz que integre las solicitudes de servicio y los activos de TI para ayudar a manejar una organización de manera efectiva, y así resolver las solicitudes de servicio eficientemente.
3.1.Método
De acuerdo con la investigación planteada en el presente proyecto, este se desarrollará con una Metodología de Desarrollo (RUP), de acuerdo con los lineamientos de la norma ISO 20000.
Adaptación de la metodología RUP
La metodología RUP contiene fases y disciplinas donde en se encuentran artefactos según sea el caso, por ello se realizó la adaptación de la metodología RUP, determinando los artefactos que se utilizan para la elaboración de la aplicación, tal como se muestra en la tabla Nº 1
ADAPTACION DE LA METODOLOGIA
Actividad Artefactos
Modelado sobre los casos de uso del negocio
Modelo de casos de uso del negocio o Actor externo
o Meta
o Caso de uso del negocio Modelo de Análisis del negocio
o Trabajador del negocio o Entidad del negocio o Realizaciones
o Diagrama de actividades
Matriz
Matriz de procesos y requerimientos. Matriz de requerimientos adicionales Matriz de requerimientos no funcionales.
Especificación de requisitos
Catálogo de los requisitos funcionales y catálogo de requisitos no funcionales Lista de los actores
36 Modelado de los casos de uso del sistema Especificación de los casos de uso del sistema
Diagrama de casos de uso del sistema
Modelado de datos Modelo de datos lógico y físico
Diseño de interfaces Interfaces web
Diseño de arquitectura Diagrama de componentes Diagrama de despliegue Arquitectura
Pruebas Pruebas funcionales (Caja negra)
Tabla Nº 3.1: Adaptación de la metodología RUP (Fuente Propia)
3.2.Técnicas
En la siguiente Tabla Nº 02 se muestra las técnicas que se empleara, de acuerdo con la metodología de desarrollo RUP, teniendo en cuenta las actividades que se desarrollara:
TECNICAS
Actividad Artefactos Técnica
Modelado sobre los casos de uso del negocio
Modelo sobre los CUN o Actor externo
o Meta
o CUN
Entrevista a personal de soporte técnico OGTI – SUNARP. Análisis de procedimientos.
Modelo sobre el análisis del negocio
o Trabajadores del negocio o Entidad del negocio o Realizaciones
o Diagrama de actividades
Entrevista a personal de soporte técnico de la OGTI – SUNARP.
Análisis de procedimientos.
Matriz
Matriz de procesos y requerimientos.
Matriz de requerimientos adicionales
Matriz de requerimientos no funcionales.
Entrevista a personal de soporte técnico de la OGTI – SUNARP.
Análisis de procedimientos.
Especificación de requisitos
Catálogo de requisitos funcionales y no funcionales Lista de actores
Lista de casos de uso
Entrevista a personal de soporte técnico de la OGTI – SUNARP.
