COMPUTER-AIDED SOFTWARE DEVELOPMENT

Daniel Teichroew, Ernest Allen Hershey III, and Yuzo Yamamoto

ISDOS Project, University of Michigan, Ann Arbor, Michigan, USA.

Beizer, Holzman, and Kent (1975).

Abstract 1.1.1 Classification of Systems. The terms such as systems, information systems, information In recent years, as the hardware cost/capability processing systems are used with widely different ratio has continued to decrease and as much of the meanings. The meanings in which they are used in routine data processing has been computerized, the this paper are defined in this section and emphasis in software development has shifted from illustrated in the example in Figure 1.1.1. just getting systems operational to the maintenance of existing systems, reduction of Organization duplication by integration, selective addition of new applications, systems that are more usable, An organization is a legal entity, or sub-unit of maintainable, portable and reliable and to a legal entity, that is uniquely and specifically improving the productivity of software developers. identifiable. Usually an Information System is a part of an organization which has a basic function This paper examines a number of trends that are other than information processing. In Figure changing the methods by which software is being 1.1.1 the example of an organization is a produced and used. More and more of the research Manufacturing Enterprise. and development is now being directed towards producing systems that have the desirable Organizational SHb-systemS properties mentioned above. Also, more computer-aided tools are being developed and made An organization may have a number of sub-systems available. The most important trend probably is which are used to accomplish, or contribute to the the introduction of software development support accomplishment, of the basic function. One of facilities which provide an integrated set of these subsystems is an Information System. In tools, based on a central computerized data base. Figure 1.1.1, the Manufacturing Enterprise has At this stage, these systems perform primarily sub-systems such as Production, Logistics, clerical work but gradually their facilities are Distribution, Finance, etc. being expanded. A number of research and development efforts are concerned with moving Information Systems closer to the ultimate objective of producing executable software for a particular computing The Information System is the sub-system of an environment directly from a set of functional organization in which information (in the form of requirements. data) is received, recorded, processed, stored, retrieved and transmitted. The Information System A large part of the software developed today is may consist of an informal system and (formal) still custom built to meet a specific set of Information Processing Systems. The informal requirements in a specific computing environment. system consists of all the information processing Considerable effort is being directed towards in which data is not recorded. reducing the amount of software that must be newly produced each time by making use of software that Information Processing Systems already exists. The subsystems of the Information System in which Many of the concepts and techniques in which these data are recorded and processed following a formal developments are based are not new. Many tools procedure are called Information Processing are available but are not widely used. The Systems. Two kinds of Information Processing availability of technology does not necessarily Systems may be distinquished: manual and mean that it will be used. Some of the reasons computer-based. Manual systems are those in which for this are examined as a basis for the all operations are performed manually. consideration of issues involved in practical Computer-based information processing systems are application of new system development technology. those in which some operations (though not necessarily all) are performed by a computer. 1. Software Environment Since this paper is primarily concerned with computer-based systems, the term Information 1.1 Computer Based Information Processing Systems Processing System will be used to refer to alia. Related Terminology Computer-based Information Processing Systems. Each Information Processing System consists of Large amounts of resources are being devoted to some non-computerized procedures, a data base, development and maintenance of computer based application software, and a computing system as information processing systems, i.e., systems that indicated in Figure 1.1.1. include hardware, software and other components. Much of the concern with the efficiency and 1.1.2 Classification of Software. Software effectiveness of these systems today is focused on may be subdivided into components at various the software e.g., "software is the problem". levels: System, subsystem, module, and statement. This paper is primarily concerned with software development, however it is desirable to first Software System. A software system is a place software in its proper context within collection of software components that, if used systems. Terminology is not yet standard in this together, accomplish a complete information field, and it is therefore necessary to start with processing function. a number of definitions. In general these are consistent with those used in the recent Software Subsystem. A software subsystem is a encyclopedias by Ralston and Meek (1976) and part of software system that, if used together,

- 189 - accomplishes a separately defined part of the product. This differs from the simple whole software system's function. In very complex program in all of the above ways. It costs software systems it may be useful to distinguish nine times as much. But it is the truly more than one level of software subsystems. useful object, the intended product of most system programming efforts." Software Components. Software components are parts of software system that constitute basic Software is frequently classified as either system individual units such as programs, routines, software or application software. System Software1 subroutines, modules, units of data description is used during the execution of other software; and executable modules. it includes operating systems, monitors, etc. It is necessary because the application software Software Module. The smallest part of a software cannot run on the raw hardware itself. system that can be utilized by a software Application Software includes software components component at the same or higher level to tailored to the user's needs, including all accomplish a defined function. software products that are not part of system software as defined above. Statement. The smallest self-contained component of a Software System which can be expressed in the The application area that is of most concern in source programming language. this paper is that of software development. All programs supporting the development of software, In a particular system, these definitions can be such as assemblers, compilers, translators, made more specific since they depend on the program generators, design-aid packages and the operating system under which the system is to be like are included in this classification. run and the programming language in which it is written. Since the discussion in this paper is It will be convenient to distinguish between independent of operating systems and programming generalized software and custom-tailored software. languages, the terms system, subsystem module, and Generalized Software is software produced to meet statement will be used with the general meaning the needs of a number of users for the same given above. general application in different organizations and different computing environments. Custom-tailored Software may be classified by its operational Software is software designed to meet specific status. An excellent taxonomy is given by Brooks requirements in a specific situation and for a (1975) Figure 1.1.1: specific environment.

1.2 Environment in Which Software la Developed and "In the upper left of Fig. 1.1.2 is a Used program. It is complete in itself, ready to be run by the author on the system on Since software is developed in many different which it was developed... circumstances and used in many different situations, it is desirable to classify the There are two ways a program can be different cases and to attempt to identify some converted into a more useful, but more parameters which characterize them. Boehm (1976) costly, object. These two ways are p. 1239, considers the application of software represented by the boundaries in the engineering to two areas: diagram. AREA 1 : Detailed design and coding of system Moving down across the horizontal boundary, software by experts in a relatively a program becomes a programming product. economics-independent context. This is a program that can be run, tested, repaired, and extended by anybody. It is AREA 2: Requirements analysis, design, test and usable in many operating environments, for maintenance of applications software by many sets of data... technicians in an economics-driven context.

Promotion of a program to a programming The parameters that he considers in distinguishing product requires its thorough between Areas 1 and 2 are: documentation, so that anyone may use it, fix it, and extend it. As a rule of thumb, - whether the requirements analysis is done before I estimate that a programming product costs or after the at least three times as much as a debugged design and coding start program with the same function. - whether the software is "system" or "application" software Moving across the vertical boundary, a - whether the development is done by software program becomes a component in a experts or by programming system. This is a collection technician programmers of interacting programs, coordinated in - whether (economic) efficiency is relevant or function and disciplined in format, so that not. the assemblage constitutes an entire facility for large tasks... However, he does not consider other parameters which are also important. One of these is the A programming system component costs at least three times as much as a stand-alone program of the same function. The cost may 'System software is usually considered as being be greater if the system has many provided by the hardware manufacturer though components. Dolotta, et al. (1976) predicts a separation between the user's Installation Control Program In the lower right-hand corner of (ICP) and the vensor-supplied System Control Fig. 1.1.2 stands the programming systems Program (SCP).

- 190 - motivation which causes the software to be These produce software primarily to demonstrate produced. There appear to be at least the feasibility rather than to accomplish applications following reasons for organizations to produce in a production environment. State-of-art software: for their own use, for other software is produced by experts primarily for organizations under contract, for sale (or lease) research purposes. In this situation, the to other organizations, to sell a service, to sell software is not intended to be used for hardware, or to carry out research. operational uses, and cost and performance may not be as important as demonstrating feasibility. Another important parameter is the way in which an organization meets its requirements: by buying a The above environments are ones in which a large service, by having a software system developed by amount of software must be produced and maintained others under contract, by purchasing or leasing over a long period of time. During this time the available software, or by developing its own requirements and computing environments may software. change. In such an environment any given software system is difficult to maintain. Further, since The combination of these and other parameters the software is always being changed, it may exist leads to the identification of six major in many versions, each with many releases. environments in which the software problem is important. 1.3 System Development. Software Development sua Software Engineering The Systems Department in. .afi. Organization. The unit in an organization that runs the production 1.3.1 Evolution of System Development operation which produces results for various users Methods. Software development is only one aspect in the organization is frequently called the of Information Processing Systems. It is, Systems Department. Its production facilities therefore, desirable to examine the evolution of include computers, systems software, applications system development because improvements in software, data bases, etc. The department software development must be compatible with the maintains the existing application software and changes in the total environment. also develops new systems. Many new systems involve integration of existing systems. The Initially systems were developed by ad hoc Systems Department may develop new systems, have methods. Such an approach is practical only for systems built under contract or acquire existing very small systems where only few people are systems. involved. Since it is usually not feasible to divide systems into separate, distinct small Organizations which acquire software systems £y_ systems, this approach is not relevant to the contract. This environment is similar to the environments described in section 1.2. previous one in that the software must be maintained. However since the organization did The traditional or classical approach to system not develop the software itself, it must depend on development is the System Life Cycle method based the developer for the documentation that is on a sequence of phases controlled by a project necessary for use and maintenance. management system. The approach, covered in many books and publications, (e.g., Hartman (1968), Software Enterprises. These are organizations Hice, et al. (1974), Metzger (1973)), consists that produce software for others either under of: (1) specifying a number of activities that contract or for sale as standard products. must be carried out, (2) identifying a number of phases with the results to be obtained in each, Companies using software £o_ offer a. service. Such and (3) describing the results, i.e., business services are becoming more common and are documentation, which must be produced at the end predicted to increase, e.g., Seidman (1975): of each phase. Figure 1.3-1» taken from the front "The line between computer services vendors cover of Metzger, illustrates these aspects that and computer equipment vendors is beginning characterize all such methods. Frequently, the to blur. By 1980, most users will be procedures are designed for a particular type of buying solutions to problems instead of system. For example, the O.S. Department of the buying hardware and/or services. In order Navy (1974) has a documentation standard for to deal with the rapidly increasing tactical digital systems. competition at both the high and low revenue ends of the spectrum, computer Even though information systems are a type of services vendors will evolve into system, few applications of systems theory have Multi-Service Vendors (MSV's), selling appeared in the literature. One interesting solutions to users' problems. This will example is the attempt to apply control theory to include, as required, the provision of information systems by Lehman (1969), Belady and hardware, software, and facilities Lehman (1971), and Belady and Lehman (1976). management (FM), in addition to the Their models of the life cycle of systems include traditional remote computing and batch the concepts of releases and versions. Another services currently offered. To the dp example is given by Putman (1977) who analyzes a user, this will mean a greater opportunity Systems Department with many systems in different to get the most efficient and most stages of their life cycle. economical solution to his problem with a minimum of comparison studies and 1-3-2 Software peyelopment. The System installation and integration problems." Life Cycle method usually includes the following activities in software development: Hardware Manufactures. These produce system software, particularly operating systems, and Determination of the requirements that the other software that interfaces directly with software is to accomplish hardware. Design of the software including specification of the major modules Academic, research and development organizations• Design of the individual modules

191 - Programming the individual.modules using the output data to perform its tasks. The Assembling or compiling the programs fourth group, the organization's management. Debugging and testing individual programs consists of persons bearing the overall Integrating and testing the programs as a responsibility for the organization's image and system the organization's economic effectiveness. Among this group are the managers responsible for the The exact procedure that has to be followed in a Systems Department in the organization. particular computing environment depends on the methods used for design, the conventions and 1.4 Software Costs and Other Characteristics standards that have been adopted, the programming language, and the operating system. While it is clearly desirable to "improve" software, in the software field there is as yet no 1.3.3 Software Engineering and Software satisfactory way to measure progress in quality or Production. While the System Life Cycle method is productivity. Currently, the most common measure in widespread use, the model on which it is based is lines of code. Even the basic definition of is too simple for many practical situations today. "code" is subject to interpretation, e.g., does it One improvement which has been proposed is include comment lines? Furthermore, the use of frequently referred to as Software Engineering. this measure as a productivity measure leads to The term has been defined by Boehm (1976) as undesirable results. If a programmer knows that follows: he will be judged by the number of lines of code he will be motivated to avoid the use of macros " SOFTWARE ENGINEER™ ; The practical and libraries, to use low level programming rather application of scientific knowledge in the than higher level statements, and avoid design and construction of computer generalizing code into reusable units because this programs and the associated documentation reduces the number of lines of code and also tends required to develop, operate and maintain to make the resulting code more difficult to them." produce. The lack of satisfactory quantitative and scientific methods and adequate measures is The Software Engineering concept implies a change emphasized in most of the surveys of the state of from preoccupation with programming to a broader the art of information systems. See, for example, view encompassing software (i.e., a collection of Dolotta et al. (1976). interrelated programs), recognition of the need for tradeoffs among a number of criteria and There are also no generally accepted consideration of the applicability of engineering characteristics in which improvements can be practices. However, the term still is too narrow measured. Terms such as reliability, quality, for a comprehensive view of systems since software maintainability, etc. are used without definition is only one part of systems; systems also include or with different definitions by different non-computerized procedures and hardware. The authors. Recently, several efforts have been made non-software or manual procedures include many to define software characteristics and develop a aspects of user interfaces that determine the method for measuring the values of the value of the system to the organization which is characteristics for a particular unit of software. paying for it. See, for example, Boehm (1973), Glib (1976) and Reifer (1976). The characteristics tree developed In this paper, the term "Software Engineering" by Boehm is shown in Figure 1.4.1. Here will be used to describe the initial design and characteristics will be divided into two development of prototype software. The term categories: cost and other. The "other" "Software Production" will be used to describe all characteristics will be classified as in Teichroew the activities necessary to produce software that (1974). is satisfactory for operational use. 1.4.1 Software Cost. Three methods for 1.3.4 Personnel Classification. An reducing the cost of software to the final user important consideration in improvement in software may be considered: development is the personnel associated with systems and their respective roles. Four major Reducing the cost to develop software to groups of personnel involved with can be meet given requirements. This in turn can distinguished: the software personnel, the be accomplished by improving the information processing personnel, the personnel productivity of software developers or by using the target system and the organization's having more of the software developed by management. The software personnel are directly machines at lower cost. involved with the software and are concerned with its development, operation and maintenance. These Reducing the amount of new software which are Software System Designers, Programmers, the must be developed to meet a given software-hardware Operators and Program requirement. Librarians. The second group - the Information processing personnel are concerned with the Producing software which will be used by a development, operation and maintenance of the number of users. The cost to each should entire organization's information processing decrease proportionately to the number of system. These consist of Systems Managers, users. In practice the decrease will not Project Leaders, System Analysts, System be proportionate since some of the cost Architects, Data Base Designers, Data Base such as maintenance increases as the number Administrators, System Operators, Hardware of users increases. Furthermore, obtaining Engineers, Communication Engineers, Project and a number of users to use the same software System Librarians. The third group, the target inevitably requires a marketing effort. system's users. consist of organization's personnel and its customers or customers' One of the difficulties in improving software is personnel. This group is involved with preparing deciding what should be included in the cost of input data, observing the software format and software. It is now being recognized that the

