
The software problem which delayed the first Shuttle orbital flight [pdf] - jsnell
https://www5.in.tum.de/~huckle/space_.pdf
======
gmueckl
Interesting read! I like how the final request foreshadows the creation of
agile software development techniques. But as far as I know the shuttle
software stayed with a classic linear development model (waterfall or V
model?).

Agile development is tough in embedded systems. Test automation only works up
to a point. Integration and system testing turns into a monstrosity requiring
hardware in the loop. And there are the inevitable failure modes that need to
be caught reliably, but can only be simulated by modifying the hardware under
test (I.e. manual testing). All of this means that no purely iterative
model.is going to work. You must have discrete testing phases in your project.
And in theory they need to be redone entirely before every iterative update
that gets into production.

Right now, testing efforts are reduced by doing impact analysis of the changes
and reducing the scope of the tests to affected portions of the code. But this
requires the impact analysis to be perfect and without omissions. This article
nicely shows how an impact analysis can be wrong, causing major issues down
the road from a simple change (a single, seemingly unrelated changed
constant).

------
jey
Has the BFS ever been used in flight?

~~~
sitharus
No, the BFS was never used as there were only single-unit failures of the main
computer (which used a quorum system with 4 machines running identical code).

edit: NASA writeup on the reliability of the computers:
[https://www.nasa.gov/mission_pages/shuttle/flyout/flyfeature...](https://www.nasa.gov/mission_pages/shuttle/flyout/flyfeature_shuttlecomputers.html)

