Coordinador de transacciones electrónicas en línea entre empresas María Emilia Blanco - Gerente...

Proyecto OmbúCoordinador de transacciones

electrónicas en líneaentre empresas

María Emilia Blanco - GerenteMónica Hernando - SQA

Pablo Venturino - Arquitecto y SCMGabriel Kouyoumdjian - IR

Tutor: Rafael Bentancur

AgendaObjetivos principalesEl cliente, su problema, nuestra soluciónEl productoDemoMetodología de trabajoConclusionesLecciones aprendidasPreguntas

AgendaObjetivos principales El cliente, su problema, nuestra soluciónEl productoDemoMetodología de trabajoConclusionesLecciones aprendidasPreguntas

Objetivos principales1. 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.

Cliente

Cliente Gabriel Ledesma:

Egresado y Docente de la Universidad ORT15 de experiencia en desarrollo de sistemas empresarialesFue Jefe de Desarrollo de Abitab S.A. y Director del

proyecto "Abitab Online" basado en JEEActualmente:

Gerente de TI en MEVIR Presidente de AQuaIT

Problema

ProblemaNecesidades de la implementación B2B:

Coordinar mecanismos de comunicación Garantizar consistencia de las transacciones distribuidasMinimizar tiempos de puesta en producción

ProblemaDificultades:

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

ProblemaDificultades:

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

ProblemaSe 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

Análisis del estado del arteObjetivo:

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:BTPebXMLBPELWS-Coordination y WS-Atomic Transaction Apache Kandula

Análisis del estado del arteProtocolos seleccionados: WS-Coordination y WS-Atomic

TransactionVentajas:

Soporte de OASIS (Microsoft, IBM, Oracle, entre otros) Basada en SOAP WebServices

Desventajas: No soporta REST WebServices

Solución

SoluciónNuestro producto:

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

SoluciónDefiniciones:

Actividad: unidad de computación distribuida que involucra varios participantes

Participante: entidad que participa en la actividadIniciador: participante que inicia una actividadCoordinador: entidad encargada de coordinar los

participantes

SoluciónWS-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ónWS-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

Requerimientos

RequerimientosRequerimientos funcionales

• Crear contexto (WS-Coor)• Registrar participante (WS-Coor)• Registrar evento (WS-Coor)• Confirmar actividad (WS-AT)• Confirmar operación (WS-AT)• Abortar actividad (WS-AT)• Abortar operación (WS-AT) • Guardar log

Requerimientos no funcionales

• Java, open source• Seguridad• Escalabilidad• Extensibilidad• Disponibilidad• Performance

Arquitectura

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 negocio

Mensajes de negocio

Mensajes de coordinación

Mensajes de coordinaciónMensajes de

coordinación

DemoLaptops

Laptop 1 representa el iniciador: terminal de ventasLaptop 2 representa el coordinadorLaptop 3 representa un Teatro con sus 6 asientos libres color VERDELaptop 4 representa un Banco con 2 cuentas cuyos saldos iniciales son:

Cuenta 1: $150 Cuenta 2: $300

Colores de asiento en el teatro: Verde: libreAmarillo: pre reservadoRojo: ocupado

Costo de la entrada: $100Importante: hay un retardo en la ejecución para mayor entendimiento

JBoss AS 5.1 Servidor banco

Servidor red de ventas Servidor teatro

coordinator.earcoordinatorWS.jar

coordinatorEJB.jar

participant.jar

Banco.jar

DBcoordinación

Teatro.jar

DBcoordinación

participant.jarparticipant.jar

RedDeVentas.jar

DBcoordinación

Web ServiceTeatro

Web ServicesCoordinator

Base de datos Web Service Banco

Atributos de calidadLa seguridad es reducida

se utiliza claves de seguridadEscalabilidad

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 usono podemos garantizar disponibilidad 24/7: esto depende de los sistemas

participantesPerformance

no se realizaron pruebas de performancese consideró la performance en el diseño

Pruebas

Tipos de PruebaPruebas unitariasPruebas de transición de estadosPruebas exploratoriasPruebas de sistemaPruebas de regresiónPruebas de aceptaciónLos requisitos no funcionales fueron considerados en la

solución arquitectónica pero no se probaron.

