Desglose de trabajo rastreable
Cada tarea de implementación está vinculada a un requisito específico o a un criterio de aceptación — no a una descripción de función vagamente relacionada.
Desarrollo e Integración · Paso 04 · Cómo trabajamos
Una especificación se convierte en software.
El Diseño de la solución produce una especificación probada y criterios de aceptación definidos. Esta etapa convierte esa especificación en software funcional y verificado — integrado con los sistemas con los que debe operar, y probado frente a los criterios definidos antes de que comenzara el desarrollo.
El desarrollo aquí no es interpretación. Toda decisión de implementación se remonta a una especificación producida durante el diseño — no a lo que un desarrollador supuso que probablemente era la intención.
No es esta la pregunta
"¿El código funciona?"
Esta pregunta, en su lugar
"¿El sistema construido satisface los criterios de aceptación definidos antes de que comenzáramos — bajo condiciones reales de integración, no solo en aislamiento?"
Implementación · Verificación · Integración · Trazabilidad · Disciplina de entrega
Por qué el desarrollo sigue al diseño
Nada de esto es conjetura.
Todas las entradas a esta etapa se produjeron durante el Diseño de la solución: el Documento de Especificación de la Solución, el Informe de Evaluación del Prototipo y los Criterios de Aceptación y el Plan de Pruebas. Desarrollar sobre una especificación no probada simplemente trasladaría al código de producción el riesgo que el prototipado pretendía eliminar.
Especificación de la solución + Criterios de aceptación → Implementación verificada
Por qué importa la disciplina de entrega
La velocidad y la estabilidad se miden juntas, no se sacrifica una por la otra.
El desempeño en la entrega de software no es simplemente una cuestión de qué tan rápido un equipo escribe código. La investigación de Forsgren, Humble y Kim — publicada en Accelerate: The Science of Lean Software and DevOps (2018), basada en la investigación plurianual del programa DevOps Research and Assessment (DORA) a través de miles de organizaciones — identificó dos categorías de desempeño de ingeniería que deben medirse conjuntamente: throughput (rendimiento) y estabilidad.
Tiempo de entrega
Cuánto tiempo tarda un cambio validado en pasar desde el commit hasta un estado desplegable.
Forsgren, Humble & Kim, Accelerate (2018); DORA, informe State of DevOps.
Tasa de fallos de cambios
El porcentaje de cambios que introducen un defecto que requiere corrección.
Forsgren, Humble & Kim, Accelerate (2018); DORA, informe State of DevOps.
Un equipo que entrega rápidamente pero que con frecuencia provoca fallos no tiene un buen desempeño según esta investigación — y tampoco lo tiene un equipo que entrega de forma segura pero demasiado lentamente como para importar. OpenQCore mantiene ambas dimensiones en consideración durante esta etapa, en lugar de optimizar únicamente la velocidad.
De la especificación a la implementación
Cada línea de trabajo se remonta a un requisito.
El trabajo de implementación se descompone directamente a partir de la Especificación de la Solución y de los Criterios de Aceptación — no a partir de una comprensión general de lo que el diseño "intentaba lograr".
Definición de Hecho
Una tarea no está completa cuando se escribe el código. Está completa cuando cumple el criterio de aceptación vinculado bajo prueba.
Control de deriva de la especificación
Cuando la implementación revela una laguna o ambigüedad en la especificación, la especificación se actualiza y revisa — no se reinterpreta silenciosamente por quien esté escribiendo el código ese día.
Verificación dirigida por pruebas
La verificación se realiza en cada capa, no solo al final.
OpenQCore estructura la verificación según la pirámide de pruebas —un marco ampliamente utilizado, popularizado por Mike Cohn— para equilibrar la cobertura de pruebas entre las capas de un sistema en lugar de concentrarla en pruebas de extremo a extremo lentas y costosas.
Pruebas unitarias
Verificación rápida y aislada de componentes individuales frente a su comportamiento especificado —incluido su comportamiento ante entradas no válidas.
Pruebas de integración
Verificación de que los componentes interactúan correctamente según los contratos de datos definidos durante el diseño de la solución.
Pruebas de extremo a extremo
Verificación de flujos de trabajo completos frente a los criterios de aceptación definidos antes de comenzar el desarrollo —la capa más pequeña y costosa, reservada para lo que realmente lo requiere.
El objetivo no es la mayor cantidad de pruebas. Es la confianza de que los criterios de aceptación se cumplen genuinamente, en la capa de menor costo capaz de demostrarlo.
Pruebas de integración y de contratos
Un contrato de API solo es real si se prueba, no solo si se documenta.
Los contratos de datos y de API especificados durante el Diseño de la Solución no se tratan como documentación para seguir de forma informal. OpenQCore aplica pruebas de contrato impulsadas por el consumidor —un enfoque formalizado en herramientas como Pact— donde cada punto de integración se verifica frente a un contrato ejecutable que ambas partes de la integración deben cumplir.
Esto importa especialmente para sistemas que deben conectarse a infraestructura existente: un contrato que solo se verifica mediante revisión manual puede desviarse silenciosamente a medida que cualquiera de los lados cambie. Un contrato que se prueba automáticamente no puede.
Revisión de código y verificación estática
Un segundo revisor detecta lo que el autor no puede.
Investigaciones ampliamente citadas sobre la revisión por pares de código —incluido el estudio realizado en Cisco Systems y popularizado en Best Kept Secrets of Peer Code Review de Cohen et al.— concluyeron que la efectividad de la revisión depende en gran medida del ritmo y el alcance: revisiones más pequeñas y más frecuentes, realizadas sin presión de tiempo, detectan sustancialmente más defectos que revisiones grandes realizadas rápidamente.
OpenQCore aplica revisión de código estructurada junto con análisis estático automatizado —estilo, complejidad y escaneo de vulnerabilidades conocidas— como una capa de verificación permanente, no como un pase de cortesía opcional antes de la fusión.
Canalización de Integración Continua
Cada cambio se verifica de la misma manera, automáticamente.
Commit → Compilación automatizada → Pruebas unitarias y de integración → Análisis estático y de seguridad → Verificación de contratos → Listo para despliegue.
La verificación manual e inconsistente no escala y no produce una señal fiable sobre si un cambio es realmente seguro para liberar —una determinación que se toma en la siguiente etapa, Despliegue y Habilitación. Lo que garantiza esta etapa es que un cambio que alcanza esa puerta ya ha sido verificado según el mismo estándar automatizado que todos los cambios anteriores.
Prácticas de desarrollo seguras
La seguridad se verifica durante el desarrollo, no se audita después.
Las prácticas de desarrollo de OpenQCore se alinean con la estructura descrita en el Secure Software Development Framework (SP 800-218) del NIST — organizando la actividad de seguridad en torno a preparar la organización, proteger el software, producir software bien asegurado y responder a las vulnerabilidades.
Escaneo de dependencias y vulnerabilidades
Escaneo automatizado de dependencias de terceros en busca de vulnerabilidades conocidas como parte del pipeline estándar, no una auditoría manual periódica.
Modelado de amenazas
Consideración estructurada de cómo un componente podría ser mal utilizado, informada por los modos de fallo definidos durante el diseño de la solución.
Implementación de privilegios mínimos
Alcances de acceso y permisos implementados en el nivel más restringido que satisface la especificación — no en el nivel más amplio que sea conveniente.
La puerta de verificación de integración
Una compilación no está lista solo porque compila.
Cada cambio alcanza una puerta de verificación definida antes de que pueda considerarse para su despliegue.
Listo para el despliegue
Se cumplen todos los criterios de aceptación, verificados mediante pruebas automatizadas, comprobaciones de contrato y escaneo de seguridad.
Devolver para correcciones
Los defectos específicos e identificados deben resolverse antes de que este cambio pueda continuar.
Volver al diseño
La implementación reveló que la propia especificación no se sostiene en condiciones reales — la respuesta correcta es revisar la especificación, no eludirla con código.
Escalar el riesgo
Se identificó un riesgo de seguridad, cumplimiento o arquitectónico que requiere una decisión por encima de la autoridad del equipo de desarrollo.
Un pipeline que siempre alcanza "listo para el despliegue" no está verificando nada.
Lo que produce esta etapa
Software listo para la decisión de desplegar — aún no desplegado.
Dependiendo del alcance del compromiso, esta etapa produce:
Base de código verificada
Implementación rastreable hasta la especificación, superando todas las capas de verificación definidas.
Informe de cobertura de pruebas
Resultados de pruebas unitarias, de integración y de extremo a extremo mapeados a los criterios de aceptación.
Conjunto de pruebas de contrato
Verificación ejecutable de cada punto de integración definido durante el diseño de la solución.
Registros de revisión de código
Historial de revisiones documentado y resolución de los problemas planteados.
Resultados del escaneo de seguridad
Hallazgos de dependencias, vulnerabilidades y análisis estático y su resolución.
Documentación de la canalización de CI
La canalización de verificación automatizada aplicada a este cambio, y a todos los cambios posteriores.
Del desarrollo al despliegue y habilitación
El software verificado aún no es software en producción.
Desarrollo e Integración produce software que ha sido verificado frente a su especificación —no software que haya sido lanzado, monitorizado o demostrado estable bajo la carga real de producción. La siguiente etapa regula cómo, cuándo y con qué seguridad ese software llega realmente a producción.
Especificación de la solución → Implementación verificada → Despliegue y habilitación
Paso 05
Despliegue y habilitación
Poner en producción software verificado de forma segura, deliberada y con una ruta definida para revertirlo.
Referencias de investigación y metodológicas
Forsgren, N., Humble, J. y Kim, G. — Accelerate: La ciencia del software Lean y DevOps (2018); Google Cloud, investigación DORA sobre el estado de DevOps
Fuente de las métricas de rendimiento de entrega mencionadas anteriormente.
Cohn, M. — Succeeding with Agile (2009)
Fuente del concepto de la pirámide de pruebas mencionado anteriormente en la verificación dirigida por pruebas.
Cohen, J. et al. — Best Kept Secrets of Peer Code Review (SmartBear, basado en investigación de Cisco Systems)
Fuente de los hallazgos sobre la eficacia de la revisión de código mencionados anteriormente.
Pact / Contratos dirigidos por el consumidor
Un enfoque establecido para contratos de integración ejecutables y verificados automáticamente, mencionado anteriormente en la sección de pruebas de integración.
NIST — Marco de Desarrollo de Software Seguro, SP 800-218
Fuente de la estructura citada en las prácticas de desarrollo seguro mencionadas anteriormente.