coordinador de transacciones electrónicas en línea entre empresas maría emilia blanco - gerente...
TRANSCRIPT
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.
AgendaObjetivos principalesEl cliente, su problema, nuestra soluciónEl productoDemoMetodología de trabajoConclusionesLecciones aprendidasPreguntas
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
AgendaObjetivos principalesEl cliente, su problema, nuestra soluciónEl productoDemoMetodología de trabajoConclusionesLecciones aprendidasPreguntas
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
AgendaObjetivos principalesEl cliente, su problema, nuestra soluciónEl productoDemoMetodología de trabajoConclusionesLecciones aprendidasPreguntas
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
AgendaObjetivos principalesEl cliente, su problema, nuestra soluciónEl productoDemoMetodología de trabajoConclusionesLecciones aprendidasPreguntas
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
SCM
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
AgendaObjetivos principalesEl cliente, su problema, nuestra soluciónEl productoDemoMetodología de trabajoConclusionesLecciones aprendidasPreguntas
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
AgendaObjetivos principalesEl cliente, su problema, nuestra soluciónEl productoDemoMetodología de trabajoConclusionesLecciones aprendidasPreguntas
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.
AgendaObjetivos principalesEl cliente, su problema, nuestra soluciónEl productoDemoMetodología de trabajoConclusionesLecciones aprendidasPreguntas
¿Preguntas?