Proyecto HelpDesk sobre plataforma Link-All

Presentación del tema: "Proyecto HelpDesk sobre plataforma Link-All"— Transcripción de la presentación:

1 Proyecto HelpDesk sobre plataforma Link-All
Grupo 05 Proyecto de Ingeniería de Software 2005

2 Integrantes Agustín Centurión. Responsable de SQA – Asistente de Verificación Francy Bodeant. Analista – Implementador Guzman Llambías. Arquitecto – Coordinador de Desarrollo – Asist. de Verificación Hugo Cepeda. Analista – Implementador – Diseñador de Interfaz de Usuario. Ignacio Moreira. Analista - Implementador Javier Oliva. Analista – Documentador de Interfaz de Usuario – Asist. de Verific. Marcel Fernández. Administrador – Asist. de Verific. – Resp. de la Comunicación. Marcelo Caponi. Especialista Técnico – Implementador – Asistente de Arquitecto. Martín Boero. Responsable de Verificación – Asistente de SQA Pablo Zamudio. Especialista Técnico – Implementador – Responsable de SCM. Sebastian Martínez. Especialista Técnico – Implementador.

3 Contexto El cliente posee un conjunto de aplicaciones corriendo en un servidor web en el contexto Link-All. Sus aplicaciones proveen funcionalidades, que serán consumidas por los usuarios. Es necesario un HelpDesk en donde los usuarios puedan reportar errores, al consumir dichas funcionalidades.

4 Requerimientos

5 Objetivos de la herramienta
Proveer mecanismos para que los usuarios del Link-All puedan reportar incidentes. Especialistas técnicos puedan atender y solucionar dichos incidentes, e ingresar datos en la base de conocimiento. Administradores puedan configurar el sistema, gestionar y supervisar el estado de los incidentes reportados. Todos los usuarios pueden consultar una base de conocimientos, con información de problemas ya resueltos.

6 Requerimientos Básicos
A Gestión de Incidentes Reportados Manejo de una Base de Conocimientos Administración de Notificaciones (Alertas) Gestión de Workflow API de ayuda online a los usuarios Extensible Fácil de utilizar e instalar Necesidad de un Sistema Configurable Comunicación vía entre los usuarios Uso de la plataforma Link-All, para el manejo de seguridad del sistema Reportes Gráficos Comunicación entre los usuarios por medio de un chat A A A A A A A A A

7 Herramientas y tecnologías utilizadas
J2EE Eclipse 3.1 Con plugins Web Tool Project (WTP) para J2EE JBPM Designer JBoss JBPM Struts Plataforma LinkAll JavaScript PostgreSQL JDOM JavaMail - J2EE o Pues la aplicación debía ser una aplicación que siguiera dicho standard - Eclipse o Como IDE para el desarrollo - WTP, entorno integrado de desarrollo para generacion de aplicaciones J2EE. - JBPM Designer, que permite - JBoss o Servidor de aplicaciones sobre el que debía correr la aplicación - JBPM o Motor de Workflow utilizado para la implementación de el proceso configurable. - Struts o Framework de presentación utilizado para realizar la presentación del sistema. - Plataforma LinkAll o Plataforma sobre para la que el sistema fue construido, con la que debe interactuar y sobre la que corre. - WTP (Web Tool Project) o Plugin para eclipse que brinda funcionalidades para la implementación de aplicaciones J2EE - JavaScript o Utilizado en la presentación del sistema, para brindar funcionalidades útiles y permitir mayor navegabilidad. - PostgreSQL o Manejador de Base de Datos Relacional utilizado para la persistencia de los datos manejados por el sistema. JDOM Para la lectura de xml JavaMail Para el envió de correo electrónico a usuarios del sistema.

8 Soporte de internacionalización:
Interfaz Gráfica Proveer soporte para navegadores: Internet Explorer Mozilla FireFox Soporte de internacionalización: Ingles Español Extensible: Utilización de librerías de tags Standard Utilización de hojas de estilos

9 Arquitectura

10 Arquitectura orientada a Servicios. SOA Base de conocimiento
Características Arquitectura orientada a Servicios. SOA Base de conocimiento Comunicarse con el Link-All Usar Componente de acceso a datos del Link-All Motor de workflow - JBPM Alto grado de configurabilidad Características de la arquitectura a diseñar: Dados los requerimientos presentados anteriormente y el proceso de desarrollo a seguir, nuestra arquitectura debe poseer las siguientes características: - Debe ser una arquitectura orientada a servicios - Debe comunicarse con la plataforma Link-All, para proveer la seguridad y ayuda de nuestro sistema. - Se debe utilizar el mismo componente encargado del acceso a datos del Link-All - Debe poseer un motor de workflow para la gestión del proceso de resolución de incidentes. - El sistema a diseñar debe poseer un alto grado de configuración, tanto en tiempo de ejecución como en tiempo de desarrollo.

