L. LEE PRYOR DEVELOPING AND MANAGING A LARGE COMPUTER PROGRAM Successful development of a large computer program requires careful planning and coordination. The mana.gement t~ch~iques described in this article are the techniques learned during development of the orbIt determInatIon program for the Navy Navigation Satellite System. INTRODUCTION from the fact that the predecessor program, which The development of large computer programs is a survived for 17 years, was coded entirely in assembly management art with its own subtleties. The absence language. It was recognized that the program would of these subtleties is frequently experienced by process all possible data types, e.g., bit string data, managers caught in the software quagmire-software character string data, integers, floating point that is 900;0 "complete," behind schedule, going to numbers. It was also recognized that the vehicle be completed next week ... and then next machine, defined by Brooks' (Chapter 12) as the week . and then next week. Managers who realize machine on which the program would be built, would that adding more people will make bad things get be APL's IBM 360/91. The target machine, defined worse are painfully aware that something has gone as the machine for which the software was being writ­ awry. Just as bad is to have things going well and lose ten,' would be the IBM 360/65. (The IBM 360/65 one or two key people from a software effort. was nearly equivalent in computing power to the then We will describe here our way of implementing operational IBM 7094.) Nevertheless, one objective large computer programs. Our definition of "large" was to develop a program that would be as machine­ -is a program that requires 10 to 20 people several independent as possible. years to complete, e.g., the Orbit Determination Pro­ Programs with a projected lifetime of 10 to 15 gram (OOP) that we wrote for the Navy and that has years undergo continuing stages of maintenance. Ac­ been an ongoing development since 1959. One char­ cordingly, it was desirable to have a program code acteristic of a large computer program is that if it is that would be readable by many users. The system of of any consequence it is never completed. More typi­ the previous generation depended entirely on sequen­ cally, the program continuously evolves in response tial access devices (tapes) and, therefore, had some to changes in the operating environment (changes in obvious limitations (e.g., the data had to be time­ computer hardware, instrumentation, physical ordered, and data and results files had to be syn­ models, print formats, constants, etc.). The program chronized). had best be designed to accommodate change. To do The newer computer systems were oriented toward otherwise is to create a dinosaur having limited direct access devices (disks) and the requirements of evolutionary potential. the program were better served by direct access logic. The current OOP is coded in PL/ llanguage and con­ Hence, the OOP was designed to be file driven and sists of 176 subroutines with about 15,000 source controlled, and presently uses 20 distinct data files. statements. The generated machine instructions are The file-driven nature of the program permits adjust­ about a million bytes on an IBM 3033 computer. A ment of the program to changes in operational condi­ structured overlay scheme permits the program to tions without the need to recompile any source code. run in a region of 600K bytes. A typical orbit com­ New satellites in the constellation or new station putation takes about 10 minutes of 3033 time. On the equipment are examples of new entries in a peripher­ operational computer, an IBM 360/ 65, it executes in al data file. Time-dependent functions that cannot be one hour. The program is supported by seven modeled, such as the position of the earth's axis of "utilities" that are part of the executable program rotation, the ultraviolet activity of the sun, or the ac­ library. The total cost for development of the pro­ tivity index of the earth's magnetic field, are also gram is estimated to be $3 million. kept as data files. Even fundamental constants in the gravity model of the earth (an array of about 900 coefficients) can be changed by means of a data file, DESIGN OBJECTIVES i.e., without disturbing any logic in the program. A number of design objectives were established at It was desirable from an operational standpoint to the beginning of the project. Some probably resulted make the program as automatic as possible. The pro- Vo lume 2, N umber I , 198 1 39 gram must run reliably for 10 orbit computations per four languages are actually needed to implement the day and should not require the attention of computer orbit determination program. Basically, of course, technicians or analysts for routine daily operations. the program is coded in PL/ I. But to run the program A graceful embedding in the operational environ­ one must allocate files and create data sets; run utility ment meant that the program had to have numerous programs; and route output to disk files, printers, or threshold tests and error messages, and that the pro­ card punches. All this requires a knowledge of the gram had to make many decisions internally. Job Control Language. Creation of the program The program was designed (a) to be machine in­ from its subroutine components involves the use of dependent (it would run on a number of PLiI program overlays and if one wishes to be system­ machines); (b) to be readable with a highly­ independent, one must be very careful in the selection segmented code for ease of maintenance; (c) to be file of system modules. These factors require knowledge driven and controlled to permit model changes of the operating system's linkage editor which has its without forcing code changes; and (d) with the target own language (LKED). There are machine language machine and running time in mind. (MACHINE) considerations in the design of data struc­ The selection of language was difficult. We had to tures and choices of input/output methods. In par­ have a higher-level language for readability and ticular, bit string lengths, integer precision, floating machine independence. If there were language limita­ point precision, character string lengths, and struc­ tions, we did not want to compound our problems by ture alignments were chosen to reflect the underlying resorting to a second language for special functions machine language. (see below); we wanted to operate solely in whatever language was chosen. We needed enough efficiency DOCUMENTATION to achieve reasonable running time on our target I t was planned from the beginning that the pro­ machine. "Reasonable" meant that the execution gram listing would be the definitive document on time should not exceed that of the older program. each subroutine. That program listing was aug­ We needed a broad range of input/output methods mented, wherever necessary, with pages of analytical (sequential indexed sequential, direct access) and a text to provide the "complete" program documenta­ broad range of data types. We knew from experience tion. The program documentation evolved along that to control storage allocation we would need pro­ with the program in a series of internal memoranda gram overlay logic. It was considered desirable to that were accumulated in looseleaf notebooks. When have a language that had been defined as a standard. the time came to publish the document for release to Among the candidates at that time, FORTRAN and the user, a final editing of those working papers PL/ I were the major contenders, particularly since the became that document. Moreover, the documenta­ vehicle machine was an IBM 360/91 and those two tion accurately reflected what was programmed. languages were readily available. FORTRAN had Brooks I (p. 169) has pointed out the advantages of 2 3 already been defined to be a national standard • and using self-documenting programs to reduce the need was (and still is) the most widely available higher­ for coordinating two independent media (program level language. But compared to PL/ I, FORTRAN had and document). some limitations: it did not have as much generality in input/output methods, in data types, or in control LANGUAGE-INDEPENDENT STANDARDS of storage allocations. There was pressure from the Orbit determination is primarily a problem of Navy to choose FORTRAN because of its universal ac­ physics and mathematics. Some program standards ceptance. But there was pressure from the program­ and conventions could be adopted independently of mers to choose PLiI because it was felt to be a richer the language chosen and oriented to the analysis language and because it had the compile time facility behind the problem. It is important for the program­ that we saw as a powerful tool in establishing pro­ ming staff to develop its own standards. The staff is gram standards and conventions. PL/ I'S data and in the best position to know what specific standards program structure features, its interrupt handling are needed but, more importantly, developmen,t "on conditions," and greater choice of input/output within the staff provides the strongest motivation to methods made PLiI more attractive than FORTRAN. conform to the standards5 (Section II). These stan­ Finally, the Navy yielded the point and PLiI was ac­ dards were also applied to the assembly-language cepted. Later, PL/ I was also defined to be a national predecessor of the PL/ I Orbit Determination Pro­ standard computer language. 4 gram. Some of the language-independent standards that were adopted are the following: 1. There is a pool of fundamental constants from THE NEED FOR FOUR LANGUAGES which all other constants are derived.