- 192 - cost of a system is much more than the cost of Industries which start with a new product or development. For example, there are costs service go through a life cycle. In the initial involved in training and documentation. It is growth phase, the industry is rapidly expanding also being recognized that development costs may its markets, frequently by expanding the be small relative to maintenance costs during the capability of its produce or service. The life of the system. Decisions on systems are industry reaches maturity when its product can no frequently based on cost of software only, and longer find new markets; it is then limited to the decisions on software are frequently based on replacement market. If that market shrinks development costs only. enough, possibly due to newer products, the industry becomes extinct. 1.4.2 Software Characteristics. Ideally software should have three major types of The computer industry has been evolving and characteristics: accomplishing a given set of clearly is still in a growth phase. The rate of requirements, be efficient in its use of evolution of computers has been very rapid. resources, be easily changeable as the situation Evolution of computers is commonly divided into changes. "generations", each of which centers around a major jump in capability and/or decrease in cost. Achievement of these goals usually involves a The generation concept has been applied to tradeoff since improvement in one may result in hardware, (Withington 1974), operating systems, degredation in others. Systems are built to serve (Denning 1971), EDP management, (Gibson and Nolan organizations. Consequently the systems must 1974), systems development (Benjamin 1972), and accomplish the requirements that are stated by the systems analysis techniques, (Couger 1973, 1974). organization. A first objective, therefore, is to The evolution is still continuing, particularly in build systems that accomplish those requirements. hardware. The cost of hardware to perform a given Requirements are seldom absolute; the organization computation has been decreasing and the relative and its environment change and therefore the cost of hardware to software, in a given system, requirements may change. Also, requirements are has also been decreasing. not independent of cost. There is usually a point beyond which it is not worthwhile to achieve the Since hardware costs have been decreased it is requirement. There is also a tradeoff in the worthwhile to examine the reasons and to see other direction, i.e., as the cost of a system whether the same approach could be applied to decreases the organization becomes more willing to software to reduce the cost of software and at the adapt itself to the system rather than insisting same time improve its quality. on requirements which may cost more. Hardware costs have decreased for three major Many of the techniques considered in this paper reasons: have a potential of reducing the need for the tradeoff by making it easier to change software to Research in the underlying phenomena. This fit a particular situation. resulted in discovery of ways of performing basic operations at much higher speed with 1.5 Improvement ££ Software Development much greater reliability.

The attempts to improve software development arise Differentiation of functions involved in out of the recognition of the need for changes and the hardware system life cycle, and the recognition that improvement is possible. development and use of appropriate mechanized tools for each of the functions. 1.5.1 The Need for Improvement. A number The separate functions that exist in most of studies of the state of software development hardware manufactures are: engineering, have shown that the quantity and quality of prototype development, manufacturing, software being produced is already a limitation on marketing,and maintenance. the effective utilization of computers and that this problem will become even more serious in the Mass production of components and future. Two studies were conducted for the U.S. sub-assemblies. This has permitted Air Force (CCIP-85 and SADPR-85); the first has investment in production facilities to been summarized by Boehm (1973). An extensive reduce the per-unit cost. study has been conducted by the SILT committee of SHARE, Dolotta et al. (1976). IBM has conducted The analogy with software production is not a survey on application development problems perfect and some of the relative costs are (Perry 1975). A general overview of the different. For example, the cost to produce effectiveness and efficiency of System Departments another copy of a program is insignificant whereas is given by Canning (1975). While these studies the cost to produce, for example, another disc contain some quantitative data, comprehensive data drive is not. Nevertheless if one includes all is hard to obtain. (An excellent summary of relevant costs associated with information available data is given by Phister (1976).) processing system the analogy becomes much closer. Development problems sometimes have to be reported as hypothetical situations as in the MUDD report This paper is concerned with the application of (Weiss 1975). One situation where quantitative the concepts in the last two points above data sometimes appears is in situations which have (differentiation of function, and mass production) to be resolved by legal methods. (Wiseman 1976). to software development. In particular Section 2, 3 and 4 describe the tools that might be used in There seems to be no question that improvement in each of the functions in the software system life qualitative characteristics is essential. cycle. Section 5 covers the software analogue of Furthermore the amount of software needed in the mass production; namely the use of existing future cannot be produced by present manual software components. Section 6 discusses the methods (Prywes 1975 and Dolotta 1976). technical, operational and economic feasibility of changing the development of software. Any 1.5.2 Possibilities for Improvement. approach to improving productivity should take

- 193 - into account the evolution occurring in the latter. computer field. On one hand, the type of software that is to be developed and the manner by which Currently much of the software intended for software productivity is measured will be affected operational use is produced under the system life by evolution in hardware. On the other hand, the cycle approach as described in Section 1.3. This investment in software at one stage in the cycle approach has been characterized by the following: may limit the opportunity to make use of new hardware capabilities at another stage. - most software is developed manually with little use of tools other than compilers, One factor affecting productivity is the type of editors, linkers and loaders, and operating systems being built. Systems are becoming large systems. and more complex. Consequently, software development emphasis is on the sharing of - most software has been designed to facilities. However, the increase in the satisfy a particular requirement in a availability of mini-computers has led to particular computer environment. distributed processing which may both make systems smaller and simpler and resource sharing less To improve software development it is necessary to important. One example of the possible changes in be able to identify the characteristics in which software development is indicated by Rigo (1977): improvement is desired and to be able to measure improvement. These characteristics are examined "We have all heard about Citibank's massive in section 1.4. The most important are: conversion to minicomputers. We are now beginning to hear the rest of the story and it involves a lot more than hardware. - to reduce the cost of software to a In somewhat oversimplified form the current particular user situation was recently described like this: * Citibank, one of the world's largest - to improve the degree to which the corporations, is junking all its big IBM functional capabilities meet the users mainframes. needs * It is replacing its big machines with minis - dozens of them, of every make and - to increase the liklihood that the model. software functions correctly and * It has drastically reduced its permanent efficiently. systems and programming staff. For new development, it rents consultants for as A basic premise is that software development and long or short a time as needed. maintenance will change in the following major * It used to take two to five years to ways: design and implement a new system. Now the bank is getting the job done in as little - software development in the future will as six weeks." be aided by coordinated set of tools (manual as well as computer aided). 1.6 Summary and Conclusions - more of the software development will be In the development of software that is to be used done by computers. operationally in computer based information processing systems (see definition in section - the amount of new software, that would 1.1), the emphasis must be on "programming system otherwise have to be produced, will be product" as specified by Brooks (1975), Figure reduced by synthesizing systems out of 1.1.2. existing software modules.

The primary use of programming system products is Interest in improvement originates with the desire in System Departments as defined in Section 1.2. to utilize more fully the potential capability of The environment in which these techniques are most computer and is pursued because there are relevant is one in which a large amount of indications that improvement is possible, as software must be produced and maintained over a indicated in section 1.5. long period of time during which the requirements and computing environment may change. Any given The basic motivation for the approach to software software system in such an environment is large development outlined in this paper is that a with hundreds of modules and tens of thousands of substantial reduction can be obtained in the cost lines of source statement. The software must be of a software system to an individual user while developed and maintained by staff whose membership at the same time making it more reliable and more is also changing. The software may exist in many adaptable to changes in the computing environment. versions each with many releases. Techniques that However, these new approaches will not be adopted are useful in this environment are not appropriate automatically. Some of the reasons why progress for situations in which state-of-art software is has not been faster are examined in section 6. produced by software experts primarily for demonstration purposes. In these situations These considerations lead to the following software is not intended to be used for conclusions: operational uses and does not have to be maintained and cost and performance may not be as important as demonstrating feasibility. - The productivity of software developers should be improved by making use of the Software may be developed by the using computer for data processing activities. organization, by software companies under contract, by software companies for sale or lease - The productivity of software developer or by research institutes. The techniques to be can be further improved by automating as discussed are appropriate to all except the much of the software development and

194 - maintenance as possible. "That's all they found because they didn't - The productivity can also be further do that much testing. We figure that if improved by reducing the amount of new there's only one bug per 10,000 lines of software to be developed. code, then IBM owes us about a million additional lines." A survey of the state of the art of techniques to accomplish these approaches to improvement of Hard to maintain. "Why was it hard to productivity is given to provide the specification maintain? Among other things it was poorly for a Software Support System. The current status parameterized. When the staff attempted to of development along these lines is summarized in introduce a new type of display terminal, the following sections. The tools available for they were horrified to discover that all information processing system development are sorts of modules 'knew' how many lines surveyed and several state of the art approaches there were to a page, for instance, and how to integrating the tools are examined in section many characters per line. It was a major 2. The specification for a software system effort to make the code more general." capable of supporting information processing systems during their entire life cycle "The major drawback is that three or four (development, operation and maintenance) is experts are still required to maintain the outlined in section 3. Section 4 describes code. Ms. Szuch estimates that it takes a approaches to using the computer to develop newcomer about six months to get on board software. Section 5 is concerned with reducing and safely make changes." the amount of new software that must be developed. Efficiency. "It was slow, for one thing, 2. Tools for Software Development, Operation and too slow to be marketable. And when the Maintenance maintenance programmers looked inside to see how to tune it up, they weren't The tools for system development, operation and terribly happy about what they found. The maintenance may be divided into manual tools and upshot was that the system limped along for computer-aided tools. The manual tools are about nine months with only one 'friendly discussed in section 2.1. Computer-aided tools user' (i.e., non-paying), while The New are classified and some of the factors that limit York Times programmers puzzled out the code their use are discussed in section 2.2. The next and hammered it into decent shape. The four subsections describe briefly some attempts to Data Bank is alive and working today, but overcome these limitations: the National Software it has yet to fulfill its original Works in section 2.3, the System Development promise." Laboratories in Section 2.4, the Application Management System in section 2.5 and the Quality of code. "As for the quality of Information Automat in section 2.6. Some the code, the Times programmers found it to conclusions on the use of tools are given in be highly variable. They soon learned to Section 2.7. spot the individual writing styles of different member of the development team. 2.1 Manual Tools 'You could hardly call it "egoless" code'."

The term "manual tools" is intended to cover all Design decisions. "But she is critical of the skills, knowledge, disciplines and procedures some of the design decisions made which, that are used in system development, operation, she says, 'meet the letter of the stated and maintenance. To a large extent these tools requirements but not the spirit.' She have been developed out of necessity in order to suggests that computer professionals have a use the computing hardware and software as they duty to inform users of specifications that have evolved. The tools therefore, are ad hoc and will be regretted later." in many cases have to be learned by experience since they have not been adequately documented. This particular example, of course, does not mean that these Improved Programming Productivity In the last few years considerable attention has techniques should not be used. In fact, practical been directed to the Improved Programming experience with these techniques in many Techniques developed by IBM. These include Chief organizations suggests that they should be Programmer Team organization, Structured Walk adopted, but the desired benefits will not be Through, Program Librarian, Top Down Development obtained unless the means to achieve them are and Structured Programming. These techniques explicitly included. achieved considerable attention as a result of the spectacular results reported by Eaker (1972) when One of the reasons for the lack of adequate manual they were used in a project for the New York tools is that there has as yet been relatively Times. Consequently many organizations have little progress in the investigation of the adopted these methods and consider them underlying phenonema of information systems; there worthwhile. is, in fact, little agreement as to what classes of phenonema are really basic. Wegner (1976), for However, it should be noted that these methods by example, considers themselves do not necessarily lead to software that has all the desirable qualities. This is "the ramifications of four influential indicated by the experience of the New York Times definitions of computer science: with the system produced by IBM, as reported by Plauger (1975): 1. Computer science is the study of phenonema related to computers, Newell, Number of errors. "The developers claimed, Perlis and Simon, (1967). in fact, a record of one bug for every 10,000 lines of delivered code: 2. Computer science is the study of

- 195 - algorithms, Knuth, (1968). aid the application development process. Some installations have over a hundred 3. Computer science is the study of separate products installed but find that information structures, Wegner, (1968). most are used by only a handful of people and many are used only once or twice. It 4. Computer science is the study and appears that there are some problems management of complexity, Dijkstra, associated with the use of the tools (1965)." presently available: 1) poor human factors, He concludes that 2) lack of education and publicity, 3) incompatibilities with installation "these definitions reflect four different standards and other tools, 4) not a part of approaches to the study of computer science an integrated system, 5) specialized nature and has given rise to four very different of some tools (i.e., only good at serving paradigms for computer science research. one particular non-recurring problem) and Computer science is perhaps unique in the 6) unsatisfactory performance (i.e., does diversity of its admissible research not improve productivity of the application paradigms, and this diversity is perhaps development process). In addition, most responsible both for our difficulties in users are not aware of the range of tools deciding how computer scientists should be available, their benefits, and other users trained and for differences of opinion experience with them." concerning the nature of computer science research." The major reasons for the limited usage of tools are: 2.2 Computer-aided Tools - Knowledge of existence. Despite the attempt to Many computer-aided tools for system development, provide directories of existing tools, it is operation and maintenance have been produced. In frequently difficult to determine where a tool particular, there are the compilers, linkers, with the required characteristics for a given task loaders, operating systems, utilities such as exists. sort, which exist in every computing installation of any size. There are also many other tools - Access and availability. A tool may not be intended to aid the development of application available to a person, even if he knows of its software. existence, understands it and wishes to use it, because he does not have access to the computer Each computing facility contains usually only one system on which it is installed. operating system and only one, or very few, compilers. The use of these tools is essential - New languages. In order to use a tool, it is for use of the facility and therefore controlled usually necessary for a person to learn two and enforced. Since the entire operation of the languages. First is the language used by the tool computer facility and portfolio of application itself and second is the operating system or software depends on these tools, there is a great command language. The first is almost always a reluctance to change the basic system software or new language while the second may or may not be. even to allow any way to do it. Unfortunately, either the use of application software development - Interfaces. Most tools have their own input and tools frequently is incompatible with the existing output formats and consequently, each user must system software, or the benefits come from reformat his data to be acceptable to the tool and overcoming the deficiencies of the system then reformat the output if he needs it for software, and therefore, a basic conflict arises. another tool. The problem becomes one of obtaining the benefits from the application software while at the same - Status. Many tools, in the terminology used by time maintaining stability in the system software. Brooks (1975), are "Programs" rather than (The virtual machine concept is one approach to "Programming Systems Products". They have overcoming this dilemma.) Directories of tools to inadequate user documentation and are inadequately aid in the design, development, operation, tested. After a certain amount of trying to use a modification and maintenance of information tool without success, the user may well give up processing systems, have been published, e.g., by and decide the effort to get the tool working is ICP and Datapro. More detailed descriptions have not worth it. also appeared. For example, Naftaly, et al. (1972) have described a number of tools The potential benefit of using tools in systems available to aid development of systems in COBOL; development has lead to a number of attempts to Reifer (1975b) has provided a list of tools overcome these difficulties. These approaches are available in the U.S. Air Force. Several authors characterized here by the degree to which they have attempted to classify available tools: Reifer make use of what already exists. The first (1975a) and Curry (1976). Reifer has developed approach starts with the premise that it must be definitions for the 80 types of tools; the types possible to incorporate existing tools essentially are listed in Appendix 1. unchanged. An example is the National Software Works (Section 2.3). The second approach also All evidence clearly indicates that despite the makes as much use of existing tools as possible existence of many computer-aided tools, very few but attempts to integrate them by providing common are being used and most of these are not used very interfaces. Examples are the Software Development extensively. This conclusion was the opinion of Laboratories described in Section 2.4. A somewhat many at Session L351 of the recent SHARE XLVII similar approach is incorporated in the meeting which was devoted to a "Survey of Application Management System described in Section Facilities for Application Development." The 2.5. The third approach is based on the premise session report contains the following evaluation: that the basic compatibility problems can only be solved by a completely new start. A proposal in "There are hundreds of tools available to this direction is the Information Automat (Section

