An Early Application Generator and Other Recollections
Barry Boehm, USC
In this paper, I'll focus primarily on a set of experiences I had
in developing an early application generator in the area of rocket flight
mechanics. But I'll begin with some other recollections to indicate what
led up to this work. And I'll end with recollections of some of the
software experiences I've had since.
1. Early Experiences
In early June, 1955, I showed up at the personnel office of General Dynamics - Convair in San Diego, for a summer trainee job after my sophomore year at Harvard. I was a math major, and was very concerned about what math majors did once they grew up. Being an actuary, statistician, or math teacher all seemed pretty dry.
The personnel manager looked at his blackboard, and said, "Hmm, math major. Well, we have summer openings in Structures, Thermodynamics, and the Digital Computer Lab. Why don't you try the Digital Computer Lab?" Luckily for me, the computer field came along just in time to give math majors a fascinating and rewarding lifetime of mathematics-related challenges and applications.
On that first day, my supervisor spent some time explaining what computer programmers did, and then took me on a walking tour through the computer. It was Univac's ERA 1103, with a 12-microsecond-cycle time and a whole 1024 words of main memory, and it occupied most of a large room. But the thing I remember most indelibly was my supervisor's next remark:
"Now listen. We're paying this computer six hundred dollars an hour, and we're paying you two dollars an hour, and I want you to act accordingly."
This was my first exposure to software engineering economics. As behavioral conditioning, it was valuable to me in impressing good habits of desk checking, test planning, and analyzing before coding. But it also created some bad habits -- a preoccupation with saving microseconds, patching object code, etc. -- which took me years to unlearn after the balance of hardware and software costs began to tip the other way.
After a summer at General Dynamics building mathematical routines and paper-tape input-output utilities, I returned to Harvard with an urge to learn more about computers and programming. I also returned with altogether too much confidence in what I had learned already. Harvard's computer laboratory had the original Mark IV computer that Howard Aiken had developed at Harvard, and a recently acquired Univac I. You programmed the Mark IV in absolute octal using instructions which opened gates and sent strings of bits down wires to registers.
My big assignment in my first Harvard computer course, Numerical Analysis, was a classic in optimistic effort estimation. It involved programming a number of numerical algorithms, and entering various data sets to test and compare the algorithms. I rapidly sketched out the program for the algorithms, and assumed I was pretty near complete. However, I hadn't considered that the input-output for the Mark IV required a good deal of complex programming that was significantly different from the ERA 1103's I-O. After a couple of all-nighters, I got most of the cases to run, but my grade in the course went south. It taught me (at the gut level rather than at the intellectual level) that the housekeeping details on a software job generally consume most of the code, and that being a whiz on Computer A didn't mean that you were a whiz on Computer B.
Eventually, I ended up doing some useful software things at Harvard, such as eliminating my job as a Friden calculating-machine operator. I was reducing data on meteor trails for the Harvard College Observatory, and developed a computer program to automate all the calculations. Fortunately, the Observatory found other things for me to do to earn my keep.
During the summer of 1956 and after graduating (still as a math major) in 1957, I went back to programming jobs at General Dynamics. I didn't realize it at the time, but several of the regular-guy programmers and engineers I worked with day-to-day would become heavyweights in the profession. For example, my carpool to work included Bob Price, who became the CEO of Control Data, and Donn Parker, who did a lot of the pioneering work on computer crime and computer ethics. In 1957-58, Parker was the leader of the Fortran movement within General Dynamics. Its adherents came in wearing Fortran T-shirts, and joked about the Neanderthal assembly-language programmers. I was one of the Neanderthals, still believing that Fortran wasted microseconds and restricted my essential access to the machine's registers and exotic instructions.
It was an exciting time to be both in the computer business and the rocket business. One of my assignments involved the Atlas-Mercury astronaut program. The General Dynamics Atlas rocket engineers wanted to put an escape tower on top of the Atlas, that would blast free of the Atlas if it started getting into trouble. They weren't sure that the escape tower would work in all the situations in which it was needed, and I got the job of analyzing it. This involved modifying a big assembly-language simulation of the Atlas rocket, running a lot of cases that might cause problems, and working with the rocket engineers to fix the problem situations. It really made me identify with the astronauts, who were putting their lives on the line that things like this would work. The escape tower did become part of the Atlas-Mercury flight vehicle, but fortunately never had to be used.
Again, I didn't realize it at the time, but the big Atlas rocket simulation program was an early example of domain engineering, software product line architecting, and software reuse. The Atlas rocket product line included a number of options for rocket engines, aerodynamic configurations, and flight guidance algorithms. Their performance could be represented by either mathematical functions, tables, or polynomial approximations to the table values. Led by an unsung hero named Herb Hilton, the team developing the Atlas rocket simulation had encoded the most likely options as numerical sequence numbers. Thus, for example, the rocket engine simulation options were encoded roughly as:
00 - no thrust and fuel flow
01 - constant thrust and fuel flow
02 - constant thrust and fuel flow modified by atmospheric pressure
03 - Atlas V.1 booster thrust and fuel flow tables vs. time
04 - Atlas V.2 booster thrust and fuel flow tables vs. time
05 - etc.
Other sequences covered aerodynamic, guidance, and special output options. Thus, a simple unpowered coasting trajectory with a simple aerodynamic model and no guidance could be represented by the sequence 00-01-00, while an Atlas V.1 booster with simple aerodynamics and a simple guidance scheme would be represented as 03-01-01.
Using this approach, most of the Atlas trajectory analyses desired by the rocket engineers could be accommodated by preparing input cards with these option sequences, plus some general parameters describing the rocket's launch location, initial weight, initial fuel weight, etc. It was also fairly easy to add new standard options. Exotic options, such as the Atlas-Mercury escape tower, involved special programming efforts. But overall, the approach provided great labor savings and rapid service via reuse of the standard Atlas rocket model components.
In 1959, I left General Dynamics and went to the Rand Corporation in Santa Monica, working primarily as an engineering programmer-analyst. My primary motivation was that Rand was willing to have me work full-time while taking graduate courses toward a Ph.D. in math at UCLA (UC-San Diego didn't exist at the time, nor did any computer science departments).
Another major motivation involved Rand's world-class people and research programs. I got to learn linear programming, dynamic programming, and network flow theory from their inventors, George Dantzig, Richard Bellman, and Ray Fulkerson (with the latter two, frequently mixed in with weekend tennis matches). Allen Newell, Cliff Shaw, and Herb Simon were developing the Logic Theorist, IPL-V, and other pioneering artificial intelligence contributions. Another future Nobel Prize winner, Harry Markowitz, was developing the Simscript programming language. Paul Armer, the Computer Sciences Department Head, also sponsored "AI summers" in which people like Marvin Minsky, Ed Feigenbaum, and Dan Bobrow experimented with new AI concepts and floated mind-stretching visions of robotic futures. There were occasional controversial fireworks, such as the summer of 1964 when Hubert Dreyfus came to Rand with his "Alchemy and Artificial Intelligence" challenge.
A team led by Willis Ware had developed the Johnniac computer, named after Rand consultant John von Neumann. Cliff Shaw was using it to develop JOSS (Johnniac Open Shop System), one of the world's first on-line interactive time-sharing systems. Tom Ellis invented the first freehand graphic input device, the Rand Tablet; Gabe Groner developed a robust freehand character recognizer for it. Paul Baran developed his classic 14-report study "On Distributed Communications," which provided the conceptual foundation for packet switching, ArpaNet, and Internet. Experts in large-scale software development such as Pat Haverty were available from the time that Rand spun off System Development Corporation to develop the software for the SAGE system.
My interest in mathematical economics was also stimulated at his time by Rand's pioneering efforts in cost-benefit analysis, systems analysis, game theory, decision theory, and conflict analysis.
My job at this time involved developing computer models for Rand's engineers and physicists. Unlike the Atlas rocket engineers, Rand's rocket engineers did characteristically exotic analyses. Some examples were rockets fired out the side of tall mountains, rockets carried above most of the atmosphere on huge airplanes, and aerospace-planes cruising around converting atmospheric oxygen into rocket fuel before taking off into orbit.
After programming some of these special cases, I had a pretty good idea of how to develop a general-purpose rocket simulation to handle Rand's wide range of analyses. Fortunately, Rand's Engineering Department was interested in having such a program, and this became my main job in 1961. At this point, I'll spent some time describing the resulting rocket domain model and rocket trajectory application generator, as they formed the experience base for things I tried to do more recently with the DARPA Megaprogramming, STARS, and Domain Specific Software Architecture initiatives.
2. Rocket Trajectory Domain Architecting
The first step in domain architecting was to interview the Rand rocket engineers to determine the range of their desired capabilities. These are summarized below by contrasting them with the capabilities of the General Dynamics Atlas rocket model.
It turned out to be feasible to accommodate all of these desired capabilities except the final two, which would have added significant complexity to the system.
Besides the technical capabilities, there were also operational needs to make the program as easy to use and easy to modify as possible. This was also one of my main win conditions, as I would have to do all of the software maintenance myself.
Rand had an IBM 704 computer which ran the Share Operating System. It still ran in batch-sequential mode, in which engineers submitted card-deck inputs and got back printouts either a few hours later or the following morning. It had a number of amenities, such as the ability to compile programs and link them to system or programmer libraries of relocatable object modules. It did not have a job control language, but applications could be programmed to provide multiple simulation runs within a single pass on the computer. The primary programming languages supported were Fortran and COBOL. By this time, I was no longer preoccupied with saving microseconds, and did most of my programming in Fortran. For this program, I chose Fortran both for ease of maintenance and for portability, just in case Rand's next computer might not be assembly-language compatible with the IBM 704.
The users were primarily aerospace engineers. They were not programmers, but were largely willing and able to learn some simple programming constructs if it helped expedite getting their analysis jobs done. They wanted simple, problem-oriented input forms. They wanted the inputs to be concise, but not so concise as to be hard to read (e.g., not 030101). They wanted a good users' manual to explain the inputs, outputs, and control options. They would eventually like graphic outputs, but were satisfied with numerical printouts. They wanted an easily extensible system for their unpredictable new analyses. And they wanted to be able to reuse inputs as files or macros.
Accommodating all of the desired capabilities above appears complicated. Fortunately, the rocket trajectory simulation domain can build on a relatively simple and elegant central domain model:
Based on this domain model, the core domain architecture involved a trajectory initialization step, the central trajectory simulation loop, and a loop-termination step. The initialization step involved the assimilation of input parameters provided by the engineer. This was followed by a loop involving the three steps of the central domain model above; the calculation of rocket forces and attitude angles; the resolution of these forces along the rocket's body axes; and the integration of rates of change to determine the rocket's future position, velocity, attitude, and weight. Finally, the loop was terminated with the use of termination conditions supplied by the engineer. Figure 1 summarizes this core domain architecture.
Figure 1. Rocket Program Core Domain Architecture
The key to the practical success of the core domain architecture
was the set of published interface specifications for the inputs to and
outputs from the Flight Program of propulsion, aerodynamic, guidance, and
other routines specified or supplied by the engineer.
The set of inputs that any flight program subroutine could count on
being available is shown in Table 1. The first quantity is the current
time. The next three quantities are one representation of the rocket's
position. The three quantities v
Table 1 - Quantities automatically furnished to flight program subroutines
The set of outputs that every flight program (combination of
computational subroutines specified by the engineer) was expected to
produce is shown in Table 2. The first three quantities are the components
of the rocket's thrust vector along the body axes (see figure 2). The
second three quantities are the corresponding components of the rocket's
aerodynamic force vector. The third three quantities collect any other
non-gravitational forces, such as solar radiation pressure. The next two
quantities, and , are the angles relating the rocket's body axis to its
velocity vector. The final quantity is the rocket's rate of change of
Table 2 - Quantities supplied by the user's flight program
Figure 2 - Thrust Orientation
Note that the output interface specifications indirectly indicate force quantities that the engineer does not have to specify, such as the gravitational force. Such forces are calculated in the same way across the entire trajectory, and thus are taken care of by the main program (subject to some parameters that the engineer can specify for the entire run).
Also, the input interface specifications indirectly indicate input quantities that the engineer will have to calculate if he or she needs them for subsequent calculations. Examples are the local atmospheric pressure and density, often used for propulsion or aerodynamic calculations, but not automatically furnished because their calculation takes considerable time and is unnecessary for major portions of rocket trajectories above the atmosphere.
The "published interface specifications" were eventually published in a book constituting the users' manual for the program, which was used at its peak by over 50 organizations besides Rand. The book, ROCKET: Rand's Omnibus Calculator of the Kinematics of Earth Trajectories [Boehm, 1964], is the source of several further tables and figures in this paper.
Three examples of propulsion flight program subroutine descriptions are provided in Table 3 to give a feel for their nature. The first one, CONTFL(TH,FL), assumes that the rocket's thrust and fuel flow are constants specified by the values TH and FL. The subroutines are invoked by a standard Fortran CALL statement. Thus, CALL CONTFL(300000., 1000.) specifies a rocket engine which will deliver a constant thrust of 300,000 lb, and a constant fuel flow of 1000 lb/sec. Each standard ROCKET subroutine is described by a common schema specifying the inputs needed which are not automatically furnished via Table 1, the outputs produced, and the action performed by the subroutine.
The second subroutine is TBTFTM(N), which assumes that thrust and fuel flow will be determined from a table as a function of the current time, using Nth order interpolation. The third subroutine, CONTAU(TA,TB), assumes that the rocket engine is offset from the body axis by two angles, sub and sub . It takes the total THRUST determined by subroutines like CONTFL and TBTFTM and distributes it across the three body-axis components TAX, TBT, and TAL expected by the output interface specification in Table 2. Figure 2 is an example illustration [Boehm, 1964, p. 137] showing the definition of the thrust angles and force vector components.
|None||THRUST, total thrust T (lb);
TAX, axial thrust T ||TH, after being modified by the
multiplicative factor C
|THRUST, total thrust T (lb)||TAX,
thrust along A-axis T ||TA and TB are assumed to be
the angles T sub and T sub , in degrees. They are converted to radians and used in Eq. (B-30) to produce the final T
|None|| THRUST, total thrust T (lb);
TAX, axial thrust T ||Tables of T in lb and FF, the positive fuel flow in lb/sec, as functions of
the time t in seconds, are assumed to in table number 2. The subroutine
TABTFL (TIME, N) is then used to produce T and w from t. T
Table 3. Propulsion Flight Program Subroutine Descriptions
3. Integrated Architecting: Control Structures, Data
Structures, and User Interface
The overall architecting process involved elaborating the core domain architecture into a set of control structures, data structures, and user interface capabilities. These were determined by trying to accommodate as many as possible of the desired technical and operational capabilities above without overly compromising performance or ease of use and extension. The process thus involved a simultaneous determination of requirements and system architecture, including iteration of prototypes of the input forms and output formats with the prospective users.
Some of the main control structures involved the support of
simulating multiple options or branches of a trajectory during a single
run. Figure 3 shows the desired capability. For example, an engineer
might want to experiment with range-vs.-payload-weight tradeoffs using more
or less lofted trajectories.
Figure 3 - Trajectory Sections and Branches
In Section 3, two branches are created, using two values of a rocket guidance parameter that will create more or less lofted trajectories. For each of these branches, two further branches are created for Section 4 by varying the rocket's burn time during Section 3. The longer burn times produce trajectories with greater range, but result in less remaining weight for the rocket's payload. The resulting trajectory outputs would enable the engineer to get a feel for the type of trajectory settings best providing the range and payload desired for the rocket's mission.
The overall ROCKET program control structure accommodating the
section and branching capabilities is shown in Figure 4. At the bottom of
Figure 4, it shows that the central trajectory simulation loop from Figure
1 is extended to accommodate the printing of trajectory outputs.
Proceeding upward in Figure 4, there are loops to cover multiple branches,
multiple trajectory sections, and multiple runs per computer pass. The
"Compile Flight Programs" and other initialization activities will be
covered under the User Interface discussion below.
Figure 4 - ROCKET Program Basic Flowchart
The ROCKET data structures relied heavily on the Fortran Global COMMON and EQUIVALENCE capabilities. These have been accurately analyzed as being highly risky and easy-to-misuse data structures [Wulf-Shaw, 1973]. Global COMMON enables any routine to modify a shared variable (e.g., the force of gravity) without anyone else's knowledge. The EQUIVALENCE capability enables the same storage location to have multiple names. This also can create dangerous side effects if one of the names is used to modify a variable which is assumed to be stable under its other name.
However, these capabilities provided powerful support for the services ROCKET needed to provide, and ROCKET used them in ways that reduced the risks of misuse. One such strategy was to provide the data definitions as further published interface specifications, as shown in Figure 5.
The equivalent arrays B and BLOCK at the top of Figure 5 are the storage areas for the ROCKET input block. From the DIMENSION statements further below in Figure 5, we can see that the overall size of the input block was 10,000 words. From other EQUIVALENCE and DIMENSION statements, we can identify particular areas of the input block:
The remainder of the 10,000 input locations were largely used for storing large tables defining atmospheric properties, rocket engine performance, etc.
Various other shared arrays are indicated, such as the H array containing the Section conditions for the current trajectory Section, and the T array containing the variables involved in the numerical integration of the trajectory derivatives (acceleration, velocity, fuel flow, etc.).
Quite a bit of the input and shared-variable areas were provided to
accommodate extra user-defined capabilities. For example, the last 5
spaces in the T area were available for users to specify additional
derivatives they wanted to integrate (e.g., heating rates, pressure
buildups, etc.). These controlled discretionary areas further reduced the
risks of misusing the shared variables.
Figure 5 - ROCKET Program COMMON Package
Locations 0001-0029 accommodate the standard initial conditions and options for the run. Figure 6 indicates that the run will print a sequence number of 101 and operate with a non-oblate (spherical) and non-rotating earth model. It will start at time 0.0 with an altitude of 1426 feet, a weight of 724 pounds, etc.
Locations 0100-0134, 0200-0234, etc. accommodate the standard inputs for Sections 1,2, etc. Locations 0100-0101 and 0200-0201 indicated the Section termination conditions and values: Section 1 will be terminated when the weight (termination condition #2) reaches 395 pounds (when all the fuel is expended). Section 2 will be terminated when the altitude (termination condition #3) reaches 0.
At the bottom, the ROCKET input form provides a set of spare input
fields to enable users to easily extend the program's input capabilities.
Figure 6 - Flight Control Form: Sputsput I
The user interface for specifying the Flight Program used to
"Compute Forces and Angles," as discussed with Figure 1, was as a set of
standardized Fortran subroutines. The Flight Program for the Sputsput I
rocket example is shown in Figure 7.
Figure 7 - Flight Programming Form: Sputsput I
Both Sections 1 and 2 specify a set of atmospheric forces defined by tables of atmospheric density and pressure (TABDPQ), and a constant drag coefficient of 0.4 (CONCAX). Section 1 also specifies a propulsion model involving a constant thrust of 2800 pounds, modified by back pressure of the atmosphere against the engine's nozzle area of 0.1 square feet, and a constant fuel flow of 8 pounds per second (CTHAIR). The direction of the thrust is indicated by a table of thrust angles vs. time (TBTATM).
Having learned something about programming languages and compilers by this time, I was tempted to invent a special-purpose Flight Programming Language and compiler for it, rather than using Fortran capabilities. I decided against this, for the following main reasons:
Figure 8 - Sample Output: Sputsput I
The outputs were the most awkward part of the ROCKET user interface. The engineers were accustomed to reading them, and engineering assistants were generally available to turn the results into graphs, but a graphical output capability was much needed. I will summarize a followon user-interactive program, Graphic ROCKET, a bit below.
4. ROCKET Development and Usage
The overall ROCKET development took 6 months of roughly full-time
effort. About 4 months involved architecting, which included prototypes of
key capabilities. Coding and integrating took about a month, as did
testing. Testing of complex numerical programs is quite difficult; one
large trajectory program operated for two years before it was discovered
that one minor gravitational parameter had been entered with a positive
rather than a negative sign.
For ROCKET, there were several trajectory programs I could use for test oracles, such as the General Dynamics Atlas simulation, an Aerospace Corp. rocket simulator, and some special-purpose models I had done at Rand. Fortunately these initial tests picked up the serious defects in the program. The residual defects found during ROCKET usage were special cases which gave quite obviously erroneous outputs.
After about a year's use of ROCKET at Rand, I prepared an export version for the IBM SHARE users' group library. Before exporting it, I did the equivalent of a Post-Deployment Review. This picked up a number of shortfalls. For example, I had written a "Common Pitfalls" section of the users' manual, including such advice as "Don't leave the rocket's initial weight input blank; it will make the weight equal to zero and cause an abort when the program tries to compute a = F/m." On review, it made a lot more sense to just test for such inputs before starting the simulation.
Eventually, the program was used regularly at over 50 installations. It turned out to be quite portable, running on IBM (7000 and 360 series), Control Data, DEC, GE, Honeywell, and Univac machines. It was not a big burden to maintain, although there were occasional peaks of activity to add new capabilities, such as aerodynamic heating and non-stationary trackers.
"Experience with the ROCKET program suggests the following conclusions for developers of similar large general-purpose computer programs:
5. Some Followons: Graphic ROCKET and POGO
John Rieber, Vivian Lamb and I developed Graphic ROCKET in 1966-1967. It ran on a dedicated IBM 360-40 that Rand was using for interactive graphics research for ARPA. Graphic input-output was done via an IBM 2250 display with both light-pen and freehand Rand Tablet inputs, plus a Stromberg-Carlson SC-4060 graphic output device.
Figure 9 shows the general nature of the user interaction, and
Figure 10 shows an example input screen with the counterpart of the
Sputsput I propulsion inputs. The program turned out to be quite popular
with Rand engineers, but not very popular elsewhere. The main reason was
economics. At Rand, the engineers were research subjects operating on a
paid-for computer. Elsewhere, IBM 360-40 prime-shift time cost $50/hour, a
difficult figure to justify when engineering assistants were paid around
Figure 9 - User Viewing Graphic ROCKET Display
Figure 10 - Graphic ROCKET Display, Showing Section 1 Propulsion System
For comparison, the Conclusions from an early paper on Graphic ROCKET [Boehm-Rieber, 1967] are provided below.
Conclusions 1 and 2 provide some rationale for benefits and savings due to interactive operation, but this rationale was not sufficiently persuasive for most organizations. Conclusions 3 and 5 are the strongest in retrospect. I was particularly surprised by the amount of breakage in converting ROCKET to Graphic ROCKET. Some capabilities, such as branching, just weren't needed. Others needed total reorganization, such as batch vs. interactive input validation.
After a few months of doing this, we decided to use the Rand Tablet's dragging and dropping features to develop a screen-building and modifying capability for Graphic ROCKET. At the time, we were limited to using integers to indicate where to place parameters when a user entered them into an input slot, and where to transfer control when a box was clicked on. But with the ability to move the slots and boxes around, even this level of capability improved our maintenance productivity by more than a factor of 2.
It turned out that there were other Rand models and simulations that were looking for easy ways to develop interactive graphic interfaces. Se we packaged the screen-builder and -linker capability with Graphic ROCKET's curve-display capabilities to provide a support tool for such applications. The result was POGO, the Programmer-Oriented Graphic Operation [Boehm-Lamb-Mobley-Rieber, 1969]. It was used to provide graphic user interface (GUI) capabilities for several Rand models, particularly in the medical area.
Figure 11 - Function Key Overlay for "DESIGN" Program
1. Most of the functions in Figure 11 are reasonably self-explanatory. The POGO paper's explanations for some of the functions are given below.
2. Touch-Up - The console is placed in the character recognition mode. The user may modify any character on the screen by writing over it freehand with the tablet stylus.
3. Move - The user points to the character string or geometric entity he wants to move with the tablet stylus and drags it around the screen with the stylus until it is in the desired position. Lifting the stylus completes the action.
7. Values - The user points with the stylus to define a place to store the value of a variable; the position is denoted by underscores.
8 Fancy Boxes - These are similar to plain boxes, except that they have a dot at the center to serve as a target for the light pen.
9. Insert Codes - By each box and each "values" position in the current display, the user is presented with a line of underscores to furnish a numerical code that will identify this box or value to his FORTRAN control program.
12. System Gronk - If the system becomes unresponsive during a session, POGO will save as much as possible of the programmer's work, and reinitialize the system.
15. Recall Files - These allow the user to recall previously created display for review or modification.
16. Output Display - POGO asks the user to provide a name for the current display. When this is done, POGO punches out a set of cards with the information necessary to re-create the display and identify its components to the FORTRAN control routines.
The Output Display function illustrates the primitive nature of the linkage between the POGO GUI composition mode and the GUI execution mode: a set of punched cards to be read by the GUI execution control programs. As with ROCKET and Graphic ROCKET, these linkages were defined by open published interfaces, to enable GUI designers to develop and integrate GUI capabilities not included in the POGO capability set.
Figure 12 - Initial Conditions Page for POGO Example
The five slots for entering initial condition values are created and positioned using the Values, Insert Codes, and Move buttons. The numbers 1,2,3,4, and 14 in the slots indicate the positions in the POGO standard input parameter array D into which user-supplied values would be placed. Thus, during execution, if a user entered the number 5.0 in the top slot for "Initial time," POGO would convert it to floating point format and store it in location D(1). The programmer's Fortran execution-control program would then use this value (5.0 minutes) as the initial time for starting the fluid balance simulation program.
The remaining boxes define the user's control buttons. These were created and positioned using the Plain Boxes, Small or Large Characters, Insert Codes, and Move buttons. The number 500 was always keyed to a POGO program called SAVAL which checked the validity of the user's parameter inputs, converted them, and stored them in the D array. The numbers above 1000 were sequence numbers for the Fortran subroutines supplied by the programmer to perform the functions indicated in the boxes' titles (input curves; input control parameters; compute and display; quit). In the POGO execution mode, if a user selected one of the boxes, control would then be transferred to the appropriate programmer-supplied subroutine.
"Total development time for POGO to date has been approximately one man-year. Machine usage on the 360/40 was about 100 hours for development. As mentioned above, the ability to bootstrap some curve input and output pages with the DESIGN program reduced the development time by approximately two months and made these pages much easier to modify.
On the Graphic ROCKET application, the POGO DESIGN page is estimated to have cut control-page development times by factors of four to ten below those required for the manual layout-paper approach. Also, the work is far more palatable, and the error rate is virtually nil.
The most important consequence of the above factors is that they have allowed more response in providing users with additional capabilities not in the basic Graphic ROCKET package. On most interactive graphic systems this extension-threshold is quite high and constitutes a major usage bottleneck.
If any reason for this exists, it must be due to a tendency to design complete interactive graphics systems by deductive inference from an abstract model of typical user performance at a console; this produces "closed" systems that are quite responsive in the small (when the system is on the air), but quite unresponsive in the large (when trying to extend or modify the system). Experience with Graphic ROCKET and POGO users indicates that general characterizations of user activity are still quite risky, and that more overall responsiveness is gained by the prototype approach: deliberately designing an austere but extendable prototype and refining it by inductive inference from observed usage patterns."
The final conclusion on GUI prototyping is similar to Conclusion 5 of the Graphic ROCKET paper. This conclusion came back to the fore in the late 1970's and early 1980's, when I was trying to figure out why TRW's waterfall model worked well for batch programs and ran into trouble on interactive programs. This eventually led to TRW's experimentation with user interface prototyping and the Spiral Model [Boehm, 1988].
For similar economic reasons to those for Graphic ROCKET, POGO was little-used outside Rand. It was only about 10 years later that similar GUI-builders began to be economically feasible at TRW and elsewhere on machines like the DEC VAX, and about 10 years after that before the term "GUI builder" became widespread through emerging PC capabilities.
6. Broader Lessons Learned : Domain Engineering, DARPA, and Megaprogramming
A broader set of lessons I learned from the ROCKET, Graphic ROCKET,
and POGO experiences involved the power of domain engineering and domain
architecting in achieving savings via software reuse. The domains could be
oriented around applications, such as rocket trajectory simulation, or
around support elements, such as GUI's.
There was a negative part of these lessons learned as well. My experiences with the IBM SHARE library involved successful sharing of Fortran mathematical subroutines as well as ROCKET, and I was convinced that many more software programs could be successfully shared. This led to my developing a catalog of potentially reusable software programs at Rand [Boehm, 1966].
Unfortunately, the programs in the Rand Computer Program Catalog did not get reused very much at all. In trying to analyze why, I discovered how many incompatible assumptions could be built into software programs. Some of the reasons for failure became clear to me somewhat later when I read Larry Constantine's excellent analysis of module cohesion and coupling as critical success factors for software reuse [Constantine, 1967].
But beyond these general criteria, it appeared that there were further keys to domain-specific reuse involved with shared assumptions and domain-specific interface specifications. These were worked out for the ROCKET components, but were absent for the programs in the Rand Catalog.
From time to time afterwards, I came upon people and organizations who had developed domain architectures and successful associated software component libraries, such as Toshiba in industrial process control [Matsumoto, 1984], Raytheon in business data processing [Lanergan-Grasso, 1984], and a signal processing group at TRW in the 1980's led by Lyndon Hardy and Roger Vossler.
These experiences came to the fore again when I went to DARPA in 1989 and was looking for themes for the DARPA software research and technology program. They provided an experience base and example set of success stories for the DARPA Megaprogrmming initiative [Boehm-Scherlis, 1992], the Domain Specific Software Architectures program [Mettala-Graham, 1992], and the domain-oriented reuse component of the STARS program [Kramer-Foreman, 1992-96]. These in turn led to the successful establishment of larger DoD initiatives such as the Army Software Reuse Initiative [Hess, 1992] and the DoD Software Reuse Initiative [Reifer, 1994].
7. Epilogue : My Efforts to Get Out of the Software Business
While I was developing Graphic ROCKET and POGO, I was also trying
hard to get out of the software business. As interesting as these general
solutions were, they were basically providing services to engineers and
system analysts. These systems people were working the real-world decision
issues, and got to formulate the technical problems rather than just react
to them via programming solutions. At the time, it seemed to me that they
were doing much more useful and satisfying things than programmers were.
Eventually, I got into doing command and control system studies. Some were for exotic satellite command and control systems whose titles were even security-classified. Others were for urban systems such as the New York City Fire Department. Another involved applying Paul Baran's packet-switching ideas to make a survivable command and control system for the Minuteman ICBM system (Coincidentally, my wife Sharla had developed the original packet-switched network simulation with Paul Baran [Baran-Boehm, 1964]). This packet-switching analysis activity got me involved in the initial ARPAnet Working Group, and many of the ARPAnet Pioneers such as Larry Roberts, Frank Heart, Bob Kahn, Len Kleinrock, Vint Cerf, and Steve Crocker.
The original expectation was that the biggest gaps were in such areas as supercomputing and large screen displays. But, as the study went on, it was increasingly clear that the Air Force's biggest command and control information processing problems were in the software area. The Strategic Air Command's 465L system software had to be 95% redone to make it operationally useful. The Ballistic Missile Early Warning System software identified the rising moon as a Soviet missile attack. Software caused numerous long delays in cutover of new command and control systems. Software errors dumped $50 million satellites into the ocean.
A good many of the software rework and delay problems needed management solutions more than technical solutions. On the other hand, CCIP-85 had briefings on some new and exciting software engineering technologies that addressed many of the critical software needs. Dan Teichroew's emerging PSL/PSA system had great potential for addressing the Air Force's software requirements problems. Harlan Mills briefed us on the exciting software productivity and reliability results IBM was getting with structured programming technology on the New York Times project. Eldred Nelson and John Brown briefed us on TRW's suite of automated test tools, and Win Royce's waterfall model. Jules Schwartz presented SDC's early efforts in building and using an integrated software development environment. IBM, TRW, and SDC also had some early quantitative data on how those techniques affected software cost ad quality.
As the study went on, I found that the problem of producing software for large mission-critical systems was very important for both national defense and industrial competitiveness. At the same time, there were a number of exciting new software technology and management approaches coming along which looked as if they could be orchestrated into good solutions [Boehm, 1973].
It was enough to draw me back into the software business. By 1973, I had left Rand and joined TRW as their Director of Software Research and Technology. My charter was to come up with an integrated set of procedures, methods, and tools which would bring the software problem under control.
At the time, I remember estimating that it would take a good 5 years to do this. It was not the first or the last software underestimate I've made. Twenty three years later, we've made a lot of progress, but the magnitude of the software problem seems to grow as fast as our ability to develop solutions. But the challenge is still as important, exciting, and fun as ever. I feel incredibly lucky to have happened onto the software engineering field so near its inception, and to have shared its challenges with so many of its outstanding pioneers.
[Baran-Boehm, 1964]. P. Baran and S.P. Boehm, "On Distributed Communications, II : Digital Simulation of Hot-Potato Message Routing in a Broadband Distributed Communications Network," The Rand Corporation, RM-3103-PR, August 1964.
[Boehm, 1964]. B.W. Boehm, ROCKET : Rand's Omnibus Calculator of the Kinematics of Earth Trajectories, Prentice-Hall, 1964.
[Boehm, 1965]. B.W. Boehm, "Developing and Usage of the ROCKET Trajectory Program," Proceedings, Design Automation Working Group Conference, June, 1965.
[Boehm, 1966]. B.W. Boehm, "Rand Computer Program Catalog," The Rand Corporation, D-14653, April 1966.
[Boehm-Rieber, 1967]. B.W. Boehm and J.E. Rieber, "Graphical Aids to Aerospace Vehicle Mission Analysis," Proceedings, AIAA Annual Meeting, October 1967.
[Boehm et al, 1969]. B.W. Boehm, V.R. Lamb, R.L. Mobley, and J.E. Rieber, "POGO: Programmer-Oriented Graphics Operation," Proceedings, SJCC 1969, AFIPS, May 1969, pp. 321-330.
[Boehm, 1973]. B.W. Boehm, "Software and Its Impact: A Quantitative Assessment," Datamation, May 1973, pp. 48-59.
[Boehm, 1988]. B.W. Boehm, "A Spiral Model of Software Development and Enhancement," Computer, May 1988, pp. 61-72.
[Boehm-Scherlis, 1992]. B.W. Boehm and W.L. Scherlis, "Megaprogramming," Proceedings, DARPA Software Conference, April 1992, pp. 63-82.
[Constantine, 1967]. L.L. Constantine, Concepts in Program Design, Information and Systems Press, Cambridge, MA 1967.
[Hess, 1992]. J. Hess, "Army Software Reuse Plan," U.S. Army, 1992.
[Kramer-Foreman, 1992-96]. J. Kramer and J. Foreman, STARS Newsletter, DARPA, 1992-96.
[Lanergan-Grasso, 1984]. R.G. Lanergan and C.A. Grasso, "Software Engineering with Reusable Design and Code," IEEE Trans SW Engr, SE-10(5), 498-501, Sept. 1984.
[Matsumoto, 1984]. Y. Matsumoto, "Some Experience in Promoting Reusable Software: Presentation in Higher Abstract Levels," IEEE Trans SW Engr, SE-10(5), 502-512, Sept. 1984.
[Mettala-Graham, 1992]. E. Mettala and M.H. Graham, "The Domain-Specific Software Architecture Program," Proceedings, DARPA Software Conference, April 1992, pp. 204-210.
[Parnas, 1979]. D.L. Parnas, "Designing Software for Ease of Extension and Contraction," IEEE Trans. SW Engr., March 1979, pp. 128-137.
[Reifer, 1994]. D.J. Reifer, "DoD Software Reuse Plan," DISA, 1994.
[Wulf-Shaw, 1973]. W.A. Wulf and M. Shaw, "Global Variables Considered Harmful," ACM SIGPLAN Notices, Feb. 1973, pp. 28-34.