Lecciones aprendidas en la gestión de requisitos: fallos en la conversión de unidades

En el desarrollo de productos de hardware, los ingenieros comparten números todos los días. Un valor pasa de un ingeniero a un plano, de una especificación a un componente, o de tu equipo a un proveedor. La mayoría de las veces, eso funciona porque todos saben qué significa el número y qué unidad utiliza.

El riesgo aparece cuando ese valor cruza un punto de transferencia y las dos partes no lo interpretan de la misma manera. Una parte puede trabajar en libras mientras la otra espera kilogramos. Un documento puede usar un diseño imperial anterior, mientras que el nuevo proyecto es métrico. El número puede parecer correcto para ambas partes, pero ya no está guiando la misma decisión.

Las tres historias de ingeniería a continuación muestran lo fácil que puede ser que esto ocurra:

Tres casos, un mismo patrón

Tres fallos de ingeniería, a lo largo de tres décadas, muestran el mismo problema de transferencia en distintas formas. En cada caso, un número pasó de una parte del flujo de trabajo a otra. El número parecía correcto para los usuarios, pero había dos sistemas de medida en juego. En la transferencia no se aclaró qué unidad utilizaba el número.

Vuelo 143 de Air Canada: el Gimli Glider

El primer ejemplo es el Gimli Glider de 1983. Muestra lo que ocurrió cuando una aerolínea, Air Canada, cambió de unidades imperiales a métricas. El vuelo 143, un Boeing 767 que volaba de Montreal a Edmonton, fue su primera aeronave métrica.

Ese día, el sistema indicador de cantidad de combustible (FQIS) no funcionaba, por lo que la tripulación midió el combustible manualmente. Utilizaron la cifra de densidad del operador de repostaje de 1,77, que estaba en libras por litro, el estándar para el resto de la flota. Pero el 767 métrico necesitaba esa cifra en kilogramos por litro, donde el valor correcto era aproximadamente 0,8.

La aeronave despegó con solo la mitad del combustible que la tripulación esperaba, lo que provocó que ambos motores se detuvieran durante el vuelo. Por suerte, los pilotos lograron aterrizarla de forma segura.

Mars Climate Orbiter

Dieciséis años después, el Mars Climate Orbiter se perdió debido a un error de navegación causado por no convertir unidades inglesas a métricas. El software de Lockheed Martin envió los datos de los propulsores en libra-fuerza segundo. El software de navegación de NASA esperaba newton-segundo, que difieren de las libra-fuerza segundo por un factor de 4,45.

La nave espacial debía orbitar entre 150 y 200 kilómetros sobre Marte. En cambio, descendió hasta unos 57 kilómetros y se desintegró en la atmósfera marciana.

La montaña rusa Space Mountain de Tokyo Disneyland

En 2003, la montaña rusa Space Mountain de Tokyo Disneyland mostró un problema similar a través de los planos de diseño. La atracción se redibujó de imperial a métrico en 1995, cambiando el diámetro de un eje de 44,14 a 45 milímetros. Sin embargo, los planos antiguos no se retiraron de uso y, como resultado, había dos juegos de planos de diseño.

En 2002, cuando se volvió a hacer un pedido de un nuevo conjunto de ejes, el pedido se basó en la versión de diseño anterior a 1995. Como resultado, las piezas llegaron con un tamaño menor al debido. Esa diferencia de 0,86 milímetros hizo que la holgura del rodamiento fuera mucho mayor de lo previsto. Tras meses de uso, el eje se rompió.

En los tres casos, el número en sí no parecía sospechoso. El problema comenzó cuando ese número se convirtió en la base del siguiente paso de ingeniería y su unidad o su origen no estaban lo bastante claros.

La ilustración es un recordatorio de que un valor puede parecer correcto para todos y aun así estar mal: ¿coinciden ambas partes de tu transferencia en la unidad?

Qué pueden aprender los equipos de hardware de estas historias

La mayoría de los equipos de hardware no vuelan aeronaves ni lanzan naves espaciales. Pero transferencias similares ocurren todos los días. Un valor pasa de un requisito a un plano, de una especificación a un componente, o de tu equipo a un proveedor. En cada transferencia, la unidad tiene que permanecer junto al número. Tres prácticas pueden ayudar:

Especifica unidades en cada valor de requisito

