22
MarketPlace de Los Alpes Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

Embed Size (px)

Citation preview

Page 1: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

1

MarketPlace de Los Alpes

Proyecto 2

Yéssica Forero Navarro Raúl Ernesto Gómez MendozaDiana Carolina Mogollón Ruiz

Luis Fernando TaboadaErnesto Fabián Vargas Madrid

Page 2: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

2

AgendaProceso realización contratos

Planeación actividades Arquitectura Negocio Arquitectura Datos Arquitectura Aplicaciones Arquitectura Solución Web Services utilizados en el proceso Tiempos de implementación experimentados

Proyectos a implementar – Proyecto 3 Descripción proyectos a implementar. Impacto de los proyectos Roles Estimación y cronograma de proyectos Riesgos Plan de comunicaciones Infraestructura de soporte Conclusiones

Page 3: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

3

Proceso contratosPlaneación de actividades

ActividadHoras

planeadasIngeniero

sTotal

Documentación MarketPlace 2 5 10

Inventario de tecnologías y productos 3 1 3

Documentación Productos y tecnologías 20 5 100

Despliegue MarketPlace 4 2 8

Inventario y descripción de aplicaciones, portafolio de servicios, Arquitectura, comunicación. 4 1 4

Análisis proceso de contratación 1 3 3

BPMN Proceso de contratación 2 1 2

Identificación a nivel de negocio de las implicaciones de la inclusión del nuevo proceso 1 2 2

Matriz de actividades 1 1 1

Identificación a nivel de Datos de las implicaciones de la inclusión del nuevo proceso 1 2 2

Realización del modelo canónico 1 1 1

Identificación a nivel de Aplicaciones de las implicaciones de la inclusión del nuevo proceso 1 2 2

Vista funcional 1 1 1

Identificación a nivel de infraestructura de las implicaciones de la inclusión del nuevo proceso 1 2 2

Vista de despliegue 1 1 1

Ajustes CRM OD 3 2 6

Implementación de ContractManager 8 2 16

Despliegue Web Service conectado al OSB 3 2 6

Modificación de Web Services legados 8 3 24

Despliegue Web Services sobre el OSB 3 2 6

BPEL para la orquestación de servicios 8 2 16

Implementación y despliegue de Portlets 8 2 16

232

Page 4: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

4

Negocio

Page 5: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

5

Datos

Actividades:

•Enviar solicitud contrato•Radicar contratos en sistema•Enviar numero radicación•Aceptar/rechazar contrato•Enviar rechazo•Indicar nuevo precio•Enviar aceptación•Enviar mensaje rechazo•Enviar mensaje aceptación•Enviar mensaje confirmar cierre•Enviar mensaje rechazar cierre•Cobrar comisión•Informar establecimiento de contrato

Page 6: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

6

Aplicaciones

• ContractManager

Se creará la aplicación ContractManager para gestionar las operaciones relacionadas con la entidad “contrato”. Esta aplicación prestará entre otros los siguientes servicios:

• Creación y Actualización de contratos.• Consulta de contratos.• Aprobación o Rechazo de contratos.

Page 7: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

7

Solución

Page 8: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

8

Actividad Web Service Operaciones Legado Utilizadas Operaciones Agregadas

Consultar Fabricantes GestionPO ConsultarPOsComercio ConsultarFabricantesPOsConsultar Productos GestionCliente ConsultarProductosCliente Calcular Precio GestionPO CalcularPrecioPromedioRegistrarSolicitud GestionContrato RegistrarSolicitudConsultarSolicitud GestionContrato consultarSolicitudEnviarSolicitudFabricante GestionCorreoElectronico enviarCorreoElectrónico EnviarCorreoComercioRadicacion GestionCorreoElectronico enviarCorreoElectrónico AprobarSolicitud GestionContrato aprobarSolicitudRechazarSolicitud GestionContrato rechazarSolicitud

Web Services utilizados en el proceso de realización de contratos

Page 9: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

9

Actividad Web Service Operaciones Legado Utilizadas

Operaciones Agregadas

EnviarCorreoComercioRechazo GestionCorreoElectronico enviarCorreoElectrónico EnviarCorreoComercioConfirmacion GestionCorreoElectronico enviarCorreoElectrónico ConsultarPorcentaje GestionCliente consultarPorcentajeCobrarComisión GestionCliente modificarComisión EnviarCorreoComercioConfirmación GestionCorreoElectronico enviarCorreoElectrónico EnviarCorreoFabricanteConfirmacion GestionCorreoElectronico enviarCorreoElectrónico EnviarCorreoComercioRechazo GestionCorreoElectronico enviarCorreoElectrónico EnviarCorreoFabricanteRechazo GestionCorreoElectronico enviarCorreoElectrónico

Web Services utilizados en el proceso de realización de contratos

