Lecciones aprendidas sobre gestión de requisitos: vuelo 501 del Ariane 5

El desastre del vuelo 501 de Ariane 5 muestra por qué siempre deberíamos pensarlo dos veces antes de reutilizar tal cual requisitos, diseños de ingeniería y pruebas de proyectos anteriores. 

En el desarrollo de productos de hardware, es común reutilizar requisitos, rutinas de software, casos de prueba o decisiones de diseño de proyectos previos. Eso puede ahorrar tiempo, pero solo si las condiciones que hacían válidas esas decisiones siguen aplicando.

Ariane 5 Flight 501 fue el primer vuelo del cohete europeo Ariane 5, el 4 de junio de 1996. El cohete reutilizó parte del software del sistema de referencia inercial de Ariane 4, un cohete europeo anterior en el que el software había funcionado con éxito. Pero Ariane 5 seguía un perfil de vuelo diferente, uno de los valores superó el rango que el software esperaba, y el cohete fue destruido menos de un minuto después del lanzamiento.

La lección es simple, pero fácil de olvidar: antes de reutilizar trabajo de proyectos anteriores, compruebe si los mismos supuestos y condiciones de operación siguen siendo válidos en el nuevo proyecto.

Conclusiones clave

• Reutilizar requisitos, software, pruebas o decisiones de diseño ya comprobados ahorra tiempo, pero es necesario revisar el contexto original.
• Revise los casos de prueba reutilizados antes de usarlos para demostrar el mismo requisito en otro producto.
• Reduzca el riesgo manteniendo conectados los requisitos, los procedimientos de prueba, la evidencia y el estado.

Qué ocurrió en el lanzamiento de Ariane 5

El 4 de junio de 1996, Ariane 5 realizó su primer vuelo desde Kourou, Guayana Francesa, transportando cuatro satélites de investigación Cluster para la Agencia Espacial Europea. La misión duró menos de un minuto. Aproximadamente a los treinta y siete segundos de vuelo, el cohete se desvió de su trayectoria prevista y fue destruido.

El problema se originó en el sistema de referencia inercial, que enviaba datos de actitud y velocidad a la computadora de a bordo del cohete. Ariane 5 reutilizó software de Ariane 4, incluida una rutina de alineación que permanecía activa durante unos 40 segundos después del lanzamiento. Esa rutina había funcionado en Ariane 4, pero Ariane 5 seguía un perfil de vuelo diferente.

Debido a ese perfil diferente, ocurrieron varias cosas en rápida sucesión:

• Un valor de velocidad horizontal se volvió mayor de lo que el software esperaba.
• El software intentó convertir el valor de un número de punto flotante de 64 bits a un entero con signo de 16 bits, pero ya no cabía en ese formato.
• La conversión produjo un desbordamiento, y el sistema de referencia inercial trató esto como un error y se apagó.
• El sistema de respaldo ejecutaba el mismo software y se apagó por la misma razón.
• Sin datos de vuelo válidos, la computadora de a bordo utilizó datos de diagnóstico en su lugar, emitió comandos de vuelo incorrectos y el cohete fue destruido.

Esto es lo que hace que este caso sea útil para la gestión de requisitos. El software reutilizado había funcionado antes, pero arrastraba un supuesto del cohete anterior: que este valor se mantendría dentro de un rango seguro. Ariane 5 cambió el contexto de ese supuesto, por lo que era necesario hacerlo visible y volver a comprobarlo en el nuevo sistema.

La ilustración sirve como recordatorio de que el trabajo de ingeniería reutilizado todavía necesita una verificación simple: ¿siguen siendo ciertos en el nuevo sistema los supuestos que hay detrás?

Qué pueden aprender los equipos de hardware del caso Ariane 5

La mayoría de los equipos de hardware no construyen cohetes, pero reutilizan trabajo ya probado constantemente. Un bloque de PCB de un producto anterior puede copiarse en un nuevo diseño. Una rutina de firmware puede pasar a una nueva revisión de hardware. Un procedimiento de prueba puede mantenerse aunque cambie la arquitectura de alimentación. 

Eso es trabajo de ingeniería normal. La reutilización ayuda a los equipos a avanzar más rápido. El paso importante es asegurarse de que el requisito, el supuesto y la verificación sigan correspondiendo al nuevo sistema.

Revise los requisitos reutilizados

Un requisito que funcionó en un producto no debe considerarse automáticamente válido en el siguiente. Puede que las mismas palabras sigan pareciendo correctas, pero las condiciones de operación a su alrededor pueden haber cambiado. Por ejemplo, un límite de corriente, un rango térmico o una restricción de interfaz puede ser seguro en un diseño y requerir revisión en otro. Antes de reutilizar un requisito, el equipo debe comprobar si el nuevo producto sigue operando dentro de los mismos supuestos.

