Proyecto Ombú

2. Proyecto Ombú 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 • El cliente, su problema, nuestra solución • El producto • Demo • Metodología de trabajo • Conclusiones • Lecciones aprendidas • Preguntas

5. Objetivos principales • Aprobar el proyecto con 100. • Superar las expectativas del cliente.  • Con el producto se pueda lograr una mejora entre las transacciones B2B. • Entregar un producto con cero defectos “graves”. • 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 producto • Demo • Metodología de trabajo • Conclusiones • Lecciones aprendidas • Preguntas

7. Cliente

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

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. Análisis del Estado del Arte

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. Solución

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

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

25. Requerimientos

26. Requerimientos

27. Arquitectura

28. Sistemas participantes Mensajes de negocio Mensajes de negocio Mensajes de coordinación Mensajes de coordinación Mensajes de coordinación Mensajes de negocio

29. Agenda • Objetivos principales • El cliente, su problema, nuestra solución • El producto • 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. coordinator.ear participant.jar coordinatorWS.jar Banco.jar coordinatorEJB.jar DB coordinación Base de datos participant.jar participant.jar DB coordinación Teatro.jar DB coordinación RedDeVentas.jar

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 • Conclusiones • Lecciones aprendidas • Preguntas

34. Pruebas

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

40. Calidad

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 19% 31% 8%

45. SCM

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

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