- 196 - 2.6). operational use for several years is CADES, produced by ICL for support of production and 2.3 national Software Works maintenance of an operating system (Pratten and Snowdon 1976). Davis and Vick (1976) describe the The National Software Works (Figure 2.3.1) is an SDS system which is intended for support of extension of the ARPANET Project, (Braden 1976). development of real time systems. In these The initial objective of the ARPANET was to situations the relevant tools are identified and provide communication among a number of computer some investment is made in making the tools easier centers so that any person having access to one to use by providing standard interfaces and center could use any of the other computing providing standard data base systems. environments. This helped to simplify the access problem but it did not reduce the other Another class of such systems are ones which are difficulties mentioned above. The user must still basically designed as programming development know the existence of a tool and the operating laboratories. These include de Jong (1973), TOPD system command language of the environment on (Henderson and Snowdon 1974), ECL (Wegbreit 1971, which it is located before he can start to use it. Cheatham and Wegbreit 1972), and SL-1 (Gardner, et The National Software Works starts with a premise al. 1976). that the existing tools will remain unchanged and that a "super structure", i.e., a network A proposal for such a system is given by Irvine operating system known as the Works Manager will and Brackett (1976) (Figure 2.4.2). They view be placed on top of the present network. This their SEF (Software Engineering Facility) as Works Manager will allocate resources, control consisting of a System Analyzer, an Interface, a access, handle accounting, and maintain a central Test and Validate Module, and a Report Generator. index of available tools. In addition, each All of these interface with a Software Engineering computing environment will contain a front end Data Base. Other proposals have been made by which is a Command Language Interface to the Works Hamilton and Zeldin (1976), Walters (1977), and Manager. Each host computing environment which Falla, et.al. (1976). contains tools will have an additional software component known as the Foreman that will act as Another example of such a system oriented not so the interface in using the local tools. In much towards software development, but rather addition, each (tool building) host will contain a towards providing application users direct access file package to provide file compatibility. to a number of tools is the GMIS system developed by Donovan (1976). GMIS provides the access This system is currently in development and when through the use of the virtual machine concept and completed will make it easier for users of the through a generalized relational data base ARPANET to use tools at other hosts and will management system. somewhat simplify the interface problems among tools by the file package. However, it does not These software development laboratories form the help to alleviate the problem of each tool having basis for the Software Support System proposed in its own language. In effect, it adds another Section 3. language and command system which a user must learn though this one will hopefully serve him at 2.5 Application Management System (AMS) many hosts so that he can use local tools without having to know the local operating system The Application Management System (AMS) was language. developed by TRES, Inc; user experience is described by Wright (1975) and in the EDP The ARPANET is a research vehicle, most of the Analyzer, Canning (1974). An overview of the hosts are research computing centers and most of system is given in Figure 2.5.1. the users are researchers who are interested in tool development. They are, therefore, less The system consists of four major subsystems. likely to produce Programming System Product Each produces or updates a data base. The first Packages and also are more likely to tolerate the subsystem, the Data Dictionary Generator, accepts limitations of other people's programs when they data definition and produces the Data Dictionary. try to use them. To what extent this experience The second subsystem, the AMS Compiler, uses this will be translatable into a production software Data Dictionary and produces a data base of data environment is not clear. processing modules from statements in a Data Processing Language. This data base together with 2.4 Software Development Laboratories the Data Dictionary is used by the third subsystem, the AMS Configurator, to produce an A number of "laboratories" have been proposed to executable system called the Run Control File. aid software development by providing an The fourth subsystem, the AMS Monitor, executes "integrated" set of tools. These arise in two the Run Control File under the control of the different situations. The first one is a operating system. Each of the subsystems is development group which needs tools and in which controlled by a Control Language and each one also management decides some investment in providing an produces documentation in addition to updating the integrated set of tools is desirable.1 Examples of AMS data bases. this are the DAIS system of the U.S. Air Force, (Ruth 1973) (Figure 2.4.1), the SDL Laboratory Wright (1975) describes the use of AMS in the (Naval Electronics Laboratory Center (1976), and development of two systems LMS and FMS; some the Support Software System described by Crafford, information from his paper is summarized in et al. (1976). An early example is Clear-Caster Appendix 2. (Brown 1969). A system which has been in

1 For an interesting discussion of the role of tool development in large projects, see Brooks 1975, p. 127.

- 197 - 2.6 The Information Automat This, at the present time, is probably a little premature. It is certainly true that the The Information Automat has been proposed by individual components can be constructed. Wilson (1976). (See also Mills and Wilson However, the technology to produce an integrated (1976)). He begins with a premise that all the set of tools still remains to be demonstrated. A support software, including the operating systems, number of approaches are being tried and more have the system utilities, data base management been proposed as the brief summary given in this systems, compilers, etc., have been developed paper shows. independently and each has its own language and its own interfaces. He proposes to develop a The approach followed by the National Software kernel system which will be the central software Works will undoubtedly make it easier for computer surrounding the hardware to provide these services scientists to use tools developed and installed at in an integrated fashion, Hofnagle and Wilson another computer environment. However, it will (1976), (Figure 2.6.1). Surrounding this kernel probably not be directly useful in systems system there will be other layers of support which departments or for software development in which will provide necessary services for application operational software must be produced. development and operation. The basic concept is that one language can serve as the communication The approach implied by the Information Automat is media for all the various services. His kernel no doubt ideal and, if implemented, could result system therefore will provide the basic support both in a substantial decrease of the size of that are now provided by a number of independent software required for a complete set of tools and systems: TSO, JCL, IMS, GIS, FORTRAN, COBOL, PL/I, a substantial decrease in the cost of using the OS/VS, etc. The central concept is a language tools. However, even if it were implemented, known as a "semantic language" which can be used there would be problems with incorporating the at each level for each service. While the already existing software produced under previous vocabulary and the actions will vary, the methods. structure will be the same and hence it will be simpler to learn by all those who have to use it. One way to solve the interface problem is to have the tools work from a common data base. The The fundamental advantage of the approach will be approaches to building programming laboratories to eliminate duplication. Now each tool in the are usually based on the concept of one level of support systems in today's system must have its user using one basic language. To be more useful own language interpreter and analyzer; in the these systems will have to serve a number of Information Automat kernel system only one will be different types of users with a number of required. Similarly, all data base management different language levels. will be done by one program and all the support systems will use the same data base system. This What is likely to be practical and applicable in will eliminate the incompatibility among the the next few years is the concept of a coordinated interfaces of the various support systems. The facility for software development that makes use Information Automat proposal has been described in of existing operating systems and some other some detail in a number of documents, but it has standard software such as data base management not yet been implemented. It is undoubtedly systems. Furthermore, this facility should possible to do so and to produce a system which is provide not only for the development of new much smaller and more compact and easier to use software but also for the maintenance of existing than existing systems. However, the elapsed time applications software. The specification for such and costs required are likely to be large. In a facility are discussed in the next section. addition it is likely to be incompatible with existing systems and would therefore require 3. Software Support Systems (SSS) anyone planning to use it to start afresh with

this system. Existing software tools would have This section outlines the requirements for a to be rewritten to be included. Software Support System (SSS) which would provide a coordinated set of tools for software 2.7 Synmai-Y and Conclusions development, operation and maintenance. The facilities discussed are those necessary to A number of software tools are being developed. develop a new software system to meet a given set However, they are seldom compatible. A user has of requirements in the environments described in to learn each of the tools, prepare the input in section 1. The specifications outlined in this the form needed, and probably have to use the section are based on the analysis of software tools on different computing environments. development systems (some of which are mentioned in Section 2) and on experience with prototypes of Some argue that the software development parts of a system, such as the Problem Statement facilities can now be built, for example, Stillman Analyzer (PSA), Teichroew and Hershey (1977). and Leong-Hong (1975): Then, assuming that a basic Software Support "The technology already exists to construct System exists, the next two sections will describe a software production facility. Its additional methods of decreasing the cost and components, e.g., advanced programming increasing the quality of the completed products. languages, structured programming Section 4 is devoted to methods for reducing the precompilers, dynamic analyzers, amount of software which must be produced manually intelligent text editors and sophisticated by having more of the software produced by the file management systems, are within the computer. Section 5 is concerned with state of the art. What has not been done synthesizing a system out of software which is to identify and develop an effective set already exists, i.e., out of "reusable modules". of tools, integrate them into a single system, and make that system available to a 3.1 Software Support System as â Decision Support broad spectrum of users." System

- 198 - It has become fashionable to characterize certain their own decisions into the Software Support types of information processing systems as System data base and then should be able to obtain Decision Support System. For example, Sprague and the information implied by the above Watson (1977) define them as follows: characteristics of Decision Support System. An overview of the interaction of the various users "Just recently, information systems with with the Software Support System is shown in rather unique characteristics have begun to Figure 3.2.1. emerge. These systems, usually referred to as Decision Support Systems, feature Information Processing Systems management should decision models, a data base and the obtain summary reports describing the status of decision maker as subsystems and are various projects and various systems. The systems specifically oriented to supporting department staff should be able to obtain summary decision making." information necessary for the coordination of various projects, evaluation of new projects, and and state that a determination of the impact of proposed changes. Project Leaders need to obtain relevant data about "Decision Support Systems (DSS) should have projects they manage including both management and the following characteristics. technical data.

1. The DSS is designed specifically to The Analysts should be able to obtain status and support decision making. Attention to checking reports about the data entered into the information flows, report structure, and data base, including its consistency and data base design is specifically related to completeness. After the analysis is completed, this primary objective. they should also obtain the necessary final reports. 2. The DSS is interactive to allow the manager or his representative fast access The System Architect should be able to obtain the to models and data. The interactive description of the overall system with which he is capability is not necessarily to provide concerned and all the information provided by the immediate access to minutes-old data, but, Analysts. The Software Designer should be able to rather, to give access to data and models obtain the requirements produced by the Analysts at a speed which matches the thought as well as the specification produced by the processes of the manager. System Architect. The Programmer should be able to obtain the up to date specification of the 3. The DSS is flexible enough to satisfy programs he is assigned to develop and the source the decision making requirements of many code of programs of similar functions as well as types of managers - those in different reports indicating whether all program branches functional areas, at various managerial were tested against all requirements and whether levels, and with different management the programming documentation is complete. The styles. System Operators should be able to obtain an up to date report on the status and progress of the 4. The DSS is an integrated set of data operated application system (input data and models which allows the models to work preparation, error messages issued, handling of together, and thus avoid suboptimization exceptions, action report handling by the target whenever possible. users). During operations, the Operation Staff should be able to record operations data and 5. The DSS is dynamic enough to keep relate it to the system description. Similarly, itself up to date without major or frequent the Data Base Designer should be able to obtain ad hoc revisions. the requirements for the data base derived by the Analysts and the System Architect. The Data Base 6. The DSS is sophisticated, utilizing Administrator should be able to enforce data base modern information processing and standards and determine the requirements for management science techniques whenever integrated data bases. The Project Librarian and Program Librarian together with the maintenance appropriate." staff, should be able to keep track of all the information regarding the project documentation. The Software Support System proposed in this paper It is their responsibility to maintain a complete can be considered a Decision Support System in the description of the system and a record of changes sense that it supports the decision making by that have been made. Target System Users should System Management (usually a separate department be able to obtain the description of target in an organization), Project Leaders, Analysts, systems that pertain to them. System Architects, Software Designers, Programmers, System Operators, Data Base Designers, Data Base Administrators, Project and 3.3 Data Base Program Librarians, and Target System Users, that is, all personnel associated with information In order to ensure that all the relevant data will processing system and software system development, be available, it will be necessary to store it in use and maintenance. one integrated data base in which the various types of information are separately identified. 3.2 Users Thus, the appropriate subparts of the information can be selected for use by the various One of the most effective ways to ensure that a individuals. As with any data base system, system will be operationally feasible and appropriate controls must be exercised to ensure economically cost effective is to have one system that the integrity of the data base is preserved. provide for all the needs of a set of users whose Individuals must have access to only that part of needs are related. the information that they are entitled to and are able to modify, change or augment only the part of All users should be able to enter the results of the data base which has been authorized for them.

- 199 - The data base structure will be very complex; for operations between a statement of requirements and example, Figure 3.3.1 shows the data structure for the executable system code. The "decision models" a prototype of one sub-subsystem of an Software and decision making aids of the Software Support Support System which is designed for the storage, System will be increased and it will become more manipulation and retrieval of FORTRAN modules. of a Decision Support System.

The methods for producing executable systems from 3.4 Major Subsystems a£ a. Software Support System higher level descriptions may be classified in three ways. One approach to higher level The Software Support System would consist of a definition is to "specify" larger units of the number of major subsystems as shown in Figure system. This concept is discussed in section 4.2. 3.4.1. Another approach is to present the specifications in a form natural to human beings but which can The Requirements Determination System allows also be implementated by computer software. These Analysts and Target System Users to enter data forms are described in section 4.3. The methods describing existing and proposed systems. The by which the executable system is actually software performs various checks and analyses and produced are outlined in section 4.4. Conclusions produces hard copy documentation on request. It on the present state of these methods and trends maintains a data base containing the description in their use are given in section 4.5. of the target system from the "user's point of view". 4.2 isssl SiL Specifications

The Development System allows Architects, Software Software systems generally may be classified as Designers, Data Base Designers and Programmers to described in section 1.1.3. When the current develop and construct a system to accomplish a set general purpose programming languages are used, of requirements recorded in the Requirements Data the structure is completely specified by the Base. This system is divided into two subsystems. programmer and the compiler has very little First, the Software Engineering Facility is freedom in changing the structure. Therefore if designed to permit the rapid and efficient the compiler is to do more of the work it must development of a prototype to demonstrate have more freedom to receive specifications at a feasibility. This is consistent with the higher level. A number of levels are possible; definition of Software Engineering given in here the levels used are system, subsystem, and Section 1.3-3. Second, the Software Production module. System is designed to begin with a prototype system and produce a production version. Specifications given at the system level are functional specifications that state what the The Support System allows software systems to be system is to do but not how it is to do it, at operated and maintained. It is subdivided into least not in a way that constrains the software two systems. The Operations Facility controls the structure. There need, therefore, be no operation of the target system in an actual correspondence between the structure in the environment. It collects statistics that may be specifications and the structure in the software. used to improve performance. The Installation and Maintenance system provides the capability to When specifications are given at the subsystem install the target system in a particular hardware level, each subset of specification will be environment and to maintain it as changes occur. transformed into a software subsystem. One case The Management System allows management to where this occurs is where specifications are maintain plans and obtain data from each of the given in terms of a transaction. The various project and system data bases. It also specification for a given type of transaction are provides for all the coordination necessary among implemented as one subsystem; within a single type projects and systems. of transaction the compiler may choose its own software structure. The Data Base System contains all the data that describe the target systems and the projects. It When specifications are given at the module level, is subdivided into a number of data bases, but the each module is implemented as a software module relevant interconnections among all the subdata and within a module the compiler decides on the bases are maintained. software structure.

