Repositorio Institucional de Documentos

Gestión ubicua de incidentes y problemas basada en ITIL LUIS COMPS FORCÉN Director: Eladio Domínguez Murillo Departamento: Informática e Ingeniería de Sistemas Ponente: José Ángel Bañares Bañares Departamento: Informática e Ingeniería de Sistemas Curso Académico: 2009/2010 Septiembre 2010 Tomo 1 / 2. Memoria Gestión ubicua de incidentes y problemas basada en la norma ITIL Luis Comps Forcén 1 Gestión ubicua de incidentes y problemas basada en la norma ITIL Resumen El proyecto nace ante la necesidad de encontrar una solución al problema derivado de las necesidades de comunicación y registro de acontecimientos que han aparecido en el trabajo colaborativo que deben realizar los agentes pertenecientes a la cadena de valor en la gestión de incidencias y problemas en el marco de la gestión de un biobanco. La solución encontrada a través del proyecto se encuentra actualmente en explotación en la gestión del biobanco ARASIS que, bajo la responsabilidad del Instituto Aragonés de Ciencias de la Salud (I+CS) y del Centro Nacional de Investigaciones Cardiológicas (CNIC), está dirigido a la identificación de determinantes genéticos y de estilo de vida que condicionan la aparición de factores de riesgo cardiovascular que se está realizando en el proyecto Aragon Workers Health Study (AWHS) con los trabajadores de la General Motors. Un biobanco es un registro de muestras biológicas, que se guardan con fines diagnósticos o de investigación médica. En las tareas ordinarias del biobanco se pueden producir incidentes, que pueden provocar deficiencias en el servicio y que deben solventarse lo más rápido posible. La gestión del incidente correspondiente, la reposición del servicio si es necesario, es esencial para la calidad del biobanco. La gravedad de un incidente o su reiteración puede que determine la existencia de un problema en la gestión que es necesario solventar. El gobierno del biobanco tomó la decisión de utilizar la norma ITIL para la gestión de incidentes y problemas, norma basada en la ejecución de subprocesos y actividades por diversos agentes bajo responsabilidades determinadas que proporcionan un flujo de trabajo entre los agentes dirigido por comunicaciones. Un problema añadido a la gestión es que, en el caso que estudio los agentes están muy dispersos geográficamente. El problema que se planteó era encontrar una solución informática que, por una parte, diera solución a una implantación de un sistema de comunicaciones seguras con independencia de la ubicación geográfica de los agentes y, por otra parte, que proporcionará un registro de todos los acontecimientos y, en particular, de las decisiones tomadas. Un requisito añadido es que los agentes serían personas no cualificadas informáticamente. Por tanto el sistema, y la interacción con el mismo, tenía que estar adaptado para este tipo de personas. La solución encontrada al problema planteado, que se presenta como PFC, ha sido la construcción de un entorno colaborativo, que recoge el sistema de comunicaciones, utilizando tecnología en el ámbito de la Web 2.0 Profesional soportada por el protocolo de Gestión ubicua de incidentes y problemas basada en la norma ITIL Luis Comps Forcén 2 comunicaciones seguras https, apoyada, en particular, mediante mensajes de texto a móviles (SMS) y correos electrónicos para potenciar la usabilidad del sistema. El proyecto presenta innovación a nivel de procesos, ya que se implementa una integración tecnológica de los procesos ITIL en los procesos propios de la gestión de un biobanco. Los módulos desarrollados incorporan además aspectos de innovación de producto industrial, ya que es la única herramienta, a nivel internacional, que implementa completamente la norma ITIL con las características de ubicuidad y seguridad planteadas en este proyecto; siendo además la única que incorpora el envío de mensajes instantáneos a terminales de dispositivos móviles. La propiedad intelectual e industrial de la aplicación y de toda la documentación técnica pertenece a Infozara S. L. Gestión ubicua de incidentes y problemas basada en la norma ITIL Luis Comps Forcén 3 Índice 1. Introducción ......................................................................................................................... 5 1.1- Objetivo del proyecto .................................................................................................. 5 1.2- Contexto de realización y antecedentes ...................................................................... 5 1.3- El problema a resolver ................................................................................................. 6 1.4- Cómo se resuelve el problema .................................................................................... 6 1.5- Elementos innovadores ............................................................................................... 7 1.6- Tecnología utilizada ..................................................................................................... 7 1.7- Contenidos y alcance del documento .......................................................................... 8 1.8- Motivos de realización de proyecto ............................................................................ 9 2. La solución del problema .................................................................................................... 10 3. Desarrollo de la aplicación ................................................................................................. 11 3.1- Distribución temporal del proceso ............................................................................ 11 3.2- Trabajo previo ............................................................................................................ 12 3.3- Desarrollo de la aplicación ......................................................................................... 12 3.4- Pruebas realizadas ..................................................................................................... 13 4. Resultado obtenido ............................................................................................................ 15 4.1- Alcance de la solución ................................................................................................ 15 4.2- Aspecto de la aplicación ............................................................................................ 15 5. Conclusión y trabajo futuro ................................................................................................ 18 5.1- Cumplimiento de los objetivos del proyecto ............................................................. 18 5.2- Dificultades encontradas en el desarrollo del proyecto ............................................ 18 5.3- Mejoras posibles de la aplicación .............................................................................. 19 5.4- Conclusiones personales ............................................................................................ 19 6. Referencias ......................................................................................................................... 20 7. Glosario ............................................................................................................................... 21 Gestión ubicua de incidentes y problemas basada en la norma ITIL Luis Comps Forcén 4 Relación de figuras Figura M.1 Modelo en cascada con realimentación. .................................................................. 11 Figura M.2 Diagrama de Gantt. ................................................................................................... 12 Figura M.3 Pantalla de registro de incidentes. ........................................................................... 16 Figura M.4 Ejemplo de listado de incidentes pendientes. .......................................................... 16 Figura M.5 Ventana emergente para la introducción de causas en el análisis de problemas. ... 17 Figura M.6 Filtro para la búsqueda transversal de incidentes. ................................................... 17 Gestión ubicua de incidentes y problemas basada en la norma ITIL Luis Comps Forcén 5 1. Introducción En este capítulo se realiza una introducción del proyecto fin de carrera, exponiendo el objetivo del proyecto, el contenido de esta memoria y las motivaciones que llevaron a realizarlo. 1.1- Objetivo del proyecto Como objetivos del proyecto, tal como se incluyó en la propuesta del proyecto fin de carrera, tenemos: • Comunicación inmediata de incidentes y problemas vía SMS y correo electrónico (lo que implica su visualización tanto en ordenadores como en terminales móviles). • Creación de módulos para el registro de incidentes y problemas integrados en la aplicación del biobanco ARASIS. • Uso de cauces de comunicaciones seguras para todo ello. 1.2- Contexto de realización y antecedentes Dentro de la empresa Infozara Consultoría Informática S.L., se está desarrollando el proyecto ARASIS. Se trata de un proyecto que tiene como objetivo el desarrollo de una herramienta informática para la gestión de un biobanco, incluyendo soporte a investigaciones básicas, investigaciones traslacionales e investigaciones clínicas de las muestras biológicas que anualmente serán extraídas a los trabajadores de la General Motors. Está catalogado como un proyecto de I+D+I y dispone de financiación del Ministerio de Industria, Turismo y Comercio, del CNIC y del I+CS. ARASIS se encuentra enmarcado dentro del proyecto LISBB, de donde se obtiene su financiación. El proyecto LISBB tiene como objetivo el desarrollo de una herramienta para la gestión colaborativa de biobancos en el ámbito de la Web 2.0, de modo que la gestión estará dirigida por un mapa de procesos. La información se almacena bajo la forma de una Base de Datos Longitudinal Dirigida por Procesos Actuando sobre Objetos, y su explotación estará dirigida a facilitar el Análisis Longitudinal de la información almacenada. En el proyecto LISBB participan como colaboradores Idea Informática, Universidad de Zaragoza e Infozara, tiene un coste de ejecución de 1.201.271 € y un tiempo de ejecución de 14 meses y medio. La explotación de este proyecto, se efectuará dentro del proyecto AWHS –Aragon Workers Health Study-, proyecto para identificar factores epidemiológicos, de estilo de vida, ambientales y genéticos implicados en la enfermedad cardiovascular, a través de un estudio longitudinal a realizar en el que participan los trabajadores de la General Motors. El proyecto ARASIS se encuentra dividido en dos partes: • Aplicación Cliente-Servidor: En ella se registran en el sistema la relación entre muestras extraídas y empleado al que pertenecen. A través de esta aplicación se establece una relación entre el código de un empleado y un código anonimizado que se utiliza en la segunda parte. Gestión ubicua de incidentes y problemas basada en la norma ITIL Luis Comps Forcén 6 • Aplicación Web: Es la componente principal del proyecto ARASIS. En esta aplicación se realiza toda la gestión de almacenamiento de los datos correspondientes de los trabajadores mediante su código anonimizado, así como la gestión y consulta de la información presentes en ellos. La razón de esta división es debido a que la aplicación Cliente-Servidor está creada para el acceso interno (local) a la base de datos de la General Motors, ya que este acceso no puede darse desde la Web. Así, la aplicación Web trabaja exclusivamente con datos anónimos. 1.3- El problema a resolver El proyecto del biobanco ARASIS se desarrolla por varias entidades (Infozara y la Universidad de Zaragoza, en colaboración con el CNIC (Centro Nacional de Investigaciones Cardiológicas) y la General Motors) estableciendo un marco de trabajo colaborativo. En muchas ocasiones personas alejadas geográficamente (Zaragoza, Madrid, Figueruelas) trabajan bajo la misma aplicación y sobre los mismos datos. Durante la ejecución de las actividades ordinarias propias del biobanco pueden ocurrir eventos que provoquen una pérdida del servicio o una disminución de la calidad del mismo. A estos eventos los denominaremos incidentes. Resulta obvia la necesidad de que la ocurrencia de estos eventos llegue al conocimiento de los encargados de su resolución lo antes posible y de una forma fidedigna, independientemente del lugar donde se encuentren estos y de si están teniendo o no acceso en ese momento a la aplicación del biobanco. Así pues necesitaremos tanto una estructura de avisos a los responsables de la gestión de incidentes, como un canal de comunicaciones seguro que garantice su recepción y la privacidad de los datos que tratan. Si los incidentes se repiten en el tiempo o son suficientemente importantes, pasarán a denominarse problemas. Además por definición, un biobanco requiere trazabilidad, es decir, requiere que de todos los elementos que en él participan exista un registro que permita seguir su historia. Se crea por tanto una necesidad de estudio, análisis y almacenamiento de los incidentes y problemas para poder ser resueltos, ya sea de forma automática o por parte de los propios usuarios del biobanco. Mediante el registro en una base de datos de toda esta información se desea adquirir un conocimiento de incidentes previos para que los que puedan surgir a posteriori se resuelvan más fácilmente y por tanto tengan un impacto menor en las tareas del biobanco. Todo este trabajo debía ser integrado en la aplicación ya existente de ARASIS, enmarcada en el ámbito de la Web 2.0, y siguiendo los procesos que se nos diesen en alguno de los estándares de calidad de las TI. 1.4- Cómo se resuelve el problema Se decide solventar el problema de la comunicación de incidentes con un trabajo en varios frentes: 1) Se decide que el método de avisos a utilizar será por medio de e-mails y SMS, una forma simple y a la vez eficiente de hacerlo. Así garantizamos la ubicuidad de la gestión de incidentes, es decir, cualquier responsable del biobanco, Gestión ubicua de incidentes y problemas basada en la norma ITIL Luis Comps Forcén 13 Mozilla Firefox, pero posteriormente se adaptó a otros navegadores web, como Safari o Explorer. Posteriormente se paso a diseñar los javabeans que permiten la comunicación entre la base de datos y el controlador y que implementarían el patrón MVC, todo esto trabajando con la herramienta de desarrollo en Java Netbeans y usando el framework de Struts. Se trabajó siguiendo la estructura que ya se estaba utilizando en ARASIS, con unos archivos JSP que se encargan de implementar la parte visual de la aplicación que previamente diseñamos en html, y una serie de clases java (denominadas beans) que se encargan de controlar la capa de negocio y la conexión con la base de datos. La estructura de la aplicación se explica con un poco más de detalle en el anexo correspondiente. Una vez terminado este proceso de diseño se programó la parte de alertas. Para el envío de correos electrónicos se decidió incluir la librería Javamail, que integra todas las herramientas necesarias para la creación y envío de este tipo de mensajes. Para la parte de alertas a teléfonos móviles, se consideró en un principio la posibilidad de crear un servidor propio que gestionase este tipo de mensajes, pero su coste y dificultad lo hicieron inviable. Así pues se decidió buscar otras soluciones, siendo la más eficiente el contratar un servicio de enlace con las operadoras de telefonía móvil, el cual nos viene dado por la pasarela SMS de la empresa ALTIRIA. Esta empresa nos proporciona un API o interfaz que adaptamos a nuestra aplicación, y que consigue el envío de nuestro mensaje vía protocolo http a los servidores de esta empresa, que nos hace de puente con la operadora móvil correspondiente ue será la que envíe el mensaje. Concluido el diseño de la aplicación, se realizó la inclusión, en un principio solo para la parte de incidentes y problemas, y posteriormente para toda la parte web de ARASIS, del protocolo de comunicaciones seguras https, creándose los contenedores de claves necesarios para su funcionamiento. 3.4- Pruebas realizadas Las pruebas que se han realizado sobre la aplicación se pueden dividir en los grupos que se muestran a continuación: Pruebas unitarias: Durante la realización de cada subsistema de ambos módulos se realizaron las pruebas propias del mismo utilizando, en caso de ser necesario, alguna parte del sistema ya desarrollado. Pruebas de integración: Estas pruebas se realizaron tras la integración de cada subsistema dentro del sistema completo, y tras la integración de los dos módulos dentro del conjunto de la aplicación del biobanco. Se probaron todos los componentes desarrollados para cada uno de los módulos. En estas pruebas participó mi jefe de proyecto Antonio Carceller. Pruebas de validación: Estas pruebas se realizaron para comprobar que los módulos desarrollados cumpliesen el cometido para el que se habían diseñado. En ellas participó también el jefe de proyecto. Gestión ubicua de incidentes y problemas basada en la norma ITIL Luis Comps Forcén 14 Pruebas de sistema: Pruebas de todo el sistema desarrollado. Estas pruebas se hicieron una vez que se completó la integración en ARASIS. En estas pruebas, además del jefe de proyecto, participó también el director del proyecto Eladio Domínguez. Pruebas de carga: Una vez integrado los módulos, se realizaron pruebas para comprobar si varias peticiones de incidencias a la vez eran registradas correctamente en la base de datos. Gestión ubicua de incidentes y problemas basada en la norma ITIL Luis Comps Forcén 15 4. Resultado obtenido Este capítulo muestra brevemente el resultado obtenido tras el desarrollo completo del proyecto. 4.1- Alcance de la solución A continuación se enumeran las funcionalidades que posee la aplicación realizada: a) Se ha conseguido la comunicación y aviso de ocurrencia de incidentes y problemas mediante el envío de correos electrónicos y mensajes SMS que pueden ser atendidos en terminales móviles. b) Se han creado dos módulos que permiten el registro, análisis y resolución de incidentes y problemas que acaecen en las tareas del biobanco ARASIS, además de su almacenamiento en la base de datos del conocimiento para su posible posterior consulta. c) Se implementa una búsqueda transversal de incidentes y problemas, para aprovechar el conocimiento adquirido previamente en la resolución de hechos anteriores. d) Se ha logrado implementar un sistema de comunicaciones seguras gracias al protocolo https que consigue tanto privacidad como evitar pérdidas en la información. 4.2- Aspecto de la aplicación A continuación se muestran unas capturas de la aplicación. Se puede observar el diseño de los módulos, integrados en la aplicación del biobanco ARASIS. Para poder ver en más detalle toda la funcionalidad de los módulos, existe un anexo con el manual de usuario completo de la aplicación. Gestión ubicua de incidentes y problemas basada en la norma ITIL Luis Comps Forcén 16 Figura M.3 Pantalla de registro de incidentes. Figura M.4 Ejemplo de listado de incidentes pendientes. Gestión ubicua de incidentes y problemas basada en la norma ITIL Luis Comps Forcén 17 Figura M.5 Ventana emergente para la introducción de causas en el análisis de problemas. Figura M.6 Filtro para la búsqueda transversal de incidentes. Gestión ubicua de incidentes y problemas basada en la norma ITIL Luis Comps Forcén 18 5. Conclusión y trabajo futuro Este capítulo está dividido en cuatro secciones en las que se analiza el cumplimiento de objetivos, las principales dificultades encontradas en el desarrollo del proyecto, se muestran las posibles futuras mejoras de la aplicación y, por último, se muestran las conclusiones personales. 5.1- Cumplimiento de los objetivos del proyecto La aplicación desarrollada consigue los objetivos que se marcaron en la propuesta del proyecto fin de carrera. Además de una gestión de incidentes y problemas muy fiel a lo que nos marca la norma ITIL, conseguimos una ubicuidad en la gestión, ya que podemos conocer la existencia de incidentes a pesar de no estar conectados a la aplicación en ese momento. Todo esto mediante un diseño integrado en ARASIS, pero que por su diseño permite una cierta independencia y portabilidad. 5.2- Dificultades encontradas en el desarrollo del proyecto A continuación se enumeran las principales dificultades que me encontré durante el trabajo en el proyecto fin de carrera. La primera y más importante para mí fue el encontrarme en un entorno totalmente nuevo. Viniendo de ingeniería de telecomunicaciones, el tratar con bases de datos, java, html y partiendo desde cero suponía un reto importante al que me tuve que enfrentar. Se solventó gracias a la preparación del Máster BDI y a la propia experiencia que fui adquiriendo conforme iba avanzando en las diferentes fases del proyecto. Otra dificultad a solventar fue el adaptarme en todas las fases del diseño a la estructura ya utilizada en el biobanco ARASIS. Para ello tuve que emplear un tiempo en familiarizarme con la metodología de trabajo tanto a la hora de realizar el diseño de la base de datos como en la programación de propios módulos. En todo ello fue inestimable la colaboración tanto del jefe de proyecto como del resto de compañeros que estaban trabajando en ella. El uso de una base de datos longitudinal es positivo porque permite guardar la historia de todos y cada uno de los objetos que se originan en el trabajo de la aplicación pero a la vez requiere un diseño muy preciso de la misma, y que muy a menudo fue un origen de numerosos quebraderos de cabeza, sobre todo en el caso de estados que permitían dar marcha atrás en el flujo de procesos (los estados de reanálisis por ejemplo). El diseño de la capa de presentación, aun siendo simple, exigía adaptarla a varios navegadores, algo que siempre acaba dando algún que otro problema, sobre todo trabajando con Internet Expolorer. El hacer eficientes las consultas a la base de datos, sobre todo en el caso de las búsquedas transversales, para ahorrar tanto tiempo de carga como recursos de la propia máquina también fue un escollo que finalmente se solventó satisfactoriamente. Gestión ubicua de incidentes y problemas basada en la norma ITIL Luis Comps Forcén 19 5.3- Mejoras posibles de la aplicación Una vez terminado el trabajo que era objetivo del proyecto fin de carera, quedan varias líneas de trabajo abiertas que podrían explorarse en un futuro. • Mejorar las búsquedas. Actualmente la cantidad de campos que se pueden usar como filtro para las búsquedas transversales no es muy amplia. Una posible mejora sería ampliar la capacidad de ese filtrado para hacer las búsquedas lo mas específicas posible. • Posibilidad de integración de los módulos en otras aplicaciones (SUSER). Aunque en principio los módulos se diseñaron para integrarlos en el biobanco ARASIS, dado el resultado satisfactorio del proyecto se pensó en, utilizando el diseño ya realizado, crear una aplicación independiente que sea portable y pueda usarse en otras aplicaciones y proyectos, que adapte la norma ITIL pero de una forma más amplia. De ahí surge el proyecto SUSER (SUpport SERvice) que actualmente se desarrolla en Infozara y que abarca la gestión de incidentes, problemas, versiones, cambios y configuraciones, todo ello mediante la aplicación de los procesos de ITIL V3. • Mejora de incidentes relacionados. De una forma parecida a lo que sucede con las búsquedas transversales, los criterios para declarar un incidente como relacionado con otro son ahora mismo escasos (únicamente temporales). Se podrían ampliar por protocolo de ejecución, usuario, descripción de la solución, etc. • Adaptación de aplicación para uso en terminales móviles. Una futura línea de trabajo muy interesante dado el desarrollo cada vez mayor de los nuevos terminales móviles con conexión a Internet sería el poder tener ciertas partes de ARASIS disponibles en versión móvil, para poder acceder a ellas y trabajar sin necesidad de tener un ordenador delante. La parte de incidentes y problemas, debido a la importancia que tiene para el correcto funcionamiento de las tareas del biobanco sería una de las que más se beneficiaría de esta opción. 5.4- Conclusiones personales Tras finalizar el proyecto y viendo el resultado obtenido y de dónde había partido (un nulo conocimiento de la mayoría de los campos en los que tuve que trabajar) me he sentido muy satisfecho con el resultado obtenido. La realización de este proyecto me ha ayudado a crecer tanto en el aspecto personal como en el profesional. He aprendido a usar tecnologías que me eran desconocidas, a superar obstáculos y a adaptarme a trabajar en un ambiente de empresa y en equipo. Además el ver como este trabajo ha servido de germen para el nacimiento de un nuevo proyecto es muy alentador. Para mí personalmente ha sido una experiencia muy importante y que espero me sirva en mi futuro laboral. Gestión ubicua de incidentes y problemas basada en la norma ITIL Luis Comps Forcén 20 6. Referencias [1] API de la versión 5 de JEE. Disponible en http://java.sun.com/javaee/5/docs/api/ [2] Netbeans. Disponible en web: http://www.netbeans.org [3] Documentación PostgreSQL. Disponible en web: http://www.postgresql.org/docs [4] Struts. Disponible en web: http://struts.apache.org/ [5] JSP. Disponible en web: http://java.sun.com/products/jsp/ [6] Javascript. Disponible en web: http://www.w3schools.com/JS/default.asp [7] LISBB. LISBioBank: Longitudinal Information System Biobank AVANZA I+D / TSI-020302-2008-8 Idea Informática S. A., Universidad de Zaragoza, Infozara S. L. En la web: http://www.lisbb.es/WebLISBB/?idioma=es [8] Javamail. Disponible en web: http://www.oracle.com/technetwork/java/index-jsp- 139225.html [9] ALTIRIA. http://www.altiria.com/web/sms_mms/tecnicos [10] Https. http://www.w3.org/Protocols/rfc2616/rfc2616.html [11] JDBC. Disponible en: http://java.sun.com/docs/books/tutorial/jdbc/basics/index.html [12] UML. http://www.uml.org/ [13] Ian Sommerville. Ingeniería del software. Addison-Wesley, 6ª edición, 2002. Gestión ubicua de incidentes y problemas basada en la norma ITIL Luis Comps Forcén 21 7. Glosario • API: Una interfaz de programación de aplicaciones (del inglés application programming interface) es el conjunto de funciones y procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción. • Aplicación: Un tipo de programa informático diseñado como herramienta para permitir a un usuario realizar uno o diversos tipos de trabajo. • Biobanco: establecimiento público o privado, sin ánimo de lucro, que acoge una colección de muestras biológicas concebida con fines diagnósticos o de investigación biomédica y organizada como una unidad técnica con criterios de calidad, orden y destino. • Diagrama de Gantt: Herramienta gráfica cuyo objetivo es mostrar el tiempo de dedicación previsto para las diferentes tareas o actividades a lo largo de un tiempo total determinado. • Framework: En el desarrollo de software, un framework es una estructura conceptual y tecnológica de soporte definida, normalmente con artefactos o módulos de software concretos, con base en la cual otro proyecto de software puede ser organizado y desarrollado. Típicamente, puede incluir soporte de programas, bibliotecas y un lenguaje interpretado entre otros programas para ayudar a desarrollar y unir los diferentes componentes de un proyecto. • Https: Protocolo seguro de transferencia de hipertexto (del inglés Hypertext Transfer Protocol Secure). Es un protocolo de red basado en el protocolo HTTP, destinado a la transferencia segura de datos de hipertexto, es decir, es la versión segura de HTTP. • Incidente: Cualquier evento que no forma parte de la operación estándar de un servicio y que causa, o puede causar, una interrupción o una reducción de calidad del mismo. • ITIL: Biblioteca de Infraestructura de Tecnologías de la Información (del inglés Information Technology Infrastructure Library). Conjunto de buenas prácticas en el ámbito de las tecnologías de la información, que se encargan de asegurar la calidad y eficiencia en las operaciones de TI. • Java: Lenguaje de programación orientado a objetos, desarrollado por Sun Microsystems, que permite la ejecución de las aplicaciones con él desarrolladas en diferentes plataformas. • Librería: Conjunto de procedimientos, funciones y objetos agrupadas en un archivo para ser aprovechados por otros programas. Gestión ubicua de incidentes y problemas basada en la norma ITIL Luis Comps Forcén 22 • Máquina virtual de Java: Software que crea un entorno virtual, entre la plataforma y la computadora, que ejecuta el código resultante de la compilación de un programa escrito en el lenguaje de programación Java. • Módulo: Un módulo es una parte de un programa de ordenador. De las varias tareas que debe realizar un programa para cumplir con su función u objetivos, un módulo realizará una o varias de dichas tareas. • Patrón: Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias. • Problema: Un incidente que se repite en el tiempo o es lo suficientemente importante como para que se deban buscar las causas que lo producen. • Requisito: Declaración abstracta, en lenguaje natural o formal, que define un servicio que debe proveer un sistema o una restricción del mismo. • Servidor de aplicaciones: Servidor en una red de computadoras que ejecuta ciertas aplicaciones. • Struts: Herramienta de soporte para el desarrollo de aplicaciones Web bajo el patrón MVC bajo la plataforma J2EE (Java 2, Enterprise Edition). • TI: Tecnologías de la información (también denominadas tecnologías de la información y la comunicación o TIC). Conjunto de elementos y técnicas utilizadas en el tratamiento y la transmisión de las informaciones, principalmente de informática, Internet y telecomunicaciones. • Web 2.0: Fenómeno social, basado en la interacción que se logra a partir de diferentes aplicaciones web, que facilitan el compartir información, la interoperabilidad, el diseño centrado en el usuario y la colaboración en la World Wide Web.