Page 10: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

10

Tiempos de implementación experimentados

Tiempos aproximados medidos en horas/hombre

ArtefactoComplejidad

Baja Media Alta

EJB 5 9 16

Portlet

Servicios de brokering

4,5 (1-3 operaciones)

7 (4-6 operaciones)

12 (mas de 6 operaciones)

Servicios tipo proceso

Page 11: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

11

Descripción proyectos a implementar

• Proyecto Actualización del portal del MarketPlace de los Alpes

Extender los procesos de negocio del MarketPlace (Registrar entidad, PO, DA, PRICAT, RMA, Facturación y preferencias del cliente) con el fin de incorporar MarketPlace internacionales.

• Proyecto Sistema de pagos

Integrar un sistema de pago en línea que permite a sus clientes tener la posibilidad de realizar sus pagos a través del portal del MarketPlace de los Alpes.

Proyecto 3

Page 12: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

12

Impacto de los proyectos

Actualización Portal Sistema de pago

Procesos modificados 4 1

Procesos nuevos - -

Entidades modificadas 12 9

Entidades nuevas 1 1Aplicaciones modificadas 5 2

Servicios reutilizados 4 2

Servicios modificados 10 1

Servicios nuevos 3 operaciones 1

Page 13: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

13

Roles

Rol Descripción

GerenteEs el gerente del proyecto, encargado de la supervisión general. Es un facilitador y hace que el trabajo del equipo fluya.

Ingeniero desarrollador

Todos los roles del equipo deberán cumplir tareas de ingeniero desarrollador. Este rol está encargado de la implementación.

ArquitectoEncargado y responsable de la arquitectura del sistema y la definición de los lineamientos que seguirá el equipo de desarrollo. (Cumple el mismo rol que el ingeniero de diseño y el ingeniero analista).

Ingeniero de pruebas

Encargado y responsable diseño y la ejecución de las pruebas.Mantiene el estándar de calidad en todas las actividades del proyecto. Supervisa y hace cumplir dichos estándares.

Page 14: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

14

Estimación

Estimación de proyectos - horas

ProyectoHoras proyecto

Dedicación sema persona

Cantidadpersonas

DedicaciónTotal sema

Tiemposemanas

Tiempomeses

Sistema Pagos 411,5 14 5 70 5,88 1,47Actualización 732,5 14 5 70 10,46 2,62

4,09

Estimación de ciclos – fechas

Inicio Fin

Ciclo 1 15 – Ago - 2011 19 – Sep - 2011

Ciclo 2 20 – Sep - 2011 25 – Oct - 2011

Ciclo 3 26 – Oct - 2011 30 – Nov - 2011

Page 15: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

15

Cronograma

Page 16: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

16

Cronograma

Page 17: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

17

Riesgos

Proceso

1. Identificación (riesgos de alcance y de tiempo)

2. Evaluación (cualitativa basada en criterios de probabilidad e impacto)

3. Priorización (de acuerdo a valoración de criticidad – Top Ten)

4. Planes de mitigación y prevención (para los Top Ten)

Page 18: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

18

Riesgos - PriorizaciónAmenaza Probabilidad

Impacto sobre:Criticidad

Alcance Tiempo Costo

La base de datos diseñada en el sistema fue modificada, requiriendo más recursos y causando retrasos.

4 2 4 4 40

Todos los componentes pasaron las pruebas del sistema de manera individual, pero al ser integrados el sistema falló.

4 2 4 4 40

El desarrollo de software fue subestimado. 4 1 4 4 36

Los ingenieros de desarrollo experimentaron una larga curva de aprendizaje.

4 1 4 4 36

Los partners se habían retrasado  con el trabajo prometido, y aun así  sus entregables no funcionaron como se esperaba.

4 1 4 4 36

Un sistema complejo fue diseñado por piezas/partes. Cuando la integración falla, se requiere hacer rediseño.

3 4 4 3 33

Los módulos de software en el sistema no trabajan juntos como estaba previsto.

3 3 4 3 30

Las decisiones se retrasaron sin razón aparente. 4 1 3 3 28

El desarrollo programado en paralelo llevó frecuentemente a re trabajo.

4 1 3 3 28

El equipo de desarrollo malinterpreto una serie de requerimientos. 2 5 5 4 28

Page 19: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

19

Riesgos – Plan de ManejoAmenaza

Plan de respuestaOpción de manejo Descripción

La base de datos diseñada en el sistema fue modificada, requiriendo más recursos y causando retrasos.

Evitar

Toda intención de cambio debe pasar por un proceso de control de cambios, que va desde la solicitud del cambio, hasta su aprobación/reprobación

Todos los componentes pasaron las pruebas del sistema de manera individual, pero al ser integrados el sistema falló.