4. Reducing JUS. Manual E££ar_t_ jfca fxadjagjE Software 4.3 Form o£ Specification

4.1 Classification OL Methods The form in which requirements are acceptable as input to the computer may be classified as In the discussion in the previous section, it was follows : implicitly assumed that the basic tool for software development was an assembly or higher Natural language. Ideally, any text in a natural level programming language (FORTRAN, COBOL, PL/1, language will be acceptable. The software system ALGOL, PASCAL, etc.). The major purpose of the starts without any knowledge of the problem domain Software Support System was to have the clerical and builds its entire knowledge on what it obtains operations performed by the computer. In from the input. Several systems based on natural addition, the Software Support System performed a languages are discussed by Heidorn (1976). number of checks and provided management information. In essence the software was still Specialized languages. The structure of the input produced manually, though the process was aided by is still natural language but certain words or the computer. This section is concerned with phrases have preassigned meanings to the system. methods by which the software can be produced more These languages are easier to use and the automatically and, therefore, the manual effort specifications are easier to implement but each can be reduced. All of these methods basically language is restricted to a special application attempt to reduce the number and effort of manual field.

- 200 - Relational languages. These languages have processing. Few organizations yet have extensive specific structures and a certain set of reserved capability to input graphical information directly words. Input is free format. Examples are the and, therefore, graphical language input is not Problem Statement Language (Teichroew and Hershey, widely used. This conclusion is also reached by 1976) and Requirements Statement Language (Bell, Rose (1976) in relation to specification of et al. 1977 and Alford 1977). hardware :

Forms. Forms have long been advocated as a means of expressing requirements since they are easier "Computer hardware description languages to use than languages. Examples of the use of (CHDL's) will continue to develop and to be forms are the ADS (Accurately Defined Systems) used as "front ends" of conventional developed by National Cash Register and TAG (Time hardware design automation systems, but the Automated Grid) developed by IBM. (A comparison research emphasis will have been on system is given by Teichroew 1972). A recent example is descriptive languages such as that used by the programming language used in The System for LOGOS. It is probable that these languages Business Automation (SBA) prepared by Zloof and de will be string-oriented rather than graphic Jong (1977). An example of a program to produce because of the cost of sophisticated an invoice is given in Figure 4.3.1. A diagram of terminals." the language structure is given in Figure 4.3.2. The language attempts to show the format of the Module Specification Languages. These languages documents graphically. The domain over which the focus on specifications at the functional level program is to be executed is shown by underlining and usually include some facility to describe an item in a table (which is considered to be a relationships among modules. Examples are the relation). languages proposed by Rin (1976), Beck(1976), and DeRemer and Kron(1976). Decision Tables. Decision tables have been advocated as useful tools for specifying Augmented (Procedural) Prngr-ammlng Languages. A requirements. However, there appears to be number of extension to procedural language have general agreement that they are not widely used. been proposed. Some of these incorporate See, for example, Chvalovsky (1976) and Central structured, programming constructs, for example Computer Agency (1973). One of the reasons given RATFOR, (Kernighan and Plauger, (1976)). Others in the latter report is that decision tables by are designed, not so much to reduce the amount of themselves are not enough, they should be manual programming, as to provide facilities to incorporated into a more comprehensive system. state requirements which will make the object code Attempts to do so have been made in HSL/1 more reliable. Another augmentation is in the developed by Hoskyns (Rhodes, 1972) and marketed direction of making the language extensible for by Martin Marietta and in AMS developed by TRES, data types (Liskov 1975). Inc. (Wright 1975). The HSL/1 approach to programming is contrasted with the traditional 4.4 Production of Software Systems method in Figure 4.3.3. (The AMS system is briefly described in section 3.3.) The methods discussed in this section are designed to implement higher level specifications (at one Questionnaires. The questionnaire approach is of the levels outlined in 4.2), in one of the simply a list of multiple choice questions. A forms described in 4.3, and produce an specification consists of the selection of one of "executable" system automatically with minimum each of the available choices. The first formal human intervention. For the purpose of this description of the technique appears to the one section, it does not matter whether the given by Ginsberg, et al. 1965. The combination "executable" system is object code for a given of this technique with decision tables was computing environment or whether it is source code advocated by Low (1973): in a programming language. In practice, of course, the performance of the system may very well be affected by what form of executable system "Programming by questionnaire combines is produced. aspects of decision table programming and general purpose programming by using 4.4.1 Artificial Intelligence. The input decision tables to construct an application to this method is either text in a natural program through the selection of certain language or in a specialized natural language. A source statements from a predefined file. survey of the state-of-the art in automatic It is proposed that programming by programming natural language dialogue is given by questionnaire is a useful compromise Heidorn (1976). He begins with this introduction: between general and special purpose programming for a significant class of "Since the early days of computing, effort large scale problems." has been put into automating more and more of the programming process. The ultimate The most extensive use of the technique appears to objective in automatic programming is a be by IBM in the Application Customizer which is system that can carry on a natural language used to produce executable code for System/3. dialogue with a user (especially a nonprogrammer) about his requirements and Graphical Languages. Graphical languages appear then produce an appropriate program for attractive as a means of specifying requirements him. Although the basic idea of since human beings can comprehend a large amount 'programming in English' has often been of information when it is presented graphically. expressed in the literature, only in recent Graphical languages have been proposed as years have any serious attempts been made supplementary forms to other languages, (see, for toward producing such a system." example, Young and Kent, 1961). When recorded manually, however, graphical languages must be He then describes four experimental systems and transformed into input suitable for computer discusses a number of research issues and

- 201 - concludes with the statement: to accomplish the stated requirements. In its full generality, this is equivalent to the "Higher level considerations such as this artificial intelligence approach. In practice, will have to be dealt with in addition to however, the domain must usually be constrained in the more technical issues discussed above some way. before natural language automatic programming can become a practical A second approach assumes the existence of a reality." number of modules. The generator needs only to decide which modules are necessary and provide for One of the systems surveyed is the SAFE system the required interconnections. The system based being developed by Balzer (ISI Research Staff on "Programming by questionnaire" (Ginsburg 1976). He describes his approach as follows: (1965), Low (1972)) is an example of this level of generators. Another example is automatic program "Only modest gains in programming synthesis (Feldman (1972), and Lee, Charnig and productivity have been produced in 25 years Waldinger (1974)). of software research, but the groundwork has been laid for major advances through A third level occurs when a skeleton of the system rationalization and automated aids. This exists and the generator merely parameterizes it groundwork rests on two critical ideas: to fit a particular environment. The system that specification must be separated from generation of an operating system for a particular implementation, and that the separation environment is an example of this level. between these two processes should be a formal operational abstract (i.e., very 4.4.3 Module Preprocessors. The module high level) program rather than a preprocessors work at the module level, i.e. , each nonoperational requirements specification. unit of specification is transformed into a Structured programming represents the first software module. The methods differ by the degree results of combining these ideas. It is a to which the specification is rearranged or special case of a more general two-phase transformed by the preprocessor. In the system process, called Abstract Programming, in proposed by Beck (1976) for example, the which an informal and imprecise specification given in a module specification specification is transformed into a formal language are transformed to "Standard Processes ." abstract operational program, which is then In general, these methods are based on producing a transformed into a concrete (i.e., detailed directed graph from the specifications and then low-level) program by optimization. partitioning the graph in some way. Abstract programming thus consists of a specification phase and an implementation 4.4.4 Compilers for Augumented Programming (optimization) phase which share a formal Languages. These software systems accept abstract operational program as their statements in augumented languages (including common interface." structural programming constructs and abstract data types) and produce either source statements He summarizes the current status as follows: in the programming language or object code. These compilers expand the augumented statements but "Though the results using this example are generally do not rearrange statements to the very promising, and although we have extent done by the Preprocessors. attempted to build a general system capable of handling a wide variety of 4.5 Conclusions specifications from many different domains, it is extremely difficult to extrapolate The preceeding discussion indicates that a number from a single data point. We therefore are of approaches for producing executable systems planning to present several different and from higher level specifications have been more complex examples to the system during proposed and/or are being developed. These use the next year." different levels of specification, different forms of specification and different approaches to the There seems to be general agreement that while generation of executable systems. However, the this approach is promising and research should be use of these techniques, to reduce the amount of continued, it will be some time before this method software that must be produced, is so far limited. is capable of producing results that compare with what now is being produced manually. System Generators are the method with the best chance to yield a dramatic reduction in the cost 4.4.2 Software System Generators. The of the software components of systems and at the concept of generating complete systems from a set same time improving the effectiveness of the of requirements has long been a dream of system for the user. However, before System application software developers. Recently, the Generators achieve widespread use, a number of generator concept has been described by Dolotta, problems will have to be overcome. The most et al. (1976). Their description is given in pressing problem is introducing methods for Appendix 3. persuading the organizational unit that needs a new system, to accept one that is generated rather The system generator approach differs from the than custom built. One of the necessary artificial intelligence approach primarily in that conditions for acceptance of the generated target some knowledge of either the application area or system is that it, in fact, accomplish the the software system structure is assumed. The requirements. Thus, considerable skill is domain is therefore much more limited and required to produce generators that meet a wide specialized. enough range of users to justify the investment.

Three types of software system generators may be Under the right circumstances, these approaches considered. In the first, the generator is may contribute substantially to reducing the cost capable of producing modules and assembling them of high quality software. Thus, it is worthwhile

- 202 - to consider the factors which are currently a Software Support System, as defined in Section 3 limiting their use, so that these techniques can and augmented by the software generator techniques be incorporated into the approach outlined in discussed in Section 4, can be further improved by section 6. incorporating the concepts of reusable modules and generalized software. 5. Reducing the Amount of Software that must be Produced 5.2 Software Distribution

5.1 Introduction A great deal of software is available for use at a nominal or even zero cost. Nevertheless this There are a number of methods, techniques, and software is not widely used. The reasons for this approaches that will reduce the amount of "new" include all the reasons given in section 2 for the software necessary to meet a specific requirement. specific case of software for development of A person or organization who has a requirement can application software. Large organizations obtain software to meet his needs by one of the frequently have programs to disseminate knowledge ways identified in section 1.2: develop the of available software. For example, Computerworld software himself, have it developed for him, recently reported on one attempt by the U.S. select from a set of available packages, or select Government to foster sharing of software (Appendix it from a set of available "turn-key" system. 5).

The greater the proportion of the software that is 5.3 Generalized Software Produced bv the Software already available, and therefore, does not have to Industry be developed, the more the user gains. The software should be less expensive since the The software industry markets program packages development cost is spread over more users, it which are usually referred to as generalized should be available sooner since it does not have software since a package is intended to satisfy a to be developed, and it should be more reliable large number of users with as little change as since it has presumably already been tested. possible. Many organizations which develop software for their own use also attempt to sell it The developer of software should also gain from to others as generalized software. While many using predeveloped software; he should be able to packages are available very few of them achieve improve his profit through increased sales since any substantial number of installations. The most each user can obtain the software at a low cost, successful is Mark IV which is marketed by he would be able to increase the amount of Information, Inc. According to Datamation development he does since he becomes more (December 1976, p. 142) there are over 1000 competitive as compared to the custom-tailored installations of Mark IV which have resulted in developers, and he can afford to invest in more than 40,000,000 dollars in revenue. Analysis improving his development methods along the lines of other packages that have been purchased by many described in sections 3 and 4. users, shows that the most success has been achieved in application-independent packages. The potential advantages of reusable modules is Data base management is an example of an area illustrated by the price charged by one software where few organizations can now justify producing company, Martin-Marietta, as shown in Appendix 4. a software system for themselves. However, According to its advertisements, the company software enterprises have had limited success in charges $6 per statement for custom-tailored marketing generalized application packages. system but only $1 per statement if the system is built entirely out of existing modules. 5.4 Modularization Based on Decomposition of Application Functions Despite the apparent advantages of making maximum use of existing software and of designing and The synthesis approach to software system building software to have a maximum number of development attempts to realize a system to users, a large amount of the development today is accomplish a given set of requirements from a concerned with designing and building new given library of available components. There have custom-tailored systems to meet each requirement. been a number of attempts to use this approach This section examines the present status of though few have been reported in the literature in "generalized" software and considers some of the any degree of detail. One attempt was the problems that must be solved if the concept is to Information Systems Engineering effort described be incorporated into the Software Support System. by Welsh (1968). It is an instructive example because it involved a relatively large effort Section 5.2 discusses attempts to use existing sustained over a number of years, because it was software where the software itself can be obtained concerned with application modules, and because it at nominal cost. Section 5.3 outlines very did not succeed in replacing the conventional briefly the current status of the software custom-tailoring approach. industry which, by definition, is motivated to produce software with as broad a market as The effort was motivated by the attempt of a large possible. Section 5.4 describes one attempt to industrial firm to avoid building unique systems develop a method to synthesize systems from to accomplish essentially similar requirements modules based on application functions. Section (payroll, production scheduling, inventory 5.5 and 5.6 outline attempts, at national levels, control, etc.) in each semi-autonomous subsidiary. to develop systems based on reusable modules in (The first approach was to try to build a system the USSR and Japan respectively. Section 5.7 and to accomplish a given requirement at one 5.8 describes some of the issues that must be subsidiary and then transport it to the others - addressed and outlines some possible approaches in this was abandoned as impractical after a few reusing modules and generalized software attempts). The approach, summarized in Figure respectively. 5.4.1, uses three tools:

Section 5.9 summarizes how software development in Functions - predefined units of information

- 203 - processing requirements. For standardization of the modules is widely example, one Function might be emphasized (Maohrov et al (1974), p. 281 and "determine manpower requirements". Myasnikov (1974) p.. 92). Besides the long-existing Central Institute of Scientific Satisfiers - preprogrammed modules or routines Research in Management and Control Technology in that satisfy a given Function. The Minsk (employing several thousand researchers), in library of Satisfiers may contain 1974 the computer industry created in Kalinin a more than one Satisfier for a given Software Development Center charged with Function. developing, from standardized modules, application packages serving all the potential users in the Configurator - a form in which the needs or USSR, (Myasnikov (1974) p. 92). The users are requirements of a particular set of strongly urged to build "open" application users are stated. systems, which could be enhanced in the future when the basic system has already been in The synthesis consists of three major steps: operation for some time. The wide use of the first 130 standardized application packages has a. The requirements for a system are been recommended by the Union Committee for determined and expressed using the Science and Technology of the USSR Council of Configurator. Ministers (Myasnikov (1974) p. 92). The cooperation in this field between the USA and the b. A solution to the needs is synthesized USSR has become feasible since the same Committee using the Functions and the available recommended COBOL, ALGOL, FORTRAN and PL/1 as Satisfiers. If no acceptable Satisfier is basic programming languages and the IBM standards available for a given Function, a new one have been adapted for the development of the RIAD is produced. Computer Series (Myasnikov (1974) p. 91).

