proyecto final de carrera. ing.informática. help-desk

Universidad CEU – Cardenal Herrera ESCUELA SUPERIOR DE ENSEÑANZAS TÉCNICAS

INGENIERÍA INFORMÁTICA

PROYECTO FINAL DE CARRERA

Desarrollo e implementación de un centro de Asistencia HELP-DESK siguiendo la Metodología

ITIL

Autor: Fernando Leandro Baladrón

Directores de proyecto:

Dr. D. Juan Pardo Albiach D. José Luis Roig Azpitarte

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo1. Índice de contenidos 20/03/07

ÍNDICE DE CONTENIDOS CAPÍTULO 1 1.1 INTRODUCCIÓN 3 1.2 OBJETIVOS 5 CAPÍTULO 2 2.1 FASES DEL PROYECTO 7 2.2 DIAGRAMA DE GANTT 13 CAPITULO 3 3.1 ESTADO DEL ARTE 15

3.1.1 INTRODUCCIÓN A ITIL 15 3.1.2 VENTAJAS DE ITIL PARA EL CLIENTE/USUARIO 16 3.1.3 VENTAJAS DE ITIL PARA LA ORGANIZACIÓN 16 3.1.4 PROBLEMAS POTENCIALES DE ITIL 17 3.1.5 PERSPECTIVA GENERAL DE LA GESTIÓN DEL SERVICIO 17 SEGÚN ITIL

3.1.5.1 SERVICE DESK. 17 3.1.5.2 MANEJO DE INCIDENTES. 18 3.1.5.3 MANEJO DE PROBLEMAS 22

3.1.6 EL FUTURO DE LOS HELP DESKS 26

3.2 COMPARATIVA CENTRO DE ASISTENCIA 28 3.2.1 APLICACIÓN GIGLOBAL SUPPORT 26

3.2.2 APLICACIÓN DEMO HELPDESK 27 3.2.3 APLICACIÓN PRO DE AQCENTUS CORPORATION INC. 28 3.2.4 APLICACIÓN CENTRO DE ASISTENCIA NAVIGATOR 29 3.2.5 APLICACIÓN CENTRO DE ASISTENCIA ISOLSOFT 30 3.2.6 APLICACIÓN CENTRO DE ASISTENCIA PERL DESK 33 3.2.7 APLICACIÓN CENTRO DE ASISTENCIA CRM DESK 35 3.2.8 APLICACIÓN CENTRO DE ASISTENCIA JITBIT HELPDESK 36 3.2.9 APLICACIÓN CENTRO DE ASISTENCIA SERVICE DESK 37

3.2.10 CUADRO COMPARATIVO 40 CAPITULO 4

4.1. BASE DE DATOS HELP-DESK 43 4.2. NIVEL DEL DISEÑO DE LA BASE DE DATOS 43

4.2.1. ANÁLISIS DE REQUERIMIENTOS 43 4.2.2. DISEÑO CONCEPTUAL 45 4.2.3. DISEÑO LÓGICO 46

4.2.4 .DIAGRAMA UML 52

4.2. PROCEDIMIENTOS ALMACENADOS CON SQL SERVER 54 4.2.1. PROCEDIMIENTOS IMPLEMENTADOS 54 4.2.2. CONEXIONES EN SQL SERVER. 58

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo1. Índice de contenidos 20/03/07 5. NIVEL DEL DISEÑO WEB 59

5.1. DISEÑO DE NAVEGACIÓN 59 5.2. HOJA DE ESTILOS CSS 66 5.3. USABILIDAD 69

6. NIVEL DEL DISEÑO DE LA INTERFACE 74

6.1. CLASES 74 6.2. PROGRAMACIÓN ASP .NET 81

6.2.1. DISTRIBUCIÓN DE LAS CARPETAS 83 6.2.2. CONTROLES DE USUARIO 87 6.2.3. INSERCIÓN DE ITEMS 88 6.2.4. SUBIR ARCHIVOS 88 6.2.5. VISUALIZACIÓN DE LOS DATOS 89 6.2.6. IDENTIFICACIÓN DE LOS USUARIOS 90 6.2.7. OBTENER ITEMS 91

6.2.8. TEMAS ADICIONALES 92 7. CONCLUSIONES Y TRABAJO FUTURO 95

7.1. CONCLUSIONES FINALES 95 7.2. TRABAJO FUTURO 98

BIBLIOGRAFIA 100 ANEXOS

1. ESPECIFICACIÓN DE REQUISITOS DE ACUERDO NORMA IEEE 2. ITIL STUDY GUIDE3. HOJA DE ESTILOS (CSS)

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo1. Índice de contenidos 20/03/07

ÍNDICE DE FIGURAS fig 2.1 Diagrama de Gantt del proyecto 14 fig 3.1.1 Ciclo vital del incidente 21 fig 3.1.2 Descripción gestión de problemas 23 fig 3.2.1 Logo Aplicación Giglobal Support 26 fig 3.2.2 Aplicación Demo HelpDesk 28 fig 3.2.3 Aplicación Help Desk Pro de Aqcentus Corporation Inc 29 fig 3.2.4 Aplicación Centro de Asistencia Navigator 29 fig 3.2.5 Aplicación Centro de Asistencia Isolsolf 30 fig 3.2.6 Listado de incidencias 31 fig 3.2.7 Pantalla de búsqueda sobre la base de conocimiento 31 fig 3.2.8 Listado de incidencias 32 fig 3.2.9 Formulario de datos de un item/ticket 32 fig 3.2.10 Aplicación centro de asistencia Perl Desk 33 fig 3.2.11 Formulario de introducción item / ticket 34 fig 3.2.12 Listado de incidencias 34 fig 3.2.13 Aplicación centro de asistencia CRM Desk 35 fig 3.2.14 Búsqueda en la base de conocimientos 36 fig 3.2.15 Aplicación centro de asistencia JitBit HelpDesk 36 fig 3.2.16 Aplicación centro de asistencia Service Desk 37 fig 3.2.17 Posible listados con la aplicación 38 fig 3.2.18 Búsqueda sobre la base de conocimiento 39 fig 3.2.19 Listado de informes 40 fig 4.1 Diseño conceptual utilizando el modelo Entidad - Relación 46 fig 4.2 Diagrama generado con el SGBD SQL Server 50 fig 4.3 Tablas generadas con el SGBD SQL Server 51 fig 4.4 Diagrama UML Help Desk CEU 53 fig 5.1 Movimiento del ojo al visualizar un página 59 fig 5.2 Boceto del diseño de la organización de la página inicial perfil visitante 60 fig 5.3 Diseño de la organización de la página principal perfil visitante 62 fig 5.4 Captura de la página con la información de la pregunta 63 fig 5.5 Boceto del diseño de la organización de la página inicial perfil personal 63 fig 5.6 Diseño de la organización de la página principal perfil personal 64 fig 6.1.1 Desarrollo de las clases en Visual Studio .NET 79 fig 6.2.1 Distribución de las carpetas en Visual Studio .NET 84 fig 6.2.2 Formulario de edición desarrollado en Visual Studio .NET 85 fig 6.2.3 Diseño del formulario de inserción de items en Visual Studio .NET 87 fig 7.1 Fases de la documentación del proyecto 94

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo1. Introducción 20/03/07

CAPÍTULO 1 1.1. INTRODUCCIÓN Las organizaciones dependen cada vez más de las tecnologías de la información para alcanzar sus objetivos corporativos. La misión del departamento de tecnologías de la información es ofrecer servicios fiables, de alta calidad y a un coste aceptable, por lo que debe incorporar de manera sistemática las mejores prácticas del mercado para la optimización continua de sus procesos. La información es un recurso imprescindible para cualquier universidad que quiera ofrecer a sus clientes una mayor calidad. Las tecnologías de la información ofrecen la posibilidad de crear una infraestructura única mediante la que capturar, procesar, distribuir, explotar y almacenar esa información. Se trata de una herramienta estratégica para potenciar la eficacia de la actividad asistencial, la asimilación y puesta en práctica del conocimiento derivado de la investigación, y la optimización en el despliegue y consumo de recursos que esta actividad requiere. Debida a la gran abundancia de información disponible a usuarios de internet, una de las necesidades que surgen es la de proveer al usuario de medios para manejar de manera más efectiva el gran volumen, dinamismo y complejidad de la información. Generalmente el usuario se ve enfrentado con la necesidad de navegar entre el gran volumen de datos para buscar y localizar la información que necesita y que le es de importancia. Esto representa frecuentemente una desorientación del usuario entre los diferentes caminos que puede seguir un sistema con tantos medios de búsqueda. La información tiene que ser inteligente. El principal objetivo de los sistemas de gestión de incidencias es el procesamiento de las consultas y las incidencias de cualquier tipo. Esto se consigue mediante la correcta clasificación de los niveles de información. En función de los niveles de habilidad y especialización de sus miembros, estos equipos se agrupan en unidades de primer, segundo y tercer nivel de soporte. En esta función, la gestión de incidencias asume el papel particular de mantener el contacto entre los sistemas de información y el negocio. La gestión de incidencias es el primer y más importante punto de contacto para el cliente. A la hora de realizar el correspondiente estudio del estado del arte de los centro asistenciales se tiene que destacar la metodología ITIL (Information Technology Infrastructure Library) la cual es una colección de las mejores prácticas contempladas en el sector de las tecnologías de la Información que se ha convertido en un estándar “de facto”. ITIL describe los procesos de gestión de servicios de tecnologías de la información. Dentro de esta metodología se recomienda una serie de pautas a la hora de trabajar con un centro asistencial. Un primer concepto que se debe conocer es la definición de incidente. Un incidente es cualquier acontecimiento que no forma parte del funcionamiento normal de un servicio y que causa o puede causar una interrupción o reducción en la calidad del mismo. La primera fase en todo centro asistencial es la de registrar la incidencia, en esta fase almacenaremos información del tipo de quién informa del problema, que síntomas se extraen del problema, cuál es el equipo involucrado, etc. La siguiente fase será clasificar la incidencia y asignar el trabajo a realizar a un grupo de soporte o a un técnico, desarrollando para ello un estudio de los niveles de información llegando

