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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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