Resumen del Pedido
Fecha Pedido | 28/04/2021 | ||||||||
---|---|---|---|---|---|---|---|---|---|
Fecha Documento | 28/04/2021 | ||||||||
Estado del Documento |
| ||||||||
Autor | Orlando Ojeda | ||||||||
Version | 1.0 | ||||||||
Descripcion | Mejoras para Disponibilizar informacion de TC y como cuenta origen Poder configurar y cobrar un porcentaje de Comision por las Transferencias de TP Dimo hacia las Billeteras Registro de Actividades en el Registro a DIMO + Bloqueo de Funcionalidades + Registro de Incidencias |
Información del Proyecto
Proyecto | Mejoras para Disponibilizar informacion de TC y como cuenta origenRegistro de Actividades en el Registro a DIMO + Bloqueo de Funcionalidades + Registro de Incidencias | ||||||
---|---|---|---|---|---|---|---|
Dueño del Producto | Juan Almada | ||||||
Prioridad |
| ||||||
Administrador del Proyecto | Hugo Diaz | ||||||
Arquitecto | Orlando Ojeda |
Resumen Técnico
Se solicita modificar la forma en la que exponemos los datos de las Tarjetas de Crédito dentro de DIMO, incorporando un proceso de "vinculacion" de tarjetas habilitadas.
La idea es replicar un concepto similar a las preguntas de seguridad de las cooperativas, pero haciendo preguntas relacionadas a la tarjeta que el usuario desea habiltar dentro de DIMO.
Definiciones Principales:
- Ofuscar los datos de todas las tarjetas de Crédito del Usuario que se muestran en DIMO que no hayan sido vinculadas
- Esta definicion se aplica para TODOS los usuarios en DIMO, incluyendo a los usuarios provinientes de MiCabal quienes dejarán de tener una consideracion especial en el sistema, que les permite acceder a la TC sin haber completado su registro.
- La informacion que se muestra en la pantalla principal con el numero de tarjeta, disponible, etc. , se mostrará oculta. Ej: Tarjeta: **** **** **** ****
- Cuando el usuario intente acceder a su tarjeta se le solicitarán preguntas de seguridad relacionadas a la tarjeta seleccionada:
- Ult. 4 digitos de la tarjeta seleccionada (Nuevo) Obs: Para conocer que tarjeta esta seleccionando el usuario y no asumiendola, obligando tambien a que el usuario provea un dato mas de la TC
CVV
PIN
Fecha de vencimiento de plástico.
- Al responder las preguntas de seguridad, en caso de exito, se debe marcar la tarjeta como vinculada.
- La tarjeta de crédito no debe poder ser utilizada para ser origen de ninguna transaccion mientras la misma no se haya vinculada a DIMO.
- Esta definicion aplica para las opciones de Transferencias / Pagos / Compras QR / etc.
Desarrollo:
Luego del relevamiento realizado y tras un analisis rapido, se pudo identificar de que sera necesario de modificar los programas en al menos los siguientes puntos:
PL/SQL- Agregar columa de datos que indique que la tarjeta ya fue vinculada.
- Nuevo procedure con las preguntas de seguridad de la TC
API Ceibo / API Tarjeta Habientes:
- Ofuscar los datos en el caso de que la TC no esta validada
- Si la TC no esta validada al momento de entrar en la misma, derivar al paso de preguntas de Seguridad TC
- Consumir Servicio de Preguntas de Seguridad
- Componente para mostrar las Preguntas de Seguridad de TC y responder
- Enviar respuesta al nuevo servicio de respuestas del Usuario
- Modificacion en las opciones Transaccionales para no mostrar las Tarjetas que no han sido vinculadas a DIMO.
Factibilidad
Soluciones
Evaluadas
¿Aceptada?
(Si/No)
- Modificar DIMO:
- Frontend
- Servicio API Ceibo
- Base de Datos
En DIMO se evaluará si la tarjeta ya se encuentra vinculada y no ser así, los datos se mostrarán ocultos hasta que el usuario pueda vincular individualmente cada una de ellas a traves de preguntas de seguridad.
Para que se pueda crear esa experiencia se deben de modificar ademas del Frontend, la capa de servicio que provee los datos a la aplicacion y la capa de base de datos
El pedido en cuestion se separa en tres grupos principales:
- Registro de Actividades en el Registro a DIMO: Consiste en poder registrar lo intentos de registros a DIMO y que los datos puedan verse a traves de un reporte en el CRM. Este pedido implica cambios en:
- Frontend de DIMO, para enviar los datos que se desean registrar
- Dimo Services, para habilitar un nuevo servicio de registro de actividades
- CRM, para mostrar a traves de una interfaz los diferentes datos de intentos registrados
- Bloqueo de Funcionalidades : Consiste en poder tener la flexibilidad de ocultar ciertas opciones mencionadas en el ticket para que no esten disponibles al usuario. Este pedido implica cambios en:
- Frontend de DIMO, para ocultar/mostrar las funcionalidades.
- Dimo Services, para habilitar un nuevo servicio de consulta de varias funcionalidades a la vez, actualmente solo se puede hacer de uno en uno.
- Registro de Incidencias : Consiste en generar nuevas incidencias cuando el usuario realiza ciertas ciertas actividades especificadas en el ticket del pedido. Este pedido implica cambios en:
- Frontend de DIMO, para disparar las incidencias ante los eventos de las actividades solicitadas.
- Obs: Algunas de estas actividades deberian ser registradas directamente desde el Backend pero esa actividad implicará aun mas tiempo para el relevamiento que por la presion de entregar se opta por esta solucion mas rápida
- Backend de DIMO: ws-dimo
- Modulo de Incidencias, a relevar factibilidad de envio de otros datos no relacionados al registro
- Frontend de DIMO, para disparar las incidencias ante los eventos de las actividades solicitadas.
Factibilidad
Soluciones Evaluadas | Descripción | ¿Aceptada? (Si/No) |
---|---|---|
1. Desarrollo de todos los cambios solicitados |
| - |
2. Desarrollo Solo Bloqueo de Funcionalidades y lo demas en un siguiente entregable |
| - |
2.1 Desarrollo de Registro de Actividades |
|
Impacto sobre Plataformas
Plataformas TI
Soluciones Evaluadas | Plataforma | Descripción |
---|---|---|
Solución 1 |
- Nuevas Tablas
- Codificacion PL / SQL de los nuevos procedimientos almacenados requeridos
Agregar nuevos servicios de:
- Servicio para retornar las preguntas de seguridad
- Servicio para recibir las preguntas de seguridad y retornar el resultado
Servicio DimoServices / Gx |
|
CRM / Gx |
|
Frontend de Dimo |
|
Visión Preliminar de Componentes de Plataformas Afectadas (Alto Nivel)
Diagrama de Proceso de Registro de "Intentos de Registro a DIMO"
CRM - Reporte de Intentos de Registro a DIMO Fallidos
Diagrama de Bloqueo de Funcionalidades
Diagrama de Registro de Incidencias
Presupuestos
Recursos
Área/Función | Cantidad | Tipo de Asignación | Comentarios |
---|---|---|---|
Arquitecto de Proyecto | 1 |
On Demand | - |
Desarrollador Frontend | 1 |
Full | - |
Desarrollador Genexus |
1 |
Full | - | |
Desarrollador JAVA | 1 | Semi |
Full | Para el ws-dimo backend |
Desarrollador CEIBO |
- |
- |
- | |
Analista CEIBO |
- |
- | - | ||
Infraestructura | 2 | On Demand |
|
Tester | 1 | On Demand | Durante las pruebas funcionales de la solucion. |
Solucion 1
Tiempos Estimativos
Nº | Tarea | Tiempo Estimado | Obs |
---|---|---|---|
1 | Analisis (Rápido) | 6 hs | Realizado |
2 | Desarrollo | 54 hs (Gx: 32 hs + Frontend: 16 hs + Backend ws-dimo: 6 hs) | - |
4 | MOPP | 2 hs | - |
5 | Pruebas | 4 hs | - |
Total horas | 66 hs | - | |
Restantes | 60 hs | - |
Solucion 2
Tiempos Estimativos . Entregable 1
Nº | Tarea | Tiempo Estimado | Obs |
---|---|---|---|
1 | Analisis (Rápido) | 3 X hs | Realizado |
2 | Desarrollo | 36 hs13 hs (Gx: 8 hs + Frontend: 5 hs) | - |
4 | MOPP | 1 hs | - |
5 | Pruebas | 2 hs | - |
Total horas | 16 hs | - |
Tiempos Estimativos. Entregable 2
Nº | Tarea | Tiempo Estimado | Obs |
---|---|---|---|
1 | Analisis (Rápido) | X hs | Realizado |
2 | Desarrollo | 41 hs (Gx: 24 hs + Frontend: 11 hs + Backend ws-dimo: 6 hs) | - |
4 | MOPP | 1 hs | - |
5 | Pruebas | 2 hs | - |
Total horas | 44 hs | - |
Observaciones:
Deberá considerarse aparte recursos adicionales de OPERACIONES para apoyo durante la fase de pruebas, en caso de que sea necesario..
Riesgos
Nº | Riesgo | Descripción | Observaciones |
---|---|---|---|
1 | - | - | - |