3


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


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


Estudio de la usabilidad aplicado al sitio web a desarrollar Este apartado se realizará un estudio de la estructura del sitio web que se desea desarrollar, para ello se recurrirá a estudios ya realizados revisando las pautas que se recomiendan para ello. También se repasará el uso de las hojas de estilos (CSS) aplicado al diseño.

Desarrollo final del centro de asistencia. Y todo esto concluirá con el desarrollo de la Aplicación, la cual será desarrollada mediante la tecnología ASP.NET, siguiendo la arquitectura de tres capas. La arquitectura de tres capas tiene una primera fase que se dedica a la persistencia de los datos, en esta fase se diseña una base de datos con la que poder mantener dicha persistencia y así poder almacenar todos los datos que una biblioteca puede generar. La segunda capa de diseño representa el nivel del dominio o aplicación, consistente en aplicar los componentes realizados en la aplicación para se implementen correctamente las características especificadas en la fase de modelo conceptual. Y finalmente la tercera fase es la de la realización de la interfaz gráfica de usuario (IGU).

6

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 2. Propuesta y Planificación 20/03/07

CAPÍTULO 2 2.1. PROPUESTA Y PLANIFICACIÓN DEL PROYECTO A continuación se describirá en profundidad cada una de las fases del proyecto, indicando el objetivo marcado, las subtareas identificadas y el resultado esperado. También se establecerán plazos para cada tarea que tendrán su representación gráfica en un diagrama de de Gantt. Tras un estudio del proyecto propuesto se han identificado hasta 10 fases distintas. Estas fases irán desde la profundización en el estudio de la metodología ITIL, definiendo conceptos, pasando por el análisis de las incidencias de la universidad hasta llegar al diseño, implementación e implantación del propio sistema. Las fases identificadas son: 2.1 Ámbito 2.1.1 Descripción Determinar el ámbito del proyecto. El objeto de esta fase es la del estudio inicial del proyecto. En esta fase se buscará hacer un estudio inicial de los recursos de los que se dispone para realizar el proyecto 2.1.2 Objetivos Uno de los principales objetivos de esta etapa inicial será el de afianzar y fidelizar a los patrocinadores del proyecto, en nuestro caso la Universidad. Se tratará de definir los recursos preliminares, con ello se contemplará el personal dedicado al proyecto, ordenadores de los que se dispone, medios publicitarios, tiempo estimado al proyecto, etc. Se buscará realizar una buena gestión y planificación del proyecto con lo cual se pretende afianzar los recursos principales de los objetivos de partida. 2.1.3 Tareas • Afianzar a los patrocinadores del proyecto • Definir recursos preliminares • Afianzar recursos principales

2.1.4 Resultados esperados

El resultado final esperado es el conseguir haber determinado el ámbito total del proyecto.

7

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 2. Propuesta y Planificación 20/03/07 2.2 Estudio metodología ITIL 2.2.1 Descripción Conocer en profundidad la metodología ITIL y lo que conlleva, en que consiste, la étapa de gestión del servicio, que contempla y como se desarrolla un service desk. 2.2.2 Objetivos Este estudio se encargará de desarrollar los conceptos relacionados con la metodología ITIL, seguidamente vendrá la descripción y la metodología a desarrollar. Para finalmente cerrar este apartado con la implantación de ITIL en un entorno universitario. 2.2.3 Tareas • Conceptos: Se estudiarían los conceptos de incidencia, ITIL, gestión del servicio y aquellos relacionados con el tema de investigación. El objetivo es tener un conocimiento claro y conciso de lo que se pretende diseñar e implementar, diferenciándolo de aplicaciones de gestión que no implementen ITIL para ello. • Descripción y metodología: Descripción de las fases de implementación de ITIL y su metodología destacando la gestión del incidente. • Implantación: Esta tarea se centrará en el estudio del manejo del incidente. Se analizarán los pasos que se recomienda dar y en qué momentos, cómo implantarlo en un entorno universitario y cómo ir enseñando a los usuarios a familiarizarse con el sistema. 2.2.4 Resultados esperados El resultado esperado es un conocimiento profundo de la metodología ITIL: qué es un service desk, la metodología común del manejo del incidente, ventajas e inconvenientes para la empresa, las dificultades en la implantación, el conocimiento del ciclo vital del incidente. Demostrar los beneficios en los que puede repercutir el uso de ITIL en una determinada empresa. 2.3 Análisis y requisitos del software 2.3.1 Descripción En esta étapa se busca realizar un análisis exhaustivo de las necesidades reales del proyecto ha desarrollar para conseguir como resultado, una correcta consecución del mismo. 2.3.2 Objetivos Un primer estudio vendrá contemplado por un análisis de las necesidades del proyecto. Estudio del público objetivo del proyecto y que se desea alcanzar con el desarrollo del mismo. Acompañando a esta etapa se realizará el desarrollo de un presupuesto, además de la planificación de tiempo y fechas de entrega esperando así la aprobación del cliente para continuar.

8

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 2. Propuesta y Planificación 20/03/07 2.3.3 Tareas • Realizar análisis de necesidades • Borrador de las especificaciones preliminares del software • Desarrollar presupuesto preliminar • Revisar las especificaciones del software y el presupuesto con el equipo • Incorporar los comentarios a las especificaciones del software • Desarrollar los tiempos y fechas de entrega • Obtener aprobaciones para continuar (concepto, fechas, presupuestos) • Afianzar los recursos necesarios 2.3.4 Resultados esperados Finalmente como resultado de esta etapa se espera tener el análisis completado. 2.4 Estudio de las Incidencias del sistema 2.4.1 Descripción Con esta etapa se busca identificar las distintas incidencias que se generan en una universidad. Se desarrollará un estudio de las especificaciones generales de la aplicación ha desarrollar, desarrollando el ciclo vital de cada una de las incidencias. 2.4.2 Objetivos Estudio y conocimiento de la plataforma de desarrollo con la que se va ha desarrollar el sistema. Obtención, en líneas generales de los pasos que sigue la universidad en su día a día y en los procesos que generan más incidencias. Obtener una serie de requisitos de carácter general que marcaran un primer diseño del sistema de información. Identificación de las incidencias: se identificarán las distintas incidencias que se generan en una universidad, tratando de separarlas y diferenciarlas al máximo. Clasificándolas finalmente por departamentos. Identificación del modelo de resolución de la incidencia por cada nivel: A partir de la separación de las distintos tipos de incidencia, se obtendrá de nuevo el modelo de trabajo de cada una de las incidencias en particular: se identificarían los usuarios que intervendrían en su resolución clasificándolos por niveles, la importancia de cada uno de estos, la frecuencia con la que intervienen en su resolución, etc. El resultado será una visión muy concreta y detallada de cada incidencia. 2.4.3 Tareas • Desarrollar especificaciones de funcionamiento • Desarrollar prototipo basado en las especificaciones de funcionamiento • Revisar especificaciones de funcionamiento • Identificar las distintas incidencias y su resolución por nivel • Incorporar comentarios a las especificaciones de funcionamiento • Elección herramientas de desarrollo

