⌂ ARQ · 830 + 60

Parte 44 · Clase 432 de 830

ARQ-432 · Requisitos de información y usos del modelo

Parte 44 · Clase desarrollada · Incorporada en v0.25.0.

Prerrequisitos conceptuales: ARQ-431. Sin calendario. Los casos, cantidades, algoritmos e indicadores son didácticos y ficticios salvo antecedentes expresamente atribuidos. No constituyen certificación BIM, ACV conforme, auditoría, especificación contractual ni habilitación profesional. Revisión externa especializada pendiente.

Pregunta central

¿Qué información debe producirse, cuándo y para qué decisión, antes de pedir un modelo “más detallado”?

Resultado y continuidad

ARQ-432 abre un nuevo tramo dentro de la Parte 44 y recibe los métodos de la clase anterior sin heredar automáticamente sus cifras. Elaborarás una estructura de evidencia, resolverás un caso reproducible, contrastarás una variante y cerrarás distinguiendo dato, requisito, interpretación y pendiente.

1. Definir la pregunta y el uso

Un requisito de información debe comenzar por un uso y una decisión. Para mantener una bomba interesa identidad, ubicación, acceso, manuales y datos de reposición; para comprobar coordinación espacial interesan geometría, tolerancias y relaciones. Pedir “LOD alto” sin definir propósito puede aumentar trabajo sin mejorar la decisión.

2. Información que debe conservar significado

Conviene separar información requerida de información disponible y de información aceptada. Un atributo puede existir y estar desactualizado; un valor puede ser correcto pero pertenecer a otra fase. El estado y la fecha forman parte del dato cuando la decisión depende del tiempo.

3. Estados, versiones y fronteras

Los requisitos también necesitan granularidad. Si el mantenimiento se gestiona por equipo, una propiedad agregada al sistema completo puede ser insuficiente; si la decisión es estratégica, exigir cada tornillo puede ser inútil. La granularidad adecuada reduce tanto vacíos como sobreproducción.

4. Comprobación antes de automatizar

La verificabilidad exige escribir criterios que otra persona pueda comprobar. “Modelo completo” es ambiguo; “cada unidad de ventilación tendrá identificador único, ubicación y vínculo con manual vigente antes de la entrega” permite revisar existencia, unicidad y estado.

5. Caso trabajado

Caso INFO-REQ-01: un operador ficticio necesita programar mantenimiento de 12 equipos. Se exigen cinco campos por activo: ID, ubicación, tipo, fecha de instalación y manual. El primer intercambio contiene 60 celdas posibles: 54 con datos, 3 vacías y 3 con manuales marcados “por confirmar”. La completitud bruta es 90 %, pero la clase no acepta sumar “por confirmar” como evidencia válida. Para el uso mantenimiento, solo 54/60 están realmente disponibles; además se revisa si los tres vacíos pertenecen al mismo equipo, porque una sola ficha incompleta puede bloquear una tarea entera.

6. Profundización: de una cifra a una decisión auditable

La comprobación no termina cuando una suma cierra. Debe poder reconstruirse la procedencia de cada entrada, la unidad, la versión y la frontera a la que pertenece. Cuando dos resultados se comparan, ambos deben responder a la misma pregunta o la diferencia debe explicarse antes de concluir.

Una segunda comprobación útil cambia una sola hipótesis. Si el resultado cambia mucho, la decisión es sensible a ese dato; si cambia poco, puede ser más importante investigar otra variable. Sensibilidad no significa probabilidad: los escenarios del curso no inventan distribuciones estadísticas cuando no hay datos.

También se conserva el estado desconocido. En información digital, un campo ausente no es cero; en una comparación ambiental, un módulo no reportado no es impacto nulo; en un control de reglas, una condición no comprobada no se transforma en aprobación. Esta disciplina impide que un tablero visualmente “verde” o una tabla aparentemente completa oculte huecos relevantes.

7. Interfaces profesionales y control de cambios

Arquitectura, ingeniería, construcción, operación, datos y sostenibilidad pueden utilizar el mismo objeto con propósitos diferentes. El registro debe indicar quién origina una propiedad, quién la revisa, para qué uso se acepta y qué modificación obliga a reabrir la evidencia. Un cambio de geometría puede afectar cantidad, cronograma y análisis ambiental; un cambio de producto puede afectar propiedades, documentación y mantenimiento.

El control de cambios no exige repetir indiscriminadamente todo. Exige rastrear dependencias y justificar qué permanece válido. Si un identificador, versión o fuente cambia, los documentos dependientes deben revisarse de forma proporcional al efecto. Conservar la base anterior permite entender la evolución y evita reemplazar silenciosamente resultados desfavorables.

8. Errores frecuentes

Evita confundir presencia de información con validez; formato abierto con interoperabilidad garantizada; automatización con verificación completa; clasificación con desempeño; archivo entregado con activo operable; EPD con superioridad ambiental; carbono con sostenibilidad total; y certificación con cumplimiento de todas las dimensiones del proyecto.

Otro error es sumar porcentajes o indicadores que tienen denominadores distintos. Antes de combinar valores, escribe sus unidades, población u objeto, horizonte y criterio. Cuando no existe una conversión defendible, presenta los resultados en paralelo y explica el conflicto en lugar de fabricar una puntuación universal.

Figura 432. Esquema original del programa. Resume relaciones del caso; no representa una obra, producto o certificación real.

9. Práctica independiente

Para ocho activos define cuatro campos necesarios para una inspección anual. Crea un intercambio con dos campos ausentes y uno desactualizado. Calcula completitud sintáctica y completitud válida, y explica por qué no deben presentarse como el mismo indicador.

10. Solución razonada

