Pensar como ingeniero: construir bajo restricciones

Un puente no falla porque su dibujante haya olvidado la palabra «seguridad». Falla cuando una necesidad se traduce mal, una carga se supone menor de lo que es, una unión no se inspecciona, una variación se trata como excepción o una reparación cambia el sistema sin que nadie lo registre. También puede «funcionar» y ser inaceptable: demasiado caro de mantener, inaccesible para sus usuarios, contaminante, imposible de retirar o dependiente de una pieza que ya no se fabrica.

Pensar como ingeniero es construir una cadena de decisiones que conecte una necesidad humana con una solución material o sociotécnica bajo condiciones explícitas. Esa cadena contiene requisitos, restricciones, modelos, prototipos, pruebas, márgenes, interfaces, riesgos, responsables y decisiones de ciclo de vida. No es una receta lineal ni una garantía de éxito. Es una forma de hacer visible qué se sabe, qué se supone, qué se mide y qué queda por decidir.

El capítulo 389 trata fallas funcionales, mantenimiento, diagnóstico y repuestos; aquí la mantenibilidad aparece como una propiedad que debe diseñarse, no como una intervención posterior. El capítulo 391 desarrollará especificaciones, tolerancias, planos, versiones y control de configuración; aquí se explica por qué esas representaciones hacen posible decidir, sin convertir el capítulo en un manual de documentación.

390.1. Necesidades, requisitos y criterios verificables#

Una necesidad expresa un problema, propósito o resultado que importa a alguien: transportar personas con seguridad, mantener una temperatura, permitir que una persona con movilidad limitada abra una puerta o contener un fluido durante una vida prevista. Todavía no dice qué componente comprar ni qué tecnología usar. Preguntar quién necesita qué, en qué entorno, con qué consecuencias si falla y durante cuánto tiempo evita diseñar una solución para un problema imaginado.

Un requisito convierte una necesidad en una condición que puede comprobarse. «Debe ser cómodo» puede orientar una conversación, pero no basta para decidir conformidad. Un requisito útil identifica sujeto, función, condición de operación, límite y método de verificación. «El asiento permitirá la transferencia lateral sin que el usuario deba levantar todo su peso, en el escenario de uso definido, y será evaluado con usuarios representativos» aún necesita criterios concretos, pero ya señala contexto, usuario y evidencia. No todo requisito debe ser una cifra: puede verificarse una secuencia, una interfaz, una compatibilidad o la ausencia de una condición peligrosa.

La claridad no consiste en escribir requisitos más largos. La guía de ingeniería de sistemas de NASA recomienda expresar una sola idea por requisito, evitar términos ambiguos y acompañar supuestos con una justificación que pueda validarse. «Adecuado», «fácil», «rápido», «robusto» y «cuando sea necesario» pueden ser útiles en una conversación inicial, pero si permanecen sin definición permiten que cada parte del proyecto imagine un resultado distinto. La redacción debe conservar la intención sin ocultar la decisión pendiente.

La verificación pregunta si el sistema construido cumple una condición especificada: mediante inspección, análisis, demostración, prueba u otra evidencia apropiada. La validación pregunta si el sistema resuelve la necesidad en el entorno y uso previstos. Un dispositivo puede verificarse contra una dimensión y no validar la tarea porque es difícil de limpiar, incómodo o confuso. El manual de sistemas de NASA separa estas preguntas y propone planificar qué evidencia demostrará conformidad y qué evidencia mostrará utilidad para usuarios y clientes.

La trazabilidad vincula necesidad, requisito, diseño, prueba y decisión. No significa llenar una base de datos sin leerla. Significa poder responder de dónde salió una condición, qué parte la implementa, cómo se comprueba y qué se altera si cambia. Una matriz puede mostrar que un requisito no tiene prueba, que dos equipos interpretan la misma interfaz de manera diferente o que una prueba cubre solo el caso nominal. La trazabilidad también hace visible un requisito huérfano: una característica implementada que nadie pidió y que introduce costo o riesgo.

Las necesidades no pertenecen solo al cliente que paga. Incluyen usuarios directos, operadores, mantenedores, vecinos, servicios de emergencia, autoridades, proveedores y personas afectadas sin poder de decisión. Una carretera, una aplicación médica o una planta industrial tiene públicos distintos y a veces intereses incompatibles. La participación no garantiza consenso, pero descubre usos reales, barreras y efectos que un equipo técnico puede no observar. Documentar el desacuerdo es más honesto que inventar una «voz del usuario» única.

