Este documento presenta un proyecto de desarrollo e implementación de un centro de asistencia siguiendo la metodología ITIL. El proyecto analiza el estado del arte de los centros de asistencia, compara diferentes aplicaciones, diseña una base de datos y la interfaz web. El objetivo es mejorar la gestión de incidencias en una universidad mediante la incorporación de mejores prácticas y el registro y seguimiento de problemas para mejorar la calidad del servicio.

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

36. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 3. - Estado del Arte 20/03/07
Fig.3.2.6: Listado de incidencias.
En la anterior imagen (fig.3.2.6) se nos muestra un listado de incidencias con los siguientes
campos ID, Titulo, Categoría, Estado, Prioridad, Abierto Por, Última modificación por, Fecha y
Hora.
Fig.3.2.7: Pantalla de búsqueda sobre la base de conocimiento.
En la anterior imagen (fig.3.2.7) se nos muestra la pantalla de búsqueda sobre la base de
conocimiento (KB) clasificada por Categorías.
31

37. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 3. - Estado del Arte 20/03/07
Fig.3.2.8: Listado de incidencias.
En la anterior imagen (fig.3.2.8) además de mostrarnos un listado de Incidencias con los
siguientes campos ID, Titulo, Categoría, Estado, Prioridad, Abierto Por, Última modificación
por, Fecha y Hora vemos que utiliza iconos para indicar el Estado y la prioridad.
Además destacar que podemos listar por el estado de los tickets.
Fig.3.2.9: Formulario de datos de un item/ticket.
32

38. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 3. - Estado del Arte 20/03/07
A continuación se nos muestra los campos editables dentro de un (item-ticket). Los campos que
se visualizan son: Tema, Tiempo abierta, Copia Carbon del email, Prioridad, Emergencia,
Tiempo esperando, Estado, IP, Equipo Staff, Categoría.
3.2.6 Aplicación Centro de Asistencia PERL DESK
Aplicación realizada en PERL [PERDES01]
Fig.3.2.10: Aplicación Centro de Asistencia PERL DESK.
En la siguiente imagen (fig.3.2.10) se muestra la página principal con las 7 secciones principales
muy claras en un solo vistazo: Registro, Nueva Pregunta, Artículos, Estado de la petición,
Descargas, Chat, Skype y además en el panel inferior se observa un listado de los
conversaciones más recientes, artículos más populares.
33

39. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 3. - Estado del Arte 20/03/07
Fig.3.2.11: Formulario Item/ticket
A continuación se nos muestra los campos editables dentro de un (item/ticket):
Nombre, Email, Categoría, Prioridad por Colores, Titulo, Descripción y Archivo.
Fig.3.2.12: Listado de incidencias
34

40. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 3. - Estado del Arte 20/03/07
En la anterior imagen (fig.3.2.12) además de mostrarnos un listado de incidencias con los
siguientes campos ID, Titulo, Propietario, Estado, Cuando ha entrado por última vez, Última
modificación por, vemos que utiliza iconos para indicar el Estado y la prioridad.
Destacar que en todo momento no perdemos de vista el menú superior con las 6 secciones
principales.
3.2.7 Aplicación Centro de Asistencia CRM DESK
Disponible en [CRMDES01]
En la imagen siguiente (fig.3.2.13) se nos muestra la pantalla principal donde la información
queda organizada en cinco pestañas: Inicio, Base de conocimientos, Preguntas, Clientes,
Informes y Configuración.
En esta imagen se observa todos los ítems, cuales están abiertos y cuantos están cerrados,
quienes son los que han generado los ítems, que ítems están asignados, etc..
Fig.3.2.13: Aplicación Centro de Asistencia CRM DESK.
En la siguiente imagen (fig.3.2.14) se nos muestra la pantalla de búsqueda sobre la base de
conocimiento (KB) –Frequent Asked Question FAQ , clasificada por Categorías (producto)
ordenar por fecha de actualización.
35

41. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 3. - Estado del Arte 20/03/07
Fig.3.2.14: Búsqueda en la Base de Conocimientos.
3.2.8 Aplicación Centro de Asistencia jitbit Helpdesk
Desarrollado en ASP .NET . Disponible en [JITBIT01]
Fig.3.2.15: Aplicación Centro de Asistencia jitbit Helpdesk
En la imagen anterior (fig.3.2.15) destacamos en el panel central la información clasificada por
pestañas. Se observan cuatro secciones principales: inicio, Mis ítems, todos los ítems sin cerrar
y la Base de conocimientos.
Además dentro de ese mismo panel central tenemos el listado de ítems, el cual se puede
clasificar por: ítems sin cerrar, ítems sin cerrar asignado al administrador y todos los items.
Dentro de ese mismo listado tenemos un icono indicando que ese item es nuevo.
En el panel de la derecho tenemos la información clasificada por categorías, además se puede
observar entre paréntesis el numero de ítems asociado a cada una de las categorías.
36

42. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 3. - Estado del Arte 20/03/07
3.2.9 Aplicación Centro de Asistencia SERVICE DESK
Desarrollado en JAVA [SERDES01]
Fig.3.2.16: Aplicación Centro de Asistencia SERVICE DESK
ServiceDesk Plus es una solución de Service Desk y Gestión de Inventario. Ofrece un paquete
integrado con la gestión de incidencias, inventario automático, gestión de activos, compras,
gestión de contratos, portal de autoservicio para usuarios finales y gestión de conocimientos,
todo ello a un precio muy competitivo. ServiceDesk Plus incluye todo lo que necesita para
gestionar sus procesos de informática interna, lo cual redunda en mayor productividad y mejor
servicio para usuarios finales.
Una solución robusta y fácil de usar, que ayuda a las organizaciones a automatizar y mejorar sus
procesos de soporte y gestión, resultando en un soporte coherente, fiable y superior, tanto para
clientes internos como externos.
Gracias al portal de autoservicio se reduce el volumen de llamadas a su centro de atención de
usuarios, a través de un portal Web que permite a los usuarios buscar en la base de
conocimientos, introducir una nueva incidencia o solicitud, comprobar el estado de sus
peticiones existentes.
La base de conocimientos otorga a los técnicos de soporte con un fácil acceso a las respuestas, a
través de una base de conocimientos que permite organizar los conocimientos de la empresa,
realizar búsquedas y encontrar respuestas en un tiempo récord.
La gestión de los niveles de servicio mejora la calidad de servicio a través de la definición de
niveles de servicio (SLAs). Este potente módulo permite definir, aplicar, monitorizar y cumplir
con los niveles de servicio y procesos de escalación.
37

43. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 3. - Estado del Arte 20/03/07
Otro de los factores ha destacar es la gestión de activos e inventario. El inventario automático de
red sin necesidad de instalar agentes, compatible tanto para máquinas windows como linux.
Gestión completa de los activos de inventario.
Además permite realizar el seguimiento de licencias de software, utilización de aplicaciones,
violaciones de acuerdos de licencia. Minimice sus costes de software al adquirir únicamente lo
que realmente necesita.
Permite el seguimiento y gestión de pedidos de compra, teniendo control total de los procesos
de compra. Este módulo permite hacer el seguimiento del estado del pedido en todo momento y
una vez recibido el material, se integra con el módulo de gestión de inventario.
Permite crear y gestionar una lista completa de todos los activos y tipos de producto que su
organización posee, así como el seguimiento detallado de cada artículo.
Permite hacer seguimiento de todos sus contratos de soporte, mantenimiento, leasing, etc.
incluyendo avisos y notificaciones cuando el contrato está cerca de su fecha de renovación.
ServiceDesk Plus incluye un módulo completo de informes, con variedad de informes
preconfigurados y la posibilidad de generar informes a medida.
En la Pantalla principal de la aplicación, tenemos dos opciones, una entrar como técnico
(personal) o entrar como generador del incidente.
Fig.3.2.17: Posibilidad de listados.
En la imagen anterior (fig.3.2.17) destacamos la posibilidad de realizar los distintos listados:
Solicitudes no asignadas, Mis solicitudes abiertas, Mis solicitudes vencidas, Mis solicitudes
pendientes, Mis solicitudes que vencen hoy, Mis solicitudes completadas, Todas las solicitudes.
38

44. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 3. - Estado del Arte 20/03/07
La información está clasificada por nueve pestañas: Inicio, Solicitudes, Soluciones, Inventario,
Comprar, Contratos, admin., Informes y Soporte.
Fig.3.2.18: Búsqueda sobre la base de conocimiento.
En la siguiente imagen (fig.3.2.18) se nos muestra la pantalla de búsqueda sobre la base de
conocimiento (KB) – FAQ, clasificada por Áreas.
Además tenemos un listado de los últimos artículos de la Base de Conocimiento y de las más
populares.
A la derecha tenemos una sección de creación rápida de una incidencia. Con los campos nombre
del cliente, titulo de la solicitud y descripción.
En la siguiente imagen (fig.3.2.19) se nos muestra un listado de todos los posibles informes que
se pueden generar: Solicitudes por Grupo, Solicitudes por fecha de creación, Solicitudes por
departamento, Solicitudes por vencimiento, Solicitudes por nivel, Solicitudes por prioridad,
Solicitudes por estado, Solicitudes por técnico y Estado de las solicitudes por nivel.
39

45. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 3. - Estado del Arte 20/03/07
Fig.3.2.19: Listado de informes
3.2.10 CUADRO COMPARATIVO
El objetivo de esta sección es la establecer que ventajas y que deficiencias se han encontrado a
cada una de las aplicaciones que se han encontrado. La comparativa se ha dividido en cinco
secciones: funcionalidad, extras, mantenimiento, diseño e interfaz de publicación.
De todas formas no conviene olvidar la misión de todo Help Desk, el cual se dedica a
proporcionar soporte de excelencia, usando tecnologías de información para ayudar a nuestros
usuarios a resolver sus necesidades cotidianas y cumplir con sus metas a largo plazo. Mejora
continuamente los servicios solicitando feedback a los usuarios e implementando avances
tecnológicos para mejorar los servicios a la comunidad.
La misión del Help Desk es proporcionar a los empleados de nuestra empresa de un único punto
de contacto para proporcionar el acceso a los niveles apropiados de los servicios de informática
y redes y proveer de soporte técnico esencial para utilizar estos servicios mencionados de una
manera eficiente y eficaz.
El Help Desk proporciona un único punto de contacto para todos los usuarios de servicios de
informática, respondiendo a las preguntas y problemas relacionados directamente con el
software y hardware soportados. El Help Desk resuelve la cuestión del requerimiento y procura
ayudar al usuario a maximizar el uso de sus aplicaciones o equipamiento, o deriva la llamada al
personal apropiado. El Help Desk asiste en la notificación de tendencias y de situaciones que le
permitan a la Gerencia de las tecnologías de la información mantener altos niveles del servicio a
la comunidad de usuarios"
40

46. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 3. - Estado del Arte 20/03/07
La misión del Help Desk es proporcionar asistencia técnica a los empleados de la compañía,
apoyándolos en su propio cumplimiento de la misión de la empresa. Contestamos a preguntas,
ofrecemos una instrucción informal, proporcionamos una resolución de primer nivel de
problemas y manejamos el escalamiento de temas a los especialistas de IT. Mejoramos
continuamente nuestros servicios practicando y promoviendo el trabajo en equipo, la
comunicación clara, y comprometiéndonos a mejorar nuestras capacidades técnicas y
profesionales.
GIGLOB JITBIT
PRO DE NAVIGATO ISOLSOF PERL CRM SERVICE
AL HELPDESK HELPDE
Funcionalidad AQCENTUS R T DESK DESK
SK
DESK
Gestión estados, No
No Si Si Si Si Si Si Si
Prioridades
No
Gestión Categorías Si Si Si Si Si Si Si Si
Gestión No
Si Si Si Si Si Si Si Si
Subcategorias
Gestión Personal No
Si Si Si Si Si Si Si Si
Resolución
No
Listados Estadísticas Si Si Si Si Si Si Si Si
Creación rápida No
Si Si Si Si Si Si Si Si
Item
Si
Identificación (login) Si Si Si Si Si Si Si Si
Búsquedas Si
No Si Si Si Si Si Si Si
Buscador general
Enviar
Si Si Si Si Si Si Si Si Si
email/imprimir
GIGLOB PRO DE JITBIT
NAVIGAT ISOLSO PERL CRM SERVIC
AL HELPDESK AQCENTU HELPD
Extras OR FT DESK DESK E DESK
S ESK
No
Acercamiento a ITIL Si Si Si Si Si Si No Si
RSS No No Si Si Si Si No No Si
Uso Skype No No Si No No Si No No No
GIGLOB PRO DE JITBIT
NAVIGAT ISOLSO PERL CRM SERVIC
AL HELPDESK AQCENTU HELPD
Mantenimiento OR FT DESK DESK E DESK
S ESK
No
Logs No Si Si Si Si No No No
Base de Estáticos
Base
Los datos se guardan datos Base de Base de Base de Base de o Base de
Base de datos de
en datos datos datos datos dinámico datos
datos
s
41

47. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 3. - Estado del Arte 20/03/07
GIGLOB PRO DE JITBIT
NAVIGAT ISOLSO PERL CRM SERVIC
AL HELPDESK AQCENTU HELPD
Diseño OR FT DESK DESK E DESK
S ESK
Si
Utilización de iconos No No Si No Si Si Si Si
Si
Uso de estilos CSS Si Si Si Si Si Si Si Si
Menú navegación Si
Si Si Si Si Si Si Si Si
siempre visible
No
Mapa del Sitio No No No No No No No No
Listado documentos Si
No No Si Si Si Si Si Si
relevantes
Si
Migas de pan No No No No No No No No
Si
Cabecera y Pie Si Si Si Si Si Si Si Si
No
Animaciones en Flash No No No No No No No No
GIGLOB PRO DE JITBIT
NAVIGAT ISOLSO PERL CRM SERVIC
Interfaz de AL HELPDESK AQCENTU HELPD
OR FT DESK DESK E DESK
publicación S ESK
Niveles de usuarios No No No Si Si Si Si Si Si
Subir ficheros No No No Si Si Si Si Si Si
Editar textos No No No Si Si Si Si Si Si
Filtros de busqueda
Si Si Si Si Si Si Si Si Si
para la edición
ASP.N ASP.NE
Lenguaje desarrollo PHP PHP JAVA PHP PHP PERL JAVA
ET T
42

48. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 4. Diseño Base de Datos 20/03/07
CAPÍTULO 4
4.1 Base de Datos Centro de Asistencia CEU-UCH:
Una base de datos es una colección de datos estructurados según un modelo que refleje las
relaciones y restricciones existentes en el mundo real. Los datos, que han de ser compartidos por
diferentes usuarios y aplicaciones, deben mantenerse independientes de éstas, y su definición y
descripción han de ser únicas estando almacenadas junto a los mismos. Por último, los
tratamientos que sufran estos datos tendrán que conservar la integridad y seguridad de éstos.
Las ventajas de tener una base de datos son muchas. Para empezar necesitamos de un recipiente
donde poder almacenar nuestras incidencias. Si almacenamos la información correctamente
luego conseguiremos interpretarla y recuperarla de forma eficiente, convirtiéndose con el
tiempo en nuestra base de conocimiento (knowledge base).
En esta base de datos se almacenarán todas las incidencias que se producen en un entorno
universitario. La principal ventaja que se obtiene es que se podrá registrar la incidencia: quién
informa del problema, síntomas, equipo involucrado, además de conseguir tener la solución
pertinente de esa incidencia.
Otra de las ventajas es que, al disponer de una base de datos, se podrán realizar múltiples
informes, que ayuden a conocer qué está sucediendo y a mejorar el proceso.
El centro de asistencia que se desea implementar necesitará de una base de datos de dimensión
media, por lo que tanto el gestor como el diseño de la base de datos serán de gran importancia.
Aunque la base de datos deba soportar todo tipo de operación básica (crear, modificar,...) será la
consulta la operación que con mayor frecuencia se realice, por lo que se deberá agilizar dicha
operación.
4.2. Nivel del diseño de la Base de Datos
A continuación se pasa a detallar el diseño de la base de datos de nuestro Help Desk. Una vez
expuesto el diseño veremos los procedimientos almacenados implementados sobre SQL Server
que tratan esos datos.
Con el desarrollo de la base de datos se pretende obtener, por medio de una abstracción del
mundo real, un conjunto de datos y un conjunto de operaciones sobre ellos que permitan
satisfacer las necesidades de la organización. Para el desarrollo de este documento se ha divido
en tres fases que se presentan a continuación:
1) Análisis de Requerimientos.
2) Diseño Conceptual.
3) Diseño Lógico.
4) Diagrama UML.
4.2.1) Análisis Requerimientos
En este apartado se presenta una visión del sistema de información desde un punto de vista
organizativo independiente del sistema de gestión de bases de datos que se utilice e incluso de
que se utilice o no una base de datos. En este esquema se describe la información y funciones de
la organización desde un punto de vista no informático.
43

49. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 4. Diseño Base de Datos 20/03/07
Este análisis tiene como objetivo “descubrir” el conjunto de requerimientos de información por
una parte, y de proceso por otra, que la organización necesita para cumplir sus fines.
Empezando a describir el análisis de requerimientos lo primero que se necesitará es poder
almacenar las áreas, de las cuales guardaremos el nombre (AREA_Titulo) y el orden en el que
queremos que aparezca (AREA_Orden).
De las subareas necesitaremos almacenar el nombre (SAREA_Titulo), el orden en el que
queremos que aparezca (SAREA_Orden) y ademas el área a la que pertenece
(SAREA_AREA_ID), por último se tendrá un campo que se ha llamado parámetros por si se
necesita tener un trato especial pasándole parámetros (SAREA_Parametros).
Además se necesitará poder guardar una incidencia, los campos que se deberán poder almacenar
son el código de la incidencia (INC_Cod), el nombre de la incidencia (INC_Titulo), la
prioridad que se considere que se le asigna a esa incidencia (INC_Prioridad) y además la
incidencia estará relacionada con una subarea (INC_SAREA_ID).
Cada una de las incidencias tendrá asignada una persona para su resolución
(INC_REL_PER_PER_ID). Donde una persona podrá estar asociada a más de una incidencia.
Habrán tres niveles definidos de resolución (INC_REL_PER_Nivel), y cada nivel tendrá un
tiempo definido (INC_REL_PER_Tiempo).
Se quiere poder almacenar los diferentes ítems que se generen. Los campos que se desean
registrar son el nombre del item (ITEM_Titulo), la descripción del ítem generado
(ITEM_Descripcion), la resolución asociada de ese ítem si es que la tiene
(ITEM_Resolucion), que luego además nos servirá para listar las Frequent Asked Questions
(FAQ’s), se almacenará también la fecha en la que se generó el ítem (ITEM_FechaIni) y la
fecha en la que se resolvió el ítem si es que ha sido resuelta (ITEM_FechaFin) en el caso de no
ser resuelta su valor será nulo, además el ítem estará relacionado con un tipo de incidencia
concreta (ITEM_INC_ID) ya comentado anteriormente, el ítem tendrá un estado que podrá ser
resuelto, pendiente, cancelado, etc (INC_EST_ID), en cualquier caso se podrán añadir estados
nuevos según la necesidad del usuario, además se registrará la persona que debe resolver la
incidencia la cual ira cambiando según el tiempo y el nivel que se le haya asignado
(ITEM_PER_ID), también se registrará el alumno que ha generado el ítem (ITEM_ALU_ID),
con esto se conseguirá poder uso de las estadísticas y saber que alumnos por carreras generan
más incidencias, y por último se necesitará un campo para contabilizar el numero de visitas
realizadas a ese ítem.
De los estados que pueden tener un ítem, se guardará el nombre del estado (EST_Nombre).
Además de cada uno de los ítems se podrá tener varios enlaces y archivos relacionados,
teniendo en cuenta que estos a su vez podrán estar relacionados a más de un ítem.
De los archivos almacenamos se quiere poder guardar la descripción del archivo almacenado
(ARC_Descripcion), el nombre que se le quiere asignar al archivo (ARC_Titulo), el nombre
físico del archivo (ARC_NombreFisico), la dirección url donde está almacenado el archivo
(ARC_Url), la dirección IP de la persona que ha subido el archivo (ARC_IP), y la fecha en la
que fue guardado el archivo (ARC_Fecha).
De los enlaces almacenados se quiere poder guardar el nombre que se le quiere asignar al enlace
(ENL_Titulo), la descripción del enlace almacenado (ENL_Descripcion), la dirección url del
enlace (ENL_Url) y la fecha en la que fue guardado el enlace (ENL_Fecha).
44

50. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 4. Diseño Base de Datos 20/03/07
De los alumnos guardaremos los datos básicos tales como el código del alumno (ALU_Cod), el
identificador del alumno (ALU_Identificador), el nombre del alumno (ALU_Nombre), los
apellidos (ALU_Apellidos), la titulación a la que pertenece (ALU_TIT_ID), además las
titulaciones estarán clasificadas por centros, el email (ALU_Email) y el teléfono
(ALU_Telefono).
Del personal almacenaremos el nombre (PER_Nombre), los apellidos (PER_Apellidos), el dni
(PER_DNI), el código de personal (PER_PERSONAL_ID), la titulación asignada de
resolución para dicha persona (PER_TIT_ID) y el email de esa persona (PER_Email).
A continuación se comentará que campos y que restricciones se deben cumplir para que la base
de datos desarrollada se adapte a la metodología ITIL.
Por una parte se necesitará poder definir los estados de los ítems generados, de esta forma se
podrán definir estados nuevos, por ejemplo: cancelado, resuelto, en espera, etc. Con esto además
se conseguirá detectar rápidamente el estado de cada uno de los ítems.
Además se deberá poder asignar el personal de resolución de cada una de las incidencias. La
resolución de cada una de las incidencias deberá estar jerarquizada por niveles. Cada uno de los
niveles de resolución deberá tener un tiempo limite de permanencia en ese nivel, por ejemplo:
24 horas, 48 horas, 64 horas, etc. A las incidencias a su vez se les podrá asignar una prioridad
dependiendo del nivel de urgencia que dicha incidencia tenga.
Los ítems generados deberán estar debidamente clasificados. Los documentos generados
deberán poder servir de manuales de uso para los usuarios finales. Todas las incidencias deberán
estar debidamente tipificadas y con el personal de resolución correctamente asignado.
4.2.2) Diseño Conceptual
Esta parte de estudio comprende gran parte de análisis, tiene como objetivo obtener una
representación de la realidad que capture las propiedades estáticas y dinámicas de la misma
necesarias para satisfacer los requerimientos recogidos en la actividad anterior. En este proceso
se debe aprehender y conceptualizar el mundo exterior transformándolo en un conjunto de ideas
y definiciones que supongan una imagen fiel del comportamiento del mundo real. Esta imagen
de la realidad se denomina esquema conceptual.
A continuación se presenta el esquema conceptual obtenido, en la siguiente figura podemos
observar el diagrama entidad-relación de la parte principal de la base de datos. Como se puede
apreciar no es una base de datos complicada por lo que solo cabe destacar unos pequeños
puntos. La relación resuelve entre items y persona se le ha añadido un par de atributos
necesarios para cumplir los requisitos de la aplicación, el campo nivel y el campo tiempo
asignado, además del hecho de que es una relación muchos a muchos. Por otro lado también
resaltar la relación muchos a muchos de los enlaces, categoría, archivos y avisos con la tabla
ítems.
El diseño conceptual lo hemos realizado con la herramienta Microsoft Visio, la cual tiene un
modulo especial para el dibujo de base de datos el cual te permite representar las diferentes
entidades y relaciones que se necesitan.
45

51. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 4. Diseño Base de Datos 20/03/07
Fig. 4.1 Diseño conceptual utilizando el modelo Entidad Relación
4.2.3) Diseño lógico
El diseño lógico consiste en transformar el esquema conceptual que se encuentra descrito
usando un cierto modelo de datos, a estructuras y transacciones descritas en términos del
modelo de datos en el cual se base el sistema de gestión de bases de datos que se vaya a utilizar.
Ya que el modelo de datos elegido es el modelo relacional, se deberá realizar este proceso para
obtener finalmente un esquema relacional y un conjunto de transacciones sobre las relaciones de
este esquema. Este proceso se dividirá en dos fases:
1) Transformación de los aspectos estáticos del esquema conceptual: para ello se verá cómo es
posible transformar cada una de las estructuras de un diagrama Entidad-Relación, modelo
utilizado en el diseño conceptual, a relaciones. Esta transformación dará lugar a un primer
esquema relacional.
Además, se estudiará la teoría de la normalización, que permite refinar este primer esquema
relacional, obteniendo un esquema relacional adecuado, desde el punto de vista de su
manipulación.
2) Transformación de los aspectos dinámicos del esquema conceptual: para ello se verá cómo se
obtienen transacciones sobre las relaciones del esquema relacional a partir de las transacciones
del esquema conceptual.
A continuación se presenta el diseño lógico realizado, aquí se listan los atributos que se
consideran necesarios y que no se han incluido en el diagrama entidad-relación con objeto
hacerlo más legible. Estos atributos son muy importantes ya que, al pasar del modelo entidad-
relación a la representación final de la base de datos, se convierten en los campos de las tablas:
46

52. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 4. Diseño Base de Datos 20/03/07
WEB_CENTROASISTENCIA_Area:
AREA_Id: int
AREA_Titulo:nvarchar
AREA_Orden: int
CP:{AREA_ID}
VNN: {AREA_Titulo }
WEB_CENTROASISTENCIA_SubArea:
SAREA_Id: int
SAREA_Titulo: nvarchar
SAREA_AREA_ID: int
SAREA_Parametros: nvarchar (1000)
CP:{SAREA_ID}
C.Aj: {SAREA_AREA_ID }→Area
VNN: {AREA_Titulo,SAREA_AREA_ID}
WEB_CENTROASISTENCIA_Incidencia:
INC_Id: int
INC_COD: int
INC_Titulo: nvarchar
INC_SAREA_ID: int
CP: {INC_ID}
C.Aj: {INC_SAREA_ID }→SubArea
VNN: {INC_Titulo, INC_SAREA_ID}
WEB_CENTROASISTENCIA_Item:
ITEM_Id: int
ITEM_Titulo: Título
ITEM_Descripcion: nvarchar (4000)
ITEM_Resolucion: nvarchar (4000)
FechaIni: datetime NOT NULL,
FechaFin: datetime NULL,
ITEM_INC_ID:int
ITEM_PER_ID: int NULL
ITEM_ALUMNO_ID: int NOT NULL
ITEM_EST_ID: int NOT NULL
CP:{ITEM_ID}
C.Aj: {ITEM_INC_ID }→ Incidencia
C.Aj: {ITEM_PER_ID }→Personal
C.Aj: {ITEM_ALUMNO_ID }→ Alumno
C.Aj: {ITEM_EST_ID }→ Estado
VNN: {ITEM_INC_ID, ITEM_FechaIni, ITEM_EST_ID}
47

53. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 4. Diseño Base de Datos 20/03/07
WEB_CENTROASISTENCIA_Aviso:
AVIS_Id int,
AVIS_Descripcion nvarchar (500)
AVIS_Fecha datetime
CP: { AVIS_ID}
VNN: { AVIS_Descripcion, AVIS_Fecha}
WEB_CENTROASISTENCIA_ITEM_REL_ARC:
ITEM_REL_ARC_ID int
ITEM_REL_ARC_ITEM_ID int
ITEM_REL_ARC_ARC_ID int
CP:{ ITEM_REL_ARC_ID }
C.Aj: { ITEM_REL_ARC_ITEM_ID }→ Item
C.Aj: { ITEM_REL_ARC_ARC_ID }→ Archivo
VNN: { ITEM_REL_ARC_ITEM_ID, ITEM_REL_ARC_ARC_ID }
WEB_CENTROASISTENCIA_ITEM_REL_ENL:
ITEM_REL_ENL_ID int
ITEM_REL_ENL_ITEM_ID int
ITEM_REL_ENL_ENL_ID int
CP:{ ITEM_REL_ENL_ID }
C.Aj: { ITEM_REL_ENL_ITEM_ID }→ Item
C.Aj: { ITEM_REL_ENL_ENL_ID }→ Enlace
VNN: { ITEM_REL_ENL_ITEM_ID, ITEM_REL_ENL_ENL_ID }
WEB_CENTROASISTENCIA_ITEM_REL_CAT:
ITEM_REL_CAT_Id int ,
ITEM_REL_CAT_CAT_ID int,
ITEM_REL_CAT_ITEM_ID int,
CP:{ ITEM_REL_CAT_ID }
C.Aj: { ITEM_REL_CAT_ITEM_ID }→ Item
C.Aj: { ITEM_REL_CAT_CAT_ID }→ Categoria
VNN: { ITEM_REL_CAT_ITEM_ID, ITEM_REL_CAT_CAT_ID }
WEB_CENTROASISTENCIA_ITEM_REL_AVI:
ITEM_REL_AVI_Id int ,
ITEM_REL_AVI_AVI_ID int,
ITEM_REL_AVI_ITEM_ID int,
CP:{ ITEM_REL_AVI_ID }
C.Aj: { ITEM_REL_AVI_ITEM_ID }→ Item
C.Aj: { ITEM_REL_AVI_AVI_ID }→ Aviso
VNN: { ITEM_REL_AVI_ITEM_ID, ITEM_REL_AVI_AVI_ID }
WEB_CENTROASISTENCIA_Categoria:
CAT_Id int
CAT_Nombre nvarchar (100)
48

54. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 4. Diseño Base de Datos 20/03/07
CAT_Descripcion nvarchar (500)
WEB_CENTROASISTENCIA_Personal :
PER_Id int ,
PER_Nombre nvarchar (100),
PER_Apellidos nvarchar (500),
PER_TIT_ID int,
PER_Email nvarchar (200),
PER_Telefono nvarchar (100),
PER_Despacho nvarchar (100),
WEB_CENTROASISTENCIA_Alumno:
ALU_Id int,
ALU_Cod char(9)
ALU_Identificador char(9)
ALU_Nombre nvarchar (100)
ALU_Apellidos nvarchar (500)
ALU_TIT_ID int NOT NULL,
ALU_Email nvarchar (200)
ALU_Telefono nvarchar (100)
WEB_CENTROASISTENCIA_Titulacion
TIT_Id: int
TIT_Cod: char(3)
TIT_Nombre: nvarchar (300)
TIT_CENTRO_ID: int not null
WEB_CENTROASISTENCIA_Centro
CEN_Id int ,
CEN_Nombre nvarchar (300)
WEB_CENTROASISTENCIA_Url:
ENL_Id: int
ENL_Titulo: nvarchar (100) not null
ENL_Descripcion: nvarchar(500) null
ENL_Url: nvarchar(300) not null
ENL_Fecha: datetime not null
WEB_CENTROASISTENCIA_Archivos:
ARC_Id: int
ARC_Descripcion: nvarchar(500)
ARC_Titulo: nvarchar(100)
ARC_NombreFisico: nvarchar(100)
ARC_Url: nvarchar(300)
ARC_IP: nvarchar(50)
ARC_Fecha: datetime
WEB_CENTROASISTENCIA_Estado:
EST_ID: int
EST_Nombre: nvarchar(100)
CP:{ EST_ID}
VNN: { EST_Nombre}
49

55. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 4. Diseño Base de Datos 20/03/07
Fig 4.2 Diagrama realizado con el SGBD SQL Server.
Como hemos comentado anteriormente, la base de datos es una parte fundamental en el
desarrollo de nuestra aplicación. Nuestro centro de asistencia almacenará todas las incidencias
que se generan en un entorno universitario, y como tal debe almacenar gran cantidad de datos,
enlaces, archivos que sean de necesidad para el usuario. Pues bien, esa gran cantidad de datos
que nuestra aplicación debe tratar están guardados, o mejor dicho, son tratados por un gestor de
base de datos.
Que es un sistema gestor de bases de datos?
Un gestor de base de datos es una herramienta software que proporciona una interfaz entre los
datos almacenados y los programas de aplicación que acceden a éstos y que se caracteriza
fundamentalmente por permitir una descripción centralizada de los datos y por la posibilidad de
definir vistas parciales de los mismos para los diferentes usuarios.
Las funciones de un sistema de gestión de base de datos fundamentalmente se pueden enunciar
las siguientes:
• Descripción de los distintos esquemas de la base de datos (excepto el esquema conceptual).
• Manipulación de la base de datos en lo que respecta a recuperación y actualización de la
información.
• Facilidades de utilización relativas al manejo de la base de datos, desde lenguajes de
programación de alto nivel a lenguajes conversacionales, así como utilidades para la
administración de la base de datos.
¿Porque SQL Server?
A la primera decisión que debemos enfrentarnos llegado este punto, es cual sistema gestor de
bases de datos se empleará en nuestra aplicación de todos los que tenemos disponibles en el
50

56. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 4. Diseño Base de Datos 20/03/07
mercado, existe una gran variedad con diferentes características de rendimiento, fiabilidad y
precios.
Finalmente se ha optado por usar SQL Server producto de Microsoft Corporation, este sistema
es uno de los mas extendidos ya que es un SGBD totalmente integrado con el resto de
aplicaciones de Microsoft, al ser SQL Server otro producto de la misma compañía no va a tener
problemas de conectividad, ya que se trabajará además con el servidor de aplicaciones para
Internet Information Server de Microsoft.
El motivo de haber elegido este tipo de base de datos y no otro fue simplemente por cuestión de
comodidad y de probar una herramienta nueva. El elegir SQL Server fue además por la facilidad
de integración con el Visual Studio .NET.
Visual Studio .NET ofrece muchas facilidades para trabajar con SQL, permitiendo realizar todo
tipo de trabajos de forma sencilla, ya que dispone de asistentes para crear todo tipo de consultas.
Además, permite introducir código SQL en el mismo código ASP .Net.
Además de las facilidades que aporta el trabajar con SQL Server conjuntamente con Visual
Studio, también hay que hablar de la facilidad a la hora de implementar la propia base de datos.
SQL Server permite crear toda la estructura de la bade de Datos de forma cómoda y sencilla, con
una interfaz amigable y fácil de entender. Para ver como está construida la Base de Datos,
consultar el punto “Diseño de la base de datos”. (4.1.1)
Lógicamente, con SQL Server no todo es sencillo. Para poder trabajar con esta herramienta es
también necesario conocer las propias características que posee, como se accede a las tablas,
como dejarlas en estado seguro, etc.
A continuación se nos muestra un listado de las tablas generadas con el sistema gestor de bases
de datos SQL Server:
Fig 4.3 Tablas generadas con SGBD SQL Server.
51

57. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 4. Diseño Base de Datos 20/03/07
4.2.4) Diagrama UML
UML es un lenguaje de propósito general para el modelado orientado a objetos. La perspectiva
de UML es ser un lenguaje de modelado orientado a objetos estándar predominante en los
próximos Años.
Cuando se va a construir un sistema software es necesario conocer un lenguaje de
programación, pero con eso no basta. Si se quiere que el sistema sea robusto y mantenible es
necesario que el problema sea analizado y la solución sea cuidadosamente diseñada.
Se debe seguir un proceso robusto. Tal proceso de desarrollo se ocupa de plantear cómo se
realizan las distintas actividades, y cómo se relacionan los productos de las mismas. Con el uso
de un proceso de desarrollo adecuado la construcción de sistemas software va a poder ser
planificable y repetible, y la probabilidad de obtener un sistema de mejor calidad al final del
proceso aumenta considerablemente, especialmente cuando se trata de un equipo de desarrollo
formado por varias personas.
Para este proyecto se va a seguir un proceso de desarrollo orientado a objetos. Este proceso no
fija una metodología estricta, sino que define una serie de actividades que pueden realizarse en
cada fase, las cuales deben adaptarse según las condiciones del proyecto que se esté llevando a
cabo.
La notación que se usa para los distintos modelos, tal y como se ha dicho anteriormente, es la
proporcionada por UML, que se ha convertido en el estándar de facto en cuanto a notación
orientada a objetos. El uso de UML permite integrar con mayor facilidad en el equipo de
desarrollo a nuevos miembros y compartir con otros equipos la documentación, pues es de
esperar que cualquier desarrollador versado en orientación a objetos conozca y use UML.
El lenguaje UML comenzó a gestarse en octubre de 1994, cuando Rumbaugh se unió a la
compañía Rational fundada por Booch (dos reputados investigadores en el área de metodología
del software). El objetivo de ambos era unificar dos métodos que habían desarrollado: el método
Booch y el OMT (Object Modelling Tool). El primer borrador apareció en octubre de 1995. En
esa misma época otro reputado investigador, Jacobson, se unió a Rational y se incluyeron ideas
suyas. Estas tres personas son conocidas como los “tres amigos”. Además, este lenguaje se abrió
a la colaboración de otras empresas para que aportaran sus ideas. Todas estas colaboraciones
condujeron a la definición de la primera versión de UML.
Para entender UML necesitamos conocer el concepto de modelo y de diagrama. Un modelo
captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema,
considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del
sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle.
Por otra parte un diagrama es una representación gráfica de una colección de elementos de
modelado, a menudo dibujada como un grafo con vértices conectados por arcos. Un proceso de
desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto
desde cada una de las perspectivas de interés.
A continuación mostramos el diagrama UML generado.
52

58. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 4. Diseño Base de Datos 20/03/07
Fig 4.4 Diagrama UML HELP Desk CEU
53

59. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 4. Diseño base de datos 20/03/07
4.2 PROCEDIMIENTOS ALMACENADOS EN SQL SERVER.
4.2.1 Definición de los procedimientos almacenados.
Los procedimientos almacenados son un conjunto precompilado de instrucciones Transact-SQL
almacenados bajo un solo nombre y procesados como una unidad. Los procedimientos
almacenados pueden recibir parámetros en base a los cuales realizar distintas acciones.
La utilización de procedimientos almacenados en nuestras aplicaciones aporta multitud de
ventajas, entre las que podemos destacar las siguientes:
Rendimiento
Los procedimientos almacenados son analizados y optimizados en el momento de su creación, a
diferencia de las instrucciones Transact-SQL, que deben ser analizadas, compiladas y
optimizadas cada vez que son enviadas por el cliente. Además, el motor de SQL Server es capaz
de reutilizar el plan de ejecución del procedimiento almacenado que se encuentra en la memoria
(caché de procedimientos) después de haberse ejecutado una primera vez.
Reducción del tráfico de red
Una sentencia formada por decenas, cientos o incluso miles de líneas de código Transact-SQL
puede escribirse como un procedimiento almacenado en el servidor y ejecutarse simplemente
mediante el nombre de dicho procedimiento, en lugar de enviar todas las líneas de código por la
red desde el cliente hasta el servidor (ésta reducción del tráfico de red será especialmente
significativa en redes no muy veloces, como por ejemplo, algunas redes WAN).
Seguridad
Los procedimientos almacenados facilitan algunas tareas de administración de seguridad y
asignación de permisos. Por ejemplo, se puede conceder permiso a un usuario para ejecutar un
determinado procedimiento almacenado, aunque el usuario no disponga de los permisos
necesarios sobre los objetos afectados por las acciones individuales de dicho procedimiento.
Encapsulación
Los procedimientos almacenados encapsulan gran parte de la lógica de los datos a las
aplicaciones que los utilizan. Por ejemplo, una aplicación puede llamar al procedimiento
almacenado CategoriaBorrar sin conocer cómo funciona internamente éste proceso
(transacciones e instrucciones Transact-SQL utilizadas, tablas afectadas, etc.)
Programación modular
Los procedimientos almacenados se crean una sóla vez, se almacenan en la base de datos y se
ejecutan desde las aplicaciones cliente tantas veces como sea necesario. Además, en caso de
detectarse un error en un procedimiento almacenado, éste podrá ser reparado por el
administrador de la base de datos desde el servidor sin afectar y probablemente, volver a
compilar las aplicaciones cliente.
A continuación, mostramos los procedimientos almacenados que se han creado. Los hemos
clasificado según la clase con la que van ha trabajar en que se integran.
La notación que se ha seguido a la hora de nombrar a los procedimientos almacenados es la
siguiente:
sp (stored procedure) + ACCION+ NOMBREAPLICACION + TABLA
54

60. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 4. Diseño base de datos 20/03/07
Alumno
• sp_borrar_CENTROASISTENCIA_Alumno
• sp_obtener_CENTROASISTENCIA_Alumno
• sp_obtener_CENTROASISTENCIA_Alumno_todos
• sp_insertar_CENTROASISTENCIA_Alumno
• sp_actualizar_CENTROASISTENCIA_Alumno
Área
• sp_borrar_CENTROASISTENCIA_Area
• sp_obtener_CENTROASISTENCIA_Area
• sp_obtener_CENTROASISTENCIA_Area_todos
• sp_insertar_CENTROASISTENCIA_Area
• sp_actualizar_CENTROASISTENCIA_Area
SubÁrea
• sp_borrar_CENTROASISTENCIA_SubArea
• sp_obtener_CENTROASISTENCIA_SubArea
• sp_obtener_CENTROASISTENCIA_SubArea_Area
• sp_obtener_CENTROASISTENCIA_SubArea_todos
• sp_insertar_CENTROASISTENCIA_SubArea
• sp_actualizar_CENTROASISTENCIA_SubArea
Incidencia
• sp_borrar_CENTROASISTENCIA_Incidencia
• sp_obtener_CENTROASISTENCIA_Incidencia
• sp_obtener_CENTROASISTENCIA_Incidencia_SubArea
• sp_obtener_CENTROASISTENCIA_Incidencia_todos
• sp_insertar_CENTROASISTENCIA_Incidencia
• sp_actualizar_CENTROASISTENCIA_Incidencia
Aviso
• sp_borrar_CENTROASISTENCIA_Aviso
• sp_obtener_CENTROASISTENCIA_Aviso
• sp_obtener_CENTROASISTENCIA_Aviso_todos
• sp_insertar_CENTROASISTENCIA_Aviso
• sp_actualizar_CENTROASISTENCIA_Aviso
Centro
• sp_borrar_CENTROASISTENCIA_Centro
• sp_obtener_CENTROASISTENCIA_Centro
• sp_obtener_CENTROASISTENCIA_Centro_todos
• sp_insertar_CENTROASISTENCIA_Centro
• sp_actualizar_CENTROASISTENCIA_Centro
Estado
• sp_borrar_CENTROASISTENCIA_Estado
• sp_obtener_CENTROASISTENCIA_Estado
• sp_obtener_CENTROASISTENCIA_Estado_todos
• sp_insertar_CENTROASISTENCIA_Estado
55

61. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 4. Diseño base de datos 20/03/07
• sp_actualizar_CENTROASISTENCIA_Estado
Item
• sp_borrar_CENTROASISTENCIA_Item
• sp_obtener_CENTROASISTENCIA_Item
• sp_obtener_CENTROASISTENCIA_Item_Incidencia
• sp_obtener_CENTROASISTENCIA_Item_Archivos
• sp_obtener_CENTROASISTENCIA_Item_Enlaces
• sp_obtener_CENTROASISTENCIA_Item_Avisos
• sp_obtener_CENTROASISTENCIA_Item_Categorias
• sp_obtener_CENTROASISTENCIA_Item_todos
• sp_insertar_CENTROASISTENCIA_Item
• sp_actualizar_CENTROASISTENCIA_Item
Titulación
• sp_borrar_CENTROASISTENCIA_Titulacion
• sp_obtener_CENTROASISTENCIA_Titulacion
• sp_obtener_CENTROASISTENCIA_Titulacion_todos
• sp_insertar_CENTROASISTENCIA_Titulacion
• sp_actualizar_CENTROASISTENCIA_Titulacion
A continuación vamos a mostrar un ejemplo de cada uno de los tipos posibles: un ejemplo de
borrado, otro de inserción, otro de modificación y un último de consulta.
-Ejemplo de borrado: borra un registro especificado de la tabla item, se observa como en este
procedimiento se le está pasando un parámetro de entrada (@ITEM_Id) que es el identificador
del registro que se quiere borrar.
CREATE PROCEDURE [dbo].sp_borrar_CENTROASISTENCIA_Item
@ITEM_Id int
AS
DELETE FROM [dbo].[WEB_CENTROASISTENCIA_Item]
WHERE
[ITEM_Id] = @ITEM_Id
GO
-Ejemplo de inserción: Este procedimiento es para guardar un nuevo registro en la tabla aviso.
En este procedimiento almacenado es interesante comentar que se le pasan tres parámetros de
entrada, y que uno de los parámetros de entrada también es parámetro de salida, en nuestro caso
@AVIS_Id. Esto es una práctica común para procedimientos almacenados de inserción donde
nos interesa que después de haber insertado un registro nos devuelva el identicador asignado a
ese nuevo elemento.
CREATE PROCEDURE [dbo].sp_insertar_CENTROASISTENCIA_Aviso
@AVIS_Descripcion nvarchar(500),
@AVIS_Fecha datetime,
@AVIS_Id int OUTPUT
AS
56

62. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 4. Diseño base de datos 20/03/07
INSERT INTO [dbo].[WEB_CENTROASISTENCIA_Aviso] (
[AVIS_Descripcion],
[AVIS_Fecha])
VALUES (
@AVIS_Descripcion,
@AVIS_Fecha
)
SET @AVIS_Id = @@IDENTITY
GO
-Ejemplo de modificado: En este procedimiento se modifican los datos de un item generado por
el usuario. Se deberán pasarle como parámetros de entrada todos aquellos valores que deseemos
modificar.
CREATE PROCEDURE [dbo].sp_actualizar_CENTROASISTENCIA_Item
@ITEM_Id int,
@ITEM_INC_ID int,
@ITEM_Descripcion nvarchar(3500),
@ITEM_Resolucion nvarchar(3500),
@ITEM_FechaIni datetime,
@ITEM_FechaFin datetime,
@ITEM_EST_ID int,
@ITEM_PER_ID int,
@ITEM_ALU_ID int,
@ITEM_Visitas int
AS
UPDATE [dbo].[WEB_CENTROASISTENCIA_Item] SET
[ITEM_INC_ID] = @ITEM_INC_ID,
[ITEM_Descripcion] = @ITEM_Descripcion,
[ITEM_Resolucion] = @ITEM_Resolucion,
[ITEM_FechaIni] = @ITEM_FechaIni,
[ITEM_FechaFin] = @ITEM_FechaFin,
[ITEM_EST_ID] = @ITEM_EST_ID,
[ITEM_PER_ID] = @ITEM_PER_ID,
[ITEM_ALU_ID] = @ITEM_ALU_ID,
[ITEM_Visitas] = @ITEM_Visitas
WHERE
[ITEM_Id] = @ITEM_Id
GO
-Ejemplo de consulta: Obtiene los datos de un item en concreto. Este tipo de consulta es muy
común. Lo que se desea es que a raíz de especificarle un identificador nos devuelva el resto de
campos del registro. Esta consulta la invocaremos en los constructores de las clases que más
adelante se verán con mas detalle.
57

63. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 4. Diseño base de datos 20/03/07
CREATE PROCEDURE [dbo].sp_obtener_CENTROASISTENCIA_Item
@ITEM_Id int
AS
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
SELECT
[ITEM_Id],
[ITEM_INC_ID],
[ITEM_Descripcion],
[ITEM_Resolucion],
[ITEM_FechaIni],
[ITEM_FechaFin],
[ITEM_EST_ID],
[ITEM_PER_ID],
[ITEM_ALU_ID],
[ITEM_Visitas]
FROM
[dbo].[WEB_CENTROASISTENCIA_Item]
WHERE
[ITEM_Id] = @ITEM_Id
GO
4.2.2 CONEXIONES EN SQL Server.
Para crear conexiones para acceder a los datos es necesario utilizar las clases SqlConnection
para conectarse y desconectarse de una base de datos.
Para crear una conexión a una base de datos es necesaria la introducción de una serie de
parámetros como mostramos en el siguiente ejemplo:
Sqlconnection.connectionstring = “user id =idusuario; pwd=pwdusuario; initial
catalog=bdname; Data Source = localhost; Connect TimeOut = 30”;
Explicaremos brevemente cuales son los parámetros que componen la conexión a una base de
datos:
- SqlConnection.ConnectionString es una clase ya creada. Es necesaria siempre que
queramos crear una nueva conexión con la base de datos.
- User id: este parámetro indica el nombre de usuario.
- Pwd: Representa la contraseña del usuario. También se puede omitir este parámetro no
introduciendo nada.
- Initial catalog: Este parámetro describe la instancia de base de datos a la que hay que
conectarse.
Una vez la conexión a la base de datos esté establecida debemos abrirla o cerrarla cuando
queramos trabajar con ella o hayamos terminado, respectivamente. Esto es una ventaja ya que
permite trabajar con los datos teniendo la conexión cerrada y abrirla solamente para hacer
modificaciones a la base de datos. Los comandos para abrir y cerrar la conexión son:
- Sqlconnection.open para abrir la conexión.
- Sqlconnection.close para cerrar la conexión.
58

64. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 4. Diseño base de datos 20/03/07
Es conveniente tener en cuenta estos dos comandos ya que abrir y cerrar la conexión
inadecuadamente puede dejar la base de datos en estado inseguro.
59

65. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 5. Diseño Web 20/03/07
CAPÍTULO 5
5. DISEÑO WEB
En este apartado nos vamos a centrar en tres aspectos. El primer aspecto es el diseño de
navegación; en este apartado nos centraremos en explicar como queremos que esté organizada
la página. En el segundo apartado nos dedicaremos a resaltar la gran importancia de las hojas de
estilo, y detallaremos la hoja de estilos que hemos desarrollado. El tercer punto está dedicado a
la usabilidad.
Es muy importante realizar un diseño sencillo, interesante, rápido y funcional de la aplicación
debido a su naturaleza. Debido a que el cliente tiene muy claro que diseño debe seguir la
aplicación Web, similar al de otra aplicación de idéntica naturaleza realizada previamente,
comprobamos que en la planificación estimada se estiman más días de los que realmente luego
son necesarios.
5.1 DISEÑO DE LA NAVEGACIÓN
En este apartado nos vamos a centrar en el esqueleto de la página web.
Según estudios realizados, cuando un usuario observa una página web sigue el siguiente trazado
con la vista:
Fig 5.1. Movimiento del ojo. [eyetrack01]
Una de las primeras mejoras que nos permitiría el diseño como pagina web será la división de la
pantalla en distintas secciones que nos permitiría navegar por la aplicación sin necesidad de
seguir un orden lineal en la sucesión de paginas. Se incluirá una sección desde donde se podrá
acceder mediante un enlace a cualquier categoría. Otra sección nos permitirá consultar los
59

66. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 5. Diseño Web 20/03/07
ítems/incidencias más demandados. También habrá una sección con unos enlaces a las paginas
de ayuda, documentos de interés, etc. Esto permitirá que en cualquier momento un estudiante
pueda cambiar de sección del centro de asistencia sin necesidad de acudir a la página de
bienvenida. Esto también nos permitirá en un futuro añadir las secciones que creamos
convenientes ya que el espacio ya estará definido dentro de la página.
Otra de las características que gana nuestra aplicación al hacerla en formato de pagina web es la
posibilidad de adición de una cabecera y de un pie de pagina donde se puede incluir el logo de
la universidad e información relativa al centro, al copyright. Incluso se podría incluir un espacio
destinado a banners informativos.
A la hora de decidir como vamos a organizar la información debemos tener bien definido a que
usuarios se dirige nuestra aplicación. Hay que resaltar que se tendrá dos aplicaciones una para
los visitantes y otra para el personal.
En la figura 5.2 se observa el esquema de la organización de la información para la página
principal de los usuarios con el perfil de visitante.
Fig.5.2.boceto del diseño de la organización de la página principal perfil visitante (Default.aspx)
A continuación se desarrollará más en profundidad como se va ha encontrar organizada la
información:
En esta figura se puede apreciar las distintas secciones en las que quedan divididas las distinta
paginas web que componen la aplicación. En ella se pueden distinguir cuatro partes
diferenciadas. En la parte superior e inferior se aprecian la cabecera y el pie respectivamente y
la parte central dividida en dos secciones.
El logo en la parte superior izquierda (ya que está estudiado que lo primero que vemos siempre
es lo que está en la parte superior izquierda). Después del logo lo segundo que llama la atención
es el slogan que preside a la pagina, se ha optado por una frase contundente y clara “la web
donde todas tus dudas tienen solución”, bajo este slogan el usuario sabe rápidamente donde
esta y que se le está ofreciendo.
60

67. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 5. Diseño Web 20/03/07
Después tendremos la fecha actual, con esto se consigue dar una sensación de actualidad y de
constante cambio.
Debajo de la fecha nos encontramos con las diferentes categorías/áreas; además de indicar el
nombre de la categoría se ha considerado interesante indicar entre paréntesis el numero de ítems
asociados a esa área, con esto se consigue que el usuario tenga la sensación de acudir a una web
con gran volumen de información donde todos los datos esta cercanos y visibles.
En el centro tendremos el listado de los ítems más frecuentes ordenados por fecha; dentro de
cada item se podrá pinchar para ampliar la información, con esto se consigue que en un solo clic
el usuario pueda acceder rápidamente a la solución que necesita. Otra de las consideraciones
claves fue la de cambiar el nombre “item” por “pregunta”, se pensó que el usuario podría
entender más fácilmente el termino “pregunta”.
En la parte de la derecha, al principio del menú también tendremos una búsqueda sencilla para
que el usuario pueda buscar directamente por titulo, así como un enlace para realizar una
búsqueda avanzada donde se podrán utilizar como argumentos de búsqueda la mayor parte de
campos disponibles.
Para finalizar la parte de la derecha nos encontramos con otras secciones que hemos titulado
“preguntas más recientes”, “documentos de interés” y “enlaces de interés”, a modo de
biblioteca, el usuario podrá consultar los documentos archivados, también se podrá visualizar un
listado de enlaces considerados de interés, y por último gracias a esta secciones también se
consigue saber cual es la última pregunta mandada al sistema, donde se mostrará un listado de
las 5 últimas preguntas lanzadas al sistema.
Resaltar que al final de la parte de la derecha se ha añadido un enlace al mapa del sitio, no se ha
querido prescindir de este, ya que es una de las pautas más importantes en el desarrollo de la
usabilidad. En el mapa del sitio se muestra un informe detallado de toda la información que hay
albergada en la aplicación, colaborando a la comprensión de la totalidad del sistema.
Al recorrer la parte central de la página lo primero que nos encontramos es la sección que se ha
titulado “pregunta lo que quieras”, desde esta sección el usuario podrá lanzar una pregunta al
sistema con un solo clic de ratón. Con esto se consigue facilitar la participación del usuario,
haciendo muy cómoda la consulta al sistema. Se quiere mostrar al usuario que los problemas
importan a la organización y que se quieren resolver con inmediata urgencia. Desde la pagina se
tratará que el usuario sienta la predisposición a preguntar y a sentirse respondido.
Dentro de la parte central además el usuario dispondrá de un listado, en este listado se muestran
las 10 preguntas más frecuentes, jugando con los colores de las filas se consigue que estén
fácilmente diferenciadas, con un solo clic el usuario podrá acceder a la solución de la pregunta
demandada.
Otra de las cosas ha resaltar del boceto es que se quiere mantener la imagen corporativa de la
organización, para esto se ha procurado no abandonar en ningún momento los colores
corporativos de la organización, además de darle una imagen clásica tan propia de la institución
para la que se está realizando el centro de asistencia, de esta forma se logrará que el usuario
asocie la calidad del sistema a la imagen de marca.
Por último comentar la importancia del pie de página, el cual proporciona la sensación de
termino; este consigue, además, encuadrar la información en el centro. En el pie de pagina se ha
decidido indicar datos de la organización tal y como recomiendan las normas de usabilidad.
61

68. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 5. Diseño Web 20/03/07
Se ha procurado que la fuente de autoría siempre esté visible en la parte superior central,
intentando conseguir que el usuario memorice la web donde se encuentra.
Finalmente plasmando todo lo anterior al diseño real quedaría:
Fig.5.3 .Diseño de la organización de la página principal perfil visitante (Default.aspx)
Otra de las páginas fundamentales del portal web concebido será la que obtendremos una vez
hayamos pinchado en una pregunta en concreto y queramos mostrar toda la información en
detalle.
El esqueleto es similar, lo que cambia es que ahora, en el centro, lo que tendremos será la
información de esa pregunta. (ver figura 5.4).
Para esta sección se ha recurrido a las migas de pan o breadcrumbs, gracias a esta herramienta
visual se consigue que el usuario no se pierda y sepa en todo momento donde está. Las migas de
pan son un texto aclaratorio donde se le indica al usuario el nivel y subniveles en los que se
encuentra, pinchando en cualquiera de estos podrá volver acceder de forma rápida y directa al
nivel solicitado.
A pesar de mostrar la información de la pregunta se mantiene el acceso a la sección de
“pregunta rápida”, por si se diera el caso que la respuesta de la pregunta no se acerca a la
solución que se desea. Con esto se consigue que el usuario pueda aproximar su consulta de
forma rápida.
Para el caso que el usuario haya encontrado la solución que buscaba se le permite que pueda
enviársela a un amigo, o descargársela en un archivo pdf. Con esto se consiguen dos objetivos
fidelizar a nuestros clientes y darse a conocer a los amigos de nuestros clientes.
En la imagen siguiente se muestra, todo lo comentado anteriormente plasmado en el diseño real.
(Ver figura 5.4)
62

69. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 5. Diseño Web 20/03/07
Fig.5.4.Captura de la página con la información de la pregunta (perfil visitante)
Después tendremos una segunda aplicación enfocada al usuario que gestiona la información.
Esta aplicación será de uso interno para la organización, en este caso la aplicación deberá estar
más enfocada hacia la introducción de datos más que a la consulta de los mismos.
En la figura siguiente se puede apreciar un boceto de la aplicación para la gestión de la
información del centro de asistencia.
Fig.5.5. boceto del diseño de la organización de la página perfil personal.
63

70. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 5. Diseño Web 20/03/07
Se seguirá disponiendo de una cabecera y de un pie pero ahora lo primero que se ha hecho
accesible es la edición de los campos, a diferencia de la aplicación anterior se busca que el
usuario pueda introducir los datos de forma rápida.
Para el caso en el que el volumen de información sea muy grande se necesitará disponer de una
herramienta de búsqueda para que el gestor de la aplicación pueda localizar de forma fácil aquel
registro para su edición. Esto se consigue con los filtros de búsqueda que se han añadido justo
después de los campos para la edición.
Finalmente se tiene un listado con los registros para acceder fácilmente a su edición y borrado.
Alternando los colores de las filas se consigue que estén fácilmente diferenciadas. Lo que se
busca en este listado es que con un solo clic el usuario pueda acceder fácilmente a la edición del
registro seleccionado.
Como resumen de todo lo plasmando anteriormente el diseño real quedaría, como se muestra a
continuación:
Fig.5.6.Diseño de la organización de la página (perfil personal).
Finalmente comentar en esta apartado que una de las fases en el desarrollo de la aplicación será
la evaluación de la usabilidad de nuestro producto. No solo se deberá evaluar su funcionamiento
sino que también será necesario comprobar si la aplicación satisface las necesidades del usuario.
La cualidad que nos indica esto como se comentará en el tercer apartado es la usabilidad.
Las pautas que se seguirán a la hora de realizar la aplicación son las siguientes:
• Se pensará en que modo el usuario desearía encontrar la información.
• Se tendrá en cuenta las limitaciones de los recursos del usuario a nivel de ancho de banda,
capacidad de procesamiento y resolución.
• Se diseñar el grado de profundidad que daremos a nuestros contenidos, y si el usuario podrá
avanzar en complejidad a medida que lo desee.
• Se definirá un árbol de navegación atractivo como referencia de navegabilidad en nuestra
página web, no abrumando con excesivos enlaces, y mostrándolos a medida que el usuario se
interesa por ellos.
• Se definirá una iconografía y un diseño visual con importante carga semántica, que transmitirá
justo lo que nos proponemos, para así poder ayudarnos del impacto visual en lugar de que éste
produzca confusión.
64

71. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 5. Diseño Web 20/03/07
Otra de las cosas que serán muy recomendables es que a medida que se va creando la aplicación
ir realizando una serie de pruebas para comprobar la navegabilidad como es la prueba de
enlaces rotos y también las pruebas referentes a la accesibilidad como la pruebas de verificación
de estándares y la prueba de resolución para comprobar la correcta visualización por parte del
usuario.
Pruebas de validación.
Para realizar las pruebas de validación del formato se puede acceder a la pagina del consorcio
W3C que incluye un validador de paginas en formato XHTM. Y otro de paginas de estilo CSS.
Si se pretende que nuestra aplicación cumpla los estándares XHTML se debe ir comprobando
pagina por pagina desde la pagina del validador que se encuentra en: [W3CSS02] e ir
corrigiendo los errores que se vayan encontrando.
También se puede acceder al comprobador de paginas de estilo CSS desde la dirección:
[W3CSS02]. Donde se podrá comprobar si nuestra hoja de estilos cumple los estándares CSS
2.0.
Comprobación de enlaces rotos.
Existen bastantes programas disponibles para realizar la comprobación de enlaces rotos. Uno
que esta bastante bien y que es gratuito se puede encontrar en la dirección [ANYBRO01]
Este programa comprueba todos los enlaces de la pagina indicada y muestra una lista indicando
si son correctos o por el contrario están rotos.
Comprobación de resolución.
Para una correcta visualización de la aplicación debe comprobarse que esta se muestra
correctamente en las resoluciones mas comunes entre los usuarios que en la actualidad suele ser
800x600 pixeles o superior.
Comprobación en otros navegadores.
Aparte de la comprobación de distintas resoluciones también es recomendable realizar una
prueba con varios navegadores. Hasta ahora se han realizado todas las visualizaciones con el
navegador netscape y han sido correctas. A continuación se muestra la visualización utilizando
el navegador internet explorer.
65

72. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 5. Diseño web 20/03/07
5.2 HOJA DE ESTILOS CSS
Las hojas de estilo en cascada (Cascading Style Sheets, CSS) son un lenguaje formal usado para
definir la presentación de un documento estructurado escrito en HTML o XML y permiten a los
diseñadores y desarrolladores web separar la estructura de la presentación.
Gracias a la hojas de estilo conseguimos uniformidad en el aspecto y funcionamiento de todo un
sitio.
Al separar la estructura (o contenido) de la presentación se aumenta la uniformidad del diseño
web. Con CSS la presentación se define con un documento en el lenguaje CSS orientado a la
disposición. Este se puede aplicar a un conjunto de documentos HTML, lo que permite hacer un
cambio completo de la presentación en todos los documentos a la vez.
Un desafío común al cual se enfrentan los desarrolladores web al asumir la administración de
sitios existentes es el código escrito por otros desarrolladores. En muchos casos se enfrentan a
código HTML de mala calidad que puede además depender de características que no han sido
documentadas o hacks y prácticas de codificación específicas.
Además, la falta de documentación es un problema frecuente. Gracias a que las
especificaciones, tales como CSS, están bien documentadas, una persona que hereda un código
que cumple con las normas puede comenzar a trabajar de inmediato, y no tendrá que
familiarizarse con las prácticas de codificación del desarrollador anterior. Esto, además, reduce
considerablemente la dependencia en un solo proveedor.
Si el diseño se ajusta a un estándar se puede estar seguro de que los navegadores que han sido
diseñados para ajustarse a dicho estándar representarán nuestros contenidos tal y como los
habíamos imaginado.
Gracias a su uso conseguiremos alcanzar una representación única y universal en todos los
navegadores y dispositivos que respeten el estándar propuesto en que nos hayamos basado.
El problema de usabilidad supone construir sitios accesibles por personas con minusvalía. Una
de las consecuencias del uso de la filosofía CSS es que, debido a la separación de los contenidos
y del diseño, se minimiza el contenido redundante entre páginas.
Cuando diseñamos respetando los estándares logramos que los analizadores de los motores de
búsqueda clasifiquen mejor nuestros contenidos.
Una de las causas de ello es el empleo de los elementos semánticos a los que nos obligan dichas
normas, los cuales sirven para dotar de importancia a determinadas partes de nuestros
contenidos.
Igualmente, la separación entre contenidos y diseño posibilita que en la lectura de cada una de
nuestras páginas dichos analizadores encuentren un ratio mayor de contenidos útiles que de
código destinado a la representación de los mismos.
Las hojas de estilo se pueden insertar directamente en el código HTML o bien en un archivo
separado de hoja de estilos, al que el documento principal enlazará. En esta aplicación se ha
utilizado este último método, con el cual el estilo se centraliza en un único punto, con lo que
ganamos en eficiencia, los cambios se limitan a un único archivo y además el tamaño de los
documentos HTML se reduce al no contener ya información referente al estilo. Otra ventaja
añadida radica en el hecho de que un cambio en la hoja de estilos desemboca en un cambio de
66

73. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 5. Diseño web 20/03/07
estilo general para todo el portal, mientras que de otra forma habría que revisar uno a uno todos
los documentos para aplicarles los estilos correspondientes.
Las hojas de estilo en el portal se han empleado precisamente para presentar las páginas web
generadas por el servidor de forma estructurada, así como de aplicarle cierto diseño al portal en
general para que los navegadores puedan mostrarlo al usuario de forma más agradable, intuitiva
y amigable.
Para cargar el CSS, en la página principal, hay que colocar la siguiente instrucción:
<HEAD>
<link href="estilos.css" rel="stylesheet" type="text/css">
Cada definición de una propiedad CSS comienza con un resumen de la información clave que se
asemeja a lo siguiente:
'nombre_de_la_propiedad'
Valor: valores permitidos y sintaxis
Inicial: valor inicial
Se aplica a: elementos a los cuáles se aplica esta propiedad
Se hereda: si la propiedad es heredada
Porcentajes: cómo se interpretan los valores de porcentaje
Medios: a qué grupo de medios se aplica la propiedad
Valor
Esta parte especifica el conjunto de valores válidos para la propiedad. Los tipos de valor pueden
ser
designados de varias maneras:
1. Palabras clave (ej., auto, disc, etc.)
2. Datos básicos, que aparecen entre "<" y ">" (ej., <medida>, <porcentaje>, etc.).
3. Tipos que tienen el mismo rango de valores que una propiedad con igual nombre (ej.,
<'border-width'> <'background-attachment'>, etc.). En este caso, el nombre del tipo es el
nombre
de la propiedad (completo con comillas) entre "<" y ">" (ej., <'border-width'>).
4. No-terminales que no comparten el mismo nombre que una propiedad. En este caso, el
nombre
no-terminal aparece entre "<" y ">", como en <border-width>. Note la diferencia entre <border-
width> y <'border-width'>; el último se define en términos del anterior. La definición de un no-
terminal se encuentra en su primera aparición dentro de la especificación.
Otras palabras en estas definiciones son palabras clave que deben aparecer literalmente, sin
comillas (ej.,red). La barra inclinada (/) y la coma (,) también deben aparecer literalmente.
Los valores pueden estar organizados de las siguientes maneras:
• Varias palabras yuxtapuestas significa que todas ellas deben aparecer, en el orden dado.
• Una barra (|) separa dos o más alternativas: exactamente una de ellas debe aparecer.
• Una barra doble (||) separa dos o más opciones: una o más de ellas debe aparecer, en
cualquier orden.
67

74. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 5. Diseño web 20/03/07
Los corchetes ([ ]) son para agrupar.
Cada tipo, palabra clave o grupo encerrado entre corchetes puede ser seguido por uno de los
siguientes modificadores:
• Un asterisco (*) indica que el tipo, palabra o grupo precedente aparece cero o más
veces.
• Una signo más (+) indica que el tipo, palabra o grupo precedente aparece una o más
veces.
• Un signo de interrogación (?) indica que el tipo, palabra o grupo precedente es opcional.
• Un par de números entre llaves ({A,B}) indica que el tipo, palabra o grupo
precedente aparece por lo menos A y a lo sumo B veces.
Los siguientes ejemplos ilustran los diferentes tipos de valor:
Valor: N | NW | NE
Valor: [ <medida> | thick | thin ]{1,4}
Valor: [<family-name> , ]* <family-name>
Valor: <uri>? <color> [ / <color> ]?
Valor: <uri> || <color>
Algunas propiedades son fórmulas resumidas, significando que permiten a los autores
especificar los valores de varias propiedades con una sola propiedad.
Por ejemplo, la propiedad 'font' es una propiedad resumida para definir 'font-style', 'font-variant',
'font-weight', 'font-size', 'line-height' y 'font-family', todas de una sola vez.
Cuando algunos valores son omitidos en la fórmula resumida, a cada propiedad "ausente" le es
asignado su valor inicial.
Ejemplo:
Las múltiples reglas de estilo de este ejemplo:
H1 {
font-weight: bold;
font-size: 12pt;
line-height: 14pt;
font-family: Helvetica;
font-variant: normal;
font-style: normal;
font-stretch: normal;
font-size-adjust: none
}
pueden re-escribirse con una sola propiedad resumida:
H1 { font: bold 12pt/14pt Helvetica }
En el anexo se presenta el código de la hoja de estilos que se utiliza.
68

75. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 5. Diseño Web 20/03/07
5.3 Estudio de la usabilidad
La definición más clara, simple y eficaz del concepto de usabilidad es la de Nielsen
[JACNIEL01]: usabilidad es un atributo de calidad que mide lo fáciles de usar que son las
interfaces web.
Otra definición clarificadora es la de Redish [JEFVEEN01], para quien es preciso diseñar sitios
web para que los usuarios sean capaces de:
Encontrar lo que necesitan, entender lo que encuentran y actuar apropiadamente… dentro del
tiempo y esfuerzo que ellos consideran adecuado para esa tarea.
Así, un factor decisivo para determinar la calidad de una web lo constituye el éxito o fracaso del
usuario durante su exploración del sitio, su experiencia de uso, en la que influye decisivamente
la usabilidad.
La clave de un sitio usable es que quien navega por él consiga entender su estructura y realizar
con satisfacción aquello que pretendía realizar.
Ante los millones de sitios web existentes en internet, dificultar la cómoda navegación en
alguno de ellos significa invitar al usuario a abandonarlo y dirigirse a otro sitio en unos
segundos [JACNIEL02].
Los criterios que determinan el grado de usabilidad de un sitio web se basan sobre todo en el
sentido común. Son normas básicas de diseño para que una página web pueda ser utilizada
adecuadamente, tales como:
• Hacer que los textos sean legibles (tipos y tamaño de letra, contraste texto/fondo,
textos más cortos…)
• Adecuada organización de las páginas (Arquitectura de la Información)
• Descarga rápida de las páginas (poco peso de las imágenes y ficheros vinculados, buen
etiquetado…).
• Que la tecnología empleada no sea una barrera de entrada para nadie (Accesibilidad)
De forma general, podremos tratar de dividir los principios relacionados con la usabilidad en
cuatro áreas:
Respeto a los estándares de la web, especialmente a los más o menos oficiales, como los
emanados del W3C:
• Los enlaces de color azul, subrayados, y los ya visitados de color morado
• Texto negro sobre fondo blanco (o con buen contraste entre ambos)
• Imágenes con texto alternativo
• El usuario puede modificar el tamaño del texto en su navegador para leerlo mejor
• Emplear encabezados y subencabezados para organizar el texto.
Ergonomía cognitiva y usos comunes en Internet:
• Acostumbramos a leer de izquierda a derecha y de arriba abajo.
• Entendemos mejor las cosas si se las llama por su nombre más común.
• El logotipo suele estar arriba a la izquierda.
• La navegación se suele basar en colocar los ítems en un rail izquierdo, fichas
superiores o categorías centrales.
• El buscador tiende a figurar arriba y a la derecha.
• La ayuda aparece arriba a la derecha.
69

76. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 5. Diseño Web 20/03/07
• Es difícil recordar una lista de items de más de 7 elementos.
Aspectos físicos de la legibilidad y percepción en una pantalla:
• En una pantalla se leen mejor los tipos de letra sans-serif que los serif .
• El contraste entre texto y fondo influye en la legibilidad (negro sobre blanco, amarillo
sobre negro…).
• Los tipos de letra demasiado pequeños se ven y leen mal.
• El ancho de línea y los márgenes influyen en la legibilidad.
• La ubicación de elementos como título, imagen e introducción al texto es clave para
que los usuarios lean o no los aspectos importantes del texto.
• Los elementos animados o parpadeantes distraen la atención del usuario.
Rotulación y ayudas a la navegación:
Son necesarias determinadas ayudas a la navegación, que permitan ubicar al usuario dentro de la
estructura de contenidos del web e identificar visualmente la permanencia o no dentro de la
misma interfaz de trabajo:
• Rastro de migas de pan (por ejemplo. Inicio > Artículos > Usabilidad ) .
• Correcta rotulación de los enlaces (deben identificar claramente el destino. Nunca usar
“pinche aquí”).
• Mapa de la web .
En definitiva, la usabilidad se basa en no molestar ni hacer pensar en exceso al navegante
[PATLYN01] “hasta el más torpe debe ser capaz de navegar correctamente en la web” y en
hacerle fácil y grata la experiencia en el sitio web.
No obstante, pese a lo obvio de estas pautas, son aún muy pocos los sitios web que realmente
respetan la mayoría de ellas y facilitan la utilización del sitio. Así lo pudimos comprobar
haciendo sendos análisis a los principales periódicos digitales españoles y a sitios web para
personas mayores.
En cualquier caso, suelen bastar sólo unas pequeñas mejoras en la usabilidad de diseño para
lograr un importante incremento en el grado de éxito de un sitio web.
Disciplinas afines a la usabilidad
La usabilidad es una de las disciplinas fundamentales que entran a formar parte de la rueda de la
experiencia de usuario. Todas esas disciplinas interactúan entre sí, y se solapan en muchos
casos. Tanto que es difícil delimitar el ámbito exacto que cubre cada una.
Dependiendo del autor consultado, y del ámbito del conocimiento en el que éste trabaje, tenderá
a considerar a una disciplina como parte de otra, como contenida en ésta o bien como
disciplinas con muy poca relación entre sí.
De hecho, ahora veremos como algunas de las mencionadas áreas propias de la usabilidad
suelen ser consideradas también como propias de algunas de estas disciplinas.
Consideramos que una forma adecuada de representar esta idea la aporta gráficamente F. Tosete
(2005), para quien las disciplinas vinculadas a la experiencia de usuario son:
• Usabilidad.
• Accesibilidad.
• Diseño de información y diseño gráfico.
• Buscabilidad (findabiliby).
• Arquitectura de la información.
• Diseño de interacción.
70

77. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 5. Diseño Web 20/03/07
Veamos algunas ideas sobre las disciplinas que, junto a la usabilidad, completan la rueda de la
experiencia de usuario.
Accesibilidad
La accesibilidad web es la posibilidad de que el mayor número posible de personas pueda entrar
a una web y usarla, indiferentemente de las limitaciones propias del individuo o de las derivadas
del contexto de uso. (Definición adaptada de Hassan y Martín)
La accesibilidad suele vincularse erróneamente únicamente con discapacidad. Las personas con
discapacidad son más sensibles a la falta de accesibilidad, pero una web accesible permitirá una
mejor interacción con todo el mundo.
Un resumen de las principales pautas de accesibilidad podría concretarse en un decálogo, a
modo de guía breve para el diseño de sitios web accesibles:
1. Imágenes y animaciones. Use el atributo alt para describir la función de cada elemento visual.
2. Mapas de imagen. Use el elemento map de tipo cliente y texto para las zonas activas.
3. Multimedia. Proporcione subtítulos y transcripción del sonido, y descripción del vídeo.
4. Enlaces hipertextuales. Use texto que tenga sentido leído fuera de contexto. Por ejemplo,
evite “pincha aquí”.
5. Organización de las páginas. Use encabezados, listas y estructura consistente. Use CSS para
la maquetación donde sea posible.
6. Gráficas y esquemas. Resuma o use el atributo longdesc.
7. Scripts, applets y plug-ins. Ofrezca contenido alternativo si las funciones nuevas no son
accesibles.
8. Marcos (frames). Use el elemento noframes y títulos con sentido.
9. Tablas. Que puedan leerse línea a línea. Resumir.
10. Se recomienda revisar el trabajo. Verificar. Usar las herramientas, lista de comprobación y
pautas de W3C [W3CCSS01] y [W3CCSS02].
Diseño de información y diseño gráfico
La información suele entrar por los ojos. La forma en que se presenta a los ojos del usuario
influye en la experiencia de uso. El diseño gráfico es la vía por la que la información se plasma
en formas y colores. Un diseño estético es el que que resulta agradable para los sentidos, la
imaginación, o el entendimiento (Y. Hassan).
Un diseño estéticamente agradable aumenta la sensación de facilidad de uso, lo que hace más
agradable el uso, y ello, finalmente, puede mejorar no sólo la usabilidad percibida, sino también
la efectiva. Aunque no influya directamente en la interacción, la estética es el factor que más
percibe el usuario. La simplicidad del diseño también es una noción estética.
La simetría y la armonía en las formas adecuadamente combinadas son la clave para que un
diseño se perciba como bello. La escuela de la Gestalt estudia cuestiones como la proximidad y
la semejanza, en función de las cuales podemos percibir como un todo áreas y contenidos
próximos y parecidos (Manchón, 2002).
Un error de algunos diseñadores consiste en centrarse únicamente en la estética, creando
páginas bellas pero difíciles de acceder o utilizar, buscando sólo el lucimiento personal, en lugar
de utilizar la estética como una herramienta más para mejorar la experiencia de usuario.
Buscabilidad (Findabiliby)
a. La cualidad de ser localizable o navegable.
b. El grado en el que un objeto particular es fácil de descubrir o localizar.
71

78. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 5. Diseño Web 20/03/07
c. El grado en el que un sistema o entorno apoya la navegación y recuperación (Morville, 2005).
De poco sirve una web que los usuarios no puedan encontrar. Todo lo demás falla si una web no
está visible, fácilmente localizable mediante los buscadores. Evidentemente, la buscabilidad de
un sitio está intimamente ligada con el resto de componentes. Si el sitio está bien hecho será
más fácil de encontrar.
Una buena buscabilidad requiere:
• Definición.
• Distinción.
• Diferencia.
Ello se consigue utilizando adecuadamente las palabras, como etiquetas, como palabras clave.
Algunos de los aspectos que mejoran la buscabilidad de un sitio son:
• Utilizar texto en lugar de imágenes para representar los conceptos clave.
• Emplear un texto en el título (etiqueta ‘title’) descriptivo pero no muy largo. En las
primeras palabras debe describirse el sitio.
• Ofrecer un buen lema. Descriptivo, más largo que el título. Que cuente lo que el
usuario encontrará en la web.
• Brindar contenido interesante, que atraiga enlaces externos, a ser posible de sitios que
sean visibles en la red.
• Utilizar encabezados (h1, h2…) para estructurar documentos y elegir bien los
descriptores a emplear en ellos, pues los buscadores les dan más importancia a las
palabras que ahí aparecen.
• Cuidar la rotulación de los enlaces. Que tengan claro significado semántico. Ese texto
es muy importante para la navegación y para ser registrados por los buscadores (véase
el efecto Google bombing).
• Centrarse en los productos (contenidos) más importantes en lugar de mostrarlos todos
a primer nivel.
Arquitectura de la información
1.- La combinación de organización, etiquetado y esquemas de navegación dentro de un sistema
de navegación.
2.- El diseño estructural de un espacio de información que facilite la finalización de tareas y el
acceso intuitivo a los contenidos.
3.- El arte y la ciencia de estructurar y clasificar los sitios web y las intranets para ayudar a las
personas a encontrar y gestionar la información. [PERMOR01].
Una vez encontrado un sitio web y entrado en él es preciso localizar exactamente lo que se
busca. La forma en la que estén organizados los contenidos y la estructura de navegación será
fundamental para que se logre el éxito o no. Así, estructura y organización son las cuestiones
clave.
Por tanto, son funciones de la Arquitectura de la información [BAE01]:
• Idea general de organización del sitio.
• Sistema organizacional de productos.
• Etiquetado para las categorías de producto.
• Navegación global.
Diseño de Interacción
Diseño de interacción es la creación de interfaces que realizan un diálogo (interacción) entre la
persona y un sistema interactivo, un producto inteligente. Es la parte del diseño orientada a los
procesos más que a su presentación.
72

79. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 5. Diseño Web 20/03/07
Cuando se realizan operaciones en la web tales como comprar un billete de avión, realizar una
transacción económica, etc. es el diseño de interacción el que ha de velar para que todo el
proceso se realice de forma adecuada, sin fallos, y que el usuario sea capaz, en todo momento,
de saber exactamente que está haciendo y cómo puede hacer lo que desea.
Evaluación de la Usabilidad
Hay diferentes maneras de estudiar y medir la usabilidad. Buena parte de ellas son
complementarias entre sí. Las dos principales técnicas son el estudio heurístico y el test de
usuarios.
El test heurístico lo realiza un grupo de expertos, siguiendo un cuestionario de evaluación con
una lista de pautas o criterios (heurísticos) que verificar [JACNIEL03].
El test de usuarios registra los problemas que encuentran los usuarios cuando tratan de
realizar las acciones concretas propuestas por el evaluador, así como los tiempos
empleados en cada una de ellas [PETMOR03].
Aunque se puede hacer de forma más sofisticada, para realizar un test de usuarios aceptable
puede bastar con 4 ó 5 usuarios y tomar notas en una libreta. Ambos test se deben hacer en las
primeras fases de desarrollo. Es preferible hacer primero el test heurístico, para detectar fallos
graves, y tras el primer rediseño hacer el test de usuarios, para encontrar fallos más difíciles de
detectar.
También hay otros métodos de evaluación, y técnicas relacionadas con la mejora de la
usabilidad o de alguno de sus aspectos específicos.
La técnica de card sorting (ordenación de tarjetas), resulta útil para planificar o mejorar la
organización de contenidos de un sitio. Consiste en entregar a los usuarios un paquete de
tarjetas con las posibles categorías del sitio, para que ellos las ordenen y organicen en los grupos
que consideren más afines entre sí.
Así, a partir de varios usuarios que realicen este ejercicio se puede extraer un patrón que tener
en cuenta para ordenar las categorías del sitio.
La evaluación de Accesibilidad se realiza de forma manual y mediante herramientas
automáticas, si bien las automáticas sólo son capaces de revisar ciertos aspectos. El objetivo es
determinar el grado de cumplimiento de las pautas de accesibilidad.
Hay tres grados de cumplimiento:
• A. Si se cumplen las pautas de accesibilidad de nivel 1. Los sitios web TIENEN que
cumplir estas pautas.
• AA. Si se cumplen de las pautas de accesibilidad de nivel 2. Los sitios web DEBEN
cumplir estas pautas.
• AAA. Si se cumplen las pautas de accesibilidad de nivel 3. Los sitios web PUEDEN
cumplir estas pautas.
Por supuesto, hay otras técnicas y métodos, aunque no todos relacionados directamente con la
usabilidad. Y con esto se dá por concluido este apartado del proyecto dedicado a la usabilidad.
73

80. Fernando Leandro Baladrón Proyecto fin de carrera
Capitulo 6. Diseño Interface 20/03/07
CAPÍTULO 6
6. DISEÑO DE LA INTERFACE
Este apartado se divide en dos partes: primero se expondrán las clases con que se ha trabajado
en Visual Studio, pasando después a comentar el código implementado en ASP.NET,
subrayando los detalles de la programación desarrollada, así como explicando cuestiones tales
como ¿qué son los controles de usuario?.
Cuando se va a construir un sistema software es necesario conocer un lenguaje de
programación, pero con eso no basta. Si se quiere que el sistema sea robusto y mantenible es
necesario que el problema sea analizado y la solución sea cuidadosamente diseñada.
Se debe seguir un proceso robusto. Tal proceso de desarrollo se ocupa de plantear cómo se
realizan las distintas actividades, y cómo se relacionan los productos de las mismas. Con el uso
de un proceso de desarrollo adecuado la construcción de sistemas software va a poder ser
planificable y repetible, y la probabilidad de obtener un sistema de mejor calidad al final del
proceso aumenta considerablemente, especialmente cuando se trata de un equipo de desarrollo
formado por varias personas.
Para este proyecto se va a seguir un proceso de desarrollo orientado a objetos. Este proceso no
fija una metodología estricta, sino que define una serie de actividades que pueden realizarse en
cada fase, las cuales deben adaptarse según las condiciones del proyecto que se esté llevando a
cabo.
6.1. Clases
Primero se necesita definir el concepto de objeto. Un objeto es un software que representa un
objeto de la realidad, y que por lo tanto permite realizar mejores modelos que los obtenidos con
fórmulas y tablas. Los objetos pueden representar tanto objetos físicos (piezas de un avión o un
computador) como conceptos (una vídeo conferencia). Los objetos pueden ser sencillos y
pequeños (enteros y caracteres) o grandes y complejos (conjunto de documentos).
Como en la vida real, los objetos pueden construirse a partir de otros objetos, creando "objetos
compuestos". Así, los resultados técnicos de una conferencia se componen de documentos, o
una cuenta de estudiante incluye todas las asignaturas en las que está matriculado dicho
estudiante. Cada elemento de información se considera como un objeto, que se agrupan con
otros objetos, para formar un objeto compuesto. Existen, por supuesto, unos objetos básicos
(enteros, reales, tiras de caracteres,...), que sirven de base para la construcción de otros objetos.
Los objetos consisten de datos, código y una interfaz. En el código (llamado cuerpo) se
especifican los detalles de cada operación (también se usa método). La interfaz consiste en el
nombre y parámetros de las operaciones y describe como se puede manipular el objeto, es decir,
su comportamiento. Con el uso de los objetos, el desarrollo de aplicaciones se parece a un
proceso de ensamblaje con código y datos reusables.
Una clase es un grupo de objetos que modela una misma cosa o concepto. Es una categoría de
objetos del mundo real. Así, mujeres y hombres son personas, y pueden formar la clase
"persona". Esta clase define los datos y el comportamiento a seguir por cada "persona". La
colección de objetos en clases es una forma útil para comprender como se modelan los
conceptos básicos.
73

81. Fernando Leandro Baladrón Proyecto fin de carrera
Capitulo 6. Diseño Interface 20/03/07
Una clase nueva puede ser una "subclase" de una o varias clases existentes. La subclase hereda
todos los datos y métodos, es decir, el comportamiento de la clase padre. La herencia facilita los
cambios incrementales de las clases sin romper con la funcionalidad existente. Por ejemplo,
tanto "clientes" como "estudiantes" son tipos específicos de "personas".Todas las personas
tienen nombre y dirección, pero los estudiantes se matriculan, y los clientes compran. En
algunos casos convendrá tratar a los estudiantes como de la clase persona, pero en otras
aplicaciones lo relevante será en qué se matriculan.
C# .NET ofrece herencia, interfaces y sobrecarga, que lo convierten en un eficaz lenguaje de
programación orientado a objetos.
C# .NET admite el concepto de herencia y le permite definir clases que sirven de base para las
clases derivadas. Las clases derivadas heredan, y pueden extender, las propiedades y los
métodos de la clase base. También pueden reemplazar métodos heredados con nuevas
implementaciones. De forma predeterminada, todas las clases creadas con C# .NET son
heredables. Puesto que los formularios que diseña son realmente clases, puede utilizar la
herencia para definir nuevos formularios basados en formularios existentes.
Un objeto es una combinación de código y datos que puede tratarse como una unidad. Un objeto
puede ser una porción de una aplicación, como un control o un formulario. Una aplicación
entera puede también ser un objeto.
Los objetos permiten declarar variables y procedimientos una vez y utilizarlos siempre que sean
necesarios. Por ejemplo, si desea agregar un corrector ortográfico a una aplicación puede definir
todas las variables y funciones auxiliares para proporcionar a la aplicación funcionalidad de
corrección ortográfica. No obstante, si crea el corrector ortográfico como una clase, puede
volver a utilizarlo en otras aplicaciones mediante la inclusión de una referencia en el
ensamblado compilado. Aún mejor, tal vez pueda ahorrarse trabajo mediante el uso de una clase
de corrector ortográfico que otra persona ya ha desarrollado.
Cada objeto de C# .NET se define mediante una clase. Las clases describen los campos,
propiedades, métodos y eventos de un objeto. Los objetos son instancias de clases.
Lo primero que debemos hacer es buscar en la descripción de la aplicación y en la
especificación de requisitos las sustantivos que serán candidatos a convertirse en clases, para
nuestra aplicación se han desarrollado 13 clases:
1) Alumno: Clase creada para trabajar con los alumnos.
2) Archivo: Clase creada para trabajar con los archivos.
3) Area: Clase creada para trabajar con las áreas.
4) Aviso: Clase creada para trabajar con los avisos.
5) Categoria: Clase creada para trabajar con las categorías.
6) Centro: Clase creada para trabajar con los centros.
7) Enlace: Clase creada para trabajar con los enlaces.
8) Estado: Clase creada para trabajar con los estados.
9) Incidencia: Clase creada para trabajar con las incidencias.
10) Item: Clase creada para trabajar con los items.
11) Personal Clase creada para trabajar con el personal.
12) SubArea: Clase creada para trabajar con las Subareas.
13) Titulacion: Clase creada para trabajar con las búsquedas.
En todos los constructores de las clases se crea la conexión a la base de datos:
74

82. Fernando Leandro Baladrón Proyecto fin de carrera
Capitulo 6. Diseño Interface 20/03/07
static SqlConnection connWebceuWeb = Utilidades.Utilidades.conectarUCH();
Public SqlConnection ConectarUCH()
{ SqlConnection miconn = New SqlClient.SqlConnection
//creo los parámetros de la conexión
Try
{ miconn.ConnectionString = "Data Source=.;" & _
"Initial Catalog=web;" & _
"Integrated Security=true"
}
Catch (Exception ex)
{ throw new Eception(ex, "utilidad ADO conectar")
}
Return miconn
}
Aquí especificaría la cadena de conexión
1) Clase Subárea:
En esta clase se controlan las Subáreas que tenemos en nuestro centro de asistencia.
En todas las clases siempre se hace lo mismo: primero declaramos los campos que va a tener, y
después los métodos.
private int _id; //Identificador autonúmerico del SubArea
private string _titulo; //Titulo de la SubArea
private int _orden; //El orden en el que queremos que aparezca
private Area _area; //Área a la que pertenece
Este sería un ejemplo de una de los métodos que tiene implementada la clase Subárea este
método llama al procedimiento almacenado “sp_insertar_CentroAsistencia_SubArea” de la
base de datos donde le pasa como entrada el Título, el orden y el identificador del Área a la que
pertenece. Es importante resaltar que es la clase la que llama al procedimiento almacenado para
la inserción.
cmdInsertarSubArea.Parameters["@SAREA_Id"].Value = 0;
cmdInsertarSubArea.Parameters["@SAREA_Titulo"].Value = titulo;
cmdInsertarSubArea.Parameters["@SAREA_Orden"].Value = orden;
cmdInsertarSubArea.Parameters["@SAREA_AREA_ID"].Value = idArea;
connWebceuWeb.Open();
cmdInsertarSubArea.ExecuteNonQuery();
id = int.Parse(cmdInsertarSubArea.Parameters["@SAREA_Id"].Value.ToString());
}
catch (Exception ex)
{
Utilidades.Utilidades.guardarError(Ruta, ex, "CLASES CENTRO DE ASISTENCIA");
}
finally
{connWebceuWeb.Close();}
75

83. Fernando Leandro Baladrón Proyecto fin de carrera
Capitulo 6. Diseño Interface 20/03/07
}
El resto de métodos son:
BorrarSubArea()
ModificarSubArea()
ObtenerSubArea_todos()
ObtenerSubAreaPorArea()
2) Clase items:
En esta clase se controla las ítems generados por los alumnos.
Por un lado declaro los campos con su tipo:
private int _id; //Identificador del Item
private Incidencia _incidencia; //Incidencia
private string _descripcion; //Descripción del problema
private string _resolucion; //resolucion del Item, FAQ´s
private DateTime _fechaIni; //fecha inicio del Item NO NULA
private DateTime _fechaFin; //fecha fin del Item
private Estado _estado; //Estado del Item
//puede tener un aviso generado (Anotaciones pendientes)
private System.Collections.ArrayList _aviso;
//puede tener más de una categoria asignada
private System.Collections.ArrayList _categoria;
//puede tener más de un archivo asignada
private System.Collections.ArrayList _archivo;
//puede tener mas de una url asignada
private System.Collections.ArrayList _url;
private Personal _personal; //personal
private Alumno _alumno; //alumno
private int _visitas; //numero de visitas
private int _prioridad; //de 0..5
Y por el otro los métodos:
Métodos:
BorrarItem()
InsertarItem()
ModificarItem()
ObtenerArchivo()
ObtenerArchivoPorItem()
ObtenerAviso()
ObtenerAvisoPorItem()
ObtenerCategoria()
ObtenerCategoriaPorItem()
ObtenerEnlace()
ObtenerEnlacePorItem()
ObtenerItem_todos()
ObtenerItemPorAlumno()
ObtenerItemPorEstado()
ObtenerItemPorIncidencia()
ObtenerItemPorPersonal()
QuitarArchivo()
QuitarArchivo_todos()
76

84. Fernando Leandro Baladrón Proyecto fin de carrera
Capitulo 6. Diseño Interface 20/03/07
QuitarAviso()
QuitarAviso_todos()
QuitarCategoria()
QuitarCategoria_todos()
QuitarEnlace()
QuitarEnlace_todos()
AsociarArchivo()
AsociarArchivo_todos()
AsociarAviso()
AsociarAviso_todos()
AsociarCategoria()
AsociarCategoria_todos()
AsociarEnlace()
AsociarEnlace_todos()
Como ejemplo, presentamos los métodos obtenerItem_todos y borrarItem.
public static DataView ObtenerItem_todos()
{
DataTable dt = new DataTable();
DataView dvItem_todos = null;
try
{
connWebceuWeb.Open();
SqlDataAdapter Adapter = new SqlDataAdapter(cmdObtenerItem_todos);
Adapter.Fill(dt);
dvItem_todos = new DataView(dt);
dvItem_todos.AllowNew = false;
dvItem_todos.AllowEdit = false;
return dvItem;
}
Ver como en realidad la función borrarItem lo único que hace es llamar a un procedimiento que
está en la base de satos que se llama “sp_borrar_CentroAsistencia_Item” pasándole el
identificador del item que se desea borrar.
cmdBorrarItem.Parameters["@ITEM_Id"].Value = this.id;
connWebceuWeb.Open();
cmdBorrarItem.ExecuteNonQuery();
connWebceuWeb.Close();
3) Clase incidencia: prácticamente ya se han comentado todos los conceptos importantes en las
dos clases anteriores.
Por un lado los campos:
private int _id;
77

85. Fernando Leandro Baladrón Proyecto fin de carrera
Capitulo 6. Diseño Interface 20/03/07
private string _cod; //codigo de la Incidencia
private string _titulo; //titulo de la Incidencia
private SubArea _subArea; //subArea a la que pertenece la Incidencia
private int _prioridad; //prioridad de la incidencia
Y luego los métodos:
BorrarIncidencia()
InsertarIncidencia()
ModificarIncidencia()
ObtenerIncidencia_15primeros()
ObtenerIncidencia_todos()
ObtenerIncidencia_todos_Filtro()
ObtenerIncidenciaPorFiltro()
ObtenerIncidenciaPorPrioridad()
ObtenerIncidenciaPorSubArea()
ObtenerIncidenciaPorTexto()
En el siguiente método se presenta un último ejemplo con modificar.
cmdModificarIncidencia.Parameters["@INC_Id"].Value = 0;
cmdModificarIncidencia.Parameters["@INC_Cod"].Value = cod;
cmdModificarIncidencia.Parameters["@INC_Titulo"].Value = titulo;
cmdModificarIncidencia.Parameters["@INC_SAREA_ID"].Value = sareaId;
cmdModificarIncidencia.Parameters["@INC_Prioridad"].Value = prioridad;
connWebceuWeb.Open();
cmdModificarIncidencia.ExecuteNonQuery();
}
catch (Exception ex)
{
Utilidades.Utilidades.guardarError(Ruta , ex , "CLASES CENTRO DE ASISTENCIA");
}
finally
{
connWebceuWeb.Close();
4) Clase Alumno:
BorrarAlumno()
InsertarAlumno()
ModificarAlumno()
ObtenerAlumno_10primeros()
ObtenerAlumno_todos()
ObtenerAlumno_todos_Filtro()
ObtenerAlumnoPorEmail()
ObtenerAlumnoPorTitulacion()
5)Clase Aviso: en esta clase tendremos los avisos generados.
78

86. Fernando Leandro Baladrón Proyecto fin de carrera
Capitulo 6. Diseño Interface 20/03/07
BorrarAviso()
InsertarAviso()
ModificarAviso()
ObtenerAviso_todos()
ObtenerAviso_todos_Filtro()
ObtenerAvisoPorFiltro()
ObtenerAvisoPorTexto()
En la figura siguiente se muestra una captura de cómo nos quedaría la implementación de las
clases en la aplicación de programación Visual Studio.NET. Decir también que se han generado
15 clases en total, las cuales trabajan con 20 tablas de la base de datos y 120 procedimientos
almacenados.
Fig. 6.1.1 Desarrollo de las clases en Visual Studio .NET
Como resultado de la implementación de las clases se obtendrá el nivel lógico o de aplicación
del portal que estará formado por la librería generada a partir de la implementación de las
clases. Esta librería realiza diversas funciones relacionadas con operaciones de cálculo,
comprobación de condiciones y niveles de acceso, generación de peticiones a la base de datos,
transformación y validación de datos, etc.
Este nivel permite una independencia entre el nivel de interfaz y el nivel de persistencia, de
forma que sería posible realizar cambios importantes en dicho nivel (por ejemplo, cambiar el
sistema de gestión de la base de datos incluso sustituir la propia base de datos por otro sistema
de almacenamiento) sin que esto afectase en absoluto al nivel de interfaz, simplemente
realizando algunos cambios en el nivel lógico para adaptarse al nuevo nivel que tiene por
debajo.
Esta librería generada a partir de las clases se ocupará de agrupar una serie de operaciones que
podrán ser accedidas desde cualquier otra parte del código de la aplicación. Esto nos permitirá
rebajar la cantidad de código de la aplicación al reutilizar el código de esta librería. También
nos permitirá que al hacer un cambio en la librería el cambio aparezca automáticamente en
todas las paginas.
79

87. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 6. Diseño Interface 20/03/07
6.2. PROGRAMACIÓN EN ASP.NET
En este apartado se subrayan los detalles de la programación desarrollada, presentando los
fragmentos de código que se han considerado interesantes.
Llegados a este punto es importante saber que el diseño del portal web se ha basado en una
arquitectura multicapa de tres capas lógicas:
• Nivel de presentación o de interfaz al usuario.
• Nivel lógico o de aplicación.
• Nivel de persistencia.
El nivel de interfaz está formado por todos los documentos que envía el servidor del portal al
navegador y que éste presenta al usuario, de forma que le proporcionan la información que ha
solicitado acerca del portal y le permite interactuar con el mismo a través de enlaces y
formularios.
El nivel de aplicación o lógico está formado por un conjunto de librerías que implementan las
clases del dominio. Este nivel es el encargado de realizar todas las operaciones a nivel de
aplicación.
El nivel de persistencia lo forman la base de datos y el SGBD, los encargados de almacenar toda
la información del portal y de permitir el acceso a la misma de forma controlada y segura.
Visual Studio .NET nos ha permitido desarrollar el nivel de interfaz. El lenguaje bajo el que se
ha desarrollado la aplicación es C#.NET.
C# (pronunciado en inglés “C Sharp”, en español “C Sostenido”, y más popularmente como “C
Almohadilla”) es el nuevo lenguaje diseñado por Microsoft para su plataforma .NET. En
concreto, ha sido diseñado por Scott Wiltamuth y Anders Hejlsberg, éste último también
conocido por haber sido el diseñador del lenguaje Turbo Pascal y la herramienta RAD Delphi.
Aunque en realidad es posible escribir código para la plataforma .NET en muchos otros
lenguajes, como Visual Basic.NET o JScript.NET, C# es el único que ha sido diseñado
específicamente para ser utilizado en esta plataforma, por lo que programarla usando C# es
mucho más sencillo e intuitivo que hacerlo con cualquiera de los otros lenguajes. Por esta razón,
Microsoft suele referirse a C# como el lenguaje nativo de .NET, y de hecho gran parte de la
librería de clases base de .NET ha sido escrito en este lenguaje. C# es un lenguaje orientado a
objetos sencillo, moderno, amigable, intuitivo y fácilmente legible que ha sido diseñado por
Microsoft con el ambicioso objetivo de recoger las mejores características de muchos otros
lenguajes, fundamentalmente Visual Basic, Java y C++, y combinarlas en uno sólo en el que se
unan la alta productividad y facilidad de aprendizaje de Visual Basic con la potencia de C++.
Aunque actualmente no se consiguen prestaciones en velocidad tan altas como usando el C++
tradicional, Microsoft asegura que en futuras versiones se irá aumentando la eficiencia del
lenguaje, gracias fundamentalmente a la posibilidad de generar dinámicamente código
optimizado para aprovechar las características de la máquina sobre la que se ejecute el
programa.
Quizás el más directo competidor de C# es Java, lenguaje con el que guarda un enorme
parecido en sus sintaxis y características. En este aspecto, es importante señalar que C#
incorpora muchos elementos de los que Java carece (sistema de tipos homogéneo, propiedades,
indexadotes, tablas multidimensionales, operadores redefinibles, etc.) y que según los
80

88. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 6. Diseño Interface 20/03/07
benchmarks realizados la velocidad de ejecución del código escrito en C# es ligeramente
superior a su respectiva versión en Java.
A continuación se recoge de manera resumida las principales características de C#. No se van a
detallar completamente todas las características del lenguaje, sino que la intención es mostrar
una visión general del lenguaje:
- Dispone de todas las características propias de cualquier lenguaje orientado a objetos:
encapsulación, herencia y polimorfismo.
- Ofrece un modelo de programación orientada a objetos homogéneo, en el que todo el código
se escribe dentro de clases y todos los tipos de datos, incluso los básicos, son clases de que
heredan de System.Object (por lo que los métodos definidos en ésta son comunes a todos los
tipos del lenguaje).
- Permite definir estructuras, que son clases un tanto especiales; sus objetos se almacenan en
pila, por lo que se trabaja con ellos directamente y no referencias al montículo, lo que permite
accederlos más rápido. Sin embargo, esta mayor eficiencia en sus accesos tiene también sus
inconvenientes, fundamentalmente que el tiempo necesario para pasarlas como parámetros a
métodos es mayor (hay que copiar su valor completo y no sólo una referencia) y no admiten
herencia (aunque sí implementación de interfaces).
- Es un lenguaje fuertemente tipado, lo que significa que controla todas las conversiones entre
tipos se realicen de forma compatible, lo que asegura que nunca se acceda fuera del espacio de
memoria ocupado por un objeto. Así se evitan frecuentes errores de programación y se consigue
que los programas no puedan poner en peligro la integridad de otras aplicaciones.
- Tiene a su disposición un recolector de basura que libera al programador de la tarea de tener
que eliminar las referencias a objetos que dejen de ser útiles, encargándose de ello éste y
evitándose así que se agote la memoria porque al programador se le olvide liberar objetos
inútiles o que se produzcan errores porque el programador libere áreas de memoria ya liberadas
y reasignadas.
- Incluye soporte nativo para eventos y delegados. Los delegados son similares a los punteros a
funciones de otros lenguajes como C++ aunque más cercanos a la orientación a objetos, y los
eventos son mecanismos mediante los cuales los objetos pueden notificar de la ocurrencia de
sucesos. Los eventos suelen usarse en combinación con los delegados para el diseño de
interfaces gráficas de usuario, con lo que se proporciona al programador un mecanismo cómodo
para escribir códigos de respuesta a los diferentes eventos que puedan surgir a lo largo de la
ejecución de la aplicación (pulsación de un botón, modificación de un texto, etc.).
- Incorpora propiedades, que son un mecanismo que permite el acceso controlado a miembros
de una clase tal y como si de campos públicos se tratasen. Gracias a ellas se evita la pérdida de
legibilidad que en otros lenguajes causa la utilización de métodos set() y get() pero se mantienen
todas las ventajas de un acceso controlado por estos proporcionada.
- Permite la definición del significado de los operadores básicos del lenguaje (+, -, *, &, ==,
etc.) para nuestros propios tipos de datos, lo que facilita enormemente tanto la legibilidad de las
aplicaciones como el esfuerzo necesario para escribirlas. Es más, se puede incluso definir el
significado del operador [ ] en cualquier clase, lo que permite acceder a sus objetos tal y como si
fuesen tablas. A la definición de éste último operador se le denomina indicador, y es
especialmente útil a la hora de escribir o trabajar con colecciones de objetos.
81

89. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 6. Diseño Interface 20/03/07
- Admite unos elementos llamados atributos que no son miembros de las clases sino
información sobre éstas que podemos incluir en su declaración. Por ejemplo, indican si un
miembro de una clase ha de aparecer en la ventana de propiedades de Visual Studio.NET, cuáles
son los valores admitidos para cada miembro en ésta, etc.
Como conclusión podremos decir que C#.NET es un lenguaje orientado a objetos de sintaxis
fácil y programación complicada, cuya peculiaridad radica en que se trata de un lenguaje con un
amplio entorno visual, de forma que permite realizar rápidamente un prototipo. C#.Net posee
módulos, clases, excepciones, llamadas al sistema y gran cantidad de componentes.
Todas las páginas generadas bajo Visual Studio .NET tendrán la extensión ASPX. Lo siguiente
que haremos será definir ASPX (Active Server Pages Framework, páginas de servidor activas)
que es una tecnología de Microsoft para hacer scripts del lado del servidor. Con páginas HTML
simples, el cliente pide una página de un servidor (www.cualsea.com). El servidor se la envía y,
la página es mostrada en el navegador.
Los scripts ASPX, en cambio, se ejecutan antes de ser enviados. Si se utiliza un servidor
Microsoft, lo único que se ha de hacer es crear un archivo en el servidor con extensión .ASPX.
Cuando el cliente pida la página, el servidor sólo la preprocesará y la enviará.
El código ASPX se puede conectar a una base de datos (Access, SQL, Oracle, o cualquiera que
cumpla ODBC) e insertar dinámicamente los datos en el HTML. Esto lleva a unas grandes
posibilidades en el terreno del comercio electrónico, sitios Web personalizables, sistemas de
entrada y salida de datos a través de Internet.
Esta tecnología es la base de la nueva plataforma de desarrollo de Microsoft y promete darle a
los creadores de sitios y aplicaciones web un nivel de control y flexibilidad sin precedentes al
momento de desarrollar sus sitios.
Una de las razones por las que hemos elegido Visual Studio .NET es por la capacidad de escribir
aplicaciones ASP.NET en lenguajes como VB.NET, C#, JScript.NET y muchos otros.
Otra de las razones es por la amplia gama de controles en el servidor para formularios Web
además Visual Studio ofrece un amplio soporte para XML.
Y la última razón y la más importante es por la creación de poderosos objetos de negocios
(DLLs compilados) para aplicaciones Web.
A continuación pasaremos a detallar como se ha implementado la aplicación con Visual Studio
.NET parándose con más detalle en las peculiaridades que se consideren más relevantes.
6.2.1 Distribución de las carpetas
Una de las cosas que se ha cuidado en el desarrollo es la correcta y ordenada estructuración de
carpetas del proyecto. Con esta práctica se consigue tener bien clasificado el proyecto
facilitando así su mantenimiento. Dentro de esta estructura de carpetas cabe destacar la carpeta
denominada “controles” donde se guardaran todos los controles relativos a la aplicación. Por
otro lado en la carpeta “reports” se guardarán todos los informes realizados con la herramienta
Cristal Reports que nos permitirán realizar listados en función de las necesidades del cliente. En
la carpeta “logs” se almacenan todos los errores generados por la aplicación, esto es muy útil
teniendo en cuenta que en la primera etapa de vida de la aplicación se generan muchos errores
que son necesarios controlar, con esto se conseguirá tener constancia de todos ellos. Y por
último la carpeta “archivos_subidos” en la cual se harán dos divisiones una para imágenes y otra
82

90. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 6. Diseño Interface 20/03/07
para documentos, en dicha carpeta se almacenaran todos los ficheros subidos a través de la
aplicación.
Después de haber mencionado la palabra controles será importante definir que es un control. Un
control es un pequeño trozo de un formulario que luego invocaremos desde los diferentes
formularios, gracias a un control se nos permite modularizar en código y en diseño. Todo lo que
se modifique en ese control será automáticamente actualizado en todos los formularios que lo
invoquen.
Para incluir un control de usuario en un formulario se deberán incluir las etiquetas declarativas
del control y el atributo runat="server".
Destacar que en la aplicación se ha incluido un control denominado FreeTextBox, este control
es gratuito y nos permite la inclusión en nuestro formularios de un editor del tipo Microsoft
Office gracias a este el usuario podrá maquetar los textos de forma fácil y equivalente a la que
hace con el Microsoft Word. Para su uso tendremos que referenciar en nuestro proyecto la
librería facilitada en la web de los autores del control, además de incluir la carpeta “textbox”
con todo el material necesario para el correcto funcionamiento de dicho control.
En la figura siguiente (Fig.6.1) se nos muestra de forma visual un resumen de todo lo
comentado anteriormente.
83

91. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 6. Diseño Interface 20/03/07
Fig.6.2.1.Distribución de las carpeta en Visual Studio .NET
Después de comentada la estructura de carpetas pasaremos a ver con más detalles el
funcionamiento básico de un formulario de edición. En la figura 6.3 se nos muestra un ejemplo
de formulario de edición donde además tenemos los controles anteriormente comentados, en
este caso aparecen tres controles, uno para la inserción de archivos, otro para la asignación de
enlaces ya existentes y un último para la inserción de enlaces nuevos.
El listado de los documentos se hace con la herramienta datagrid, la cual nos muestra los datos
en formato de tabla, esta herramienta nos permite especificar que columnas queremos visualizar
y cual es el origen de los datos del mismo. En nuestro caso el origen de los datos nos lo
facilitará la clase implementada para ello, la cual nos devuelve un dataset con todos los registros
84

92. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 6. Diseño Interface 20/03/07
a listar. Destacar también que gracias a la lógica de negocio se consigue que el código de
nuestros formularios quede muy simple y limpio, ya que la totalidad del código de acceso a
datos y su manipulación están implementados en dicha clase.
Será necesario conocer la definición de dataset. Un dataset es un conjunto de datos similar a la
de una base de datos relacional; el dataset expone un modelo jerárquico de tablas, filas y
columnas. Además, contiene restricciones y relaciones definidas para el conjunto de datos.
Los filtros los implementamos con la propiedad rowfilter de la vista generada para el dataset,
con rowfilter se le puede especificar en una consulta sql por que campo se quiere filtrar.
Fig.6.2.2.Formulario de edición desarrollado en Visual Studio .NET
Dentro del listado generado por el datagrid se tendrán campos elaborados que no se obtienen
directamente del dataset y que requieren de un tratamiento, esto se conseguirá con la etiqueta
del datagrid llamada itemtemplate, la cual nos permitira invocar a funciones que se preparen
para la correcta visualización de esa columna, para el resto de campos que no requieran de
tratamiento se hará con la etiqueta boundcolumn. Con la etiqueta headerText se especificara el
texto para el encabezado de la columna.
Se quiere destacar una función la cual se encarga de que al rellenar el datagrid de comprobar el
tiempo transcurrido desde que se creo la pregunta, dependiendo de ese tiempo asigna un
personal de resolución u otro, además cuando el personal de resolución cambia porque el nivel
ha excedido su tiempo, avisa al nuevo personal de resolución.
85

93. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 6. Diseño Interface 20/03/07
6.2.2 CONTROLES DE USUARIO
Dada su importancia se ha decidido dedicarle un apartado a este tema. Los controles de usuario
ofrecen una forma sencilla de dividir y reutilizar funciones de interfaz de usuario comunes entre
las aplicaciones Web ASP.NET.
Gracias a los controles de usuario podemos crear fácilmente nuestros propios controles
personalizados y reutilizables.
Los que se han utilizado en este trabajo han sido entre otros los siguientes: "calendario" es un
control para el calendario que mostramos en la aplicación, "populares" es un listado con los
items más populares, "recientes" es un listado con los items más recientes, "itemCorto" se
muestra la información resumida de un item, "buscador.ascx" en este control tenemos
implementado la funcionalidad del buscador, "area.ascx" aquí nos encontramos toda la
información relativa al área, "sarea.ascx" y en este toda la información relativa a la subárea, en
"incidencia.ascx" tendremos toda la información relativa a la incidencia, "cabecera.ascx" se
muestra toda la información de la cabecera de nuestra aplicación, "pie.ascx" esta guardada toda
la información relativa al pie de la página, "gridItems.ascx" donde se tiene un datagrid con los
ítems, "itemInfo.ascx" donde se muestra la información del item, y por úlitmo "migasPan.ascx"
donde está definida la herramienta para las migas de pan o breadcrumbs que ya hemos
explicado en el apartado de usabilidad.
Hay dos formas de cargar un control. La primera sería indicándoselo en el código html de la
siguiente forma:
Al principio de la página ponemos el siguiente código para registrar el control:
<%@Register TagPrefix="Control" TagName="Menu" Src="CtrMenu.ascx"%>
<%@Register TagPrefix="Control" TagName="Buscar" Src="CtrBuscar.ascx"%>
<%@Register TagPrefix="Control" TagName="Calendar" Src="CtrCalendar.ascx"%>
Luego, desde la celda de la tabla que se desee, lo cargamos referenciándolo con su etiqueta
correspondiente:
<td id="LeftPane3" vAlign="top" align="left" width="20%" runat="server">
<CONTROL:BUSCAR id="Buscar1" runat="server"></CONTROL:BUSCAR></td>
Una vez realizados dichos pasos, se podrá trabajar con el control a través de código, para el caso
que por ejemplo se quisiera ocultar o presentar un control en concreto de nuestro formulario,
dicha situación se haría mediante la sentencia Page.Request.QueryString["itemId"], que lo que
hace es evaluar la cadena url que sirve el navegador, desde la aplicación se programará para
que dependiendo de si tiene o no valor se oculte o muestre un control u otro.
//Se activa el Control con las Información del Item
if (Page.Request.QueryString["itemId"] != null)
{itemInfo1.Visible = true;}
else
{//Se Activa el control con las SubAreas (2ºBloque)
if (Page.Request.QueryString["areaId"] != null)
{area1.Visible = true;}
else
{//Se Activa el Control con las Incidencias (3ºBloque)
if (Page.Request.QueryString["sareaId"] != null)
{incidencia1.Visible = true;}
86

94. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 6. Diseño Interface 20/03/07
En el ejemplo anterior se carga en el centro un control u otro dependiendo del valor de la
variable que nos devuelva la cadena url.
6.2.3. INSERCIÓN DE LOS ITEMS
Empezaremos introduciendo el código implementado para la introducción de nuevos grupos en
nuestra base de datos. Utilizaremos este ejemplo para mostrar como hemos ido guardando los
diferentes datos en nuestra base de datos mediante parámetros.
ItemLargo.ascx
Fig.6.2.3 Diseño del formulario de inserción de Items
Hay que realzar que se ha trabajado con la herramienta RequiredFieldValidator para validar los
diferentes campos del formulario. Esta herramienta permite asociarle un campo a controlar del
formulario, de esta forma si el campo no cumple los requisitos se disparará avisando al usuario
con el mensaje que se le indique.
6.2.4. SUBIR UN ARCHIVO
Seguidamente pasaremos a mostrar el código usado para la “subida” de un documento al centro
de asistencia.
87

95. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 6. Diseño Interface 20/03/07
Para realizar esto se trabaja con un flujo de datos stream, el cual nos permite de forma fácil
guardar los documentos en el servidor. El primer paso será guardar en un stream el fichero
seleccionado por el usuario. Dicho fichero vendrá indicado gracias a la herramienta que se ha
utilizado llamada fileinput la cual nos permite acceder al fichero con el método postedfile. Y el
segundo paso será guardar ese stream en el servidor. En el siguiente ejemplo se muestra como
se ha realizado.
if (fileArchivo.PostedFile.FileName != "")
{ HttpPostedFile myFile = fileArchivo.PostedFile;
// Read file into a data stream
byte[] myData = new Byte[nFileLen];
myFile.InputStream.Read(myData, 0, nFileLen);
// Save the stream to disk
System.IO.FileStream newFile = new System.IO.FileStream(sSavePath +
sFilename, System.IO.FileMode.Create);
newFile.Write(myData, 0, myData.Length);
newFile.Close();
6.2.5. VISUALIZACIÓN DE LOS DATOS.
Pasamos ahora a mostrar el código referente a la visualización de los datos guardados en la base
de datos.
Para el listado de los datos se han utilizado varias herramientas, por un lado la del datagrid
anteriormente comentada, y por el otro la del repeater y la del datalist.
El código que se muestra a continuación corresponde al listado de los items utilizando la
herramienta repeater, destacar que el acceso a los campos que se desean mostrar se le indica
con las etiquetas container.dataitem:
<asp:repeater id="Repeater1" runat="server">
<ItemTemplate>
<tr>
<td class="ItemDetalleTexto">
<img src=".imagesicon.bmp">
<%# container.dataitem("ITEM_Titulo")%>
<%# container.dataitem("ITEM_Fecha")%>
</td>
</tr>
<tr>
<td class="ItemDetalleResumen">
<%#container.dataitem("ITEM_Descripcion")%>
</td>
</tr>
</ItemTemplate>
Al igual que el resto de la herramientas para la visualización (dataset,datalist), será necesario
indicarle el origen de los datos, esto se hará con el atributo datasource de la herramienta del
listado. Para el caso del ejemplo el origen de datos es la tabla “item” del dataset “DSItem”:
Repeater1.DataSource = DSItem.Tables("Item");
88

96. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 6. Diseño Interface 20/03/07
Recordar que el dataset con el que estamos trabajando lo obtenemos directamente de la lógica
de negocio.
Y un último ejemplo en este apartado sería el de los menús, que en este caso se está haciendo
con un datalist. Aquí se muestra todas las categorías de forma vertical, y cada vez que se
selecciona una de ellas le pasa en la url el identificador de la categoría:
<asp:datalist id="MyList" runat="server" EnableViewState="False"
width="80%" cellpadding="3" RepeatDirection="Vertical"
HorizontalAlign="Right">
<SelectedItemTemplate>
<a href='<%# "Default.aspx?IdCategoria=" &
DataBinder.Eval(Container.DataItem, "CAT_ID") %>'
class="Menu2Seleccionado">
<%# DataBinder.Eval(Container.DataItem, "CAT_Title") %>
</a></asp:HyperLink>
</SelectedItemTemplate>
<ItemTemplate>
<asp:HyperLink id=Hyperlink3 cssclass="Menu2SinSeleccionar"
runat="server" Text='<%# DataBinder.Eval(Container.DataItem,
"CAT_Title") %>' NavigateUrl='<%# "Default.aspx?IdCategoria=" &
DataBinder.Eval(Container.DataItem, "CAT_ID") %>'>
</asp:HyperLink>
</ItemTemplate>
</asp:datalist>
Además de esto hay que indicar en el código el origen de los datos que, en este caso, se
contempla al recurrir al dataset DSCategoria:
MyList.DataSource = DSCategoria;
MyList.DataBind();
6.2.6. IDENTIFICACIÓN DE LOS USUARIOS
Pasamos seguidamente a comentar el código realizado para identificar los usuarios en nuestra
aplicación, dando así acceso a los usuarios registrados.
Este es el código que se ejecutará al pulsar el botón “Entrar”, comprobando la identidad de los
usuarios.
Login.ascx
Session("OUsuario") = New ClsUsuario
If
CType(Session("OUsuario"),ClsUsuario).CalcularLogin(txtUsuario.Text,
txtPassword.Text) = True Then
'Usuario correcto
FormsAuthentication.RedirectFromLoginPage(txtUsuario.Text,
chkPersistentes.Checked)
89

97. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 6. Diseño Interface 20/03/07
Else
'Usuario no correcto o fallo de identificación
FormsAuthentication.SignOut()
Session("oUsuario") = Nothing
Response.Redirect("default.aspx", True)
End If
Las variables de tipo session se utilizaran cuando se quiera trabajar con variables, sin el
problema de tener que compartirlas al estilo: public integer i;
Las variables de tipo session no tienen tipo de datos asociado, por lo que sí luego queremos
asignarle un tipo haremos un cast de la siguiente forma: (Tipo) (session("i").
En el código anterior se trabaja con la variable oUsuario de tipo session. Las variables session
pueden ser de tipo objeto, en el ejemplo anterior convertimos esta variable de tipo session a la
clase usuario indicándosela entre paréntesis y, una vez convertida, llamamos al método
CalcularLogin de la clase usuario.
Otro aspecto a tener en cuenta para la autenticación de usuarios es añadir a web.config el
siguiente código:
Al estar este código en web.config, se ejecutará para todos los formularios.
<authentication mode="Forms">
<forms name=".ASPXAUTH" loginUrl="Default.aspx" protection="All"
timeout="60" />
</authentication>
<authorization>
<deny users="?" />
</authorization>
Gracias a esto en el formulario principal se activará el formulario del login. En el formulario
hay que importar el namespace: using System.web.security.;
6.2.7. OBTENER ITEMS
En esta sección se utilizará como ejemplo el código del formulariob ItemInfo.ascx
En este caso se le pasa a través de la url el identificador del item. Eso se comprobaba con el
método Page.Request.QueryString
if (!Page.IsPostBack)
{
if (Page.Request.QueryString["itemId"] != null)
{itemId = int.Parse(Page.Request.QueryString["itemId"]);
Item item = new Item(itemId);
txtId.Text = item.id.ToString();
txtTitulo.Text = item.Titulo.ToString();
freeTxtDescripcion.Text = item.Descripcion.ToString();
freeTxtResolucion.Text = item.Resolucion.ToString();}
}
90

98. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 6. Diseño Interface 20/03/07
Si es la primera vez que cargamos la página, el IsPostBack se encarga de preguntar si es la
primera vez que se cargó la página y además, comprueba que el identificador proporcionado es
positivo. Una vez realizado esta tarea se hace una llamada al constructor de la clase item que
nos devolverá un objeto a través del cual podremos acceder a todos sus atributos.
6.2.8. TEMAS ADICIONALES
En esta sección se tratarán algunos aspectos importantes no contemplados en las secciones
anteriores.
Relativo a la captura de errores, se hace con este tipo de estructura de código:
Try {
...........CÓDIGO..........
}
Catch (Exception ex)
{ Utilidades.guardarError(ex.Message);
}
Utilidades es una librería implementada para su uso en este proyecto y para futuros proyectos,
con funciones de tipologia variada. Una de las funciones que tiene se encarga de guardar los
errores en una base de datos y en un fichero log, avisando al administrador del sistema de que se
ha producido dicho error.
En cuanto al diseño del Calendario, este viene especificado en el siguiente código:
<asp:calendar id="Cal" runat="server" CssClass="CalendarText"
FirstDayOfWeek="Monday" ForeColor="#C0C0FF"
DayNameFormat="FirstTwoLetters" BorderColor="White" Font-Names="Arial"
Font-Size="XX-Small" BorderStyle="Solid" ShowNextPrevMonth="False"
ShowTitle="False" BorderWidth="5px">
<todaydaystyle Font-Bold="True" ForeColor="White"
BackColor="#990000"></todaydaystyle>
<daystyle BorderWidth="2px" ForeColor="#666666" BorderStyle="Solid"
BorderColor="White" BackColor="#EAEAEA"></daystyle>
<dayheaderstyle ForeColor="#649CBA"></dayheaderstyle>
<selecteddaystyle Font-Bold="True" ForeColor="#333333"
BackColor="#FAAD50"></selecteddaystyle>
<weekenddaystyle ForeColor="White" BackColor="#BBBBBB"></weekenddaystyle>
<othermonthdaystyle ForeColor="#666666" BackColor="White"></othermonthdaystyle>
</asp:calendar>
Relativo a la cadena de conexión, indicar que se puede colocar en el fichero de configuración
global web.config, tal y como se indica en el ejemplo siguiente, no obstante no se ha
considerado conveniente hacerlo de este modo por ser dicho fichero público:
<?xml version="1.0" encoding="utf-8" ?>
91

99. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 6. Diseño Interface 20/03/07
<configuration>
<!-- application specific settings -->
<appSettings>
<add key="ConnectionString" value="workstation id=FERNANDO;packet
size=4096;integrated security=true; initial catalog=DocuNews" />
</appSettings>
La principal ventaja que se obtienen al trabajar de esta forma es que el mantenimiento de la
aplicación se hace mucho más sencillo, puesto que con modificar los parámetros de la conexión
en web.config estos se cambian en toda la aplicación.
Cuando un usuario autorizado pulsa sobre el enlace para eliminar una item, se ha puesto una
ventana con un mensaje de confirmación. Esto se consigue gracias al siguiente código
JavaScript, el cual antes de realizar la operación de borrado pregunta que se desea hacer:
Button2.Attributes.Add("onClick", "javascript:return confirm('¿esta seguro de borrar este item?');");
También se ha útilizado código JavaScript para cerrar una ventana del formulario al pulsar a un
boton llamado btncerrar.
btnCerrar.Attributes.Add("onClick", "javascript:window.close();");
Para obtener la dirección IP de la máquina desde la cual se hace la consulta, recurrimos a la
instrucción:
Request.UserHostAddress.ToString()
De esta forma, podemos almacenar todas las consultas que hacen nuestros usuarios
conjuntamente con su dirección IP.
Por otro lado, es interesante comentar que se ha trabajado con el servicio que proporciona
Microsoft Search (Index Server). Gracias a este servicio se obtiene toda la potencia para
realizar una búsqueda lingüística de caracteres de datos sobre una misma tabla. Una búsqueda
lingüística opera en palabras y frases, lo que permite buscar palabras o frases similares, distintas
formas de una palabra, o palabras que se encuentren relativamente cercanas.
Para poder realizar consultas complejas, lo primero que se tiene que hacer es habilitar la base de
datos.
sp_fulltext_database 'enable'
El segundo paso consiste en habilitar la búsqueda de texto en las tablas deseadas. Para activar
una tabla hay que recurrir a instrucciones del tipo:
sp_fulltext_table 'Item', 'activate'
Para verificar que efectivamente se ha actualizado la base de datos con la propiedad de consulta
de texto se ejecuta la siguiente consulta:
SELECT DATABASEPROPERTY('CentroAsistencia','IsFullTextEnabled')
Para crear el catálogo de texto se utiliza el siguiente procedimiento almacenado:
92

100. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 6. Diseño Interface 20/03/07
sp_fulltext_catalog 'Item', 'create'
Una vez realizados los pasos anteriores se podrán efectuar consultas utilizando el servicio
Microsoft Search. Un ejemplo de consulta con el operador CONTAINS podría ser:
DSItem = MiItem.leeDataSet("select * from ItemWHERE CONTAINS( Item_Descripcion, '" &
Request.Params("Descripcion").ToString & "')")
Este operador utiliza una notación funcional en la que el primer parámetro es el nombre de la
columna en la cual se realiza la búsqueda, y el segundo parámetro es una condición de búsqueda
de texto. De esta forma se consigue realizar búsquedas más complejas que con el operador
LIKE.
93

101. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 7 .Conclusiones 20/03/07
CAPÍTULO 7
7. Conclusiones y trabajo futuro
7.1 Conclusiones
Mucho tiempo ha pasado desde que empecé a realizar este proyecto y durante el proceso son
muchas las experiencias he tenido durante este tiempo. Entre ellas puedo destacar la ilusión de
poner en práctica todo lo aprendido durante el estudio de la carrera, las ganas de aprender cosas
nuevas, pero también el aburrimiento ante las tareas monótonas e incluso a veces desesperación
cuando algo no funcionaba bien o era muy costoso.
Ha sido muy duro y laborioso seguir todos los procesos para la realización del proyecto:
especificación, análisis, diseño, etc. Pero al final siempre esta la satisfacción del trabajo
acabado. Además durante el desarrollo de la aplicación he aprendido un sinfín de nuevas
técnicas, lenguajes y otros conocimientos que me ayudaran en un futuro para próximos
proyectos.
La aplicación en su estado actual no se puede considerar como acabada porque puede tener
numerosas ampliaciones. Siempre hay algo mas que se puede añadir para aumentar su
funcionalidad y sin duda alguna estas mejoras podrían alargarse durante mucho tiempo. Pero
llegado un momento en que se debe dar por concluida una etapa y pasar a otros proyectos.
En este punto se hará un resumen que ofrezca una visión global de lo que ha sido la consecución
de la memoria del proyecto, la cual se ha dividido en cinco niveles en forma piramidal.
En el primer nivel, que hemos llamado introducción, se ha comenzando con una introducción en
la que se comenta el interés de dicha aplicación, a que usuarios va dirigida, y con que lenguajes
ha sido implementada.
También en este nivel se ha realizado el estudio de la metodología ITIL, presentando aquí una
breve explicación junto con la especificación de este standard, concretando los niveles que lo
componen. La utilización de este conjunto de buenas prácticas ha repercutido directamente
sobre el diseño de la base de datos.
Una de las principales normas de ITIL es la de que toda institución tiene que tener un punto de
acceso claramente diferenciado donde el cliente pueda realizar sus consultas o dudas al respecto,
gracias a esta aplicación se consigue cumplir una de las principales requisitos para implementar
ITIL.
Nos hemos encontrado con que ITIL es uno de los estándares cada vez más demandados y con
mayor factor de éxito en las impresas lo cual siempre es una garantía de ir por buen camino.
Otra de las cosas a destacar es que a pesar de que el idioma predominante en la web es el inglés,
nos hemos encontrado con muchos documentos en español, destacar la web [WHITPAP01] por
haber sido de gran interés para la búsqueda de información en el desarrollo del proyecto.
El segundo nivel está dedicado al diseño de la base de datos. Aquí hemos abarcado el análisis de
los requerimientos, centrándonos después en el diseño conceptual y el diseño lógico,
presentando finalmente presentamos el diagrama UML. Dentro de este mismo nivel se
95

102. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 7 .Conclusiones 20/03/07
encuentran los procedimientos implementados en el sistema de gestión de bases de datos que ha
sido, en nuestro caso, SQL SERVER 2000 SP4.
Después del diseño de la base de datos pasamos al tercer nivel. En este nivel comienza uno de
los grandes bloques del trabajo como buen profesional del mundo de la web, el correspondiente
al diseño web. Comenzamos este punto resaltando la importancia del diseño de la página web,
detallando que estructura vamos a llevar a cabo y como tiene que estar organizada la
información. Terminado este apartado pasamos a comentar la hoja de estilos utilizada, decisiva
en el aspecto final de la página.
El cuarto nivel está dedicado al diseño de la interface entre el sistema de gestión de bases de
datos y el servidor web. Puesto que Visual Studio .Net soporta la metodología orientada objetos,
se ha aprovechado la potencia de dicha tecnología al trabajar con clases. Dentro de este bloque
se presenta la programación desarrollada en ASP.NET para darle funcionalidad a la página web.
Destacar dentro de la programación el desarrollo de una utilidad desarrollada con clases en
visual Studio .NET, para guardar todos los errores que se vayan generando en la aplicación, de
esta forma se tienen constancia de todos los errores que se producen y de correcta corrección.
En el quinto y último nivel nos hemos dedicado a la documentación del proyecto, fase laboriosa
y de gran enriquecimiento donde se me ha confirmado que es necesaria para el correcto
mantenimiento de la aplicación desarrollada. Y por último decir que no se concibe un proyecto
como tal sin una adecuada selección de la bibliografía consultada, ya sea en formato papel o
electrónico.
Para mi la labor más dura ha sido una de las más necesarias, la de documentar todo el trabajo
realizado, tarea fundamental y que luego es de vital importancia para el continuo desarrollo del
proyecto.
Dentro de los anexos, todos ellos importantes, tenemos un primer documento con el análisis de
requisitos IEEE. El siguiente anexo es un estudio de la gestión del servicio en ITIL y un tercer
anexo, también determinante en nuestro portal, es la hoja de estilos empleada en el diseño del
portal web.
Respecto a la ejecución de este proyecto en concreto, se ha podido valorar la importancia de
realizar todos los pasos del mismo de forma meticulosa y completa, ya que se ha podido
constatar que cualquier olvido o error en una etapa anterior, ha supuesto la necesidad de
modificar cosas y volver atrás en todo momento.
Si bien es cierto que a priori no siempre es posible tener clara la visión final del sistema, es
importante que ya desde el principio ésta sea lo mas certera posible, ya que de este modo se
evitan correcciones y tiempo perdido, lo cual viene a demostrar una vez más, que es mejor
perder un poco de tiempo en aspectos fundamentales como son el análisis de requisitos o el
modelado de objetos, pues en conjunto siempre se acaba ganando.
Y como no, la importancia de tener un trato continuo con el cliente, en este caso el director de
proyecto para no perder el rumbo y realizar las correcciones mínimas oportunas para evitar
incurrir en errores de concepto o malas interpretaciones.
Un resumen de todo lo explicado anteriormente se refleja en el siguiente gráfico:
96

103. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 7 .Conclusiones 20/03/07
Fig 7.1 Fases de la documentación del proyecto
El principal beneficio obtenido tras la realización de este proyecto es la satisfacción de haber
creado una aplicación capaz de albergar todas las incidencias que se generan en una universidad
utilizando uno de los lenguajes más utilizados hoy en día, como es el ASP.NET. Hay que
resaltar también el uso de unos de los estándares cada vez más extendidos, como es ITIL.
Uno de los logros obtenidos en este proyecto es el de la interfaz gráfica, sencilla para el usuario
común ya que se basa en un sistema típico web que, al ser muy intuitivo, es fácilmente
controlable por parte de los usuarios.
El tiempo estimado para la realización de este proyecto ha sido de 600 horas repartidas,
aproximadamente, de la siguiente forma:
El 30% del total de las horas de trabajo ha sido invertido en el análisis y aprendizaje del uso de
ASP .NET. Este aprendizaje a sido constante y continuado a lo largo de la implementación de la
aplicación.
Al trabajo relacionado con la captura de requisitos de la aplicación, generación de la Base de
Datos y diseño de la aplicación se ha dedicado un 20% del tiempo total.
A la implementación de la interfaz gráfica de usuario se ha dedicado un 10% del tiempo total.
Para la generación de la documentación se ha dedicado un 10% del tiempo total, siendo
generada de forma continuada a lo largo de la implementación de la aplicación.
La codificación y funcionalidad de la aplicación han requerido un 30% del tiempo total.
El equipo de trabajo ha estado compuesto por tres personas, un director encargado de de
planificar, organizar y controlar el trabajo diario del servicio. Un informático en cuyo puesto me
encuentro yo encargado de la programación y desarrollo de las diferentes aplicaciones que en su
mayoría son gestores de contenidos y una tercera persona que es el diseñador dedicada a realizar
en photoshop los bocetos y maquetar en html las web resultantes.
Además tenemos dos becarios dedicados a temas de diseño y otro dos becarios dedicados a
temas de programación, una de las labores en la que los becarios de programación han
colaborado activamente es la de testear los programas.
97

104. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 7 .Conclusiones 20/03/07
La forma de trabajar ha sido la siguiente tras sucesivas reuniones con el director de informática,
donde se hizo un estudio de lo que se estaba pidiendo y el tiempo requerido, se ha realizado un
diseño boceto de lo que se quería por parte del diseñador, una vez hecho esto el informático se
encargó de hacer un diseño de la base de datos que se iba a requerir ajustándose a las demandas
y requerimientos solicitados, una vez realizado esto se paso a implementar la aplicación de
gestión de los datos, para una vez finalizado implementar la aplicación de visualización de los
datos.
Recordar que el objetivo del proyecto era el de realizar un centro de asistencia enfocado a una
universidad donde los alumnos pudieran solicitar todas aquellas dudas, problemas, incidencias
que tuvieran, consiguiendo así tener registrados todos aquellos problemas que se generan en un
entorno universitario. A este proyecto se le sumo la motivación de asumir estándares
internacionales como es ITIL, este conjunto de buenas prácticas ha sido un garante de éxito de la
aplicación. Por otra parte no hay que olvidar que otra de las grandes motivaciones del proyecto
era la de evitar la gran generación de documentos impresos y acumulados en secretaría general,
muchos de ellos repetitivos y lentamente administrados.
Para finalizar decir que el trabajar con la metodología de tres capas me ha confirmado que
aunque sea más lento, generar primero la lógica de negocio genera muchas más ventajas a largo
plazo. Una de las mayores ventajas que se ha encontrado con esta práctica es que luego
tengamos todo el código de la gestión muy limpio y fácilmente modularizable.
7.2 TRABAJO FUTURO
En un futuro se estudia la integración con Skype. Se está popularizando el concepto de
eSupport. Skype es una herramienta que permite la comunicación on-line y la videoconferencia.
Destacar dentro de esta iniciativa a la aplicación [PERDES01], la cual ofrece a sus clientes este
servicio.
Otra las líneas del futuro es la aplicación de técnicas de Inteligencia Artificial. Se tiende hacía el
Help Desk inteligente que te responda automáticamente, destacar en este punto la iniciativa de
la empresa de muebles y decoración IKEA que ha apostado fuertemente por un robot virtual
llamado Ana, el cual te responde a tus preguntas de forma on-line. [IKEA01]. Este proyecto
podría ser el futuro de investigaciones en el reconocimiento automático de palabras.
Otra de las mejoras pendientes es la asignación del personal de resolución. Dentro de la
universidad se genera una cantidad de información enorme y es necesario que esté
correctamente clasificada para la gestión de las incidencias. Se considera un problema definir
los niveles de resolución de las incidencias en la organización. También al haber tantos tipos de
incidencias es importante que queden correctamente clasificadas y una vez hecho esto que a su
vez estén correctamente asignadas.
Otra de los inconvenientes con el que nos hemos encontrado es la dificultad de lanzar la
aplicación por no haber clasificado bien toda la información. Un trabajo futuro será el de
realizar un estudio exhaustivo de la información que está albergada en la base de conocimiento
y de cuantos clicks hacen falta para su acceso. En la aplicación se almacenan todas las
búsquedas realizadas por los usuarios, esta información será muy valiosa para hacer el trabajo
de clasificación.
Otro de los trabajos posibles, es el paso de test de usuarios. Al pasar una serie de tests de
usabilidad podremos asegurarnos que los usuarios entienden nuestro portal y no realizan
esfuerzos adicionales para comprender el contenido de la página. Procuraremos asegurar que el
portal está, sobre todo, enfocado al usuario. Se pueden pasar encuestas a los usuarios
preguntándoles que dudas han tenido, que les ha gustado, y que no. De esta forma
98

105. Fernando Leandro Baladrón Proyecto fin de carrera
Capítulo 7 .Conclusiones 20/03/07
conseguiremos analizar el comportamiento de los usuarios, así como definir con exactitud las
necesidades reales de los visitantes de la página.
Y finalmente decir que me he dado cuenta lo importante que es saber vender un proyecto,
puedes haber desarrollado una labor magnífica pero si ese proyecto no viene acompañado de
una correcta campaña de concienciación de que es necesario se puede tirar a la basura. Muchas
veces el cliente tiene la percepción de que se le va ha dar más trabajo, cuando es totalmente lo
contrario, hay que dejar claro al cliente que esa aplicación es por y para él, y que la aplicación
va ha ser una herramienta que le va ha facilitar su trabajo diario.
Otro de los trabajos futuros es la integración del centro de asistencia con otras aplicaciones para
que de esta forma se generen las incidencias de forma automática, el futuro del éxito será en
apostar por la integración con el resto de aplicaciones.
Para acabar me gustaría finalizar con las tres frases con las que termine mi presentación: “Todo
está conectado con todo” de Tim Berners-Lee. “En la construcción de la Universidad hay que
partir del estudiante” de Ortega y Gasset y por último “El conocimiento no conoce frontera” de
Peter Drucker.
99

106. Fernando Leandro Baladrón Proyecto fin de carrera
Bibliografía 20/03/07
BIBLIOGRAFÍA
[DELKAL01] Delaney, Kalen. “A fondo Microsoft SQL Server 2000”. Madrid. McGraw-
Hill/Interamericana de España, 2001.
[GRIFJOHN01] Griffin, John. “Creación de sitios Web con XML y SQL Server 2000”. Madrid.
Prentice-Hall, 2002.
[MRIPAR01] Mridula, Parihar. “La biblia de ASP .NET” . Anaya. ISBN 8441513856
[CHAROJ01] Charte Ojeda, Francisco. Serrano Pérez, Jorge. “Programación con Visual Studio
.Net”.Anaya.. ISBN 8441513767
[EN97] Elmasri, R.; Navathe, B. “Sistemas de bases de datos. Conceptos fundamentales”
Addison-Wesley Iberoamericana. 2ª edición 1997.
[MCC94] Mota, L.; Celma, M.; Casamayor, J. C.; “Bases de datos relacionales: teoría y
diseño”. SPUPV 767.94, 1994+
[JOSCH01] Joseph Schmuller. “Aprendiendo UML en 24 horas” (Ed. Prentice Hall)
[PETMOR01] Peter Morville y Louis Rosenfeld. “Arquitectura de la información para el WWW
(1998)”.
[JAKNIEL01] Jakob Nielsen. “Usabilidad : diseño de sitios Web (2000)”.
[JEFVEEN01] Jeffrey Veen . “The Art and Science of Web Design (2001)”.
[GAR01] Garrett. “The elements of user experience: user-centered design for the Web (2002)”.
[JAKNIEL02] Jakob Nielsen y Marie Tahir. “Usabilidad de páginas de inicio: análisis de 50
sititos Web (2002)”.
[PATLYN01] Patrick J. Lynch y Sarah Horton. “Web Style Guide (2002)”.
[PETMOR02] Peter Morville. “Information architecture : blueprints for the Web (2003)”.
[SANJAY01] Sanjay J. Koyani, Robert W. Bailey, Janice R. Nall. “Research-based Web
Design and usability guidelines (2003)”.
[BAE01] Baeza Yates, R.; Rivera Lozaia, C.; Velasco Martín, J. “Arquitectura de la
información y usabilidad en la Web”.
[PETMOR03] Peter Morville. “Ambient findability (2005)”.
[CASMAR01] Casado Martínez, C. Mor Pera, E.; Sabaté Jardí, Ll. "Accesibilidad en la Web".
Mosaic, 2006, nº 47.
[JAKNIEL03] Jakob Nielsen, Hoa Loranger. “Usabilidad : prioridad en el diseño Web (2006)”.
98

107. Fernando Leandro Baladrón Proyecto fin de carrera
Bibliografía 20/03/07
RECURSOS ITIL
[ISCJ01] Information Systems Control Journal. "ITIL in a complex world: focusing on success
in a multisourced environment", 2006, vol. 1, pp. 38-9.
[BARG01] Barash, G., Bartolilli, C. & Wu, L. 2007, "Measuring and improving the
performance of an IT support organization in managing service incidents", INFORMATION
TECHNOLOGY MANAGEMENT FROM A BUSINESS PERSPECTIVE, , pp. 11-18.
[BENK01] Bender, K. 2004, "Value based assessment of ITIL deployment projects",
Information Management & Consulting, vol. 19, no. 1, pp. 36-8.
[BITZELD01] Bitzel, D. & Igelbrink, C. 2004, "ITIL and the IT service culture", Information
Management & Consulting, vol. 19, no. 1, pp. 27-30.
[BRENNER01] Brenner, M. 2006, "Classifying ITIL processes - A taxonomy under tool support
aspects", First IEEE/IFIP International Workshop on Business-Driven IT Management, BDIM
2006, vol. 2006, pp. 19-28.
[CHONG01] Chongshan, R. & Ping, Z. 2006, "Business's IT resource service system based on
ITIL", Journal of Wuhan University of Technology (Information & Management Engineering),
vol. 28, no. 5, pp. 80-3.
[CONNOR01] Connor, J. 2006, "What is ITIL?", Software World, vol. 37, no. 5, pp. 3-5.
[FEGT01] Feglar, T. 2004, "ITIL based service level management if SLAs cover security",
ISAS/CITSA 2004: INTERNATIONAL CONFERENCE ON CYBERNETICS AND
INFORMATION TECHNOLOGIES, SYSTEMS AND APPLICATIONS AND 10TH
INTERNATIONAL CONFERENCE ON INFORMATION SYSTEMS ANALYSIS AND
SYNTHESIS, VOL 3, PROCEEDINGS, vol. 3, pp. 225-230.
[FORTD01] Forte, D. 2007, "Security standardization in incident management: the ITIL
approach".
[HAENA01] Hanemann, A. 2007, "Refining ITIL/eTOM processes for automation in service
fault management", INFORMATION TECHNOLOGY MANAGEMENT FROM A
BUSINESS PERSPECTIVE, , pp. 106-107.
[HOCHA01] Hochstein, A., Zarnekow, R. & Brenner, W. 2005, "ITIL as common practice
reference model for IT service management: formal assessment and implications for practice",
e-Technology, e-Commerce and e-Service, 2005.EEE '05.Proceedings.The 2005 IEEE
International Conference on, pp. 704-710.
[HOCHA02] Hochstein, A., Zarnekow, R. & Brenner, W. 2004, "ITIL as common practice
reference model IT service management - Formal evaluation and implications for practice",
vol. 46, pp. 382-389.
99

108. Fernando Leandro Baladrón Proyecto fin de carrera
Bibliografía 20/03/07
[HOCHA03] Hochstein, A. & Zarnekow, R.1. 2004, "Case study on City of Cologne,
rearranging its internal IT service provider by adapting best practices according to IT
Infrastructure Library (ITIL)", Information Management & Consulting, vol. 19, no. 1, pp. 47-
51.
[HOCH04] Hochstein-A, Zarnekow-R & Brenner-W "ITIL as common practice reference model
IT service management - Formal evaluation and implications for practice",
WIRTSCHAFTSINFORMATIK-, vol. Engineering-Computing-and-Technology; 46, no. 5, pp.
382.
[HOMM01] Hommel, U. 2004, "Standardized service offerings for IT infrastructures with ITIL
- SAP IT services and application management", Information Management & Consulting, vol.
19, no. 1, pp. 10-13.
[ISHI01] Ishibashi, K. 2007, "Maintaining quality of service based on ITIL-based IT service
management", FUJITSU SCIENTIFIC & TECHNICAL JOURNAL, vol. 43, no. 3, pp. 334-
344.
[JANT01] Jantti, M. & Eerola, A. 2006, "A conceptual model of IT service problem
management", 2006 INTERNATIONAL CONFERENCE ON SERVICE SYSTEMS AND
SERVICE MANAGMENT, VOLS 1 AND 2, PROCEEDINGS, vol. 1, pp. 798-803.
[KARHUN01] Karhunen, H., Eerola, A. & Jantti, M. 2006, "Improving service management in
supply chains", 2006 INTERNATIONAL CONFERENCE ON SERVICE SYSTEMS AND
SERVICE MANAGMENT, VOLS 1 AND 2, PROCEEDINGS, vol. 1, pp. 1415-1420.
[KASHAN01] Kashanchi-R & Toland-J "Can ITIL contribute to IT/business alignment? An
initial investigation", WIRTSCHAFTSINFORMATIK-, vol. Engineering-Computing-and-
Technology; 48, no. 5, pp. 340.
[KRAJN01] Krajnc, T. 2005, "ITIL - IT services management", Organizacija, vol. 38, no. 6, pp.
302-8.
[LIUHAI01] Liu Hai-feng & Lian Yi-feng1 2007, "Architecture for network security operation
management based on ITIL", Computer Engineering and Applications, vol. 43, no. 9, pp. 193-7.
[MARH01] Marquis, H. 2007, "ITIL and the evolving CMDB", Business Communications
Review, vol. 37, no. 2, pp. 54-7.
[MCNB01] McNaughton, B. & Ray, P. 2006, "Evaluation of IT Service Management from an
organisational perspective", WEBIST 2006: PROCEEDINGS OF THE SECOND
INTERNATIONAL CONFERENCE ON WEB INFORMATION SYSTEMS AND
TECHNOLOGIES, , pp. 140-152.
[MOUA01] Moura, A. & Sauve, J. 2007, "Research challenges of business-driven IT
management", INFORMATION TECHNOLOGY MANAGEMENT FROM A BUSINESS
PERSPECTIVE, , pp. 19-28.
100

109. Fernando Leandro Baladrón Proyecto fin de carrera
Bibliografía 20/03/07
[PELP01] Pela, P. 2006, "ITIL helps keep network fit", Communications News, vol. 43, no. 2,
pp. 32.
[SANK01] Sangani, K. 2006, "ITIL: share and share alike?", Information Professional, vol. 3,
no. 1, pp. 32-5.
[SCHAT01] Schaaf, T. 2007, "The IT infrastructure library (ITIL) - An introduction for
practitioners and researchers", INTER-DOMAIN MANAGEMENT, PROCEEDINGS, vol.
4543, pp. 235-235.
[STAH01] Staudt, H. 2003, "ITIL standardizes IT service processes", Information Management
& Consulting, vol. 18, no. 4, pp. 63-7.
[VANSAN01] Van Sante, T. & van der Pols, R. 2006, "Guide to choice of a standard [ITIL,
ASL and CobiT]", Informatie, vol. 48, no. 10, pp. 38-42.
[TSO01] TSO. “ITIL the key to managing IT services”. Application management London: TSO,
2005.Best practices series
[WANS01] Wan, S.H.C. & Chan, Y. 2007, "IT Service Management for campus environment -
practical concerns in implementation", 10th IFIP/IEEE International Symposium on Integrated
Network Management 2007, IM '07, , pp. 709-712.
[WANJ01] Wang, J. & Su, H. 2006, "ITIL implement and evaluation", TWELFTH ISSAT
INTERNATIONAL CONFERENCE RELIABILITY AND QUALITY IN DESIGN,
PROCEEDINGS, , pp. 289-291.
[ZHENW01] Zhen, W. & Xin-yu, Z. 2007, "An ITIL-based IT Service Management Model for
Chinese Universities", Software Engineering Research, Management & Applications,
2007.SERA 2007.5th ACIS International Conference on, , pp. 493-497.
RECURSOS ELECTRÓNICOS
[DEMHEL01] Demohelpdesk. Aplicación demo. on-line http://www.demohelpdesk.com/
[HELDES01] Helpdeskpro.net. Aplicación demo.on-line http://www.helpdeskpro.net/tryit.htm
[NAVNET01] Navigatoris.net. Aplicación demo. on-line
http://www.navigatoris.net/support/index.php?languageid=2
[ISOSOL01] Isolsoft. Aplicación demo. on-line. http://www.isolsoft.com/demo/
[PERDES01] PerlDesk. Aplicación demo. on-line. http://www.perldesk.com/demo.0.html
[CRMDES01]CrmDesk. Aplicación demo. on-line. http://www.crmdesk.com/demo.htm
[JITBIT01] Jitbit.com. versión en ASPX. Aplicación demo. on-line
http://www.jitbit.com/helpdesk.aspx
101

110. Fernando Leandro Baladrón Proyecto fin de carrera
Bibliografía 20/03/07
[SERDES01] Servicedeskplus.com. Aplicación demo. on-line.
http://demo.servicedeskplus.com/
[CODEP01] The Code Project. http://www.codeproject.com.
[PROGCOM01] Programación.com http://www.programacion.com.
[ASPFAC01] ASP Fácil. http://www.aspfacil.com
[KEENS01] Keene System, Inc. http://www.sql-server-vb-asp.net.
[MICNET01] Tutoriales de Microsoft .NET.
http://es.gotdotnet.com/quickstart/aspplus/doc/webdatabinding.aspx
[MILIU01] Miliuco .NET http://www.miliuco.net/indexpnetasp.htm
[GUILLE01] El Guille .NET http://www.elguille.info/NET/default.aspx
[VILHUG01] Villada, Hugo. “Modelos de HELP Desk”. Biblioteca Foro Help Desk. www.foro-
helpdesk.com
[LAGJUD01] Laguardia , Judit. “Entender la cultura organizacional para implementar ITIL”
WhitePapers. www.foro-helpdesk.com
[WHITPAP01] WhitePapers. “Mejores prácticas diseñando Bases de Conocimiento”.
www.foro-helpdesk.com
[WHITPAP01] WhitePapers. Villada Hugo. “Modelos de Help Desk” WhitePapers. www.foro-
helpdesk.com
[WHITPAP01] WhitePapers. Laguardia Judit. “Entender la cultura organizacional para
implementar ITIL”. www.foro-helpdesk.com
[DUMB01]. Universidad de Malaga. “Aplicación de Help-Desk: Adaptación de ITIL a la
realidad de las universidades”.
www.crue.org/grupostrabajo/tecnologiasInformacion/ponencias/171006/Dumbo.ppt
[RONPAL01] Ron Palmer. "IT Service Management Foundations: ITIL Study Guide".
http://roxen.bizcom2.com/~author/Foundations/FoundationsPreview.pdf
[FERCAR01] Carlos Fernandez Baladrón. “Qué es ITIL?”
http://www.coit.es/publicaciones/bit/bit160/46-49.pdf
[IKEA01] IKEA, muebles y decoración. “Necesitas ayuda, pregúntale a Ana”.
http://www.ikea.com/es/es/
[ITILORG01] ITIL.org: The portal for information regarding ITIL and BS15000.
http://www.itil.org
[OGC01] Office of Government Commerce. http://www.ogc.gov.uk/itil
[ITSMF01] IT Service Management Forum. http://www.itsmf.es/index.asp?Page=1
[WIKI01] Wikipedia. The free enciclopedia libre. “ITIL”. http://es.wikipedia.org/wiki/ITIL
102

111. Fernando Leandro Baladrón Proyecto fin de carrera
Bibliografía 20/03/07
[eyetrack01] Eyetracking research. http://www.useit.com/eyetracking/
[ANYBRO01] Anybrowser. Comprobador de enlaces rotos.
http://www.anybrowser.com/linkchecker.html.
[W3CSS01] W3.org. Validador CSS. http://validator.w3.org/
[W3CSS02] W3.org. Validador CSS. http://jigsaw.w3.org/css-validator/.
[SIDAR01] Fundación SIDAR. Hojas de Estilo CSS. http://bd.ub.es/pub/termens/taller/css2-
es.pdf
103

112. Fernando Leandro Baladrón Proyecto fin de carrera
IEEE 20/03/07
ANEXO 1
Especificación
de
Requisitos de acuerdo a la norma
IEEE std 830 –1998:
IEEE Guide to Software Requirements
Specifications. IEEE Standards Board.
1

113. Fernando Leandro Baladrón Proyecto fin de carrera
IEEE 20/03/07
1.2 Especificación de requisitos de acuerdo a la norma IEEE
El objetivo de este punto es dejar claro desde el principio los requerimientos
y funcionalidades que va ha tener la aplicación. Para esto vamos a
especificar todas aquellas características y requisitos con los que queremos
dotar nuestra aplicación.
1.2.1 Introducción
1.2.1.1 Propósito
La aplicación consiste en la construcción de una aplicación para la
gestión de las incidencias generadas en la universidad, almacenando toda
la información en una una base de datos, debiendo dar la funcionalidad de
una página web de consulta a esa base de conocimiento. Dicha base de
datos permitirá introducir la información relativa a las incidencias
relacionando por áreas, subareas, categorías, archivos, enlaces, avisos,
etc.
El administrador de la aplicación será el encargado de gestionar las
tareas de mantenimiento y actualización de los datos.
1.1.2.2 Ámbito
Nuestra aplicación recibe el nombre de “HELP DESK CEU”.
Desempeñará el papel de gestionar y ordenar los datos introducidos por
el Administrador y usuarios para poder después mostrarlo a cualquier
visitante.
La aplicación dará la posibilidad de dar de alta a nuevos usuarios, y
estos podrán introducir nuevas items, modificarlas e incluso borrarlas.
1.1.2.3 Definiciones, acrónimos y abreviaturas
-ADMINISTRADOR: Encargado fundamentalmente de introducir las areas,
subareas, ver el estado de los items, modificarlos, borrarlos, crear las
categorías, asociar personal de resolución de incidencias, generar listados,
estadisticas.
-VISITANTE: Persona que visita la web de forma anónima.
-HITOS: Objetivo parcial que se alcanza una vez concluida una serie de
tareas.
-USUARIO: Persona que accede a la aplicación con derechos de
modificación y visualización de los items.
*Acrónimos:
2

114. Fernando Leandro Baladrón Proyecto fin de carrera
IEEE 20/03/07
-URL: Uniform Resource Locator.
-ASP: (Active server pages), páginas de servidor activo.
-IEEE: (Institute of Electrical & Electronics Engineers).
1.2.1.4 Referencias
-IEEE std 830 –1998 IEEE Guide to Software Requirements Specifications.
IEEE Standards Board.
-Guía del IEEE para la especificación de requerimientos software.
1.2.2. DESCRIPCIÓN GENERAL
1.2.2.1 Perspectiva del producto:
La aplicación HELP DESK CEU es una aplicación totalmente
independiente destinada a ejecutarse sobre cualquier PC que soporte un
sistema operativo Windows.
1.2.2.2 Funciones de producto:
a) Funciones especificas de los miembros:
a1) Funciones de gestión de información:
Añadir / Eliminar / Modificar Áreas.
Añadir / Eliminar/ Modificar SubÁreas.
Añadir / Eliminar/ Modificar Incidencias.
Añadir / Eliminar/ Modificar Items.
a2) Funciones de comprobación:
Verificar Login y Password del Personal, Alumno.
a3) Funciones personales de un Administrador:
Generación de Listados/Estadísticas.
Asignar Personal Resolución Incidencia.
b) Funciones de cualquier usuario:
b1) Funciones de búsqueda:
Consultar Items Por Estado.
Consultar Items Por Responsable.
Consultar Items Por Prioridad.
Consultar Items Por Categoría.
Consultar Items Por SubArea.
Consultar Items Por Area.
3

