Parte 04 · Clase 40 de 830

ARQ-040 · Validación del programa y control de cambios

Parte 04 · Clase desarrollada · Incorporada en v0.3.0 · 21 de septiembre de 2026.

Material de estudio con casos originales. Revisión externa especializada pendiente. La numeración organiza conocimientos, no un calendario.

Pregunta central

¿Cómo saber que un programa arquitectónico responde al encargo y cómo evitar que sus cambios destruyan decisiones ya justificadas?

Qué aprenderás y qué entregarás

Distinguirás necesidades, requisitos, soluciones y evidencias; construirás una pequeña matriz de verificación y validación; y tramitarás un cambio ficticio con impacto en superficies y relaciones. Entregarás una versión de programa con estados explícitos, una solicitud de cambio y una decisión razonada.

La clase utiliza una adaptación de prácticas de ingeniería de sistemas a un ejercicio arquitectónico. No sustituye permisos, contratos ni atribuciones profesionales. Ningún ejemplo se presenta como aprobado por una autoridad o especialista real.

1. Una necesidad no es todavía una solución

“Las personas necesitan conversar sin exponer asuntos personales” describe una necesidad. “Debe existir una alternativa de atención reservada compatible con el acceso al servicio” expresa un requisito inicial. “Construiremos una sala en esta posición” propone una solución. “La prueba de uso y las verificaciones técnicas muestran que responde a las condiciones definidas” constituye evidencia, si esas pruebas efectivamente se hicieron.

Confundir los niveles dificulta revisar alternativas. Si el requisito se redacta como una solución prematura, cualquier cambio parece negar la necesidad. Si la necesidad queda demasiado vaga, cualquier habitación podría presentarse como respuesta sin demostrar nada.

El objetivo es conservar una cadena revisable: evidencia de origen → necesidad → requisito → decisión de diseño → comprobación → resultado. Los identificadores permiten relacionar documentos sin depender de que todos recuerden la conversación inicial.

2. Requisitos comprensibles y comprobables

Un requisito debe indicar qué condición se necesita y en qué contexto. “El edificio será excelente, flexible y moderno” no ofrece una forma clara de comprobarlo. “La configuración de conversación debe poder prepararse con el almacenamiento y responsables definidos, sin ocupar los recorridos que deben permanecer libres” permite estudiar una secuencia concreta.

No todo requisito se reduce a una cifra. La comprensión de un recorrido o la posibilidad de elegir un lugar de espera pueden evaluarse mediante escenarios, observación y participación, además de revisión técnica. Lo importante es definir evidencia pertinente y criterios antes de declarar éxito.

Evita añadir números arbitrarios para que una frase parezca científica. Un porcentaje de satisfacción sin método, población, pregunta y umbral justificado no convierte una preferencia en una prestación verificable.

3. Verificar y validar hacen preguntas relacionadas, pero distintas

La verificación pregunta si el resultado satisface requisitos especificados. La validación pregunta si responde a necesidades y uso previsto. El manual de NASA distingue esos procesos y contempla métodos como inspección, análisis, demostración y prueba [NASA-VERIFY]. Aquí usamos esa distinción como apoyo metodológico, no como una norma obligatoria para arquitectura.

Puedes verificar que una sala tiene la superficie dibujada y aun descubrir que no permite la actividad para la cual se pidió. También puedes obtener una buena impresión en una simulación de uso sin haber verificado condiciones técnicas necesarias.

Los métodos deben corresponder al requisito. Una fotografía no demuestra aislamiento acústico; una conversación no reemplaza un cálculo profesional; un cálculo de superficie no comprueba que el acceso sea comprensible. La combinación de métodos evita que un tipo de evidencia pretenda responder todas las preguntas.

4. Caso trabajado: una matriz inicial del centro comunitario

El programa ficticio contiene las siguientes necesidades y comprobaciones. Los estados “pendiente” son resultados honestos del ejercicio, no fallos que deban ocultarse.

“Pendiente” necesita una pregunta y un responsable funcional, no necesariamente el nombre de una persona inventada. Por ejemplo, R02 requiere coordinación de arquitectura, operación y especialidad acústica. El programa no debe atribuir firma o aprobación a profesionales que no participaron.

5. Establecer una base de referencia

Una línea base identifica una versión acordada de información para controlar cambios. No implica que todo el diseño esté terminado; implica que se conoce qué se está modificando y con qué procedimiento.

En nuestro caso, la base PB-01 tiene 240 m² útiles programados. Para estimación preliminar se adopta que lo útil será el 80 % de la superficie total, de modo que A_total=240/0,80=300 m². La fracción es un supuesto del ejercicio, no un criterio normativo ni una distribución ya comprobada.

La base incluye tabla de actividades, relaciones, supuestos, estados de comprobación y versión de planos disponibles. Guardar solo un PDF llamado “final” no permite reconstruir esos elementos si luego se reemplaza silenciosamente.

NASA describe gestión de requisitos, configuración y análisis de cambios dentro de procesos técnicos transversales [NASA-CHANGE]. La adaptación importante es conservar identidad, impacto y autorización de las modificaciones, no adoptar burocracia por su nombre.

6. Cambio solicitado: ampliar el taller

Llega CC-03: añadir 24 m² útiles al taller porque se incorporará una actividad con materiales y puestos adicionales. La solicitud describe la nueva actividad; todavía no demuestra que 24 m² sean la respuesta correcta.

Si se aceptara ese aumento manteniendo la proporción preliminar, lo útil pasaría de 240 a 264 m². La superficie total estimada sería 264/0,80=330 m²: aumento de 30 m² totales. No basta sumar 24 a los 300 anteriores y afirmar que todo conserva la misma proporción.

Si el límite del estudio permanece en 300 m² totales, los útiles seguirían siendo 240 bajo el mismo supuesto. Agregar 24 al taller requeriría retirar 24 útiles de otras actividades, cambiar justificadamente el modelo de superficies o revisar el límite. Ninguna de esas decisiones es una simple corrección gráfica.

La cuenta solo descubre una consecuencia. También deben revisarse relaciones, almacenamiento, instalaciones, operación, posibles exigencias y costos mediante los profesionales correspondientes. No calculamos un presupuesto real a partir de estos metros cuadrados.

7. Un registro de cambio desarrollado

La ficha CC-03 del ejercicio puede escribirse así:

Origen: nueva actividad propuesta por el equipo operador ficticio. Necesidad: admitir trabajo con materiales y apoyos que no estaban en PB-01. Solicitud inicial: aumentar 24 m² útiles de taller. Estado: en análisis, no aprobado.

Elementos afectados: actividad T-02, requisito R01, relación taller–bodega, configuración de sala, tabla de superficies y estimación total. Opciones: ampliar el conjunto; redistribuir superficie con efectos sobre otras actividades; estudiar una configuración alternativa; o revisar la actividad solicitada.

Evidencia requerida: descripción de tareas, objetos, simultaneidad, operación, revisión de geometría y coordinación técnica. Decisión del ejercicio: mantener PB-01 como referencia mientras se estudia CC-03; no incorporar el aumento a planos emitidos como si estuviera autorizado.

Condición de cierre: una opción debe contar con justificación de impacto, actualización de requisitos y comprobaciones afectadas, y la autorización de quienes tengan atribuciones en el proyecto. Esta ficha no contiene firmas reales ni representa una autorización de obra.

8. Analizar dependencias, no solo el elemento cambiado

Un cambio de taller puede modificar bodega, recorridos, relación con lectura, carga de instalaciones y mantenimiento. La matriz de relaciones de ARQ-033 permite descubrir parte de esas dependencias. La cadena de evidencia permite saber qué validaciones dejaron de corresponder a la alternativa actual.

No todo cambio obliga a repetir todas las pruebas. La decisión debe basarse en impacto. Cambiar una etiqueta sin alterar significado no equivale a modificar una actividad o una interfaz. Pero llamar “ajuste menor” a una modificación no demuestra que sus consecuencias sean menores.

Una revisión sólida enumera documentos afectados y conserva los que no cambian. También distingue propuestas, versiones de trabajo y documentos emitidos para un uso específico. La claridad de estado evita que una alternativa descartada termine utilizándose como referencia vigente.

9. Validación con participantes y límites técnicos

Para validar el programa se pueden recorrer escenarios con usuarios y operadores, revisar actividades omitidas y contrastar si las prioridades fueron interpretadas correctamente. La participación no exige que esas personas asuman responsabilidad por cálculos o normativa.