Un requisito es también una afirmación sobre el futuro. Cambios de clima, regulación, suministro, conducta, software o mantenimiento pueden dejarlo fuera de contexto. Por eso las condiciones de aplicabilidad, supuestos y horizonte deben quedar explícitos. La evidencia es que una necesidad fue recogida y un requisito fue formulado; la inferencia es que esa condición representa suficientemente el uso; la recomendación es adoptar una arquitectura o prueba. Separarlas evita que una preferencia de diseño se presente como hecho inevitable.

390.2. Restricciones y compromisos de diseño#

Toda solución se construye bajo restricciones. Algunas son físicas: resistencia, energía, estabilidad, temperatura, espacio, velocidad, materiales o límites de fabricación. Otras son institucionales: presupuesto, plazo, regulación, interfaces existentes, capacidades de mantenimiento, compras o propiedad. Otras son humanas y ambientales: accesibilidad, exposición, ruido, privacidad, residuos, dignidad, distribución de beneficios y efectos sobre terceros. Una restricción no es un inconveniente que el ingeniero pueda eliminar con optimismo; es una condición que debe modelarse, negociarse o respetarse.

Una interfaz es la frontera por la que pasan materia, energía, información, fuerza, responsabilidad o autoridad. Muchos fallos nacen donde dos subsistemas son correctos por separado: un conector encaja pero no soporta el ambiente; una señal tiene el formato esperado pero llega tarde; una pieza cumple la carga nominal pero no el acabado del asiento; una instrucción asigna una tarea sin dar autoridad para detenerla. Definir interfaces temprano revela acoplamientos y evita que cada equipo optimice su parte a costa del conjunto.

Los compromisos aparecen porque los objetivos compiten. Reducir masa puede disminuir margen estructural; aumentar redundancia puede añadir costo, consumo y modos de fallo; sellar mejor puede dificultar reparación; maximizar velocidad puede reducir tiempo para detectar un error. No existe «optimización» sin una función de valor y límites. Una solución que es mejor según peso y peor según seguridad no puede llamarse óptima sin decir qué prioridad se adoptó.

La decisión debe distinguir restricciones duras de preferencias. Una normativa de emisiones puede ser un límite no negociable; un acabado estético puede ser una preferencia; un presupuesto puede ser un límite político revisable o una condición contractual. Clasificar todo como absoluto bloquea alternativas; tratar todo como intercambiable permite incumplimientos peligrosos. El análisis de alternativas hace explícito qué se relaja, quién autoriza y qué consecuencia se acepta.

Los modelos de decisión pueden representar costos, desempeño y riesgo, pero no eliminan juicios de valor. Un análisis multicriterio puede comparar opciones con pesos explícitos; un análisis de sensibilidad muestra qué supuesto cambia la elección; un escenario extremo revela una fragilidad. La precisión decimal de una hoja de cálculo no convierte en exacta una probabilidad incierta. El modelo debe declarar entradas, rangos, exclusiones y la evidencia que lo actualiza.

La fabricación y el uso retroalimentan el diseño. Una tolerancia difícil de medir, un acceso imposible para mantenimiento o una herramienta que el operador no puede sujetar son restricciones reales, aunque no aparezcan en el primer dibujo. El capítulo 377 mostró cómo tolerancias, uniones, rodamientos y reparación forman una cadena funcional; aquí la lección es que la solución debe incorporar el proceso que la realizará y el ciclo de servicio que la conservará. Diseñar una pieza que solo puede producirse una vez en un laboratorio no es diseñar una capacidad repetible.

Un compromiso responsable no se oculta detrás de una cifra agregada. Si una opción reduce costo desplazando riesgo a trabajadores, usuarios o comunidades, ese traslado debe nombrarse. Si una mejora de eficiencia aumenta dependencia de un proveedor o de una red, esa dependencia es parte del balance. El criterio no es evitar toda renuncia —imposible—, sino hacerla visible, justificable, reversible cuando sea posible y sometida a revisión cuando cambien las condiciones.

390.3. Modelos, prototipos y pruebas#

Un modelo es una representación parcial que permite razonar antes de construir el sistema completo. Puede ser una ecuación, un dibujo, una simulación, una maqueta, un modelo físico, una prueba de concepto o una descripción de estados. Su valor depende de la pregunta: un modelo de cargas no demuestra usabilidad; una simulación de flujo no demuestra que un sensor pueda limpiarse; una maqueta de tamaño real puede revelar acceso y postura, pero no resistencia a fatiga. Todo modelo tiene un dominio de validez.

