Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
CHAPTER 111 Tec 1no Oslo Cal Considerations To achieve an effective SSA process in the future, a number of applicable technologies will need to be exploited. In this chapter the panel con- siders those technologies. Indeed, the panel's evaluation of computer technologies has been developed at such length that it has been placed in the Appendix--though this is not intended to diminish its importance. While it is obvious that semiconductor technologies and data base and system software techniques are central to the total system design, it may be less obvious how important to system design are the considerations of modeling, Communications, user terminals, applications software, and human factors. These topics are examined here. INTERFACING AND MODELING The panel strongly supports the SSA planning group in its intentions to (1) emphasize system modularity in the architecture and design of the future system and (2) employ advanced modeling techniques as a means of formulating, communicating, testing, and updating the plan for the future process from the architecture phase through design, implementation, transition, evolution, and evaluation. The essential role of modularity in dividing a very large system into subsystems and components of compre- hensible and manageable proportions was discussed in Chapter II. Here the panel relates the concept of modularity, including the specification of definite interfaces among the subsystem and component modules, to the notion of modeling and provides specific explanation of the use of modeling. System Modularity in Relation to Interfacing and Modeling 27 The essential idea of modularity is to subdivide a large and complex system into parts that interact with one another across well-defined interfaces. The specifications for the parts should be functional and relate to the needs of people, as well as be free of implementation details. The specifications are cast in terms of types and amounts of information, clearly describable transformations of information, allowable time delays, and constraints imposed by privacy and security considerations. If a module must be complex internally
2g in order to realize simple interfacing with other modules, the complex module can itself be further subdivided. There is no theorem stating that repeated subdivisions must ultimately result in simple modules with simple interfaces. But practical experience suggests that such is indeed the case. After discussion with the GAS planners, the panel has concluded that a basic tenet of the future SSA system should be modularity at all levels. The interfaces among the modules need to be clear and definite. The best way to determine whether an interface specification is clear is to try to program it.* If the interfaces can be represented in computer-program form, as a software system of data plus processing procedures, it is vir- tually certain that the modules as well as their interconnections can be modeled. When used for system modeling, interface specifications provide a description of the system that actually works to design. There is no guarantee that if the model operates well, the actual process or system will do equally well. Still, there are two conditions that are construc- tive: (1) If the model does not operate well, neither wi 1 1 the actual system;-* and ~ 2 ~ if the model behaves well and the actual system turns out not to do so, the trouble probably lies in the implementation of the modeled specifications and not in the specifications themselves. Modeling Methods and Techniques The modeling that the panel envisions as a fundamental part of the development of the future system is not the routine application of some single, magical technique that is available to solve all the operational problems of the SSA. Indeed, there are many methods and techniques ~ The future SSA system has a number of prospective subsystems that could profit from well conceived modeling techniques. Examples of such sub- systems are the operation of the data base under various conditions; the flow of clients and workloads at a field office; and the operation of the nationwide communications network under a range of traffic loads. It will take expert judgment plus experimentation to select the appro- priate techniques and adapt them to the situation. All the methods and techniques start with problem definition, which must be guided by systemic modularity and must yield good interface specifications. For modeling the interactions and interrelationships at the upper levels of the future system--that is, for macroscopic modeling--there x The specification must also be "sufficiently complete." Because the specification is abstract, it will not be complete in the full detail of actual) ty. Programing does not provide a demonstration of "sufficient completeness, " but it creates a clear and definite representation with respect to which experts can make good judgments about completeness. *^Barring accidental compensations in which design errors are corrected by implementation errors.
29 are two promising approaches: (1) "dynamic modeling" by programming in a high-level function-application language such as LISP or APL and (2) 'simulating" by programming in a simulation language such as DYNAMO, GASP, GPSS, SIMSCRIPT, or SIMULA. At lower levels--for microscopic modeling--those two approaches continue to work. Here, more specialized techniques enter the picture. Finite state machine methodology, as applied by IBM on a fairly large scale in the development of its system network architecture, and Petri Nets, as developed at Applied Data Research, Inc., the University of Michigan, and M.I.T., seem especially promising for certain applications. Applications of Modeling In the most ambitious application of modeling to a computer-infor- mation system development program such as the one under consideration, the model could be used to represent the concept, architecture, design, schedule, medium of communication, and conditions in which actual components are first tested. The model also would be the setting in which prospective users first become acquainted with the new process/ system and trained in its use. The grand model would be updated as each decision is made to modify the design or refine the developmental schedule, and as each step of implementation is taken that provides a more certain measure of performance. From the earliest phases of planning onward, there would be a running model of the process/system and something like a dynamic PERT chart of its developmental situation. The process of development would then be essentially the perfection of the grand model, and the process of implementation would be essen- tially its realization. System developers in the information industries are adopting the methodology just described. Even so, it would be rather risky just yet to put all the future eggs into one dynamically modeled basket. The model might turn out to be harder to develop than the actuality. The panel, therefore, stops short--but only a little short--of recommending a switch to a revolutionary new scheme of model-based development. It supports, in particular, the plans for task and job modeling that have been developed in connection with the human factors test and evaluation facility, and it urges that major efforts be made in all of the following areas of modeling: 0 comparisons of alternative architectures, including various distributions and centralizations; · dynamic representation of process and system designs at various levels; modeling of human interaction, through terminals and hard copy, with the computer-communications system; communications network modeling;
30 computer-based scheduling and reporting of progress; · computer-based cost projections, reporting, and analysis; and . use of models in education and training of prospective users. The idea is to give modeling a real chance to overcome some of the chaos and confusion that have beset the development of large and complex information systems in the past. Wherever it is unproductive, the modeling effort should be examined carefully to make sure that it has been genuine, but there is no absolute need to press on with it, because more conventional methods can be employed as back-up. At the very least, a major modeling effort would put a great deal of the development work on-line in a large time-shared computer-- an essential prerequisite for the successful prosecution of a large developmental program like that of the SSA. COMMON ICAT ION S SSA Communications Requirements The SSA's future communications requirements fall basically into the following four categories: · High-speed, high-capacity communications facilities between major computer/data base storage centers. · Medium or low speed, low capacity communications facilities between SSA district offices and the major computer facilities (this may include low capacity facilities to communications "hubbing points," from which high capacity facilities would be used to the computer facilities). Mobile communications (low speed) for field operations. SSA administrative networks (voice grade communications facili- ties) between all locations. Decisions about major system alternatives (regional versus central data base), as well as about how much information is to be transferred between SSA facilities, will have a significant impact on the final communications requirements and network design. For example, if only one major computer facility (with associated single data base) is required, the design of the communication network, placement of communi- cations nodes, interconnection of facilities via high-speed data lines , will be different than the design of a communications network to interconnect several major computer facilities with multiple data bases.
31 SSA Future System Communications Solutions _ In broad terms, the SSA has the following options for meeting the complex communications needs of the future process: Build a complete communications system from scratch (construct a microwave system, launch satellites, and so forth). Bootstrap the SSA requirements onto another major government- owned network. · Procure raw facilities or services from common carriers and design and develop a configuration of its own communications network by procuring the appropriate terminal/communications processors, multiplex equipment, etc. As part of this option, different types of raw facilities would be considered, including digital facilities (DDS), analog facilities (private line, WATS, MTS), bandwidth facilities, and so on. Procure complete data network capabilities from value-added type common carriers. Procure complete integrated system capabilities from a carriers Some of the alternatives may be eliminated readily. For example, SSA would be hard-put to justify the cost of pursuing the first alter- native. Start-up and continuing operational costs of a privately owned communications network would be prohibitive based on any traffic projections for the SSA's future system. Similarly, the second alternative would require a significant amount of interaction and cooperation WIth another agency. At Ends come, ~c Is unlikely that this option would merit consideration, except for continued use of the Federal Telecommunications System (FTS). The panel recommends that the comunications system design be struc- tured as a separate and identifiable task and be concerned only with the last three possible options, except as noted above. The final approach to the network design will depend to a large extent on (1) an evaluation of the current network (SSADARS) and (2) how much of the day-to-day operational responsibility and management the SSA wants to assume over the network. At the present time, SSA utilizes the government FTS system for most of its administrative communications. Although the panel is not suggesting that SSA look toward a separate administrative network, it is important to note that once a large, sophisticated data network is put in place, it is possible to incorporate voice communications into that same network. Communications-Related Software Requirements Problems relating to the software and computers associated with the network design will be dependent, to a large degree, on whether SSA
32 decides to procure complete raw facilities and design and implement the network using an in-house staff or to procure services from a vendor with an in-place data network (so-called value-added facilities). In the latter case, most of the infra-network design and software will already exist. The most fundamental concern in software design for a communications network is that of its interfaces and protocols with the future system and associated applications. Although the level of sophistication in the terminals (or terminal clusters) of the future system can have some impact, the panel recommends that the communications network be treated as a "transparent conduit." In this context, the word conduit is not meant to imply raw facilities or physical pipes. Rather, the network would be transparent when viewed from the applications programs perspec- tive. More specifically, the applications programs and software systems will perform their functions completely separate from the communications network. Information to be transmitted will be "handed off" to the network; the application programs will not be concerned with network operational functions, such as the particular routing, and data speed. The concept of separating the network from the applications, as proposed by the panel, is similar to that utilized within industry. Impact of Communications Technology No major technological development in communications is needed to meet the implementation requirements of SSA's proposed future system. Although communications breakthroughs will certainly come in the form of fiber optics, say, and lasers, none are required to meet the SSA require- ments. Today's communications systems knowledge and hardware capability are adequate to meet SSA future needs in any desired design concept. The network design problem and the required technology associated with the SSA future system are comparable to those of several industrial organizations that have existing networks. New developments in the field of communications could, however, improve the future SSA process. Therefore, the network design by SSA should remain flexible in the early days of implementation. Further- more, the system should not be planned around communications systems or facilities that are so special in nature (whether they exist today or are proposed for the future) that the communications network design would dominate the system design. The network should be so structured conceptually as to allow future changes which may be beneficial. Other technological considerations include: . It is assumed that the "price-per-unit-of-information-trans- ferred" will decrease in the future. This will happen even though the price of raw facilities and/or the cost of communications equipment will probably increase. This implies that, even though the relative cost of the communications system is small when compared to the overall cost of the future
33 system, the communications cost should decrease as technology advance s e o Different communications systems should be considered to meet different needs . For example, facsimile broadcast and/or video transmission may suggest that satellite links serve as an effec- tive communications mode, whereas other transmission facilities may be considered for other communications needs O Specific technologies may enhance specific solutions to meet the SSA's requirements . @' Security considerations will be an important factor in the design of the communications system. Parse 1 Recommends t ion The future SSA commune cations network should be a widely dispel sea, sophisticated, highly interactive system that enables hi gh transmission reliability, minimum cost ~ adaptable lity to terminal and host equipment types, and flexibility in call set-up and data transport. The data com- munications network that best satisfies these requirements has the Following characteristics: It makes use of a packet-trans~iss~on technology with error detection/correction protocols to satisfy reliability and cost considerations. It is a hybrid switching network supporting both line and packet switching and permitting an economical choice of the best mode of communications. It has features that facilitate communications among a wide range of incompatible terminals and Computers with differing protocols, formats, speeds, and codes. The 'abbe of communications network that the panel believes SSA should develop is illustrated in figure ~ (page 34~. Terminals and/or d~s~ribntea p-ocess'ng locations may be connected to the switching node &i rectly or via multi-party lines, depending on the volumes of traffic and the economics of the network. The node would adapt to the protocol and speed or the interacting terminal. The network consists of high speed lines utilizing ~ packet-type protocol in a full-duplex mode. Link-by-~nk error detection and correction is inherent. Each node matches the protocol of ~ he host complex and uses high speed lines to utilize the hos'_ comer ex' s capability efficiently. The network inher- ently provi des speed and protocol converse on for connections between non-co~pacib~'e terminals ~ An attenuate approach which is an extension of this concept, has been proposed for possible consideration. This approach incorporates
34 i) At\ Q Cal in , . ~ O I ~ by'` 1 ~ I ~,1 c o ._ ._ C ~ .' Qua DC O° 1- _0- By\ O_ \ \ \ \ \ \ ~ Q i, o: ~ \ 0 O '~0 I ~ / ,~ \ a, ~ w ·_ CL · ~ ·= C, O Q a, a.= a, I J Z \ \ \/ 'a ~ O UJ ° 4- A, ~ C., To o LL A \ ~ J \ / ~0 I ~ ~ FIGURE 5 Data Oriented Network
35 all terminal interaction functions into the basic design of the communi- cations network. The communications nodes would poll the terminals, provide terminal screen formats and other terminal entry aids, edit the data before transmitting to the host, and store and accumulate data for later delivery, if this is required. Summary The panel has the following observations and recommendations in the area of the future communications subsystem design: . . The design effort for the communications subsystem should be a separate and identifiable design task. Interface points, appropriate protocol, etc., should be established and coordina- ted with the main system design effort. The network design effort could be structured to have a short term positive impact on SSA's current communications needs and then evolve to meet the requirements of the future system. The communications subsystem should be designed so that it can be supported by today's communications capabilities rather than be dependent on communications systems or technologies that may be developed in the future. · The communications network should not be the driving factor in the design of the SSA system, but rather the future system should be designed with major concern directed toward the data base, computer facilities, and work force. The communications system should be designed as a separate effort to serve the rest of the system. The communications system and network should be structured as a transparent conduit that transmits the informa- tion required by the future system. The design should be compatible with the SSA functional systems and applications design. A decision, for example, as to whether the future sys- tem should be structured around regional computer centers and a regional data base organization should be dictated by the functional and operational requirements of the future system and not by the design of the communications network. · The cost of the communications system is not a dominant factor in the overall future system design and should not bias any major considerations, such as regionalized data base storage. The communications system design can be adapted to any concept without significant cost variations, particularly as related to the overall cost of this project.
36 TERMINALS SSA Considerations A key element in SSA's future system will be the selection of the actual setting in which the end terminals will be used. The decision to place a terminal on every desk would provide fingertip access to the full system. However, because of the expense and the possible adverse human reaction, this approach should be evaluated against other alterna- tives, such as shared and off-line use in conjunction with a modified interviewer interface with the client. Optical character input could offer a middle-of-the-road approach in which traditional forms are processed for entry into the system at the conclusion of an interview. Display quality, function, and price of the terminal are obvious tradeoffs. Color could be effective for highlighting the information to be presented. Some limited graphic capability could be useful for preparation of reports. The choice of printers (thermal, ink jet, mechanical) and display (storage, refresh) will be influenced by the terminal's planned location in an office, because noise and lighting must be considered. Convenience and high volume print capability may dictate that different types of printers be used for different functions within the same facility. The degree to which system functions are distributed will affect the need for storage and programmable intelligence at local work stations. In considering terminal specifications, many factors need attention, including line protocols for network attachment, reliability, alternate backup procedures to cover power failures, and support programming. In addition, serious consideration should be given to procuring communica- tions software and developing only application code. Data privacy and security must be addressed explicitly. Data access limitations and data encryption during transmission are sensitive aspects in overall system design that will have an impact on terminal selection, use, and features. Terminal placement must provide at least the same degree of confidentiality as does today's client/interviewer method. A degree of commonality among work stations is desirable. SSA may decide to design a minimal configuration for all offices, and to use standard enhancement features to achieve functional capability in excess of that provided by the basic work station. Current Status Today's available, off the shelf terminals range widely from simple hard copy typewriter devices to highly interactive cathode-ray tube displays. Configurations can range from central processor-dependent, host-connected devices to self-contained, user-programmable clusters with their own disk, tape, and cassette storage peripherals, capable of off-line, store-and-forward, or interactive use. Attachable alter- natives range from plug-compatible units interchangeable among several suppliers to unique channel or teleprocessing connections. User programmability can be restricted to a central processor, distributed to
37 an intermediate controller or minicomputer separated from the central host or contained in the terminal work station. Terminal logic can vary from hardwired to microprocessor control. Display devices offer a wide range of features, built-in functions, price ranges, and connection protocols. While monochrome or black and white displays have been available for many years, some vendors now offer color capability. Screen sizes vary from the smaller sizes of 100 to 200 characters, through medium sizes capable of displaying several hundred characters, to larger sizes capable of displaying several thousand characters. Cathode-ray tubes are most prevalent, although plasma or gas panel displays are available. Both alphanumeric and graphic displays are widely available. Channel attachments for high speed or teleprocessing capability for remote work station use are geographic and performance choices. Functions such as scrolling, split screen, formating, multiple character fonts, upper and lower case fonts, large type fonts, text editing, and field checking can be provided by the terminal itself or by central host/minicomputer programming. Associated with the display are various input/output devices. For hard copy output, this permits the use of matrix, ink jet, thermal, or line printers which attach to the display, controller, or computer. Light pens are a popular interactive input medium. Optical scanners are available for direct input of pre-printed or hand-lettered forms, as are mark sense and magnetic readers. Keyboard input can be a standard typewriter or a special purpose unit. Support programming systems abound. COBOL, RPG, FORTRAN, and PL/1 are readily available, as are many unique, special languages. Data base and inquiry program products support a wide variety of display terminals. Access method, communications control, and network management programs are available so that users can concentrate upon developing application programs without having to acquire special talent for the specialized communications tasks. Diagnostic programs are also available to aid in isolating fault. Anticipated Trends Terminal prices are likely to continue to decline, both in terms of actual dollars and of increased functions for the same or moderately higher costs. Intelligent microprocessor-controlled displays will further obscure the distinction between controller and display as intelligence shifts increasingly to the display terminal. The trend toward intelli- gent work stations should also result in suppliers offering additional terminal functions with increased possibility of user customization. Color and mixed alphanumeric-graphic features are expected to become more widespread. Improvements in lines, speeds, and network support will make large networks practical for more users. Technology advances will be evolutionary. Plasma technology offers the potential for more compact, lower-powered display terminals, but cathode ray tubes should dominate. Electroluminescent, light-emitting diode, liquid crystal, and deformographic technologies are among those
38 that could move from research to development status for specialized display usage late in this decade or in the next. Increased screen content, as well as physically larger viewing areas or projection dis- plays, are anticipated. Image density will improve and image usage should increase. However, new display devices should remain compatible with previously obtained computer attachments and programming support. Use of optical character readers for input and mixed graphic/image alphanumeric applications should grow in the foreseeable future. The major commercial thrust will increasingly emphasize broader system support. Extensive programming support, coupled with functions customized to the user and created by unique microcode, should further simplify incorporation of terminal stations into major computer networks. The most significant advances in display stations should come in color cathode-ray tube (CRT) displays--both in quality and price as well as in the peripherals--especially local storage media that can be attached to a terminal. Bubble technology holds the prospect of non-volatile electronic memory in terminals to complement mechanical media such as disk, tape, and cassettes. APPLICATIONS SOFTWARE Some 300 years ago the English philosopher John Locke, seeking to explain the adaptability of human behavior, referred to the human mind as a tabula rasa, a blank slate on which the impressions received from daily experience are engraved. Today, to use a metaphor in tech- nology, this concept can be employed to describe that most malleable of machines--the computer. Probably the most significant characteristic of computers is their programmability--their functional performance can be tailored to specific information processing tasks. This tailoring is brought about by the patterns and sequences of instructions known as computer programs. Thus, the objectives of a data processing system are achieved by way of its programs and through their integration with each other and with new data. In order to realize these objectives, it is necessary to define the goals of the system and to take the steps that are best calculated to achieve them. One cannot tell whether a system is successful until one first translates the concept into functional characteristics for which standards of success have been defined, and then establishes an appropriate organization and methodology to ensure that the standards are applied to the system's development. Systems that have been designed with every expectation of success have turned out unsuccessful in operation, or have even had to be dis- carded before implementation was achieved. Such unfortunate experiences result from limiting success criteria to (1) those that are most easily quantifiable--namely, the project cost and duration, (2) the conditions existing at the time the system was initally conceived, and (3) the operations of the computer system itself, with the consequent exclusion of the external and particularly the human environment.
39 The existence of these limitations can adversely affect the rele- vance, efficiency, and maintainability of the system. Some specific illustrations follow. System Relevance The principal prerequisite for program relevance is a realistic detailed description of the functional requirements the programs are intended to satisfy. It is imperative that management appreciates its necessity and that this task be completed before program design is undertaken. This is even more important in the development of on-line systems than it is to those operating in the batch mode. In batch system development, a reasonable though somewhat artificial interface exists between the operations of an office and its often physically remote computer systems. In on-line systems, on the other hand, computer operations are essentially fused with those of the office. Such matters as the sequence in which data is entered, the degree to which the terminal operator looks to the computer for assistance, the degree to which such assistance is provided by the computer program by prompting and other techniques are matters of joint and equal concern to the programmer and to the office personnel. The definition of functional requirements and the design of the programs that satisfy those require- ments are much more intimately intertwined than is true in batch systems. This coupling must be explicitly defined in the initial development phase when functional requirements are being examined. Only through such definition can adequate information be made available to the computer system designers and programmers and the relevance of system operations be assured. System designs for on-line systems are likely to be much more lengthy and detailed than a batch system-oriented management is likely to expect or appreciate. The added time and cost must be understood and supported, if the subsequent program products are to achieve the desired degree of operational success. One must consider the individuals involved and their everyday operations. They are no longer outside the computer system, looking in. They are an integral part of it. It often happens that the performance requirements of a system are limited to those that exist at the time a study is undertaken. Existing requirements are necessary, but hardly ever sufficient. Changes in requirements are not only inevitable, but are likely to occur at an accelerating rate in the future. A successful system is dynamtc-- constantly compatible with such changes under varying conditions. Yet, inestimable amounts of money have been spent in modifying systems to expand a data record by only one position to accommodate an increased range of data values, because the system designer had not anticipated that it would ever be needed. The SSA should plan to accommodate as wide a range of changes as possible. System relevance is not merely a goal to be achieved, it is to be an essential characteristic of the SSA system throughout its useful life.
40 System Efficiency - Overall system efficiency generally has meant the maximum use of systems resources such as machine cycles, memory, secondary storage, and communications lines. With the increasing development of interactive programs, attention must also be given to the more productive use of the human resources involved. In on-line systems, office operations and computer operations are so integrated that neither one can be performed efficiently without the other. Efficient organization of instructions within a computer program is for naught if the terminal operator does not understand what is expected. Similarly, office operations cannot be conducted efficiently if the computer operations with which they are intertwined are slow or inefficient. Such mutual efficiency is called the "man-machine interface." It is likely to be achieved only by the direct introduction of operating personnel into the design process. Systems must be efficient from the users' points of view as well as the computer' s. The arbitration of situations where these demands conflict must be viewed as one of the project management's most impor- tant responsibilities. Maintainability . _ System maintenance may be defined as the attempt to preserve or improve the accuracy and efficiency of a system in the face of newly discovered or newly altered circumstances. A rule of systems develop- ment is that maintenance is unavoidable, but should be minimized. It -is usually costly and time-consuming to perform. Maintenance may be minimized in either of two ways: (1) by ensuring immunity from changes that can be foreseen and avoided initially, and (2) by ensuring responsiveness to changes that cannot be avoided or foreseen. The key to successful software maintenance, in other words, lies in the original design and concept of the system. Much can be done at the outset to make the system easy or difficult to maintain. Therefore, maintenance should be considered as an integral part of the initial system design. Some of the principal factors to be considered: o The more flexible a program is to begin with, the less mainte- nance it will require later. Such flexibility can be attained only by a clear definition of what each program is to do, combined with a full test of the program to ensure that its actual operation conforms with its planned performance. It is also generally true that the simpler a program is, the more likely it is to remain relevant. Unfortunately, it is often the case that the more skillful the programming personnel are, the less likely they are to content themselves with writing simple programs. It is important for the system designer to observe the principle that the simplest of several possible solutions to a problem is the best. Assurance of such simplicity requires systematic application of the many
41 o practices that have been developed for the simplification of program development. These include, the use of "top-down" and structured design and programming techniques, the use of table- driven programs, the isolation of highly variable data and specialized functions in self-contained and easily accessible and modifiable modules. The important consideration, however, is that such principles not only be enunciated, but that their practice be institutionalized. Programming standards and practices are often pronounced with great fanfare. Equally necessary, but often absent, are strong management support and a technique for rewarding adherence or penalizing indifference to these principles by programmers and designers. While it is important to minimize the need to change programs it is equally important to ensure responsiveness to changes that need to be made. Even the most perceptive of system designers will be unable to anticipate all innovations --' changes that may occur. It is imperative that appropriate resources be quickly available for such accommodation. One resource is detailed system and program documentation. This must be complete and uniform so that a general familiarity with its character can be established easily. The structure of programs must reflect the same general approach so that each program does not become a new mystery to unravel. One of the very serious problems in program maintenance is the time it takes the maintenance programmer to understand what has to be done before he can correct the problem or make the necessary change. This can be minimized by making the original code simple and uniform. Maintainability will be enhanced by other factors as well: o Use of a single commonly employed high level computer language, such as COBOL. It is essential to use a language that is commonly known and for which expert programmers can be acquired easily and inexpensively. Also, it is important to avoid the use of different languages for related programs, lest a programmer be required who knows all of the languages involved. Continuity of program operation will be fostered by the continuity of the personnel associated with the project. If the people who design a system are per- mitted to turn it over when implemented to a separate group of maintenance personnel, a substantial volume of invariably undocumented knowledge will be lost. The incentive to implement a program properly will be increased if the responsibility for its maintenance . ..,
42 is shouldered, at least in part, by the project developers. The panel recognizes that on a project of the scale of the SSA process, with much of the programming possibly being done by contract personnel, it will be difficult to maintain continuity. However, continuity should be considered carefully when staff- ing for key program tasks. In recent years, the line separating vendor-supplied system control programs from user-written application programs has become increasingly blurred. At the same time, the data processing services used by applications programs have become increasingly complex. Programs can be made obsolete not only by changes in functional requirements but also by changes in the hardware and system software environment in which the programs are executed. Maintenance operations can be greatly facilitated if application program interfaces with such system software are isolated and standard- ized. Summary: System Synthesis and the Role of Project Management Before a system can achieve success, the criteria for its success must be defined. In defining these criteria,~it is necessary to include . .. .. . standards of success other than those that are easily quantifiable. Success must be measurable in the external context in which the system operates and, in particular, in light of the activities performed by the people who interact with the system. This context, furthermore, needs to be considered as subject to constant change. The panel recommends, therefore, that the SSA design the system to be programmed to anticipate change whenever possible and to be quickly responsive to change even when it cannot be anticipated. Part of this can be achieved by ensuring that the system design embraces the entire operational setting of which the computer system is but a part, includ- ing people, management, and procedures. Part can also be achieved by the judicious selection of the facilities and techniques used to construct the computer system. Normally, such functions fall under the general rubric of systems analysis. Successful systems operation demands as well, however, that systems synthesis be performed--that the multiple objectives and requirements be considered together so that while all are achieved, none is addressed at the expense of the others and that full weight is given to system accuracy, efficiency and maintainability. This task of systems synthesis is a highly important responsibility of the managers of data processing systems. In most cases, it will be found that these desiderata co-exist in an almost symbiotic relationship. A system that is designed to satisfy high standards of accuracy and efficiency also will generally be one
43 that is easy to maintain. In addition, a system that is easy to maintain is likely to operate accurately and ef f iciently. Trade-off situations will occasionally be encountered in which the achievement at one objective must be subordinated to the achievement of another. For example, program efficiency may suggest one approach while considerations of program maintainability will encourage another. Also, the privacy and security of system data are issues of great public concern. While emphasis must be given to these concerns, and necessary measures enacted to regulate strictly the access to the system data' such measures can affect the efficiency of system operations. It is critical, therefore, that the managers of system software development be conscious of the existence of such tradeoffs and that the manner and reasons for resolving the matters be explicitly documented Accordingly, management must stipulate the ob jectives of the process and their interrelationships. It must also employ sampling techniques and other tools of quality assurance and performance measurement both during and after the development period to ensure that the objectives are both understood and realized.