Evaluación de Arquitectura

Identificación y explicación de los 3 Concerns

1. Protección de datos: La plataforma debe proporcionar seguridad a los datos sensibles del cliente, como lo son los documentos de identidad, liquidaciones de sueldo, cotizaciones en AFP, etc. Por esto se necesita que se encripten los datos del usuario, que se guarden los documentos de manera segura y que la cuenta este protegida por autentificación 2FA. Este concern impacta la arquitectura porque obliga a definir una capa de seguridad transversal que afecta a múltiples componentes del sistema. Posibles HUs a modificar:

• Carga de documentos personales
• Autentificación 2FA
• Evaluacion de riesgo

2. Plataforma 100% digital: La plataforma debe ser capaz de procesar una solicitud de credito 100% online, es decir desde el ingreso de datos y carga de documentos hasta la firma del contrato. Se deben facilitar todos estos pasos desde la página sin tener que ir presencialmente. Esto impacta la arquitectura porque el flujo completo debe diseñarse como un proceso orquestado y con estado persistente, de modo que el usuario pueda retomar su solicitud si interrumpe el proceso. Además se necesita de un servicio externo para la extracción de datos desde un documento pdf. Posibles HUs a modificar:

• Carga de documentos
• Firma digital
• Ingreso manual de datos al perfil
• Solicitud de préstamo

3. Comunicación entre plataforma y usuario: La plataforma debe garantizar que los eventos críticos de un crédito lleguen correctamente al usuario y queden registrados en el sistema, como avisos de cobranza, confirmación de firma y actualización del historial. Este concern impacta la arquitectura porque estos eventos no pueden perderse ni duplicarse sin consecuencias legales y financieras, lo que obliga a decidir entre comunicación síncrona (más simple pero frágil ante fallos) o asíncrona con garantía de entrega (más robusta pero más compleja). También exige diseñar mecanismos de reintento y consistencia entre servicios para evitar estados incoherentes, como que un crédito esté firmado pero no aparezca en el historial. Posibles HUs a modificar:

• Avisos de cobranza
• Historial de créditos

Análisis de abordamiento de requisitos derivados de los Concerns

• Para cumplir con el concern 1 (Protección de datos) tenemos que hacer 2 modificaciones al sistema. Primero tenemos que encriptar datos, que afecta directamente el login ya que las contraseñas no se encuentran encriptadas en la DB y también afecta al sistema de autentificación que tenemos. La HU de Carga de documentos personales son documentos privados, que pueden tener nombres y datos de los clientes, por lo que deben ser hasheados igual. La evaluación de riesgo no es necesario hashear, ya que si se encuentran hasheados los documentos y las credenciales como por ejemplo el rut, no te da ninguna información sobre el cliente ver solamente una evaluación de riesgo. La Autenticación 2FA no se encuentra implementada, pero hay que tener en cuenta para su arquitectura, respetar la protección de datos.

• Para cumplir con el concern 2 Plataforma (100% digital) Nos falta poder firmar el contrato de forma online, cosa que se puede solucionar ocupando como firma digital el sistema de autentificación ya implementado. También falta que la evaluación de riesgo sea online HU todavía no implementada.

• Para cumplir con el concern 3 ( Comunicación entre plataforma y usuario) tenemos que hacer cambios de arquitectura profundos, tenemos que crear dos nuevas tablas en la DB, necesitamos una tabla que se refiera a procesos realizados por el cliente (entiende un proceso como un crédito pedido) para poder tener en una tabla un registro histórico de créditos pedidos y otra tabla relacionada con la tabla de procesos, que sea el estado del proceso, con campos como fecha estado del proceso etc, para poder tener logs de todo. Para la HU de avisos de cobranza, tenemos que tener en cuenta que para cada aviso por crédito se actualice el estado del crédito, para la HU de historial crediticio también hay que tener en cuenta lo de actualizar los logs.

Identificación de trade-off's

• Concern 1

  • Trade Off: seguridad vs usabilidad y desempeño, ya que al priorizar la Seguridad en el software para evitar vulneraciones se engorrosa el uso de este osea la Usabilidad, además de sacrificar desempeño al agregar tareas de encriptación y desencriptación de datos.
  • Riesgos Asociados: el riesgo de negocio de que la carga de documentos y la evaluación de riesgo sea tan engorroso que los clientes dejen de solicitar el crédito por esto, y el riesgo técnico sería que como nuestro backend es una aplicación de un solo hilo el loop de este se puede bloquear en algoritmos de encriptación y hashing pesados, provocando un congelamiento temporal de este sistema.

• Concern 2

  • Trade Off: usabilidad y simplicidad vs seguridad e inoperabilidad, al volver a usar el componente login/auth para un fin legal, esto para hacer el sistema más fácil y rápido de programar pero sacrifica la seguridad legal.
  • Riesgos Asociados: Alto riesgo de negocio y cumplimiento, donde el código de autenticación que guardamos en la base de datos no puede ser vinculable de forma legal como una “firma”, si el cliente desconoce la deuda el banco no va a poder probar realmente que esa persona firmó.

• Concern 3

  • Trade Off: consistencia de datos y simplicidad vs modificabilidad.
  • Riesgos Asociados: al guardar todo el historial de créditos, avisos de cobranza y demás en la misma base de datos donde estan las imagenes y documentos de los usuarios se agrava el punto único de falla, donde si la base de datos se satura o cae por una consulta pesada al historial, también se cae las simulaciones, el login y la carga de documentos.

Iteración de HU's

HU: Carga de documentos personales.

• Decisión: Mantener.
• Rationale: Si bien el análisis del Concern 1 (Protección de datos) identifica que los documentos deberían encriptarse antes de almacenarse, esta mejora representa un requisito técnico a abordar en una iteración futura. La HU cumple con su funcionalidad base definida originalmente y no presenta defectos críticos en las pruebas del Hito 3 que obliguen a reformularla. La encriptación de los datos personales se registra como una implementación pendiente, pero no crítica por ahora.

HU: Firma Digital.

• Decisión: Mantener, con ajuste de parámetros de prueba.
• Rationale: Esta HU es clave para el Concern 2 (Plataforma 100% digital), ya que permite completar el flujo de solicitud de crédito sin presencia física. Si bien se ajustaron algunos parámetros para los tests, la HU se mantiene sin cambios funcionales. Se reconoce como trade-off que el uso de un PIN de 6 dígitos como mecanismo de firma presenta riesgo legal (no es equivalente a una Firma Electrónica Avanzada). Este riesgo queda registrado para una iteración futura pero se utiliza como una forma válida hasta el momento. No se registran cambios.

HU: Avisos de cobranza.

• Decisión: Mantener, sin prioridad inmediata.
• Rationale: Esta HU responde al Concern 3 (Comunicación entre plataforma y usuario). Si bien es relevante para garantizar que eventos críticos lleguen al usuario y queden registrados, no se considera prioridad en esta iteración dado el estado actual del desarrollo.

HU: Historial de créditos.

• Decisión: Mantener.
• Rationale: Esta HU también responde al Concern 3. Actualmente registra simulaciones ejecutadas correctamente en el perfil del usuario, cumpliendo su funcionalidad base, falta trabajar la solicitud. Para soportar los requisitos derivados del concern se requerirán nuevas tablas en la BD, lo que se planifica como trabajo futuro sin afectar la HU en su forma actual.

Sobre modificaciones del repositorio.

• El presente hito no implicó modificaciones al código, dado que el foco de este mismo fue el ánalisis estructural del repositorio. El trabajo de desarrollo, discusión, redacción y posterior revisión se llevó a cabo en un plazo de una semana por parte del equipo.