115. Fernando Leandro Baladrón Proyecto fin de carrera
IEEE 20/03/07
Consultar Items Por Fecha.
Consultar Items Por Centro.
Consultar Items Por Titulación.
Consultar Items Por Visitas.
Consultar Items Por Fecha más Recientes.
b2) Otras funciones:
Importación Automática de items formato RSS 2.0.
● Imagen Perfiles posibles:
1.2.2.3 Características del usuario:
Los usuarios que podrán utilizar el producto pueden ser:
- Cualquier persona que tenga acceso a Internet y tenga
curiosidad por conocer los items de actualidad.
- Un miembro perteneciente al grupo de administradores no
necesita ninguna formación especifica.
4

116. Fernando Leandro Baladrón Proyecto fin de carrera
IEEE 20/03/07
1.2.2.4 Restricciones generales:
La aplicación se realizará bajo el entorno ASP.NET con lo cual
vamos a utilizar el entorno Windows, luego no podemos hacer uso de
ninguna aplicación que no trabaje bajo dicho entorno. Además, solo
puede estar alojada en un servidor Windows.
1.2.2.5 Supuestos y dependencias:
Para utilizarlo necesitamos un servidor que procese nuestras
páginas ASP, para ello existe el Internet Information Server bajo
Windows NT o 2000.
1.2.3. REQUISITOS ESPECIFICOS.
1.2.3.1 Requisitos funcionales:
1.2.3.1.1 Añadir Área (Área):
-Introducción: El administrador podrá dar de alta una nueva
Área.
-Entrada: [Consultar Campos de entrada – consultar BD]
-Proceso: almacenar toda la información de la nueva área e
introducirla en la base de datos de la aplicación.
-Salida: Base de datos actualizada.
1.2.3.1.2 Eliminar Área (Área):
-Introducción: El Administrador puede dar de baja un área
existente.
-Entrada: El id del área que se quiere dar de baja.
-Proceso: sólo se podrá borrar si no existen SubÁreas
relacionadas con ese Área.
-Salida: En caso de que no existan Áreas relacionadas con ese
área la salida será la base de datos actualizada. En caso contrario se le
avisará al administrador de que la operación no se ha podido realizar por
existir subÁreas con el área que se desea borrar.
1.2.3.1.3 Modificar Área (Área):
-Introducción: modificar una área actualizando cualquier campo de
datos de dicha área.
-Entrada: Nombre del área que se desea modificar.
5

117. Fernando Leandro Baladrón Proyecto fin de carrera
IEEE 20/03/07
-Proceso: El Administrador, una vez identificado como tal, puede
modificar esa área en la base de datos.
-Salida: La base de datos actualizada.
1.2.3.1.4 Añadir SubÁrea (SubÁrea):
-Introducción: El administrador podrá dar de alta una nueva
SubÁrea.
-Entrada: [Consultar Campos de entrada – consultar BD]
-Proceso: almacenar toda la información de la nueva SubÁrea e
introducirla en la base de datos de la aplicación.
-Salida: Base de datos actualizada.
1.2.3.1.5 Eliminar SubÁrea (SubÁrea):
-Introducción: El Administrador puede dar de baja un SubÁrea
existente.
-Entrada: El id del SubÁrea que se quiere dar de baja.
-Proceso: sólo se podrá borrar si no existen Incidencias
relacionadas con ese SubÁrea.
-Salida: En caso de que no existan SubÁreas relacionadas con
ese SubÁrea la salida será la base de datos actualizada. En caso
contrario se le avisará al administrador de que la operación no se ha
podido realizar por existir Incidencias con la SubÁrea que se desea
borrar.
1.2.3.1.6 Modificar SubÁrea (SubÁrea):
-Introducción: modificar una SubÁrea actualizando cualquier
campo de datos de dicha SubÁrea.
-Entrada: Nombre del SubÁrea que se desea modificar.
-Proceso: El Administrador, una vez identificado como tal, puede
modificar esa SubÁrea en la base de datos.
-Salida: La base de datos actualizada.
1.2.3.1.7 Añadir Incidencia (Incidencia):
-Introducción: El Administrador y los usuarios autorizados
pueden insertar una Incidencia en la Base de datos.
-Entrada: [Consultar Campos de entrada – consultar BD]
-Proceso: Reestructurar la información para insertarla de forma
eficiente a la base de datos.
-Salida: La base de datos actualizada.
1.2.3.1.8 Eliminar Incidencia (Incidencia):
-Introducción: El Administrador y los usuarios autorizados
pueden eliminar incidencias.
-Entrada: El id de la Incidencia que se desea eliminar.
6

118. Fernando Leandro Baladrón Proyecto fin de carrera
IEEE 20/03/07
-Proceso: Comprobar que existe y si no existen ítems
asociados a dicha incidencia borrar ese registro de la base de datos.
-Salida: La base de datos actualizada.
1.2.3.1.9 Modificar Incidencia (Incidencia):
-Introducción: El Administrador y los usuarios autorizados
pueden modificar los datos de una incidencia.
-Entrada: Los campos de la incidencia que se desea modificar.
-Proceso: Comprobar que existe y modificar ese registro de la
base de datos.
-Salida: La base de datos actualizada.
1.2.3.1.10 Añadir Items (Items):
-Introducción: El Administrador y los usuarios autorizados
pueden insertar un Item en la Base de datos.
-Entrada: [Consultar Campos de entrada – consultar BD]
-Proceso: Reestructurar la información para insertarla de forma
eficiente a la base de datos.
-Salida: La base de datos actualizada.
1.2.3.1.11 Eliminar Items (Items):
-Introducción: El Administrador y los usuarios autorizados
pueden eliminar items.
-Entrada: El id de la Item que se desea eliminar.
-Proceso: Comprobar que existe y si no existen ítems
asociados a dicha incidencia borrar ese registro de la base de datos.
-Salida: La base de datos actualizada.
1.2.3.1.12 Modificar Items (Items):
-Introducción: El Administrador y los usuarios autorizados
pueden modificar los datos de un item.
-Entrada: Los campos del item que se desea modificar.
-Proceso: Comprobar que existe y modificar ese registro de la
base de datos.
-Salida: La base de datos actualizada.
1.2.3.1.13 Asignar Personal Resolución Incidencia:
-Introducción: Un Administrador podrá asignar que personal será
el encargado de resolver los diferentes ítems en base al subárea al que
pertenezca el item.
-Entrada: idPersonal, idItem, fechaPlazo.
-Proceso: A partir de los dos identificadores, se generará un
nuevo registro en la base de datos.
-Salida: Base de datos actualizada.
7

119. Fernando Leandro Baladrón Proyecto fin de carrera
IEEE 20/03/07
1.2.3.1.14 Consulta Ítems por Estado:
-Introducción: Busca un item a partir de un Estado
-Entrada: idEstado
-Proceso: El idEstado realizar la búsqueda de los diversos
registros de la base de datos.
-Salida: Base de datos actualizada.
1.2.3.1.15 Consultar Ítems Por Responsable:
-Introducción: Busca un item a partir de un Responsable
-Entrada: idResponsable
-Proceso: Con el responsable realizar la búsqueda de los diversos
registros de la base de datos.
-Salida: La página html con el resultado de la búsqueda realizada.
1.2.3.1.16 Consultar Ítems Por Prioridad:
-Introducción: Busca un item a partir de una prioridad
-Entrada: Prioridad
-Proceso: Con la prioridad, realizar la búsqueda de los diversos
registros de la base de datos.
-Salida: La página html con el resultado de la búsqueda realizada.
1.2.3.1.17 Consulta Ítems Por Categoría:
-Introducción: Busca un item a partir de un Categoría.
-Entrada: idCategoria.
-Proceso: con la Categoria realizar la búsqueda de los diversos
registros de la base de datos.
-Salida: La página html con el resultado de la búsqueda realizada.
1.2.3.1.18 Consultar Ítems Por SubÁrea:
-Introducción: A partir de un idSubArea buscar todas la ítems
-Entrada: idSubArea
-Proceso: Con ese idSubárea realizar la búsqueda de los diversos
registros de la base de datos.
-Salida: La pagina html con el resultado de la búsqueda realizada.
1.2.3.1.19 Consultar ítems por Área.
-Introducción: A partir de un Área, buscar los items de esa área.
-Entrada: idárea.
-Proceso: con ese idárea obtener todos los ítems que cumplan
esa condición.
-Salida: La pagina html con el resultado de la búsqueda realizada,
ordenando los registros por fecha de publicación.
1.2.3.1.20 Consultar items por Fecha:
8

120. Fernando Leandro Baladrón Proyecto fin de carrera
IEEE 20/03/07
-Introducción: A partir de una Fecha, obtener todos los items de
esa Fecha.
-Entrada: Fecha.
-Proceso: Con esa Fecha realizar la búsqueda de los diversos
registros de la base de datos.
-Salida: La pagina HTML con el resultado de la búsqueda
realizada
1.2.3.1.21 Consultar ítems por Centro:
-Introducción: búsqueda de items con ese idcentro
-Entrada: idcentro
-Proceso: Buscaremos aquellos registros que tengan ese mismo
idCentro.
-Salida: La página html con los items con Imagen.
1.2.3.1.22 Consultar ítems por Titulación:
-Introducción: A partir de un idTitulación, buscar los items con
igual idTitulacion.
-Entrada: idTitulacion
-Proceso: Con el idTitulación realizar la búsqueda de los diversos
registros de la base de datos.
-Salida: La pagina html ordenadas por valor de impacto.
1.2.3.1.23 Consultar ítems por Visitas:
-Introducción: A partir de unas palabras claves, buscar los items
con esas palabras clave.
-Entrada:no tiene.
-Proceso: Realizar la búsqueda de los diversos registros de la
base de datos con mas visitas.
-Salida: La página html con el resultado de la búsqueda realizada.
1.2.3.1.24 Consultar ítems por Fechas más recientes:
-Introducción: A partir de unas palabras claves, buscar los items
con esas palabras clave.
-Entrada: no tiene.
-Proceso: Realizar la búsqueda de los diversos registros de la
base de datos más recientes.
-Salida: La página html con el resultado de la búsqueda realizada.
1.2.3.2 Requisitos de la aplicación
1.2.3.2.1 Interfaces de usuario
9

121. Fernando Leandro Baladrón Proyecto fin de carrera
IEEE 20/03/07
La aplicación se visualizará con cualquier navegador, como puede
ser Internet Explorer, Netscape, Opera, Mozilla Firefox, etc.
Todo visitante anónimo tendrá acceso a todo el contenido de la
aplicación pero sin la posibilidad de realizar ningún cambio. Podrá
realizar consultas sobre la Base de datos, cuyo resultado de las
búsquedas será mostrado en el navegador.
Se presentarán distintos formularios con la información pertinente
en cada uno de ellos, donde el usuario podrá seleccionar las opciones
deseadas y, en caso de ser un usuario con acceso registrado, se le
permitirá la introducción y modificación de todos los datos que considere
oportunos, en cualquier sección de la Web que desee excepto en las
páginas personales del resto de los usuarios registrados.
Como miembro del grupo de Administradores se tendrá acceso a
dar de alta a otro Administrador, o a modificar sus datos personales.
1.2.3.2.2 Requisitos Hardware
No se necesitará un Hardware específicamente potente, bastará
con un equipo Hardware normal que cumpla los requisitos de SQL
Server y Internet Information Server (IIS).
1.2.3.2.3 Requisitos Software
El producto que estamos describiendo está desarrollado bajo el
sistema operativo Windows por el hecho de utilizar la tecnología de
Microsoft ASP .NET.
Del lado del cliente no será necesario trabajar bajo un entorno
Windows ya que lo que se genera son paginas HTML. Estas se pueden
visualizar con cualquier navegador independientemente del sistema
operativo utilizado.
1.2.3.2.4 Interfaces de comunicación
Tener conexión a Internet gracias a un módem (acceso remoto),
tarjeta de red u otro dispositivo.
1.2.3.3 Requisitos de eficiencia
Esta aplicación está pensada para que se pueda visualizar bajo
cualquier navegador.
El prototipo de HelpDesk se alojará en un servidor Windows.
1.2.4. Requerimientos específicos
1.2.4.1 Estándares cumplidos
10

122. Fernando Leandro Baladrón Proyecto fin de carrera
IEEE 20/03/07
El lenguaje utilizado para la anotación, definiciones y acrónimos
es el castellano, aunque para algunos campos de la base de datos
hemos utilizado el inglés.
1.2.4.2 Limitaciones Hardware
El PC que vaya a visualizar la aplicación debe disponer de una
interface de red o un módem para conectarse a Internet, bien sea a
través de una LAN o de una conexión directa a Internet.
La capacidad del servidor estará en función de la carga de
transacciones a que estará sometido. Los PC´s para la visualización
deberán disponer, como mínimo, de la capacidad de almacenamiento
requerida por el navegador.
1.2.5. Atributos
1.2.5.1 Mantenimiento
El mantenimiento de la aplicación será sencillo, así como su
instalación, administración y reparación. Además irá acompañada de los
manuales correspondientes que clarifiquen los pasos a seguir por el
usuario.
En cuanto al idioma y formato de los datos, preferentemente se
hará en español, aunque quizás en un futuro se realice en otros idiomas.
1.2.5.2 Seguridad
Los Administradores y usuarios tendrán un login y password para
acceder a posibles modificaciones de la aplicación. De esta forma,
cualquier persona no identificada sólo podrá consultar las incidencias.
Al tratarse de una aplicación a la cual se accede a través de
Internet hay que tener un control estricto de las claves de los usuarios y
de sus permisos para que ningún usuario malicioso pueda modificar o
dañar la base de datos de la aplicación o la aplicación en sí.
11

123. ITIL Essentials Study Guide
Introduction
Service Support Functions:
• Service Desk
• Incident Management
• Problem Management
• Change Management
• Configuration Management
• Release Management
Service Delivery Functions:
• Availability Management
• IT Services Continuity Management
• Capacity Management
• Financial Management
• Service Level Management

