El análisis de negocio se basa en el caso propuesto de un evento tecnológico acerca de la IA y cómo influye en la productividad del desarrollo de software llamado "IA para la Alta Productividad en Software".
Se discute y desarrolla el análisis basado en una metodología Top-Down que nos ayuda a visualizar desde un principio y de manera general la problemática a resolver antes de desarrollar cualquier solución.
Para construir un sistema de capacitación y registro de usuarios para un evento digital. Desde la perspectiva del producto, el problema real que resuelve el sistema es el siguiente:
Las empresas desarrolladoras de software desconocen cómo aplicar la inteligencia artificial de forma estratégica para incrementar su productividad. Existe una brecha entre la oferta de herramientas de IA disponibles y la adopción efectiva dentro de equipos de desarrollo. El evento "IA para la Alta Productividad en Software" busca cerrar esa brecha, y el sistema es el canal principal de captación de asistentes.
El sistema debe comunicar el valor del evento (secciones de contenido + galería), y capturar el registro del interesado antes de que expire el tiempo límite de inscripción para el evento.
Casa Bengala opera como una empresa de desarrollo de software que, en este contexto, actúa como organizadora de un evento de formación orientado a CEOs, Tech Leads y equipos de ingeniería de empresas desarrolladoras de software.
El sistema a construir es un producto de captación con vida útil acotada: tiene un inicio (apertura del registro), un clímax (el countdown expira) y un cierre (el formulario desaparece). No es un sistema permanente.
Esto tiene implicaciones arquitectónicas directas: la lógica y la visibilidad del formulario no son features de UI, son reglas de negocio que deben estar correctamente encapsuladas y ser independientes del resto del sistema.
Estos son los verbos atómicos e irreducibles que el sistema ejecuta — el vocabulario mínimo del negocio:
| # | Verbo | Actor | Descripción |
|---|---|---|---|
| 1 | Discover | Visitante | El usuario llega a la landing y descubre el evento |
| 2 | Evaluate | Visitante | El usuario consume el contenido del evento (información, galería) para decidir si le interesa |
| 3 | Register | Visitante | El usuario completa y envía el formulario de registro dentro de la ventana de tiempo activa |
| 4 | Validate | Sistema | El sistema valida los datos de entrada antes de persistirlos |
| 5 | Persist | Sistema | El sistema almacena el registro del usuario en la base de datos |
| 6 | Expire | Sistema | El sistema cierra la ventana de registro al agotarse el temporizador |
NOTA: Todo lo que el sistema hace puede reducirse a uno de estos seis verbos. Cualquier feature que no mapee a alguno de ellos está fuera del alcance de negocio.
Aplicando Volatility-Based Decomposition identificamos las áreas del sistema ordenadas de mayor a menor frecuencia de cambio esperada:
V1 · Contenido del Evento (Alta volatilidad) El nombre, fecha, speakers, descripción, imágenes y video del evento cambian en cada edición del evento e incluso durante la misma campaña de marketing. Esta es la zona de mayor volatilidad del sistema y debe estar completamente desacoplada de la lógica y la UI estructural.
V2 · Reglas del Temporizador (Media-Alta volatilidad) La duración del countdown, la fecha de inicio y la lógica de expiración (¿se oculta el formulario?, ¿redirige?, ¿muestra un mensaje?) pueden cambiar por decisión de negocio entre campañas (cancelaciones, cambios de horario, etc). No debe estar hardcodeada en la UI.
V3 · Lógica de Validación del Formulario (Media volatilidad) Los campos requeridos, sus reglas de validación y los mensajes de error pueden evolucionar (e.g., agregar teléfono, empresa, cargo). La validación debe estar encapsulada, no dispersa entre frontend y backend sin contrato claro.