9

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 2. Propuesta y Planificación 20/03/07 2.4.4 Resultados esperados Identificación de la totalidad de las incidencias del sistema y su correcto estudio de resolución jerarquizado por niveles debidamente estipulados. 2.5 Base de Datos 2.5.1 Descripción Diseñar e implementar la base de datos que será soporte para todo el sistema de información. Se definirá por completo indicando relación y restricciones. 2.5.2 Objetivos Un primer paso será el análisis de los requisitos determinados en la fases anteriores. De esta manera, analizando las necesidades de la metodología ITIL, se podrán comenzar a definir los datos que necesitarán para realizar su correcta implantación. Después se desarrollará el diseño conceptual que nos permitirá un entendimiento completo de la estructura, el significado (semántica), las relaciones y las restricciones de la base de datos, siendo siempre independiente del SGBD que se elija posteriormente. El diseño conceptual, a través del modelo E-R, representará las estructuras que constituyen el contenido del sistema de información junto con restricciones de distintos tipos y finalmente se estudiarán y evaluarán distintos SGBD valorando sus aspectos negativos y positivos, precio y coste de mantenimiento entre otros. 2.5.3 Tareas • Análisis de requisitos • Diseño conceptual: modelo E-R • Selección de SGBD 2.5.4 Resultados esperados Con la resolución de esta etapa se espera definir por completo el diseño y la implantación de la base de datos. 2.6 Desarrollo 2.6.1 Descripción Esta es la fase más extensa de las desarrolladas, se realizará la preparación de la lógica de negocio, para después acompañar al desarrollo de la interfaz que a su vez vendrá respaldado de un estudio de la usabilidad del sistema. 2.6.2 Objetivos Diseño e implementación de objetos que representen los datos con los que la información trabaja. Creación de los objetos de datos que hagan de intermediario entre los objetos de negocio y la base de datos. Desarrollo de la interfaz.

10

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 2. Propuesta y Planificación 20/03/07 Estudio de la usabilidad del interfaz ha desarrollar para hacer al usuario una aplicación cercana y fácilmente entendible en su flujo de trabajo diario. Maquetación de la interfaz utilizando HTML y CSS para permitir que se pueda cambiar la apariencia, adecuándose a los estándares de usabilidad. 2.6.3 Tareas • Revisar especificaciones de funcionamiento • Identificar parámetros de diseño modular y de componentes separados • Asignar el personal de desarrollo • Desarrollar el código • Pruebas de los desarrolladores • Estudio de la usabilidad • Maquetación HTML 2.6.4 Resultados esperados Desarrollo completado 2.7 Pruebas 2.7.1 Descripción Se busca identificar las anomalías además de asegurar el correcto funcionamiento de la aplicación. 2.7.2 Objetivos Se tratará de testear la aplicación al máximo, introduciendo datos ficticios y probando todas las acciones posibles para descubrir posibles errores. Durante una semana, se instalará la aplicación en la universidad usando datos reales, para comprobar si existen errores no corregidos en fases anteriores. 2.7.3 Tareas • Desarrollar planes de pruebas de integración usando las especificaciones del producto • Revisar el código modular • Probar si los módulos de los componentes se ajustan a las especificaciones del producto • Identificar anomalías y anotarlas en las especificaciones del producto • Modificar código • Consiste en realizar una guía para próximos proyectos que ayude a realizar un diseño de una manera fácil y esquematizada. • Facilitar la labor de realizar el diseño. • Reducción del coste temporal de próximos proyectos. 2.7.4 Resultados esperados Desarrollo del plan de pruebas completado

11

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 2. Propuesta y Planificación 20/03/07 2.8 Formación 2.8.1 Descripción Se tratará de desarrollar las especificaciones de formación para los usuarios finales además de documentar las especificaciones de formación para el personal de soporte al cliente. 2.8.2 Objetivos Se busca el acercamiento de la aplicación a los usuarios finales, se persigue conseguir que la conozcan y se habitúen a ella, para ello se recurrirá a la realización de cursos de formación, realización de manuales de usuario, etc. 2.8.3 Tareas • Identificar la metodología de formación (utilizando PC, aulas, etc.). • Desarrollar materiales de formación. • Realizar estudio de posibilidades de uso de la formación. • Finalizar los materiales de formación. • Desarrollar mecanismo para impartir la formación. 2.8.4 Resultados esperados Materiales de formación completados 2.9 Documentación 2.9.1 Descripción Fase dedicada a la documentación final del proyecto, gracias a esta quedará plasmado todo el esfuerzo realizado para la correcta consecución del proyecto, en esta fase se abordaran temas tales como la confección de los manuales de usuario, manuales de ayuda. 2.9.2 Objetivos Se pretende dejar plasmado toda la información necesaria para que cualquier persona ajena al proyecto pueda en el menor tiempo posible entender el proyecto en todas sus facetas. 2.9.3 Tareas • Revisar la documentación de la ayuda • Incorporar los comentarios a la documentación de la ayuda • Desarrollar las especificaciones de los manuales de usuario • Desarrollar los manuales de usuario • Revisar toda la documentación para el usuario • Incorporar comentarios a la documentación de usuario 2.9.4 Resultados esperados

12

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 2. Propuesta y Planificación 20/03/07

• Documentación completadas 2.10 Componente piloto 2.10.1 Descripción Consiste en realizar una guía para próximos proyectos que ayude a realizar un diseño de una manera fácil y esquematizada. 2.10.2 Objetivos • Facilitar la labor de realizar el diseño. • Reducción del coste temporal de próximos proyectos. 2.10.3 Tareas • Desarrollar las especificaciones de la ayuda • Desarrollar el sistema de ayuda • Designar grupo de pruebas – Jefe de proyecto • Desarrollar el mecanismo de entrega del software • Instalar y distribuir el software • Obtener comentarios de los usuarios • Evaluar la información de las pruebas • Componente piloto completado 2.10.4 Resultados esperados Documentación que sirva como guía en el desarrollo del proyecto. 2.2. Planificación temporal. Diagrama de Gantt.

soft Project. Destacar que las

, que genera la aplicación de Microsoft Project,

ara la realización de la planificación se utiliza el programa MicroP

tareas sin duración son consideradas como hitos por la aplicación y representan un evento puntual como la presentación de un documento.

continuación, se muestra el diagrama de GanttAen donde el eje horizontal representa el tiempo transcurrido y el vertical las distintas tareas realizadas. Este grafico permite visualizar también la dependencia temporal entre una tarea, sus predecesoras y sus sucesoras. Por ultimo indicar que al lado de la tarea aparece el nombre de la persona que va a realizarla.

13

Id Nombre de tarea

1 Ámbito2 Determinar el ámbito del proyecto

3 Afianzar a los patrocinadores del proye

4 Definir recursos preliminares

5 Afianzar recursos principales

6 Ámbito completado

7 Estudio Metodología ITIL8 Conceptos

9 Descripción y Metodología

10 Estudio posible Implantación

11 Estudio Completado

12 Análisis y requisitos del software13 Realizar análisis de necesidades

14 Borrador de las especificaciones prelim

15 Desarrollar presupuesto preliminar

16 Revisar las especificaciones del softwa

17 Incorporar los comentarios a las espec

18 Desarrollar los tiempos y fechas de ent

