Coordinador de transacciones electrónicas en línea entre empresas María Emilia Blanco - Gerente Mónica Hernando - SQA Pablo Venturino - Arquitecto y SCM.

Presentación del tema: "Coordinador de transacciones electrónicas en línea entre empresas María Emilia Blanco - Gerente Mónica Hernando - SQA Pablo Venturino - Arquitecto y SCM."— Transcripción de la presentación:

1

2 Coordinador de transacciones electrónicas en línea entre empresas María Emilia Blanco - Gerente Mónica Hernando - SQA Pablo Venturino - Arquitecto y SCM Gabriel Kouyoumdjian - IR Tutor: Rafael Bentancur

3 Agenda Objetivos principales El cliente, su problema, nuestra solución El producto Demo Metodología de trabajo Conclusiones Lecciones aprendidas Preguntas

4 Agenda Objetivos principales Objetivos principales El cliente, su problema, nuestra solución El producto Demo Metodología de trabajo Conclusiones Lecciones aprendidas Preguntas

5 Objetivos principales 1.Aprobar el proyecto con 100. 2.Superar las expectativas del cliente. 3.Con el producto se pueda lograr una mejora entre las transacciones B2B. 4.Entregar un producto con cero defectos “graves”. 5.Realizar proyecto con características diferentes a los proyectos que estábamos acostumbrados a realizar en la carrera.

6 Agenda Objetivos principales El cliente, su problema, nuestra solución El cliente, su problema, nuestra solución El producto Demo Metodología de trabajo Conclusiones Lecciones aprendidas Preguntas

7

8 Cliente Gabriel Ledesma: Egresado y Docente de la Universidad ORT 15 de experiencia en desarrollo de sistemas empresariales Fue Jefe de Desarrollo de Abitab S.A. y Director del proyecto "Abitab Online" basado en JEE Actualmente: Gerente de TI en MEVIR Presidente de AQuaIT

9

10

11 Problema Necesidades de la implementación B2B: Coordinar mecanismos de comunicación Garantizar consistencia de las transacciones distribuidas Minimizar tiempos de puesta en producción

12 Problema Dificultades: Soluciones existentes: Altos costos: en licencias y/o consultorías Capacitación de personal técnico No es económicamente viable para todo tipo de negocio

13 Problema Dificultades: Desarrollo de solución especializada: Acordar mecanismos de comunicación y tecnologías a utilizar. Analizar, negociar, definir protocolo para garantizar consistencia. Desarrollo y prueba de la solución: 1 mes aprox. (1 persona full time + 1 part time). El problema se repite cada vez que la red de ventas concreta un nuevo negocio B2B

14 Problema Se nos plantean los siguientes requisitos: Un protocolo que estandarice la comunicación y coordinación de los sistemas y asegure la consistencia del resultado de las operaciones. Una implementación de este protocolo para agilizar el desarrollo. Inclusión de un sistema de bitácora (o log), que sirva como registro de las operaciones.

15

16 Análisis del estado del arte Objetivo: Encontrar protocolo con las siguientes características: Permita estandarizar comunicación y coordinación de los sistemas Garantice consistencia de las operaciones Principales fuentes analizadas: BTP ebXML BPEL WS-Coordination y WS-Atomic Transaction Apache Kandula

17 Análisis del estado del arte Protocolos seleccionados: WS-Coordination y WS-Atomic Transaction Ventajas: Soporte de OASIS (Microsoft, IBM, Oracle, entre otros) Basada en SOAP WebServices Desventajas: No soporta REST WebServices

18

19 Solución Nuestro producto: Middleware de coordinación de transacciones distribuidas en línea implementando los protocolos WS-Coordination y WS-Atomic Transaction de OASIS

20 Solución Definiciones: Actividad: unidad de computación distribuida que involucra varios participantes Participante: entidad que participa en la actividad Iniciador: participante que inicia una actividad Coordinador: entidad encargada de coordinar los participantes

21 Solución WS-Coordination: Permite crear instancia de coordinación o "contexto" Por si mismo no define todo lo necesario que requiere una solución de coordinación; debe ser usado con otras especificaciones

22 Solución WS-Atomic Transaction: Transacciones atómicas cumplen propiedad "todo o nada" Cuando la aplicación finaliza, la transacción solicita al coordinador el resultado Si todos los participantes respondieron "OK", el coordinador realiza Commit Si alguno de los participantes responde Abort o no responde, el coordinador aborta las operaciones realizadas en la actividad

23

24 Agenda Objetivos principales El cliente, su problema, nuestra solución El producto El producto Demo Metodología de trabajo Conclusiones Lecciones aprendidas Preguntas

25

26 Requerimientos

27

28 Sistemas participantes Servidor de Coordinación Aplicación Cliente (Red de ventas) Aplicación Servidora 1 (Banco) Aplicación servidora 2 (Teatro) Mensajes de negocio Mensajes de coordinación Mensajes de coordinación Mensajes de coordinación

29 Agenda Objetivos principales El cliente, su problema, nuestra solución El producto Demo Demo Metodología de trabajo Conclusiones Lecciones aprendidas Preguntas

30 Demo Laptops Laptop 1 representa el iniciador: terminal de ventas Laptop 2 representa el coordinador Laptop 3 representa un Teatro con sus 6 asientos libres color VERDE Laptop 4 representa un Banco con 2 cuentas cuyos saldos iniciales son: Cuenta 1: $150 Cuenta 2: $300 Colores de asiento en el teatro: Verde: libre Amarillo: pre reservado Rojo: ocupado Costo de la entrada: $100 Importante: hay un retardo en la ejecución para mayor entendimiento