Con 32 campos esperados, si 30 existen la completitud sintáctica es 93,75 %. Si uno de esos 30 está desactualizado, solo 29 son utilizables bajo el criterio: 90,625 %. La respuesta debe identificar además qué decisión queda bloqueada y no limitarse a un porcentaje.

La solución pertenece únicamente al modelo declarado. En un proyecto real deben verificarse fuentes, contratos de información, software, reglas de intercambio, declaraciones ambientales, datos de producto, legislación, autorizaciones y responsabilidades aplicables. Una ficha pública de norma no equivale a la lectura completa de sus cláusulas.

11. Autoevaluación y transferencia

Puedes avanzar cuando seas capaz de reconstruir el caso sin mirar la respuesta, nombrar al menos una condición que el cálculo no verifica y explicar qué actor debería producir la evidencia pendiente. Si solo puedes repetir el porcentaje final, el aprendizaje está incompleto.

La clase siguiente conserva el método, no las cifras. Las familias de casos permanecen separadas para que un valor didáctico no reaparezca como antecedente de otro proyecto.

Decisión pedagógica y posición curricular

Por qué existe

Esta clase existe para resolver una necesidad concreta del recorrido: ¿Qué información debe producirse, cuándo y para qué decisión, antes de pedir un modelo “más detallado”?

Por qué está exactamente aquí

Ocupa el lugar 2 de la Parte 44. Se estudia después de ARQ-431 · BIM es gestión de información, no solo modelar en 3D porque usa esa base para responder «¿Qué información debe producirse, cuándo y para qué decisión, antes de pedir un modelo “más detallado”?». Se ubica antes de ARQ-433 · Coordinación, responsabilidades y entorno común de datos porque la evidencia producida aquí debe estar disponible para ese paso.

flowchart LR
    A["Prerrequisitos · ARQ-431"] --> B["ARQ-432 · necesidad y fundamento"]
    S["Fuentes · ISO-19650-1 ISO 19650-1:2018 — Information management using BIM: Concepts and principles — ISO. + ISO-19650-2 ISO…"] --> B
    B --> C["Actividad auténtica"]
    C --> D["Evidencia auditable"]
    D --> E["Continuidad · ARQ-433"]

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 requisitos de información y usos del modelo.
  2. Producir y comprobar la evidencia declarada por la clase: ARQ-432 abre un nuevo tramo dentro de la Parte 44 y recibe los métodos de la clase anterior sin heredar automáticamente sus cifras. Elaborarás una estructura de evidencia, resolverás un caso reproducible, contrastarás una variante y cerrarás distinguiendo dato, requisito, interpretación y pendiente.
  3. Justificar una decisión de requisitos de información y usos del modelo mediante fuentes, supuestos, alternativas y límites explícitos.

Actividad, evidencia y criterio de aceptación

Actividad: Para ocho activos define cuatro campos necesarios para una inspección anual. Crea un intercambio con dos campos ausentes y uno desactualizado. Calcula completitud sintáctica y completitud válida, y explica por qué no deben presentarse como el mismo indicador.

Evidencia mínima: ARQ-432 abre un nuevo tramo dentro de la Parte 44 y recibe los métodos de la clase anterior sin heredar automáticamente sus cifras. Elaborarás una estructura de evidencia, resolverás un caso reproducible, contrastarás una variante y cerrarás distinguiendo dato, requisito, interpretación y pendiente.

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

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

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

# Decisión o fundamento Fuente utilizada Aplicación y límite en esta clase
1 Principios de gestión de información de activos ISO-19650-1 ISO 19650-1:2018 — Information management using BIM:… Consulta: Ficha pública Límite: No es licencia de software ni certificado automático de un modelo.
2 Gestión de información durante la entrega del proyecto ISO-19650-2 ISO 19650-2:2018 — Delivery phase of the assets Consulta: Ficha pública; edición publicada con revisión en curso Límite: Un proyecto de revisión no reemplaza por sí solo la edición publicada. Texto íntegro no consultado.
3 Requisitos de intercambio legibles por personas y máquinas y comprobación automatizada de información alfanumérica en IFC. BIM-IDS Information Delivery Specification (IDS) 1.0 Consulta: Página oficial del estándar y documentación pública; IDS 1.0 figura como estándar final desde 2024. Límite: IDS no cubre por sí solo comprobaciones geométricas; no se implementa aquí un archivo contractual real.

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-433 · Coordinación, responsabilidades y entorno común de datos; conserva el método y vuelve a verificar datos y límites.

Fuentes y alcance de uso

[ISO-19650-1] ISO 19650-1:2018 — Information management using BIM: Concepts and principles

ISO. https://www.iso.org/standard/68078.html

Consulta: Ficha pública Apoyo: Principios de gestión de información de activos Límite: No es licencia de software ni certificado automático de un modelo.

[ISO-19650-2] ISO 19650-2:2018 — Delivery phase of the assets

ISO. https://www.iso.org/standard/68080.html

Consulta: Ficha pública; edición publicada con revisión en curso Apoyo: Gestión de información durante la entrega del proyecto Límite: Un proyecto de revisión no reemplaza por sí solo la edición publicada. Texto íntegro no consultado.

[BIM-IDS] Information Delivery Specification (IDS) 1.0

buildingSMART International. https://www.buildingsmart.org/standards/bsi-standards/information-delivery-specification-ids/

Consulta: Página oficial del estándar y documentación pública; IDS 1.0 figura como estándar final desde 2024. Apoyo: Requisitos de intercambio legibles por personas y máquinas y comprobación automatizada de información alfanumérica en IFC. Límite: IDS no cubre por sí solo comprobaciones geométricas; no se implementa aquí un archivo contractual real.