MitigarAgregar un paquete de trabajo en la EDT que contemple pruebas de integración

El desarrollo de software fue subestimado. MitigarConstruir una EDT lo más detallada posible previamente al proceso de estimación

Los ingenieros de desarrollo experimentaron una larga curva de aprendizaje.

MitigarPlanear actividades de capacitación explicitas en la EDT con respecto a las tecnologías a usar.

Los partners se habían retrasado  con el trabajo prometido, y aun así  sus entregables no funcionaron como se esperaba.

MitigarDefinir alternativas que permitan suplir el trabajo esperado por los partners.

Un sistema complejo fue diseñado por piezas/partes. Cuando la integración falla, se requiere hacer rediseño.

Mitigar

Durante la fase de diseño agregar requerimientos de integración.Planear actividades de integración en fases tempranas del desarrollo de los componentes que permitan ir válidado su funcionamiento en conjunto.

Los módulos de software en el sistema no trabajan juntos como estaba previsto.

MitigarProgramación de actividades de integración y pruebas cada vez que se termina un modulo.

Las decisiones se retrasaron sin razón aparente. MitigarEstablecer reuniones con una perodicidad fija en las que se revise el estado del proyecto, y por cada aspecto a resolver se documente una decisión.

El desarrollo programado en paralelo llevó frecuentemente a re trabajo.

MitigarEstablecer mecanismos de comunicación entre las personas que estan realizando trabajos relacionados

El equipo de desarrollo malinterpreto una serie de requerimientos.

MitigarPlanear y realizar reuniones de validación del entendimiento de los requerimientos.

Page 20: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

20

Plan de comunicacionesDestinatario

Frecuencia comunicación

Información a comunicarMétodo de comunicación

Medio de comunicación

Junta directiva del MarketPlace

Al finalizar cada ciclo

Formato: FormalIdioma: EspañolInformación: Relacionada con el avance del proyecto y su impacto sobre el negocio.

Comunicación interactiva

Reuniones

Comunicación tipo push

Informes, correos electrónicos

Vicepresidentes departamentales y jefes del MarketPlace

Al finalizar cada ciclo

Formato: FormalIdioma: EspañolInformación: Relacionada con el avance del proyecto a nivel de negocio y funcionalidad.

Comunicación interactiva

Reuniones

Comunicación tipo push

Informes, correos electrónicos

ClientesAl final del proyecto

Formato: FormalIdioma: Español/InglesInformación: Relacionada con el objetivo del proyecto y su impacto en el flujo de las transacciones actuales del MPLA.

Comunicación tipo push

Informes

BancosAl final del proyecto

Formato: FormalIdioma: Español/InglesInformación: Relacionada con el objetivo del proyecto y su impacto en las transacciones monetarias del MPLA.

Comunicación tipo push

Informes

Líderes de Desarrollo

Semanalmente

Formato: InformalIdioma: EspañolInformación: Relacionada con el avance del proyecto a nivel técnico, dificultades, mejoras y en general todo lo relacionado a las actividades de implementación.

Comunicación interactiva

Reuniones, llamadas telefónicas o conferencias

Comunicación tipo pull

RepositorioWiki

Comunicación tipo push

Correos electrónicos

Page 21: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

21

Infraestructura de soporte

HerramientaImplementació

n Propósito-Uso

Wiki DokuWikiReportes de avance de las actividades asignadas de los integrantes del equipo

Comunicación-Llamadas Skype Realización de reuniones virtuales

Comunicación-Mensajeríainstantánea

GtalkAlternativa a skype en caso de que no se posible usar skype para las reuniones virtuales

IDEEclipse, Jdeveloper

Como entorno de desarrollo se usará Eclipse de Jdeveloper de acuerdo a la pertinencia de cada para el uso especifico

Control de versiones SVNControl de versiones, tanto para fuentes como de la documentación del proceso

Gestión de errores Assembla-TrackReporte y seguimiento de errores en las actividades de pruebas y corrección

Ofimática Microsoft OfficeDocumentación en general (Informes, Planeación, Estándares, Plantillas)

Page 22: Proyecto 2 Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando Taboada Ernesto Fabián Vargas Madrid 1

22

Conclusiones

• Cuando se tiene una representación lo más cercana a la realidad de lo que se encuentra construido en un sistema legado, es muchos más fácil planear y establecer los pasos a seguir.

• Contar con conocimiento y experiencia en las herramientas sobre las que se encuentra un sistema construido es crítico para poder llevar a buen término cualquier proyecto.

• El proyecto de redefinición e implementación de la arquitectura empresarial del MarketPlace de Los Alpes está expuesto a riesgos de alcance tanto administrativos como técnicos.

• Las arquitecturas empresariales nos permitieron entender el AS-IS del MarketPlace de Los Alpes y descubrir el camino para llegar al TO-BE.