11 Casos de Uso Relevantes
Reportar Incidentes Registrar Eventos Disparar alerta de entrada y salida dentro de una tarea (solo mediante el envío de mail) Buscar datos en la base de conocimiento Ver incidente

12 Contexto SOA Conceptos claves Application Front End Servicios
Inician y controlan las actividades. Servicios Componente con un significado que encapsula un concepto de alto nivel del Negocio Repositorio de Servicios Provee facilidades para descubrir servicios y obtener la info. para usarlos Bus de Servicios Es el encargado de conectar a todos los participantes de una SOA. Como dijimos, nuestra arquitectura esta orientada a Servicios, por lo que nuestro N

13 Servicios Intermediarios
Arquitectura Presentación Application Front End Diálogo/Intermedia Servicios Intermediarios Application Back End Servicios Básicos Nuestra arquitectura esta compuesta por varias capas. En ellas encontramos la capa de presentación, en donde se encuentra la interfaz gráfica de nuestro sistema. Una capa de Diálogo o Intermedia que permite desacoplar la presentación del negocio. Presentación invoca unicamente a una operación de esta capa, la cual conoce, a partir de los datos que recibidos, quien resuelve esa logica particular. De esta forma presentación siempre resuelve las llamadas a la capa de dialogo de la misma forma y se resuelven tambien de forma ya preestablecida. Presentación resuelve distintas problematicas, pero siempre invocando una única operación de la capa de dialogo. La capa de dialogo conoce que es lo que quiere hacer presentación a partir de los datos que esta le suministra. Estas dos capas componen el Front End de nuestra aplicación. A continuación encontramos dos capas de Negocio: una contiene los Servicios Básicos del Sistema y la otra los Servicios Intermedios del helpDesk. Finalmente, encontramos la capa de persistencia de los datos, que en nuestro caso resulto ser una base de datos Postgres. Persistencia

14 Arquitectura Presentación Application Front End Diálogo/Intermedia
Serv. Int. Serv. Int. Application Back End Serv. Bás. Serv. Bás. Uno de los requerimietos es que exista una BC para guardar el detalle de todos los incidentes resueltos. Es por ello, que una de las decisiones de diseño fue separar las capas de Servicios Intermedios y Basicos en dos. Una para la base de conocimiento y otra para el HelpDesk. Esto permite tener una base de conocimiento totalmente independiente del HelpDesk. Sin embargo dicha base de conocimiento tambien es vista como una aplicación Link-All, por lo que debera tener los requerimientos de Seguridad que posee el HelpDesk. Siempre y cuando el HelpDesk quiera utilizar una funcionalidad de la BC, este, debera comunicatse con la Base de conocimiento para realizarlo. No se llamará directamente a la base desde la capa de Dialogo. HD BC Base de conocimiento HelpDesk

15 Principales Servicios

16 Principales Servicios
Presentación Application Front End Diálogo/Intermedia Gestión Seguridad Gestión Alertas Gestión Incidentes Gestión BPM Gestión de la Base de Conocimiento Application Back End Solo se comentaran los servicios mas relevantes del sistema, ya que el tiempo no es mucho. Dentro de estos, se encuentra la Gestion de Incidentes. Este servicio se encarga de encapsular y proveer todas las funcionalidades, que involucran un incidente. Reportar un incidente y registrar un evento son las funcionalidades mas importantes de este servicio. La gestion de alertas, como su nombre lo indica es la encargada de administrar las alertas del sistema. Una alerta es un mensaje en la pantalla de un usuario o simplemente el envio de un mail. Dentro de las funcionalidades mas importantes de este servicio se encuentran: dispararAlerta, listarAlerta La gestion de seguridad es quizas uno de los servicios mas importantes del sistema. Este servicio provee las funcionalidades para birndar los mecanismos de seguridad que debe poseer nuestra aplicación. La funcionalidad mas importante de este servicio es el que permite validar el uso de una funcionalidad cualquiera por parte de un usuario. Además, es el punto de conexión entre el Helpdesk y el Link-All. La Gestion de la BC, es el servicio mas importante de la base de conocimiento. Provee las funcionalidades para la administracion de la base, como ser Ingresar o buscar un item de conocimiento. GestionBPM. La gestion BPM, es sin dudas el servicio mas importante de nuestra aplicación y a su vez el que puede ser mas reemplazable. Este servicio es el encargado de la administracion del proceso de resolucion de un incidente. Algo importante a destacar, es que no conoce el negocio, como asi lo demuestran sus funcionalidades, que son propias de la gestion de un proceso, como ser Crear un proceso, ejecutar una tarea dada del proceso o slistar las tareas pendientes de un usuario o proceso. Existe el servicio broker cuyas funcionalidades permiten comunicar a la gestionBPM, sin necesidad de conocer que esta haciendo osea sin conocer el negocio. El Broker, es el encargado de conocer el negocio. Esto permite que este servicio pueda ser reemplazado mas adelante por otro mas conveniente, mientras provea los contratos de la GestionBPM y se comunique con el Broker para realizar las tareas relacionadas al negocio. HD BC Base de conocimiento HelpDesk Link-All