La fidelidad no es una propiedad única. Un prototipo puede reproducir geometría y no materiales; otro puede reproducir control y no escala; una simulación puede representar una perturbación difícil de provocar físicamente. Elegir qué fidelidad importa evita gastar en una réplica completa cuando una prueba barata puede eliminar la incertidumbre decisiva. La pregunta correcta es: ¿qué decisión cambia si este supuesto es falso y qué evidencia lo discrimina?

Un prototipo no es necesariamente una versión incompleta del producto final. Puede ser un instrumento para aprender una interfaz, una unión, una secuencia, una distribución térmica o una capacidad de fabricación. Su resultado debe registrar condiciones y limitaciones. «Funcionó» carece de sentido si no se sabe con qué carga, ambiente, usuario, duración, tolerancia y procedimiento. Un prototipo puede ser exitoso como aprendizaje aunque falle como producto; ocultar ese fallo destruye su función.

Las pruebas tienen objetivos distintos. Una prueba exploratoria busca descubrir comportamientos; una de caracterización estima una propiedad; una de verificación demuestra cumplimiento frente a un requisito; una de validación observa si la solución satisface una necesidad en su contexto. Mezclarlas produce conclusiones exageradas. Una demostración de un caso favorable no sustituye un ensayo de límites; un ensayo de laboratorio no demuestra operación en campo; la opinión de un usuario sobre comodidad no estima resistencia estructural.

La planificación de pruebas incluye criterio de éxito, muestras, instrumentos, ambiente, incertidumbre, condiciones de parada y tratamiento de resultados inesperados. La prueba debe ser segura para el objeto, el equipo y las personas. Cuando un ensayo destructivo es la única evidencia válida, se decide cuántas unidades y qué variación representan; cuando no puede reproducirse el entorno real, se justifica la simulación y sus límites. La prueba no debe diseñarse para confirmar una decisión tomada, sino para poder refutarla.

La evidencia negativa es información. Un prototipo que se atasca al limpiar, una estructura que vibra, una interfaz que confunde o un ensayo que no es repetible señala una hipótesis falsa o incompleta. Corregir el dispositivo y volver a probar puede ser necesario, pero no se debe borrar el resultado anterior: la historia de cambios muestra qué riesgos se resolvieron y cuáles se trasladaron. La revisión independiente ayuda a evitar que el equipo que diseñó interprete toda evidencia en favor de su solución.

La validación con usuarios requiere contexto y consentimiento. Un evaluador experto puede compensar una mala interfaz; un usuario real puede usar el sistema de una manera no prevista. En productos que afectan salud, movilidad, privacidad o seguridad, la prueba debe considerar vulnerabilidad, accesibilidad, datos y consecuencias. El «usuario promedio» suele excluir precisamente a quien encuentra la barrera más costosa. La ingeniería integra conocimiento técnico y experiencia situada, no los enfrenta.

390.4. Optimización con objetivos en conflicto#

Optimizar significa buscar una solución mejor según objetivos y restricciones definidos. En muchos proyectos hay varios objetivos: costo, energía, masa, duración, velocidad, reparabilidad, accesibilidad, ruido, emisiones y seguridad. Si no pueden maximizarse a la vez, existe un conjunto de compromisos: mejorar una métrica puede empeorar otra. Presentar una sola puntuación como verdad final oculta los pesos y la distribución de las consecuencias.

Una frontera de Pareto reúne soluciones en las que no se puede mejorar un objetivo sin empeorar al menos otro, dadas las restricciones del modelo. No elige por sí sola. Una opción de bajo costo y alta reparación puede competir con otra de menor energía inicial; la decisión depende de horizonte, usuarios, riesgos y autoridad. El análisis de sensibilidad muestra cuándo una incertidumbre pequeña cambia la frontera. Si cambia con cualquier supuesto, la conclusión debe expresarse como condicional, no como recomendación categórica.

Los objetivos de seguridad suelen actuar como límites, no como una variable compensable. No es aceptable justificar una probabilidad mayor de daño porque el producto sea más barato o rápido, salvo que exista un marco regulatorio y ético explícito para decidir el riesgo. La ingeniería de riesgos identifica peligros, escenarios, barreras, exposición y consecuencias. Una barrera debe tener responsable, prueba, mantenimiento y respuesta; una lista de peligros sin mecanismo de control es inventario, no gestión.

La optimización puede crear efectos de sistema. Reducir material en un componente concentra tensiones en otro; reducir inventario aumenta sensibilidad a retrasos; ahorrar energía en operación puede exigir materiales difíciles de reciclar; automatizar selección puede excluir casos atípicos. Por eso se analizan interfaces, ciclo de vida y usuarios afectados. Una decisión local debe demostrar que no desplaza la carga a una fase o grupo menos visible.