Un número por sí solo no es suficiente. “45” no le dice a la siguiente persona qué debe construir o probar. “45 mm” le da significado al número. Mantén la unidad junto al valor en todo momento. No es un detalle de formato; es parte del requisito.

Asigna responsabilidad en las transferencias de ingeniería

Las confusiones con unidades suelen ocurrir cuando la información pasa de un equipo a otro. Una parte puede estar trabajando con una referencia, mientras la otra espera otra distinta. Esa transferencia necesita un responsable claro. Alguien debe comprobar el sistema de unidades, el formato de los datos y el documento fuente antes de que el valor se utilice en las etapas posteriores.

Mantén los requisitos y la evidencia con trazabilidad

Cuando un valor cambia, el equipo necesita encontrar qué depende de él. Eso significa que el requisito, el plano, el componente, la prueba y la evidencia no deben existir como elementos desconectados. La trazabilidad ayuda al equipo a ver de dónde proviene un valor, qué lo utiliza y qué necesita revisión cuando cambia.

Cómo ayuda un flujo de trabajo conectado para requisitos

Un mejor flujo de trabajo de requisitos mantiene juntos el número, su unidad, su responsable y el documento fuente. No trata el valor como un simple número suelto en una hoja de cálculo, un plano o una especificación.

Esto importa especialmente en las transferencias. Cuando un valor pasa de un requisito al trabajo de diseño o verificación, la siguiente persona puede ver qué significa el valor, qué unidad utiliza y de dónde proviene. Si el valor cambia, el equipo también puede identificar qué necesita revisión.

Altium Requirements Portal da soporte a este tipo de flujo de trabajo al mantener requisitos, responsables, trazabilidad y trabajo de verificación en un entorno compartido. No sustituye el criterio de ingeniería. Ayuda a mantener visibles la unidad, el responsable y el contexto de ingeniería relacionado antes de que un valor se use en las etapas posteriores.

Conclusiones clave

• Las confusiones con unidades suelen comenzar en las transferencias, cuando un valor pasa a otro equipo, documento o sistema y su unidad no se deja clara.
• Antes de que un número guíe el siguiente paso de ingeniería, el equipo debe saber de dónde proviene y quién es responsable de él.
• La trazabilidad ayuda a los equipos a ver qué depende de un valor antes de que cambie o pase a etapas posteriores.

¿Está completo cada número de tu proyecto?

Cada uno de estos incidentes podría haberse evitado. No con mejor ingeniería, sino con preguntas claras hechas en el momento de la transferencia:

• ¿Cada valor de tus requisitos incluye una unidad?
• ¿Cada interfaz entre equipos tiene a alguien responsable de ella?
• ¿Está claro qué versión de una especificación es la actual?
• Si algo cambiara mañana, ¿tu proceso mostraría qué necesita revisarse?

Ahora hazte las mismas preguntas sobre tu proyecto. Si la respuesta a alguna de ellas es "probablemente", ya sabes por dónde empezar.

Mantén clara y fácil de comprobar la información de ingeniería importante en cada transferencia con una herramienta de gestión de requisitos que todo tu equipo pueda usar.

Comienza con Requirements Portal →

Preguntas frecuentes

¿Por qué ocurren los errores de conversión de unidades en proyectos de ingeniería?

Estas confusiones rara vez se deben a malos cálculos. Ocurren en las transferencias, cuando un valor pasa entre equipos, herramientas o documentos. Una parte puede asumir que el valor está en una unidad, mientras que la otra lo interpreta en otra. El valor puede seguir siendo correcto, pero es correcto para una suposición equivocada.

¿Qué debe incluir un valor de requisito completo?

Un valor de requisito completo debe incluir el número, la unidad y el contexto necesario para usarlo correctamente. Por ejemplo, “45” no es suficiente; “45 milímetros” sí lo es. El equipo también puede necesitar saber la condición en la que aplica el valor, el documento fuente y quién es responsable de ese requisito.

¿Cómo ayuda la trazabilidad a reducir errores en las transferencias?

La trazabilidad vincula un valor con todo lo que depende de él: desde el requisito de nivel superior hasta el componente, la prueba y el responsable asociados. Cuando un valor cambia, esos vínculos facilitan encontrar qué más puede necesitar revisión. Esto reduce la probabilidad de que una especificación antigua, una unidad poco clara o una prueba desactualizada sigan usándose por error.