c. The system is "assembled" and is then ready for installation and test. 5.6 System Development la Japan A large part of this development effort consisted In 1973, the Japanese Ministry of International of identifying and specifying the Functions. The Trade and Industry (MITI) funded a project to make criteria vised to identify the Functions were: it easier, faster, and cheaper to produce application programs from small chunks of - the Functions had to be mutually exclusive, previously written and stored application modules, - the Functions had to be exhaustive, and assemble these into working, or nearly - the Functions had to be of approximately the complete, new programs. The results as reported right size. by Datamation, (September 1976 p. 97), were as follows : Approximately fifty functions were identified and described. In some cases a description required "The five groups, however, each did their several hundred pages. The functions are listed own thing with little, if any, management in Appendix 6. or coordination from a central body. There was not even agreement on the definition of Despite the extensive development effort and a module. At least one group wrote its intensive attempts to apply the results, the modules in FORTRAN. Another used DPL. And approach is not being used. The reasons are one group really didn't know what the partly technological. Functions that covered data others were doing. The result, say some processing, e.g., Message Discrimination and observers in Japan, was a flop." Validation, File Update and Surveillance and Report Data Compiler, were apparently implemented MITI in 1976 created a new corporation, Joint in such a way that the synthesized system could System Development Corporation (JSD), which has not compete in usage of computer resources with initiated a five year program to produce a Program custom tailored systems. Productivity Development System (PPDS). An overview of the initial system is given in Figure However, the main reasons for the lack of adoption 5.6.1 (JSD, 1976). were institutional. The managers of the subsidiaries could not be convinced that there 5.7 Issues in Reusable Software would be sufficient gains to warrant the loss of autonomy that they had with the custom tailored In dealing with a complex system, either in systems. Corporate management on the other hand analyzing an existing system or in building a new was not convinced that corporate benefits would be one, it is often beneficial to treat it as a sufficient to warrant forcing the subsidiaries to hierarchy of modules comprising the entire system use the synthesis approach against their will. (Simon 1962). The use of subassemblies in manufacturing industry is a well-known engineering 5.5 System Development in ihs. USSR application of this principle. With regard to information processing systems, modularization has The USSR is engaged in a major effort to develop a long been recognized as desirable, and many papers relatively large number of computerized management have been written on modular programs, modular information systems (Myasnikov 1974, pp. 88,95). software, modular file organization, and modular In order to facilitate the development procedure, systems architecture. However, many systems when detailed guidelines have been established and completed are not, in fact, modular. There are, approved by the Union Committee for Science and therefore, many factors which tend to work against Technology of the USSR Council of Ministers effective modularization even if the designers (1972). The development procedure is based on the have that as their goal. Some argue that concept of synthesizing systems from a number of modularization will be achieved only if it is existing modules rather than custom building a forced and there is no other choice. system for each application. The need for

- 204 - 5.7.1 How ia Modularize. Any given system concepts in software development was that of the can be decomposed into smaller systems or closed subroutine. Almost every installation has, components in many different ways. A number of over time, developed a library of subroutines methods for decomposition have been proposed. which perform common useful functions, and most Some of the problems are: programming languages have adopted standard set of subroutines such as SIN, COS, etc. The extension 1. Whether to modularize on of this principle to the program level, results in application-independent functions or on the many utility functions which are generally application dependent functions. available often at the system command level for Frequently an examination of application copying, sorting, editing, etc. Taking advantage software will reveal some application of these well-defined and tested capabilities not independent functions that are repeated only simplifies the task of the system developer, several times. The identification of these but makes the developed system easier to functions and the provision of modules to understand and maintain. accomplish them when they are required usually leads to a reduction in the amount Turn-key systems are acquired in cases where the of application software that is needed. buyer does not have the capability to produce the See for example IBM(1977). system himself or where he is prevented from doing so by legal or policy constraints. The former 2. How to separate data definition from occurs primarily in small organizations which up processing definition. to the present, have absorbed only a small part of In the early days the lack of distinction the computer industry's products. This will between data and instructions was regarded probably be relatively unimportant for the by many as one of the great achievements of software industry since the turn-key systems are the electronic computer. It has become likely to make maximum use of firmware. The increasingly clear, however, that the latter occurs in some government departments and distinction should be made and the trend is in some industries under governmnet regulatory clearly towards further and further control. These situations are also likely to separation. remain relatively unimportant. The second situation arises when the cost of a turn-key - COBOL separated the Data Division from system is so clearly less than that of a custom the Procedure Division, thus allowing each built system that the buyer has no choice. This to be defined, and hopefully modified, requires that the buyer know the relative costs of separately though they have to be compiled both turn-key and custom made systems including together. maintenance and other related costs.

- Data Base Management Systems carry this While software components at all these levels can concept one step further by having separate be made reusable, the level with the most Data Definition Languages and Data potential for mass usage is the "module" level. Manipulation Languages. The term "module", as defined in 1.1.2, is a component of software that can be compiled - Data Dictionaries provide for definition separately but may contain components which can of data elements that contain the user also be compiled separately. oriented descriptions as well as computer oriented descriptions. 5.7-3 Effioienov. It is generally accepted - Another trend is to distinguish data that that modular systems are inefficient because of describes the structure of the the overhead involved in linking and calling organization, and is used to control modules. Camp and Jensen (1976) have investigated processing, from other data. In its past the system cost or overhead associated with they have frequently been embedded in the software modularity. They conclude that the added programs; the objective now is to remove cost is relatively small compared to the savings them from the program and put them in gained in software development and tables so that the tables can be changed maintainability. The overhead that currently without changing the program. exists can probably be reduced in future systems by more effective linking and loading. 3. How to separate processing from control-flow. 5.7.t Parameterization. All generalized By separating modules which perform basic approaches, even turn-key systems and those based functions from the logic which causes one on modules, require adaptation to an individual function to be performed rather than installation for three major reasons: hardware another, the likelihood that the basic configurations are different and change over time, modules will be reusable is increased. the individual installation requirements differ, not all want all options, and the software itself 5.7.2 What is the Best Size for a Reusable is changed to correct errors and improve Module. One of the basic questions in reusable performance. It is therefore desirable to embed module development is the size of the component of as few parameters in a module as possible. software which should be standardized or made reusable. The terminology, referring to size of The early information processing systems were software components, used here is defined in stand-alone applications with their own files. section 1.1.2. All of the levels system, This resulted in considerable duplication of data, including subsystem, program, routine and module duplication of processing operations, and great have been used as the unit of reusable components. difficulty in maintaining the systems. For example, one major food processing firm had to Many programming languages have provisions for rewrite its entire order entry, production control incorporating predefined sets of statements, and distribution software when a new product was usually called macros. One of the very first introduced because the knowledge of the existing

- 205 - product codes was embedded in the individual and its external description verified as being modules. Plauger (1976) describes the consistent with its internal operation. It would difficulties caused by lack of parameterization in be possible also at this time to search for the New York Times project. possible overlap with existing modules.

5.8 Issues in. Generalized Software 6. Summary and Consideration for Progress

The individual programmer should organize his 6.1 Siimmary programs so that he can reuse portions of his code without having to rewrite it. However, the The concern of this paper has been with surveying components are usually not used by others since the state-of-the-art in software, examining the they are not documented well enough. If attempts that have been and are being made to components are going to be reused they must be improve software, analyzing the reasons why these developed with this in mind. Provisions must be attempts have not always been successful, and made for component definition and development, finally, synthesizing an approach which may description, documentation, cataloging, overcome many of the reasons for the lack of maintenance and modification, and a system success in the past. The objective is to propose construction method that compiles and links the methods to obtain the same degree of improvement object code. in software as that which has been obtained in hardware. The hardware improvements in Since all this requires a substantial investment, capability, reliability and reduction in cost have the success of a developer of a system based on been achieved through research, separation of reusable modules depends on whether or not there engineering and manufacturing functions and mass is a sufficiently large market for the modules. production. These same concepts can be applied to software, though currently not as readily. There are a number of different ways in which the subdivision into modules can be made. One of the The environment in which these techniques are most most pervasive is on whether the function to be relevant is one in which a large amount of performed is dependent on the application or software must be produced and maintained over a whether it is a data processing function which is long period of time during which the requirements independent of a particular application. An and computing environment may change. A software example of application independent functions is system in such an environment is usually large given in section 5.4 with hundreds of modules and tens of thousands of lines of source statement. The software must be 5.9 Use Qf the. Software SuDjjari. System developed and maintained by staff whose membership is also changing. The software may exist in many The key problem in basing a system on the versions each with many releases. The techniques utilization of modules is specification of what are not necessarily appropriate for situations in each module should do. An approach which allows which state-of-the-art software is produced by each software designer to design his own modules experts primarily for research purposes. In these and add them to the library will not be situations software is not intended to be used for successful. Three requirements are necessary. operational uses and does not have to be First, some set of criteria will have to be maintained. Cost and performance may not be as established for the specification of a module. important as demonstrating feasibility. The criteria will probably include several types of information; both structural and functional. 6.1.1 Manor Components. Software can be Second, the modules will have to be adequately provided to the user at a substantially lower described, catalogued, and documented so that a cost, be more reliable and more adaptable as his prospective user will be able to locate those that environment changes, by an approach that consists might satisfy his needs. Third, the modules will of three components. have to be constructed according to some standards for both internal structure and external Coordinated software development tools ta provide interfaces. assistance io. ine professional software developers. The assistance will be clerical, for Generalized systems have had only limited success. enforcing conventions, and managerial. The If these methods are to be pursued, the reasons clerical function will provide storage of the for the lack of success must be identified to software components and preparation of hard copy determine whether they can be overcome or whether documentation. The system will ensure that the evolution in other areas will change conventions are being followed, will provide for conditions so as to favor generalized systems. performing a check of various kinds on the software components. It will also provide The concepts of reusable modules and generalized managerial functions for keeping track of progress software can be incorporated in the Software and for evaluating the impact of changes. The Support System. This may not immediately and/or system itself, however, at this point does not completely overcome all the difficulties produce software; the software is still produced identified in section 5.7 and 5.8, but manually but through the use of the computer as an considerable improvement can be made. The use of automated information storage and retrieval a data base to record all system descriptions system. More detailed specifications are given in automatically enforces a standard definition of a section 3- module. Furthermore, the data base contains descriptive information about each module. This Increased use of the computer to reduce the amount will simplify determining whether a module that of software which must be developed "manually". accomodates a desired function already exists. These techniques permit the computer to be used to reduce the manual work of actually generating the Each module will be stored in a data base together software and also support decision-making by all with its external description. When a new module those involved with software. The techniques are is entered into a data base it will be examined described in section 4.

- 206 - Increased use of existing software to reduce the individually developed data base management amount c¡¿ new software that must be developed in a. systems. given system. One of the most effective ways to reduce cost and time is to make use of software 6.2 Considerations for Progress that already exists and has been fully debugged and tested. The techniques for accomplishing this It is obvious that a development of a Software are discussed in section 5. Support System with the capabilities described above is no small undertaking. The technical, In the past, individual approaches in most of operational and economic feasibility of such a these areas have been tried, but progress has been system must be examined and the specific actions slow. The impediments to progress are not limited that are needed for such a system to become viable to technical problems, though these do exist. determined. More serious are the management, economic, and political problems. Analysis of the various 6.2.1 Technical Feasibility- The first techniques indicates that many of these requirement is the ability to maintain in a data limitations can be overcome by an integrated base, all information about the software system to approach rather than considering them to be be developed. Data base management systems are in mutually exclusive. existence and have been used in cases such as PSA (Teichroew and Hershey, 1977) and REVS (Davis and 6.1.2 Implementation Objectives. The Vick, 1976). The amount of information that has creation of comprehensive Software Support System to be stored is less than that of many . should be based on the following concepts: applications in which these data base management systems are now being used. The performance - An integrated, coordinated data base that requirements of such systems need to be contains all the relevant information about the determined, though again this is not expected to software. The more complete the relevant be any major difficulty. It must be recognized, information, the more the data base will be able however, that a Data Base Administrator function to serve all the needs of various users of the will be necessary in this application as it is in system. A coordinated data base also eliminates other applications using data base management the difficulties caused by incompatible systems. interfaces. One of the major requirements is to develop an - The system should serve as much of the integrated approach to the use of languages for information needs of all the individuals concerned specifying the input to the system, and for with systems. The more these needs are met, the commanding it to perform the necessary operations. more likely it is that the individuals will use A consistent approach is necessary as there will the system and provide the necessary input data. be many different users and each requires a language that includes his own vocabulary. A - The system should provide for continual large number of languages, however, become evolution. It should be able to accommodate the difficult to learn and difficult to maintain. A software which already exists and which must be number of different forms of the languages have maintained. It should also be able to provide for been discussed in section 3- It appears that future transition to other environments. This natural languages will not be suitable since includes both hardware and hard software such as natural language processing is still too operating systems and data base management difficult. The more promising approach is the use systems. of a relational language such as that used in PSL and RSL, supplemented by one or more levels of - The system should have a consistent approach to procedural programming languages. This approach languages. This will make the entire system has the advantage that the terms in the language easier to understand and reduce the time required can be selected so as to be natural to the user. to learn to use the system. It will also reduce The approach of the specifying objects and their the cost of implementing the system and extending relations is easy to follow and applies to most of the functions it provides. the areas which the system is to be used. It will of course be necessary for the data base - The system should provide consistent interfaces administrator to insure consistency in the naming of objects and relationships. Thus, among the various functions that it provides. The interrelationships among objects specified by reports should have standards formats so that the different users can be maintained. The basic contents of one report may be used as the input to relational language can be supplemented by forms, another. tables, graphical language, etc. as desirable.

6.1.3 Potential Benefits. It will be desirable to evaluate these languages A Software Support System with the capabilities further to improve their ease of understanding, outlined above has the potential to provide the power of communication, and human engineering. same improvements for software as has been obtained in hardware. These will become One of the major advantages of the Software particularly evident over time as a data base of Support System will be the ability to generate reusable modules is built up and as the techniques executable systems for different computing to generate software from a higher level environments. The techniques available for this specifications are gradually refined. have been discussed in section 4. Many of these techniques require further evaluation; however, In time, the quality of the software produced with the basic approach of the data base and the should be so superior that production software languages mentioned above, these can be produced by these methods will replace software incorporated as they are being developed and developed by traditional methods. This is exactly proved. The desirability of developing systems the way that commercially produced data base that operate in different computing environments management systems have completely replaced can be improved by the techniques which were