Las restricciones de fabricación y suministro también forman parte del problema. Una geometría óptima en simulación puede requerir una máquina inexistente, una inspección que no puede realizarse o una materia prima con cadena de suministro frágil. Incorporar capacidad del proveedor, reparabilidad, sustitución y fin de vida evita optimizar un objeto imposible de sostener. El diseño para desmontaje y reparación puede sacrificar una fracción de desempeño nominal y ganar disponibilidad durante años.

Los escenarios son más honestos que una predicción única cuando hay incertidumbre. Se prueban demanda baja y alta, ambiente frío y caliente, operador nuevo y experto, suministro normal e interrumpido, sensor sano y fallado. No se trata de imaginar todos los futuros, sino de detectar decisiones que son buenas solo en uno. La recomendación final debe declarar qué escenarios cubre, qué no cubre y qué señal activaría una revisión.

390.5. Márgenes, tolerancias y seguridad#

Un margen es la distancia entre el desempeño previsto y un límite relevante. Puede referirse a carga, temperatura, energía, tiempo, capacidad, memoria, presión, precisión o disponibilidad. Un margen no es un número universal ni una reserva que pueda gastarse sin control. Depende de incertidumbres, variación, degradación y consecuencias. Un diseño con margen amplio en una condición puede tenerlo estrecho en otra; la verificación debe explorar los extremos que realmente gobiernan.

Las tolerancias describen variación permitida de una característica; los márgenes comparan capacidad y demanda o condición y límite. Una tolerancia demasiado estrecha encarece fabricación y medición; una demasiado amplia puede impedir función o aumentar riesgo. La combinación de tolerancias puede cerrar un juego, desalinear una interfaz o reducir un margen térmico. El análisis debe incluir correlación, temperatura, desgaste, montaje y medición, no sumar cifras por hábito.

La seguridad trabaja con incertidumbre epistemológica —lo que aún no se conoce— y variabilidad aleatoria —lo que cambia entre casos—. Un promedio no representa un máximo; una prueba favorable no cubre una combinación rara; una probabilidad calculada sobre datos pobres no merece muchos decimales. Conviene registrar supuestos, rangos, confianza y sensibilidad. Cuando la consecuencia es grave, se prefieren barreras y diseño inherentemente seguro antes que confiar en una estimación optimista.

La revisión de seguridad pregunta qué ocurre cuando una función falla, un usuario se equivoca, un componente envejece o dos desviaciones coinciden. Los análisis de modos y efectos de fallo, árboles de fallos, listas de peligros o revisiones estructuradas son herramientas, no veredictos. Deben incluir condiciones de operación, mantenimiento, interfaces, factores humanos y recuperación. Una alarma que requiere interpretar tres pantallas puede ser una barrera débil aunque el sensor sea exacto.

El margen también es humano. Un procedimiento que solo funciona con tiempo ilimitado y atención perfecta no tiene margen operativo. El acceso para inspeccionar, la claridad de una señal, la posibilidad de detener el sistema y la disponibilidad de repuestos reducen o aumentan riesgo. Diseñar para mantenimiento no significa hacer el equipo más grande sin límite; significa definir qué tareas son necesarias, con qué herramientas, formación y tiempo, y verificar que puedan ejecutarse sin exposición indebida.

La seguridad no se certifica una sola vez. Cambiar material, software, proveedor, uso, ambiente o procedimiento puede consumir margen y crear un modo de fallo nuevo. La gestión de configuración y cambio del marco ISO/IEC/IEEE 15288:2023 sitúa los procesos de sistemas a lo largo del ciclo de vida y permite aplicarlos iterativa y concurrentemente. El manual NASA de ingeniería de sistemas insiste en que la verificación objetiva y la validación en el entorno de uso cumplen funciones relacionadas pero distintas.

390.6. Ciclo de vida y responsabilidad#

Un sistema comienza antes de fabricarse y continúa después de su puesta en servicio. La concepción define problema y actores; el desarrollo transforma requisitos en arquitectura; la producción introduce variación; la operación revela usos reales; el mantenimiento conserva o modifica funciones; el retiro redistribuye materiales, datos, riesgos y responsabilidades. La ISO/IEC/IEEE 15288:2023 proporciona un marco de procesos para el ciclo completo —concepción, desarrollo, producción, utilización, soporte y retiro— sin imponer una metodología única.

La responsabilidad no consiste en predecir todo. Consiste en identificar quién decide, qué evidencia tenía, qué supuestos aceptó, qué controles instaló y cómo respondió cuando aparecieron señales nuevas. Una firma no sustituye al razonamiento, pero una decisión sin autoridad y registro no puede ser revisada. La responsabilidad se distribuye entre diseñadores, organizaciones, proveedores, operadores, reguladores y usuarios; distribuirla no significa diluirla.