19 Obtener aprobaciones para continuar (

20 Afianzar los recursos necesarios

21 Análisis completado

22 Estudio de las Incidencias del Sistema23 Estudio de las incidenias del sistema

24 Estudio Completado

25 Base de Datos26 Especificaciones preliminares del softw

27 Desarrollar especificaciones de funcion

28 Desarrollar prototipo basado en las esp

29 Revisar especificaciones de funcionam

30 Incorporar comentarios a las especifica

31 Obtener aprobación para continuar

32 Diseño completado

33 Desarrollo34 Revisar especificaciones de funcionam

35 Identificar parámetros de diseño modu

36 Asignar el personal de desarrollo

37 Desarrollar el código

38 Pruebas de los desarrolladores (depura

39 Desarrollo completado

Ámbito

AdministraciónDeterminar el ámbito del proyecto

AdministraciónAfianzar a los patrocinadores del proyecto

Jefe de proyectoDefinir recursos preliminares

Jefe de proyectoAfianzar recursos principales

Ámbito completado 06/02

Estudio Metodología ITIL

Conceptos

Descripción y Metodología

Estudio posible Implantación

Estudio Completado 09/02

Análisis y requisitos del software

AnalistaRealizar análisis de necesidades

Borrador de las especificaciones preliminares del software Analista

Jefe de proyectoDesarrollar presupuesto preliminar

Jefe de proyecto;AnalistaRevisar las especificaciones del software y el presupuesto con el equipo

AnalistaIncorporar los comentarios a las especificaciones del software

Desarrollar los tiempos y fechas de entrega Jefe de proyecto

Obtener aprobaciones para continuar (concepto, fechas, presupuestos) Administración;Jefe de proyecto

Afianzar los recursos necesarios Jefe de proyecto

Análisis completado 02/03

Estudio de las Incidencias del Sistema

Estudio de las incidenias del sistema

02/03

Base de Datos

AnalistaEspecificaciones preliminares del software

Desarrollar especificaciones de funcionamiento Analista

Desarrollar prototipo basado en las especificaciones de funcionamiento Analista

Revisar especificaciones de funcionamiento Administración

Incorporar comentarios a las especificaciones de funcionamiento Administración

Obtener aprobación para continuar Administración;Jefe de proyecto

Diseño completado 23/03

Desarrollo

DesarrolladorRevisar especificaciones de funcionamiento

DesarrolladorIdentificar parámetros de diseño modular y de componentes separados

DesarrolladorAsignar el personal de desarrollo

DesarrolladorDesarrollar el código

DesarrolladorPruebas de los desarrolladores (depuración primaria)

Desarrollo completado 24/04

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

Id Nombre de tarea

40 Pruebas41 Desarrollar planes de pruebas de unida

42 Desarrollar planes de pruebas de integ

43 Pruebas de unidades44 Revisar el código modular

45 Probar si los módulos de los comp

46 Identificar anomalías y anotarlas e

47 Modificar código

48 Volver a probar el código modifica

49 Pruebas de unidades completadas

50 Formación51 Desarrollar las especificaciones de form

52 Desarrollar las especificaciones de form

53 Identificar la metodología de formación

54 Desarrollar materiales de formación

55 Realizar estudio de posibilidades de us

56 Finalizar los materiales de formación

57 Desarrollar mecanismo para impartir la

58 Materiales de formación completados

59 Documentación60 Desarrollar las especificaciones de la a

61 Desarrollar el sistema de ayuda

62 Revisar la documentación de la ayuda

63 Incorporar los comentarios a la docume

64 Desarrollar las especificaciones de los

65 Desarrollar los manuales de usuario

66 Revisar toda la documentación para el

67 Incorporar comentarios a la documenta

68 Documentación completada

69 Componente piloto70 Designar grupo de pruebas

71 Desarrollar el mecanismo de entrega d

72 Instalar y distribuir el software

73 Obtener comentarios de los usuarios

74 Evaluar la información de las pruebas

75 Componente piloto completado

Pruebas

Desarrollar planes de pruebas de unidades usando las especificaciones del producto Personal de pruebas

Desarrollar planes de pruebas de integración usando las especificaciones del producto Personal de pruebas

Pruebas de unidades

Revisar el código modular Personal de pruebas

Personal de pruebasProbar si los módulos de los componentes se ajustan a las especificaciones del producto

Identificar anomalías y anotarlas en las especificaciones del producto Personal de pruebas

Personal de pruebasModificar código

Personal de pruebasVolver a probar el código modificado

Pruebas de unidades completadas 15/05

FormadoresDesarrollar las especificaciones de formación para los usuarios finales

Desarrollar las especificaciones de formación para el personal de soporte al cliente Formadores

FormadoresIdentificar la metodología de formación (utilizando PC, aulas, etc.)

Desarrollar materiales de formación Formadores

Realizar estudio de posibilidades de uso de la formación Formadores

Finalizar los materiales de formación Formadores

Desarrollar mecanismo para impartir la formación Formadores

Materiales de formación completados 28/05

Documentación

Escritores técnicosDesarrollar las especificaciones de la ayuda

Desarrollar el sistema de ayuda Escritores técnicos

Escritores técnicosRevisar la documentación de la ayuda

Incorporar los comentarios a la documentación de la ayuda Escritores técnicos

Escritores técnicosDesarrollar las especificaciones de los manuales de usuario

Escritores técnicos Desarrollar los manuales de usuario

Revisar toda la documentación para el usuario Escritores técnicos

Escritores técnicosIncorporar comentarios a la documentación de usuario

Documentación completada 07/05

Jefe de proyectoDesignar grupo de pruebas

Desarrollar el mecanismo de entrega del software

Instalar y distribuir el software Equipo de distribución

Obtener comentarios de los usuarios Equipo de distribución

Evaluar la información de las pruebas Equipo de distribución

Componente piloto completado 26/06

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

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07

CAPÍTULO 3 3.1 ESTADO DEL ARTE En esta sección se va ha comentar el estado del arte de los centros de asistencia, para ello se empezará comentando que metodología se sigue para ello. En una segunda parte se hará una comparativa de las diferentes aplicaciones relacionadas con la gestión de incidencias 3.1.1 Introducción a ITIL Hace unas décadas que los desarrollos en tecnologías de la información vienen teniendo un gran impacto en los procesos del negocio. La introducción de la tecnología Lan, cliente / servidor e Internet han permitido que las organizaciones lleven sus productos al mercado más rápido. Estos desarrollos han marcado la transición de la era industrial a la de la información. Las organizaciones jerárquicas tradicionales tienen dificultades para adaptarse a mercados en constante cambio, ello ha marcado una tendencia hacia organizaciones menos jerárquicas y más flexibles. De igual manera, dentro de las organizaciones se ha puesto énfasis en cambiar de funciones verticales, o departamentos a procesos horizontales que se extienden a toda la organización, y se le otorga al personal de menor nivel la autoridad para tomar decisiones. Teniendo en cuenta estos aspectos básicos se desarrollaron los procesos operativos de la gerencia de servicio en tecnologías de la información. En los años 80, la calidad de los servicios en tecnologías de la información que brindaba el gobierno británico era tal que se instruyó a la por entonces CCTA (Agencia Central de Telecomunicaciones y Computación, hoy Ministerio de Comercio, OGC) a que desarrollara una propuesta para que los ministerios y demás oficinas del sector público de Gran Bretaña utilizaran de manera eficaz y con eficiencia de costos los recursos en tecnologías de la información. El objetivo era desarrollar una propuesta sin compromisos con proveedor alguno. Esto dio como resultado la Information Technology Infrastructure Library (ITIL). ITIL nació de una colección de las mejores prácticas observadas en la industria del servicio de las tecnologías de la información. ITIL brinda una descripción detallada de un número de prácticas importantes en tecnologías de la información, a través de una amplia lista de verificación, tareas, procedimientos y responsabilidades que pueden adaptarse a cualquier organización en tecnologías de la información. En algunos casos hasta se han definido las prácticas como procesos que cubren las actividades más importantes de las organizaciones de servicio en tecnologías de la información. La vasta cantidad de temas cubiertos por las publicaciones transforma a la ITIL en un elemento de referencia útil para fijar nuevos objetivos de mejora para la organización en tecnologías de la información. La organización puede crecer y madurar con ellos. En base a ITIL se han desarrollado varios sistemas para la administración de servicio en tecnologías de la información, generalmente organizaciones del negocio. Los ejemplos incluyen Hewlett & Packard (HP ITSM modelo de referencia), IBM (Modelo de Proceso), Microsoft y muchos otros. Ésta es una de las razones por las que ITIL se ha convertido en el estándar de facto para describir

15

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 varios procesos fundamentales de la administración de servicio en tecnologías de la información. Esta adopción y adaptación de ITIL refleja la filosofía de ITIL, y es un desarrollo bienvenido ya que la ITIL se ha transformado en el tan necesario orden imprescindible para el actual medio heterogéneo y dividido de tecnologías de la información. ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez más de las tecnologías de la información para alcanzar sus objetivos corporativos. Esta dependencia en aumento ha dado como resultado una necesidad creciente de servicios en tecnologías de la información de calidad que se correspondan con los objetivos del negocio, y que satisfaga los requisitos y las expectativas del cliente. ITIL ofrece un marco común para todas las actividades del departamento de tecnologías de la información, como parte de la provisión de servicios, basado en la infraestructura de las tecnologías de la información. Estas actividades se dividen en procesos, que dan un marco eficaz para lograr una administración de servicio más madura. Cada uno de estos procesos cubre una o más tareas del departamento de tecnologías de información, tal como desarrollo de servicio, administración de infraestructura, provisión y soporte de los servicios. Este planteo del proceso permite describir las mejores prácticas de la administración de servicio independientemente de la estructura de organización real de la entidad. Muchas de estas prácticas son claramente identificables y son de hecho utilizadas hasta cierto punto en varias organizaciones de las tecnologías de la información. ITIL presenta estas mejoras prácticas de manera coherente. Los libros de ITIL describen cómo estos procesos, que se han identificado, pueden ser optimizados, y cómo la coordinación entre ellos puede ser mejorados. Los libros de ITIL también explican cómo los procesos se pueden formalizar dentro de una organización. Los libros de ITIL también ofrecen un marco de referencia para la terminología relevante dentro de la organización, y ayuda a definir los objetivos y a determinar el esfuerzo necesario. 3.1.2 Ventajas de ITIL para el cliente/usuario La entrega de servicios de las tecnologías de la información se orienta más al cliente y gracias a los acuerdos sobre la calidad del servicio se mejora la relación. Gracias a la metodología ITIL se describen mejor los servicios, se consigue un lenguaje más cómodo para el cliente, y a la vez con mayores detalles. Como consecuencia de la utilización de ITIL se manejan mejor parámetros de calidad y de costo del servicio. Su uso también mejora la comunicación con la organización al acordar los puntos de contacto. 3.1.3 Ventajas de ITIL para la organización La organización IT desarrolla una estructura más clara, se vuelve más eficaz, y se centra más en los objetivos corporativos La administración tiene más control y los cambios resultan más fáciles de manejar. Una estructura de proceso eficaz brinda un marco para concretar de manera más eficaz el outsourcing de los elementos de los servicios en tecnologías de la información.

16

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 Seguir las mejores prácticas de ITIL alienta el cambio cultural hacia la provisión de servicio, y sustenta la introducción de un sistema de administración de calidad basado en las series ISO 9000. ITIL establece un marco de referencia para la comunicación interna y la comunicación con los proveedores, como así también la estandarización y la identificación de los procedimientos. 3.1.4 Problemas potenciales de ITIL Su introducción puede llevar tiempo y bastante esfuerzo, y supone un cambio de cultura en la organización. Una introducción demasiado ambiciosa puede llevar a la frustración porque nunca se alcanzan los objetivos. Si la estructura de procesos se convierte en un objetivo en sí misma, la calidad del servicio se puede ver afectada de forma adversa. En ese caso, los procedimientos se transforman en obstáculos burocráticos que tratan de evitarse. No hay progreso por la falta de comprensión sobre lo que deben dar los procesos, cuáles son los indicadores de desempeño, y cómo se controlan los procesos. No se ven las reducciones de costo y la mejora en la entrega de los servicios. 3.1.5 Perspectiva general de la Gestión del Servicio según ITIL

ITIL postula que el servicio de soporte, la administración y la operación se realiza a través de seis procesos:

• Service Desk. • Manejo de incidentes. • Manejo de problemas. • Manejo de configuraciones. • Manejo de cambios. • Manejo de entregas.

Nos vamos a centrar en los tres primeros que son los que más se acercan al interés del proyecto. 3.1.5.1 Service DESK El primero de ellos es el service desk que es el punto central de contacto entre el cliente y el área de las tecnologías de la información en todos los aspectos que conciernen a los servicios de tecnologías de la información. Esto incluye funciones de help desk así como coordinación de peticiones de cambios, gestión del nivel de servicio, gestión de la configuración y todos los otros procesos de gestión del servicio de ITIL. El service desk no es un proceso sino una función dentro de la organización del servicio. En su papel especial como primer punto de contacto con el cliente, el service desk es de gran importancia, aun más cuanto representa la imagen y la calidad de servicio de la organización de tecnologías de la información. Determinar la estructura del service desk y seleccionar a personal adecuado para el mismo depende de un número importante de factores que conciernen a la forma y el tipo de la compañía. Según cambie ésta, la estructura del service desk necesitara cambiar en consecuencia, de un modo continuo. Básicamente, hay tres estructuras de service desk:

17

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 Service desk local: Cada localización o cada departamento en la compañía tiene su propia unidad de service desk local. Sus ventajas son la óptima proximidad al cliente en consecuencia la capacidad de reflejar sus necesidades individuales con más exactitud. La coordinación central y la estandarización de procesos son algunas de las tareas más necesarias por el service desk local. Service desk central: Existe un único service desk responsable para todas las unidades organizativas. Esto tiene la ventaja de la facilidad de manejo y la estandarización de procesos. Sin embargo, es más difícil atender individualmente los requerimientos locales de los clientes. En el caso de organizaciones extensas también puede surgir el problema de diferentes lenguas y zonas horarias. Organización de service desk virtual: Este tipo de service desk combina aspectos de las dos formas organizativas anteriores. Gracias a la tecnología actual, la información puede ser guardada centralizadamente y estar disponible globalmente. Las unidades locales de service desk proporcionan soporte on site a los clientes, mientras que la unidad central de service desk es responsable de todas las consultas así como de coordinar las organizaciones de servicio involucradas. El centro de servicio al usuario realiza una función esencial para la gestión de un servicio eficaz. Más que un centro de ayuda al usuario (CAU), el centro de servicio al usuario (CSU) actúa como la principal interconexión operacional entre la informática y sus usuarios. Una buena impresión inicial para cada uno de sus usuarios se basa en su funcionamiento y actitud. 3.1.5.2 Gestión de Incidencias

El principal objetivo de la gestión de incidencias es restaurar el funcionamiento normal del servicio lo más rápido posible de manera que suponga una interrupción mínima para la empresa, asegurando de ésta manera que se mantengan los mejores niveles de servicio y disponibilidad posibles.

Descripción

La gestión de incidencias conlleva el procesamiento de las consultas y las incidencias de cualquier tipo. Esto se consigue mediante un grupo de especialistas que trabajan virtualmente al unísono. En función de los niveles de habilidad y especialización de sus miembros, estos equipos se agrupan en unidades de primer, segundo y tercer nivel de soporte. En esta función, la gestión de incidencias asume el papel particular de mantener el contacto entre los sistemas de TI y el negocio. Junto con el service desk, la gestión de incidencias es el primer y más importante punto de contacto para el cliente.

¿Por que Gestión de Incidentes? - Para asegurar el mejor uso de los recursos de apoyo a la empresa. - Para desarrollar y mantener expedientes significativos relacionados con los incidentes. - Para diseñar y aplicar un método consistente a todos los incidentes. Definición de Incidente

18

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 Un incidente es cualquier acontecimiento que no forma parte del funcionamiento normal de un servicio y que causa o puede causar una interrupción o reducción en la calidad del mismo. Ejemplos de Incidentes - Una aplicación errónea o no disponible. - Indisponibilidad de hardware o uso restringido. - Solicitudes de servicio de información o ayuda (por ejemplo. una ampliación del servicio). Responsabilidades - Detección y registro de incidentes. - Clasificación de todos los incidentes y apoyo inicial. - Investigación y diagnostico. - Resolución y recuperación. - Cierre del incidente. - Propiedad, control, seguimiento, y comunicación del incidente. Ciclo vital de incidente Papel que desempeña el centro de servicio al usuario (CSU) en la gestión de incidentes. El centro de servicio al usuario (CSU) suele desempeñar un papel clave en el proceso de gestión de incidentes, registrando y vigilando el progreso de incidentes y reteniendo su pertenencia. Consideraciones Claves Factores críticos para el éxito de la gestión de incidentes: - Una base de datos de gestión de configuración (“Configuration Management Data Base” CMDB) actualizada. - Una “base de conocimientos” donde se registren datos de problemas y errores Conocidos, así como resoluciones y soluciones provisionales. - Disponibilidad de herramientas de apoyo automatizados y eficaces. - Estrechas relaciones con una gestión de nivel de servicio eficaz. Priorización Urgencia es una valoración de la rapidez con la que se requiere la resolución de un incidente. Impacto refleja el posible efecto que el Incidente tendrá sobre el servicio empresarial. La prioridad de asignación de recursos para la resolución de un Incidente se base en una combinación de impacto y urgencia, junto con otros factores relevantes tales como disponibilidad de recursos. Relación entre Incidentes, Problemas y Errores conocidos Cuando la causa de un Incidente no se puede identificar si una investigación al respecto es requerida, entonces se creará un expediente de problema representa un error desconocido en uno o más elementos de configuración. Una vez identificada la causa subyacente y determinado el remedio o la corrección adecuada a través de una solicitud de cambios (“request for change”. RFC) el problema pasa a ser un expediente de error conocido. Estructura

19

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 Los incidentes recién registrados serán comparados con la base de datos de incidencias, problemas y errores conocidos. Se emplean las soluciones provisionales disponibles con el fin de resolver rápidamente los incidentes. Esta base de conocimientos debe ser mantenida de manera que solamente sean presentados al centro de servicio al usuario (CSU) los expedientes pertinentes. Tramitación de incidentes mayores Incidentes mayores son aquellos que ejercen un efecto extremo sobre la comunidad de usuarios o cuando la interrupción es excesiva. Deberá notificarse a la gestión de problemas y deberá organizarse una reunión oficial con aquellas personas que pueden ayudar. El centro de servicio al usuario (CSU) deberá asegurar que sea mantenido en el registro del incidente un expediente de las acciones y decisiones adoptados. Beneficios - Reducción del impacto de los incidentes sobre la empresa, gracias a su resolución puntual. - Identificación proáctiva de las mejoras beneficiosas. - Disponibilidad de información empresarial enfocada en relación con el acuerdo de nivel de servicio ( “Service Level Agreement” SLA). -Vigilancia mejorada del rendimiento frente a los SLA. - Mejor utilización del personal que resulta en mayor eficiencia. - Eliminación de Incidentes y Solicitudes de Servicio Perdidos. - Información más precisa contenida en la base de conocimientos, permitiendo una auditoria constante al tiempo que se registran los incidentes. - Menos interrupción tanto para el personal de apoyo de informática como para el usuario. Posibles Problemas - Falta de compromiso por parte de la dirección. - Falta de niveles de servicio acordados con el cliente. - Falta de conocimiento o recursos para resolver incidentes. - Procesos o funciones ausentes o incorrectamente integrados. - Herramienta de Software ausentes, inadecuadas o demasiado caras. - Usuarios y personal de informática que eluden el cumplimiento de los procesos. Indicadores de rendimiento - Cumplimiento de los niveles de servicio acordados. - Uno de los factores ha tener en cuenta es el coste de las tecnologías de información. - Se valorará la satisfacción del cliente. - Se tendrán en cuenta los tiempos y respuesta y procesamiento. - Cumplir el ratio de auto resolución. Proceso de manejo de incidentes Su objetivo primordial es reestablecer el servicio lo mas rápido posible para evitar que el cliente se vea afectado, esto se hace con la finalidad de que se minimicen los efectos de la operación. Se dice que el proveedor se debe de encargar de que el cliente no perciba todos aquellos pequeños o grandes fallos que llegue a presentar el sistema.

20

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 A este concepto se le llama disponibilidad es decir que el usuario pueda tener acceso al servicio y que nunca se vea interrumpido. Para este proceso se tiene un diagrama que en cada una de sus fases maneja cuatro pasos básicos que son: propiedad, monitorización, manejo de secuencias y comunicación.

Detección y Registro de Incidentes

Clasificación y apoyo inicial

Sí Propiedad Solicitud de servicio Procedimiento de Vigilancia solicitud de servicioSeguimiento

No

Investigación y diagnóstico

Resolución y reparación

Cierre del incidente

Comunicación

Fig.3.1.1: Ciclo vital del incidente En el gráfico anterior vemos que se da como primera etapa la detección del incidente, esta etapa se da cuando el sistema presenta alguna anomalía o fallo, esto se puede traducir en un error en el sistema o que el usuario no puede hacer algo y recurre a pedir ayuda. Una segunda parte sería hacer una clasificación del incidente, en esta parte se ve si el error que se presenta es conocido o si nunca se ha presentado, de la mano a esta parte irá el soporte inicial que es el punto en el que el cliente llega a la mesa de servicio a solicitar ayuda, porque no sabe o no puede hacer algo. En caso de que el incidente sea conocido se hace el procedimiento de solicitud de servicio, es decir se ejecutan los pasos a seguir según el manual de procedimientos para poder llegar a la solución de una forma viable y eficiente. Una vez que se le dio una solución al incidente por medio del manual de procedimientos se recurre a la documentación y contabilización del incidente, para ver cuanta incidencia tiene este caso. Finalmente se hace una evaluación para ver si efectivamente se resolvió el incidente de forma satisfactoria, en el supuesto de ser afirmativo se cierra el incidente. El otro supuesto sería que la solución que se planteó no sea lo suficientemente eficiente o acertada para que se resuelva el problema, entonces se recurre a hacer una investigación y un diagnóstico de la situación para ver como se puede enfrentar el problema de frente y así conseguir resolverlo. Una vez que se tiene todo un contexto analizado se recurre a la ejecución de la propuesta de

21

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 solución del incidente y se hace un estudio para ver si el incidente es recuperable o si es un caso perdido, en la mayoría de los casos son recuperables, pero cuando el nivel de daño es muy fuerte, se da el caso por perdido. Finalmente se cierra el incidente y esta solución se documenta en la base de datos a la que se le llama base del conocimiento, aquí vienen documentadas todas las soluciones, con esto se consiguen establecer todos los pasos a seguir para que se haga de forma eficiente en el momento de volverse a presentar el incidente ya documentado, consiguiéndose así que sea mas fácil, rápida y eficiente su resolución. 3.1.5.3 Gestión de Problemas El objetivo de la gestión de problemas es minimizar el efecto adverso que tienen sobre los negocios los incidentes y problemas causados por errores en la infraestructura y prevenir proactivamente la ocurrencia de incidentes, problemas y errores. La gestión de problemas es de vital importancia para el área de soporte del servicio. Incluye el tratamiento de todos los fallos de los servicios de tecnologías de la información desde el punto de vista especial de identificación de la causa raíz de los mismos. Esto incluye recomendar cambios de los elementos de configuración a la gestión de cambios. Los procesos de gestión de problemas utilizan información proporcionada por otros procesos (por ejemplo por la gestión de incidencias o por la gestión de cambios). Además, la gestión de problemas toma una aproximación proactiva para detectar debilidades a priori y tomar medidas preventivas. ¿Por qué Gestión de Problemas? Las causas por las que se necesita recurrir a la gestión de problemas son las siguientes: - Para resolver los problemas de manera rápida y eficaz. - Para asegurarse de que los recursos sean dados una prioridad a fin de resolver los problemas en el orden más apropiado basado en la necesidad empresarial. - Para identificar y resolver proactivamente problemas y errores conocidos y con ello minimizar la posibilidad de que ocurran incidentes. - Para mejorar la productividad del personal de apoyo. - Para suministrar información de gestión relevante. Responsabilidades A continuación se hace una enumeración de las acciones que se deben de realizar a la hora de gestionar un problema: 1.- Control del problema. 2.-Identificación y registro del problema. 3.-Clasificación del problema. 4.-Investigación y diagnóstico del problema. 5.-Control del error. 6.-Identificación y registro del error. 7.-Evaluación del error. 8.-Registro de la resolución del error. 9.-Cierre del error.

22


la gestión de problemas debe ser implementada en paralelo o inmediatamente después de la gestión

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

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

Identificación y registro del

problema

Clasificación del problema

Investigación y diagnostico del

problema

RFC (petición de cambio) + resolución y

cierre del probl.

Resolución el registro de

error Clasificación y apoyo inicial

Identificación y registro del

error

Cerrar error y

problemas conocidos

Control de errores: seguimiento y monitorización de errores

23


i los recursos son escasos, deberá concentrarse en el control (reactivo) de problemas y errores

nfocarse en algunos de los problemas claves que causan las peores inconvenientes para el negocio.

eneficios

ervicios de tecnologías de la información continuos y más estables. iempo de indisponibilidad.

s negativos al aprovechar los registros que documentan problemas a priori.

través de una información de gestión mas adecuad. (CSU).

osibles problemas

usencia de un buen proceso de control de incidentes.

o de servicio al usuario (CSU).

problemas sobre

oceso de manejo de problemas

El Objetivo de este proceso es prevenir y reducir al máximo los incidentes, y esto nos lleva a una

n este proceso lo que se busca es que se pueda tener pleno control del problema, esto se logra

l diagrama de este proceso es muy particular, ya que se maneja en dos fases: la primera esta

n lo que respecta a la fase de control del problema: primero se tiene que identificar el problema en

de incidentes. Sdejando 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. ELa experiencia demuestra que el 20% de los Problemas causan el 80% de la degradación del servicio. B -S-Incremento de la productividad del usuario mediante la reducción del t-Mayor productividad del personal de soporte. -Prevención de errores. -Reducción de los efecto-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-Mejora de la tasa de soluciones en primera instancia del centro de servicio al usuario P -A-Falta de compromiso por parte de la dirección. -Debilitamiento del papel que desempeña el centr-Tiempo y recursos insuficientes para crear y mantener la base de conocimientos.-Incapacidad para evaluar de manera precisa el impacto que tienen los incidentes yla empresa. Pr

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. Edándole un seguimiento y una monitorización del problema. Erelacionada con lo que es el control del problema y la segunda es con el control del error. Ebase 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


sta solicitud de cambio implica que se va a tener que implementar la solución, finalmente se va a

on lo que respecta a la segunda fase del modelo, el control del error se hace por medio de la

ste modelo tiene una fase difícil, que es determinar que problemas están asociados, se intenta

as organizaciones dependen de forma creciente de los servicios de tecnologías de la información,

os procesos de negocio deben conducir las opciones tecnológicas, no estar a su merced, como

IL (Information Technology Infrastructure Library) es un conjunto de “mejores prácticas”

l valor intrínseco de ITIL es la adopción de nuevos procesos, una nueva forma de hacer las cosas.

ambiar las prácticas de trabajo supone un reto mayor que el despliegue de software o hardware.

os proyectos de implantación de “mejores prácticas” son similares a ERP (“Enterprise Resource

a resistencia al cambio existe en todas las organizaciones, en mayor o menor medida. Cuando se

IL se está introduciendo rápidamente en España, centrado inicialmente en el sector financiero y

a rama española del itSMF (IT Service Management Forum) estima que la convergencia con

Ehacer 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. Cidentificació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. Eidentificar que problemas influyen indirectamente al resto del sistema, evitando así que se presentan inconsistencias. Lya 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. Locurre con frecuencia. Y los procesos de de tecnologías de la información deben diseñarse con el objetivo de beneficiar el negocio. ITrecogidas en ocho libros. En conjunto, representan la experiencia colectiva de expertos a nivel mundial. E C LPlanning”). 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. Laborda 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. IToperadores de telecomunicación, aunque también en la Administración Publica. Un caso destacable es la Generalitat de Catalunya. LEuropa se producirá en el 2009.

25

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 La adopción de ITIL puede reportar enormes beneficios claramente mensurables: reducción de tiempos de indisponibilidad del servicio así como de costes y recursos innecesarios, mejora en estabilidad. Los plazos de ejecución suelen ser mayores de lo esperado, debido al cambio necesario en las prácticas de trabajo. El despliegue de las herramientas necesarias, si bien constituye un requisito, resulta de importancia secundaria. El tiempo y esfuerzo necesario para cambiar los procesos depende en gran medida de la cultura de la organización y de lo “flexible” que ésta sea al cambio. 3.1.6 El futuro de los Help Desks El término Help Desk probablemente ya no se encuentre en uso en el año 2010. Help Desk implica un acercamiento reactivo de soporte al cliente. Es común que cuando un cliente tiene un problema llame al Help Desk para conseguir ayuda, lo que por supuesto implica que el cliente tenía un tema específico. El Help Desk esperaba que el cliente lo contactara para ponerse en acción. En los últimos años se ha producido un cambio importante porque se pasó de ofrecer soporte reactivo a dar soporte preactivó. Para adaptarse a esta situación el término Help Desk está siendo reemplazado por el de Service Desk. El Service Desk moderno ofrece una gran variedad de servicios proactivos y reactivos. Por otro lado, ya no se lo considera un agregado de las tecnologías de la información sino que se lo comienza a reconocer y a operar como una unidad de negocios independiente. El support process managment suplantará a nuestra actual obsesión por la Administración de call tracking. En los últimos 5 - 10 años la administración de call tracking ha sido el foco de nuestra industria. Los proveedores de tecnología se han volcado de lleno al proceso de call tracking como algo que se presta con facilidad para la automatización de soluciones. Todavía existen muchos procesos de soporte que no están siendo dirigidos manual o automáticamente. Sin embargo estamos a la vera de adoptar por completo el support process managment. La depresión de la economía mundial ha sido el principal motivador y ha obligado a las empresas a concentrarse en mejorar los procesos por verse forzadas a hacer más con menos recursos. La disponibilidad de dominios públicos en marcos de trabajo de proceso, tales como ITIL (Information Techology Infrastructure Library), también están ayudando a transformar el servicio y el soporte de las tecnologías de información. Este nuevo foco sobre la administración completa de procesos del negocio llama a que los proveedores suministren soluciones de proceso más completas. Ya existen nuevas soluciones tecnológicas que se centran en la administración completa de procesos del negocio que van más allá de lo que hemos visto con respecto a las soluciones tecnológicas para nuestro mercado. Estas nuevas soluciones serán capaces de acomodar todos los procesos de servicio y de soporte al cliente y podrán ofrecer colaboración en los procesos de operación del negocio a toda la empresa como así también a los clientes tanto internos como externos.

26

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo3. Estado del Arte 20/03/07 Las habilidades de los empleados de soporte seguirán madurando. Mientras nosotros continuaremos poniendo el foco en los procesos de soporte y las opciones de automatización y el self service siga eliminando las tareas repetitivas y de bajo nivel del área de soporte, el rol del personal de soporte continuará madurando. En el futuro el personal de soporte tendrá habilidades para analizar la base de la causa, versus la resolución de síntomas. Se los alentará a dar soluciones de soporte proactivas, conocimiento accesible al usuario y a asegurar continuidad en el negocio versus respuestas reactivas y procedimientos de recuperación del negocio. El foco de la actividad de soporte será anticiparse a los requerimientos del cliente versus esperar para resolver los problemas de los mismos.

27

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 3. - Estado del Arte 20/03/07 3.2. ESTADO DEL ARTE. ESTUDIO DE LA COMPETENCIA Dentro del Estado del Arte reflejar como está el panorama actual es uno de los motivos principales de este estudio, además de conseguir detectar las carencias y fortalezas de nuestra competencia. Esto condicionará nuestras posibilidades de éxito. A continuación se realizará un listado y una descripción de las aplicaciones que se han encontrado relacionadas con el sector: 3.2.1 Aplicación GIGLOBAL SUPPORT Fig.3.2.1: Logo Aplicación Giglobal Support La primera de las aplicaciones que se quiere destacar es la de la empresa GIGLOBAL SUPPORT que ha desarrollado un gestor de incidencias para unidades de soporte y atención a clientes vía teléfono, fax, e-mail o web. Esta empresa ofrece poder acceder vía web a todas las consultas que hacen los clientes de forma ordenada, además también se puede ver el estado actual del proceso o seguir paso a paso el desarrollo de la incidencia hasta la resolución final, visualizando fechas, responsables de las tareas y tiempos de dedicación. Ofrece la posibilidad de que los clientes puedan realizar consultas vía web, de esta forma se conseguirá que los técnicos de la empresa trabajen de forma ordenada y controlada. También se podrá facilitar el acceso de los usuarios a incidencias de otros clientes a modo de "preguntas frecuentes", pudiendo ofrecerlo como una "garantía de soporte" en sus productos.Las incidencias se resuelven una vez y luego el “conocimiento” se reutiliza. Como Gestor de Incidencias de Soporte el sistema cuenta con las siguientes Fortalezas: -Totalmente vía web. Tanto el sistema se administración como el Portal de Soporte generado se acceden a través de una pantalla del explorador de internet sin necesidad de instalaciones ni descargas en el disco duro local. -Diseño gráfico propio o a elección, ofrece una galería de plantillas. Para la creación de su Portal de Soporte puede utilizar las plantillas gráficas que ponemos a su disposición o crear un formato gráfico personalizado por usted mismo. El aspecto gráfico se integra a su imagen corporativa de forma flexible. -Gestión de usuarios. Tanto alta como baja de usuario. Desde la Aplicación se podrá dar de alta a "empresas clientes" y dentro de cada empresa "personas de contacto" para identificarlos como responsables del ingreso de cada incidencia. También se podrá habilitar "personal de soporte" asociado a determinados "departamentos" y relacionarlos a determinados "productos" para identificarlos como responsables de producto.

26

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 3. - Estado del Arte 20/03/07 -Control de Acceso por Usuarios. Gestión de la navegación y administración. Se podrá definir "clientes" con acceso a gestionar sus incidencias y también "administradores" que podrán editar la configuración del propio sistema. -Se permite el registro de incidencias. A través de una interfaz web se ingresa y consulta información sobre incidencias registradas. Consultas por personal encargado de atender la solicitud, incidencias pendientes de respuesta, acciones realizadas sobre dicha incidencia, alta de nuevas incidencias, definición, origen y marcaje de prioridades. -Se ofrece la Gestión del Conocimiento. Las incidencias se almacenan en la base de datos, lo que hace natural la consulta de incidencias similares antes de abordar la resolución de una nueva optimizando tiempos y facilitando la incorporación de gente poco experta a la actividad de soporte. -Gestión de acciones a realizar tras el registro de una incidencia. Se permite la identificación / tipificación para su asociación a otras existentes, definición de tareas a realizar (por comprobación/reproducción del problema reportado), generación de la documentación pertinente (e-mail) a proveedor y/o cliente y registro del tiempo empleado en solventar cada incidencia (de suma importancia para el control de costes internos del personal de la unidad de trabajo). -Realización de estadísticas. Desde la aplicación se podrá realizar estadisticas por tipo de consulta y de tiempos por cliente o usuario. - Posibilidad de búsqueda contextual. Se podrá realizar una búsqueda contextual sobre toda la información almacenada. Ello permite encontrar respuesta a consultas ya realizadas y contestadas en su día, con independencia de a quién se diera el servicio y con la finalidad de optimizar tareas redundantes. -Uso del Interfaz web. Para el personal y para el usuario de soporte. Al personal de soporte le permite resolver incidencias y administrar las entidades básicas desde cualquier ordenador sin ningún requerimiento especial. A los usuarios les permite crear incidencias, aportar información, darlas por resueltas, ver el estado de la incidencia o buscar en la base de datos de incidencias. 3.2.2 Aplicación Demo HelpDesk Aplicación realizada en PHP [DEMHEL01] De esta aplicación hemos capturado como representativa la siguiente imagen en la que se muestra un listado de las incidencias, por los campos ID, Fecha y Hora, Nombre, Apellidos, Prioridad.

27

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 3. - Estado del Arte 20/03/07

Fig.3.2.2: Aplicación Demo HelpDesk

Diseño sencillo, colores azules, menú de navegación en el lateral izquierdo clasificado en dos bloques Acciones normales y Control del helpdesk. En el primer bloque tenemos: cambio de password, Crear un Informe, Abrir una pregunta, gestionar la configuración del helpdesk, base de conocimiento, ver preguntas activas, ver todas las preguntas, ver sólo las preguntas asignadas, salir. En el segundo bloque tenemos Gestionar las prioridades de las llamadas, Gestionar los estados de las llamadas, Gestionar las Categorías de las llamadas, Gestionar las Reglas de los emails, gestionar los Ficheros subidos. 3.2.3 Aplicación HELP DESK PRO DE AQCENTUS CORPORATION Inc. Aplicación realizada en Java [HELDES01]

28


Fig.3.2.3: Aplicación HELP DESK PRO DE AQCENTUS CORPORATION Inc

De esta aplicación hemos capturado como representativa la siguiente imagen (fig.3.2.3) en la que se muestra un listado de Incidencias con los siguientes campos ID, Fecha, Nombre, Categoría, Prioridad, Estado, Descripción, Técnico. A la izquierda, tenemos en un solo vistazo, las incidencias que están sin resolver, cuales están resueltas, todas ellas llevan un totalizado de las incidencias. Además podemos ver todas las FAQ´s, buscar una FAQ´s, añadir una nueva FAQ´s. 3.2.4 Aplicación Centro de Asistencia NAVIGATOR Aplicación realizada en php [NAVNET01]

Fig.3.2.4: Aplicación Centro de Asistencia NAVIGATOR

29

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 3. - Estado del Arte 20/03/07 En la anterior imagen (fig.3.2.4) se nos muestra la página principal con las 6 secciones principales muy claras en un solo vistazo. Estas seis secciones también se encuentran en el pie de la página. La información principal de la aplicación se encuentra representada por seis iconos. Las secciones son: Registrar, Enviar Ticket, Base de Conocimiento, Solucionador de problemas, Noticias y Descargas. En el panel central además nos encontramos con un listado de 4 items de los últimos artículos de la Base de Conocimiento. Se resalta además en este mismo panel la categoría más popular con el numero de visitas realizadas. El diseño en tonalidades de azul. En el panel de la derecha tenemos un buscador, además una sección con las 5 últimas noticias. En este mismo panel tenemos el panel de acceso de los usuarios. 3.2.5 Aplicación Centro de Asistencia ISOLSOFT Aplicación realizada en PHP [ISOSOL01]

Fig.3.2.5: Aplicación Centro de Asistencia ISOLSOFT

En la imagen (fig.3.2.5) se nos muestra la página principal con las 4 secciones principales muy claras en un solo vistazo. Las cuatro secciones son: Nuevo ticket, suscríbase, Base de Conocimientos y Descargas. Las cuatro secciones vienen acompañadas de un icono representativo. Estas cuatro secciones también se encuentran en un panel superior horizontal de color naranja destacando sobre el resto. En el panel de la izquierda tenemos un panel de acceso a la aplicación. Además tenemos la posibilidad de ver un ticket indicando la dirección de correo y el identificador del item. Se usan tonalidades azules.

30


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


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

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


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

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


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

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

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

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


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

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.

Funcionalidad GIGLOBAL HELPDESK

PRO DE AQCENTUS

NAVIGATOR

ISOLSOFT

PERL DESK

CRM DESK

JITBIT HELPDESK

SERVICE DESK

Gestión estados, Prioridades

No No Si Si Si Si Si Si Si

Gestión Categorías No Si Si Si Si Si Si Si Si

Gestión Subcategorias

No Si Si Si Si Si Si Si Si

Gestión Personal Resolución


Listados Estadísticas No Si Si Si Si Si Si Si Si

Creación rápida Item


Identificación (login) Si Si Si Si Si Si Si Si Si

Búsquedas Buscador general

Si No Si Si Si Si Si Si Si

Enviar email/imprimir Si Si Si Si Si Si Si Si Si

Extras

GIGLOBAL HELPDESK

PRO DE AQCENTUS

NAVIGATOR

ISOLSOFT

PERL DESK

CRM DESK

JITBIT HELPDESK

SERVICE DESK

Acercamiento a ITIL No 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

Mantenimiento

GIGLOBAL HELPDESK

PRO DE AQCENTUS

NAVIGATOR

ISOLSOFT

PERL DESK

CRM DESK

JITBIT HELPDESK

SERVICE DESK

Logs No No Si Si Si Si No No No

Los datos se guardan en

Base de datos Base de datos Base de

datos Base de datos

Base de datos

Base de datos

Base de datos

Estáticos o dinámicos

Base de datos

41


Diseño

GIGLOBAL HELPDESK

PRO DE AQCENTUS

NAVIGATOR

ISOLSOFT

PERL DESK

CRM DESK

JITBIT HELPDESK

SERVICE DESK

Utilización de iconos Si No No Si No Si Si Si Si

Uso de estilos CSS Si Si Si Si Si Si Si Si Si

Menú navegación siempre visible

Si Si Si Si Si Si Si Si Si

Mapa del Sitio No No No No No No No No No

Listado documentos relevantes

Si No No Si Si Si Si Si Si

Migas de pan Si No No No No No No No No

Cabecera y Pie Si Si Si Si Si Si Si Si Si

Animaciones en Flash No No No No No No No No No

Interfaz de publicación

GIGLOBAL HELPDESK

PRO DE AQCENTUS

NAVIGATOR

ISOLSOFT

PERL DESK

CRM DESK

JITBIT HELPDESK

SERVICE DESK

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 para la edición Si Si Si Si Si Si Si Si Si

Lenguaje desarrollo PHP PHP JAVA PHP PHP PERL ASP.NET

ASP.NET JAVA

42

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

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

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


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

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

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

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


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

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

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


Fig 4.4 Diagrama UML HELP Desk CEU

53

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

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


• 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


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

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

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

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


í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


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


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


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


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


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

suario.

o

or que se encuentra en: [W3CSS02] e ir orrigiendo los errores que se vayan encontrando.

SS02]. Donde se podrá comprobar si nuestra hoja de estilos cumple los estándares CSS .0.

. Uno ue esta bastante bien y que es gratuito se puede encontrar en la dirección [ANYBRO01]

la pagina indicada y muestra una lista indicando i son correctos o por el contrario están rotos.

ones mas comunes entre los usuarios que en la actualidad suele ser 00x600 pixeles o superior.

orrectas. A continuación se muestra la visualización utilizando l navegador internet explorer.

u Pruebas de validación. Para realizar las pruebas de validación del formato se puede acceder a la pagina del consorciW3C 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 validadc También se puede acceder al comprobador de paginas de estilo CSS desde la dirección: [W3C2 Comprobación de enlaces rotos. Existen bastantes programas disponibles para realizar la comprobación de enlaces rotosq Este programa comprueba todos los enlaces des Comprobación de resolución. Para una correcta visualización de la aplicación debe comprobarse que esta se muestra correctamente en las resoluci8 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 ce

65

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

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

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


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


• 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


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


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


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

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


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


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


} 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


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


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


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

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

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

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

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

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

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

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

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

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=".\images\icon.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

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

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

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

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 6. Diseño Interface 20/03/07 <configuration>  <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

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

Fernando Leandro Baladrón Proyecto fin de carrera Capítulo 7 .Conclusiones 20/03/07

95

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


96

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:


97

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.


98

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


99

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.

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

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

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

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

http://www.demohelpdesk.com/

http://www.helpdeskpro.net/tryit.htm

http://www.navigatoris.net/support/index.php?languageid=2

http://www.isolsoft.com/demo/

http://www.perldesk.com/demo.0.html

http://www.crmdesk.com/demo.htm

http://www.jitbit.com/helpdesk.aspx

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

http://demo.servicedeskplus.com/

http://www.codeproject.com/

http://www.programacion.com/

http://www.aspfacil.com/

http://www.sql-server-vb-asp.net/

http://es.gotdotnet.com/quickstart/aspplus/doc/webdatabinding.aspx

http://www.miliuco.net/aspnet/clikear.xml/intro.htm

http://www.elguille.info/NET/default.aspx

http://www.foro-helpdesk.com/







http://www.crue.org/grupostrabajo/tecnologiasInformacion/ponencias/171006/Dumbo.ppt

http://roxen.bizcom2.com/~author/Foundations/FoundationsPreview.pdf

http://www.coit.es/publicaciones/bit/bit160/46-49.pdf

http://www.ikea.com/es/es/

http://www.itil.org/

http://www.ogc.gov.uk/itil

http://www.itsmf.es/index.asp?Page=1

http://es.wikipedia.org/wiki/ITIL

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

http://www.useit.com/eyetracking/

http://www.anybrowser.com/linkchecker.html

http://jigsaw.w3.org/css-validator/

http://bd.ub.es/pub/termens/taller/css2-es.pdf

http://bd.ub.es/pub/termens/taller/css2-es.pdf

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


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


-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


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


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


-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


-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):


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):


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):


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


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


-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


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


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

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

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)

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

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

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

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

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.

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:

• 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

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)

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

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

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

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

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.

Modeling:

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

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

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.

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

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

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;

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 {

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; }

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;

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;

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; }

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;

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;

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;

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********************************/ /**************************************************************/

proyecto final de carrera. ing.informática. help-desk

Education