- 207 - identified in section 5. 6.3 Conclusion A number of current limitations in progress in reusing software are identified in section 5. The For an organization that is continuously Software Support System requires, and implies, developing and maintaining software, the use of a that all software components can be named. This Software Support System should result in is the first step in being able to identify and substantially lower costs and better overall reuse software. The system encourages quality. As this use becomes completely dominant, descriptions that will be helpful in reusing the the benefit of reusing systems and being able to software. Nevertheless, additional discipline generate systems with less and less manual will have to be provided by management to ensure intervention will become more evident. If these that the adequate description exists for the design objectives are successful, the system identification of the potentially reusable should eventually become indispensable. software components. References 6.2.2 Operational Feasibility. Even if a Software Support System is built there remains the Alford, M., "A requirements engineering question of whether it would in fact be used. methodology for real-time processing Clearly, such a system is first and foremost a requirements", IEEE Transactions of management tool. Its basic objective is to reduce Software Engineering. February 1977. the cost and improve the quality of software from the point of view of the organization that is Baker, F.T. "Chief Programmer Team Management of producing it. Therefore, it is absolutely Production Programming", IBM Systems essential that the approach has full management Journal, Volume 11, No. 1, 1972. understanding and support. Beck, L.L., "Automatic Design of Structured Data

However, the major users of the systems will be Processing Systems" Proceedingsr 1976 the professionals: Systems Analysts, System SIGMOD International Conference on Architects, Software Designers, Data Base Designers, Programmers, Quality Assurers, etc. Management ¡¡t pata, pp. 179-188. These individuals will use it if it provides Beck, L.L., Automatic Pesjm .a£ Structured. functions that they recognize are important, which Processing Systems Ph.D. Dissertation, management recognizes as important, and which the Department of Computer Science, Southern system performs more effectively than if they were Methodist University, December 1975. done manually. This implies that in the design of the system considerable attention must be given to Belady, L. A., Lehman, M. M., "The Evolution each one of the functions if the system is to be Dynamics of Large Programs," IBM Research cost effective. Report, RC5615, September 9, 1971

The use of the system will also depend to a good Belady, L. A., Lehman, M. M., "A model of large extent on its ease of use and hence, considerable program development," IBM Systems Journal. attention must be paid to making the system as Vol. 15 No. 3, 1976 simple to use and as reliable as possible. Bell, T.E., D.C. Bixler, and M.E. Dyer, "An Further research and development is required into extendable approach to computer-aided what functions should be accomplished and how they software requirements engineering", IEEE can best be performed in the system. On the basis Transactions Q& Software Engineering,, of experience gained with the prototypes, such as February 1977. PSA (which at present provides only a part of the functions of a full Software Support System) it is Beizer, Jack(ed), Holzman, Albert G.(ed), Kent, evident that it is possible to design a system Allen(ed), Encyclopedia M Computer Science that such professionals will use. and Technology r New York, NY, Marcel Dekker, 1975 6.2.3 Economic Feasibility. The System clearly requires substantial investment and the Benjamin, Robert I., "A Generational Perspective initial problem is to obtain the necessary of Information System Development," Coma resources. One approach is to build the system of the ACM, Vol. 15 No. 7, pp. 640-643, software in phases. Thus, benefits are obtained July 1972 from the beginning and since the system is open ended, compatible components can be added as they Blosser, Patrick Alan, An Automatic System for become available. Application Software generation ana. Portability, Ph.D. Dissertation, August Even if it is available, can such a system compete 1976, Purdue University. with present manual methods? There are clearly costs associated with the use of such a system Boehm, B.W., J.R. Brown, H. Kaspar, M. Lipow, G.J. which includes training, software, maintenance, MacLeod, M.J. Merrltt Characteristics of documentation, etc. These costs are all highly Software Quality. TRW Systems Group, Report visible. The benefits, on the other hand, in a No. 25201, 6001-RO-OO, December 28, 1973. particular application in a particular installation, are likely not to be as visible. Eoehm, B. W. , "Software Engineering", IEEE. They will be hard to measure, and take effect only Transactions on Computers, Vol. C-25, No. over a period of time. However, it can be argued 12, December 1976. pp. 1226-1241. that, in general, the out-of-pocket direct costs of producing systems with such a facility should Braden, Robert, "The National Software Works be no more' than the present direct costs if they Project," Proceedings. ¿HABE. XLJLL1, Session were completely measured. C103, Montreal, August 15-20, 1976

- 208 - Brooks, Frederick P. , lüg. Mythical Man Month. Essavs on Software Engineering. Addison-Wesley, 1975, 195 pp. Datapro, Directory of Software, Datapro Research Corporation, New Jersey Brown, H.M., "Clear-Caster System," Software Engineering Techniques, NATO Science Denning, Peter J., "Third Generation Computer Committee Report, Brussels, Belguim, 53-60 Systems," Computing Surveys, Vol. 3 No. 4, (Oct. 1969). December 1971

Camp, J.W., E.D. Jensen, "Cost of Modularity", DeRemer, Frank, Hans Kron, "Programming-in-the Hughes Aircraft Company, Fullerton, CA, large versus Programming-in the small" 1st Manuscript, 1976, 18 pp. Conference on Reliable Software. Sjgplan Notices, May/June 1975. Canning, Richard C, Application Management System (AMS), EDP Analyzer. December 1974, p.9. Dijkstra, E.W., "A constructive approach to the Canning Publications, 925 Anza Avenue, problem of program correctness, BIT, Vista, CA 92083. August, 1968.

Canning, Richard C, "Are We Doing Things Right?," Dolotta, T. A., Bernstein, M. T., Dickson Jr, R. EDP Analyzer. Vol. 13 No. 6, June 1975, S., France, N. A., Rosenblatt, B. A., Smith, D. M., Steel Jr, T. B., Data Canning, Richard C, "Are We Doing the Right Processing in 1980-1985: A Study of Thing?," EDP Analyzer, Vol. 13 No. 5, May Potential Limitations ia Progress, New 1975, York, NY, Wiley Interscience, 1976

Canning, Richard C, "Do We Have the Right Donovan, John J., "Database System Approach to Resources?," EDP Analyzer, Vol. 13 No. 7, Management Decision Support," MIT Center July 1975, lor Information Systems Research, Report COSR-25, Sloan WP-868-76 Central Computer Agency of the Civil Service Dept. Implications aL Using. Modular Pmp-i-amrH ncr , Falla, M.E., Pearce, D.J., Pierce, R.H. "The Gamma ISBN 0-11-630361-1. 1973. 148 pp. Her Design and Programming System", pp. 89-107 Majesty's Stationary Office, London. in Software Systems Engineering, Proceedings of the European Computing Central Computer Agency, Guide #6, "Decision Conference on Software Systems Engineering, Tables." Evaluation of Programming and London, September 1976, On-line, Uxbridge, Systems Techniques. London: Her Majesty's England. Stationery Office, 1974, ISBN011 6303662 92 pp. Feldman, J., "Automatic Programming", Stanford University Report CS-255, February 1972. Cheatham Jr, T. E., Wegbreit, B., "A Laboratory for the Study of Automating Programming," Gardner, R., Estrin, G., Potash, H., "A Structural Proceedings of AFIPS FJCC 1Q72, Vol. 40, Modeling Language for Architecture of pp. 11-21 Computer Systems," International Symposium on Methodologies for the Design and Chvalovsky, V. "Problems with Decision Tables," Construction of Software and Hardware Comm. of the ACM, December 1976, Vol. 19, Systems, Rio de Janeiro, Brazil, June No. 12, p. 705 28-July 2, 1976

Computer Weekly. "Hewlett-Packard enlists the Gibson, Cyrus F., Nolan, Richard L., "Managing the marketing aid of Hoskyns," July 15, 1975 four stages of EDP growth," Harvard Business Review, pp. 76-88, Couger, J. D.(ed), Knapp, R. W.(ed), Sj£s£em. January-February 1974 Analysis Techniques, John Wiley & Sons, 1974 Gilb, T., Software Metrics. Studentlitteratur, 1976, 282 pp. Couger, J. D., "Evolution of Business System Analysis Techniques," Computing Surveys, Ginsberg, A.S., Markowitz, H.M. and Oldfather, Vol. 5 No. 3, September 1973 P.M., "Programming by Questionnaire," RM-4460-RR, RAND CORP., Santa Monica, Crafford, J.C, R.W. Curry, and R.A. DeCarli, Calif. 1965 "Integrated Test Bed Support Software System Study, Phase II," Prepared for U.S. Hamilton, M., Zeldin, S., "Integrated Software Army Computer Systems Command, 5 November Development System/Higher Order Software 1976 Conceptual Description," Version 1, Research and Development Technical Report, Curry, R.W., "A Measure to Support Calibration and ECOM-76-0329-F, November 1976, ECOM, Fort Balancing of the Effectiveness of Software Monmouth, NJ. Engineering Tools and Techniques," Science Applications. Inc.. , 25 March 1976, Hammer, M. M., Howe, W. Gerry, Wladawsky, Irving, Manuscript "An Interactive Business Definition System," Proceedings of the Symposium on Davis, CG. and CR. Vick, "The Software Very High Level Languages, SIGPLAN Notices, Development System," Proceedings, 2nd Vol. 9 No. 4, April 1974 International Conference on Software Engineering, 13-15 October 1976, San Francisco, IEEE No. 76CH1125-4C.

- 209 - Hartman, W. H., Proeme, A., Management Information Systems Handbook, McGraw-Hill, 1968 Lee, R.C.T., Chang, S.K. , and Waldinger, R.J., "An Harvey, F. L., "The Developing Software Industry," Improved Program-Synthesizing Algorithm and Infosvstems, July 1976 Its correctness", £omm.. of the ACM, April 1974, pp. 211-217. Heidorn, G. E., "Automatic Programming Through natural Language Dialogue: A Survey," IBM. Lehman, M. M., "The Programming Process," IBM Journal of Research and Development, Vol. Research Report, RC2722, December 5, 1969 20 No. 4, pp. 302-313, July 1976 Liskov, Barbara H., Zilles, Stephen N., Heiker, Vince, "Small Shops Need Help, Too," "Programming with Abstract Data Types," Infosvstems, July 1976 Proceedings of the Symposium on Very High Level Languages, SIGPLAN Notices, Vol. 9 Henderson, P., Snowdon, R. A., "A Tool for No. 4, April 1974 Structured Program Development," IFIP 74, pp. 204-207, August 1974 Liskov, Barbara H., Zilles, Stephen N., "Specification Techniques for Data Hice, G. F., Turner, W. S., Cashwell, L. F., Abstractions, " IEEE. Transactions on System Development Methodology, New York, Software Engineering. Vol. 1 No. 1, pp. NY, American Elsevier, 1974 7-19, March 1975

Hofnagle, G.F., M.L. Wilson, "The Kernel System of List, Eernard, "DAIS: A Major Crossroad in the the Information Automat," IBM, 1800 Development of Avionic Systems," Frederick Pike, Gaithersburg, MD 20760, Astronautics &. Aeronautics, January 1973 April, 1976 Low, David W., "Programming by Questionnaire: An Hunter, John J., "The Packaged Software Effective Way To Use Decision Tables," Explosion," Infosvstems, July 1976 Comm. of the ACM,. Vol. 16 No. 5, pp. 282-286, May 1973 IBM, IMS. Application Development Facility, General Information Manual, GB21-9869-0, Program Lucena, Carlos J., Cowan, Donald D., "Toward a Number: 5796-PHX, January 1977. System's Environment for Computer Assisted Programming," Department of Applied ICP, ICP Quarterly, International Computer Analysis 1 Computer Science, University of Programs, Inc. Indianapolis, Indiana Waterloo. Waterloo, Ontario, Canada, CS-76-06 Irvine, C. A., Brackett, J. W., "Automated Software Engineering Through Structured Lufkin, J.M., "Not Invented Here", IEM Data Management," Second International Transactions QB. Engineering Management. Conference an. Software Engineering, San Volume EM-18, no. 4, November 1971. Francisco, October 13-15, 1976 Machrov, N.V., Modin, A.A., Iakovienko, E.G., ISI Research Staff, "A Research Program in "Development parameters of contemporary Computer Tecnology, Annual Technical computer-aided management systems in Report, July 1975-June 1976," USC enterprises." ("Paramietry razrabotki Information Sciences Institute, Marina del sovriemiennych avtomatizirovannych sistem Rey, California, ISI/SR-76-6 upravlienia priedipriatiami",) Izdatielstvo "Nauka"• Moskva 1974. JSD, "An Outline of the Programming Productivity Development System, (PPDS)." Joint System Martin Marietta Data Systems, "Building Computer Development Corporation, Tokyo, December Systems - Overview," Martin Marietta Data 1976. Systems, Sales Brochure (1976) de Jong, S.P., "System Building System (SBS) Build Maynard, H.S., "User Requirements for Data BAse 4 Users Manual," IBM Research Report Management Systems (DBMS)", Data Base RC4485, Yorktown Heights, NY (August 1973). Management Systems (Proc. 1973 SHARE Working Conference on Data Base Management Kernighan, B.W. and Plauger, P.J., Software Tools, Systems), pp. 129-45, New York: American Addison-Wesley Publishing Company, Elsevier, 1974. Inc. 1976. Metzger, Phillip W., Managing a Pi-oc;r«nim1nf!; Knuth, Donald E., "The Semantics of Context Free Project, Prentice-Hall, Inc. New Jersey, Languages," Mathematical Systems Theory. 1973, 201 pp. Volume II, No. 2, 1968 Mills, H.D., and M.L. Wilson, "An Introduction to Konsynski, Benn R., A Model of Computer-Aided the Information Automat," IBM, 1800 Definition and. Analysis o£ Information Frederick Pike, Gaithersburg, MD 20760, May System Requirements , Ph.D. Dissertation, 7, 1976. Purdue University, December 1976. Myasnikov, V.A. "Computer-aided management today - Leavitt, Don, "Center to Aid Sharing of Federal Experiences, problems and prospects ." Software." Computer World, 1976 Article written by the Head of the Eoard of Computer Technology and Management and Control Systems at the Union Committee for Science and Technology of the USSR Council of Ministers. EKO Economics and

- 210 - PAGE

