Verificación y validación de la solución software es el módulo del ciclo 3 — Validar la solución — donde ustedes determinan si una solución de software ya diseñada realmente se puede construir y sostener con el equipo, la tecnología y la infraestructura disponibles. Lo van a hacer en cinco fases, cada una construida sobre la anterior: primero identifican requerimientos, restricciones y dependencias; después evalúan las tecnologías y la infraestructura; luego valoran la capacidad real del equipo; después verifican estándares y seguridad; y por último comprueban con una prueba de concepto los supuestos más críticos, antes de emitir el dictamen final. Mi nombre es Anwar Abdallah, Ingeniero de Software, y voy a acompañarlos como profesor a lo largo de las cinco fases.
La mayoría de los proyectos de software no fallan por falta de talento: fallan porque alguien dio por sentado que algo iba a funcionar, sin comprobarlo antes de comprometerse. Este módulo certifica exactamente esa capacidad: la de detenerse a verificar, con evidencia, antes de decir "sí se puede".
Van a trabajar siempre sobre un diseño que ya existe — no lo van a crear ustedes — y su trabajo es someterlo a prueba: ¿los requerimientos están bien derivados? ¿las restricciones del entorno están documentadas con evidencia? ¿el equipo realmente tiene la competencia que el proyecto exige? ¿el diseño cumple los estándares y es seguro? ¿los supuestos más riesgosos se probaron antes de construir?
Junto con el módulo 095 (que verifica que el diseño esté completo y consistente), este módulo cierra la verificación del ciclo 3 y los deja listos para pasar, con evidencia y no con optimismo, del diseño a la construcción.
Cada fase se cursa sobre el entregable de la anterior. Las cinco fases y sus dieciséis clases ya están disponibles en este sitio, de modo que pueden avanzar a su propio ritmo dentro de cada fase.
Identifican los requerimientos técnicos que el diseño impone, las restricciones del entorno de operación, y las dependencias internas y externas — incluidas las que el diseño no declara.
Evalúan si las tecnologías, la arquitectura y la infraestructura previstas en el diseño son realmente compatibles con el entorno donde va a operar la solución.
Valoran la competencia real del equipo frente a lo que el proyecto exige, y estiman el esfuerzo de implementación con ese dato, no con optimismo.
Verifican que el diseño cumpla los estándares aplicables y revisan su seguridad, distinguiendo una desviación que es defecto de una que es decisión justificada.
Determinan qué supuesto crítico merece una prueba de concepto, la ejecutan, y emiten el dictamen final de conveniencia técnica de la solución.
Cada técnica usa un código corto (RT-0XX, TC-0XX, etc.) para nombrar de forma consistente las filas de sus tablas de registro. Estos códigos son una convención propia de este módulo, pensada para que las dieciséis clases hablen el mismo idioma — no son una sigla estándar de la industria. La actividad que cada técnica enseña sí es una práctica reconocida en el desarrollo de software profesional, y esta tabla muestra cómo se llama esa práctica afuera de este curso.
| Código | Técnica / Fase | Qué registra | Así se llama en la industria |
|---|---|---|---|
| RT-0XX | Técnica 1 · Fase 1 | Requerimiento técnico derivado del diseño | Matriz de trazabilidad de requisitos (Requirements Traceability Matrix, RTM) — estándar ISO/IEC/IEEE 29148 |
| RE-0XX | Técnica 2 · Fase 1 | Restricción del entorno de operación | Sección de supuestos y restricciones ("assumptions and constraints") de un documento de requisitos, misma norma ISO/IEC/IEEE 29148 |
| DP-0XX | Técnica 3 · Fase 1 | Dependencia interna o externa | Mapeo de dependencias de arquitectura / grafo de dependencias (p. ej. modelo C4, herramientas como Structurizr) |
| TE-0XX | Técnica 4 · Fase 2 | Examen de compatibilidad de una tecnología | Análisis de brechas tecnológicas (technology fit-gap analysis) — ejemplo real: el Technology Radar de ThoughtWorks |
| IN-0XX | Técnica 5 · Fase 2 | Evaluación de infraestructura | Evaluación de preparación de infraestructura / planificación de capacidad (infrastructure readiness assessment, capacity planning) |
| TC-0XX | Técnica 6 · Fase 2 | Componente de terceros (madurez, mantenimiento, licencia) | Análisis de composición de software (Software Composition Analysis, SCA), que produce un SBOM (Software Bill of Materials, formatos SPDX/CycloneDX) — herramientas reales: Snyk, Dependabot, FOSSA, OWASP Dependency-Check |
| VC-0XX | Técnica 7 · Fase 3 | Valoración de competencia del equipo (nombre completo inferido por el docente; la lección no lo escribe así de forma explícita) | Matriz de habilidades / análisis de brechas de competencias (skills matrix, competency gap analysis) |
| CX-0XX | Técnica 8 · Fase 3 | Complejidad técnica de una tarea | Evaluación de complejidad técnica, parte de la práctica de estimación de esfuerzo |
| OC-0X | Técnica 8 · Fase 3 | Orden de construcción por dependencias | Secuenciación de tareas por dependencias / método de la ruta crítica (Critical Path Method, CPM) |
| CA-0X | Técnica 8 · Fase 3 | Curva de aprendizaje del equipo | Estimación de curva de aprendizaje (learning curve estimation) |
| EF-0X | Técnica 8 (cierre) · Fase 3 | Esfuerzo estimado, con margen de incertidumbre | Estimación de esfuerzo con incertidumbre (estimación de tres puntos / PERT, planning poker) |
| EO-0XX | Técnica 9 · Fase 4 | Estándar u obligación que el diseño debe cumplir | Matriz de cumplimiento normativo / de estándares (regulatory or standards compliance matrix) |
| — (Técnica 10 no usa código) | Técnica 10 · Fase 4 | Clasificación de una desviación del diseño | Gestión de desviaciones / dispensas y reporte de no conformidad (deviation/waiver management, Non-Conformance Report, NCR) |
| VU-0XX | Técnica 11 · Fase 4 | Vulnerabilidad detectada en el diseño | Modelado de amenazas (threat modeling) — ejemplo real: metodología STRIDE |
A lo largo de las cinco fases van a registrar su proceso en el Diario de Formación institucional: qué hicieron, qué aprendieron y qué mejoraron en cada momento. Descarguen el documento y tráiganlo diligenciado a medida que avanzan.
⬇ Descargar el Diario de Formación (.docx)