Automatización de pruebasParticipante

JUnit dentro del entorno de Eclipse

CoordinadorSe crea proyecto web que ejecuta pruebas JUnit a través de

un Servlet

Seguimiento de pruebasLuego de la entrega se siguió realizando testingSe pasó de 93 casos de prueba a 190Se siguieron registrando ticketsSe cerraron 36 ticktes y quedaron 8 sin cerrarErrores “graves”: CERO

Seguimiento de pruebas

7%

3%

4%

86%

Casos de prueba

No implementadaFuncionalidad no im-plementadaFallanCorrectas

11 12 13 14 15 16 17 1802468

101214

LeveMedioGrave

Iteración

Canti

dad

Tick

ets

11 12 13 14 15 16 17 180

5

10

15

20

CreadosCerradosPendientes

Iteración

Canti

dad

Tick

ets

Calidad

Gestión de la CalidadGarantía

Estableciendo marco de trabajo de procedimientos y estándares

PlanificaciónSeleccionando 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 calidadObjetivos de calidad enfocados a cumplir con los

objetivos del proyecto.Objetivos de calidad:

Enfoque preventivoAdquirir conocimientos de cómo gestionar la calidad en un

proyectoCorrección del 100% de los errores gravesGenerar casos de pruebas que cubran el 100% de los

requisitos funcionales y no funcionales

Métricas de calidadMétricas del proceso

1 2 3 4 50

100200300400500600700800

Horas de re-trabajo Horas de prevención Horas de evaluación

Revisiones/ Entrega

Hor

as

8%

31%

19%

53%

18%

12%

12%

5%

Esfuerzo por área

Procesos de IS

Gestión

Sobrecosto Académico

Calidad

SCM

44%

21%

12%

12%

10% 3%

Horas Procesos de IS

Desarrollo

Testing

Arquitectura

Investigación

Requerimientos

Diseño

RepositorioAlmacenado en Google Code

Proyecto Ombú

Para los documentosCarpeta docs_na: Documentos no aprobadosCarpeta docs: Documentos aprobados

Para los fuentesCarpeta /trunk: Rama principal de desarrollo

Gerencia

AlcanceProtocoloDocumento con explicación protocoloAplicación coordinadoraLibrería participanteManual técnico administradoresManual técnico desarrolladores

Ciclo de vida

AvanceSe realizó el 82% de lo planificado

ProductividadValor de referencia: Productividad = 1

19-Ju

n24

-Jun

29-Ju

n4-

Jul

9-Ju

l14

-Jul

19-Ju

l24

-Jul

29-Ju

l3-

Aug

8-Au

g13

-Aug

18-A

ug23

-Aug

28-A

ug2-

Sep

7-Se

p12

-Sep

17-S

ep22

-Sep

27-S

ep2-

Oct

7-O

ct12

-Oct

17-O

ct22

-Oct

27-O

ct1-

Nov

6-No

v11

-Nov

16-N

ov21

-Nov

26-N

ov1-

Dec

6-De

c11

-Dec

16-D

ec21

-Dec

26-D

ec31

-Dec

5-Ja

n10

-Jan

15-Ja

n20

-Jan

25-Ja

n30

-Jan

4-Fe

b9-

Feb

14-F

eb19

-Feb

00.5

11.5

22.5

33.5

44.5

Productividad

Semana

Prod

uctiv

idad

2 3 4 5 6 7 8 9 10 11 12 13 140

50

100

150

200

250

Total horas

Iteración

Canti

dad

de h

oras

2 3 4 5 6 7 8 9 10 11 12 13 140

102030405060708090

100

% Completitud

Iteración

Porc

enta

je

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

junio julio agosto 2 3 4 5 6 7 9 10 14 150

1

2

3

4

5

No terminar el proyecto Poca experiencia en la tecnologíaPoca disponibilidad horaria No se complete una iteración

Mes/Iteración

Mag

nitu

d

Avance Riesgos

ConclusionesLogros

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

¿Preguntas?

Coordinador de transacciones electrónicas en línea entre empresas María Emilia Blanco - Gerente...

Documents

Transcript of Coordinador de transacciones electrónicas en línea entre empresas María Emilia Blanco - Gerente...