Desarrollo de software para Apollo [cerrado]

¿Cómo se desarrolló el software durante la apolo?

De varias fuentes, se puede deducir que la computadora era un sistema ibm 360, y el idioma era básicamente un dialecto fortran o fortran.

Lo que me gustaría saber, es ¿cómo lo hicieron? ¿Simplemente escribieron o planearon? ¿Hubo críticas? ¿Cómo eran los procedimientos de prueba en ese entonces? ¿Qué editor se utilizó? ¿Había un sistema de control de versiones en el lugar? ¿Cómo se manejó la gestión del cambio?

Lo siento, pero esto es demasiado amplio. Puede comenzar con el informe del Plan de Verificación y Desarrollo de Software de Orientación Apolo de 43 páginas fechado el 4 de octubre de 1967. Luego continúe con Computadoras a bordo de la nave espacial Apolo: La computadora de orientación Apolo: Software en el sitio web de historia de la NASA.
También puede leer sobre Margaret Hamilton , también Su código consiguió humanos en la luna e inventó el propio software y Margaret Hamilton, la ingeniera que llevó el Apolo a la luna . Una búsqueda en la web de algo como el desarrollo de software de apollo debería brindarle mucho más para comenzar.
O, si prefiere que se presente como video, puede darle una vista a Moon Machines: The Navigation Computer . Es un documental (de unos 43 minutos de duración) que describe el desarrollo de la computadora de navegación Apollo, incluido su software.
Sí, demasiado amplio. ¿De qué software estás hablando? ¿A bordo? ¿Control de la misión? los simuladores? ¿Planificación de vuelo?
@OrganicMarble Tienes razón. Mirando de nuevo, sospecho, basándome en la mención del System/360, que OP no está interesado principalmente en el software integrado (que también probablemente se desarrolló en algo que no sea FORTRAN, debido a las limitaciones de las computadoras integradas en particular). Todavía creo que los enlaces ilustran cuán amplia es la pregunta, incluso si se relacionan solo con algunos de los sistemas informáticos que hicieron posibles las misiones Apolo, y posiblemente no con lo que el OP estaba interesado principalmente.
@MichaelKjörling Estoy de acuerdo con todo lo que dijo y vinculó, estaba dirigiendo mi comentario al interrogador, para explicar por qué voté por el cierre.
Mike, podrías comenzar brindando algunas de las fuentes que mencionaste. Eso proporcionaría algo de la especificidad que falta actualmente.
@OrganicMarble Oh, no estaba discutiendo contra ti (en realidad, todo lo contrario). Disculpas si se presentó de esa manera.
@JerardPuckett Me temo que la pregunta aún sería demasiado amplia incluso con citas de las afirmaciones hechas en la pregunta misma. Es simplemente pedir demasiado. Por otro lado, reducir la pregunta a uno de los (seis, según mi cuenta) aspectos mencionados en el párrafo final probablemente podría hacerla lo suficientemente limitada como para justificar la reapertura, en mi opinión.

Respuestas (1)

El sitio de historia de la NASA da muchas de las respuestas a sus preguntas:

Lo que me gustaría saber, es ¿cómo lo hicieron? ¿Simplemente escribieron o planearon? ¿Hubo críticas?

En el programa Apolo, así como en otros programas espaciales con múltiples misiones, el software del sistema y algunos programas de computadora subordinados solo se escriben una vez, con algunas modificaciones para ayudar a integrar el nuevo software. Sin embargo, cada misión genera nuevos requisitos operativos para el software, lo que requiere un diseño que permita el cambio. Desde 1968, cuando los diseñadores utilizaron por primera vez el término ingeniería de software, la conciencia de un ciclo de vida del software que incluye un período prolongado de mantenimiento operativo ha sido una parte integral del desarrollo adecuado del software.

Incluso a principios de la década de 1960, se siguió el ciclo de definición, diseño, codificación, prueba y mantenimiento de requisitos...

¿Cómo eran los procedimientos de prueba en ese entonces? ¿Había un sistema de control de versiones en el lugar? ¿Cómo se manejó la gestión del cambio?

Tres tableros contribuyeron directamente al control del desarrollo de software y hardware de Apollo. La Junta de Control de Configuración de la Nave Espacial Apolo supervisó y evaluó los cambios solicitados en el diseño y la construcción de la propia nave espacial, incluido el sistema de guía y control, del cual formaba parte la computadora. La Junta de Control de Cambios de Procedimientos, presidida por el astronauta jefe Donald K. Slayton, inspeccionó elementos que afectarían el diseño de las interfaces de usuario. La más importante fue la Junta de Control de Configuración de Software, establecida en 1967 en respuesta a los continuos problemas y presidida durante un largo período por Christopher Kraft. Controlaba las modificaciones realizadas en el software de a bordo. Todos los cambios en la especificación existente debían enrutarse a través de esta placa para su resolución. Stan Mann de la NASA comentó que el MIT "

La NASA también desarrolló un conjunto específico de puntos de revisión paralelos al ciclo de desarrollo de software. ...

Los diseñadores desarrollaron los programas utilizando una computadora Honeywell 1800 y luego una IBM 36O, pero nunca con el hardware de vuelo real. Las computadoras de desarrollo generaron un código de objeto binario y una lista. La cinta [44] que contiene el código objeto se probaría y, finalmente, se liberaría para la fabricación del cable central. El listado sirvió como documentación del código.

Para Apollo, el MIT desarrolló un lenguaje especial de orden superior que traducía los programas en una serie de enlaces de subrutinas, que se interpretaban en el momento de la ejecución. Esto fue más lento que un programa de lenguaje ensamblador comparable, pero el lenguaje requirió menos almacenamiento para hacer el mismo trabajo. La instrucción promedio requería dos ciclos de máquina, alrededor de 24 milisegundos, para ejecutarse.

Cualquier software no trivial requiere diseño. Nadie se sienta frente a una computadora y simplemente comienza a escribir si quiere que funcione. Cuando hay vidas humanas en juego, se utilizan procesos más formales. Incluso hoy, cuando escribo scripts de shell, "diseño" escribiendo los comentarios que describen lo que debe suceder en orden. A veces, cada comentario es una sola línea de código, pero más a menudo se convierte en una subrutina... o en un subsistema completo para proyectos no triviales. Tomar notas sobre la marcha es muy importante, ya que todos perdemos ideas mientras dormimos. No esperaría que Apollo pudiera soportar los requisitos de energía para un IBM-360.