Organization of Industrial Manufacturing - Bimonthly of the Siberian Chapter of the USSR Academy of Sciences. (ASU Reifer, D.J., Toward Specifying Software siegodnia-opit.uroki, perspektivu - Properties , The Aerospace Corporation. "EKOnomika i Organizada Promyshliennovo Manuscript. proisvodstva". Akademia Nauk SSSR, Siberskoie Otdielienie, Izdatielstvo Rhodes, J. "Beyond Programming: Practical Steps "Nauka," - Siberskoie Otdielienie, No Towards the Automaton of DP System 6/1974.) Creation." (1972) In System Analysis Techniques, pp. 328-335. Edited by J. Naftaly, Stanley M., Cohen, Michael C, Johnson, Daniel Couger. New York: John Wiley & Sons. Bruce G., COBOL Support Packages .. . Programming M Productivity Aids, New Rigo, J.T., "Citibank's Minicomputer Approach York, NY, John Wiley & Sons, 1972 182 pp. Seems to Be Working", Computerworld Jan. 3, 1977, p.17. Naval Electronics Laboratory Center, "Systems Design Laboratory Preliminary Design Rin, N. Adam, Automatic Generation of Business Report," Naval Electronics Laboratory Data Processing Programs From a Center, San Diego, California, NELC N725 Non-Procedural Language , Ph.D. TN3145 Dissertation, University of Pennsylvania, October 1976. Newell, A., Perlis, A. J., Simon, H. A., "Computer Science," Science, 157, pp. 1373-1374, 1967 Rose, C.W., "Design Systems- A Five Year View", IEEE Comp.-Con 76 Conference. San Perry, R., "Application Development Cycle Francisco, 1976, p. 190-193 Problems", Presentation to GUIDE, May 21, 1975, Session F-1. Ruth, John C, "DAIS: The First Step," NAECON '73 Record Peters, Lawrence J., Tripp, Leonard L., "Design Representation Schemes," MRI Symposium on Seidman, H. A., "Changes in Computer Services," Computer Software Engineering. April 20, DATAMATION. pp. 40-42, July 1976 1976 Simon, Herbert, "The Architecture of Complexity," Peters, Lawrence J., Tripp, Leonard L., "Is Proceedings. American Philosophical Society Software Design "Wicked"?," DATAMATION, pp. , December 1962, pp. 467-482. 127-136, May 1976 Smoot, Oliver R., "Development of an International Phister, Montgomery, Jr., Data Processing System for Legal Protection of Computer Technology and Economics. Santa Monica Programs," Comm. of the ACM, Vol. 19 No. 4, Publishing, 1976, 571 pp. pp. 171-174, April 1974

Plauger, Bill, "New York Times Revisited," Yourdon Stillman Roña B., Leong-Hong, Belkis, "Software Report, Vol. 1 No. 3, April 1976 pp. 4-5, Testing for Network Services," National Yourdon Inc. New York. Bureau of Standards Tech Note 874, July 1975 Pratten, G.D., Snowdon, R.A., "CADES - Support for the Development of Complex Software," Takasaki, I., EDP-IT's Production and Application pp. 109-124 in Software Systems in Japan, Proceedings Third Annual Computer Engineering, Proceedings of the European Applications Symposium, Chukalongkom Computing Conference on Software Systems University, Bangkok, Thailand, July 1972. Engineering, London, September 1976, On-line, Uxbridge, England. Teichroew, Daniel, "A survey of languages for stating requirements for computer-based Prywes, N. "Preparing for Future Needs." Computer. information systems," Fall Joint Computer IEEE, June 1975 p.70-72. Conference, 1972, pp.1203-1224.

Putnam, L.H., "A General Solution to the Software Teichroew, Daniel, "Improvements in the System Sizing and Estimating Problem," Life Cycle Life Cycle," Information Processing 74 Management Conference, American Institute pp. 972,978, North-Holland Publishing of Industrial Engineers, February 1977, Company, 1974. Washington, D.C. Teichroew, Daniel, E.A. Hershey, III, Ralston, Anthony(ed), Meek, Chester L.(ed), "Computer-Aided Structured Documentation Encyclopedia of Computer Science. New York, and Analysis of Information Processing NY, Petrocelli/Charter, 1976 System Requirements", SHARE JJJÍI1, August 1976. Reifer, D.J., A Glossary of Software Tools and Techniques, The Aerospace Corporation. Teichroew, Daniel, E.A. Hershey, III, "PSL/PSA: A Manuscript 20 p. 1975a. Computer-Aided Technique for Structured Documentation and Analysis of Information Reifer, D. J., "Interim Report on the Aids Processing Systems," IEEE Transactions on Inventory Project," The Aerospace Corp.. El Software Engineering, Volume SE-3, No. 1, Segundo, California, SAMSO-TR-75-184, 1975b January 1977, pp. 41-48.

- 211 - Union Committee for Science and Technology of the USSR Council of Ministers - General methodological guidelines _£ox development Zloof, M.M., S. Peter de Jong, "The System for of. computer-aided management systems in Business Automation (SBA): Programming enterprises. (Gosudarstviennyj Comitiet Language" Comm. of the ASH. 1977 Soviets Ministrov SSSR po Naukie i Tiechnikie - Obshchieotraslievije Appendix 1 rukovodiashchije materialy po sosdaniu Types of Tools Defined by Reifer (1975a) avtomatizirovannych sistem upravlienia priedipriatiami (ASUP)", Minsk 1972.) 1. Accuracy Study Processor 2. Analytical Modeling U.S. Air Force information Processinft/Pata 3. Analyzer Automation Implications ox Air. Force 4. Automated Test Generator Command and Control Requirements in the 5. Automated Verification 1980s (CCIP-85), Volume 1, Highlights, Systems April 1972. 6. Bootstrap Loader 7. Comparator U.S. Air Force Support of Air Force Automatic Data 8. Compiler

Processing Requirements Through £M 1980st 9. Compiler Building System Volume 1 SADPR-85 Report, L.G. Hanscom 10. Compiler Validation System Field, June 1974. 11. Compressor 12. Consistency Checker U.S. Navy, "Tactical Digital Systems Documentation 13. Constants Auto Checker Standards", Secnavinst 3560.1, August 8, 14. Correctness Proofs 1974. 15. Cross-Assembler 16. Cross-Reference Program Waidinger, R.J., Constructing Programs 17. Data Base Analyzer Automatically Using Theorem Proving. Ph.D. 18. Data Definition Language Dissertation, Carnegie-Mellon University, 19. Data-Exception Handler 1969. 20. Decompiler ü1. Design Language Processor Walters, G., "Integrated Software Development 22. Diagnostics/Debug Aids Systems (GE/ISDS)" SIGPLAN Notices 1977, 23. Driver p. 10b. 24. Dynamic Simulator 25. Editor Wegbreit. B., "The ECL Programming System," 26. Engineering/Scientific Proceedings of AFIPS FJCC 1971, Vol. 39, Simulations pp. 253-262 27. Environment Simulator 28. Emulation Wegner, P., Programming Languages Information 29. EQUATE Program Structures and machine Organization. New 30. Extensible Language York: McGraw-Hill, 1968. Processor 31. Flowcharter Wegner, P., "Research Paradigms in Computer 32. Generator Science," Manuscript, 1976. 33. Hardware Monitors 34. Instruction Simulator Weiss, David M., Ina MUDD Report: A Case Study of 35. Instruction Trace Navv Software Development Practices, Naval 36. Interface Checker Research Laboratory, Washington D.C. 20375, 37. Interpreter NRL Report 7909, May 21, 1975. 38. Interrupt Analyzer 39. Language Processors Welsh, W. A., "Engineered Design of EDP Systems," 40. Library Proceedings Systems and. Procedures 41. Linkage Editor Association, International Meeting, St. 42. Linking Loader Louis, Missouri, October 1968 43. Loader 44. Logic/Equation Generator Wilson, Max, "The Information Automat," 45. Macroprocessor Proceedings, SJäAfiE. XLUI, Session LI03, 46. MAP Program Montreal, August 15-20, 1976 47. Modular Programming 48. Overlay Program Wiseman, T. "Beermaker Sues EDS for $115 Million", 49. Peripheral Simulator Computerworld, September 13, 1976. p.1. 50. Postprocessor 51. Preprocessor Withington, Frederic G., "Five Generations of 52. Process Construction Computers." Harvard Business Review, pp. 53. Production Libraries 99-108, July-August 1974 54. Program Flow Analyzer 55. Program Sequencer Wright, A.W., "User Experience with the 56. Record Generator Application Management System (AMS). Info 57. Report Generator 115., New York September 9, 1975. 58. Requirements Language Processor 59. Requirements Tracer Young, J.W., and Kent, H., "Abstract Formulation 60. Restructuring Program of Data Processing Problems," Journal of 61. Scoring Program Industrial Engineering, November-December 62. Simulator 1958, pp. 471-479. Reprinted in Ideas for 63. SNAP Generator Management International Systems-Procedures 64. Software Monitor Association 1959. 65. Standards

- 212 - 66. Standards Enforcer simplicity 67. Structure Analyzer 68. Structured Programming reduced amount of code AMS language 69. System Simulations facilities eliminates application 70. Terminal Simulator programming 71. Test Analyzer 72. Test Beds standard system architecture eliminates 73. Test Drivers, Scripts, part of design phase Data Generators 74. Test-Result Processor documentation machine generated as 75. Text Editor development progresses 76. Timing Analyzer 77. TRACE Program problem resolutions faster - debugging and 78. Translator testing aids 79. Units Consistency Analysis Program OPERATIONAL BENEFITS 80. Utilities reliability Appendix 2 User Report on the Application Management System, maintainability Wright (1975) extendability "APPLICATION ££QQSM DIMENSIONS non-obsolescence" LMS FMS TOTAL Appendix 3 PROGRAM/MODULES Application Generator Proposed by Dolotta (1975) 527 474 1,001 "The primary purpose of this study is to point out SOURCE STATEMENTS EXECUTABLE those requirements of the end users that imply 166,488 86,851 253,139 significant research or development efforts, rather than to attempt to present complete COMMENT/DOCUMENTATION solutions to meet such requirements. It seems 20,538 28,221 48,759 appropriate, however, to outline an example of the type of solution that could meet the rather severe set of requirements given above. TOTAL 187,026 114,872 301,898 One can envision an "applications generator." This PRQPUCTIVm AMLJLSIS. tool can be implemented in several different forms, each meant for a specific type of LMS FMS TOTAL application (e.g., payroll), or for a class of applications. The developer and the applications ELAPSED TIME generator would interact via a "menu" of 16 Mos alternative selections (primarily multiple choice, or true-false) on a television-like console. The MANDAYS EXPENDED generator would view each application as a 1,235 2,375 3,610 hierarchically organized set of building blocks that are to be tied together in a manner dictated TOTAL SOURCE STATEMENTS by the choices offered by the generator and 166,488 86,851 253,139 selected by the developer.

AVERAGE SOURCE STATEMENT At the beginning of the interaction, the choices PER MANDAY 151.4 48.4 83.6 offered to the developer would consist of high-level function or general intent NOTE: MANDAYS ARE ADJUSTED FOR 40-HOUR WEEK AND 21 alternatives. Further on in the development DAYS PER MANM0NTH "session," the offered alternatives would be at more detailed functional levels, until input PEVEL0PMENT mEEHS. formats, output formats, data base requirements, etc., would be specified at the most detailed REDUCED SKILLS LEVEL level. At every level, however, alternatives offered to the developer by the generator would be simplicity of language - only 38 verbs limited to those consistent with the higher-level selections already made earlier in the "session." AMS verbs, access methods to perform complex DP functions Such a generator cannot, of course, contain all conceivable functions that will (or might) be standard "building block" architecture to desired. This introduces the requirement for guide personnel always being able to select an alternative that is "none of the above." In this case, the developer tabular decision logic eliminates complex would write a new module (or a hierarchy of new implicit logic modules) to fulfill the new requirements. This would be done in a highly standardized and high level, automated, logical debugging structured manner, so that, once implemented and and testing aids tested, the new functions would be automatically added to the applications generator and could then INCREASEP PRODUCTIVITY be selected by subsequent developers.

- 213 - At the completion of the specification process, the generator would bind together the modules of Working at your site and in our offices, we code (which could consist of a combination of deliver programs at $4 per line. We design robust object modules, generated source modules, and systems: easy to use, test and modify. We pay interpretive modules) necessary to perform the attention to detail in coding, documenting and specified functions. This could (and almost always testing. We provide a maintenance warranty. would) be followed by an interactive checkout phase, where either automatically generated or Using off-the-shelf Modular Application Systems user-specified test data would be run through the (MAS) building bricks, the cost reduces to $2 per resulting applications system for verification by program statement, for a system to your exact the developer and by the end user. specification. In some respects, the quality exceeds that of custom built systems: economy of It seems quite feasible to develop such an scale permitting unusual refinement. MAS, being applications generator for a specific type of built to flex, adapts to changing company needs. application, such as inventory control. Although So, over the years, the MAS approach can offer a this could have a significant impact on an better fit that a custom built system, while industry-wide basis, the effect on productivity in avoiding code redundancy. any one given installation would not be revolutionary. It is also conceivable that If only standard MAS modules are used, the generators could be developed for broad sets of resultant system will cost $1 per line. You get applications. A general-purpose generator for all the benefits of MAS: performance proven in on-line transaction systems seems conceivable over 500 implementations, provision for total today, and the development of one such generator integration and honed down operating costs." has been reported in the literature [Maynard 1974]. Given the expected requirements for this Appendix 5 type of applications, such a generator's impact on Software Sharing in the U.S. Federal Government, development productivity could be substantial. Computerworld (1976)

Assuming that such an approach is practical, it is "The Federal Software Exchange Center (FSEC), easy to see how the objectives stated above could intended to foster sharing of programs between be realized. For example, if we look at the federal agencies, is now becoming operational difficulties the end user encounters in trying to under the General Services Administration (GSA) convey his requirements to the system developer, Automated Data and Telecommunications Service. we can see that this approach would help by allowing the end user and the developer to work as Outlined in a Federal Property Management a team in interacting with the generator; Regulation (FPMR 101-32.16) issued last February, conceivably, it could also allow the end user to FSEC's stated goal is to reduce 'overall costs, interact directly with the generator; the time and use of personnel resources for software applications developer would then be needed only acquisition and/or development.' in situations where a new function is required. The FPMR calls for the pooling of information of One of the basic strengths of this approach is the 'common use software' by all federal agencies prestruoturing of the application that is gained 'having [DP] facilities, resources or by the existence of the generator and by the requirements.' initiative the generator retains in its dialog with the developer. One of the severe weaknesses Once gathered, this information is to be the industry currently suffers from is that the maintained in a catalog, published and updated responsibility for initiative in application quarterly by the National Technical Information structuring is vested in the developer and is, Service. therefore, unique for essentially every occurrence of each application. This has defeated most Agencies will be required to search through the previous efforts to use standardized modules as listings of what is available from FSEC before building blocks in new applications. they are allowed to acquire any software from outside sources, according to Chris Bythewood, who It is apparent that this approach is an extreme has organized the operation at GSA. departure from current development techniques. If it is, in fact, necessary to make such a Software covered by the exchange is limited to substantial departure from current methods (and we programs written by agency staffs or by outside believe that it is) in order to solve the contractors working for agencies. Explicitly programmer productivity problem, then we cannot excluded are programs that are classified, overemphasize the need for extensive research and proprietary or 'developed with revolving funds' or development efforts in this area." software 'to which the government does not possess the full rights of ownership', in the language of Appendix 4 the FPMR. Prices for Software Development, Martin Marietta (1976) Though developed with federal funding, programs in the FSEC will be considered 'property' and "SYSTEMS AT $6 $4 $2 $1 PER PROGRAM therefore not in the public domain. Only federal STATEMENT agencies will have access to them, Bythewood said, noting however that the status of the software is In-house programming costs $6 to $10 per line currently under legal review. including testing. We build customer systems at $6 per line: price, performance and delivery Government 'property' cannot be given away (to a guaranteed. You don't save much money but you may nongovernment user, for example) without specific save time and avoid schedule bottlenecks. You do authorization, he explained. On the other hand, an get flexibility, access to specialist skills and agency 'giving away' a copy of a software routine assured results. still has the routine for its own use 'and hasn't

- 214 - lost any real property at all - which makes a very Develop Labor Hours awkward situation, logically and legally," he Analyze Attendance said. Compute Payroll Develop Purchased Material Costs While one part of the FPMR defines what agencies Develop Service and Loading Rates must do to support the creation and maintenance of Develop Labor Rates the FSEC library, another paragraph outlines the Develop Standard Costs expected benefits from use of the exchange and Develop Price another states what can happen if agencies try to Compute Billing bypass using the center altogether." Compute Recoveries Compute Disbursements Appendix 6 Compute Actual Costs Functions Defined by Welsh (1968) SYSTEM CONTROL FUNCTIONS ENGINEERING FUNCTIONS Message Discrimination and Validation Determine System Requirements File Update and Surveillance Determine Logical Design Report Data Compiler Determine Physical Design Data Services Determine Organizational Assignments Determine Procedures RESOURCE CONTROL FUNCTIONS Establish Time Values Determine Labor Classifications Forecast Requirements Coordinate Design Introduction Determine Safety Requirements Determine Net Requirements ADMINISTRATION FUNCTIONS Determine Economic Quantities Aggregate Economic Planning Performance Determination Detailed Economic Planning Performance Evaluation Determine Dispatch Priority Performance Projection Select Vendor Decision Aids and Simulation Determine Changes From Previous Plans Personnel Materiel Planning

H lAHUFACTURlNfi ENTERPRISE

FIGURE 1.1.1 EXAMPLE OF SYSTEM STRUCTURE

- 215 - INSTAL• 3EFINITION DESIGN PROGRAMMING SYSTEM TEST ACCEP• LATION TANCE & OPERA• PHASE PHASE PHASE PHASE PHASE TION PHASE

X3- MANPOWER

GROWTH

A PROGRAMMING

PROGRAM SYSTEM I BASELINE DESIGN

DETAILED DESIGN I

CODE. UNIT TEST (INTERFACES, SYSTEM DOCUMENT

INTEGRATION TEST INTEGRATION INTEGRATION) ^TIVI- PREPARATION TEST riES SYSTEM TEST PREPARATION SYSTEM TEST

X3 ACCEPTANCE TEST PREPARATION DEMON' STRATION

TRAINING CUSTOMER INSTALL & TEST

PROGRAMMING PROGRAMMING 1AJOR PROJECT DESIGN INTE• PRELIM• ACCEP• aocu- PLAN SPECIFI• GRATION INARY PRO• TANCE PROBLEM CATION TEST GRAM DOCU• AGREE• SYSTEMS 1ENT PRODUCT SPECIFI• PROGRAM• MENTATION MENT II LE- SPECI- CATION^ MER'S HAND• FINAL AC• FINAL 5TONES FICATIONl PROGRAM PRODUCT BOOK CEPTANCE PRELIMINARY TEST 8 SITE DOCUMEN- ENERALIZATION. (G ACCEPTANCE TEST SPEC• TATION TESTING. TEST SPECI• IFICATIONS FICATION DOCUMENTATION,

MAINTENANCE) -TIME-

