---
# System prepended metadata

title: Volcado conceptual arquitectura de software y equipo

---

# Volcado conceptual arquitectura de software y equipo

## GDS

Un GDS es un sistema de distribución de datos que permite fundamentalmente transportar estructuras de datos entre organizaciones disjuntas tanto en infraestructura como en organización empresarial.

### ¿Qué datos distribuye nuestro GDS propuesto?

Nuestro GDS distribuye una abstracción del negocio inmobiliario que llamaremos oferta. Una oferta esta compuesta por un activo inmobiliario subyacente (es transable dentro del marco legal de donde se distribuirá dicho activo) sumado a un conjunto de reglas que determinan las posibilidades de ser adquirido y las relaciones contractuales/legales que emanan de adquirir el activo bajo esas condiciones lo que para conveniencia de este documento llamaremos "oferta". El GDS además distribuye el sistema de notificaciones basado en tipo de notificaciones, canales de notificaciones y permisos notificaciones.

### ¿Dónde se distribuyen?

La distribución de la data está dada por un canal, dicho canal abstrae una organización comercializadora con roles a definir donde tentativamente se reconocen los vendedores de primera linea, mandos intermedios de supervisión y gerencia de dicha organización.

### ¿Quién distribuye dichos datos?

El distribuidor de los datos es una organización que tiene la validez legal para poder comercializar las "ofertas", siendo propietario o actuando en nombre de (*).

Sin embargo una linea de negocios a explorar es que ciertas condiciones comerciales a la oferta puedan ser agregadas por nosotros como venta cruzada, tanto en acuerdo con el vendedor como no. (más cuotas en el pie, arriendos garantizados, etc.)

(*) No es necesario demostrar propiedad de nada para promesar un activo inmobiliario, la propiedad se demuestra en el proceso de compraventa, tenemos que decidir si para subir cosas al sistema, sobre todo en usados, es necesario demostrarse propietario.

### ¿Es el GDS un sistema de solo visualización de datos?

Una de las hipótesis de generación de valor que hemos aprendido en el tiempo y que hay que validar en el nuevo arco de desarrollo es que el valor viene dado por la transacción y no solo la visualización. Desde esa perspectiva la transacción (entendiendo la transacción como un proceso basado en estados y no atómico) requiere la definición de dichos estados además de su entrada/salida.

#### Estados tentativos de la transacción

* Oferta Publicada
* Oferta Reservada: La oferta reservada se le agrega un cliente candidato (se entiende candidato ya que no cumple aún los requisitos legales o del vendedor para comprar y debe ser validado)
* Oferta Acordada: La oferta reservada esta disponible a nivel de stock y capacidad de ser vendida y el cliente candidato pasa a ser cliente: desde un KYC simple hasta el origen de fondos, dependiendo la naturaleza del cliente.
* Promesa/Contrato Para ser firmada(o): Esta etapa hace el volcado de los datos del acuerdo al documento legal necesario para realizar la compraventa según la jurisdicción correspondiente
* Escritura/Contrato: Finalización legal de la compraventa según jurisdicción.

### ¿Existen otros datos a distribuir?

El GDS debe distribuir todos los datos necesarios para realizar la transacción de nuestro negocio; no obstante existen datos y herramientas de apoyo a la venta que también deben ser distribuidos como son: Simulador de negocios, Simuladores de créditos, Arriendos esperados, plusvalía, y otros indicadores situados en nuestra comunidad como necesarios para el análisis de la inversión. Dichos datos son responsabilidad del equipo de data el que proveera de manera headless los insumos necesarios para la construcción.

### Si hay otros datos a distribuir, ¿Quién orquesta los datos?

Para los puntos de contacto la orquestación viene dada por un segundo backend hecho que tiene como Rol principal: Conectarse al GDS, Conectarse al sistema de datos, gestionar el cache y la performance, validar la estructura y forma de los datos para poder ser consumida por un punto de contacto.

## Ciclo de vida del Software simplificado

* Análisis Y Diseño
* Implementación
* Pruebas
* Instalación o despliegue
* Explotación y mantenimiento

## Equipo

### Roles dentro del equipo

Los roles dentro del equipo se dividen de la siguiente manera.

#### Desarrollo (Construye)
* Lider técnico: Ingeniero con experiencia en desarrollo de productos y de patrones arquitectonicos y de diseño.
* Ingeniero Backend: Ingeniero con experiencia en diseño de software e implementación.
* Ingeniero Frontend: Ingeniero con experiencia en diseño de software e implementación de lógica en frontend.
* Diseñador Frontend: Con capacidad de construir interfaces dadas en html, css, js, etc.

#### Producto (Especifíca el diseño)

* Product Owner: Lidera la implementación del diseño detallado del producto.
* Diseñador UX: Construye las interacciones dentro del diseño detallado del producto.
* Diseñador UI: Construye la visualización del producto.

#### QA

* Análista QA: Construye plan de pruebas automatizados para pruebas de Humo y ejecuta los planes de prueba y evidencia de funcionamiento.

#### Explotación

* SecDevOps: Seguridad perimetral, infraestructura como código, ahorro y control de costos
* Explotación: Opera el software.

#### Roles faltantes

##### Diseño conceptual (Rol nuevo)
* Convierte la visíon estrátegica en productos o servicios digitales.
* Describe los productos y servicios digitales a nivel de pitch (ver shapeUp, Milestones, Épicas e historias de usuario).

##### Ingeniero de requisitos (Rol Nuevo)
* Describe conceptualmente los requerimientos funcionales y no funcionales.
* Describe los criterios de aceptación.
* Describe los atributos de calidad.