La operación devuelve conocimiento al diseño. Un modo de fallo raro, una reparación recurrente, una queja de accesibilidad o un residuo inesperado pueden mostrar que el requisito era incompleto. Los registros deben conservar contexto suficiente para distinguir defecto de uso fuera de alcance, sin usar esa distinción para culpar automáticamente al usuario. El aprendizaje debe cambiar diseño, formación, mantenimiento o advertencias según la causa; no solo añadir una nota al manual.

La sostenibilidad pertenece al ciclo de vida y no a una etiqueta final. Materiales, energía, transporte, mantenimiento, durabilidad, reparabilidad, emisiones, datos, trabajo y retiro forman una evaluación. Alargar la vida puede ahorrar fabricación y aumentar consumo de mantenimiento; sustituir un componente puede reducir energía y aumentar residuos; reciclar puede requerir separar mezclas que nunca se diseñaron para desmontarse. La decisión debe especificar función, horizonte y efectos desplazados.

El retiro seguro es una fase de diseño. Un producto puede contener energía almacenada, sustancias peligrosas, datos personales, componentes bajo presión o materiales que requieren tratamiento especializado. Una infraestructura abandonada puede convertirse en riesgo físico o financiero. Diseñar para desmontaje, borrado, recuperación y disposición reduce decisiones improvisadas al final. También permite que el sistema deje de operar sin que su última acción sea una falla.

La ética ingenieril aparece en decisiones ordinarias: qué caso se considera normal, qué usuario se excluye de la prueba, qué defecto se acepta para cumplir fecha, qué riesgo se traslada a mantenimiento, qué incertidumbre se oculta en un promedio y qué evidencia se conserva. La competencia técnica no elimina el deber de decir «no sabemos» o «esta opción no es segura bajo esas condiciones». Pedir una revisión adicional puede costar tiempo; omitirla puede convertir una incertidumbre privada en daño público.

Pensar como ingeniero es sostener una conversación verificable entre necesidad, materia, información, personas y tiempo. Los requisitos hacen evaluable el propósito; las restricciones impiden soluciones imaginarias; los modelos y prototipos convierten supuestos en preguntas; la optimización muestra compromisos; los márgenes y barreras administran incertidumbre; el ciclo de vida devuelve consecuencias a las decisiones iniciales. El resultado no es una obra perfecta, sino un sistema cuyas condiciones de éxito, límites y responsabilidades pueden explicarse y revisarse.

Preguntas de transferencia#

La puerta accesible que no se usa#

Caso. Una puerta cumple su ancho nominal y una prueba de inspección, pero personas con distintas ayudas técnicas no pueden abrirla sin ayuda. ¿Qué falló en el razonamiento?

El diseño más barato#

Caso. Dos soluciones cumplen la función nominal; una cuesta menos al comprarla, pero requiere piezas importadas y una reparación especializada. ¿Cómo se compara?

El prototipo que “funciona”#

Caso. Un prototipo funciona en una demostración breve, pero no se ha probado con polvo, usuarios nuevos ni ciclos repetidos. ¿Qué puede concluirse?

Cambiar un componente crítico#

Caso. Un proveedor propone sustituir un material por otro “equivalente” para evitar un retraso. ¿Qué debe activarse?

Fuentes y lecturas del capítulo#

International Organization for Standardization. ISO/IEC/IEEE 15288:2023, Systems and software engineering — System life cycle processes. Marco internacional de procesos para concepción, desarrollo, producción, utilización, soporte y retiro de sistemas. (ISO).

National Aeronautics and Space Administration (NASA). NASA Systems Engineering Handbook. Guía institucional sobre necesidades, requisitos, arquitectura, verificación, validación, márgenes, riesgos y ciclo de vida. (NASA).

NASA. Systems Engineering Handbook — Appendix y Product Realization. Recursos sobre redacción de requisitos, métodos de verificación, validación, pruebas y control de cambios. (Appendix; Product Realization).

International Council on Systems Engineering (INCOSE). Systems Engineering Handbook. Referencia profesional sobre conceptos, procesos de ciclo de vida, adaptación y práctica de ingeniería de sistemas. (INCOSE).

NASA. MSFC Systems Engineering Handbook, MSFC-HDBK-3173. Guía pública de prácticas de ingeniería de sistemas a lo largo del ciclo de vida de proyectos y actividades. (NASA Technical Standards).

Bibliografía de la parte XXXV · Bibliografía general

Última revisión editorial

3 de octubre de 2026

Cierre de contenidos

3 de octubre de 2026