Vincule los supuestos con los procedimientos de verificación

Algunos de los supuestos de ingeniería más importantes nunca se escriben como requisitos formales. Viven en notas de diseño, planes de prueba antiguos o en la memoria de alguien. Esto puede volverse riesgoso cuando el trabajo se reutiliza. Si un supuesto afecta una decisión de diseño, el equipo necesita una forma de conectarlo con una verificación. De lo contrario, es fácil reutilizar la decisión sin ver la razón que la hizo segura en primer lugar.

Revise las pruebas cuando cambien los requisitos

Un caso de prueba que se aprobó en el proyecto anterior no siempre demuestra lo mismo en el siguiente. Si el requisito cambia, o si cambia el sistema alrededor del requisito, es posible que el procedimiento de prueba relacionado también deba cambiar. Esto es especialmente importante cuando los equipos reutilizan casos de prueba, criterios de aceptación o evidencia de cumplimiento.

Cómo ayuda un flujo de trabajo de requisitos conectado

Un mejor flujo de trabajo de requisitos no trata un requisito como una línea de texto independiente. Mantiene el requisito conectado con la razón que hay detrás, el trabajo de diseño al que afecta y el trabajo de verificación que muestra si sigue siendo válido. 

Eso es lo más importante cuando algo cambia. Un requisito reutilizado puede seguir pareciendo correcto, pero el supuesto que hay detrás puede que ya no coincida con el nuevo producto. Una prueba puede seguir existiendo, pero puede que ya no verifique la condición correcta.

En un flujo de trabajo conectado, los equipos pueden mantener juntas las piezas importantes: el requisito, el contexto que lo respalda, el método de verificación, el procedimiento, el resultado, la evidencia y el estado actual. En lugar de buscar en documentos antiguos o informes de pruebas, los ingenieros pueden ver qué está conectado y qué puede necesitar otra revisión.

Altium Requirements Portal admite este tipo de flujo de trabajo al mantener requisitos, trazabilidad, responsables y trabajo de verificación en un entorno compartido. Esto ayuda a los equipos a reutilizar trabajo ya probado con mayor confianza porque el requisito y las verificaciones a su alrededor permanecen conectados.

¿Los supuestos antiguos de su proyecto siguen siendo válidos?

Cada equipo de hardware reutiliza trabajo ya probado. No es un atajo que deba evitarse, sino una forma práctica de desarrollar más rápido y aprovechar buenas decisiones de ingeniería. 

La pregunta útil es qué cambió alrededor de ese trabajo reutilizado:

• ¿Cambió el rango de operación? 
• ¿Es necesario revisar la prueba? 
• ¿Siguen aplicando los supuestos detrás de la decisión original?

Cuando los equipos pueden responder a esas preguntas, resulta más fácil confiar en la reutilización. El requisito no queda aislado. La razón que hay detrás, la verificación y la evidencia permanecen lo suficientemente cerca como para que el equipo pueda revisarlas cuando cambia el contexto del producto. 

Esta es la lección que Ariane 5 sigue dando hoy a los equipos de hardware: la reutilización funciona mejor cuando el contexto que la sustenta permanece conectado.

Facilite la revisión y la confianza en las decisiones de reutilización con una herramienta de gestión de requisitos a la que todo su equipo pueda acceder.

Comience con Requirements Portal →

Preguntas frecuentes

¿Puede volverse riesgosa la reutilización del trabajo de ingeniería?

La reutilización del trabajo de ingeniería puede volverse riesgosa cuando cambia el contexto del producto, pero no se vuelven a revisar los supuestos originales, los límites operativos o las verificaciones. El trabajo puede seguir pareciendo correcto, pero las condiciones que lo hacían válido en el proyecto anterior pueden ya no aplicar.

¿Qué deben comprobar los ingenieros antes de reutilizar un requisito, una prueba o una decisión de diseño?

Los equipos deben comprobar si el nuevo producto utiliza las mismas condiciones de operación, interfaces, límites y criterios de aceptación que el proyecto original. También deben confirmar que el método de verificación relacionado sigue demostrando lo correcto en el nuevo sistema.

¿Cómo ayuda la trazabilidad cuando se reutilizan requisitos?

La trazabilidad ayuda a los equipos a ver cómo un requisito se conecta con decisiones de diseño, supuestos, procedimientos de prueba, evidencia y estado. Cuando el trabajo reutilizado pasa a un nuevo proyecto, esos vínculos facilitan ver qué sigue siendo válido y qué puede necesitar revisión.