17 Principales Servicios
Presentación Aplication Front End Diálogo/Intermedia ServiceFacade OrquestadorBC Aplication Back End HD BC Base de conocimiento HelpDesk Link-All

18 ¿A qué llegamos...?

19 usuario técnico admin APPLICACIÓN FrontOffice FUCIONALIDAD Noticias
TIPO Error DESCRIPCIÓN Error al buscar noticias del Año 2004. usuario técnico admin

20 usuario técnico admin APPLICACIÓN FrontOffice FUCIONALIDAD Noticias
TIPO Error DESCRIPCIÓN Error al buscar noticias del Año 2004. usuario técnico admin

21 Evaluación del Producto
Se presenta Martín y luego yo. Junto con Martín vamos a hablar de la Evalución del Producto.

22 Fortalezas y debilidades
Configurabilidad Proceso. Variables de proceso. Guardas. Alertas. Fácil de extender Implementacion nuestra de “framework” para comunicación entre capas de Presentacion y Dialogo. Manejo de Excepciones Presentación no captura excepciones de negocio. Recibe una lista de errores. Interfaz amigable Debilidades Manejo Transaccional Quedan errores ... Configurabilidad: Tanto .... Se configuran a partir de archivos properties y XML Facil de Extender: LEER !!!!!! -> Aumentó mucho la productividad de los programadores esto. Manejo de excepciones: Consecuencia directa de la implementación del framework anterior, puesto que cuando ocurre un error en negocio, a presentación no le llegan excepciones sino una lista de errores prontos para mostrar en pantalla. Esto es porque pusimos incapié en que presentación no conozca el Negocio. Interfaz amigable: Consideramos tener una interfaz amigable. Manejo Transaccional: No quedó del todo cerrado, debido escencialmente a la poca experiencia en J2EE. Quedan errores: De esto va a hablar mejor que yo Martín.

23 Mejoras y extensiones posibles
Exportar servicios del sistema como Web Services. Orquestación de servicios mediante el uso de BPEL. Interfaz grafica para la configuración del Sistema. Extensiones Generacion de Reportes. Chat. Mas Idiomas (bajo costo). Aumentaría mucho la Interoperabilidad de nuestro sistema. Esto sería: cambiar el mencanismo de orquestación de Servicios. Hoy la Orquestación está hecha en código y es costoso cambiarla, sin embargo si usaramos BPEL, podríamos definir la orquestación de servicios a partir de archivos XML, lo que haría mas mantenible nuestro sistema. Las 2 Primeras, como ya mencionó Javier quedaron fuera del Alcance. Y agregarle mas idiomas es interesante puesto que sería algo de muy Bajo costo puesto que sería agregar un archivo properties.

24 Limitaciones Desconocidas por no haberse evaluado.
No hicimos testeo de stess, de performance, y ese tipo de testeo, como para poder hablar con propiedad. Bueno los dejo con Martín que les va a hablar de los errores.

25 Errores conocidos, corregidos y remanentes, cuantificados por prioridad
Errores con prioridad baja Corregidos: 50 % Remanentes: 50 % Errores con prioridad media Corregidos: 68,4 % Remanentes: 31,6 % Errores con prioridad alta Corregidos: 48,3 % Remanentes: 51,7 % Errores totales Corregidos: 55,8 % Remanentes: 44,2 % Baja Media Alta Total Conocidos 4 19 29 52 Corregidos 2 13 14 Remanentes 6 15 23

26 FIN Preguntas ???