Skip to content

Instantly share code, notes, and snippets.

@christianchristensen
Created January 13, 2012 04:42
Show Gist options
  • Save christianchristensen/1604726 to your computer and use it in GitHub Desktop.
Save christianchristensen/1604726 to your computer and use it in GitHub Desktop.

No longer would programs be declared complete in order to meet schedules, requiring the users to work around errors. Instead quality would be the primary consideration. - Tindall to multiple addresses, "A New Spacecraft Computer Program Development Working Philosophy is Taking Shape," memo, 67-TM-1-39, May 17, 1967


In the end, the success of the Shuttle's software development was due to the conceptual integrity established by using rigorously maintained requirements documents. The requirements phase is the beginning of the software life cycle, when the actual functions, goals, and user interfaces of the eventual software are determined in full detail. If a team of a thousand workers was asked to set software requirements, chaos would result. On the other hand, if few do the requirements but many can alter them later, then chaos would reign again. The strategy of using a few minds to create the software architecture and interfaces and then ensuring that their ideas and theirs alone are im- plemented, is termed "maintaining conceptual integrity," which is well explained in Frederick C. Brooks' "The Mythical Man Month" other possible solutions, Parten says, "the only right answer is the one you pick and make to work"


The first was a document that "taught" NASA and other contractors how to write requirements for software, how to develop test plans, and how to use functional flow diagrams, among other tools. It seems ironic that Draper was instructing NASA and IBM on such things considering its difficulties in the mid-1960s with the development of the Apollo flight software. It was likely those difficult experiences that helped motivate the MIT engineers to seriously study software techniques and to become, within a very short time, one of the leading centers of software engineering theory. The Draper tutorial included the concept of highly modular software, software that could be "plugged into" the main circuits of the Shuttle. This concept, an application of the idea of interchangeable parts to software, is used in many software systems today, one example being the UNIX*** operating system developed at Bell Laboratories in the 1970s, under which single function software tools can be combined to perform a large variety of functions.


Draper's second contribution was the actual writing of some early Level C requirements as a This version of the Level C documents contained the same components as in the later versions delivered by Rockwell to IBM for coding. Rockwell's editions, however, were much more detailed and complete, reflecting their practical, rather than theoretical, purpose and have been an irritation for IBM. IBM and NASA managers suspect that Rockwell, miffed when the software contract was taken away from them, may have delivered incredibly precise and detailed specifications to the software contractor. These include descriptions of flight events for each major portion of the software, a structure chart of tasks to be done by the software during that major segment, a functional data flowchart, and, for each module, its name, calculations, and operations to be performed, and input and output lists of parameters, the latter already named and accompanied by a short definition, source, precision, and what units each are in.


IBM established a separate line organization for the verification of the Shuttle software. IBM’s overall Shuttle manager has two managers reporting to him, one for design and development, and one for verification and field operations. The verification group has just less than half the members of the development group and uses 35% of the software budget134. There are no managerial or personnel ties to the development group, so the test team can adopt an "adversary relationship" with the development team. The verifiers simply assume that the software is untested when received. In addition, the test team can also attempt to prove that the requirements documents are wrong in cases where the software becomes unworkable. This en- ables them to act as the "conscience" of the entire project.

@christianchristensen
Copy link
Author

@140 -- Ch. 5 ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment