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

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

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

Objetivos principales 1.Aprobar el proyecto con 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.

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 Preguntas

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

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

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

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 El problema se repite cada vez que la red de ventas concreta un nuevo negocio B2B

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.

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

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

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

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

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

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

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

Requerimientos

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

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

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: $250 Cuenta 2: $500 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

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

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

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

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.

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

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

Seguimiento de pruebas

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

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

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

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

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

Ciclo de vida

Avance Se realizó el 82% de lo planificado

Productividad Valor de referencia: Productividad = 1

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

Avance Riesgos

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

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.

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

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.

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