FIGURE 1.3.1 THE PROGRAM DEVELOPMENT CYCLE FlGUREl.1.2 EVOLUTION OF THE PROGRAMMING SYSTEMS PRODUCT

BROOKS, F. P., "THE MYTHICAL MAN MONTH,"ESSAYS ON SOFTWARE METZGER, PHILLIP W., MANAGING A PROGRAMMING PROJECT, PRENTIC-HALL, ENGINEERING- ADDISON-WESLEY, 19/5, 195 pp. INC., NEW JERSEY, 1973, 201 pp.

GENERAL UTILITY

MAINTAINABILITY

HUMAN- POITAIIUIY uuAMurr ENGINEERING MODIFIAMUTY \

/ \/ Ü DEVKE- COMPIETE- ACC Í SSI - AUGMENT- IN- ACCURACY DtfENDENCI NESS IIUTY AIIUIY ! Í1

FIGURE 1,1,1 SOFTWARE CHARACTERISTICS TREE

BOEHM, B. W., J, R, BROWN, H KASPAR, M. Lipow, G. J, MACLEOD,

M, J. MERRITT, "CHARACTERISTICS OF SOFTWARE QUALITY," TRW

SYSTEMS GROUP, REPORT NO. 25201, 6001-R0-0Q, DECEMBER 28, 1973,

- 216 - WORKS MANAGER

USER COMMAND LANGUAGE

INTERFACE

FIGURE 2.3.1 NATIONAL SOFTWARE WORKS BRADEN, R.,"THE NATIONAL SOFTWARE WORKS PROJECT," PROCEEDINGS. SHARF Mil. SESSION C113. IONTREAL, AUGUST 15-20, 1976.

DEC - 10 OPERATING SYSTEM -•-USER INTERFACE

SDVS CONTROL

LANGUAGE TRANS- :ILE MANAGEMENT IMULATION LOAD MODULE PREPARA- IAN MACHINE INTER- LATION FACILITIES FACILITIES PACILITIES TION FACILITIES FACE FACILITIES 'JOVIAL/HBC COMPILER DATA BASE MAN• JNTERPERA- LINKAGE EDITOR SDVS CONTROL LAN• AGEMENT TIVE COM• GUAGE PROCESSOR LOADER 'JOVIAL/DEC-10 COM• PUTER SIM• - SOURCE CODE 'SIMULATION CONTROL/ PILER ULATION MS PARTITIONING - OBJECT CODE SEQUENCING SUPPORT. 'HBC ASSEMBLER - TEST DATA 'STATEMENT 'OUTPUT PREPARATION - SCENARIO LEVEL SIM• - BUS TRAFFIC DEC-10 ASSEMBLER ULATION ANALYSIS - REPORTS 'LIBRARY MAN• AED COMPILER - REAL TIME USAGE - PLOTS AGEMENT 'DATA BUS - CORE ALLOCATION - STATUS FORTRAN COMPILER SIMULATION CONFIGURATION MICRO-CODE TRANS• MANAGEMENT 'SENSOR SIM• LATOR ULATION STATUS AC• COUNTING 'ENVIRONMENT VERSION SIMULATION CONTROL 'MS FUNCTION CHANGE CON• SIMULATION TROL

FIGURE 2.1.1 11A1S SOFTWARF HESIfiN t VERIFICATION SYSTFM (SOTS)

RUTH, J. C.."DAIS¡ THE FIRST STEP," äflECQä. '73, RECORD.

SYSTEM ANALYZER

INTERFACE

AUDITOR

TESTING Î

VALIDATION REPORT TOOLS GENERATOR

TEST RESULTS

TEST STATU:

FIGURE 2.1.2 SEF: PROCESSOR VIEW

IRVINE, C. A., AND J. W. BRACKETT,"AUTOMATED SOFTWARE ENGINEERING

THROUGH STRUCTURED DATA MANAGEMENT," SECOND

INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING,

SON FRANCISCO. OCTOBER 13-15, 1976.

- 217 - DATA DESC SOURCE CONTROL CONTROL DBL DPL

DATA AUS AMS DICTIONARY -DOC -DOC -DOC AMS —DOC GENERATOR COMPILER CONFIRURATOR MONITOR

DATA DICT• DPD DPL RCI IONARY

APPLICA• TION DATA IJSASE^, FIGURE 2.5.1 APPLICATION MANAGEMENT SYSTEM (AMS) WRIGHT. A. W.. "USER EXPERIENCE WITH THE APPLICATION MANAGEMENT SYSTEM (AMS) INFO '75. NEW YORK. SEPTEMBER 9. 1975.

IA KERNEL SYSTEM 103

I. BASIC USER FUNCTIONS BASIC USER SERVICES TSO. JCL. SPF. CONCEPT DEFINITION S MODELING IMS/DC. CRJE, IQF. USER INSTRUCTION t INTERROGRATION REL, GPSS. COURSEWRITER, ETC. II. DATA STRUCTURE OPERATIONS BASIC DATA STRUCTURE OPERATIONS DBDA. IMS. GIS. DIRECT DATA ENTRY VIDEO/370, DOCUMENT/GRAPHICS PROCESSING RPG, ATMS, STAIRS, DATA MIGRATION ETC. III. PROCEDURE OPERATIONS INTERACTIVE PROBLEM SOLVING BASIC, APL, BASIC PROCEDURE OPERATIONS ALC. FORTRAN, COBOL, PL/1, LANGUAGE PROCESSING SERVICES PLAN, VDL, XPL, PROCEDURE TESTING TESTRAN, CLEAR, PROCEDURE MIGRATION ETC. IV. SYSTEM MANAGEMENT FUNCTIONS SYSTEM ADMINISTRATION SMF, RSS, JCL, CONTROL PROGRAM SERVICES OS/VS, RTOS, CICS, ETC.

FIGURE 2,6,1 COMPARABLE FACILITIES IN THE KERNEL SYSTEM AND TODAY'S SYSTEMS

WILSON, M.,"THE INFORMATION AUTOMAT," PROCEEDINGS, SHARE XLVII, SESSION L103, MONTREAL, AUGUST 15-29, 1976.

MANAGEMENT COMMANDS INPUT "FUNCTIONAL" OUTPUT REPORTS ANALYSIS OPERATION PREPAR• ATION

INFORMATION PROCESSING MESSAGES DATA DATA BASE PERSONNEL ACCESS

DATA BASE MANAGEMENT SYSTEM

SOFTWARE PERSONNEL

TARGET SYSTEM USERS

FIGURE 3.2.1 SOFTWARE SUPPORT SYSTEM

- 218 - RESFOR TARSYsf WRITER / NT s~~\r WRITER ^^-s ARGSOF CALL CALLED YcCHSYS ARGS iWRITBY T RESOF ARGOT

^—I , ALL RECORD TYPES $<-L RECORD TYPES ALL RECORD TY°ES • (EXCEPT NUBS. ARGMT, (EXCEPT NUBS, (EXCEPT NUBS, ARGMT, TEXT, PERSON) ARGMTARfiMT,. TEYTTEXT. , TEXT"« , TARGET) TARGET)

SMPTO COMPFR LINKTO LINKFR PARTS PARTOF PRGFL

1 MODULE I— —"-(DH OBJECT H-(6>H PROPRA" f

ALL RECORD TYPES (EXCEPT NUBS) I i

TEXTST ($) j OPRTlj I I TEXT t sunnpi)

FIGURE 3.3,1 DATA STRUCTURE OF SELECTED SUBSYSTEM OF SOFTWARE SUPPORT SYSTEM

SOFTWARE SUPPORT SYSTEM

REQUIREMENTS DEVELOPMENT SUPPORT MANAGEMENT DATA DETERMINATION BASE

SOFTWARE SOFTWARE OPERATION INSTALLATION ENGINEERING PRODUCTION FACILITY & MAINTENANCE

FIGURE 3.1.1 MAJOR SUBSYSTEM OF SOFTWARE SUPPORT SYSTEM

- 219 - PRODUCE INVOICE

CUSTOMER NAME:ALL GM CUSTOMER NAME CLASS .. ITEM a QUANT. ITEM * QUANT. I. COST AMOUNT

TOTAL DISCOUNT TOTAL DUE ORDER 1 CUSTOMER NAME: ALL AB£ CUSTOMER NAME:ABC CLASS r ¡ CALCULATION ITEM » QUANT. ITEM # QUANT. I. COST AMOUNT 55 SUM.ALL 15 55 SUM.ALL 15 2 61-2XSUM.ALL 15

TOTAL SUM ALL 61

DISCOUNT SUM ALL (il x 3 i TOTAL DUE SUM ALL I.Í - CONDITION CALCULATION SUM ALL C] x 31 CLASS DISCOUNT 7_ m A lot ITEM MASTER B 5% ITEM # PRICE C 0% 55 2 CONDITION CALCULATION CUST. MASTER j CUST. RATING DISCOUNT CUST RATING EJf - 5» » ABC EX. FAIR 4» GOOD 51 EXCELLENT et

FIGURE 1.3.1 EXAMPLE OF SBA PROGRAMS TO PRODUCE AN INVOICE

ZLOOF, ,1. 1. AND S. PETER DE JONG. "THE SYSTEM FOR BUSINESS

AUTOMATION (SBA): PROGRAMMING LANGUAGE." COMMUNICATION

OF THE ACM. 1977.

1 CONTROL CONTROL DESTINATION

_J . 1 1 SEQUENCE OPERATION 1 CONDITION CALCULATION

E L E S L E S E SCHEDULE SEQUENCE ACTION CONDITION OPERATION OBJECT

(INFORMATION) (SEQUENCE) (INVOCATION) OPERATION CREATE CO TO SEND DESTROY END (MANUAL) INITIALIZE EXIT DESTINATION (TRIGGER) INSERT (DELAY) DELETE (RESIDUE) UPDATE

XXX - can be any program name.

FIGURE 1.3.2 SUMMARY OF SBA PROGRAMMING LANGUAGE

ZLOOF. M. M. AND S. PETER.DE JONG, "THE SYSTEM FOR BUSINESS AUTOMATION (SBfi):, PROGRAMMING LANGUAGE, COMMUNICATION OF THE ACM, 19/7.

- 220 - SYSTEM DEVELOPMENT SYSTEM DEVELOPMENT (CONVENTIONAL) HSL/1

SYNTHESIS APPROACH

FUNCTION SPECS CONFIGURATIONS FILE DESIGN PROGRAM DESIGN AND AND SPECIFICATION SPECIFICATION

SYNTHESIZE

SOLUTION PROGRAM CODING DEVELOP-

TABLEMASTER SATISFIER NEED LIBRARY ASSEMBLE ID RECORD PROCEDURE SYSTEM ED LAYOUTS IVISION DD D PROGRAM TESTING FS

PROGRAM TESTING TESTMASTER FIGURE 4.3.3 HOSKYNS SYSTEM LANGUAGE HSL/1 FIGURE 5.11.1 RHODES, J,, BEYOND PROGRAMMING: PRACTICAL STEPS TOWARDS THE AUTO• WELSH, W. A., "ENGINEERED DESIGN OF EDP SYSTEMS," PROCEEDINGS SYSTEMS MATION OF DP SYSTEM CREATION." (1972), SVSTFM AMIYBIS TTFCHNIOUFF S tun PunrrnuRES ASSOCIATION. INTERNATIONAL MEETING, "IISSOURI, UCTOBER 1968. PP. 328-335.

j CPL-A Language * Proceeeor |

Program Module Data Base Control System

»ppl1i ieet 100 Applicatioi Application r FielIdd A Field X Field Y User • F -Control Integrity Program Retrieval module

Compilation

• Security

j CPl-B Language * TPO1S"| I Related Methodologies and Tools

o Interface atandarditation o Document production 1 o Syntax check o Module test ar.d-evaluation o Ptogram analysis

o Prograa optimization o Revision of modulariza- o Program estioation

o Interface check o Debugging function

a Program sioulation o Programmaing support

o Performance analyaia o Project control

Cirapiler test and •.•valuation ri Ickiating t OS 1 I I « 2 . I Compiler I I Compilar I programa! ^L..: - J L

FIGURE 5,6.1 PROGRAMMING PRODUCTIVITY DEVELOPMENT SYSTEM (PPDS) IT SYSTEM DEVELOPMENT CORPORATION/ "AN OUTLINE OF THE PROGRAMMING PRODUCTIVITY DEVELOPMENT SYSTEM, (PROS), TOKYO, DECEMBER 19/6

- 221 -