Proyecto Final de Carrera. Ing.Informática. HELP-DESK

34,563 views
34,305 views

Published on

Proyecto Final de Carrera.
Ing.Informática
HelpDesk

Published in: Education
4 Comments
19 Likes
Statistics
Notes
No Downloads
Views
Total views
34,563
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2,634
Comments
4
Likes
19
Embeds 0
No embeds

No notes for slide

Proyecto Final de Carrera. Ing.Informática. HELP-DESK

  1. 1. Universidad CEU – Cardenal Herrera ESCUELA SUPERIOR DE ENSEÑANZAS TÉCNICAS INGENIERÍA INFORMÁTICA PROYECTO FINAL DE CARRERA Desarrollo e implementación de un centro de Asistencia HELP-DESK siguiendo la Metodología ITIL Autor: Fernando Leandro Baladrón Directores de proyecto: Dr. D. Juan Pardo Albiach D. José Luis Roig Azpitarte
  2. 2. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo1. Índice de contenidos 20/03/07 ÍNDICE DE CONTENIDOS CAPÍTULO 1 1.1 INTRODUCCIÓN 3 1.2 OBJETIVOS 5 CAPÍTULO 2 2.1 FASES DEL PROYECTO 7 2.2 DIAGRAMA DE GANTT 13 CAPITULO 3 3.1 ESTADO DEL ARTE 15 3.1.1 INTRODUCCIÓN A ITIL 15 3.1.2 VENTAJAS DE ITIL PARA EL CLIENTE/USUARIO 16 3.1.3 VENTAJAS DE ITIL PARA LA ORGANIZACIÓN 16 3.1.4 PROBLEMAS POTENCIALES DE ITIL 17 3.1.5 PERSPECTIVA GENERAL DE LA GESTIÓN DEL SERVICIO 17 SEGÚN ITIL 3.1.5.1 SERVICE DESK. 17 3.1.5.2 MANEJO DE INCIDENTES. 18 3.1.5.3 MANEJO DE PROBLEMAS 22 3.1.6 EL FUTURO DE LOS HELP DESKS 26 3.2 COMPARATIVA CENTRO DE ASISTENCIA 28 3.2.1 APLICACIÓN GIGLOBAL SUPPORT 26 3.2.2 APLICACIÓN DEMO HELPDESK 27 3.2.3 APLICACIÓN PRO DE AQCENTUS CORPORATION INC. 28 3.2.4 APLICACIÓN CENTRO DE ASISTENCIA NAVIGATOR 29 3.2.5 APLICACIÓN CENTRO DE ASISTENCIA ISOLSOFT 30 3.2.6 APLICACIÓN CENTRO DE ASISTENCIA PERL DESK 33 3.2.7 APLICACIÓN CENTRO DE ASISTENCIA CRM DESK 35 3.2.8 APLICACIÓN CENTRO DE ASISTENCIA JITBIT HELPDESK 36 3.2.9 APLICACIÓN CENTRO DE ASISTENCIA SERVICE DESK 37 3.2.10 CUADRO COMPARATIVO 40 CAPITULO 4 4.1. BASE DE DATOS HELP-DESK 43 4.2. NIVEL DEL DISEÑO DE LA BASE DE DATOS 43 4.2.1. ANÁLISIS DE REQUERIMIENTOS 43 4.2.2. DISEÑO CONCEPTUAL 45 4.2.3. DISEÑO LÓGICO 46 4.2.4 .DIAGRAMA UML 52 4.2. PROCEDIMIENTOS ALMACENADOS CON SQL SERVER 54 4.2.1. PROCEDIMIENTOS IMPLEMENTADOS 54 4.2.2. CONEXIONES EN SQL SERVER. 58
  3. 3. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo1. Índice de contenidos 20/03/07 5. NIVEL DEL DISEÑO WEB 59 5.1. DISEÑO DE NAVEGACIÓN 59 5.2. HOJA DE ESTILOS CSS 66 5.3. USABILIDAD 69 6. NIVEL DEL DISEÑO DE LA INTERFACE 74 6.1. CLASES 74 6.2. PROGRAMACIÓN ASP .NET 81 6.2.1. DISTRIBUCIÓN DE LAS CARPETAS 83 6.2.2. CONTROLES DE USUARIO 87 6.2.3. INSERCIÓN DE ITEMS 88 6.2.4. SUBIR ARCHIVOS 88 6.2.5. VISUALIZACIÓN DE LOS DATOS 89 6.2.6. IDENTIFICACIÓN DE LOS USUARIOS 90 6.2.7. OBTENER ITEMS 91 6.2.8. TEMAS ADICIONALES 92 7. CONCLUSIONES Y TRABAJO FUTURO 95 7.1. CONCLUSIONES FINALES 95 7.2. TRABAJO FUTURO 98 BIBLIOGRAFIA 100 ANEXOS 1. ESPECIFICACIÓN DE REQUISITOS DE ACUERDO NORMA IEEE 2. ITIL STUDY GUIDE 3. HOJA DE ESTILOS (CSS)
  4. 4. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo1. Índice de contenidos 20/03/07 ÍNDICE DE FIGURAS fig 2.1 Diagrama de Gantt del proyecto 14 fig 3.1.1 Ciclo vital del incidente 21 fig 3.1.2 Descripción gestión de problemas 23 fig 3.2.1 Logo Aplicación Giglobal Support 26 fig 3.2.2 Aplicación Demo HelpDesk 28 fig 3.2.3 Aplicación Help Desk Pro de Aqcentus Corporation Inc 29 fig 3.2.4 Aplicación Centro de Asistencia Navigator 29 fig 3.2.5 Aplicación Centro de Asistencia Isolsolf 30 fig 3.2.6 Listado de incidencias 31 fig 3.2.7 Pantalla de búsqueda sobre la base de conocimiento 31 fig 3.2.8 Listado de incidencias 32 fig 3.2.9 Formulario de datos de un item/ticket 32 fig 3.2.10 Aplicación centro de asistencia Perl Desk 33 fig 3.2.11 Formulario de introducción item / ticket 34 fig 3.2.12 Listado de incidencias 34 fig 3.2.13 Aplicación centro de asistencia CRM Desk 35 fig 3.2.14 Búsqueda en la base de conocimientos 36 fig 3.2.15 Aplicación centro de asistencia JitBit HelpDesk 36 fig 3.2.16 Aplicación centro de asistencia Service Desk 37 fig 3.2.17 Posible listados con la aplicación 38 fig 3.2.18 Búsqueda sobre la base de conocimiento 39 fig 3.2.19 Listado de informes 40 fig 4.1 Diseño conceptual utilizando el modelo Entidad - Relación 46 fig 4.2 Diagrama generado con el SGBD SQL Server 50 fig 4.3 Tablas generadas con el SGBD SQL Server 51 fig 4.4 Diagrama UML Help Desk CEU 53 fig 5.1 Movimiento del ojo al visualizar un página 59 fig 5.2 Boceto del diseño de la organización de la página inicial perfil visitante 60 fig 5.3 Diseño de la organización de la página principal perfil visitante 62 fig 5.4 Captura de la página con la información de la pregunta 63 fig 5.5 Boceto del diseño de la organización de la página inicial perfil personal 63 fig 5.6 Diseño de la organización de la página principal perfil personal 64 fig 6.1.1 Desarrollo de las clases en Visual Studio .NET 79 fig 6.2.1 Distribución de las carpetas en Visual Studio .NET 84 fig 6.2.2 Formulario de edición desarrollado en Visual Studio .NET 85 fig 6.2.3 Diseño del formulario de inserción de items en Visual Studio .NET 87 fig 7.1 Fases de la documentación del proyecto 94
  5. 5. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo1. Introducción 20/03/07 CAPÍTULO 1 1.1. INTRODUCCIÓN Las organizaciones dependen cada vez más de las tecnologías de la información para alcanzar sus objetivos corporativos. La misión del departamento de tecnologías de la información es ofrecer servicios fiables, de alta calidad y a un coste aceptable, por lo que debe incorporar de manera sistemática las mejores prácticas del mercado para la optimización continua de sus procesos. La información es un recurso imprescindible para cualquier universidad que quiera ofrecer a sus clientes una mayor calidad. Las tecnologías de la información ofrecen la posibilidad de crear una infraestructura única mediante la que capturar, procesar, distribuir, explotar y almacenar esa información. Se trata de una herramienta estratégica para potenciar la eficacia de la actividad asistencial, la asimilación y puesta en práctica del conocimiento derivado de la investigación, y la optimización en el despliegue y consumo de recursos que esta actividad requiere. Debida a la gran abundancia de información disponible a usuarios de internet, una de las necesidades que surgen es la de proveer al usuario de medios para manejar de manera más efectiva el gran volumen, dinamismo y complejidad de la información. Generalmente el usuario se ve enfrentado con la necesidad de navegar entre el gran volumen de datos para buscar y localizar la información que necesita y que le es de importancia. Esto representa frecuentemente una desorientación del usuario entre los diferentes caminos que puede seguir un sistema con tantos medios de búsqueda. La información tiene que ser inteligente. El principal objetivo de los sistemas de gestión de incidencias es el procesamiento de las consultas y las incidencias de cualquier tipo. Esto se consigue mediante la correcta clasificación de los niveles de información. En función de los niveles de habilidad y especialización de sus miembros, estos equipos se agrupan en unidades de primer, segundo y tercer nivel de soporte. En esta función, la gestión de incidencias asume el papel particular de mantener el contacto entre los sistemas de información y el negocio. La gestión de incidencias es el primer y más importante punto de contacto para el cliente. A la hora de realizar el correspondiente estudio del estado del arte de los centro asistenciales se tiene que destacar la metodología ITIL (Information Technology Infrastructure Library) la cual es una colección de las mejores prácticas contempladas en el sector de las tecnologías de la Información que se ha convertido en un estándar “de facto”. ITIL describe los procesos de gestión de servicios de tecnologías de la información. Dentro de esta metodología se recomienda una serie de pautas a la hora de trabajar con un centro asistencial. Un primer concepto que se debe conocer es la definición de incidente. Un incidente es cualquier acontecimiento que no forma parte del funcionamiento normal de un servicio y que causa o puede causar una interrupción o reducción en la calidad del mismo. La primera fase en todo centro asistencial es la de registrar la incidencia, en esta fase almacenaremos información del tipo de quién informa del problema, que síntomas se extraen del problema, cuál es el equipo involucrado, etc. La siguiente fase será clasificar la incidencia y asignar el trabajo a realizar a un grupo de soporte o a un técnico, desarrollando para ello un estudio de los niveles de información llegando 3
  6. 6. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo1. Introducción 20/03/07 hasta tres niveles de gestión. Una tercera fase vendrá definida por la investigación de la causa de la incidencia y comparación con otras incidencias parecidas, para ello se necesitará tener la información bien clasificada. De esta forma se desarrollará implícitamente una base de conocimiento (Knowledge Base) con información no destacable por su cantidad sino por su calidad para nuestra organización, de esta forma se conseguirá el recuperar la información de forma rápida, fácil y eficaz. Finalizando el ciclo de vida del incidente se documentará la solución, se adjuntarán los ficheros con información relacionada y se cerrará la incidencia. Concluyendo esta etapa se comunicará automáticamente al usuario el estado de su solicitud a través del e-mail y del portal de soporte. Y por último y como en cualquier sistema de Información en la metodología ITIL se contempla la necesidad y obligación de elaborar informes, que ayuden a conocer qué está sucediendo y a mejorar el proceso. Finalizando este punto a modo de conclusión se resumirá que cualquier sistema de información asistencial deberá destacar por las siguientes características: • Deberá convertirse en un punto principal de contacto. Al tener un punto central de contacto el usuario obtiene asistencia inmediata por parte de personas con los conocimientos apropiados y la disposición para atenderlo. • Otra de las principales características anteriormente comentadas es el registro y seguimiento de los problemas. Cuando se reciben llamadas o emails por problemas técnicos por parte de los usuarios, generalmente no se cuenta con los mecanismos y herramientas tecnológicas apropiadas para registrarlos constantemente, por lo que el registro y su seguimiento se hacen, con el tiempo, una tarea muy difícil de controlar. Con la gestión del centro de asistencia, se pretende crear estos mecanismos de forma automatizada que nos permita llevar un control preciso de todas las llamadas o emails que se reciben, con la finalidad de generar, en un determinado lapso de tiempo, mediciones que permitan conocer la razón de las llamadas y las soluciones propuestas. Todo esto deberá ir acompañado de una correcta definición de responsabilidades y funciones dentro de la organización. El apoyo a usuarios finales, durante mucho tiempo ha sido visto en muchas empresas y por muchas personas, como una función poco admirable y de bajo perfil, de allí que los profesionales del área de sistemas se sientan poco atraídos a ejercer estas funciones como parte de sus responsabilidades diarias. Uno de los principios fundamentales de la gestión de un centro de asistencia, es que deben constituirse equipos de trabajo con la responsabilidad de atender los problemas técnicos de los usuarios. Su función, dependiendo de la estructura organizacional que se diseñe dentro del centro de asistencia, será buscar las soluciones oportunas a los problemas presentados. El desarrollo de centros asistenciales nos permitirá la gestión de incidencias, desde su registro inicial hasta su cierre, incorporando estándares internacionales de buenas prácticas como ITIL, contribuyendo a una mayor productividad de la organización. La justificación del desarrollo y estudio de un centro asistencial aplicado a un entorno universitario viene dado por que actualmente las instituciones universitarias se encuentran en una etapa arcaica en cuanto a los sistemas de información asistencial se refiere. Son muchas las universidades que no tienen en su poder dichos sistemas y cada vez son más los problemas que ello les repercute. La competencia es dura y exige dar mayor calidad y satisfacción al cliente. Una de las grandes motivaciones que mueve en estos momentos al desarrollo de dicho proyecto es el problema de la generación de un gran volumen de documentos impresos, una media de 3.000 documentos anuales, muchos de ellos repetitivos y lentamente administrados, sin quedar 4
  7. 7. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo1. Introducción 20/03/07 constancia en ningún sitio de su correcta gestión. Gracias a la implantación de estos sistemas se consigue llevar un seguimiento de las incidencias automatizando su resolución, además de disponer de un mecanismo de búsqueda para consultar cómo se solucionaron situaciones similares, agilizando el tiempo de resolución, evitando costos de papeles y consiguiendo así dar al alumno una respuesta rápida, adecuada y eficaz en todo momento. Este nuevo sistema de gestión automatizada de atención a usuarios, abarca la comunicación y gestión de solicitudes e incidencias informáticas que se generan en el entorno universitario. Este sistema se establece como el punto central de contacto entre el usuario final y la gestión de los servicios informáticos, siendo una fuente de información relevante para gestión de los distintos servicios informáticos. 1.2 OBJETIVOS Los objetivos del proyecto se dividirían en los siguientes: • Estudio del estado del arte de la tecnología ITIL. • Estudio comparativo de los sistemas de información asistencia. • Estudio de los lenguajes de programación aplicado en el proyecto. • Diseño de la base de datos del sistema de información asistencial. • Estudio de la usabilidad aplicado al sitio web a desarrollar. • Desarrollo final del centro de asistencia. Estudio del estado del arte de la tecnología ITIL En esta sección se comentará el estado del arte de los centros de Asistencia, para ello se empezará comentando que metodología se siguen para ello. Centrándonos en aspectos tales como que es ITIL, que es el soporte de servicio y la gestión de incidencias. Estudio comparativo de los sistemas de información asistencial En una parte se hará una comparativa de las diferentes aplicaciones relacionadas con la gestión de incidencias. Dentro del estado del arte se reflejará como está el panorama actual, además de detectar las carencias y fortalezas de nuestra competencia. Gracias a este estudio incrementaremos nuestras posibilidades de éxito. Diseño de la base de datos del sistema de información asistencial En esta sección se detallará el diseño de la base de datos del Help Desk. Se verán los niveles conceptual, lógico y físico. Una vez expuesto el diseño veremos los procedimientos almacenados implementados sobre SQL Server que tratan esos datos. Estudio de los lenguajes de programación aplicado en el proyecto Este apartado se dedicará a comentar el código implementado en ASP.NET, subrayando los detalles de la programación desarrollada. Dentro de esta sección se comentará además las ventajas que ofrece C# .NET entre ellas la herencia, los interfaces y la sobrecarga, que lo convierten en un eficaz lenguaje de programación orientado a objetos. 5
  8. 8. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo1. Introducción 20/03/07 Estudio de la usabilidad aplicado al sitio web a desarrollar Este apartado se realizará un estudio de la estructura del sitio web que se desea desarrollar, para ello se recurrirá a estudios ya realizados revisando las pautas que se recomiendan para ello. También se repasará el uso de las hojas de estilos (CSS) aplicado al diseño. Desarrollo final del centro de asistencia. Y todo esto concluirá con el desarrollo de la Aplicación, la cual será desarrollada mediante la tecnología ASP.NET, siguiendo la arquitectura de tres capas. La arquitectura de tres capas tiene una primera fase que se dedica a la persistencia de los datos, en esta fase se diseña una base de datos con la que poder mantener dicha persistencia y así poder almacenar todos los datos que una biblioteca puede generar. La segunda capa de diseño representa el nivel del dominio o aplicación, consistente en aplicar los componentes realizados en la aplicación para se implementen correctamente las características especificadas en la fase de modelo conceptual. Y finalmente la tercera fase es la de la realización de la interfaz gráfica de usuario (IGU). 6
  9. 9. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 2. Propuesta y Planificación 20/03/07 CAPÍTULO 2 2.1. PROPUESTA Y PLANIFICACIÓN DEL PROYECTO A continuación se describirá en profundidad cada una de las fases del proyecto, indicando el objetivo marcado, las subtareas identificadas y el resultado esperado. También se establecerán plazos para cada tarea que tendrán su representación gráfica en un diagrama de de Gantt. Tras un estudio del proyecto propuesto se han identificado hasta 10 fases distintas. Estas fases irán desde la profundización en el estudio de la metodología ITIL, definiendo conceptos, pasando por el análisis de las incidencias de la universidad hasta llegar al diseño, implementación e implantación del propio sistema. Las fases identificadas son: 2.1 Ámbito 2.1.1 Descripción Determinar el ámbito del proyecto. El objeto de esta fase es la del estudio inicial del proyecto. En esta fase se buscará hacer un estudio inicial de los recursos de los que se dispone para realizar el proyecto 2.1.2 Objetivos Uno de los principales objetivos de esta etapa inicial será el de afianzar y fidelizar a los patrocinadores del proyecto, en nuestro caso la Universidad. Se tratará de definir los recursos preliminares, con ello se contemplará el personal dedicado al proyecto, ordenadores de los que se dispone, medios publicitarios, tiempo estimado al proyecto, etc. Se buscará realizar una buena gestión y planificación del proyecto con lo cual se pretende afianzar los recursos principales de los objetivos de partida. 2.1.3 Tareas • Afianzar a los patrocinadores del proyecto • Definir recursos preliminares • Afianzar recursos principales 2.1.4 Resultados esperados El resultado final esperado es el conseguir haber determinado el ámbito total del proyecto. 7
  10. 10. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 2. Propuesta y Planificación 20/03/07 2.2 Estudio metodología ITIL 2.2.1 Descripción Conocer en profundidad la metodología ITIL y lo que conlleva, en que consiste, la étapa de gestión del servicio, que contempla y como se desarrolla un service desk. 2.2.2 Objetivos Este estudio se encargará de desarrollar los conceptos relacionados con la metodología ITIL, seguidamente vendrá la descripción y la metodología a desarrollar. Para finalmente cerrar este apartado con la implantación de ITIL en un entorno universitario. 2.2.3 Tareas • Conceptos: Se estudiarían los conceptos de incidencia, ITIL, gestión del servicio y aquellos relacionados con el tema de investigación. El objetivo es tener un conocimiento claro y conciso de lo que se pretende diseñar e implementar, diferenciándolo de aplicaciones de gestión que no implementen ITIL para ello. • Descripción y metodología: Descripción de las fases de implementación de ITIL y su metodología destacando la gestión del incidente. • Implantación: Esta tarea se centrará en el estudio del manejo del incidente. Se analizarán los pasos que se recomienda dar y en qué momentos, cómo implantarlo en un entorno universitario y cómo ir enseñando a los usuarios a familiarizarse con el sistema. 2.2.4 Resultados esperados El resultado esperado es un conocimiento profundo de la metodología ITIL: qué es un service desk, la metodología común del manejo del incidente, ventajas e inconvenientes para la empresa, las dificultades en la implantación, el conocimiento del ciclo vital del incidente. Demostrar los beneficios en los que puede repercutir el uso de ITIL en una determinada empresa. 2.3 Análisis y requisitos del software 2.3.1 Descripción En esta étapa se busca realizar un análisis exhaustivo de las necesidades reales del proyecto ha desarrollar para conseguir como resultado, una correcta consecución del mismo. 2.3.2 Objetivos Un primer estudio vendrá contemplado por un análisis de las necesidades del proyecto. Estudio del público objetivo del proyecto y que se desea alcanzar con el desarrollo del mismo. Acompañando a esta etapa se realizará el desarrollo de un presupuesto, además de la planificación de tiempo y fechas de entrega esperando así la aprobación del cliente para continuar. 8
  11. 11. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 2. Propuesta y Planificación 20/03/07 2.3.3 Tareas • Realizar análisis de necesidades • Borrador de las especificaciones preliminares del software • Desarrollar presupuesto preliminar • Revisar las especificaciones del software y el presupuesto con el equipo • Incorporar los comentarios a las especificaciones del software • Desarrollar los tiempos y fechas de entrega • Obtener aprobaciones para continuar (concepto, fechas, presupuestos) • Afianzar los recursos necesarios 2.3.4 Resultados esperados Finalmente como resultado de esta etapa se espera tener el análisis completado. 2.4 Estudio de las Incidencias del sistema 2.4.1 Descripción Con esta etapa se busca identificar las distintas incidencias que se generan en una universidad. Se desarrollará un estudio de las especificaciones generales de la aplicación ha desarrollar, desarrollando el ciclo vital de cada una de las incidencias. 2.4.2 Objetivos Estudio y conocimiento de la plataforma de desarrollo con la que se va ha desarrollar el sistema. Obtención, en líneas generales de los pasos que sigue la universidad en su día a día y en los procesos que generan más incidencias. Obtener una serie de requisitos de carácter general que marcaran un primer diseño del sistema de información. Identificación de las incidencias: se identificarán las distintas incidencias que se generan en una universidad, tratando de separarlas y diferenciarlas al máximo. Clasificándolas finalmente por departamentos. Identificación del modelo de resolución de la incidencia por cada nivel: A partir de la separación de las distintos tipos de incidencia, se obtendrá de nuevo el modelo de trabajo de cada una de las incidencias en particular: se identificarían los usuarios que intervendrían en su resolución clasificándolos por niveles, la importancia de cada uno de estos, la frecuencia con la que intervienen en su resolución, etc. El resultado será una visión muy concreta y detallada de cada incidencia. 2.4.3 Tareas • Desarrollar especificaciones de funcionamiento • Desarrollar prototipo basado en las especificaciones de funcionamiento • Revisar especificaciones de funcionamiento • Identificar las distintas incidencias y su resolución por nivel • Incorporar comentarios a las especificaciones de funcionamiento • Elección herramientas de desarrollo 9
  12. 12. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 2. Propuesta y Planificación 20/03/07 2.4.4 Resultados esperados Identificación de la totalidad de las incidencias del sistema y su correcto estudio de resolución jerarquizado por niveles debidamente estipulados. 2.5 Base de Datos 2.5.1 Descripción Diseñar e implementar la base de datos que será soporte para todo el sistema de información. Se definirá por completo indicando relación y restricciones. 2.5.2 Objetivos Un primer paso será el análisis de los requisitos determinados en la fases anteriores. De esta manera, analizando las necesidades de la metodología ITIL, se podrán comenzar a definir los datos que necesitarán para realizar su correcta implantación. Después se desarrollará el diseño conceptual que nos permitirá un entendimiento completo de la estructura, el significado (semántica), las relaciones y las restricciones de la base de datos, siendo siempre independiente del SGBD que se elija posteriormente. El diseño conceptual, a través del modelo E-R, representará las estructuras que constituyen el contenido del sistema de información junto con restricciones de distintos tipos y finalmente se estudiarán y evaluarán distintos SGBD valorando sus aspectos negativos y positivos, precio y coste de mantenimiento entre otros. 2.5.3 Tareas • Análisis de requisitos • Diseño conceptual: modelo E-R • Selección de SGBD 2.5.4 Resultados esperados Con la resolución de esta etapa se espera definir por completo el diseño y la implantación de la base de datos. 2.6 Desarrollo 2.6.1 Descripción Esta es la fase más extensa de las desarrolladas, se realizará la preparación de la lógica de negocio, para después acompañar al desarrollo de la interfaz que a su vez vendrá respaldado de un estudio de la usabilidad del sistema. 2.6.2 Objetivos Diseño e implementación de objetos que representen los datos con los que la información trabaja. Creación de los objetos de datos que hagan de intermediario entre los objetos de negocio y la base de datos. Desarrollo de la interfaz. 10
  13. 13. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 2. Propuesta y Planificación 20/03/07 Estudio de la usabilidad del interfaz ha desarrollar para hacer al usuario una aplicación cercana y fácilmente entendible en su flujo de trabajo diario. Maquetación de la interfaz utilizando HTML y CSS para permitir que se pueda cambiar la apariencia, adecuándose a los estándares de usabilidad. 2.6.3 Tareas • Revisar especificaciones de funcionamiento • Identificar parámetros de diseño modular y de componentes separados • Asignar el personal de desarrollo • Desarrollar el código • Pruebas de los desarrolladores • Estudio de la usabilidad • Maquetación HTML 2.6.4 Resultados esperados Desarrollo completado 2.7 Pruebas 2.7.1 Descripción Se busca identificar las anomalías además de asegurar el correcto funcionamiento de la aplicación. 2.7.2 Objetivos Se tratará de testear la aplicación al máximo, introduciendo datos ficticios y probando todas las acciones posibles para descubrir posibles errores. Durante una semana, se instalará la aplicación en la universidad usando datos reales, para comprobar si existen errores no corregidos en fases anteriores. 2.7.3 Tareas • Desarrollar planes de pruebas de integración usando las especificaciones del producto • Revisar el código modular • Probar si los módulos de los componentes se ajustan a las especificaciones del producto • Identificar anomalías y anotarlas en las especificaciones del producto • Modificar código • Consiste en realizar una guía para próximos proyectos que ayude a realizar un diseño de una manera fácil y esquematizada. • Facilitar la labor de realizar el diseño. • Reducción del coste temporal de próximos proyectos. 2.7.4 Resultados esperados Desarrollo del plan de pruebas completado 11
  14. 14. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 2. Propuesta y Planificación 20/03/07 2.8 Formación 2.8.1 Descripción Se tratará de desarrollar las especificaciones de formación para los usuarios finales además de documentar las especificaciones de formación para el personal de soporte al cliente. 2.8.2 Objetivos Se busca el acercamiento de la aplicación a los usuarios finales, se persigue conseguir que la conozcan y se habitúen a ella, para ello se recurrirá a la realización de cursos de formación, realización de manuales de usuario, etc. 2.8.3 Tareas • Identificar la metodología de formación (utilizando PC, aulas, etc.). • Desarrollar materiales de formación. • Realizar estudio de posibilidades de uso de la formación. • Finalizar los materiales de formación. • Desarrollar mecanismo para impartir la formación. 2.8.4 Resultados esperados Materiales de formación completados 2.9 Documentación 2.9.1 Descripción Fase dedicada a la documentación final del proyecto, gracias a esta quedará plasmado todo el esfuerzo realizado para la correcta consecución del proyecto, en esta fase se abordaran temas tales como la confección de los manuales de usuario, manuales de ayuda. 2.9.2 Objetivos Se pretende dejar plasmado toda la información necesaria para que cualquier persona ajena al proyecto pueda en el menor tiempo posible entender el proyecto en todas sus facetas. 2.9.3 Tareas • Revisar la documentación de la ayuda • Incorporar los comentarios a la documentación de la ayuda • Desarrollar las especificaciones de los manuales de usuario • Desarrollar los manuales de usuario • Revisar toda la documentación para el usuario • Incorporar comentarios a la documentación de usuario 2.9.4 Resultados esperados 12
  15. 15. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 2. Propuesta y Planificación 20/03/07 • Documentación completadas 2.10 Componente piloto 2.10.1 Descripción Consiste en realizar una guía para próximos proyectos que ayude a realizar un diseño de una manera fácil y esquematizada. 2.10.2 Objetivos • Facilitar la labor de realizar el diseño. • Reducción del coste temporal de próximos proyectos. 2.10.3 Tareas • Desarrollar las especificaciones de la ayuda • Desarrollar el sistema de ayuda • Designar grupo de pruebas – Jefe de proyecto • Desarrollar el mecanismo de entrega del software • Instalar y distribuir el software • Obtener comentarios de los usuarios • Evaluar la información de las pruebas • Componente piloto completado 2.10.4 Resultados esperados Documentación que sirva como guía en el desarrollo del proyecto. 2.2. Planificación temporal. Diagrama de Gantt. Para la realización de la planificación se utiliza el programa Microsoft Project. Destacar que las tareas sin duración son consideradas como hitos por la aplicación y representan un evento puntual como la presentación de un documento. A continuación, se muestra el diagrama de Gantt, que genera la aplicación de Microsoft Project, en donde el eje horizontal representa el tiempo transcurrido y el vertical las distintas tareas realizadas. Este grafico permite visualizar también la dependencia temporal entre una tarea, sus predecesoras y sus sucesoras. Por ultimo indicar que al lado de la tarea aparece el nombre de la persona que va a realizarla. 13
  16. 16. Id Nombre de tarea 09 oct '06 06 nov '06 04 dic '06 01 ene '07 29 ene '07 26 feb '07 26 mar '07 23 abr '07 21 may '07 18 jun '07 16 L V M S X D J L V M S X D J L V M S X D J L V M S X 1 Ámbito Ámbito 2 Determinar el ámbito del proyecto Determinar el ámbito del proyecto Administración 3 Afianzar a los patrocinadores del proye Afianzar a los patrocinadores del proyecto Administración 4 Definir recursos preliminares Definir recursos preliminares Jefe de proyecto 5 Afianzar recursos principales Afianzar recursos principales Jefe de proyecto 6 Ámbito completado Ámbito completado 06/02 7 Estudio Metodología ITIL Estudio Metodología ITIL 8 Conceptos Conceptos 9 Descripción y Metodología Descripción y Metodología 10 Estudio posible Implantación Estudio posible Implantación 11 Estudio Completado Estudio Completado 09/02 12 Análisis y requisitos del software Análisis y requisitos del software 13 Realizar análisis de necesidades Realizar análisis de necesidades Analista 14 Borrador de las especificaciones prelim Borrador de las especificaciones preliminares del software Analista 15 Desarrollar presupuesto preliminar Desarrollar presupuesto preliminar Jefe de proyecto 16 Revisar las especificaciones del softwa Revisar las especificaciones del software y el presupuesto con el equipo Jefe de proyecto;Analista 17 Incorporar los comentarios a las espec Incorporar los comentarios a las especificaciones del software Analista 18 Desarrollar los tiempos y fechas de ent Desarrollar los tiempos y fechas de entrega Jefe de proyecto 19 Obtener aprobaciones para continuar ( Obtener aprobaciones para continuar (concepto, fechas, presupuestos) Administración;Jefe de proyecto 20 Afianzar los recursos necesarios Afianzar los recursos necesarios Jefe de proyecto 21 Análisis completado Análisis completado 02/03 22 Estudio de las Incidencias del Sistema Estudio de las Incidencias del Sistema 23 Estudio de las incidenias del sistema Estudio de las incidenias del sistema 24 Estudio Completado 02/03 25 Base de Datos Base de Datos 26 Especificaciones preliminares del softw Especificaciones preliminares del software Analista 27 Desarrollar especificaciones de funcion Desarrollar especificaciones de funcionamiento Analista 28 Desarrollar prototipo basado en las esp Desarrollar prototipo basado en las especificaciones de funcionamiento Analista 29 Revisar especificaciones de funcionam Revisar especificaciones de funcionamiento Administración 30 Incorporar comentarios a las especifica Incorporar comentarios a las especificaciones de funcionamiento Administración 31 Obtener aprobación para continuar Obtener aprobación para continuar Administración;Jefe de proyecto 32 Diseño completado Diseño completado 23/03 33 Desarrollo Desarrollo 34 Revisar especificaciones de funcionam Revisar especificaciones de funcionamiento Desarrollador 35 Identificar parámetros de diseño modu Identificar parámetros de diseño modular y de componentes separados Desarrollador 36 Asignar el personal de desarrollo Asignar el personal de desarrollo Desarrollador 37 Desarrollar el código Desarrollar el código Desarrollador 38 Pruebas de los desarrolladores (depura Pruebas de los desarrolladores (depuración primaria) Desarrollador 39 Desarrollo completado Desarrollo completado 24/04
  17. 17. Id Nombre de tarea 09 oct '06 06 nov '06 04 dic '06 01 ene '07 29 ene '07 26 feb '07 26 mar '07 23 abr '07 21 may '07 18 jun '07 16 L V M S X D J L V M S X D J L V M S X D J L V M S X 40 Pruebas Pruebas 41 Desarrollar planes de pruebas de unida Desarrollar planes de pruebas de unidades usando las especificaciones del producto Personal de pruebas 42 Desarrollar planes de pruebas de integ Desarrollar planes de pruebas de integración usando las especificaciones del producto Personal de pruebas 43 Pruebas de unidades Pruebas de unidades 44 Revisar el código modular Revisar el código modular Personal de pruebas 45 Probar si los módulos de los comp Probar si los módulos de los componentes se ajustan a las especificaciones del producto Personal de pruebas 46 Identificar anomalías y anotarlas e Identificar anomalías y anotarlas en las especificaciones del producto Personal de pruebas 47 Modificar código Modificar código Personal de pruebas 48 Volver a probar el código modifica Volver a probar el código modificado Personal de pruebas 49 Pruebas de unidades completadas Pruebas de unidades completadas 15/05 50 Formación 51 Desarrollar las especificaciones de form Desarrollar las especificaciones de formación para los usuarios finales Formadores 52 Desarrollar las especificaciones de form Desarrollar las especificaciones de formación para el personal de soporte al cliente Formadores 53 Identificar la metodología de formación Identificar la metodología de formación (utilizando PC, aulas, etc.) Formadores 54 Desarrollar materiales de formación Desarrollar materiales de formación Formadores 55 Realizar estudio de posibilidades de us Realizar estudio de posibilidades de uso de la formación Formadores 56 Finalizar los materiales de formación Finalizar los materiales de formación Formadores 57 Desarrollar mecanismo para impartir la Desarrollar mecanismo para impartir la formación Formadores 58 Materiales de formación completados Materiales de formación completados 28/05 59 Documentación Documentación 60 Desarrollar las especificaciones de la a Desarrollar las especificaciones de la ayuda Escritores técnicos 61 Desarrollar el sistema de ayuda Desarrollar el sistema de ayuda Escritores técnicos 62 Revisar la documentación de la ayuda Revisar la documentación de la ayuda Escritores técnicos 63 Incorporar los comentarios a la docume Incorporar los comentarios a la documentación de la ayuda Escritores técnicos 64 Desarrollar las especificaciones de los Desarrollar las especificaciones de los manuales de usuario Escritores técnicos 65 Desarrollar los manuales de usuario Escritores técnicos Desarrollar los manuales de usuario 66 Revisar toda la documentación para el Revisar toda la documentación para el usuario Escritores técnicos 67 Incorporar comentarios a la documenta Incorporar comentarios a la documentación de usuario Escritores técnicos 68 Documentación completada Documentación completada 07/05 69 Componente piloto 70 Designar grupo de pruebas Designar grupo de pruebas Jefe de proyecto 71 Desarrollar el mecanismo de entrega d Desarrollar el mecanismo de entrega del software 72 Instalar y distribuir el software Instalar y distribuir el software Equipo de distribución 73 Obtener comentarios de los usuarios Obtener comentarios de los usuarios Equipo de distribución 74 Evaluar la información de las pruebas Evaluar la información de las pruebas Equipo de distribución 75 Componente piloto completado Componente piloto completado 26/06
  18. 18. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 CAPÍTULO 3 3.1 ESTADO DEL ARTE En esta sección se va ha comentar el estado del arte de los centros de asistencia, para ello se empezará comentando que metodología se sigue para ello. En una segunda parte se hará una comparativa de las diferentes aplicaciones relacionadas con la gestión de incidencias 3.1.1 Introducción a ITIL Hace unas décadas que los desarrollos en tecnologías de la información vienen teniendo un gran impacto en los procesos del negocio. La introducción de la tecnología Lan, cliente / servidor e Internet han permitido que las organizaciones lleven sus productos al mercado más rápido. Estos desarrollos han marcado la transición de la era industrial a la de la información. Las organizaciones jerárquicas tradicionales tienen dificultades para adaptarse a mercados en constante cambio, ello ha marcado una tendencia hacia organizaciones menos jerárquicas y más flexibles. De igual manera, dentro de las organizaciones se ha puesto énfasis en cambiar de funciones verticales, o departamentos a procesos horizontales que se extienden a toda la organización, y se le otorga al personal de menor nivel la autoridad para tomar decisiones. Teniendo en cuenta estos aspectos básicos se desarrollaron los procesos operativos de la gerencia de servicio en tecnologías de la información. En los años 80, la calidad de los servicios en tecnologías de la información que brindaba el gobierno británico era tal que se instruyó a la por entonces CCTA (Agencia Central de Telecomunicaciones y Computación, hoy Ministerio de Comercio, OGC) a que desarrollara una propuesta para que los ministerios y demás oficinas del sector público de Gran Bretaña utilizaran de manera eficaz y con eficiencia de costos los recursos en tecnologías de la información. El objetivo era desarrollar una propuesta sin compromisos con proveedor alguno. Esto dio como resultado la Information Technology Infrastructure Library (ITIL). ITIL nació de una colección de las mejores prácticas observadas en la industria del servicio de las tecnologías de la información. ITIL brinda una descripción detallada de un número de prácticas importantes en tecnologías de la información, a través de una amplia lista de verificación, tareas, procedimientos y responsabilidades que pueden adaptarse a cualquier organización en tecnologías de la información. En algunos casos hasta se han definido las prácticas como procesos que cubren las actividades más importantes de las organizaciones de servicio en tecnologías de la información. La vasta cantidad de temas cubiertos por las publicaciones transforma a la ITIL en un elemento de referencia útil para fijar nuevos objetivos de mejora para la organización en tecnologías de la información. La organización puede crecer y madurar con ellos. En base a ITIL se han desarrollado varios sistemas para la administración de servicio en tecnologías de la información, generalmente organizaciones del negocio. Los ejemplos incluyen Hewlett & Packard (HP ITSM modelo de referencia), IBM (Modelo de Proceso), Microsoft y muchos otros. Ésta es una de las razones por las que ITIL se ha convertido en el estándar de facto para describir 15
  19. 19. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 varios procesos fundamentales de la administración de servicio en tecnologías de la información. Esta adopción y adaptación de ITIL refleja la filosofía de ITIL, y es un desarrollo bienvenido ya que la ITIL se ha transformado en el tan necesario orden imprescindible para el actual medio heterogéneo y dividido de tecnologías de la información. ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez más de las tecnologías de la información para alcanzar sus objetivos corporativos. Esta dependencia en aumento ha dado como resultado una necesidad creciente de servicios en tecnologías de la información de calidad que se correspondan con los objetivos del negocio, y que satisfaga los requisitos y las expectativas del cliente. ITIL ofrece un marco común para todas las actividades del departamento de tecnologías de la información, como parte de la provisión de servicios, basado en la infraestructura de las tecnologías de la información. Estas actividades se dividen en procesos, que dan un marco eficaz para lograr una administración de servicio más madura. Cada uno de estos procesos cubre una o más tareas del departamento de tecnologías de información, tal como desarrollo de servicio, administración de infraestructura, provisión y soporte de los servicios. Este planteo del proceso permite describir las mejores prácticas de la administración de servicio independientemente de la estructura de organización real de la entidad. Muchas de estas prácticas son claramente identificables y son de hecho utilizadas hasta cierto punto en varias organizaciones de las tecnologías de la información. ITIL presenta estas mejoras prácticas de manera coherente. Los libros de ITIL describen cómo estos procesos, que se han identificado, pueden ser optimizados, y cómo la coordinación entre ellos puede ser mejorados. Los libros de ITIL también explican cómo los procesos se pueden formalizar dentro de una organización. Los libros de ITIL también ofrecen un marco de referencia para la terminología relevante dentro de la organización, y ayuda a definir los objetivos y a determinar el esfuerzo necesario. 3.1.2 Ventajas de ITIL para el cliente/usuario La entrega de servicios de las tecnologías de la información se orienta más al cliente y gracias a los acuerdos sobre la calidad del servicio se mejora la relación. Gracias a la metodología ITIL se describen mejor los servicios, se consigue un lenguaje más cómodo para el cliente, y a la vez con mayores detalles. Como consecuencia de la utilización de ITIL se manejan mejor parámetros de calidad y de costo del servicio. Su uso también mejora la comunicación con la organización al acordar los puntos de contacto. 3.1.3 Ventajas de ITIL para la organización La organización IT desarrolla una estructura más clara, se vuelve más eficaz, y se centra más en los objetivos corporativos La administración tiene más control y los cambios resultan más fáciles de manejar. Una estructura de proceso eficaz brinda un marco para concretar de manera más eficaz el outsourcing de los elementos de los servicios en tecnologías de la información. 16
  20. 20. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 Seguir las mejores prácticas de ITIL alienta el cambio cultural hacia la provisión de servicio, y sustenta la introducción de un sistema de administración de calidad basado en las series ISO 9000. ITIL establece un marco de referencia para la comunicación interna y la comunicación con los proveedores, como así también la estandarización y la identificación de los procedimientos. 3.1.4 Problemas potenciales de ITIL Su introducción puede llevar tiempo y bastante esfuerzo, y supone un cambio de cultura en la organización. Una introducción demasiado ambiciosa puede llevar a la frustración porque nunca se alcanzan los objetivos. Si la estructura de procesos se convierte en un objetivo en sí misma, la calidad del servicio se puede ver afectada de forma adversa. En ese caso, los procedimientos se transforman en obstáculos burocráticos que tratan de evitarse. No hay progreso por la falta de comprensión sobre lo que deben dar los procesos, cuáles son los indicadores de desempeño, y cómo se controlan los procesos. No se ven las reducciones de costo y la mejora en la entrega de los servicios. 3.1.5 Perspectiva general de la Gestión del Servicio según ITIL ITIL postula que el servicio de soporte, la administración y la operación se realiza a través de seis procesos: • Service Desk. • Manejo de incidentes. • Manejo de problemas. • Manejo de configuraciones. • Manejo de cambios. • Manejo de entregas. Nos vamos a centrar en los tres primeros que son los que más se acercan al interés del proyecto. 3.1.5.1 Service DESK El primero de ellos es el service desk que es el punto central de contacto entre el cliente y el área de las tecnologías de la información en todos los aspectos que conciernen a los servicios de tecnologías de la información. Esto incluye funciones de help desk así como coordinación de peticiones de cambios, gestión del nivel de servicio, gestión de la configuración y todos los otros procesos de gestión del servicio de ITIL. El service desk no es un proceso sino una función dentro de la organización del servicio. En su papel especial como primer punto de contacto con el cliente, el service desk es de gran importancia, aun más cuanto representa la imagen y la calidad de servicio de la organización de tecnologías de la información. Determinar la estructura del service desk y seleccionar a personal adecuado para el mismo depende de un número importante de factores que conciernen a la forma y el tipo de la compañía. Según cambie ésta, la estructura del service desk necesitara cambiar en consecuencia, de un modo continuo. Básicamente, hay tres estructuras de service desk: 17
  21. 21. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 Service desk local: Cada localización o cada departamento en la compañía tiene su propia unidad de service desk local. Sus ventajas son la óptima proximidad al cliente en consecuencia la capacidad de reflejar sus necesidades individuales con más exactitud. La coordinación central y la estandarización de procesos son algunas de las tareas más necesarias por el service desk local. Service desk central: Existe un único service desk responsable para todas las unidades organizativas. Esto tiene la ventaja de la facilidad de manejo y la estandarización de procesos. Sin embargo, es más difícil atender individualmente los requerimientos locales de los clientes. En el caso de organizaciones extensas también puede surgir el problema de diferentes lenguas y zonas horarias. Organización de service desk virtual: Este tipo de service desk combina aspectos de las dos formas organizativas anteriores. Gracias a la tecnología actual, la información puede ser guardada centralizadamente y estar disponible globalmente. Las unidades locales de service desk proporcionan soporte on site a los clientes, mientras que la unidad central de service desk es responsable de todas las consultas así como de coordinar las organizaciones de servicio involucradas. El centro de servicio al usuario realiza una función esencial para la gestión de un servicio eficaz. Más que un centro de ayuda al usuario (CAU), el centro de servicio al usuario (CSU) actúa como la principal interconexión operacional entre la informática y sus usuarios. Una buena impresión inicial para cada uno de sus usuarios se basa en su funcionamiento y actitud. 3.1.5.2 Gestión de Incidencias El principal objetivo de la gestión de incidencias es restaurar el funcionamiento normal del servicio lo más rápido posible de manera que suponga una interrupción mínima para la empresa, asegurando de ésta manera que se mantengan los mejores niveles de servicio y disponibilidad posibles. Descripción La gestión de incidencias conlleva el procesamiento de las consultas y las incidencias de cualquier tipo. Esto se consigue mediante un grupo de especialistas que trabajan virtualmente al unísono. En función de los niveles de habilidad y especialización de sus miembros, estos equipos se agrupan en unidades de primer, segundo y tercer nivel de soporte. En esta función, la gestión de incidencias asume el papel particular de mantener el contacto entre los sistemas de TI y el negocio. Junto con el service desk, la gestión de incidencias es el primer y más importante punto de contacto para el cliente. ¿Por que Gestión de Incidentes? - Para asegurar el mejor uso de los recursos de apoyo a la empresa. - Para desarrollar y mantener expedientes significativos relacionados con los incidentes. - Para diseñar y aplicar un método consistente a todos los incidentes. Definición de Incidente 18
  22. 22. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 Un incidente es cualquier acontecimiento que no forma parte del funcionamiento normal de un servicio y que causa o puede causar una interrupción o reducción en la calidad del mismo. Ejemplos de Incidentes - Una aplicación errónea o no disponible. - Indisponibilidad de hardware o uso restringido. - Solicitudes de servicio de información o ayuda (por ejemplo. una ampliación del servicio). Responsabilidades - Detección y registro de incidentes. - Clasificación de todos los incidentes y apoyo inicial. - Investigación y diagnostico. - Resolución y recuperación. - Cierre del incidente. - Propiedad, control, seguimiento, y comunicación del incidente. Ciclo vital de incidente Papel que desempeña el centro de servicio al usuario (CSU) en la gestión de incidentes. El centro de servicio al usuario (CSU) suele desempeñar un papel clave en el proceso de gestión de incidentes, registrando y vigilando el progreso de incidentes y reteniendo su pertenencia. Consideraciones Claves Factores críticos para el éxito de la gestión de incidentes: - Una base de datos de gestión de configuración (“Configuration Management Data Base” CMDB) actualizada. - Una “base de conocimientos” donde se registren datos de problemas y errores Conocidos, así como resoluciones y soluciones provisionales. - Disponibilidad de herramientas de apoyo automatizados y eficaces. - Estrechas relaciones con una gestión de nivel de servicio eficaz. Priorización Urgencia es una valoración de la rapidez con la que se requiere la resolución de un incidente. Impacto refleja el posible efecto que el Incidente tendrá sobre el servicio empresarial. La prioridad de asignación de recursos para la resolución de un Incidente se base en una combinación de impacto y urgencia, junto con otros factores relevantes tales como disponibilidad de recursos. Relación entre Incidentes, Problemas y Errores conocidos Cuando la causa de un Incidente no se puede identificar si una investigación al respecto es requerida, entonces se creará un expediente de problema representa un error desconocido en uno o más elementos de configuración. Una vez identificada la causa subyacente y determinado el remedio o la corrección adecuada a través de una solicitud de cambios (“request for change”. RFC) el problema pasa a ser un expediente de error conocido. Estructura 19
  23. 23. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 Los incidentes recién registrados serán comparados con la base de datos de incidencias, problemas y errores conocidos. Se emplean las soluciones provisionales disponibles con el fin de resolver rápidamente los incidentes. Esta base de conocimientos debe ser mantenida de manera que solamente sean presentados al centro de servicio al usuario (CSU) los expedientes pertinentes. Tramitación de incidentes mayores Incidentes mayores son aquellos que ejercen un efecto extremo sobre la comunidad de usuarios o cuando la interrupción es excesiva. Deberá notificarse a la gestión de problemas y deberá organizarse una reunión oficial con aquellas personas que pueden ayudar. El centro de servicio al usuario (CSU) deberá asegurar que sea mantenido en el registro del incidente un expediente de las acciones y decisiones adoptados. Beneficios - Reducción del impacto de los incidentes sobre la empresa, gracias a su resolución puntual. - Identificación proáctiva de las mejoras beneficiosas. - Disponibilidad de información empresarial enfocada en relación con el acuerdo de nivel de servicio ( “Service Level Agreement” SLA). -Vigilancia mejorada del rendimiento frente a los SLA. - Mejor utilización del personal que resulta en mayor eficiencia. - Eliminación de Incidentes y Solicitudes de Servicio Perdidos. - Información más precisa contenida en la base de conocimientos, permitiendo una auditoria constante al tiempo que se registran los incidentes. - Menos interrupción tanto para el personal de apoyo de informática como para el usuario. Posibles Problemas - Falta de compromiso por parte de la dirección. - Falta de niveles de servicio acordados con el cliente. - Falta de conocimiento o recursos para resolver incidentes. - Procesos o funciones ausentes o incorrectamente integrados. - Herramienta de Software ausentes, inadecuadas o demasiado caras. - Usuarios y personal de informática que eluden el cumplimiento de los procesos. Indicadores de rendimiento - Cumplimiento de los niveles de servicio acordados. - Uno de los factores ha tener en cuenta es el coste de las tecnologías de información. - Se valorará la satisfacción del cliente. - Se tendrán en cuenta los tiempos y respuesta y procesamiento. - Cumplir el ratio de auto resolución. Proceso de manejo de incidentes Su objetivo primordial es reestablecer el servicio lo mas rápido posible para evitar que el cliente se vea afectado, esto se hace con la finalidad de que se minimicen los efectos de la operación. Se dice que el proveedor se debe de encargar de que el cliente no perciba todos aquellos pequeños o grandes fallos que llegue a presentar el sistema. 20
  24. 24. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 A este concepto se le llama disponibilidad es decir que el usuario pueda tener acceso al servicio y que nunca se vea interrumpido. Para este proceso se tiene un diagrama que en cada una de sus fases maneja cuatro pasos básicos que son: propiedad, monitorización, manejo de secuencias y comunicación. Detección y Registro de Incidentes Clasificación y apoyo inicial Sí Propiedad Solicitud de servicio Procedimiento de Vigilancia solicitud de servicio Seguimiento Comunicación No Investigación y diagnóstico Resolución y reparación Cierre del incidente Fig.3.1.1: Ciclo vital del incidente En el gráfico anterior vemos que se da como primera etapa la detección del incidente, esta etapa se da cuando el sistema presenta alguna anomalía o fallo, esto se puede traducir en un error en el sistema o que el usuario no puede hacer algo y recurre a pedir ayuda. Una segunda parte sería hacer una clasificación del incidente, en esta parte se ve si el error que se presenta es conocido o si nunca se ha presentado, de la mano a esta parte irá el soporte inicial que es el punto en el que el cliente llega a la mesa de servicio a solicitar ayuda, porque no sabe o no puede hacer algo. En caso de que el incidente sea conocido se hace el procedimiento de solicitud de servicio, es decir se ejecutan los pasos a seguir según el manual de procedimientos para poder llegar a la solución de una forma viable y eficiente. Una vez que se le dio una solución al incidente por medio del manual de procedimientos se recurre a la documentación y contabilización del incidente, para ver cuanta incidencia tiene este caso. Finalmente se hace una evaluación para ver si efectivamente se resolvió el incidente de forma satisfactoria, en el supuesto de ser afirmativo se cierra el incidente. El otro supuesto sería que la solución que se planteó no sea lo suficientemente eficiente o acertada para que se resuelva el problema, entonces se recurre a hacer una investigación y un diagnóstico de la situación para ver como se puede enfrentar el problema de frente y así conseguir resolverlo. Una vez que se tiene todo un contexto analizado se recurre a la ejecución de la propuesta de 21
  25. 25. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 solución del incidente y se hace un estudio para ver si el incidente es recuperable o si es un caso perdido, en la mayoría de los casos son recuperables, pero cuando el nivel de daño es muy fuerte, se da el caso por perdido. Finalmente se cierra el incidente y esta solución se documenta en la base de datos a la que se le llama base del conocimiento, aquí vienen documentadas todas las soluciones, con esto se consiguen establecer todos los pasos a seguir para que se haga de forma eficiente en el momento de volverse a presentar el incidente ya documentado, consiguiéndose así que sea mas fácil, rápida y eficiente su resolución. 3.1.5.3 Gestión de Problemas El objetivo de la gestión de problemas es minimizar el efecto adverso que tienen sobre los negocios los incidentes y problemas causados por errores en la infraestructura y prevenir proactivamente la ocurrencia de incidentes, problemas y errores. La gestión de problemas es de vital importancia para el área de soporte del servicio. Incluye el tratamiento de todos los fallos de los servicios de tecnologías de la información desde el punto de vista especial de identificación de la causa raíz de los mismos. Esto incluye recomendar cambios de los elementos de configuración a la gestión de cambios. Los procesos de gestión de problemas utilizan información proporcionada por otros procesos (por ejemplo por la gestión de incidencias o por la gestión de cambios). Además, la gestión de problemas toma una aproximación proactiva para detectar debilidades a priori y tomar medidas preventivas. ¿Por qué Gestión de Problemas? Las causas por las que se necesita recurrir a la gestión de problemas son las siguientes: - Para resolver los problemas de manera rápida y eficaz. - Para asegurarse de que los recursos sean dados una prioridad a fin de resolver los problemas en el orden más apropiado basado en la necesidad empresarial. - Para identificar y resolver proactivamente problemas y errores conocidos y con ello minimizar la posibilidad de que ocurran incidentes. - Para mejorar la productividad del personal de apoyo. - Para suministrar información de gestión relevante. Responsabilidades A continuación se hace una enumeración de las acciones que se deben de realizar a la hora de gestionar un problema: 1.- Control del problema. 2.-Identificación y registro del problema. 3.-Clasificación del problema. 4.-Investigación y diagnóstico del problema. 5.-Control del error. 6.-Identificación y registro del error. 7.-Evaluación del error. 8.-Registro de la resolución del error. 9.-Cierre del error. 22
  26. 26. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 10.-Vigilancia del progreso de la resolución. 11.-Asistencia en la tramitación de incidentes mayores. 12.-Prevención proactiva de problemas. 13.-Análisis de tendencias. 14.-Enfocar la actividad de apoyo. 15.-Suministro de información a la organización. 16.-Obtención de información sobre la gestión basado en los datos del problema. 17.-Realización de revisiones de problemas importantes. Control de problemas, seguimiento y monitorización del problema Identificación Clasificación Investigación y RFC (petición y registro del del problema diagnostico del de cambio) + problema problema resolución y cierre del probl. Cerrar Resolución el error y registro de Clasificación y Identificación problemas error apoyo inicial y registro del conocidos error Control de errores: seguimiento y monitorización de errores Fig.3.1.2: Descripción gestión de problemas. En la anterior figura quedan reflejados los sucesivos pasos enumerados anteriormente para la gestión de problemas. Consideraciones claves Los errores de software que se lancen en el entorno operacional deberán ser incorporados en la base de datos de errores conocidos para los servicios operacionales. Diferencias entre la gestión de incidentes y problemas Los procesos de gestión de incidentes y problemas tienen imperativos diferentes. La gestión de incidentes se concentra en la restauración del servicio al usuario de la empresa lo antes posible. La gestión de problemas se concentra en el establecimiento de las causas raíz de un incidente, y en su resolución y prevención subsiguientes. Estas metas a veces pueden provocar un conflicto de prioridades. Tareas Una buena gestión de problemas requiere un eficiente proceso de gestión de incidentes por lo tanto la gestión de problemas debe ser implementada en paralelo o inmediatamente después de la gestión 23
  27. 27. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 de incidentes. Si los recursos son escasos, deberá concentrarse en el control (reactivo) de problemas y errores dejando la gestión de problemas proactiva para más adelante cuando estén establecidas actividades de vigilancia de servicio y se hayan capturado datos de base. Enfocarse en algunos de los problemas claves que causan las peores inconvenientes para el negocio. La experiencia demuestra que el 20% de los Problemas causan el 80% de la degradación del servicio. Beneficios -Servicios de tecnologías de la información continuos y más estables. -Incremento de la productividad del usuario mediante la reducción del tiempo de indisponibilidad. -Mayor productividad del personal de soporte. -Prevención de errores. -Reducción de los efectos negativos al aprovechar los registros que documentan problemas a priori. -Mejorar la relación entre los usuarios y los servicios de tecnologías de la información mediante una mayor calidad de los mismos. -Mejor control de los servicios a través de una información de gestión mas adecuad. -Mejora de la tasa de soluciones en primera instancia del centro de servicio al usuario (CSU). Posibles problemas -Ausencia de un buen proceso de control de incidentes. -Falta de compromiso por parte de la dirección. -Debilitamiento del papel que desempeña el centro de servicio al usuario (CSU). -Tiempo y recursos insuficientes para crear y mantener la base de conocimientos. -Incapacidad para evaluar de manera precisa el impacto que tienen los incidentes y problemas sobre la empresa. Proceso de manejo de problemas El Objetivo de este proceso es prevenir y reducir al máximo los incidentes, y esto nos lleva a una reducción en el nivel de incidencia. Por otro lado nos ayuda a proporcionar soluciones rápidas y efectivas para asegurar el uso estructurado de recursos. En este proceso lo que se busca es que se pueda tener pleno control del problema, esto se logra dándole un seguimiento y una monitorización del problema. El diagrama de este proceso es muy particular, ya que se maneja en dos fases: la primera esta relacionada con lo que es el control del problema y la segunda es con el control del error. En lo que respecta a la fase de control del problema: primero se tiene que identificar el problema en base a alguna sintomatología; ya que se tiene este antecedente, se pasa a la clasificación de los problemas, en este proceso al igual que en el proceso de manejo de incidentes se tiene que ver si es un problema conocido, en caso de ser conocido, se recurre al procedimiento de solicitud de servicio, donde se van a aplicar las soluciones de acuerdo a como están en el manual de procedimientos; y en caso de no ser conocido se tendría que hacer una fase de investigación para ver que es lo que genera el problema para más tarde hacer un diagnostico; una vez se tenga un diagnóstico se tendrá que hacer un RFC (Request For Change o Solicitud de Cambio). 24
  28. 28. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 Esta solicitud de cambio implica que se va a tener que implementar la solución, finalmente se va a hacer una evaluación para ver si se resolvió el problema de raíz. En caso correcto esta solución se pasa a la documentación. Con lo que respecta a la segunda fase del modelo, el control del error se hace por medio de la identificación del error en general, posteriormente se hace un registro, este registro va a servir para clasificar el error; una vez se tiene la clasificación, se recurre a la evaluación del tipo de daño que se generó o que puede llegar a generar el error, esto con la finalidad de cuantificar los desperfectos que podría llegar a causar en caso de que el error prevalezca y no se solucione; posteriormente se hace la resolución o corrección del error. El error puede deberse a varios aspectos: configuraciones, falta de seguridad, inconsistencia de datos, etc. Este modelo tiene una fase difícil, que es determinar que problemas están asociados, se intenta identificar que problemas influyen indirectamente al resto del sistema, evitando así que se presentan inconsistencias. Las organizaciones dependen de forma creciente de los servicios de tecnologías de la información, ya que la información se ha convertido en uno de los recursos estratégicos más importantes. La inversión en tecnologías de la información crece pero, con frecuencia, los costes de tecnologías de la información son invisibles, lo que han provocado en parte la popularidad del outsourcing. Los procesos de negocio deben conducir las opciones tecnológicas, no estar a su merced, como ocurre con frecuencia. Y los procesos de de tecnologías de la información deben diseñarse con el objetivo de beneficiar el negocio. ITIL (Information Technology Infrastructure Library) es un conjunto de “mejores prácticas” recogidas en ocho libros. En conjunto, representan la experiencia colectiva de expertos a nivel mundial. El valor intrínseco de ITIL es la adopción de nuevos procesos, una nueva forma de hacer las cosas. Cambiar las prácticas de trabajo supone un reto mayor que el despliegue de software o hardware. Los proyectos de implantación de “mejores prácticas” son similares a ERP (“Enterprise Resource Planning”). Departamentos que han trabajado de forma aislada durante años tienen que adaptar sus procedimientos. El efecto que éstos tienen en el día a día de otros departamentos es evidente ya que sus procesos están ahora comunicados. La resistencia al cambio existe en todas las organizaciones, en mayor o menor medida. Cuando se aborda la implantación de ITIL en una empresa es necesario realizar una evaluación del volumen y ritmo de cambio que es razonable esperar en fases tempranas del proyecto. ITIL se está introduciendo rápidamente en España, centrado inicialmente en el sector financiero y operadores de telecomunicación, aunque también en la Administración Publica. Un caso destacable es la Generalitat de Catalunya. La rama española del itSMF (IT Service Management Forum) estima que la convergencia con Europa se producirá en el 2009. 25
  29. 29. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 La adopción de ITIL puede reportar enormes beneficios claramente mensurables: reducción de tiempos de indisponibilidad del servicio así como de costes y recursos innecesarios, mejora en estabilidad. Los plazos de ejecución suelen ser mayores de lo esperado, debido al cambio necesario en las prácticas de trabajo. El despliegue de las herramientas necesarias, si bien constituye un requisito, resulta de importancia secundaria. El tiempo y esfuerzo necesario para cambiar los procesos depende en gran medida de la cultura de la organización y de lo “flexible” que ésta sea al cambio. 3.1.6 El futuro de los Help Desks El término Help Desk probablemente ya no se encuentre en uso en el año 2010. Help Desk implica un acercamiento reactivo de soporte al cliente. Es común que cuando un cliente tiene un problema llame al Help Desk para conseguir ayuda, lo que por supuesto implica que el cliente tenía un tema específico. El Help Desk esperaba que el cliente lo contactara para ponerse en acción. En los últimos años se ha producido un cambio importante porque se pasó de ofrecer soporte reactivo a dar soporte preactivó. Para adaptarse a esta situación el término Help Desk está siendo reemplazado por el de Service Desk. El Service Desk moderno ofrece una gran variedad de servicios proactivos y reactivos. Por otro lado, ya no se lo considera un agregado de las tecnologías de la información sino que se lo comienza a reconocer y a operar como una unidad de negocios independiente. El support process managment suplantará a nuestra actual obsesión por la Administración de call tracking. En los últimos 5 - 10 años la administración de call tracking ha sido el foco de nuestra industria. Los proveedores de tecnología se han volcado de lleno al proceso de call tracking como algo que se presta con facilidad para la automatización de soluciones. Todavía existen muchos procesos de soporte que no están siendo dirigidos manual o automáticamente. Sin embargo estamos a la vera de adoptar por completo el support process managment. La depresión de la economía mundial ha sido el principal motivador y ha obligado a las empresas a concentrarse en mejorar los procesos por verse forzadas a hacer más con menos recursos. La disponibilidad de dominios públicos en marcos de trabajo de proceso, tales como ITIL (Information Techology Infrastructure Library), también están ayudando a transformar el servicio y el soporte de las tecnologías de información. Este nuevo foco sobre la administración completa de procesos del negocio llama a que los proveedores suministren soluciones de proceso más completas. Ya existen nuevas soluciones tecnológicas que se centran en la administración completa de procesos del negocio que van más allá de lo que hemos visto con respecto a las soluciones tecnológicas para nuestro mercado. Estas nuevas soluciones serán capaces de acomodar todos los procesos de servicio y de soporte al cliente y podrán ofrecer colaboración en los procesos de operación del negocio a toda la empresa como así también a los clientes tanto internos como externos. 26
  30. 30. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 Las habilidades de los empleados de soporte seguirán madurando. Mientras nosotros continuaremos poniendo el foco en los procesos de soporte y las opciones de automatización y el self service siga eliminando las tareas repetitivas y de bajo nivel del área de soporte, el rol del personal de soporte continuará madurando. En el futuro el personal de soporte tendrá habilidades para analizar la base de la causa, versus la resolución de síntomas. Se los alentará a dar soluciones de soporte proactivas, conocimiento accesible al usuario y a asegurar continuidad en el negocio versus respuestas reactivas y procedimientos de recuperación del negocio. El foco de la actividad de soporte será anticiparse a los requerimientos del cliente versus esperar para resolver los problemas de los mismos. 27
  31. 31. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 3. - Estado del Arte 20/03/07 3.2. ESTADO DEL ARTE. ESTUDIO DE LA COMPETENCIA Dentro del Estado del Arte reflejar como está el panorama actual es uno de los motivos principales de este estudio, además de conseguir detectar las carencias y fortalezas de nuestra competencia. Esto condicionará nuestras posibilidades de éxito. A continuación se realizará un listado y una descripción de las aplicaciones que se han encontrado relacionadas con el sector: 3.2.1 Aplicación GIGLOBAL SUPPORT Fig.3.2.1: Logo Aplicación Giglobal Support La primera de las aplicaciones que se quiere destacar es la de la empresa GIGLOBAL SUPPORT que ha desarrollado un gestor de incidencias para unidades de soporte y atención a clientes vía teléfono, fax, e-mail o web. Esta empresa ofrece poder acceder vía web a todas las consultas que hacen los clientes de forma ordenada, además también se puede ver el estado actual del proceso o seguir paso a paso el desarrollo de la incidencia hasta la resolución final, visualizando fechas, responsables de las tareas y tiempos de dedicación. Ofrece la posibilidad de que los clientes puedan realizar consultas vía web, de esta forma se conseguirá que los técnicos de la empresa trabajen de forma ordenada y controlada. También se podrá facilitar el acceso de los usuarios a incidencias de otros clientes a modo de "preguntas frecuentes", pudiendo ofrecerlo como una "garantía de soporte" en sus productos.Las incidencias se resuelven una vez y luego el “conocimiento” se reutiliza. Como Gestor de Incidencias de Soporte el sistema cuenta con las siguientes Fortalezas: -Totalmente vía web. Tanto el sistema se administración como el Portal de Soporte generado se acceden a través de una pantalla del explorador de internet sin necesidad de instalaciones ni descargas en el disco duro local. -Diseño gráfico propio o a elección, ofrece una galería de plantillas. Para la creación de su Portal de Soporte puede utilizar las plantillas gráficas que ponemos a su disposición o crear un formato gráfico personalizado por usted mismo. El aspecto gráfico se integra a su imagen corporativa de forma flexible. -Gestión de usuarios. Tanto alta como baja de usuario. Desde la Aplicación se podrá dar de alta a "empresas clientes" y dentro de cada empresa "personas de contacto" para identificarlos como responsables del ingreso de cada incidencia. También se podrá habilitar "personal de soporte" asociado a determinados "departamentos" y relacionarlos a determinados "productos" para identificarlos como responsables de producto. 26
  32. 32. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 3. - Estado del Arte 20/03/07 -Control de Acceso por Usuarios. Gestión de la navegación y administración. Se podrá definir "clientes" con acceso a gestionar sus incidencias y también "administradores" que podrán editar la configuración del propio sistema. -Se permite el registro de incidencias. A través de una interfaz web se ingresa y consulta información sobre incidencias registradas. Consultas por personal encargado de atender la solicitud, incidencias pendientes de respuesta, acciones realizadas sobre dicha incidencia, alta de nuevas incidencias, definición, origen y marcaje de prioridades. -Se ofrece la Gestión del Conocimiento. Las incidencias se almacenan en la base de datos, lo que hace natural la consulta de incidencias similares antes de abordar la resolución de una nueva optimizando tiempos y facilitando la incorporación de gente poco experta a la actividad de soporte. -Gestión de acciones a realizar tras el registro de una incidencia. Se permite la identificación / tipificación para su asociación a otras existentes, definición de tareas a realizar (por comprobación/reproducción del problema reportado), generación de la documentación pertinente (e-mail) a proveedor y/o cliente y registro del tiempo empleado en solventar cada incidencia (de suma importancia para el control de costes internos del personal de la unidad de trabajo). -Realización de estadísticas. Desde la aplicación se podrá realizar estadisticas por tipo de consulta y de tiempos por cliente o usuario. - Posibilidad de búsqueda contextual. Se podrá realizar una búsqueda contextual sobre toda la información almacenada. Ello permite encontrar respuesta a consultas ya realizadas y contestadas en su día, con independencia de a quién se diera el servicio y con la finalidad de optimizar tareas redundantes. -Uso del Interfaz web. Para el personal y para el usuario de soporte. Al personal de soporte le permite resolver incidencias y administrar las entidades básicas desde cualquier ordenador sin ningún requerimiento especial. A los usuarios les permite crear incidencias, aportar información, darlas por resueltas, ver el estado de la incidencia o buscar en la base de datos de incidencias. 3.2.2 Aplicación Demo HelpDesk Aplicación realizada en PHP [DEMHEL01] De esta aplicación hemos capturado como representativa la siguiente imagen en la que se muestra un listado de las incidencias, por los campos ID, Fecha y Hora, Nombre, Apellidos, Prioridad. 27
  33. 33. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 3. - Estado del Arte 20/03/07 Fig.3.2.2: Aplicación Demo HelpDesk Diseño sencillo, colores azules, menú de navegación en el lateral izquierdo clasificado en dos bloques Acciones normales y Control del helpdesk. En el primer bloque tenemos: cambio de password, Crear un Informe, Abrir una pregunta, gestionar la configuración del helpdesk, base de conocimiento, ver preguntas activas, ver todas las preguntas, ver sólo las preguntas asignadas, salir. En el segundo bloque tenemos Gestionar las prioridades de las llamadas, Gestionar los estados de las llamadas, Gestionar las Categorías de las llamadas, Gestionar las Reglas de los emails, gestionar los Ficheros subidos. 3.2.3 Aplicación HELP DESK PRO DE AQCENTUS CORPORATION Inc. Aplicación realizada en Java [HELDES01] 28
  34. 34. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 3. - Estado del Arte 20/03/07 Fig.3.2.3: Aplicación HELP DESK PRO DE AQCENTUS CORPORATION Inc De esta aplicación hemos capturado como representativa la siguiente imagen (fig.3.2.3) en la que se muestra un listado de Incidencias con los siguientes campos ID, Fecha, Nombre, Categoría, Prioridad, Estado, Descripción, Técnico. A la izquierda, tenemos en un solo vistazo, las incidencias que están sin resolver, cuales están resueltas, todas ellas llevan un totalizado de las incidencias. Además podemos ver todas las FAQ´s, buscar una FAQ´s, añadir una nueva FAQ´s. 3.2.4 Aplicación Centro de Asistencia NAVIGATOR Aplicación realizada en php [NAVNET01] Fig.3.2.4: Aplicación Centro de Asistencia NAVIGATOR 29
  35. 35. Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 3. - Estado del Arte 20/03/07 En la anterior imagen (fig.3.2.4) se nos muestra la página principal con las 6 secciones principales muy claras en un solo vistazo. Estas seis secciones también se encuentran en el pie de la página. La información principal de la aplicación se encuentra representada por seis iconos. Las secciones son: Registrar, Enviar Ticket, Base de Conocimiento, Solucionador de problemas, Noticias y Descargas. En el panel central además nos encontramos con un listado de 4 items de los últimos artículos de la Base de Conocimiento. Se resalta además en este mismo panel la categoría más popular con el numero de visitas realizadas. El diseño en tonalidades de azul. En el panel de la derecha tenemos un buscador, además una sección con las 5 últimas noticias. En este mismo panel tenemos el panel de acceso de los usuarios. 3.2.5 Aplicación Centro de Asistencia ISOLSOFT Aplicación realizada en PHP [ISOSOL01] Fig.3.2.5: Aplicación Centro de Asistencia ISOLSOFT En la imagen (fig.3.2.5) se nos muestra la página principal con las 4 secciones principales muy claras en un solo vistazo. Las cuatro secciones son: Nuevo ticket, suscríbase, Base de Conocimientos y Descargas. Las cuatro secciones vienen acompañadas de un icono representativo. Estas cuatro secciones también se encuentran en un panel superior horizontal de color naranja destacando sobre el resto. En el panel de la izquierda tenemos un panel de acceso a la aplicación. Además tenemos la posibilidad de ver un ticket indicando la dirección de correo y el identificador del item. Se usan tonalidades azules. 30

×