See listMAY 17 196767-FM1-39FM/Deputy ChiefA new spacecraft computer program development working philosophy is taking shape
It's becoming evident that we are entering a new epoch regarding develop- ment of spacecraft computer programs, and I thought I'd try to put my impression relating to this into words and get them out in the open.
Until a few months ago, our most basic problem was getting the spacecraft computer programs – and ultimately the flight ropes – completed in time to support the official flight schedule. This presented such a challenge to the people involved that intense reluctance was created to making changes and, after a certain point, even correcting known deficiencies in the programs. Where necessary, work around procedures were invented as the only possible solution. Since the January accident the situation has changed considerably in two ways. First of all, the flight schedule has slipped to an extent that computer program development no longer paces the flights in any way (including crew training and system tests) and, secondly, the value of quality has become supreme. These things are most clearly evident right now on LM-I where it's almost unthinkable to fly with any known deficiencies in the program – even those which would only affect very low probability contingency situations – in spite of the fact that the flight ropes have already been manufactured. I feel it's quite likely the decision will be made to rework the LM-1 program and remanu- facture ropes regardless of impact on any of MIT's program development work, including delivery of the manned mission computer programs. In fact, we have asked MIT to determine the extent of this across-the-board impact assuming all of the known deficiencies in the LM-1 program are removed, no matter how minor. Much more significant, however, is that without doubt this situation is forcing us to adopt a new working philosophy which should be recognized and included in all of our planning – program development schedules, man loading, crew training, spacecraft systems tests, etc. It is clear that, as Ed Copps puts it, program “shelf life” is very short. That is, it is extremely unlikely we will ever fly with ropes manufactured substantially in advance of the mission; instead of releasing the flight program for rope manufacture at the earliest possible date we should release it at the latest possible date.
The next question to be answered is – how far should the work on these assemblies proceed before being frozen (if you call slush “frozen”) and put on the shelf until some key milestone associated with spacecraft flight readiness? Should complete flight qualification Level 5 testing be carried out with the realization that changes will come along forcing us to revise the program and thus to repeat substantial portions of the flight verification? Or should we merely carry the program development through Level 4 testing, resulting in an assembly on the shelf which is bug free as far as we know, but which has not been completely flight qualified? There are arguments for both positions. We have asked MIT to consider this subject – program development working philosophy – and to recommend their preference. We here at MSC will do the same and within a month will be prepared to adopt what appears to be the best over-all compromise. In any case, I'm sure it will force us to maintain a larger MIT staff and more program development facilities in order to be in a position to maintain and modify these programs until we finally release them. And we are less likely to have to throw sets of ropes in the garbage can so often.
I'm not trying to flag this all out as a big problem area. It should certainly be easier to handle than our previous “schedule is king – anything is better than nothing” type of problem. But I'm sure what we do will have some fairly significant implications on everyone involved in the business of program development as well as the various users of their product and I thought it worthwhile to bring it to your attention.