31 JBoss AS 5.1 Servidor banco Servidor red de ventas Servidor teatro coordinator.ear coordinatorWS.jar coordinatorEJB.jar participant.jar Banco.jar DB coordinación Teatro.jar DB coordinación participant.jar RedDeVentas.jar DB coordinación Base de datos

32 Atributos de calidad La seguridad es reducida se utiliza claves de seguridad Escalabilidad se delega este atributo a la funcionalidad de Clustering de JBoss (pendiente) Extensibilidad el diseño contempla el agregado de nuevos tipos de coordinación y protocolos Disponibilidad la performance de la aplicación no se degrada con el tiempo de uso no podemos garantizar disponibilidad 24/7: esto depende de los sistemas participantes Performance no se realizaron pruebas de performance se consideró la performance en el diseño

33 Agenda Objetivos principales El cliente, su problema, nuestra solución El producto Demo Metodología de trabajo Metodología de trabajo Conclusiones Lecciones aprendidas Preguntas

34

35 Tipos de Prueba Pruebas unitarias Pruebas de transición de estados Pruebas exploratorias Pruebas de sistema Pruebas de regresión Pruebas de aceptación Los requisitos no funcionales fueron considerados en la solución arquitectónica pero no se probaron.

36 Automatización de pruebas Participante JUnit dentro del entorno de Eclipse Coordinador Se crea proyecto web que ejecuta pruebas JUnit a través de un Servlet

37 Seguimiento de pruebas Luego de la entrega se siguió realizando testing Se pasó de 93 casos de prueba a 190 Se siguieron registrando tickets Se cerraron 36 ticktes y quedaron 8 sin cerrar Errores “graves”: CERO

38 Seguimiento de pruebas

39

40

41 Gestión de la Calidad Garantía Estableciendo marco de trabajo de procedimientos y estándares Planificación Seleccionando procedimientos y estándares adecuados para el proyecto Control Definiendo y adecuando los procesos para garantizar que los procedimientos y estándares sean aplicados por el equipo

42 Objetivos de calidad Objetivos de calidad enfocados a cumplir con los objetivos del proyecto. Objetivos de calidad: Enfoque preventivo Adquirir conocimientos de cómo gestionar la calidad en un proyecto Corrección del 100% de los errores graves Generar casos de pruebas que cubran el 100% de los requisitos funcionales y no funcionales

43 Métricas de calidad Métricas del proceso 8% 31% 19%

44

45

46 Repositorio Almacenado en Google Code Proyecto Ombú Para los documentos Carpeta docs_na: Documentos no aprobados Carpeta docs: Documentos aprobados Para los fuentes Carpeta /trunk: Rama principal de desarrollo

47

48 Alcance Protocolo Documento con explicación protocolo Aplicación coordinadora Librería participante Manual técnico administradores Manual técnico desarrolladores

49 Ciclo de vida

50 Avance Se realizó el 82% de lo planificado

51 Productividad Valor de referencia: Productividad = 1

52 Horas planificadas por iteración: Iter. 2 a 10: 160 hs Iter. 10 a 14: 200 hs

53 Avance Riesgos

54 Agenda Objetivos principales El cliente, su problema, nuestra solución El producto Demo Metodología de trabajo Conclusiones Conclusiones Lecciones aprendidas Preguntas

55 Conclusiones Logros Se satisficieron las necesidades del cliente. Se considera que se logró una mejora en el proceso de integración entre sistemas distribuidos. Se tiene un producto con ningún defecto grave. Se realizó un proyecto diferente y desafiante.

56 Comentarios del cliente "Tras haber visto la demostración que hizo el grupo de alumnos he podido comprobar que han hecho un muy buen trabajo. El desafío propuesto por AQuA.it no era fácil de comprender y mucho menos de resolver. La solución planteada por este grupo deja en claro que invirtiendo una gran parte del proyecto en pensar, investigar y diseñar, para luego implementar con poco esfuerzo, hará rentable su solución. Utilizaron muy bien la sinergia con productos y tecnología que estaba a su alcance, sin costo extra de licencias y cumpliendo en fecha. Fueron eficientes y eficaces al desarrollar, premisas que deben ser impostadas desde el ámbito académico para que puedan tener éxito profesional en el competitivo mercado laboral. Como emprendedor, opino que es una muy buena solución costo-beneficio que podemos utilizar para seguir construyendo sobre ella.“ Gabriel Ledesma – Presidente AQuA.it

57 Agenda Objetivos principales El cliente, su problema, nuestra solución El producto Demo Metodología de trabajo Conclusiones Lecciones aprendidas Lecciones aprendidas Preguntas

58 Lecciones aprendidas Asegurarse de conocer el dominio del problema antes de trabajar en la solución. Invertir el tiempo necesario. Validar tempranamente los requisitos con el cliente. Hacer uso de los recursos disponibles (por ejemplo expertos en Arquitectura, Requerimientos, Calidad). De ser necesario cambiar procesos y procedimientos ya definidos, adecuándolos a la forma de trabajo de manera de lograr mejores resultados. Mantener un entorno de trabajo unificado. Ser selectivo en la aplicación del conocimiento en todo momento. Es importante la gestión de riesgos ya que nos ayuda a gestionar los riesgos identificados y a estar “alerta” por si surgen riesgos inesperados. Dentro del equipo es fundamental la comunicación, la colaboración y el apoyo mutuo.

59 Agenda Objetivos principales El cliente, su problema, nuestra solución El producto Demo Metodología de trabajo Conclusiones Lecciones aprendidas Preguntas Preguntas

60