124. Configuration Management
Objectives:
• Providing information on the IT infrastructure
o To all other processes
o IT Management
• Enabling control of the infrastructure by monitoring and maintaining information
on:
o All the resources needed to deliver services
o Configuration Item (CI) status and history
o Configuration Item relationships
Tasks:
• Identification and naming
• Management information
• Verification
• Control
• Status Accounting
Asset: Component of a business process like people, accommodation, computer systems,
paper records, fax machines, etc.
Configuration Management Database: A database, which contains all relevant details of
each Configuration Item (CI) and details of the important relationships between CIs.
A Configuration Item (CI):
• Is needed to deliver a service
• Is uniquely identifiable
• Is subject to change
• Can be managed
A Configuration Item (CI) has:
• a Category
• Relationships
• Attributes
• a Status
Variant: A Configuration Item (CI) that has the same basic functionality as another
Configuration Item (CI) but is different in some small way (ex: has more memory)

125. Baseline: A snapshot of the state of a Configuration Item and any component or related
Configuration Items, frozen in time for a particular purpose (such as the ability to return a
service to a trusted state if a change goes wrong)
Configuration Management supports all other processes!
Scope vs. Detail
Relationships – Common Types:
• Is a component of
• Is a copy of
• Relates to
• Relates with
• Is used by

126. Service Desk
Objectives:
• To be the primary point of call for all:
o Calls
o Questions
o Requests
o Complaints
o Remarks
• To restore the service as quickly as possible
• To manage the incident life-cycle (coordinating resolution)
• To support business activities
• To generate reports, to communicate and to promote
Different Desks
• Call Center: Handling large call volumes of telephone-based transactions.
• Help Desk: To manage, coordinate, and resolve Incidents as quickly as possible.
• Service Desk: Allowing business processes to be integrated into the Service
Management infrastructure. It not only handles Incidents, Problems and questions,
but also provides an interface for other activities.
Service Desk Essentials:
• Single point of contact / Restore service ASAP
• Tasks: Customer Interface, Business Support, Incident Control & Management
Information
• Concentrates on incident lifecycle management
• Incident: Unexpected disruption to agreed service
• Priority determined by business impact and urgency
• Correct assessment of priorities enables the deployment of manpower and other
resources to be in the best interests of the customer
• Escalation and referral

127. Incident Management
Objectives:
• To restore normal service as quickly as possible
• Minimize the adverse impact on business operations
• Ensuring that the best possible levels of service quality and availability are
maintained according to SLAs.
Incident: Any event which is not part of the standard operation of a service and which
causes or may cause an interruption to or a reduction in the quality of that service.
Work-Around: Method of avoiding an Incident or Problem.
Service Request: Every Incident not being a failure in the IT Infrastructure.
Problem: The unknown root cause of one or more incidents.
Known Error: A condition that exists after the successful diagnosis of the root cause of a
problem when it is confirmed that a CI (Configuration Item) is at fault.
Impact on the business + Urgency / Effect upon business deadlines = Priority
Category: Classification of a group of Incidents (Application, Hardware, etc.)
Escalation (Vertical Escalation): escalates up the management chain.
Referral (Horizontal Escalation): escalates to a different knowledge group. Routing.
Incident Life-Cycle
• Accept Service Event, Register and Consult the CMDB
• Classification
• Solve
• Closure
Reporting is VERY important.
• Daily reviews of individual Incident and Problem status against service levels
• Weekly management reviews
• Monthly management reviews
• Proactive service reports

128. Problem Management
Objectives:
• Stabilizing IT services through:
o Minimizing the consequences of incidents
o Removal of the root causes of incidents
o Prevention of incidents and problems
o Prevent recurrence of Incidents related to errors
• Improving productive use of resources
Tasks:
• Problem Control
• Error Control (including raising RfCs – Request for Change)
• Proactive Prevention
• Identifying Trends
• Management Information
• Posit Implementation Review (PIR)
Goal is to get from reactive or proactive. Stop problems from occurring / recurring.
Inputs:
• Incident details
• Configuration details
• Defined work-arounds
Outputs:
• Known Errors
• Requests for Change
• Updated Problem Records including work-arounds and/or solutions
• Response to Incident Management from Matching Management Information
Problem Control
• Identification
• Classification
• Assign Resources
• Investigation and Diagnosis
• Establish Known Error

129. Error Control
• Error Identification and Recording
• Error Assessment
• Recording Error / Resolution (Send out RfC)
• Error Closure
Known Error: An Incident or Problem for which the root cause is known and for which a
temporary Work-around or a permanent alternative has been identified.
Proactive Problem Management:
• Trend Analysis
• Targeting Support Action
• Providing Information to the Organization
Known Errors resulting from Development should be made known to the Helpdesk.
Reporting is also key for Problem Management.

130. Change Management
Objective: To implement approved changes efficiently, cost-effectively and with minimal
risk to the existing and to the new IT infrastructure. Only approved changes made, risk
and cost minimized.
Change Management Tasks:
• Filtering Changes
• Managing Change Process
• Managing Changes
• Chairing CAB and CAB/EC
• Review and Closure
• Management Information
Inputs:
• Requests for Change (RfC)
• CMDB
• Forward Schedule of Changes (FSC)
Outputs:
• Forward Schedule of Changes (FSC)
• Requests for Change (RFC)
• CAB minutes and actions
• Change management reports
Impact of change:
• Category 1
o Little impact on current services. The Change Manager is entitled to
authorize this RfC.
• Category 2
o Clear impact on services. The RfC must be discussed in the Change
Advisory Board. The Change Manager requests advice on authorization
and planning.
• Category 3
o Significant impact on the services and the business. Considerable
manpower and/or resources needed. The RfC will have to be submitted to
the board level (CAB/EC – Change Advisory Board / Executive
Committee)
Priority Setting:

131. • Urgent
o Change necessary now (otherwise severe business impact)
• High
o Change needed as soon as possible (potentially damaging)
• Medium
o Change will solve irritating errors or missing functionality (can be
scheduled)
• Low
o Change leads to minor improvements
A change backout plan must always be possible.
Change management always ends with a review of the change.
Change: The addition, modification, or removal of approved, supported or baselined
hardware, network, software, application, environment, system, desktop build or
associated documentation.
Request for Change: Form or screen, used to record details of a request for a change to
any CI within an infrastructure or to procedures and items associated with the
infrastructure.
Forward Schedule of Changes (FSC): Schedule that contains details of all the Changes
approved for implementation and their proposed implementation dates.
Change Management Process
1. Request for a Change
2. Registration and Classification
3. Monitoring and Planning
4. Approve
5. Build & Test
6. Authorize Implementation
7. Implementation
8. Evaluate

132. Release Management
Objectives:
• Safeguard all software and related items
• Ensure that only tested / correct version of authorized software are in use
• Ensure that only tested / correct version of authorized hardware are in use
• Right software, right time, right place
• Right hardware, right time, right place
Tasks:
• Define the release policies
• Control of the Definitive Software Library (DSL)
• Control of the Definitive Hardware Storage (DHS)
• Distribute Software and Associated CIs
• Carry out S/W audits (using CMDB)
• Manage the software releases
• Oversee build of the software releases
Releases are done under the control of Change Management.
DSL : Definitive Software Library. Reliable versions of software in a single logical
location. However, software may be physically stored at different locations.
Release Policy:
• Release Unit
• Full / Package / Delta Releases
• Numbering
• Frequency
• Emergency Change
Version Control:
• Development
• Testing
• Live
• Archive
Process:
• Software Control and Distribution (operational)
• Change Management (control)

133. • Configuration Management (control and administration)
Only process which creates its own policy.

134. Availability Management
Objectives:
• To predict, plan for and manage the availability of services by ensuring that:
o All services are underpinned by sufficient, reliable and properly
maintained CIs
o Where CIs are not supported internally there are appropriate contractual
agreements with third party suppliers
o Changes are proposed to prevent future loss of service availability
• Only then can IT organizations be certain of delivering the levels of availability
agreed with customers in SLAs.
Aspects of Availability:
• Reliability
• Maintainability: Maintenance you do yourself, as a company
• Resilience: Redundancy
• Serviceability: Maintenance done by someone else
Availability Information is stored in an Availability Database (ADB). This information is
used to create the Availability Plan. SLAs provide an input to this process.
Unavailability Lifecycle
MTTR: Mean Time to Repair (Downtime) – Time period that elapses between the
detection of an Incident and it’s Restoration. Includes: Incident, Detection, Diagnosis,
Repair, Recovery, Restoration.
MTBF: Mean Time Between Failures (Uptime) – Time period that elapses between
Restoration and a new Incident.
MTBSI: Mean Time Between System Incidents – Time period that elapses between two
incidents. MTTR + MTBF.
“An IT service is not available to a customer if the functions that customer requires at
that particular location cannot be used although the agreed conditions under which the IT
service is supplied are being met”
Simplistic Availability Calculation:
Agreed Service Hours – Downtime 100
------------------------------------------ X ----
Agreed Service Hours 1

135. IT Service Continuity Management
Why plan?
• Increases Business dependency on IT
• Reduced cost and time of recovery
• Cost to customer relationship
• Survival
Many businesses fail within a year of suffering a major IT disaster.
Business Impact Analysis:
Risk Analysis:
• Value of Assets
• Threats
• Vulnerabilities
Risk Management:
• Countermeasures
• Planning for potential disasters
• Managing a disaster
Risk Analysis: Based on the CCTA Computer Risk Analysis and Management
Methodology (CRAMM)
Options:
1. Do nothing
2. Manual workarounds
3. Reciprocal arrangements
4. Gradual Recovery (cold standby)
5. Intermediate Recovery (warm standby)
6. Immediate Recovery (hot standby)
Cold start = accommodation. Environmental controls; power and communications
Hot start = cold start + computing equipment and software

136. 7 Sections of the Plan:
1. Administration
2. The IT Infrastructure
3. IT Infrastructure management & Operating procedures
4. Personnel
5. Security
6. Contingency site
7. Return to normal
Test and Review:
• Initially then every 6 to 12 months and after each disaster
• Test it under realistic circumstances
• Move / protect any live services first
• Review and change the plan
• All changes made via the CAB – Change Advisory Board
Contingency Plan:
• Assists in fast, controlled recovery
• Must be given wide but controlled access
• Contents (incl. Admin, Infrastructure, People, Return to normal)
• Options (incl. Cold & Hot Start)
• Must be tested regularly – without impacting the live service

137. Capacity Management
Objective:
To determine the right, cost justifiable, capacity of IT resources such that the Service
Levels agreed with the business are achieved at the right time.
Objectives:
• Demand Management
o Business Capacity Management
• Workload Management
o Service Capacity Management
• Resource Management
o Resource Capacity Management
While doing the above, also need to do:
• Performance Management
o Internal and External Financial Data
o Usage Data
o SLM Data / Response Times
CDB – Capacity Data Base – Contains all Metrics, etc. Used to create a Capacity
Management Plan. Performance Management Data populates the CDB.
Essentials:
• From Customer Demands to Resources
• Demand Management
• Workload Management
• Performance Management
• Capacity Planning
• Defining Thresholds and Monitoring
Application Sizing: To estimate the resource requirements to support a proposed
application change to ensure that it meets its required service levels.

138. Modeling:
• Trend Analysis
• Analytical Modeling
• Simulation Modeling
• Baseline Models
• Used to Answer the “What If… “ questions
• Data for Modeling comes from the CDB

139. Financial Management
Objectives:
To provide information about and control over the costs of delivering IT services that
support customers business needs.
Costing is a must!
Input cost units recommended by ITIL:
• Equipment Cost Units (ECU)
• Organization Cost Units (OCU)
• Transfer Cost Units (TCU)
• Accommodation Cost Units (ACU)
• Software Cost Units (SCU)
Equipment = hardware
Organization = staff
Transfer = costs which IT incurs acting as an agent for the customer, they do not appear
as a cost against the IT department’s budget
Accommodation = buildings
Software = software
Different Cost Types:
• Fixed - unaffected by the level of usage
• Variable - varying according to the level of usage
• Direct - usage specific to one service
• Indirect or Overhead – usage not specific to one service
• Capital – not diminished by usage
• Revenue or running – diminish with usage
Charging Objectives:
• Recover from customers the full costs of the IT services provided
• Ensure that customers are aware of the costs they impose on IT
• Ensure that providers have an incentive to deliver and agreed quality and quantity
of economic and effective services

140. Charging and Pricing Options:
Charging:
• No Charging – IT treated as support center
• Notional Charging – IT treated as cost center
• Actual Charging
Pricing:
• Recover of Costs – IT treated as a service center
• Cost Price Plus – IT treated as a profit center
• Market Prices – IT treated as a profit center
Support and Cost centers used “soft charging” in which no money changes hands; service
and profit centers use “hard costing” in which money is transferred between bank
accounts
Profit centers focus on the value of the IT service to the customer
Good Financial Management minimizes the risks in decision making
3 Main Processes:
Budgeting: The process of predicting and controlling the spending of money within the
enterprise and consists of periodic negotiation cycle to set budgets (usually annual) and
the day-to-day monitoring of the current budgets. Key influence on strategic and tactical
plans.
IT Accounting: The set of processes that enable the IT organization to fully account for
the way its money is spent (particularly the ability to identify costs by customer, by
service, by activity).
Charging: The set of processes required to bill a customer for the services applied to
them. To achieve this requires sound IT Accounting, to a level of detail determined by
the requirements of the analysis, billing, and reporting procedures.

141. Service Level Management
Balance between the Demand for IT services and the Supply of IT services by knowing
the requirements of the business and knowing the capabilities of IT.
Objectives:
• Business-like relationship between customer and supplier
• Improved specification and understanding of service requirements
• Greater flexibility and responsiveness in service provision
• Balance customer demands and cost of services provision
• Measurable service levels
• Quality improvement (continuous review)
• Objective conflict resolution
Tasks:
• Service Catalog
• Service Level Requirements
• Service Level Agreement
• Operational Level Agreements (OLA) and Contracts
• Service Specsheet
• Service Quality Plan
• Monitor, Review and Report
• Service Improvement Programs
• Customer Relationship Management
Minimum Requirements for an Agreement:
• Period
• Service Description
• Throughput
• Availability
• Response Times
• Signature

142. Other Possible Clauses:
• Contingency arrangements
• Review procedures
• Change procedures
• Support services
• Customer responsibilities
• Housekeeping
• Inputs and Outputs
• Changes
Ideally contracts are based on targets in the SLA
SLAs must be monitored regularly and reviewed regularly
• Monitor to see if service is being delivered to specification
• Review to see if service specification is still appropriate

143. Fernando Leandro Baladrón Proyecto fin de carrera
ANEXO. HOJA DE ESTILOS 20/03/07
ANEXO 3. HOJA DE ESTILOS
* ================================
CSS STYLES FOR HELP DESK CEU
v1.0, 20/05/2007
================================
*/
/**************************************************************/
/**************************************************************/
body
{
margin: 10px 0px 20px 0px;
}
.fondoBlanco
{
background-color: #ffffff;
height: 89;
}
.fondoVerde
{
background-color: #cccc33;
}
.fondoSombraHorizontal
{
height: 8px;
background-image: url(imagenes/sombras/sombraHorizontal.gif);
background-repeat: repeat-x;
}
.fondoCabeceraSombraHorizontal
{
height: 8px;
background-image: url(imagenes/sombras/sombraCabecera.gif);
background-repeat: repeat-x;
}
.fondoTricolor
{
height: 69px;
background-image: url(imagenes/tricolor.gif);
background-repeat: repeat-x;
}
.fondoSombraIzquierda
{
background-image: url(imagenes/sombraMarco/sombraIzquierda.gif);
background-repeat: repeat-y;
width: 18px;
}
.fondoSombraDerecha
{
background-image: url(imagenes/sombraMarco/sombraDerecha.gif);
background-repeat: repeat-y;

144. Fernando Leandro Baladrón Proyecto fin de carrera
ANEXO. HOJA DE ESTILOS 20/03/07
width: 18px;
}
.fondoSombraArriba
{
background-image: url(imagenes/sombraMarco/sombraArriba.gif);
background-repeat: repeat-x;
height: 18px;
}
.fondoSombraAbajo
{
background-image: url(imagenes/sombraMarco/sombraAbajo.gif);
background-repeat: repeat-x;
height: 18px;
}
.fondo
{
background-color: #EBEAEA;
}
.alto100
{
height: 100%;
}
.alto6
{
height: 6px;
}
.alto5
{
text-indent:8px
}
.alinearTop
{
vertical-align: top;
}
.alinearIzquierda
{
text-align: left;
}
.alinearDerecha
{
text-align: right;
}
.margenTabla
{
padding: 10px 10px 10px 10px;
}
.titulo
{

145. Fernando Leandro Baladrón Proyecto fin de carrera
ANEXO. HOJA DE ESTILOS 20/03/07
text-align: left;
font-weight: lighter;
letter-spacing: -2px;
font-family: Verdana;
font-size: 30px;
color: #ffffff;
text-decoration: none;
}
.titulo a
{
color: #ffffff;
text-decoration: none;
}
.titulo a:hover
{
text-decoration: underline;
}
.tituloCategorias
{
font-family: Verdana;
font-size: 17px;
color: #E60003;
font-weight: lighter;
text-align: left;
text-decoration: none;
}
.tituloCalendario
{
font-family: Verdana;
font-size: 17px;
color: #666666;
font-weight: lighter;
text-align: left;
}
.datosItem
{
font-family: Verdana;
font-size: 9px;
color: #999999;
}
.opcionesItem
{
font-family: Verdana;
font-size: 11px;
color: #0099cc;
}
.enlaceItem
{
font-family: Verdana;
font-size: 10px;
color: #0099CC;
border-collapse : separate;
text-decoration: none;
font-weight:bold;
}

146. Fernando Leandro Baladrón Proyecto fin de carrera
ANEXO. HOJA DE ESTILOS 20/03/07
.enlaceItem a
{
color: #0099cc;
font-weight: bolder;
border-collapse: separate;
text-decoration: underline;
font-weight:bold;
}
.enlaceItem a:hover
{
color: #cccc33;
font-weight: bolder;
border-collapse: separate;
text-decoration: underline;
font-weight:bold;
}
.enlaceItemMigas
{
font-family: Verdana;
font-size: 10px;
color: #FFFFFF;
border-collapse : separate;
text-decoration: none;
font-weight:bold;
}
.enlaceItemMigas a
{
color: #FFFFFF;
font-weight: bolder;
border-collapse: separate;
text-decoration: none;
font-weight:bold;
}
.enlaceItemMigas a:hover
{
color: #cccc33;
text-decoration: underline;
}
.enlaceItemBlanco
{
font-family: Verdana;
font-size: 10px;
color: #0099CC;
border-collapse : separate;
text-decoration: none;
font-weight:bold;
}
.enlaceItemBlanco a
{
color: #0099cc;
font-weight: bolder;
border-collapse: separate;
text-decoration: none;
font-weight:bold;

147. Fernando Leandro Baladrón Proyecto fin de carrera
ANEXO. HOJA DE ESTILOS 20/03/07
}
.enlaceItemBlanco a:hover
{
color: #FFFFFF;
text-decoration: none;
}
.enlaceItemAzul
{
font-family: Verdana;
font-size: 10px;
color: #0099CC;
border-collapse : separate;
text-decoration: none;
font-weight:bold;
}
.enlaceItemAzul a
{
color: #0099cc;
font-weight: bolder;
border-collapse: separate;
text-decoration: none;
font-weight:bold;
}
.enlaceItemAzul a:hover
{
color: #cccc33;
text-decoration: none;
}
.enlaceItemVerde
{
font-family: Verdana;
font-size: 10px;
color: #cccc33;
border-collapse : separate;
text-decoration: none;
font-weight:bold;
}
.enlaceItemVerde a
{
color: #cccc33;
font-weight: bolder;
text-decoration: none;
/*esto es para q el datagrid no tenga borde en firefox*/
border-collapse: separate;
}
.enlaceItemVerde a:hover
{
color: #0099cc;
}
.enlaceItemRojo
{
font-family: Verdana;

148. Fernando Leandro Baladrón Proyecto fin de carrera
ANEXO. HOJA DE ESTILOS 20/03/07
font-size: 10px;
color: #CC2B00;
border-collapse : separate;
text-decoration:none;
font-weight:bold;
}
.enlaceItemRojo a
{
color: #CC2B00;
font-weight: bolder;
text-decoration: none;
border-collapse: separate;
}
.enlaceItemRojo a:hover
{
color: #0099cc;
text-decoration: underline;
}
.noBorde
{
/*esto es para q el datagrid no tenga borde en firefox*/
border-collapse: separate;
}
.tituloItem
{
font-family: Verdana;
font-size: 16px;
color: #0099cc;
font-weight: bolder;
text-decoration: none;
/*text-transform:capitalize;*/
/*esto es para q el datagrid no tenga borde en firefox*/
border-collapse: separate;
}
.tituloItem:hover
{
color: #666666;
}
.lineaAzul
{
background-color: #536BB3;
height: 1px;
}
.lineaRoja
{
background-color: #E60003;
height: 1px;
}
.lineaGris
{
background-color: #666666;
height: 1px;
}

149. Fernando Leandro Baladrón Proyecto fin de carrera
ANEXO. HOJA DE ESTILOS 20/03/07
.lineaVerde
{
background-color: #cccc33;
height: 1px;
}
.separador
{
background-image: url(imagenes/separador.gif);
background-repeat: repeat-y;
width: 9px;
}
.punteadoAzul
{
background-image: url(imagenes/punteadoAzul.gif);
background-repeat: repeat-x;
height: 1px;
}
.punteadoRojo
{
background-image: url(imagenes/punteadoRojo.gif);
background-repeat: repeat-x;
height: 1px;
}
.punteadoVerde
{
background-image: url(imagenes/punteadoVerde.gif);
background-repeat: repeat-x;
height: 1px;
}
.punteadoGris
{
background-image: url(imagenes/punteadoGris.gif);
background-repeat: repeat-x;
height: 1px;
}
.textoRojo
{
font-family: Verdana;
font-size: 9px;
color: #E60003;
text-decoration: none;
}
.textoRojo:hover
{
text-decoration: underline;
}
.textoNegroPeq
{
font-family: Verdana;
font-size: 9px;
color: #000000;
text-decoration: none;

150. Fernando Leandro Baladrón Proyecto fin de carrera
ANEXO. HOJA DE ESTILOS 20/03/07
}
.textoNegroPeq:hover
{
text-decoration: underline;
}
.textoVerde
{
font-family: Verdana;
font-size: 9px;
color: #cccc33;
text-decoration: none;
}
.textoVerde:hover
{
text-decoration: underline;
}
.alto4
{
height: 4px;
}
.alto40
{
height: 15px;
}
.interiorCalendario
{
font-family: Verdana;
font-size: 10px;
color: #666666;
}
.diaConItems
{
background-color: #0099cc;
color: #ffffff;
text-decoration: none;
}
.diaConItems a
{
background-color: #0099cc;
color: #ffffff;
text-decoration: none;
}
.diaConItems a:hover
{
color: #ffffff;
text-decoration: underline;
}
.diaSinItems
{
background-color: #ffffff;
color: #666666;

151. Fernando Leandro Baladrón Proyecto fin de carrera
ANEXO. HOJA DE ESTILOS 20/03/07
}
.diaOtroMes
{
color: #cccccc;
}
.diaSeleccionado
{
border: inset 0.05 red;
}
.txtBox
{
font-family: Verdana;
color: #666666;
font-size: 9px;
}
.btn
{
font-family: Verdana;
color: #666666;
font-size: 9px;
}
.resaltado
{
background-color: #ffff00;
}
.textoPie
{
background-color: #666666;
font-family: Verdana;
font-size: 9px;
color: #bbb;
text-decoration: none;
}
.textoPie a
{
background-color: #666666;
font-family: Verdana;
font-size: 9px;
font-weight: bold;
color: #bbb;
text-decoration: none;
}
.textoPie a:hover
{
text-decoration: underline;
}
.PieAsistencia
{
background-color: #666666;
color: #ffffff;
font-family: Verdana;
font-size: 9px;
text-align: center;

152. Fernando Leandro Baladrón Proyecto fin de carrera
ANEXO. HOJA DE ESTILOS 20/03/07
text-decoration: none;
}
.pieAsistencia a
{
background-color: #666666;
color: #ffffff;
font-family: Verdana;
font-size: 9px;
text-align: center;
text-decoration: none;
}
.pieAsistencia a:hover
{
text-decoration: underline;
}
.pie
{
color:#ffffff;
background-color:#555555;
font-family:Verdana;
font-size:9px;
text-align:center;
height:20px
}
.textoItem
{
font-family: Verdana;
font-size: 11px;
color: #000000;
}
.textoItemAzul
{
font-family: Verdana;
font-size: 11px;
color: #0099CC;
border-collapse : separate;
text-decoration: none;
font-weight:bold;
}
/**************************************************************/
/******************FIN HOJA CSS********************************/
/**************************************************************/