Una respuesta favorable a una maqueta demuestra algo sobre la representación y condiciones ensayadas. No garantiza que el edificio construido conservará la misma experiencia. El material de presentación, la geometría y las condiciones pendientes deben quedar declarados.

Del mismo modo, una verificación técnica favorable no elimina la necesidad de comprobar que la actividad prevista tiene sentido operativo. Un espacio puede cumplir un requisito formal y responder mal a una necesidad que fue traducida de manera incompleta.

10. Cerrar con evidencia, no con una palabra

Los estados pueden distinguir propuesto, en revisión, aceptado para desarrollar, comprobado dentro de un alcance y pendiente de nueva comprobación por cambio. Evita una casilla única “listo” que mezcle todos esos significados.

Antes de cerrar una versión, revisa consistencia entre superficies, relaciones, escenarios, requisitos y documentos. Lista excepciones y decisiones pendientes. Una versión puede entregarse para un propósito limitado si ese propósito y sus restricciones son explícitos; no debe presentarse como proyecto ejecutivo terminado cuando no lo es.

El cierre del programa tampoco cierra el aprendizaje. La operación real puede revelar necesidades nuevas. Esas observaciones deben entrar como cambios con evidencia, no como modificaciones invisibles que destruyen la trazabilidad acumulada.

Práctica independiente

Problema A. Partiendo de 240 m² útiles y 300 m² totales estimados, se solicitan 18 m² útiles adicionales. Manteniendo la fracción útil del 80 %, calcula el total nuevo y el aumento. Explica qué habría que reducir para conservar el total anterior.

Problema B. Un informe afirma: “Se verificó privacidad porque el plano contiene una sala llamada reservada”. Explica qué se ha observado realmente y qué comprobaciones faltan.

Problema C. Una relación taller–lectura cambia después de una validación de uso. Redacta tres acciones de control de cambios que deben preceder a mantener esa validación como vigente.

Autoevaluación y transferencia

La entrega es sólida cuando otra persona puede seguir una necesidad hasta una decisión y saber qué versión y evidencia la respaldan. Debes distinguir validación de verificación, calcular el impacto de superficies con la base correcta y reconocer que un cambio espacial puede afectar operación y especialidades. El control de cambios protege el razonamiento del proyecto, no solo sus archivos.

Decisión pedagógica y posición curricular

Por qué existe

Esta clase existe para resolver una necesidad concreta del recorrido: ¿Cómo saber que un programa arquitectónico responde al encargo y cómo evitar que sus cambios destruyan decisiones ya justificadas?

Por qué está exactamente aquí

Cierra la Parte 04: integra lo producido en ARQ-039 · Escenarios de uso, cambio y apropiación para responder «¿Cómo saber que un programa arquitectónico responde al encargo y cómo evitar que sus cambios destruyan decisiones ya justificadas?». La transición hacia ARQ-041 · Cómo leer la historia de la arquitectura sin reducirla a estilos transfiere el método y la disciplina de evidencia, no los datos o parámetros particulares de esta parte.

• Prerrequisitos: ARQ-039
• Capacidad que introduce: Distinguirás necesidades, requisitos, soluciones y evidencias; construirás una pequeña matriz de verificación y validación; y tramitarás un cambio ficticio con impacto en superficies y relaciones. Entregarás una versión de programa con estados explícitos, una solicitud de cambio y una decisión razonada. La clase utiliza una adaptación de prácticas de ingeniería de sistemas a un ejercicio arquitectónico.
• Clases o experiencias que dependen de ella: ARQ-131, ARQ-138, ARQ-041

flowchart LR
    A["Prerrequisitos · ARQ-039"] --> B["ARQ-040 · necesidad y fundamento"]
    S["Fuentes · Organismo: National Aeronautics and Space Administration. Consulta: 2026-09-21. + Organismo: National Aeronautics and…"] --> B
    B --> C["Actividad auténtica"]
    C --> D["Evidencia auditable"]
    D --> E["Continuidad · ARQ-131, ARQ-138, ARQ-041"]

El diagrama permite comprobar una relación que el texto lineal oculta con facilidad: esta clase recibe capacidades previas, toma decisiones apoyadas por fuentes, exige una experiencia y produce evidencia que habilita trabajo posterior. No representa un procedimiento de obra.

Resultado observable, evidencia y evaluación

