Diseño de la solución · Paso 03 · Cómo trabajamos
La estrategia y la arquitectura definen cómo debe estructurarse un sistema. El diseño de la solución determina exactamente lo que se va a construir — los flujos de trabajo, interfaces, contratos de datos y comportamientos ante fallos específicos que convierten una dirección diseñada en algo que un equipo pueda realmente construir.
Esta etapa no comienza con una implementación. Comienza con una especificación que ha sido probada con evidencia antes de que se escriba una sola línea de código de producción.
Esta no es la pregunta
"¿Qué deberíamos construir?"
Esta pregunta, en cambio
"¿Este diseño específico se comporta realmente como esperamos, bajo las condiciones que enfrentará — y podemos probarlo antes de comprometer el esfuerzo de ingeniería para construirlo?"
Diseño · Prototipo · Prueba · Medir · Especificar
Por qué el diseño sigue a la arquitectura
La arquitectura de referencia de la etapa anterior define capas, elecciones tecnológicas y preocupaciones transversales. Aún no define cómo debe comportarse un flujo de trabajo específico cuando una solicitud es ambigua, ni qué ocurre cuando una integración devuelve datos mal formados. El diseño de la solución cierra esa brecha —sin él, "arquitectura" sigue siendo un diagrama, no un sistema.
Arquitectura de referencia → Especificación de la solución
Por qué el rigor en el diseño importa
La investigación de Barry Boehm sobre la economía de la ingeniería de software —publicada por primera vez en 1976 y ampliada en su libro de 1981 Software Engineering Economics— encontró que el costo de corregir un defecto crece considerablemente cuanto más tarde se detecta.
~1×
Costo de arreglar un defecto detectado durante el diseño.
Boehm, Software Engineering Economics (1981); Boehm & Basili, IEEE Computer (2001).
10×–100×
Costo de arreglar el mismo defecto después del lanzamiento a producción, según la escala del proyecto.
Boehm, Software Engineering Economics (1981); Boehm & Basili, IEEE Computer (2001).
Este hallazgo ha sido revisado desde entonces. La propia revisión de Boehm y Basili de 2001 encontró que la curva es significativamente más plana para equipos pequeños que iteran rápidamente y cuentan con pruebas robustas y entrega continua. El multiplicador no es universal, y no lo tratamos como tal.
Pero la dirección del hallazgo no se ha invalidado: detectar un fallo de diseño antes de construirlo es más barato que detectarlo después. Por eso OpenQCore trata la prototipación y las pruebas como parte del propio diseño —no como una fase que ocurre una vez que la construcción ya ha empezado.
De la arquitectura a la especificación
Cada decisión arquitectónica de la etapa anterior se descompone en especificaciones concretas.
La secuencia exacta de pasos, puntos de decisión, excepciones y transferencias que una solución debe soportar —fundamentada en el Modelo de Flujo de Trabajo del Estado Actual producido durante el descubrimiento, no en un proceso ideal reimaginado.
Lo que cada usuario, sistema o agente realmente ve, envía y recibe —pantallas, flujos conversacionales, contratos de API y los campos que importan en cada paso.
La forma exacta, las reglas de validación, el enfoque de versionado y la propiedad de los datos que se mueven entre componentes.
Lo que el sistema hace —y explícitamente no hace— en condiciones normales, casos límite y condiciones de fallo.
Salida
Especificación de la solución (Borrador)
Diseño de flujo de trabajo e interacción
Una interfaz conversacional superpuesta a un flujo de trabajo defectuoso no arregla el flujo de trabajo —lo oculta, hasta que la limitación subyacente vuelve a aparecer en otro lugar.
El diseño de la solución parte de la evidencia del flujo de trabajo recopilada durante el descubrimiento y plantea una cuestión estructural antes que una cuestión de interfaz: ¿qué pasos de este proceso deberían automatizarse, cuáles deberían permanecer en manos humanas y dónde exactamente se transfiere la responsabilidad entre ellos? Mapeamos esto de forma explícita, para que los puntos con intervención humana sean una decisión de diseño deliberada —no un accidente de lo que la tecnología pudo haber sido capaz.
Puntos de control explícitos donde la revisión, el juicio o la autorización humana son requeridos por diseño — no por omisión.
Límites definidos con precisión sobre lo que un sistema puede decidir o ejecutar sin la aprobación humana.
Rutas diseñadas para casos que quedan fuera del manejo normal — no fallos silenciosos ni soluciones alternativas predeterminadas.
Prototipado y experimentación
OpenQCore trata el diseño en etapas tempranas de la misma manera en que la ciencia del diseño trata un artefacto de sistemas de información: como algo construido específicamente para poder evaluarse frente a un problema real, no simplemente para admirar su elegancia. Este enfoque —formalizado en el influyente Design Science in Information Systems Research de Hevner et al. (MIS Quarterly, 2004)— trata el artefacto y su evaluación como inseparables. Aplicamos el mismo razonamiento guiado por hipótesis usado durante el descubrimiento, pero en el nivel de diseño.
Una decisión de diseño específica y falsable — no una dirección vaga.
Una representación funcional suficiente para probar la decisión — no necesariamente apta para producción.
Entradas reales o realísticamente representativas, no ejemplos idealizados escogidos para tener éxito.
Comparación con la línea base y los criterios de éxito establecidos durante el descubrimiento — no una impresión subjetiva de calidad.
El diseño se mantiene, modifica o abandona según lo que mostró la prueba — no en función de cuánto trabajo ya se haya invertido en él.
El objetivo de un prototipo no es demostrar que un diseño puede funcionar. Es determinar si funciona de forma fiable bajo las condiciones que el sistema terminado enfrentará realmente.
Especificación de datos e interfaz
Los fallos de integración rara vez se originan en una sola decisión obviamente errónea. Tienden a originarse en la ambigüedad: un campo que se supuso que siempre estaría presente, un caso de error que nadie registró, una incompatibilidad de versiones que nadie previó.
Este es un trabajo deliberadamente poco glamuroso. También es el trabajo que determina si un sistema que funciona bien en una demo continúa funcionando bien en producción, tras seis integraciones y dieciocho meses.
Diseñar pensando en el fallo, no solo en el éxito.
La mayoría de los fallos de diseño no son fallos del camino feliz. Son fallos de lo que ocurre cuando algo sale mal — un sistema aguas arriba deja de responder, un documento no se extrae correctamente, un modelo presenta incertidumbre, un usuario hace algo inesperado. OpenQCore diseña estas condiciones deliberadamente en lugar de descubrirlas en producción.
Lo que hace el sistema cuando la confianza en una salida es baja — incluyendo si lo comunica y cómo lo hace.
Qué funciones siguen disponibles cuando falla una dependencia, en lugar de producirse una caída total del sistema.
Las condiciones específicas bajo las cuales un caso se entrega a un humano y qué contexto lleva esa transferencia.
Cómo se comporta el sistema ante entradas mal formadas, secuencias inesperadas o intentos de uso indebido — no solo ante solicitudes bien formadas.
Un sistema al que nunca se le ha preguntado "¿qué ocurre cuando esto falla?" no ha sido realmente diseñado. Solo ha sido demostrado.
Criterios de validación definidos antes de la construcción
De acuerdo con el principio establecido durante el descubrimiento — que el éxito debe definirse antes de la implementación — el Diseño de la Solución produce criterios de aceptación explícitos y por escrito y un plan de pruebas antes de que comience el desarrollo en producción.
Lo que la solución debe hacer correctamente, expresado en términos verificables.
Consistente con las características de calidad del software reconocidas — incluyendo eficiencia de rendimiento, fiabilidad, usabilidad, seguridad y mantenibilidad, tal como las organiza el modelo de calidad de producto de software ISO/IEC 25010 — especificadas como objetivos medibles en lugar de aspiraciones generales.
Los escenarios, conjuntos de datos y condiciones específicas con los que se evaluará la solución antes de considerarla apta para su construcción en producción.
La puerta de revisión del diseño
Esta práctica tiene precedente: el método formal de inspección de diseño y código de Michael Fagan, introducido en IBM en 1976, estableció que la revisión estructurada y basada en criterios detecta defectos antes y con más fiabilidad que la aprobación informal. OpenQCore aplica el mismo principio al diseño de soluciones.
La especificación es lo suficientemente precisa, el prototipo cumplió sus criterios de evaluación y el desarrollo puede comenzar.
La dirección principal es sólida, pero elementos específicos requieren revisión en función de lo revelado por las pruebas.
El trabajo de diseño reveló una restricción que la arquitectura no contemplaba — la respuesta apropiada es revisar la estructura, no diseñar en torno a ella.
El trabajo de diseño reveló un riesgo — técnico, operacional, de seguridad o ético — que requiere una decisión por encima de la autoridad del equipo de diseño antes de continuar.
Una puerta de diseño que siempre dice sí no es una puerta.
Lo que produce el diseño de la solución
Dependiendo del alcance del compromiso, esta etapa produce:
Flujos de trabajo, interfaces, contratos de datos y comportamiento, con suficiente detalle para construir sin tener que volver a deducir la intención.
Representaciones visuales del flujo de procesos, incluyendo puntos explícitos de intervención humana.
Esquemas, reglas de validación y estrategia de versionado para cada interfaz entre componentes.
Qué se probó, frente a qué línea base, y qué apoyan o descartan los resultados.
Condiciones de falla documentadas y la respuesta del sistema diseñada para cada una.
Las condiciones específicas y medibles que la solución construida debe satisfacer antes del despliegue.
Del diseño al desarrollo e integración
El diseño de la solución produce una especificación probada y validada — no un sistema terminado. La siguiente etapa convierte esa especificación en software funcional, integrado con los sistemas con los que debe operar.
Especificación de la solución → Evaluación de prototipo → Criterios de aceptación → Desarrollo e integración
Paso 04
Construya la solución especificada conforme a criterios de aceptación definidos — no según suposiciones.
Referencias de investigación y metodológicas
Boehm, B. — Economía de la ingeniería de software (1981); Boehm, B. & Basili, V. — "Lista Top 10 de reducción de defectos de software", IEEE Computer (2001)
Fuente de los hallazgos sobre el costo del cambio mencionados arriba, incluida la revisión posterior que muestra una curva más plana para equipos pequeños que iteran rápidamente.
Hevner, A., March, S., Park, J., & Ram, S. — "La ciencia del diseño en la investigación de sistemas de información," MIS Quarterly (2004)
Marco fundamental para tratar un artefacto de sistemas de información y su evaluación como inseparables — la base para el ciclo de prototipo-prueba-refinamiento descrito arriba.
Fagan, M. — "Inspecciones de diseño y de código para reducir errores en el desarrollo de programas," IBM Systems Journal (1976)
Origen de la revisión de diseño estructurada basada en criterios como práctica de ingeniería formal, referenciada en la Puerta de Revisión de Diseño arriba.
ISO/IEC 25010:2011 — Requisitos y evaluación de la calidad de sistemas y software (SQuaRE) — Modelos de calidad de sistemas y software
Fuente de las características de calidad no funcionales mencionadas en los criterios de aceptación anteriores.