1. Identificar y delimitar las condiciones necesarias para responder la pregunta central de validación del programa y control de cambios.
2. Producir y comprobar la evidencia declarada por la clase: Distinguirás necesidades, requisitos, soluciones y evidencias; construirás una pequeña matriz de verificación y validación; y tramitarás un cambio ficticio con impacto en superficies y relaciones. Entregarás una versión de programa con estados explícitos, una solicitud de cambio y una decisión razonada. La clase utiliza una adaptación de prácticas de ingeniería de sistemas a un ejercicio arquitectónico.
3. Justificar una decisión de validación del programa y control de cambios mediante fuentes, supuestos, alternativas y límites explícitos.

Actividad, evidencia y criterio de aceptación

Actividad: Problema A. Partiendo de 240 m² útiles y 300 m² totales estimados, se solicitan 18 m² útiles adicionales. Manteniendo la fracción útil del 80 %, calcula el total nuevo y el aumento.

Evidencia mínima: Distinguirás necesidades, requisitos, soluciones y evidencias; construirás una pequeña matriz de verificación y validación; y tramitarás un cambio ficticio con impacto en superficies y relaciones. Entregarás una versión de programa con estados explícitos, una solicitud de cambio y una decisión razonada. La clase utiliza una adaptación de prácticas de ingeniería de sistemas a un ejercicio arquitectónico.

Archivo sugerido: evidence/ARQ-040/evidencia.md.

Criterio de aceptación: la entrega se acepta cuando:

• La entrega responde explícitamente a la pregunta: ¿Cómo saber que un programa arquitectónico responde al encargo y cómo evitar que sus cambios destruyan decisiones ya justificadas?
• La actividad conserva las fronteras del caso y permite reconstruir el procedimiento: Problema A. Partiendo de 240 m² útiles y 300 m² totales estimados, se solicitan 18 m² útiles adicionales. Manteniendo la fracción útil del 80 %, calcula el total nuevo y el aumento.
• Cada afirmación externa puede seguirse hasta una fuente, su alcance consultado y su límite.
• La evidencia deja disponible una entrada comprobable para ARQ-131.
• “Las personas necesitan conversar sin exponer asuntos personales” describe una necesidad. “Debe existir una alternativa de atención reservada compatible con el acceso al servicio” expresa un requisito inicial.

La rúbrica común complementa estos criterios; no los reemplaza. Una entrega puede superar un promedio y continuar pendiente si oculta una condición crítica.

Trazabilidad de las decisiones

La tabla permite auditar las relaciones; la explicación, el caso y la práctica de la clase siguen siendo la documentación principal.

Autoevaluación, recuperación y continuidad

Errores diagnósticos

Antes de avanzar, comprueba si puedes reconstruir cada resultado sin mirar la solución, señalar qué evidencia lo sostiene y nombrar una condición que obligaría a revisar tu decisión. Conserva la primera versión, la objeción recibida y la revisión.

Conexión siguiente: La continuidad inmediata es ARQ-041 · Cómo leer la historia de la arquitectura sin reducirla a estilos; conserva el método y vuelve a verificar datos y límites.

Fuentes y alcance de uso

Las referencias identifican apoyos conceptuales. Los escenarios, cifras y soluciones del capítulo son elaboraciones didácticas originales, no datos de una obra ni ejemplos copiados de estas fuentes.

[NASA-VERIFY] NASA Systems Engineering Handbook, 5.0: Product Realization

Organismo: National Aeronautics and Space Administration. Consulta: 2026-09-21.

https://www.nasa.gov/reference/5-0-product-realization/

Alcance consultado: Apartados web de verificación y validación.

Apoyo: Distinguir conformidad con requisitos de adecuación al uso.

Límites: La verificación de cálculos no constituye validación de un edificio.

[NASA-CHANGE] NASA Systems Engineering Handbook, 6.0: Crosscutting Technical Management

Organismo: National Aeronautics and Space Administration. Consulta: 2026-09-21.

https://www.nasa.gov/reference/6-0-crosscutting-technical-management/

Alcance consultado: Apartados 6.2 y 6.5 sobre requisitos y configuración.

Apoyo: Línea base, trazabilidad y análisis del impacto de cambios.

Límites: Los formularios y el caso arquitectónico son originales; no se copian procedimientos contractuales.