REP llllllllllllllllllllllillllllllllllllllll LM095611 COMPTROLLER GENERAL. OF THE UNlYED STATES WASHINGTON. D.C. 20548 B-115369 To the President of the Senate and the Speaker of the House of Representatives This is our report on the acquisition and use of software products for automatic data processing systems in the Federal Government. Our review was made pursuant to the Budget and Accounting Act, 1921 (31 U.S.C. 53)> and the Accounting and Auditing Act of 1950 (31 U.S.C. 67). Copies of this report are being sent to the Director, Office of Management and Budget; Administrator of General Services; Director, National Bureau of Standards; and the heads of-Federal departments and agencies, Comptroller General of the United States 50TH ANNWERSARY 1921.1971- I COMPTROLLERGENERAL'S ACQUISITION AND USE OF SOFTWARE REPORT TO THE CONGRESS PRODUCTS FOR AUTOMATIC DATA PROCESSING SYSTEMS IN THE FEDERAL GOVERNMENT I B-115 369 DIGEST ------ WHY THE STUDY WAS MADE Software is a term that has come into use with automatic data processing (ADP) systems to identify computer programs, procedures, and related documentation and to distinguish such features from the hardware components of the systems. I It is estimated that Federal agencies are spending between $2 billion and $3 billion a year for acquisition and in-house development I of software. The General Accounting Office (GAO) studied the current method of developing, acquiring, and using software products because of the level of annual eeenditures and the apparent lack of coordinated management guidance over such acquisitions. PRINCIPAL FINDINGS Many broad management problems were found during the GAO study. One important problem that was not receiving adequate management atten- tion involved the change which was taking place with regard to the way computer services were being marketed to the Federal Government by the computer vendors. The acquisition of software from computer manufac- turers has usually been an unidentifiable part of the total price of a computer system. During the past few years, many changes in marketing practices by computer manufacturers have occurred. These included the separate . 1 pricing (unbundling) of software products, the introduction of diverse I contractual arrangements for acquiring software, the advent of general- purpose proprietary software packages, and the licensing of use of * I software products with overly restrictive provisions. The Federal Govern- ment has had no centrally guided or unified approach for dealing with these changes. (See ch. 2.) Tear Sheet JUNE30,1971 t I I 1 I L I L ’ . I * I * Federal users, For the most part, separately acquired their I I needed computer software without centralized direction or guidance. I As a result, they have: I I I --Procured computer programs unnecessarily since they I were already available at other data processing I locations within the Government. (See p.22) I I / --Procured software products with overly restrictive- I use provisions and thereby required additional ? software procurements in multiuse instances. (See p.23.) I I I = --Acquired like computer programs at varying prices within t a relatively short period of time. (See p. 22) I I I --Deprived the Government of an opportunity to benefit I from quantity procurements. (See p. 23.) I I I --Used various criteria and techniques for selection I and evaluation of computer software which resulted I I in the acquisition of many variations (some being I better than others) of the same product. (See p. 24) I I I --Duplicated unnecessarily technical evaluations of I I i computer programs. (See p. 24) I I rI The acquisition practices followed by Federal agencies were I I necessitated because of limited activity by central management agencies I of the Government in providing policy guidance for acquiring and utilizing I computer software. (See ch. 5.) I There is a definite need for: I --More positive central guidance and more effective t I procurement regulations specifically directed to I software acquisitions. I I I --Future planning of software requirements on a Govern- I ment-wide basis. I I I --Coordinated research in software development. I I I --Better communications between the central manage- I ment levels of the Government and the Federal agencies I l with data processing systems. I I I I * I I I I I I I I I I I I I I I I I --More effective use of E'ederal Supply Schedule contracts in software procurements. --Use of the ADP revolving fund administered by the General Services Administration (GSA) to acquire generalized software packages for Government-wide application. Q/ --Better procedures specifications. for more clearly defining software i I --A catalog, inventory, or central reference index of computer programs that have been developed, tested, or in use by the Government. --Software standards which would promote greater inter- changeability of computer programs among Federal data processing installations. --Better quality of software documentation which would facilitate reuse of computer programs. GAO believes that, to better manage the vast resources invested in data processing facilities, the Federal Government needs a master plan. Such a plan would include agreed-upon goals or objectives against which quality and progress could be measured. It would provide resource planning, implementation procedures, and appraisal and feedback procedures. The central agencies of the Federal Government should provide the guidance and leadership necessary for procuring computer software as efficiently and economically as possible. Management of ADP resources, however, involves more than procurement. Thus existing policy directives, such as Office of Management and Budget (OMB) Circular A-54, need to be amended to include policy guidance on software management. The Federal Government-- as the largest single user of ADP--should adopt a policy against restrictive-use provisions in contracts for computer programs that it acquires and should consider all alterna- tives available for satisfying computer software needs. (See ch. 3.) I *I Substantial savings can be realized by the Federal Government through proper evaluations, acquisitions, and uses of generalized computer software packages as tools for expediting its data processing activities. The National Aeronautics and Space Administration has reported annual savings of $2.3 million from such practices. (See ch. 4.1 I I I : I L I I I I I Substantial savings can also be realized through the use of a I I single-purchaser concept whereby one agency would acquire and manage I all software products of a similar nature. This would provide for I I bulk procurement, single evaluation, and elimination of duplication I as well as better procurement techniques. I I I I RECOMMENDATIONSOR SUGGESTIONS /) GAO recommends that the Director, Office of Management and Budget, I I arrange for the formulation of a master plan for the acquisition and I ” use of software and the structure needed to implement the plan. GAO I recommends also that OMB Circular A-54 be amended to include specific I I policy guidance to user agencies for the acquisition, management, and I use of software throughout the Federal Government. I I I Relative to the guidance and leadership necessary for the I I procurement of software, GAO recommends further that the: I I --Director, Office of Management and Budget provide I I coordinated management and central policy direction I to users for determining the most economical I I and efficient means for obtaining computer software. I I I --Administrator of General Services employ the single- I purchaser concept, use formally advertised procurement I contracts, strive to obtain nonrestrictive or license- I I free contractual arrangements for software with rentals I based on use, consider buying outright software pro- I I ducts that would be widely used throughout the Government, I and maintain an inventory of computer software. I I I --Director of the National Bureau of Standards establish I and maintain a reference index of computer programs, I I make detailed technical evaluations of computer programs I for use by all Federal ADP installations, and promulgate I I Federal standards for computer languages and program I documentation. I I I In addition, GAO recommends that, pending the issuance of more I specific policy guidance, the operational and cost factors described ID I in this report be used by Federal agencies in reaching decisions on I software needs. (See app. V.) I I * I I I I I I I I I I I I I 4 I I I AGENCY ACTIONS AND UNRESOLVED ISSUES Some of the management problems associated with acquisition and use of computer software in the Federal Government have been recognized and discussed at two Federal interagency conferences sponsored by OMB in 1969 and 1970. GAO believes that the practice of holding these conferences should continue and the conclusions I and recommendations be formalized in writing. OMB has advised that it plans to issue instructions to guide executive departments and agencies in software acquisition. 'These instructions, coupled with the actions recommended in this report, should provide the guidance and leadership needed in the procurement and use of software products., MATTERS FOR CONSIDERATION BY THE CONGRESS The Joint Economic Committee and the House Government Operations Committee have had an active interest in computer procurement and management problems for some time. Both committees have held hearings within the past year on the subject. This report contains a description and analysis of numerous management problems pertaining to the sub- stantial annual expenditures of the Government for computer software products together with recommendations to executive branch agencies for strengthening management practices. Accordingly, GAO suggests that the Congress explore these matters with the executive branch for the purpose of obtaining improvements in the Government operations in this area. Tear Sheet Contents Page DIGEST 1 CHAPTER 1 INTRODUCTION Some definitions Scope of study Scope of software problems Appendixes to this report 2 SEPARATE PRICING FOR COMPUTER SERVICES (UNBUNDLING) 11 Impact on Federal Government 12 Recommendations 13 3 RESTRICTIVE-USE LICENSES ON PROPRIETARY SOFTWARE PRODUCTS 14 Potential for increased costs to the Government 17 Recommendations 17 4 ACQUISITION AND USE OF PROPRIETARY SOFTWAREPRODUCTS 19 Need for active GSA participation in software procurements 19 Automatic flowcharting software 20 File management software 21 Information retrieval software 21 Simulation software 21 Compilers 22 Applications software 22 Savings available to the Federal Government through use of proprietary software packages 25 Potential for savings 26 Recommendations 27 5 OTHER SOFTWAREMANAGEMENTPROBLEMS 28 Central guidance 29 Procurement regulations 29 Inventory of computer software in Government 31 Catalog of available programs 31 Technical evaluations 31 Software standards 32 Planning needed for future software requirements 32 Coordinated research 33 Communication between central management and users 33 Delegations of authority by GSA 34 Awards of Federal Supply Schedule contracts for software 34 Page CHAPTER The Federal Supply Schedule for ADP procurements 35 Use of the ADP revolving fund 35 Specifications 36 Software documentation 36 Need for stronger central guidance 37 Recommendations 37 GSA, NBS and OMB comments 38 APPENDIX I COMPUTERSOFTWARE--AN OVERVIEW 41 Growth in use of ADP systems 41 Evolution of software 42 Operational systems concept 43 Software developed in-house 45 Software exchange libraries 48 Software firms 51 II FEDERAL MANAGEMENTPRACTICES FOR COMPUTERSOFTWARE 55 Office of Management and Budget 55 General Services Administration 56 Guidance to users for procuring software 57 National Bureau of Standards 58 Duplication of effort 59 Standards 60 Communication-- A problem in the management of software 61 Policy guidelines 62 Regulations 62 Inventory 63 III PROCUREMENTOF COMPUTER SOFTWARE 64 Federal Supply Schedule contracts 64 GSA delegations of procurement authority 66 ADP fund 66 Individual agency headquarters control-- a step toward central management 67 Software for subordinate installations 67 Software for agencywide applications 68 Software for grantees 68 IV EXAMPLES OF GOVERNMENTORGANIZATIONS USING PROPRIETARY SOFTWAREPACKAGES 71 MARK IV File Management System 71 Page APPENDIX AUTOFLOW 76 QWICK-QWERY 82 NAVFLOCHART-C 83 GOCHART 85 SCERT (COMET) 86 AUDITAPE 87 V FACTORS TO BE CONSIDERED IN MAKING SOFTWAREACQUISITION DECISIONS 88 Types of need 88 Methods of satisfying needs 89 Characteristics and reliability of software products 89 Hardware considerations 90 Quality of documentation, training, and maintenance 91 Contractual terms 92 Financial factors 92 VI PLANNING NECESSARY FOR FUTURE MANAGEMENTOF SOFTWARE 94 Growth in need for technical personnel 94 Need for standardization and compatibility 95 Use of computational research 97 Need for improvements in computer applications 99 Need for planning mechanisms 100 VII MANAGEMENTCONTROL 101 Need for software management 101 VIII RESUME OF PRIOR GAO GOVERNMENT-WIDE ADP MANAGEMENT REPORTS 102 June 1958 102 December 1960 102 March 1963 102 April 1964 103 August 1965 103 April 1968 103 June 1969 104 ABBREVIATIONS ADP Automatic Data Processing COBOL Common Business Oriented Language I FORTRAN Formula Translator Language FPMR Federal Property Management Regulations GAO General Accounting Office GSA General Services Administration IBM International Business Machines Corporation NASA National Aeronautics and Space Administration NBS National Bureau of Standards OMB Office of Management and Budget' RCA Radio Corporation of America i 1OMB was formerly known as the Bureau of the Budget prior to July 1, 1970. Throughout this report we have referred to this office as OMB. COMPTROLLERGENERAL'S ACQUISITION AND USE OF SOFTWARE REPORT TO THE CONGRESS PRODUCTS FOR AUTOMATIC DATA PROCESSING SYSTEMS IN THE FEDERAL GOVERNMENT B-115369 DIGEST ------ WHY THE STUDY WAS MADE Software is a term that has come into use with automatic data processing (ADP) systems to identify computer programs, procedures, and related documentation and to distinguish such features from the hardware components of the systems. It is estimated that Federal agencies are spending between $2 billion and $3 billion a year for acquisition and in-house development of software. The General Accounting Office (GAO) studied the current method of developing, acquiring, and using software products because of the level of annual expenditures and the apparent lack of coordinated management guidance over such acquisitions. PRINCIPAL FINDINGS Many broad management problems were found during the GAO study. One important problem that was not receiving adequate management atten- tion involved the change which was taking place with regard to the way computer services were being marketed to the Federal Government by the computer vendors. The acquisition of software from computer manufac- turers has usually been an unidentifiable part of the total price of a computer sys tern. During the past few years, many changes in marketing practices by computer manufacturers have occurred. These included the separate pricing (unbundling) of software products, the introduction of diverse contractual arrangements for acquiring software, the advent of general- purpose proprietary software packages, and the licensing of use of software products with overly restrictive provisions. The Federal Govern 1- ment has had no centrally guided or unified approach for dealing with these changes. (See ch. 2.) Federal users, for the most part, separately acquired their needed computer software without centralized direction or guidance. As a result, they have: --Procured computer programs unnecessarily since they were already available at other data processing locations within the Government. (See ~~23.1 --Procured software products with overly restrictive- use provisions and thereby required additional software procurements in multiuse instances. (See p.23.) --Acquired like computer programs at varying prices within a relatively short period of time. (See p.23.) --Deprived the Government of an opportunity to benefit from quantity procurements. (See p-23.) --Used various criteria and techniques for selection and evaluation of computer software which resulted in the acquisition of many variations (some being better than others) of the same product. (See p-24.) --Duplicated unnecessarily technical evaluations of computer programs. (See pa 24.1 The acquisition practices followed by Federal agencies were necessitated because of limited activity by central management agencies of the Government in providing policy guidance for acquiring and utilizing computer software. (See ch. 5.) There is a definite need for: --More positive central guidance and more effective procurement regulations specifically directed to software acquisitions. --Future planning of software requirements on a Govern- ment-wide basis. --Coordinated research in software development. --Better communications between the central manage- ment levels of the Government and the Federal agencies with data processing systems. 2 --More effective use of Federal Supply Schedule contracts in software procurements. --Use of the ADP revolvinq fund administered by the General Services Administration (GSA) to acquire generalized software packages for Government-wide application. --Better procedures for more clearly defining software specifications. --A catalog, inventory, or central reference index of computer programs that have been developed, tested, or in use by the Government. --Software standards which would promote greater inter- changeability of computer programs among Pederal data processing installations. --Better quality of software documentation which would facilitate reuse of computer programs, GAO believes that, to better manage the vast resources invested in data processing facilities, the Federal Government needs a master plan. Such a plan would include agreed-upon goals or objectives against which quality and progress could be measured. It would provide resource planning, implementation procedures, and appraisal and feedback procedures. The central agencies of the Federal Government should provide the guidance and leadership necessary for procuring computer software as efficiently and economically as possible. Management of ADP resources, however, involves more than procurement. Thus existing policy directives, such as Office of Management and Budget (OMB) Circular A-54, need to be amended to include policy guidance on software management. The Federal Government-- as the largest single user of ADP--should adopt a policy against restrictive-use provisions in contracts for computer programs that it acquires and should consider all alterna- tives available for satisfying computer software needs. (See ch. 3.) Substantial savings can be realized by the Federal Government through proper evaluations, acquisitions, and uses of generalized computer software packages as tools for expediting its data processing activities. The National Aeronautics and Space Administration has reported annual savings of $2.3 million from such practices. (See ch. 4.) Substantial. s;iv?lnr;c 7an alsia be realized tnrovi~h the use of a single-purchaser conce~~t where'by one agency would acquire and manage all software products of a similar nature, Thi,? would provide for bulk procurement, sinqle evaluation, and elimination of duplication as well as better FrOC?lrement techRiqUeS. RECOMMENDATIONSOR SLJGGCSTIONS __- GAO recommends that the Director, Office of Management and Budget, arrange for the formulation of a master plan for the acquisition and use of software and the structure needed to implement the plan. GAO recommends also that OMB Circular A-54 be amended to include specific policy guidance to user agencies for the acquisition, management, and use of software throughcut the Federal Government. Relative to the guidance and leadership necessary for the procurement of software, GAQ recommends further that the: --Director, Office of Xanagement and Budget provide coordinated management and central policy direction to users for determining the most economical and efficient means for obtaining computer software. --Administrator of General Services employ the single- purchaser concept, use formally advertised procurement contracts, strive to obtain nonrestrictive or license- free contractual arrangements for software with rentals based on use, consider buying outright software pro- ducts that would be widely used throughout the Government, and maintain an inventory of computer software. --Director of the National Bureau of Standards establish and maintain a reference index of computer programsI make detailed technical evaluations of computer programs for use by all Federal ADP installations, and promulgate Federal standards for computer languages and program documentation. In addition, GAO recommends that, pending the issuance of more specific policy guidance, the operational and cost factors described in this report be used by Federal agencies in reaching decisions on software needs. (See app. V.! AGENCY ACTIONS AND UNRESOLVED ISSUES Some of the management problems associated with acquisition and use of computer software in the Federal Government have been recognized and discussed at two Federal interagency conferences sponsored by OMB in 1969 and 1970. GAO believes that the practice of holding these conferences should continue and the conclusions and recommendations be formalized in writing. OMB has advised that it plans to issue instructions to guide executive departments and agencies in software acquisition. These instructions, coupled with the actions recommended in this report, should provide the guidance and leadership needed in the procurement and use of software products. MATTERS FOR CONSIDERATION BY THE CONGRESS The Joint Economic Committee and the House Government Operations Committee have had an active interest in computer procurement and management problems for some time. Both committees have held hearings within the past year on the subject. This report contains a description and analysis of numerous management problems pertaining to the sub- stantial annual expenditures of the Government for computer software products together with recommendations to executive branch agencies for strengthening management practices. Accordingly, GAO suggests that the Congress explore these matters with the executive branch for the purpose of obtaining improvements in the Government operations in this area. 5 CHAPTER 1 INTRODUCTION During the early years of computer development, management had difficulty keeping abreast of rapid changes and was preoccupied with the acquisition and application of the costly machines. The increased complexities of programming, the shortage of programmers, the increased cost of this effort to the point where it surpassed the cost of the machines, and the new marketing trends, all contributed to a need to inquire into how well the Federal Government was managing this resource. To this end, the General Accounting Office has studied, on a Government-wide basis, the acquisition and management of computer software. SOME DEFINITIONS Computer software consists of programs, routines, codes, and other written information used with computers, as distinguished from computer hardware. A software package-- also commonly referred to as a computer program or software product--is an accumulation of fixed sets of instructions expressed in a specific manner and assembled into one unit along with the related written material which instructs computer machinery to react in a specific manner when processing data. These packages are generally categorized as: --Systems software which controls the execution of computer programs and which may provide scheduling, debugging, input/output control, accounting, compila- tion, storage assignment, data management, and re- lated services. --Utility software which provides for file creation and maintenance capabilities, information retrieval, report generation capabilities, applications pro- gramming aids, systems evaluation techniques, etc. --Applications software which provides capabilities for performing specific data processing functions such as payroll, inventory control, accounting and statistical work, and any other data processing activity to which the computer is applied. SCOPE OF STUDY . i Our study concentrated on the Government-wide policies and practices followed in acquiring and managing software products, particularly general purpose software that can be reused by 6 others. Excluded were those programs prepared for unique applica- tions. This study did not consider the extent and type of utiliza- tion of the computer software products. More specifically, we examined into the: --Policies established by the Office of Management and Budget and the General Services Administra- tion regarding the acquisition of computer software. --Activities of GSA and the National Bureau of Standards in the procurement of computer software under Public Law 89-306--an act which provides for the economic and efficient purchase, lease, maintenance, operation, and utilization of automatic data processing equip- ment by Federal departments and agencies. --Marketing of software by the computer industry. --Policies and practices of Federal and commercial user organizations relative to the selection, procure- ment! and management of computer software in lieu of in-house development of such software. --Savings available to the Government if software packages were obtained as an alternate method of satisfying computation requirements. --Savings available to the Government through a single-purchaser concept for the procurement of software packages in lieu of acquisitions by in- dividual agencies of the Government. --Factors affecting decisions concerning the acquisition and use of generalized computer software packages. The conclusions and recommendations resulting from this study have been reviewed with officials of OMB, GSA, and NBS and their views were considered in the preparation of the report. This report is one of a series dealing with ADP management in the Federal Government. L The more recent reports in this series concerned the acquisition A peripheral equipment for use with ADP systems and the maintenance of ADP equipment used by the Federal Government. Appendix VIII provides an overview of the Goverrunent- wide ADP reports issued by GAO. SCOPE OF SOFTWAREPROBLEMS The use of data processing services by the Federal Government has increased at a very rapid rate. At June 30, 1960, there were 531 general-purpose computers in use in the Government, and this number increased tenfold to 5,277 computers by June 30, 1970. The annual Federal expenditure for ADP operations cannot be readily determined. In congressional hearings conducted during July 19701 it was estimated that the Federal Government was spending from $4 billion to $6 billion annually for ADP activities. Software is estimated by the ADP community to equal more than one half of the total ADP costs. Thus we conservatively estimate that the Federal Government spends in excess of $2 billion annually for computer software. Computer software, as we know it today, is the product of many years of development and improvement. The manufacturers of computer systems have provided, for a stipulated price, a total operational system which included equipment, software and services. Data processing requirements of many of the larger users of computers required special programs beyond the software services provided by computer manufacturers. To satisfy these software needs, larger organizations developed in-house programming capabilities. The preparation of software by various individual organizations without coordination with other users has led to some duplication of effort. In an attempt to avoid duplications of effort, software exchange libraries were established and sponsored by computer manufacturers, users, and the Federal Government, to foster reuse of computer pro- grams that were already developed. At times, reuse was not achieved because of the expense and effort needed to modify the original programs. Difficulty or impracticability of modifying programs for reuse was attributed, in part, to the inadequate documentation (written support of the coded machine instructions) that accompanied the programs. Another source of programming services was the firms of software specialists who were hired to provide these services on a contractual basis. A by-product of the work of the soft- ware firms was the emergence of general-purpose proprietary computer software products. As a result of this development, a potential source of reusable computer programs became available to all computer users with similar equipment. In the summer of 1969, some computer manufacturers adopted the concept of separate pricing of computer hardware, software, and related services. This marketing strategy has been widely 1Hearing before the Subcommittee on Economy in Government of the Joint Economic Committee, 91st Cong., 2d sess., dated July 1, 1970, pp. 17 and 18. 8 described as "unbundling." Under this concept, computer manufacturers sell equipment, software, and other services separately. Additionally, software concerns are marketing proprietary software products for use with hardware provided by the computer manufacturers. Both the computer manufacturers and software firms have imposed certain restrictions on the use of these software products in an effort to protect their proprietary interests. These restrictions, as well as matters relating to the acquisition and management of reusable software, present problems that must be considered in Government-wide management of computer software. APPENDIXES TO THIS REPORT Appendix I provides an overview of the growth in use of ADP systems and the evolution of computer software as a separate marketable product. It explains how software that is not provided by computer manufacturers under their total operational systems concept can be obtained. It also discusses the duplications of effort that can result from uncoordinated in-house programming activities by the many data processing installations of the Federal Government. (See p. 4~) Appendix II discusses the Federal management policies for the acquisition and use of computer software as set forth in Public Law 89-306 (Brooks Bill) I and the lack of development of these policies by the responsible central management agencies of the Federal Government. This appendix recognizes the need for more effective means of coordination in the Government-wide manage- ment of ADP facilities, and the need for an inventory of software. Appendix II recognizes further that central policy guidelines for computer software, similar to those that were issued in OMB circulars and bulletins for computer hardware , need to be established to promote effective Government-wide software acquisition and management de- cisions. (See p.55.) Appendix III discusses the extent to which policies, plans, and techniques have been coordinated by the departments and agencies of the Federal Government in the procurement and use of computer software, and points out a need for the establishment of a single- purchaser concept for the acquisition and management of software used on a Government-wide basis. (See P.64.) Appendix IV presents examples of proprietary software packages that have been independently procured by Government agencies to satisfy their immediate data processing needs. These examples demonstrate unnecessary duplications of effort, varied contractual arrangements, contracts that provide un- warranted restrictions on use of software products, and factors resulting in large unnecessary additional costs emanating from uncoordinated efforts by the individual Government agencies for the procurement and use of such software products. (See p.71 .I Appendix V suggests some measures to be considered in the acquisition and management of computer software by the operating agencies of the Federal Government. (See p. 88.) Appendix VI points out the need for the Federal Government to capitalize on its investment in computer software and the need to establish a planning mechanism for the future management of software used in Federal data processing activities. This appendix discusses the phenomenal growth in demand for technical data processing personnel; the lack of standardization and compatability in computer software used by the Federal Government; the failure to capitalize on and centrally coordinate computational research sponsored by the Government; and the need for improvements in computer applica- tions in an effort to use the full potential of data processing capabilities of installed equipment. (See p. 94 .) Appendix VII discusses the need for management control over software. (See p.lO1.) Appendix VIII presents a resume of prior Government-wide ADP management reports issued by GAO. (See p. 102.) 10 CHAPTER 2 SEPARATE PRICING FOR COMPUTER SERVICES (UNBUNDLING) Since the beginning of the computer industry, it has been a common practice for most computer manufacturers to include software, engineering support, and educational services as part of the price of hardware. This technique of single pricing for automatic data processing equipment and related services was one of the issues in- cluded in antitrust suits against the International Business Machines Corporation (IBM) instituted by the Federal Government and other private organizations. Some of these suits are still pending. In June 1969, IBM introduced a substantial change in its pricing policy. The new concept, commonly referred to as "unbundling," is a restricted form of separate pricing which provides for pricing computer hardware, utility and applications software, certain engineer- ing services, and most customer education programs separately. The control programs (systems software) and related maintenance were not separately priced. The manufacturer indicated that these items were an integral part of operational hardware components. Additionally, IBM has not unbundled hardware maintenance for rented computers. Although IBM has historically provided leadership in the pricing structure used by most computer equipment manufacturers, not all manufacturers followed the newly established policy. An analysis of the action taken by seven other manufacturers, as of January 1971, showed that three manufacturers have unbundled and four others still offer the operational systems concept to their customers. In addition, one of the three manufacturers that unbundled also separately priced maintenance. Other variations have also occurred in marketing strategy as a result of the separate-pricing announcement. For example, the fiscal year 1971 Federal Supply Schedule contract with the Radio Corporation 'df America (RCA) offers both the separately priced and system-priced concepts for certain of its computer models. Government users are given the option to determine the pricing arrangement to be applied to their new acquisitions. The prices that manufacturers charge for each element of a system under the separate-pricing policy do not necessarily relate to the prices charged under the total-system concept. For example, under the separate-pricing concept, IBM announced that its hardware would cost 3 percent less than the former total-system price. IBM, however, assigned a variety of prices for certain software, engineering services, and education. A user who needs only the hardware stands to spend 3 per- 11 cent less than he formerly did but users in need of separately priced services may spend more than they previously did for the same services obtained under the total-system pricing concept. It is generally re- cognized that the rates announced for separate pricing resulted in a total-system price increase for the average user. There is much speculation as to the advantages and dis- advantages of separate pricing. We visited several non-Government ADP users and have elicited comments on the expected impact of these new marketing trends. Generally, these users were of the opinion that ADP costs will increase, but there was no evidence available to relate the expected increase to separate pricing. Most non-Government computer users believe that separate pricing will force them to reevaluate their method of operation to minimize the projected increase in ADP operating costs. As a consequence, they foresee more emphasis on justifying requirements, expanding in- house capabilities, and increasing consideration given to alternate sources when procuring software and other support services. The overall effect of separate pricing on the data processing operations of the Federal Government cannot be evaluated at the present time. On the basis of the announced changes in marketing practices to date, we believe that the most important change will be the opportunity to procure only the services that are needed. Related to this change, however, is the question of whether the cost reduction for the main hardware in a computer system is commensurate with the reduced services and whether the restrictions on the use of software products will afford the user the most economical and efficient means for satisfying data processing needs. IMPACT ON FEDERAL GOVERNMENT The Federal Government, as a whole, is considered the largest single user of ADP systems. The Government ADP community, how- ever, is comprised of many small and large users who operate as independent entities. The impact of separate pricing on each in- dividual user will vary according to circumstances. Large users, for example, are apt to have large in-house capabilities. The separate pricing concept will favor these users since it will not be mandatory for them to separately procure programming, engineering, or educational services. The small user, on the other hand, may not have such in-house capability and therefore will be dependent on providers of such separately priced services. 12 To benefit fully from separate software pricing, to promote in- house self-sufficiency to the optimum degree, and to establish a more effective procedure regarding the acquisition of computer products, there is need for more management attention toward ascertaining the most efficient, effective, and economical method of acquiring computer software for use with Federal ADP systems. Under the framework of the Brooks Bill, each using agency is responsible for determining its own ADP needs. Therefore these agencies need to: --Critically evaluate their requirements, especially software services which are separately priced. --Consider the optimum use of in-house programming capabilities. --Consider all alternate sources for satisfying software requirements. In this latter connection, user agencies need to make detailed cost analysis studies and apply other evaluative techniques to properly select the most advantageous sources for software and to support the make or buy decision. RECOMMENDATIONS GSA, as the Government agency responsible for the procure- ment-of ADP services, must provide the leadership in negotiating with software suppliers and must guide Federal agencies to capitalize on the benefits of unbundled software. For these reasons, we re- commend that the Administrator of General Services: --Strive to obtain the most favorable prices and terms for software products from all available sources. --Consider buying outright the computer software products which are used widely in data processing operations throughout the Federal Government and make such soft- ware available to user agencies on an as-needed basis. --Provide direction for utilizing some of the available Government in-house capabilities to develop common- use programs when favorable prices are not available. --Create joint use in-house capabilities to satisfy the programming and support service requirements of users. --Provide guidance to user agencies as to the best way of satisfying software needs. 13 CHAPTER 3 RESTRICTIVE-USE LICENSES ON PROPRIETARY SOFTWAREPRODUCTS The suppliers of general-purpose computer programs are in some cases restricting the use of their proprietary products to specific central processing units or data processing locations, or for use within certain elements of an organization. Some vendors of software products offer terms that are more restrictive than others. The Federal Government--the world's largest user of computer systems--procures many of the same general-purpose software products to satisfy its data processing needs. The unnecessary costs attributable to the restrictive use of software products are not easily measurable at the present time due to the lack of an inventory of such products being used by the Government. Increased acceptance of various types of restrictive-use licenses by the Federal Government will result in more costly data processing activities than if the Government could purchase these products outright or have the ability to freely use the products within the Government on an as-needed basis. In order to realize the most economical and efficient use of proprietary soft- ware products, the Federal Government must be free to acquire and use commercially available software products with as little restriction as possible. In its June 1969 separate-pricing announcement, IBM stated that certain types of computer programs would no longer be furnished as part of the hardware price but must be obtained separately. These programs were not offered for sale. Instead, IBM announced that it would copyright all newly developed program products and would execute a standard license agreement with its customers, restricting the use of its program products to specific central processing units within a data processing installation. Among other things, all data pro- cessing users that accept the IBM program products under the terms of the license, agree that: --Use of a computer software product is limited to a specific computer system (single central processing unit). --The user must pay the full monthly rental for each software package used, with no discounts for multiple use of the programs. For some programs an initial charge is paid for each program at the time of in- stallation. A minimum of 3-months rental must be paid before a license can be terminated. 14 --The manufacturer can change the monthly rate for use of its programs at any time, discontinue the license agreement upon 6-months notice, and does not guarantee the results of using its programs or assume any liability for consequential damages as a result of using the subject computer software. --The user cannot make more than five copies of a program or its related documentation, distribute such copies to anyone outside of the data pro- cessing center, and must destroy all copies made upon discontinuance of use of the programs. As to software vendors, our study showed that in the past some vendors have sold their respective computer programs outright. We have been informed by several vendors of computer software products that there is now a general tendency throughout the industry not to execute outright sales of products, as control over their pro- prietary rights would be too difficult to manage. Additionally, outright sales create a problem in the maintenance of software. The user of a proprietary package usually does not receive the necessary documentation or source data to perform updates, modi- fications, or other maintenance activities on the programs. On the other hand, the user of a leased package is provided certain contractual maintenance arrangements by the vendor of the software product. The use of the leasing techniques for software products affords manufacturers and developers of such products certain degrees of control over their products. Control over the software products usually takes the form of restrictive-use agreements which states how and where the product is to be used. The restriction on the use of a software product could be to a specific central processing unit, computer installation, division or unit of an agency, or to a complete agency. In most instances, however, the arrangements offered by in- dependent software vendors were more liberal than those announced by IBM. Most noteworthy is the fact that some software firms offer substantial discounts for multiple-installation procure- ments. Additionallyp rental arrangements are provided for a fixed period of time and are not unilaterally cancellable. Any alterations to the lease agreements are usually negotiable between the lessee and lessor, whereas the IBM agreement reserves to IBM the right to alter its lease arrangements. 15 It is not practical to estimate the total financial impact that licensing computer programs for use on each c_>erating central processing unit --such as the arrangements announced by IBM and agreed to by GSA contract negotiations for fiscal year 1970--will have on the Government's data processing operations. No mechanism exists to determine the extent of use or number of copies of a software pro- duct that would be used by the Government. With the lack of such a mechanism at the time of acquisition, the Federal Government is not in a position to negotiate quantity procurements or to determine the most economical means of satisfying its software needs. The advertised prices for each proprietary software product awe ar , for the most part, to be relatively inexpensive unless long- term or multiple acquisitions are being made. In most instances, the Government would need more than one copy of a software product. In all probability, it would not be necessary to have a copy of each program for each computer. Nevertheless, to show what it could cost the Government if three packages were obtained for all the computers on which they are capable of operating, we selected the following packages. Monthly Computer license Program product configuration fee Generalized Information System 360/50 or larger $1,500 Information Management System 360/40 or larger 600 Project Management System 360/25 or larger 300 The Federal Government could spend up to $6.7 million a year if it acquired copies of these programs for every computer that could use them. The same three packages used at an installation, such as the social Security Administration in Baltimore, Maryland, which had 13 IBM 360-30 and 12 IBM 360-65 computers as of June 30, 1970, would cost $400,000 per year if each computer had a copy of each package. Over the years, the Government has been able to use its competitive advantage to obtain substantial savings by negotiating large procure- ments of similar equipment. The advantage of this technique may be lost if quantity discounts are not offered on unbundled software or a mechanism is not established whereby the Federal buyer can give recognition to the total needs of the Government for a software product under consideration. Such a mechanism could be readily established if all Government users made known to GSA their firm software package requirements and GSA, in turn, advertised for a firm requirements contract for the combined needs of all agencies. 16 Computer users in the non-Government ADP community have indicated to us that greater emphasis will be placed on in-house programming in those installations which are large enough to maintain such capabilities. Moreover, we were advised that greater effort will be placed on competitive procurements. The Government should pursue the same course of action. It should consider outright purchases and contracted development of programs and strive to obtain more satisfactory leasing arrangements, such as leases based on usage. This latter concept primarily consists of the vendor assessing a fee each time his product is used by a data processing installation, in lieu of charging basic monthly or annual rental fees. POTENTIAL FOR INCREASED COSTS TO THE GOVERNMENT The policy of assessing a fee for the use of a computer program on the basis of each designated central processing unit is a significant departure from current procurement practices, and will undoubtedly increase the data processing costs for the Federal Government. For example, in installations where two or more central processing units are necessary to perform like data processing activities, the Government will be required to pay the full price for the same software package on each central processing unit on which it is used. Because of this significant change in pricing policy, which has a potential for sub- stantial and unjustifiable increases in the price paid for computer products, there is a need for the Government to adopt a policy against this software pricing concept and to consider the alternatives that are available to it. RECOMMENDATIONS GSA is responsible for the procurement of ADP services, and should take the leadership in negotiating contract terms that are favorable to the Federal Government. Additionally, GSA should provide guidance to Government users for satisfying their software requirements free of undue contractual restrictions. Towards this end, we recommend that the Administrator of General Services give consideration to: --Alternative sources of supply for software products such as in-house or contractual developments, in- dependent vendors, or libraries. --License-free agreements for software products which were produced with the help of Government funds. --Non-restrictive COntraCtUal arrangements. --Licensing of packages on the basis of usage. --Multiple-purchase discounts offered by some software vendors. In this respect, we further recommend that the Administrator consider the use of advertised requirements type contracts for procuring proprietary software packages and other software for which specifications have been clearly defined. 18 CHAPTER 4 ACQUISITION AND USE OF PROPRIETARY SOFTWAREPRODUCTS There are instances where it is beneficial to use proprietary software products marketed by computer software firms. Many variations of the same software product--some better than others--are available and are offered under various marketing programs. The Federal user, therefore, is confronted with the problem of selecting the right pro- duct for his needs and of using the most advantageous way of acquiring such services. This problem has been compounded by the fact that the use and acquisition of proprietary software products has not received the necessary coordinated management and central policy direction. Prospective Federal users have to make an evaluative study of the various packages available to select a software package for a given task. Some of these studies have been more thorough than others and have consisted of a full canvass of the field, whereas other studies have consisted of outside assistance from consultants, published services, or from other users. Much effort is needed to properly select the most appropriate software package. On October 27, 1970, a representative of the Systems Development Division of NBS reported on a study that was made to identify data management systems software packages. This study identified 159 data management systems packages. Sixty-five of the packages were found to be written in Formula Translator Language (FORTRAN) or Common Business Oriented Language (COBOL) and 47 of these 159 packages were identified as being in the public domain. This last fact is important to Federal users, as some of these were developed by the Government and are available without charge. This report of NBS personnel filled a void for this type of information. Potential users of data management systems now have a starting point for their studies. It will still. be necessary to evaluate the capabilities of the pertinent packages to determine which best fulfills data processing needs. These evaluations, if made by a central agency such as NBS, would eliminate the need for all potential users to perform independent studies, and would help to standardize the criteria used in the evaluation processes. NEED FOR ACTIVE GSA PARTICIPATION IN SOFTWAREPROCUREMENTS Prior to fiscal year 1971, very few software products were covered 19 by Federal Supply Schedule contracts. Thus Federal ADP users individually have had to be alert to the availability of software products and to make their own procurements of these products. Since the users have received little or no guidance from responsible central agencies to evaluate effectively the many available software packages with similar capabilities, they were not properly equipped to decide when it was in the best interests of the Government to acquire commercially available software products in lieu of developing in-house Government software. We reviewed the acquisition of certain generalized proprietary software packages procured by Federal data processing users. Our efforts were directed primarily toward the acquisitions of utility software products, as this type of software has greater general- purpose applicability. We did, however, consider on a limited basis, the acquisition of some generalized applications software products, to determine if similar management problems also exist with this category of software. Automatic flowcharting software A flowchart is a graphical representation of a sequence of opera- tions that uses symbols to represent the detailed steps and depict the logic used within the operation. This type of representation was performed manually in the past. Computer programs have been developed which allow for the computer.to perform this detailed task automatically. We reviewed acquisitions of the following automatic flowcharting soft- ware packages by Federal data processing installations. --AUTOFLOW 7094--this software package was developed under a Government contract as a research and develop- ment effort and is available, without charge, to all Government agencies. --AUTOFLOW 360--this proprietary software product has been acquired by Federal data processing installations since fiscal year 1967, under the provisions of Federal Supply Schedule contracts. --GOCHART--this software package was contractually developed for GSA, to satisfy an immediate need and for potential Government-wide use. --NAVFLOCHART-C--this software package was internally developed by the Department of the Navy and is made available to all Government departments and agencies without charge. 20 File management software File management software packages are computer programs designed to be used for creating and maintaining data files within a computer system. Some of these software packages also provide a capability for the computer to prepare reports on an as-needed or systematic basis. We reviewed the actions taken by several Federal data processing in- stallations for acquiring the following proprietary file management l software packages. --MARK IV--Federal data processing users have independently acquired at least 14 copies of this software package since 1968. The Department of the Air Force awarded a Government- wide call contract for fiscal year 1971 for use by Federal departments and agencies. --SCORE--at least four copies of this proprietary software product were acquired by agencies of the Government before GSA negotiated a Federal Supply Schedule contract for this product for fiscal year 1971. Information retrieval software Information retrieval software consists of computer programs that provide for the recovery of desired information from a collection of data stored in a computer system. We reviewed the procurement actions taken by Government agencies on the following proprietary information retrieval software products. --HASKINS & SELLS AUDITAPE--the marketing strategy for this software product differs from that of most pro- prietary software packages in that rental is based on use and it can be used on any computer system for which intended, whereas use of most other proprietary programs is generally restricted to central processing units, data processing installations, corporate entities, etc. --QWICK-@JERY--this proprietary software product was pro- curred in 1968 by GSA for its internal use. Another agency subsequently purchased the services of this product from . the vendor in lieu of acquiring the product for in-house use. GSA negotiated a Federal Supply Schedule contract for this product for fiscal year 1971. Simulation software Simulation software packages are computer programs which allow a computer to perform pseudoexperimental analyses of proposed or 21 desired operating systems through the USE of mathematical or physical models that can perform in a manner similar to a computer. This technique is used as a tool to evaluate, among other things, proposed hardware and software configurations within a computer sysiem. We reviewed the acquisition of the following simulation software products. --SCERT (COMET)--this simulation software product was pur- chased by the Air Force in 1964 for $173,730. Maintenance costs have ranged from $60,000 to $EiO,OOO annually. The Air Force was permitted to use this product to perform work for any Government agency. --SCERT 50 (COMET 50) --this package is an updated version of the above-mentioned SCERT software product. Annual maintenance costs average $35,000 to $40,000 per agency, and serve as rental of the product. Compilers A compiler is a program-making routine which produces a specific computer program by determining the intended meaning of certain items of data input and replacing them with a series of instructions in machine language. These instructions are usually called subroutines and are incorporated in the newly developed computer program. The computer program which results from compiling is generally a trans- lated and expanded version of the original program. During our study, we reviewed acquisitions of the following compiler software product. --SIMSCRIPT 1.5--this compiler has been acquired by many agencies since 1967, at varying prices. No Federal Supply Schedule contract had been awarded for this software pro- duct as of January 1971. Applications software As defined in chapter 1, applications software provides the computer with capabilities for performing specific data processing functions. The following applications software package was included in our study. --CEP--this proprietary software package has been separately acquired by at least six grantees of Federal programs since 1968, to provide data handling operations within computer systems used for the Concentrated Employment Program administered by the Department of Labor. 22 Y Details of the acquisition of these selected generalized software packages are included in appendixes III and IV of this report. These appendixes discuss some of the questionable procure- ment practices noted in our study of selected packages. In summary, we found that Federal users: t --Procured computer programs that were already available at other data processing locations within the Federal Government. For example, many data processing installa- tions are acquiring automatic flowcharting software packages, data management systems packages, generalized simulation software packages, etc., for individual use, rather than sharing the use of such products already available elsewhere in the Government. --Procured utility software products with restrictive- use provisions. For example, the use of the computer program is limited to operation on a specific central processing unit or for use within a specific data processing installation. IBM software products are limited to specific central processing units. AIJTO- FLOW, SCORE, and SIMSCRIPT 1.5 are examples of soft- ware products whose use is limited to specific data processing installations. A need for the same soft- ware service on other central processing units or at other data processing installations within an agency necessitates the acquisition of additional copies of the same software package. --Acquired like computer programs at varying prices. MARK IV has been acquired separately by several Federal agencies since 1968 through the payment of one-time license fees ranging from $6,500 to $32,500 per installation. At least six grantees separately acquired the CEP software package, at prices ranging from $3,500 to $4,000 each, since 1968, to maintain management files and prepare periodic reports required by the Department of Labor. --Generally procured software products to satisfy their individual needs. Consequently, the Government did not receive the benefit of substantial discounts, ranging from 20 percent to 80 percent, offered by soft- ware vendors for quantity procurements. The Marine 23 Corps, however, centralized its software procurement actions, and realized savings of about $182,000 for the acquisition of eight copies of MARK IV and about $14,000 for the acquisition of 12 copies of AUTOFLOW when compared to prices of single copies of these products. --Used various techniques for selection of computer soft- ware. We found that some agencies performed thorough technical evaluations of the products whereas others performed cursory reviews of the written material accompanying the product, prior to its selection. The latter type of evaluation cannot always be relied upon by subsequent users thus necessitating additional evaluations prior to acquisition. --Performed duplicative computer program evaluations as a result of a lack of effective coordination of efforts among data processing installations. We found that two agencies technically evaluated MARK IV, among other software packages, during October 1968. Current procure- ment procedures of the Federal Government necessitate in- dependent technical evaluations by each data processing user prior to acquisition of a software product. This uncoordinated approach to procurement has not provided the Federal Government with the most economical and efficient means for acquiring computer software for use in its data processing operations. We visited several non-Government data processing installations that had procured commercially available software products, and found that they generally included in their considerations for use of software products such factors as: --Need. --Speed of implementation. --Savings to be realized. --Acquisition cost. --Potential reliability of the software product and related support services. It was noted that these users deemphasized the slight decrease in computer system efficiency, if any, in their decisions to acquire generalized proprietary computer software products. 24 The terms obtained by these non-Government organizations in procuring packages from software suppliers were similar to those obtained by the Federal Government, with the exception of quantity discounts and restrictive-use clauses. These non-Government users generally employed a single-purchaser concept whereby purchase was made for the corporate entity on a volume basis. Relative to re- strictive-use clauses, the terms provided that the use of those software products be limited to a single data processing installation: although, in a few instances, the software products wexe merely re- stricted for use within a corporate organization. SAVINGS AVAILABLE TO THE FEDERAL GOVERNMENT THROUGH USE OF PROPRIETARY SOFTWAREPACKAGES In the studies or evaluations by agencies leading to decisions to obtain software products, it was usually estimated that obtaining such packages in lieu of developing a custom program would result in savings in time and cost. Savings to be realized in the improve- ment of the task or work by using the software products were also considered in these evaluations. Unfortunately, users who have justified the acquisition of a product on the basis of expected savings do not document, as a matter of course, the actual accomplish- ment of that saving after the product is acquired and put in use. From all available evidence, however, substantial savings are sometimes available by obtaining proprietary products. Savings accrue when it is necessary to expedite a data processing need and the nature of the need is nonrepetitive. Additionally, if a user does not have an in-house capability or if the in-house capacity cannot accomodate the current need, the procurement of proprietary products is invariably more economical than the acquisition of a custom designed computer program. Although it is difficult to verify the claimed financial benefits of using proprietary software products, the National Aeronautics and Space Administration, Goddard Space Flight Center, reported that their acquisition of such a product resulted in annual savings of $2.3 million to their agency, and they estimated that additional savings of about $11 million were realized by other Federal agencies who used the same product. In 1966 Goddard needed a flowcharting product which would automati- cally flowchart and analyze computer programs operating on its IBM 7094 c series computer system. This task was performed manually at Goddard, since the only known available proprietary product, AUTOFLOW, 25 was not operable on the IBN 7094. The AUTOFLOWvendor had developed versions of its product to operate on the IBM 360 and other computers but had not planned to develop one for the IBM 7094 since the po- tential market was too small to warrant the investment. In exchange for a Government free-use license, Goddard sub- sidized about $87,000, out of a total estimated development cost of $250,000, for an IBM 7094 AUTOFLOWpackage. Prior to the development of this flowcharting program, both an internal and a contractual survey were performed to evaluate the requirements for such a tool at the Center and to evaluate the available software which could satisfy these needs. It was concluded that no suitable software was then available . and that savings equal to the entire Government-sponsored development costs would be realized through use of the software product at the Center. We noted that Goddard treated the contractual development of AUTOFLOWas a research and development effort and it was not coordinated with GSA prior to the development of the software package. In addition to satisfying its own needs with this product, the Center has provided about 50 Government and contractor installations with copies of the 7094 AUTOFLOWprogram for their use. Subsequent to the development of the 7094 AUTOFLOWsoft- ware package, Goddard awarded contract No. NAS-10587 to the same vendor for the development and implementation of preprocessing units for the UNIVAC 1108, DDP 24, SDS 900, and CDC 3200 computer systems. The total cost of this development effort was about $88,000. These preprocessing units were designed to allow fox the use of the vendor's proprietary 360 AUTOFLOWsoftware product to automatically flowchart the software designed for the four respective computer systems in use at the Center. Goddard officials informed us that preprocessing units were developed for use with the 360 AUTOFLOWproduct rather than the existing Government-owned 7094 AUTOFLOWsoftware product, because of Goddard's long range plan to replace its second-generation 7094 equipment for third-generation computer systems. The Center subsequently acquired a 360 AUTOFLOWsoftware product under the rental provisions of the Federal Supply Schedule contract awarded by GSA. Although NASA obtained third-generation equipment, it was still operating second-generation 7094 computers at the time of our review. POTENTIAL FOR SAVINGS 3 We believe that substantial savings can be realized by the Federal 26 Government through proper evaluation and use of generalized computer software packages as tools for expediting its data processing activities. Such savings would be realized through the relief of in-house computer programming personnel from: --Performing detailed routine tasks of document- ing computer programs manually. --Writing special programs to process one-time or occasional reports for management. --Requiring as much contractual assistance from other sources to satisfy computer programming needs. Additional savings could also be realized by the Federal Govern- ment through use of a single-purchaser concept whereby one office within the Federal entity would acquire and manage all software products. This practice would provide the Government with an oppor- tunity to: --Capitalize on the substantial quantity discounts offered by software vendors. --Eliminate the need for duplicative technical evaluations of the same software products. --Decrease the number of like software products used in its data processing activities. RECOMMENDATIONS We recommend that the Director, Office of Management and Budget, through the General Services Administration and the National Bureau of Standards, provide coordinated management and central policy direction to users for determining the most economical and efficient means for obtaining software. When it has been determined that use of proprietary software should be used, we further recommend that GSA employ a single- purchaser concept for satisfying these needs. 27 CHAPTER 5 OTHER SOFTWAREMANAGEMENTPROBLEMS There are many problem areas in the Federal Government relating to the acquisition and use of computer software. These groblems from the limited amount of central management guidance for agencies within the Government to follow when makrng decisions regarding the best means for satisfying their respective computer software needs. In addition to the management problems associated with separate pricing, restrictive-use licenses that accompany some proprietary software products, and the independent means employed by agencies for acquiring proprietary software products, there are many other areas that warrant centralized attention and guidance to achieve better and more economical management of computer software. There is a need for: --More detailed central guidance to operating agencies. --Procurement regulations specifically geared toward software acquisition. --An inventory of computer software in Government. --A catalog of available programs. --The elimination of duplicate technical evaluations. --Software standards. --Planning for future software requirements. --Coordinated research. --Greater communication between OMB, GSA, NBS, and users. --More delegations of procurement authority by GSA to qualified agencies. --Faster awards of Federal Supply Schedule contracts for software. --Improvement in the use of Federal Supply Schedule contracts for ADP procurements. --Greater use of the ADP revolving fund. 2% --Definite software specifications. --Better software documentation. These and other problem areas have, in our opinion, resulted from ineffective or nonexistent central agency policies, guidelines, and procedures, relating to the acquisition and use of computer software in the Federal Government. CENTRAL GUIDANCE Agencies of the Federal Government have, for the most part, been satisfying independently their computer software needs. This practice has resulted in the use of different criteria for considering: (1) how computer software needs should be satisfied; (2) how to select software products to be procured; and (3) whether such software should be Government-owned or licensed. OMB has, from time to time, prescribed Government policies for ADP activities by issuing circulars and bulletins to the heads of executive departments and establishments. These circulars and bulletins do not pertain to the acquisition and use of computer software but to the selection and acquisition of equipment, to studies preceding the acquisition of equipment, to sharing of equipment, etc. Circular A-54 is a good case in point. It establishes policy guidance for the selection and acquisition of hardware but does not cover software. We believe that the need for guidance on software procure- ments and administration is just as great if not greater than for hardware. PROCUREMENTREGULATIONS In January 1969, GSA issued amendment E-56 to part 101-32 of the Federal Property Management Regulations (FPMR) which provided some guidance to users for procuring software. These regulations require a user agency to consider the potential Government-wide need in determining the best means of acquisition. If it is determined that such a Government-wide need does not exist, the user agency is permitted to acquire the software product without the involvement of GSA. It is our view that these regulations place an undue burden on the user agencies, who are not in the best position for making such judgments. Decisions of this nature should be made at a central management level of Government where Government-wide software needs can be systematically determined and not at the operating level of Government where a user has a mission to accomplish and an immediate need to satisfy. 29 The need to change this regulation was recognized at the Conference on Management of Computer Systems in the Federal Govern- ment held at Myrtle Beach, South Carolina, in July 1970. This con- ference was sponsored by OMB and was attended by representatives of numerous Federal agencies. In a written summary of this conference, it was reported that: "The regulations should be changed to provide for GSA review of all such proposed software procurements that exceed a specified dollar level." It was also stated that this would remove from the agencies the making of a judgment regarding the potential for substantial use of the software elsewhere and would bring this matter under central management review. At such a level of Government, a coordinated approach could be taken for the purpose of extending the utiliza- tion of the software and reducing its costs. In February 1971, GSA amended FPMR section 101-32.403-2 as follows: "Agencies may procure software for use With ADPE without prior approval of GSA when: "(a) The procurement will occur by placing a purchase/ delivery order against an applicable Federal Supply Schedule contract under the terms of the contract; or "lb) The procurement is from other sources provided the composition and structure of the software is such that the potential for substantial use elsewhere in the Government is not readily identifiable; or "(c) The total procurement for the specific soft- ware package does not exceed $7,500 annual lease cost, excluding maintenance, or $10,000 purchase cost. " We believe that this change in the regulation is a step in the right direction. However, we also believe that the stated dollar limitations are too high and will permit agencies to acquire many software packages without prior approval from GSA. Additionally, we believe that the potential for substantial use elsewhere in the Government can best be determined at the central management level of Government. It is recognized that GSA cannot acquire all soft- ware needs for the Government, especially unique software. GSA, 30 however, should be apprised of such procurements to systematically coordinate the software needs of the Government. INVENTORY OF COMPUTER SOFTWAREIN GOVERNMENT There is no one organization in the Federal Government that main- tains a complete inventory of the computer software products used in federally financed installations. Circular A-83 issued by OMB in April 1967 prescribed the Government policies relating to the establish- ment and maintenance of a Government-wide ADP management information system. Provision was made in this circular for GSA to include in the management information system an inventory of computer programs used by the Government. At the time of our study--some 3 years later--we found no evidence that action had been taken to implement this instruction. GSA officials informed us that they are not in a position to implement such a program unless additional staff is made available for this purpose. During two conferences sponsored by OMB in September 1969 and July 1970 on the management of computer systems in the Federal Government, it was recognized that an effort should be made to inventory software products used in Federal data pro- cessing operations. We believe that such an inventory is a pre- requisite for effective management of computer software, to minimize duplication and to effect greater reutilization of such products. CATALOG OF AVAILABLE PROGRAMS In December 1966, OMB instructed NBS to maintain a reference index of computer programs so that the need for development of pro- grams already developed, tested, and being used elsewhere in the Government can be minimized. A catalog or reference index of available programs had not been prepared by NBS at the time of our study. This subject was explored during the two conferences sponsored by OMB on the management of computer systems. The proposal was considered to be conceptually sound, but because of the potential magnitude of the task involved, the report of the Myrtle Beach conference suggested that some selectivity should be exercised in determining the contents of the catalog. We believe that such a catalog would assist potential users in selecting software in an unbundled environment, in providing access to information on advances in the state-of-the-art, and in minimizing the possibility of writing programs already developed. TECHNICAL EVALUATIONS Computer users in the Federal Government have been independently evaluating software products with no uniform formalized set of standards 31 against which to make judgments. The emphasis placed on such evalua- tions has been to satisfy the immediate needs of the user. There have been duplicate technical evaluations of similar software products and of the acquisition of varying types of software for the purpose of satisfying like data processing needs. NBS was directed by OMB in 1966 to perform technical evaluations of software products being acquired by Federal data processing in- stallations. We were advised by NBS officials that they had been unable to execute these responsibilities due to the lack of financial and manpower resources. We believe that the use of a single technical evaluation pro- cedure, using existing expert resources in the Government and documenting the findings for future reference, would eliminate duplicate technical evaluation efforts. SOFTWARESTANDARDS In 1966 OMB directed NBS to initiate a program for increasing the compatability in data processing activities by recommending standards for equipment, techniques, and computer languages. It was not until March 1970 that NBS advised Federal departments and agencies of the objective of a Federal Information Processing Stan- dards program and solicited their views regarding the order of priority for establishing standards. At the Myrtle Beach conference on the management of computer systems, it was reported that the advantages to the Government of using standard languages are generally well recognized and should be encouraged, if not required, by all levels of the Government. It was reported, however, that in the case of licensed program products, the situation had been complicated by the reluctance of vendors to provide products in a standard language. To facilitate the use of the products across a wider range of equipment models and to reduce costs, it is essential that standard languages be promulgated for all software packages acquired for Government use. PLANNING NEEDED FOR FUTURE SOFTWAREREQUIREMENTS To manage ADP resources effectively requires a planning mechanism at the highest level of Government for anticipating future require- ments and methods of providing for these needs. More software will be needed as a result of the ever-increasing use of ADP services. Employment of general-purpose proprietary software products will not completely satisfy these increasing software demands. 32 Plans must be laid out now to ascertain whether the growth in software utilization can be met with the forecasted resources. These include plans by the Civil Service Commission and others con- cerned with personnel to make sure that enough trained personnel are available for Government needs. Additionally, plans should be made to support the advancement of the state-of-the-art; the exploita- tion of new technology; the facilitation of interchangeability through standardization; and the improvement of man-machine communication. We believe that such planning can best be performed by an organiza- tion such as OMB. COORDINATED RESEARCH _ Research efforts for ADP activities have been sponsored bx the various Federal departments and agencies with only limited co- ordinated efforts. We found no procedure in existence that would identify the ADP research projects going on, and we found no one organization managing and directing these research efforts as well as ensuring that the results obtained from such efforts would be utilized. It is recognized that some of these research efforts are oriented toward special unique application but coordinated management of such efforts will provide the opportunity to capitalize on the offshoots of such research. The knowledge gained from such efforts is sometimes used in developing computer software for general-purpose use. (See p-52.) We believe that ADP research efforts should be centrally coordinated by the Government. With such centralized administration, all agencies will be in a better position to capitalize on the results of the research; duplications of research efforts can be controlled; and priority for research projects, to get the most out of available resources, can be assigned. COMMUNICATION BETWEENCENTRAL MANAGEMENTAND USERS There is a need for greater communication within the Federal Government on management of computer software. Some Federal data processing users have not been aware of what is going on outside their organization and, therefore, have redone what already had been accomplished. Only limited guidelines for determining the best means of procuring computer software have been issued to the agencies to date. The pro- curement regulations issued by GSA in January 1969 concerning the acquisition of computer software have not been effective. GSA advised us that they have made no effort to administer these regulations. Effective two-way communication is necessary for good management of ADP activities. A starting point for such communications exists in the form of the Government-wide ADP management information system pre- scribed by OMB Circular A-83 issued in April 1967. The full implementa- tion of this system is not yet operational for software. 33 p Another effort at communication with central management was the two national conferences on management of computer system problems sponsored by OMB. The conferees addressed themselves to pressing management problems, and written reports on these conferences were distributed. The reports, however, did not make clear as to how the problems would be solved. It is necessary that users and central management be made aware of the on-going ADP activities in the Government. In addition to the above-mentioned methods of communication, information should be exchanged through a focal point and disseminated both to and from the data processing installation. DELEGATIONS OF AUTHORITY BY GSA The procurement of ADP products, particularly of computer soft- ware, requires a technical knowledge of the product as well as a knowledge of the procurement process. Such a capability exists to some degree in some of the larger Government agencies. GSA has delegated some of its procurement responsibility for certain software packages to some of these agencies in an effort to capitalize on this available Government resource as well as to relieve some of the work load for procuring Government-wide ADP requirements. The use of available Government resources is to be encouraged. This procedure should minimize the numerous delays encountered by suppliers in their dealings with GSA (see next paragraph). The technique of delegating authority to certain agencies, of course, does not relieve GSA of its responsibilities under Public Law 89-306 in providing for the economic and efficient acquisition of ADP products. AWARDS OF FEDERAL SUPPLY SCHEDULE CONTRACTS FOR SOFTWARE Commercially available software packages have been available since 1966. However, GSA had negotiated only one contract in 1967, one in 1968, and three in 1969, for the placement of generalized computer software packages on the Federal Supply Schedule. As of September 1969, there were 33 potential vendors on a GSA waiting list for contract negotiations. Although these potential vendors were on the waiting list, we noted that Government users had individually procured these vendors' products at varying prices and varying contractual terms. GSA officials advised us at that time that they were unable to accomodate the requests for contract negotiations with the existing financial and manpower resources available for such activities. 34 Following up on this problem in January 1971, we were advised by GSA that it had negotiated 28 contracts for fiscal year 1971. GSA also reported that the waiting list of potential software suppliers had been eliminated by a new procedure inaugurated in 1970. This new procedure requires potential vendors to submit complete contract offers instead of only an application to have their product considered for the Federal Supply Schedule. The restrictive- ness of this new procedure may account for the elimination of the waiting list but may frustrate negotiations with the hundreds of other suppliers not on the Federal Supply Schedule. We believe that all qualified suppliers should be included on this schedule. THE FEDERAL SUPPLY SCHEDULE FOR ADP PROCUREMENTS Annually, GSA has been negotiating Federal Supply Schedule con- tracts for computer equipment and related maintenance activities with several sources of supply. These contracts, in many instances, represent the commercially available prices with quantity and other discounts along with contractual terms which apply to all Government sales. These contracts are not competitively awarded. GSA has stated that the Federal Supply Schedule contracts applicable to ADP are to be considered as a "permissive source of supply" and that user agencies are required to obtain their ADP re- quirements on a competitive basis. Thus, it is necessary in each procure- ment for the agencies to prepare software specifications and determine what product can best meet those specifications at the best possible price. The only time that GSA becomes involved in the procurement process is when the maximum order limitations in the Federal Supply Schedule contracts are to be exceeded with large volume procurements. It is our view that GSA should strive to develop a pro- cedure that would provide the user with a competitively obtained source of supply through use of a single-purchaser concept. One such procedure would require the use of federally developed specifi- cations to be used in formally advertised procurements. Pending such a change, it is possible to obtain, by GSA participation in all ADP procurements, some of the benefits of Government-wide procurement. Such participation by GSA could lead to consolidation of requirements and competitive procurements of firm quantities in an effort to obtain the best product at the best price. USE OF THE ADP REVOLVING FUND GSA made little use of the ADP revolving fund to promote and facilitate an economical financial arrangement for computer software. 35 Public Law 89-306 authorized the establishment of an ADP revolving fund and in November 1967 the Congress appropriated $10 million as initial capitalization. An additional $20 million was appropriated in January 1971. The purpose of the fund is to provide economies in the acquisition of all ADP equipment and related services. To date, this fund has been used essentially to acquire equipment where special, unexpected, and attractive offers were received. The use of this financial tool to achieve the goals of economy and efficiency in the acquisition of computer software should be increased. SPECIFICATIONS In reviewing several contracts for computer software develop- ments, we found that the Government generally experiences a sub- stantial number of engineering change orders and contract modifica- tions during a procurement cycle. We also noted that there is a tendency to use cost-reimbursable-type contracts for these procurements rather than a fixed-price mode of acquisition. We were advised that such problems exist in software procurements because Government users have, for the most part, been unable to adequately define their soft- i ware requirements to a point where firm specifications can be written. We believe that efforts should be made by NBS to devise guidelines which can be used by the Federal data processing users for writing software specifications which can be monitored to promote better management of their contractual software developments. SOFTWAREDOCUMENTATION An accurate, historical reference record or documentation of a machine-acceptable coded program is necessary to use, understand, and modify the program. This record depicts the logic, reasons for changes in variables, coding used, etc. Without a complete record of what is included in a program, prospective follow-on users are unable to adapt the program for their use. There has been a general tendency to custom-design software to operate on a specific computer configura- tion and to satisfy one's needs without concern or need for completely documenting the program. With the introduction of the generalized computer software concept, it was noted that programs could be exchanged by data pro- cessing installations and used on several types of computer systems. One reason Federal data processing users have been unable to fully participate in software exchange programs is the lack of adequate documentation. We believe that minimum standards for software documentation should be issued by NBS to facilitate interagency exchange of computer programs. 36 NEED FOR STRONGERCENTRAL GUIDANCE The multibillion dollar Federal investment in computers and the annual expenditures estimated to be in excess of $4 billion warrant more effective centralized management attention and control. Many of the problems discussed in this report are directly related to the absence of this type of management. A basic framework for ADP management in the Federal Government was established by Public Law 89-306. This law assigned certain re- sponsibilities to GSA and NBS to be exercised under the policy and financial control of OMB without impinging on the right of user agencies to determine their data processing needs, select the equipment to satisfy that need, and determine the types of utilization of their data pro- cessing equipment. OMB, GSA and NBS, the central management agencies for ADP, have possessed the authority to issue needed guidance to operating agencies and participate in the acquisition of computer software products. Yet they have for the most part limited their activities to hard- ware acquisition and management. We believe that these central management agencies should pro- vide the guidance and leadership needed to obtain for the Government more effective and efficient procurement of software. For this reason, we have recommended in earlier chapters in this report that these central management agencies undertake such action as the cir- cumstances indicated. Federal ADP users need central management guidance and direction in software administration, in addition to the purchasing function. TO provide the needed management over software and other ADP activities and to properly harness ADP resources for the business of Government, we believe it is necessary to formulate a master plan. Such a plan would include agreed upon goals or objectives against which quality and progress could be measured. It would provide re- source planning, implementation procedures, and appraisal and feedback procedures. RECOMMENDATIONS We recommend that the Director, Office of Management and Budget, under authority assigned by Public Law 89-306, sponsor the formulation of such a master plan and the structure needed to implement the plan. We recommend, in addition, that OMB Circular A-54 be amended to include specific policy guidance to user agencies for the acquisition, management and use of software throughout the Federal Government. 37 We recommend also that the Administrator of General Services: --Require users to process software procurements through GSA. --Maintain an inventory of software products in the Government. --Increase its delegation of procurement authority so that expertise available in other Federal agencies can be utilized. --Add all qualified suppliers of software products onto the Federal Supply Schedule. --Consider the use of firm requirements. contracts for software products. Additionally, we recommend that the Director of the National Bureau of Standards: --Establish and maintain a reference index of computer programs. --Perform technical evaluations of software products and make them available for use by all Federal users. --Promulgate standard languages for use in Federal computer programs. --Issue guidance for preparation of computer soft- ware specifications. --Issue standards for preparation of software documen- tation. GSA, NBS AND OMB COMMENTS GSA and NBS generally agreed with the above recommendation, however, they told us that they are not in a position to implement our recommendation unless additional staff is made available for this purpose. OMB officials agreed that more policy guidance is needed in this area. OMB officials also told us that they are considering amending OMB Circular A-54 to correct some of the deficiencies mentioned in this report. 38 APPENDIXES 39 APPENDIX I COMPUTERSOFTWARE--AN OVERVIEW Since the introduction of the first general-purpose electronic computer in the early 1950's, the number of ADP systems and the expenditures for computer services have increased at a rapid rate. Many estimates have been made concerning the number of computers in use in the country and the total dollar amount expended for ADP application on a national scale. These estimates have varied widely because of the: --Lack of clear cut definitions of terms used. --Lack of uniform data for reporting and accounting. --Ever changing characteristics and capabilities of and the other improvements in this new, evolutionary art. GROWTHIN USE OF ADP SYSTEMS The following statistics, accumulated and reported by GSA, show the number of computer systems in the Federal Government and the re- lated expenditures for ADP activities. Number of Annual ADP costs At June 30 computers (millions) 1960 531 $ 464 1962 1,030 595 1964 1,862 1,096 1966a 3,007 1,284 1968a 4,232 1,653b 1970a 5,277 2,201brc aData subsequent to 1966 is based on the new ADP Management Information System administered by GSA. b Excludes costs of computers used for control purposes and computers installed in classified physical locations, although such computers are included in the inventory count. C Estimated costs for fiscal year 1970. 41 APPENDIX I Excluded from the above statistics are analog computers and those computer systems which have been built or modified to special Government design specifications and are integrals of weapon systems. Additionally, data on contractor-operated equipment is excluded from the above statistics unless the equipment is operated in performance of work under cost-reimbursement-type contracts and related subcontracts for which the equipment is (1) furnished by the Government or (2) installed in Government-owned, contractor-operated facilities. Ithas been reported in congressional hearings that the above statistics represent less than one half of the total ADP activity in the Federal Government. Thus, the annual costs for total Federal ADP activities should approximate $4.4 billion. Although there is no specific dollar amount reported for computer software expenditures, it is generally agreed in the computer industry that more than one half of current data processing costs is for the development and acquisition of computer software. We conclude therefore that more than $2 billion is expended annually by the Federal Government for computer software and related activities. EVOLUTION OF SOFTWARE The rapid growth of the ADP industry has brought computer soft- ware into prominence. The software segment of the industry is, in number of companies and gross dollar volume, growing at a more rapid rate than the hardware segment. Computer software has been defined as programs, routines, codes, and other written information used with computers, as distinguished from computer hardware. Computer programs have appeared in various forms during the evolution of data processing systems. The current techniques of using stored programs in computer systems were introduced by Dr. John von Neumann in 1946. The early stored programs were written in a basic machine-dependent language. This digital format severely limited the scope of programming capabilities and the magnitude of work which could be processed within a given period of time. Improve- ments have resulted through the development of higher level languages (resembling the everyday spoken English language) along with related compilers that are used to convert these higher level languages into a machine-readable form for execution of the data processing activities. computer software currently consists of fixed sets of instructions expressed in a specific manner, which are required for data input/output 42 APPENDIX I operationsr data movements, arithmetic operations, and decisionmaking techniques within an ADP system. Generally, such software can be categorized into the following types. --Systems software, comprising the executive and monitor operating systems, controls the execution of computer programs and may provide scheduling, debugging, in- put/output control, accounting, compilation, storage assignment, data management, and related services. --Utilities software, including the assemblers, compilers, data management systems, and routines for systems evalua- tion--provides for file creation and maintenance capabilities, information retrieval, report generation capabilities, applica- tions programming aids, systems evaluation techniques, etc. --Applications software, provides capabilities for performing specific data processing functions such as payroll, in- ventory control, accounting and statistical work, and any other data processing activity to which the computer is applied. OPERATIONAL SYSTEMS CONCEPT In an effort to promote the use of their respective computer systems, the computer manufacturers developed and maintained the systems soft- ware necessary to make the various components of the machine operate as a unit. These programs, therefore p were considered as part of the computer manufacturer's responsibility in developing a data processing system. Moreover, to facilitate the initial sales of computer machinery, the manufacturers had to demonstrate the capability of their machines to perform user tasks such as payroll, accounting, and statistical work. As a result the manufacturers developed and made available to users the utility software and applications programs necessary for the computer to perform the data processing tasks for which they were being procured. These programs, or software packages, included everything to make the machinery work; such as the punched cards, tapes, written routines, computer system specifications, and the related documentation. Manufacturers distributed their programs to users and also served as clearinghouses for computer programs developed by others. This practice contributed to a relatively free dissemination of computer software and was undoubtedly a substantial factor in the growth of the computer industry. This involvement in furnishing software tended to establish the computer manufacturer as the purveyor of complete systems, by 43 APPENDIX I adding such services as systems engineering, maintenance, and training for use of the data processing systems. It should be noted, however, that the computer manufacturer added the costs for these services to the sales price of his machines. As a result each time a user procured a computer, he paid for not only the machinery being purchased but also the related services included in the system price. The total operational systems concept used by computer manufacturers to promote more widespread use of their respective computers simplified the acquisition problems of the users although the related complete system unit price created many inequities. Most computer manufacturers followed the example set by IBM and provided total operational ADP systems to its customers. Under this concept the manufacturers provided the: --Various items of electronic, and electromechanical equipment necessary for the systems' configuration. --Software and related documentation required for the equipment to interact coherently. --Necessary people to install, maintain, and support the systems. --Training of user personnel in the operation and utili- zation of the total computer systems. Moreover, backup equipment was made available by the manufacturers on an as-needed basis. Frequently, computer users did not require all the support services included in the system price. Some programs, for example, were developed by the computer manufacturer for special-interest groups; thus, these programs were not generally applicable to the needs of all computer users. As another example, some users procured quantities of like computer systems for processing similar applica- tions. Such a user would not need duplicate computer programs and other support services. The system price concept does not take into account these services which are not required. Inequities in the pricing of ADP equipment, and other marketing practices, led the Federal Government and other large users to institute antitrust suits against IBM. These antitrust suits alleged, among other things, that the packaged pricing concept had stymied the de- velopment of competition in the various fields of computer services and that this concept had enabled the manufacturer to provide free services to some customers while denying the same or similar services to others. 44 APPENDIX I SOFTWARE DEVELOPED IN-HOUSE As previously discussed, computer users have generally obtained whatever software was furnished by computer systems manufacturers as part of the total system. There were many instances, however, when some of the needed computer programs were not available from the computer manufacturers or, when available, programs were not adequate to satisfy the requirements of the users. This was especially evident within the Federal Government where there was a need for military environmental systems, advanced research pro- grams, and other special unique applications. In these instances, it was necessary that the user develop the needed computer programs in-house or sponsor such development through other sources. The primary purpose of developing in-house computer programs was to solve specific problems with the use of an available computer. To this end, the computer programs were developed to conform to the configuration of the specific computer system used at the data pro- cessing activity. For the most part, it was not the intent of the user to write programs for optimum use of the machines, in higher level languages, or in modular building-block approaches or to pro- vide for good documentation and other general-6urpose characteristics necessary to make programs adaptable to various purposes and hardware configurations. On the contrary, the users were more concerned with satisfying their immediate computational needs. Because of the restrictiveness and lack of flexibility of the written programs, it was necessary for the users to rewrite the pro- grams whenever they changed the equipment configurations of their respective computer systems. The massive rewriting of computer pro- grams, and the attendant costs, was a major concern at data processing installations whenever a new model or generation of computer systems was introduced or whenever computer users upgraded or changed their existing systems. It is recognized that the computer manufacturers attempted to soften the impact of new hardware introductions by de- signing compilers, converters, emulators, etc., to assist a user in converting from one computer system to another. However, reprogramm- ing efforts were still required in most instances for users who wanted to fully capitalize on the potential capacities of the newly acquired equipment. In a large organization, such as the Federal Government, there are similar problems within each of its organizational units having data processing installations. The lack of documentation, standardiza- tion, and other general-purpose characteristics in computer software has prevented the free exchange of such programs among Government users. Computer users within the Federal Government have not been provided with knowledge of available computer programs at other Government in- 45 APPENDIX I stallations. The installations have had to independently develop solutions to their problems, and to write programs for their specific computer configurations similar to programs that had already been developed by other organizational elements of the Federal Government. An illustration of this duplicative software development is the multiplicity of payroll computer programs used in the Federal Government. For the most part, the overall payroll system for Federal agencies is standardized. Our study shows however, that no organizational group within the Federal Government has written a Government-wide standardized computer program for payrolls which could be easily adapted for differences in computer equipment con- figurations at the various data processing installations. Instead, each organization responsible for payroll activities has been in- dependently obtainin or developing its own computer programs for processing payrolls. ? The existing computer software development on an installation- by-installation basis results in extensive duplication of programming efforts and inappropriate use of computer programming resources. The costs attributable to these duplicative programming efforts cannot be easily estimated as there is no existing inventory of all computer software prepared for use within the Federal Government. Our study has shown that little effort has been made to either centrally develop or coordinate the development of computer programs for multifacility use on a Government-wide basis. A few agencies however, primarily within the Department of Defense, have taken steps to centrally develop computer programs to satisfy their internal data processing needs. These agencies established programming groups and made them primarily responsible for the development and maintenance of computer programs for routine-type data processing operations for use at multiple facilities of the same type., The Department of the Air Force, for example, has been able to employ this technique by requiring that its base-level data pro- cessing operations for supply management activities, financial accounting activities, etc., utilize the same type of computer system. The programs used for processing data were centrally developed by the Air Force and distributed to each data processing installation. Any major modifica- tion or revision to these programs is controlled by the centralized 1A payroll study team under the Joint Financial Management Improvement Program of the Federal Government is currently studying the feasibility of developing a single computerized payroll system for civilian employees. APPENDIX I programming group within the Air Force to ensure standardization of all copies of the programs used at the base level of operations. An alternative to the use of standardized programs centrally developed in-house is the centralized data processing concept recently instituted by one command within the Department of the Navy. The Navy Facilities Engineering Command is currently con- verting to the use of one central computer for its data processing activities, by employing the use of telecommunication facilities between the field locations and the central computer complex. The conversion to this use eliminates the duplicative programming efforts and their attendant costs. These in-house programming efforts have, for the most part, been concentrated on internal data processing problems on an agency-by-agency basis with little or no coordinating efforts among the Government agencies or on a Government-wide basis. Our study has shown that there are certain management problems associated with centralized in-house development of computer soft- ware. For example, it was necessary for the Department of the Navy to solicit the needs of many users prior to developing computer pro- grams for a standardized system to be installed at all naval shipyards. Certain compromises were made by the individual naval shipyards in accepting the standardized system. Some data that previously had been prepared for the management of certain naval shipyards was eliminated in the conversion process. Conversely, data generated under the standardized version of the system was not desired by certain individual shipyard management officials. This situation generally results when many existing local management systems are standardized and automated as one entity. However, once such developmental and implementation problems are resolved, the efficiencies and cost savings of such standardization usually more than offset the inconveniences that are experienced during the conversion processes. During the development of computer software for the standard- ized system for all naval shipyards, the Navy utilized existing computer programming talents located in its various operating in- stallations. For example, the following shipyards were assigned the responsibility for developing software for the cited phases of the new system. 47 APPENDIX I Assigned area for Name of shipyard software development Portsmouth Design Boston Production planning and control Philadelphia Payroll Norfolk Budget and work load forecasting Long Beach Shop stores San Francisco (note a) Material control Mare Island (note a) Financial accounting a The current San Francisco Bay Shipyard includes the Hunters Point Division and Mare Island Division. Subsequent to the development of the computer software by the various shipyard programming groups, the Navy established the Computer Application Support and Development Office to maintain, I revise, and improve the standardized computer systems and related programs. For the most part, the manpower resources for this newly established office were obtained from existing programming groups within the individual shipyards. This technique allowed the Navy to decrease the level of programming effort that was being maintained at each of its shipyards and provided for centralized control of changes that were made to the software for the standard- ized system. Although management problems currently exist in the development of generalized computer software for agencywide use, we believe that substantial benefits can be derived from such activities. The cen- tralized program development concept provides for a more economical and efficient use of in-house programming talents within the Federal Government. Such a technique eliminates the need for each data processing installation to reinvent the same software routines. Additionally, use of the centralized program development concept promotes greater standardization of languages, techniques, and other conventions for processing data in the Federal Government. Such centralization and standardization of software would further facilitate the implementation of uniform and consistent manage- ment policies and procedures, as well as improvements in visability, accuracy, and timeliness of data included in management reports. SOFTWAREEXCHANGE LIBRARIES From the early days of the computer industry, there has been an air of cooperation among users. Problems and experiences gained by various data processing activities were shared within the automatic 48 APPENDIX I data processing community through such media as symposiums, local meetings, and written publications. In this way, programs developed by a user were made available to other computer users upon request. Computer-user organizations were established, and computer manufacturers joined the movement. Kanufacturers provided a focal point for storage and distribution of these computer programs. The libraries established by the computer manufacturers included various categories of systems and utility software and applications programs that were developed by both manufacturers and users for pur- poses of resolving specific data processing problems. Although the software programs were made available for use by many users, much of the software was custom-made to specific computer users' data processing operations and respective equipment configurations rather than designed as a general-purpose computer software package. As a result, it was generally necessary for potential users to modify segments of these programs before they could be used in their re- spective data processing activities. Modification of programs obtained from libraries was difficult because of the inadequate documentation that accompanied many of the software packages. The documentation was not portrayed in detail nor were standardized documentation formats used. This situation existed because the programs were written principally to satisfy the data processing needs of specific installations and were not written with the intent of making them available for wide- spread use. Other sources of computer software are libraries of generalized program packages used by specific scientific disciplines. Many of these programs are developed by universities with support from the Federal Government and industry. Designated organizations as well as computer manufacturers serve as librarians for these software packages. Each library sets its own regulations for program main- tenance and support. One example of such activity is a generalized computer soft- ware package called the Integrated Civil Engineering System (ICES) which was developed at the Massachusetts Institute of Technology (MIT) Civil Engineering Systems Laboratory during the period 1964 to 1968. Support for the development of this project was provided by a number of research sponsors including a computer manufacturer, Federal and State agencies, and private industry. The supporters of this effort contributed about $2.35 million for the development of the ICES software package, exclusive of personnel and data pro- cessing services furnished. Approximately one half million dollars of the contribution was provided by the Federal Government. 49 APPENDIX I The ICES software package and the related subsystem packayes were made available to users through the IBM program library. Each using organization must adapt the generalized ICES software package to its own needs and assume the responsibility for program main- tenance. Another example of user group libraries is the Automated Engineer- ing Design (AED) software system. This software package was developed with Department of the Air Force and industry sponsorship by the MIT Electronic Systems Laboratory. This software was released by the Federal Government for public use in July 1969. Subsequent to the development of the AED software package, the Air Force awarded a l-year contract to a private contractor to distribute, maintain, and enhance the subject software package. Moreover, the software firm is responsible under the contract for the preparation of additional user documentation and the organiza- tion of a user group that will sponsor further development after the Air Force-sponsored l-year contract has terminated. It is planned that the newly established user groups will ultimately finance the subject software firm in maintaining and updating the AED software package in future years. This procedure will give a potential user an opportunity to obtain the AED software package from a library source which will maintain and update the software system. A potential user also will have the opportunity to procure technical assistance, when necessary, from the software firm maintaining the software exchange library. This type of assistance was not generally available on an as-needed basis for many of the computer programs obtained under the other types of library systems discussed above. In addition to the libraries supported by the computer manufacturers, the Federal Government also established and sponsored some computer software libraries to facilitate the availability and exchange of computer programs. One such library, identified as COSMIC (Computer Software Management and Information Center), was established in 1966 with support from NASA. This library contains more than 400 computer programs and is located at the University of Georgia, Athens, Georgia. About 70 percent of the computer programs in- cluded in the library are written in FORTRAN, and new items are added at an average rate of 15 per month. The library programs were developed for specific applications at specific data processing installations by Government contractors, by the University of Georgia, by NASA research centers, and by other 50 APPENDIX I Government agencies. Most of these particular computer programs belong to the categories of scientific applications and general-purpose mathematics. The computer programs are available free of charge to Government users, and they can be obtained by non-Government organiza- tions at minimal costs. In conjunction with the announcements of separate pricing discussed in chapter 2, IBM announced that all software available in its supported users' library prior to the separate-pricing announcement would continue to remain available free of charge. However, the services associated with the use of this software, such as modifying portions of the pro- grams for adaptation to specific user's equipment, will only be available at established hourly rates. Notice was also given that new versions or updated versions of the software programs previously included in the libraries will be made available on a separately priced basis, comparable to all new program products introduced to the user market. Thus, it appears that, if other computer manufacturers that sponsor software exchange libraries follow the example set by IBM, the "free" software available from these software exchange libraries managed by computer manufacturers will rapidly become extinct. SOFTWAREFIRMS As the need for larger and more sophisticated computer systems evolved, it became necessary for the larger data processing users to employ outside programming assistance. In particular, the Federal Government required a substantial amount of programming assistance for scientific, military command-and-control systems and other manage- ment information systems. The necessary in-house programming capabilities were not sufficiently available, and the computer manufacturers were unable to provide the level of effort necessary to satisfy the needed computer program developments. In an effort to satify this need, the Federal Government and other large computer users employed consulting and personal service contracts to obtain the needed technical programming assistance. Several in- dependent organizations were established to offer these services on a contractual basis. Some firms tended to specialize in selected aspects of software development and, as a result, developed an expertise in their specific area of computer programming that surpassed that offered by the computer manufacturers. The majority of contracts for these specialized computer pro- gramming services were awarded on a cost-plus-fixed-fee or time- and-material basis. Generally, the justification for employing 51 APPENDIX I these procurement techniques in lieu of making procurement on a fixed-price basis was that the purchaser was unable to specifically define the subject programming tasks. The purchaser, in effect, was unable to effectively control the efforts of the software con- tractor during the development of the software being procured. In some instances the computer software firms were employed to provide a complete program; but, more frequently, those firms were employed to provide certain levels of effort. These computer software firms have also been used to provide additional personnel to supplement an in-house work force. This technique, however, can result in illegal practices for Government agencies and has proved to be more costly in some instances than employing the necessary talents over a period of time. These observations were made and more fully explained in the following reports which were presented to the Congress in 1967. I --Potential Savings Available Through Use of Civil Service Rather Than Contractor-Furnished Employees I for Certain Support Services (B-1333941, dated June 1967. --Use of Contractor Personnel to Perform Research Functions Within Facilities of the Air Force Cambridge Research Laboratories (B-146981), dated November 1967. The techniques used for contractually obtaining computer pro- gramming services and other personal services is a subject of con- tinuous concern to the General Accounting Office. Additionally, software firms engaged in such activities have developed a much sought- after skill; i.e., experience, knowledge, and expertise for specialized computer programming activities. In conjunction with developing these capabilities, some software firms have further developed the concepts that were originally financed and developed for use by the Federal Government and others. With the knowledge and the techniques, they have completed the development of general-purpose computer programs. These programs were initially marketed to specialized classes of users, such as the medical, banking, and insurance industries. Additional developments by these computer software firms have generally evolved into generalized software products that could be used by many classes of users and on several types of computer configurations. The developers of packaged programs have devised various means for marketing their computer programs and for protection 52 APPENDIX I of their proprietary interests in their respective products. The software package procurements discussed in appendix IV pro- vide some illustrations of the methods used by various software firms to distribute and control their packaged programs. Many of the marketing techniques are used because patent protection is not available for most computer software packages. The user charges and restrictions on use of program products being marketed by IBM are discussed in chapter 3. It is not practicable to determine the extent that these packaged programs are duplicative of the programs or concepts developed for and financed by the Federal Government. In some cases, only the genesis of the programs, conventions, techniques, or concepts were developed under the aegis of the Federal Government. Whereas in other instances, the Federal Government sponsored the total development of certain software products. It may be appropriate therefore, for the central policy agencies of the Government to require software suppliers to eliminate from the price of their product the value of the Government's contribution to the development of the software product. Although the Federal Government has, in some instances, re- ceived certain rights for use of computer soft&are packages that it sponsored during development, the evolutionary features of data processing activities result in constant updating and other changes to existing software programs. Our study has shown that the Government rights generally have not been extended to updated versions of computer software programs which, in effect, has re- sulted in the Government having a right to a superceded and generally unusable software program. Allied to the problems associated with Government rights to updated versions of Federally financed software products is the problem of the computer users obtaining the total software services which they have leased or purchased. Generally, software firms have retained either portions of documentation or the program source deck when providing their products to Federal users, as a technique used to protect their proprietary interests. As a result software products could easily become outdated if vendors decided not to maintain their products at some future date. This problem area was considered at the Conference on the Management of Computer Systems in the Federal Government sponsored by the Office of Manage- ment and Budget at Myrtle Beach, South Carolina, in July 1970. The report of this conference stated that: 53 APPENDIX I "The Government must make sure in negotiating contracts that in all cases it gets adequate documentation to use the product in the first place, and that some provisions are made in the contract to get source language state- ments and program maintenance documentation in the event the vendor becomes unwilling or unable to maintain the program. Some unique techniques may be required to accomplish this, such as depositing the documentation in a bank or with some third party who can act as a cus- todian of a trust. This issue should be considered further by the General Services Administration in con- tractual negotiations for FY 1972." Regardless of the marketing inequities discussed above and elsewhere in this report, we believe that computer software firms can offer a capability for Government use which, under certain cir- cumstances, can provide substantial benefits to the Federal Government. We further believe that these benefits have not been fully utilized to date. Facilities for communication of situations where these available services can be beneficial to Government data processing users have been lacking in the Federal Government since no central mechanism or other media has been established to communicate this information to the using agencies. This aspect is further discussed in chapter 5. 54 APE'ENDIX II FEDERAL MANAGEMENTPRACTICES FOR COMPUTER SOFTWARE The acquisition and management of computer systems by the Federal Government has been guided by broad policies and guidelines pertaining to the procurement of electronic equipment rather than computer soft- ware and related ser,vices. This emphasis on hardware acquisition was due to the fact that, under the total operational systems concept, software and related services were provided by the computer manufacturers as part of the hardware cost. Without central policy guidance for the acquisition of computer software services, the using agencies have independently fulfilled their software requirements through various uncoordinated practices. On October 30, 1965, the Congress enacted Public Law 89-306 which provides GSA with exclusive authority for procuring all general-purpose ADP equipment for use by Federal departments and agencies. This law, however, reserves to the individual agency the,right to determine ADP requirements, develop specifications for computers, and select specific types ,md computer configurations to fulfill its data processing needs and to determine the use to be made of the subject computer systems. The Department of Commerce, through NBS, is required by the law to provide GSA and other agencies, upon requests, with technical advisory services pertaining to ADP and related systems. Additionally, Public Law 89-306 assigned OMB the responsibility of exercising fiscal and policy control over GSA and NBS in the implementation of their respective responsibilities set forth in the law. The responsibilities of these central management agencies, relative to the ADP equipment, also apply to the software products used in conjunction with the equipment. OFFICE OF MANAGEMENTAND BUDGET For many years, OMB issued numerous policy guidance and in- structions to the heads of executive departments and agencies con- cerning the management and use of ADP equipment. In January 1966, OMB established a new ADP management branch to carry out its responsibilities under Public Law 89-306. This group defined the objectives and overall content of working programs to be performed by GSA and NBS and issued policy guidance letters to the two agencies on May 4, 1966, and December 15, 1966, respectively. Also, OMB was the focal unit in interagency forums and recently two major ADP conferences were held--one at Charlottesville, APPENDIX II Virginia, and the other at Myrtle Beach, South Carolina. The reports issued on the result of the meetings indicate that various user and management problems were identified and discussed. OMB is responsible for providing policy guidance to the various organizations of the executive branch. Whether this guidance flows through other central agencies, such as GSA and NBS or directly, it is necessary to ensure that the guidance provided is implemented. GENERAL SERVICES ADMIn'ISTRATION In May 1966, GSA received pnlicy guidance from OMB which pro- vided broad guidelines for the implementation of GSA responsibilities under Public Law 89-306. This policy guidance provides, among other things, that GSA evaluate the procurement processes employed by the Federal Government for acquiring ADP equipment and services to deter- mine the areas in which revised techniques, methods, and practices would offer greater efficiency and economy in acquisition of the end product. More specifically, the evaluation is required to cover such things as: "A determination of the appropriateness of continuing the annual negotiation of schedules for lease, purchase, and maintenance of equipment and services. "A more precise definition of the software which the contractor agrees to supply and more specific penalty provisions for failure to deliver the promised software. "The possibility of procuring ADP equipment and ADP soft- ware as separate and distinct items, not necessarily from the same suppliers. "The possibility that additional sources of procurement should be cultivated to serve as competitive alterna- tives to procuring equipment or services directly from the supplier. "The advantages and possibilities of consolidated or other purchase arrangements for equipment to be selected by the agencies." Additionally, GSA was directed to undertake a program to assist in- dividual Federal agencies in negotiating "the procurement of equipment and systems support. In this undertaking, GSA is to ensure that the Government profits in each succeeding acquisition from the experience of prior procurements and that attempts be made to acquire the data processing equipment and accompanying software, training, etc., at minimum cost. 56 APPENDIX II Guidance to users for procuring software In January 1969, GSA provided guidance to Federal departments and agencies for the procurement of computer software. Amendment E-56 to part 101-32 of FPMR includes section 101-32.403-2 which pro- vides that: "Agencies may procure software for use with ADPE available from a Federal Supply Schedule contract in accordance with the applicable provisions of the contract. Agencies may procure software for use with ADPE from any other source with- out prior review and approval of GSA provided that the composition and structure of the software is such that the potential for substantial use elsewhere in the Govern- ment is not readily identifiable." The regulation further provides that, when a using agency deter- mines that a software product has applicability in other Government data processing operations, the agency should immediately forward the appropriate documentation to GSA for review and consideration for Government-wide procurement action. Subsequent to the review by GSA, the Commissioner of GSA may: --Delegate to the agency the authority to conduct the procurement. --Arrange for a joint-procurement effort between the using agency and GSA. --Provide for the procurement by GSA or some other de- signated agency. Moreover, section lOl-32.405(3) (b) of the regulation provides that, if no action is taken by GSA within 20 workdays after full re- ceipt of the request for procurement, the requesting agency may pro- ceed with the procurement activity as if delegation of authority had, in fact, been granted. It is our view that the above provisions of FPMR 101-32 place an impractical burden on the using agency to determine if a commercial lY available software package under consideration for procurement would also be applicable to other Government data processing activities. The shortcomings of the GSA regulation were also the subject of discussion at the Conference on the Management of Computer Systems in the Federal Government sponsored by OMB and held at Myrtle Beach, South Carolina, July 20 through 22, 1970. The report of this con- ference stated, in part: 57 APPENDIX II "Current General Services Administration regulations governing agency procurement of software are too loosely drawn to provide an effective base for coordinating the acquisition and use of commercial software products. They require GSA review and approval only if, in the judgment of the agency, the software has the potential for substantial use elsewhere. Because of the judg- mental factor, agencies can decide, rightly or wrongly, not to submit the proposed procurement to GSA. The regulations should be changed to provide for GSA re- view of all such proposed software procurements that exceed a specified dollar level. This would have the effect of removing the judgmental factor ard bring under management review all proposed procurements of sufficient value to warrant a coordinated approach for the purpose of extendinzlthe utility of the soft- ware and reducing its cost. NATIONAL BUREAU OF STANDARDS NBS received policy guidance, dated December 15, 1966, from OMB on its responsibilities as set forth in Public Law 89-306. This policy guidance provided for specific actions to be taken by NBS. Relative to the computer software activities, this policy guidance instructed NBS to: "Provide criteria to assist in evaluating software and hardware developments that may be considered during the systems studies. "Provide guidelines, criteria and techniques for evaluating and selecting equipment and related software, giving priority emphasis to criteria for measuring the effective- ness and efficiency of software. Data on this subject will also be furnished to GSA for consideration in the procurement of computers. "Maintain a reference index of computer programs to minimize the need for the development of programs already developed, tested and in use elsewhere." We found, during our study, that only limited action has been taken by NBS to implement these policy guidelines. NBS officials 1On February 17, 1971, GSA issued Amendment E-89 to FPMR. This amendment quoted on p. 30requires, in part, that agencies obtain GSA approval before acquiring software packages exceeding a specified dollar level. 58 APPENDIX II told us that limited reviews were performed at the request of GSA, prior to awarding Federal Supply Schedule contracts for the subject computer programs r and consisted of a cursory reading of the program documenta- tion provided by the software vendors. NBS officials also said that they did not perform any simulation activities or other tests to evaluate the software packages for GSA nor had they established a reference index of computer programs as required by OMB, due to the lack of available manpower and financial resources necessary to perform the work. In discussing these situations with OMB officials, they advised that this shortage of manpower and financial resources at NBS had been recognized but that OMB had been unable to rectify this condition at the time of our study. Duplication of effort We noted that data processing installations within the Federal Government independently evaluated the same computer software packages prior to the acquisition of such software. For example, the Pacific Missile Range and Norton Air Force Base both evaluated the technical capabilities and performance of the MARK IV software package at about the same time, as evidenced by evaluation reports dated October 1968. The reports show that, during these evaluations, other file management systems, such as PRISM and COGENT II, were also being considered by both agencies. Among other activities performed during technical evaluations, we noted that users generally: --Reviewed the software documentation in detail. --Visited other users of the respective software packages to determine their experience through use of the product. --Ran simulation tests of their actual needs of a computer system by using the specific software package under con- sideration. We noted that these two Federal data processing installations both visited the same users, as well as others, during their evaluation processes. Our study further shows that four other Government agencies have also independently evaluated the technical capabilities and per- * formance of the MARK IV software package. (See app. IV.) Many data processing installations of the Federal Government have also performed duplicate evaluations on other commercially available computer software packages, such as QWICK-QWERY, SCORE, SIMSCRIPT 1.5, 59 APPENDIX II and others. Not only did we find a common practice within the Fed- eral Government for each data processing installation to perform its own technical evaluations of software packages, but we also found very little evidence of interaction between these Government users during their evaluation processes. Much of this duplication could have been unnecessary had NBS taken part in the technical evaluations and made available to Govern- ment users a reference index of all computer programs. At the Con- ference on the Management of Computer Systems in the Federal Government sponsored by OMB at Myrtle Beach, South Carolina, the evaluative process was discussed but the discussion centered upon the techniques to evaluate computer programs. The report of the conference does not include any mention of concern for the duplication of effort in evaluating computer programs. The conference included a discussion on the lack of information concerning the present use of software packages. It was suggested that an inventory of software in use in the Government be taken and that a catalog of software products be considered. Recognition was given to the difficulty in cataloging certain packages until NBS established parameters for program identification. The need for a catalog to document information about software packages was also expressed at the Conference on the Selection and Procurement of Computer Systems by the Federal Government held September 15 through 17, 1969, by the Federal Executive Institute at Charlottesville, Virginia. Standards In its policy guidance dated December 15, 1966, OMB also pro- vided that NBS would initiate a program to increase the compatability in data processing activities of the Federal Government by recommending Federal standards related to equipment, techniques, and computer languages. In fulfilling the responsibility, the OMB policy guidance stated that NBS would: "***Immediately begin to develop, issue, and maintain a statement of the Federal Government's standardization objectives and needs. The statement is intended to guide the orderly and logical pursuit of standardiza- tion in ways that are compatible with identified Federal interests." On March 24, 1970, NBS issued a memorandum to all Federal de- partments and agencies regarding the objectives and requirements of the Federal Information Processing Standards Program. This document set forth the potential areas under this program and requested these departments and agencies to evaluate and to rank these areas in the order of priority for their needs. APPENDIX II Included within the proposed areas for Federal data processing standards was one covering computer applications and data. The primary objectives for establishing standards for computer programs were to attempt to eliminate unnecessary reinvention of like computer programs for data processing activities throughout Government departments and agencies and to facilitate the interchange of data at the same data element level within Government operations. At the Myrtle Beach conference, it was reported that Government ADP managers voiced their concern on the subject of standard language and adequate documentation. Scientific and technological advisory services, support of industry standards, establishment of uniform Federal ADP standards, and research on computer science and techniques are activities long overdue. We believe that these activities, especially as they relate to computer software, will greatly enhance the ability of the Federal Government to more effectively manage software acquisition and use with- in its data processing detivities. Moreover, such activities should provide Federal computer users with the capability for: --More effectively defining their computer software needs. --More effective documentation for computer prcgrams. --Sharing data processing work loads to achieve the maximum economic result from their investments in computer equip- ment and related software. --Elimination of the existing need for continual reinventions of computer software to fulfill data processing needs. To achieve these benefits, however, NBS must have the necessary resources. As previously pointed out, OMB recognized that NBS had a shortage of resources to fully implement the tasks and responsibilities assigned to it by Public Law 89-306 and the OMB policy guidance document. We believe that full economic and efficient acquisition and utiliza- tion of compu'zer software or equipment will be unattainable under the present management structure, unless NBS is provided with the resources to discharge its responsibility under the legislation. COMMUNICATION--A PROBLEM IN THE MANAGEMENT OF SOFTWARE We have found a lack of an effective means for communication within the Federal Government in the management of ADP, including computer software products. There are no formal lines of communication between users8 and communication between responsible management and users has been limited. Since many users are insulated from the rest of the Federal ADP community, they have unknowingly retraced the same steps previously taken by other Federal users. APPENDIX II Policy guidelines Only limited guidelines for determining the best means of fulfilling computer software needs have been issued to operating agencies to date. The OMB guidance documents to GSA and NBS included guidance only on certain Government-wide software problems. We believe, however, that GSA and NBS should provide all user agencies with the necessary guidance for determining and supporting their needs for software products and the necessary direction for satisfying these needs. Regulations In January 1969, more than 3 years after Public Law 89-306 was enacted, GSA issued an amendment to the FPMR concerning the acquisition of software products. This regulation has not been effective. GSA advised us that they have made no effort to administer these regulations for software procurement. We found in our review, for example, that the Naval Construction Battalion Center, Port Hueneme, California, was concurrently renting two generalized computer software packages; one called AUTOFLOW, which was ordered from the Federal Supply Schedule, and the other called SIMSCRIPT 1.5, which was independently acquired by the using agency. We were advised by agency officials that neither of the above procure- ments was coordinated with or reported to GSA as required by FFMR, section 101-32.403, as they were unaware that such a requirement existed. Similar conditions have also existed with other using agencies. The original version of this regulation required voluntary compliance by user agencies on the basis of their understanding of the potential for the use of the product by other users. There were no provisions in the FPMR for ensuring that the regulations are complied with. Officials of GSA have confirmed our observations and have stated that it is their view that GSA does not have the responsibility for administration of these procurement regulations once they have been released to the operating agencies. This regulation was modified in February 1971. (See p. 30.) This modified version, however, did not alter the provision dealing with voluntary compliance. Moreover, our study shows no instances where GSA made an effort to evaluate the applicability or effective- ness of these regulations in actual Government data processing opera- tions. Officials at GSA have expressed the view that another Government agency, such as the General Accounting Office, for example, should be policing their procurement policies and regulations once they are issued. They have stated that GSA does not have the necessary manpower or financial resources to administer its policy regulations. 62 APPEMDIX JI In our opinion, the issuance of regulations without concern for the applicability, effectiveness, and enforcement of such regulations does not satisfy GSA's responsibility under Public Law 89-306. We be- lieve that GSA should immediately take steps to oversee and manage computer software acquisitions in the Federal Government. It is our view that an originating agency of operating regulations, such as GSA, must take the initiative to review and evaluate such instructions to ensure that they are in consonance with the needs of Government operations. Furthermore, GSA should not depend on others to perform functions that are properly GSA's responsibility. Moreover, we believe that GSA must take a more active part in the acquisition of computer software for use in the Federal Government to ensure that such software is obtained in the most economical and efficient manner. Only in this way, can such a central procurement agency fulfill its managerial responsibilities for ensuring that economies are experienced in procurements for data processing activities within the Federal Government. Inventory There is no one source in the Federal Government where one could obtain a complete inventory of computer software products used in Federal installations. OMB Circular A-83, dated April 20, 1967, prescribed the policies relating to the establishment and maintenance of the Government-wide ADP management information system. This circular provides for inte- grated subsystems for inventory, utilization, manpower, cost, and acquisition histories for each of the computer systems used in the Federal Government. The circular further pointed out that additional subsystems concerning selected information on program plans, budget requirements, equipment and software performance, applications, etc. would be considered for development and subsequently integrated into an advanced management information system for data processing activities. GSA was designated as the agency responsible to accumulate data for the sys tern. At the time of our review, the ADP management information system had not been used to accumulate, and make available, data on software products. At the Myrtle Beach Conference on the Management of Computer Systems in the Federal Government previously mentioned, it was reported that there was a need for an inventory of software in use by the Federal Government. Accordingly, GSA should undertake the inventorying of software in use in the Government. We believe that whatever information is accumulated, either informally or through a management information system, is of little value to the individual ADP practitioner if he is not aware of the data. There- fore, the availability and information on these programs must be made known to all users. 63 APPENDIX III PROCUREMENTOF COMPUTERSOFTWARE Annually GSA has been negotiating Federal Supply Schedule contracts for computer equipment and related maintenance activities from several sources of supply. Each contract is independently negotiated on a sole-source basis with each applicable vendor. The contracts, in many instances, represent the commercially available prices with quantity and other discounts. This activity is in partial discharge of its responsibilities to procure computer products for Federal agencies. FEDERAL SUPPLY SCHEDULE CONTRACTS These Federal Supply Schedule contracts are not competitively awarded, and using agencies are required to obtain their ADP re- quirements on a competitive basis. This means that each requester of ADP products must prepare specifications and determine who can best meet those specifications at the best possible price. GSA has stated that the Federal Supply Schedule contracts are to be considered as a “permissive source of supply" and that the only time that GSA needs to be consulted in a procurement of equip- ment that is on the Federal Supply Schedule is whenever the maximum order limitation stipulated in the contract is exceeded. By being notified of large quantities or large-dollar-value items, GSA is in a position to participate in the acquisition process. The Federal Supply Schedule contracts provide users with a partial list of suppliers and the available contract terms. In some instances, the Government has the opportunity to technically evaluate the product; but this is not necessarily done. In our opinion, the Federal Supply Schedule contracts should be much more useful. We believe that a major goal of a detailed reexamination of the GSA annual negotiation of these contracts should be to develop an instrument that would eliminate the need for the duplica- tive evaluation of ADP products by each user and that would provide the user with a competitively obtained firm source of supply. Although software packages have been commercially available for about 6 years, the records show the following history of con- tracting activity for software by GSA for the Federal Supply Schedule. Number of Fiscal year contracts awarded 1966 1967 1 1968 1 1969 3 1970 4 1971 (through l-l-71) 28 64 APPENDIX III In addition to the above statistics, the Air Force has awarded a Government-wide call contract (F19628-70-C-0269) for the MARK IV soft- ware product for fiscal year 1971. (See app. IV.) Some computer software firms visited during our study expressed concern over the apparent nonresponsiveness of GSA regarding proposals submitted for contract negotiations so that their respective computer software packages could be made available to Government data pro- cessing users through the Federal Supply Schedules. An analysis of this situation as of September 1969 showed that there were 33 potential vendors on a waiting list for consideration of having their respective software packages placed on the Federal Supply Schedule. The records showed that eight of the 33 vendors were placed on this waiting list during calendar year 1968, and no effort was made to negotiate contracts with these potential vendors through September 1969. A further analysis of this waiting list of potential vendors showed that five of the applicable software packages on the list had been independently acquired and used by Federal agencies while the vendors were waiting to negotiate contracts with GSA. These five software packages were placed on the waiting list and installed at Federal Government data processing installations as follows: Date of Initial Packages application procurement by installed Software package to GSA Government agencies as of l-l-70 MARK IV February 1968 February 1968 14 QUICK-DRAW September 1968 January 1969 8 SCORE March 1969 May 1969 4 QWICK-QWERY March 1969 October 1968 1 SIMSCRIPT March 1969 March 1968 7 Relative to the MARK IV File Management System software package, the 14 copies were acquired by six separate agencies at various prices and contract terms. (See app. IV.) Moreover, the contract terms for use of these packages are very restrictive as to equipment and location. Had GSA competitively negotiated a contract for all Government needs instead of each agency independently buying what it needs, it is reasonable to expect that substantial quantity discounts and other advantageous contract terms could have been obtained. Additionally, the duplicate technical evaluations of the same product by each buyer would have been eliminated. GSA officials advised us in September 1969 that they were unable to accommodate the requests for contract negotiations with the existing financial and manpower resources available for 65 APPENDIX III such activities. They told us that emphasis was placed on completing negotiations for hardware contracts for each fiscal year prior to negotiating such contracts for commercially available computer software packages. In a follow-up inquiry on this matter, GSA advised us that the procedures for requesting contract negotiations for the Federal Supply Schedule were changed during the summer of 1970 to relieve the situation of having a large number of software vendors on a waiting list for such negotiations. Currently, potential vendors are required to submit complete contract offers when requesting negotiations for Federal Supply Schedule contracts, in lieu of merely making an application to have their respective products considered for the schedule. It was emphasized that use of this technique has increased the quality of requests for negotiations and decreased the number of applications received from vendors with products that would otherwise not qualify for the schedule. GSA DELEGATIONS OF PROCUREMENTAUTHORITY The procurement of ADP products, especially software packages, requires a technical knowledge of the product as well as a knowledge of the procurement process. Such capability exists in some of the larger Government agencies. To capitalize on this available Govern- ment resource, as well as to relieve some of the work load of procuring Government-wide ADP requirements, GSA has delegated to selected agencies some of its procurement responsibility for certain software packages. An illustration of this use of available Government resources is the delegation of procurement authority to the Department of the Air Force for the negotiation of a Government-wide call-type contract for computer simulation programs. (See app. IV.) In this case, a number of agencies had a requirement for this software package and the Air Force negotiated a contract for all known requirements, as well as the provision for adding future requirements on a call basis. The Air Force was also delegated the responsibility by GSA to negotiate a call-type contract for fiscal year 1971 for the MARK IV file management software package. This contract was negotiated to satisfy the MARK IV software requirements for the Department of Defense, as well as the requirements of all Federal agencies, and is jointly managed by both the Air Force and GSA. The use of available Government resources is to be encouraged as long as it does not degrade the contract management or procurement process responsibility that has been assigned to GSA. ADP FUND To promote and facilitate an economical financial arrangement 66 APPENDIX III for data processing equipment, an ADP revolving fund was authorized by Public Law 89-306. In November 1967, $10 million was appropriated initially for this fund, and in January 1971, an additional $20 million was appropriated. This fund has been used principally to establish computational service center capabilities for use by Govern- ment agencies. Some use of the fund has been made to procure ADP equipment for lease to other Government agencies. However, the fund has not been fully explored for hardware procurements, and it has had no impact to date on the acquisition of computer software for use by other Government agencies. It was reported in the summary of the Myrtle Beach, South Carolina, Conference on the Management of Computer Systems in the Federal Govern- ment that the ADP fund does provide flexibility for funding equipment in behalf of user agencies but that the limited capitalization has re- stricted its use; and further, user agencies are not fully aware of the guidelines under which the fund is to be used. The possibility of using the ADP fund to finance the acquisition of software products and thereby obtain the benefits of quantity purchases or outright purchase should be explored to achieve the goals of economy and efficiency set forth by Public Law 89-306. INDIVIDUAL AGENCY HEADQUARTERSCONTROL--A STEP TOWARDCENTRAL MANAGEMENT To get uniformity of results from Operating UIIitS, many in- dividual agencies have centrally established a control over ADP acquisition and applications. Centralized agency control provides for more effective and economical applications, better data for management, and a firmer grip on the huge ADP expenditures of the agencies. Such control is a step toward the administration and management of ADP by a central management organization. software for subordinate installations The software needs for operating units' applications can be centrally obtained and maintained either in-house, under contract, or purchased as a product. The military departments have exploited this management technique by using a variety of approaches. The Department of the Air Force, for example, has standardized the equipment and programs at each of its installations for certain applications. The software is prepared by a separate central organi- zation and copies are furnished to all operating units. The Department of the Navy used standardized equipment in its shipyards and had selected shipyards contribute to the production of the software. A separate organization was afterwards established to maintain the software for the Navy. In another instance, Navy headquarters selected a civilian payroll and leave accounting system prepared in COBOL by 67 APPENDIX III a naval installation for use by other naval installations because it met its criteria of acceptability. Also the Marine Corps pur- chased a quantity of proprietary program products for use by those installations needing them. All these approaches are attempts by headquarters of agencies to obtain better managerial control over ADP expenditures as well as to obtain better results from the ADP resources. Software for agencywide applications With the advent of management information systems and other large multilocation management systems, it has been necessary for agencies to develop systems and methods to undertake such programs. These programs are not repetitive but are usually one of a kind. Thus, the experience gained by an agency in implementing such a customized program is lost to other potential users due to the lack of central management and coordination of such resources. In our study, we examined into the procurement of the Centraliza- tion of Supply Management Operations System by'the Department of the Army. In this study, we found a need for: --A fully staffed system project organization to serve as the sole contact for all information and control. --Establishing parameters for contractor efforts. --Defining subsystems and selecting appropriate type of contract for each natural development element. --Sequential development of subsystems with the product of one phase becoming the definition for the succeed- ing stages, in lieu of parallel development of subsystems with interdependency on others to interface results. Due to the lack of interagency coordination, other Government users planning to develop a larger scale management system by using con- tractors may not be aware of these needs. Software for grantees zany agencies have work programs which are carried out by con- tractors or grantees. More and more Federal funds are being spent by grantees. These grantees, in many cases, employ ADP to do their work and to account for their stewardship to the host Federal agency. We believe that, where the ADP operations of grantees are solely due to Federal work programs and applications imposed by Federal agencies, it is logical for the Federal agency to be directly 68 APPENDIX III involved in the development of the needed software products. This involvement would provide for uniformity of results as well as for a control over the costly ADP expenditures. The software product CEP is a case in point. This software reporting system was written by a software supplier as part of a more comprehensive information system developed for the District of Columbia United Planning Organization. The CEP software was designed to improve the reporting system of the Concentrated Employment Program carried out by grantees for the Department of Labor. We found that the following grantees have purchased this software product to assist them in preparing reports needed by their controlling agency: Date of Grantee Price installation Chicago Committee on Urban Opportunity Chicago, Illinois $3,500 December 1968 United Planning Organization Washington, D.C. 4,000 December 1968 Human Resources, Inc. Pittsburgh, Pennsylvania 3,500 December 1968 Human Development Corporation Saint Louis, Missouri 4,000 December 1968 Community Renewal Team of Greater Hartford Hartford, Connecticut 3,500 December 1968 City of Baltimore Baltimore, Maryland 4,000 February 1969 Surely, the sponsoring Federal agencies are better equipped to determine their reporting requirements and should be in the best position to have a computer program prepared for use by all grantees, rather than to have each grantee independently satisfy his data pro- cessing needs. The benefits of such central procurement and distribution are readily apparent. In a slightly different potential application, the Manpower Administration, Department of Labor, administers and finances all administrative costs-- including data processing costs--incurred 69 APPENDIX III by each State in discharging unemployment compensation and employ- ment services programs. Each State has certain reporting require- ments to meet which are prescribed by the Manpower Administration. Therefore a centrally devised program product made available to each State, would offer great promise for uniformity, efficiency, and economy of operation. Another area where the concept of central agency participation and control promises better management and economy is in the mush- rooming Federal involvement in sociomedical assistance. To illustrate, the Social Security Administration, Department of Health, Education and Welfare, administers Medicare insurance programs through designated insurance carriers. This administration imposes many reporting and file maintenance requirements on these carriers, a situation which has some impact upon their mode of recordkeeping. During 1970, the Social Security Administration, with contractual assistance, developed a software product which could be used by its carriers to process part B (medical insurance) Medicare claims. This Government-owned soft- ware product is provided free to the insurance2carriers and was being used in several States as well as the District of Columbia as of January 1971. In January 1968, the Electronic Data Systems Corporation pro- vided a comprehensive proprietary program to process part B Medicare claims and to provide information required for reports to be submitted to the Social Security Administration. This pro- prietary software product has also been acquired and used in many States for processing part B Medicare claims and preparing reports for the Social Security Administration. The designated insurance carriers in other States involved with the Medicare program have independently satisfied their computer software needs through acquiring proprietary products from other software vendors or through other means. We noted, for example, that three of the designated insurance carriers in the State of New York that process part B Medicare claims use software packages acquired from three separate sources. Two carriers acquired pro- prietary software products from separate vendors, and the remaining carrier was in the process of implementing the Government-owned soft- ware product on its computer system as of January 1971. We can well visualize the savings that would accrue to the Government in data processing costs, as well as from the standardiza- tion of techniques for processing and reporting data on Medicare claims, if all grantees under the Medicare program were required to use the Government-owned software product. Moreover, we believe that similar savings could possibly be realized through the development of a Govern- ment-owned software product capable of processing and reporting part A (hospital) claims under the Medicare program. Currently, any software needs for processing part A claims are independently satis- fied by the designated insurance carriers. 70 APPENDIX IV EXAMPLES OF GOVERNMENTORGANIZATIONS USING PROPRIETARY SOFTWAREPACKAGES Following are examples of proprietary computer software packages that have been independently procured by Government agencies for use at their respective data processing installations. This information is based on interviews with software vendors and data processing officials of the Federal Government and examinations of selected records. Examples of the diversified techniques employed by using agencies of the Federal Government for acquisition of computer software packages are included in the following pages. These examples are intended to demonstrate duplications of effort, unlike contractual arrangements, use restrictions, and additional costs that have resulted from unco- ordinated efforts within the Federal Government for the procurement of computer software packages. Also included are examples of experi- ences at individual data processing installations relative to the use of and benefits derived from these software packages. MARK IV FILE MANAGEMENTSYSTEM The MARK IV File Management System, developed by Informatics Inc.p Sherman Oaks, California, is an advanced general-purpose software pro- duct for use with IBM 36rj and RCA Spectra 70 computers. As a file management system, MARK IV provides the capability to create and main- tain data files and to prepare reports from these files in variable formats. The software product can also be used to provide quick response for special reports and other one-time requirements, as well as for the development, implementation, documentation, and operation of business data processing applica- tions. The vendor applied to GSA on February 19, 1968, for inclusion of the IQRK IV product on the Federal Supply Schedule. Because the initial Government-wide contract was not available until fiscal year 1971, each agency had to negotiate its own contractual arrange- ments for all prior procurements. We found that the following six agencies had independently acquired 14 copies of the MARK IV soft- ware package during the period February 1968 through August 1969. 71 APPENDIX IV Government agency Sale price U.S. Dept. of Agriculture $31,687a Civil Aeronautics Board 30,000 + $2,500b U.S. Marine Corps Kansas City, MO. 30,000 + 2,500b 3rd. Div. FMF, Okinawa 10,000 + 500b FPO, San Francisco, Calif. 6,000 + 500b Parris Island, S.C. 6,000 + 500b San Diego, Calif. 6,000 + 500b Camp Lejeune, N.C. 6,000 + 500b Camp Pendleton, Calif. 6,000 + 500b Headquarters, Marine Corps Washington, D.C. 6,000 f 1,250b National Institutes of Health Chevy Chase, Md. 30,000 i- 2,500b Bethesda, Md. 6,000 + 500b Deputy Inspector General for Inspection and Safety 30,875' Norton Air Force Base San Bernardino, Calif. Pacific Missile Range ii Point Mugu, Calif. 19,500d I aconversion to purchase after 3-month lease. bspecial Feature 'conversion to purchase after 2-l/3 months of a 12-month lease. d conversion to purchase with lo-day notice at any time during the 12-month lease. 72 APPENDIX IV Following are examples of independent procurements of the MARK IV software package prior to the negotiation of a Government- wide contract for fiscal year 1971. Deputy Inspector General for Inspection and Safety Norton Air Force Base San Bernardino, California On January 20, 1969, contract F04607-69-C-0156 was awarded to Informatics Inc., for a 12-month rental of the MARK IV File Manage- ment System to be used by the Deputy Inspector General for Inspection and Safety on an IBM 360 computer system. This procurement was justified by the agency on the basis that MARK IV would improve the responsiveness to many special data requests, primarily one-time reports on accident data. Prior to selecting MARK IV, the data processing personnel per- formed a review of 21 available software packages. MARK IV was selected because it was considered by the evaluators to,be the only package that met all requirements, such as the capability for handling hierarchical files and for operating on the existing computer equipment. A data processing official told us that, by using MARK IV, they had experienced a reduction in programming hours required for one- time requests for accident data. They decided to change the rental contract to a license for perpetual use of the software product as a result of the successful application of MARK IV to the accident files. On March 26, 1969, a proposal was submitted to the vendor for a license for the MARK IV product. However, before the license agreement was finalized, the Department of Defense issued Defense Procurement Circular No. 71, dated June 25, 1969, requiring military components to obtain GSA approval prior to the procurement of com- mercial software products not available on the Federal Supply Schedule. Accordingly, a request for this procurement was submitted in August 1969 to the Air Force Directorate of Data Automation for transmittal to GSA for approval. Subsequently, the Air Force was delegated authority to negotiate a Government-wide contract. (See p.75.) This acquisition illustrates an independent acquisition which resulted in duplication as discussed in the following pages. Department of the Navy Pacific Missile Range Point Mugu, California On August 29, 1969, a contract was awarded to Informatics Inc., for the rental of a MARK IV File Management System to be used at the Scientific Data Analysis and Processing Department, Pacific 73 APPENDIX IV Missile Range. This contract, in addition to providing for a 12- month rental of MARK IV, contained a purchase option allowing for the application of 50 percent of the rental payments toward a perpetual license price of $32,500. As acquired, the MARK IV monthly rental charge was $1,625, or a total of $19,500 for the 12-month period. The rental authorization for this acquisition, received from the Naval Air Systems Command, showed that future decisions on obtaining the perpetual license arrangement for this software package would be contingent upon the results of any evaluation of the vendor's price schedule made by GSA. The data processing center at the Pacific Missile Range has the responsibility for providing computer support services to the various range users and the departments located at the range. These services include file generation, file maintenance, data retrieval, and report generation. The decision was made to acquire a file manage- ment system to provide the programming staff at the data processing center with a tool to increase productivity. Prior to acquiring the MARK IV software package, the data pro- cessing personnel performed an evaluation of the major file management system packages available at the time. Preliminary evaluations elimina- ted all but three of the packages. A representative benchmark program was then submitted to each of tie three companies for use in testing with their system. On the basis of the results of the testing and other independent analyses, MARK IV was selected to meet the needs of the data processing center. This independent procurement action again shows duplication of effort. In addition, it shows that different contractual arrange- ments from the same software vendor are obtained through uncoordinated procurement efforts. Headquarters, Marine Corps Washington, D.C. Headquarters, Marine Corps, centrally procures all computer hardware and software for use by the Marine Corps data processing installations. Accordingly, a contract (M00027-68-C-0183) was awarded in April 1968 to license the use of MARK IV at various Marine Corps installations. As of December 4, 1969, eight Marine Corps installa- tions were using the MARK IV software package under a 20-year license agreement at a total cost of about $89,900, which included support services. The MARJF:IV software package was tested for several weeks during a free trial period provided by the vendor. Moreover, con- tact was made with a commercial user of the MARK IV system to obtain its viewsl evaluations, and user experiences relative to the use of this package. 74 APPENDIX IV We were advised that contact with GSA in this procurement was limited to determining whether a Government-wide contract had been or was being negotiated for the MARK IV software package. The Marine Corps officials stated that they were unaware of the required co- ordination with GSA for computer software procurement as set forth in FPMR. It is the view of the Marine Corps officials that the vendor- supplied documentation and support services has been more than adequate to fulfill their needs. They stated that the MARK IV software package provided for flexible formatting of records and that the use of the subject package substantially relieved the routine work load of the in-house programming staff. The savings realized through use of this software package have not been quanti- fied as yet, nor has the information on its experience been officially disseminated to data processing users outside the Marine Corps. This centralized procurement action by the Marine Corps has decreased the extent of duplicate technical evaluations that other- wise would have been performed independently by each of its data processing installations and has resulted in substantial quantity discounts as was shown on page 72 m Such savings possibly could be more widespread through central agency coordination of such efforts on a Government-wide basis. We found no evidence, during our study, of any GSA parti- cipation in the acquisition of the MARK IV software products noted above. Moreover, NBS had not conducted a technical evalua- tion of this software product for Government-wide use. Because central agencies had not participated in the acquisition of the MARK IV software product, each using agency independently performed technical evaluations prior to their acquisition of the software product and obtained divergent contractual terms, as discussed on the preceding pages. In the fall of 1969, the Department of the Air Force recognized a continuing need for the MARK IV File Management System and requested that GSA negotiate a Federal Supply Schedule contract for this product. Upon receipt of the request, GSA delegated authority to the Air Force to negotiate a Government-wide call contract for the MARK IV soft- ware product. Both parties participated in negotiating contract F19628-70-C-0269 for Government-wide use of MARK IV during fiscal year 1971. The contract is jointly administered by GSA and the Air Force and contains a provision that only the Air Force can alter the terms of the contract, with concurrence from the software vendor. 7.5 APPENDIX IV A noteworthy provision of this Government-wide contract is the quantity discount granted on the basis of total packages purchased during the year by the identified agency and by the total Government. Briefly, 33 agencies or organizational elements (i.e., Marine Corps) are identified and the price of packages to each is as follows: Package Price First $26,000 Second 10,000 Third through fifth 7,000 Sixth 6,000 All others 5,400 Additionally, whenever total Government-wide purchases fall within the following quantities, an additional price reduction, equal to the noted percentage, applies. Quantity Percentage 0 to 50 51 to 74 2 75 to 99 4 100 to 124 6 over 124 8 The contract also makes provision to apply 80 percent of the amount paid for leases toward the purchase price of a perpetual license for the package. Finally, any installation which purchases a package is authorized to use it on any computer within the in- stallation. This provision is not as restrictive as IBM's pricing policy, which limits use of its packages to the central processing units. The negotiation of this Government-wide contract has pro- vided financial benefits that otherwise would not have been obtained and has provided a basic contractual arrangement for use by all Government agencies. AUTOFLOW AUTOFLOW is a utility software package developed by Applied Data Research Inc., Princeton, New Jersey, and initially made available for commercial use in 1964. The vendor has advertised this software package as having the capability of providing two- dimensional flowcharting documentation from computer languages such as COBOL, FORTRAN, and PL-1. Additionally, the AUTOFLOW software package has been advertised as having the capability 76 APPENDIX IV to generate complete statement analysis, page allocations for print-outs, vertical and horizontal line drawings, and source input rearrangements. Versions of the AUTOFLOW software package currently are available for use on the IBM models 360, 7090, and 1400 computers; the RCA Spectra 70 computer systems; and the Honeywell 200 series of computers. In general, the commercial procurement terms for acquisi- tion of the AUTOFLOW software package provide for a 3-year lease arrangement with l-year renewal options. This lease arrangement generally restricts the use of the software package to individual installations and includes training, operating manuals, software maintenance, and other customer support in the rental price. Our study shows that the total costs for a typical 3-year commercial lease ranges from $4,200 to $13,600, resulting in annual costs ranging from $1,400 to $4,533. The vendor, however, offers quantity discounts to users of multiple packages. For example, a 25 percent discount is offered at a second installation, a 50 percent discount at the third through the tenth and a 60 percent discount for the acquisition of AUTOFLOW at each additional installation within a corporate structure. Under the Federal Supply Schedule contract for AUTOFLOW for fiscal year 1970, Government installations can obtain the software package for a monthly rental fee ranging between $137 and $206, plus options, which results in annual costs ranging from $1,644 to $2,472. Documentation, support, quantity discounts, and use re- strictions are similar to those applicable to commercial procurement. It is the view of the vendor that an operating agency of the Govern- ment is equivalent to a corporate structure for the purpose of applying quantity discounts. Following are examples of Government acquisitions of the AUTOFLOW software packages for use at its data processing installations. NASA Goddard Space Flight Center Greenbelt, Maryland In 1966 the NASA Goddard Space Flight Center determined that there was need for an AUTOFLOW software package for use on its IBM 7094 computer systems. At the time that the need was determined, the vendor had not developed an AUTOFLOW software package that could be used for processing data on an IBM 7094 computer. As a result the Center subsidized the vendor's development of a 7094 AUTOFLOW package. The total value of this subsidy was about $87,000 from the estimated total development cost of about $250,000. NASA re- tained the rights for free use of the 7094 AUTOFLOWby all Federal agencies and Government contractors, in return for the dollar subsidy 77 APPENDIX IV provided for development of the software package. The contractor retained commercial rights to the 7094 AUTOFLOWpackage. Subsequent to development of the 7094 AUTOFLOW software package, the Center contracted with the same vendor for the development and implementation of preprocessing units for the UNIVAC 1108, DDP 24, SDS 900, and CDC 3200 computer systems. These preprocessing units were designed to allow for the use of an IBM 360 AUTOFLOW software package to flowchart automatically the software designed for the four respective computer systems. NASA officials informed us that they had determined that these preprocessing units should be developed for use with the 360 AUTOFLOWpackage rather than with the existing Government-owned 7094 AUTOFLOWpackage, because NASA had a long range plan for upgrading its data processing equipment to third-generation computer systems. The Goddard Space Flight Center has recognized and reported annual savings in excess of $2.3 million as a result of using these contractually developed software packages. (See ch. 4.) This example is included to show a technique that can be employed by Government departments and agencies when a software need arises and the savings that can result from the use of such a technique. NASA Flight Research Center Edwards, California The Flight Research Center issued a purchase order on May 10, 1968, for the installation and rental of AUTOFLOW for use on their IBM 360 system. This software package was acquired under the pro- visions of the Federal Supply Schedule contract for AUTOFLOW, and was installed on June 13, 1968. Because this software package was pro- cured locally by the Flight Research Center from the Federal Supply Schedule, no approval was required from GSA. At the time of acquisition, consideration was given to a flowcharting package, available from the Goddard Space Flight Center, which operated on IBM 7094 computers. However, since it would have been necessary to convert the package to operate on their IBM 360 computer, no action was taken to obtain or evaluate the package. We believe that Government-wide coordination is necessary to ensure the most economical means for satisfying computer software needs. Independent acquisitions of software products by data processing installations do not provide the Government with an opportunity to 78 APPENDIX IV capitalize on quantity discounts or to decrease the extent to which duplications of effort occur. Department of the Navy Naval Construction Battalion Center Port Huenemep California The Naval Construction Battalion Center issued a purchase order early in 1967 against the Federal Supply Schedule for the installation and rental o f AUTOFLOW for use on their IBM 360 system. This software package was installed during May and June 1967 and was obtained with the capability to produce program documentation from ASSEMBLY, COBOL, and FORTRAN source statements. The justifica- tion for this procurement was based on the computer program documenta- tion requirements at the Center and on the potential ability of the software package to save programmer time that otherwise would be devoted to program documentation. The use of an automated flowcharting package, available free of charge from IBM, was considered before the Center rented AUTOFLOW; however, tests revealed the IBM package to be less efficient and effective than the AUTOFLOW software package for accomplishing the objectives set by the Center. In April 1969, after using AUTOFLOW for approximately 2 years, the Center requested a Government-owned Navy flowcharting package, NAVFLOCHART-C, from the Navy Programming Languages Group, Washington, D.C. This software package was tested and compared to the AUTOFLOW package, and the Center determined that it should continue renting the AUTOFLOW software package in lieu of using the Government- owned capability. We believe that such duplication of technical evaluations would have been unnecessary had such evaluations been centrally performed and the results made available for use by all Federal data processing installations. Department of the Navy Navy Regional Finance Center San Diego, California On April 30, 1969, the Naval Supply Center, San Diego, issued a purchase order against the Federal Supply Schedule for the in- stallation and rental of AUTOFLOW at the Navy Regional Finance Center. Installation was made on May 1, 1969, on an IBM 360 computer system. This software package was rented by the Center to satisfy an immediate need for complete program documentation records. After evaluating the capabilities of other Government-owned flowcharting software packages, it was determined that the Center should rent the commercially available AUTOFLOWpackage. The Navy Regional Finance Center then suggested that AUTOFLOWbe procured for other Naval data processing installations. However, no action was taken by the Navy at that time. Thus, the opportunity to realize any 79 APPENDIX IV savings through large-scale procurements or the chance to eliminate duplicate technical evaluations on a departmental basis was lost. Headquarters, Marine Corps Washington, D.C. Three Marine Corps installations were each renting the AUTOFLOW software package under separate contracts prior to October 1968. At that time, the Commandant of the Marine Corps, in accordance with a newly established Marine Corps policy of centrally procuring all ADP equipment, issued one contract for the use of AUTOFLOWby a total of 12 Marine Corps installations. The applicable Federal Supply Schedule contract for the AUTOFLOWsoftware package, at the time of this procurement, provided for multiple-package discounts. The Marine Corps capitalized on these discounts through centralized bulk procurement and reduced the annual rental charge for the 12 installations by about $14,000, or 47 percent of the regular rental price. Since the October 1968 procurement, three additional Marine Corps installations have obtained AUTOFLOWand thereby have in- creased the total procurement to 15 software packages. We were advised by Marine Corps officials that they were unaware of the availability of Government-owned software packages with automatic flowcharting capabilities, such as GOCHART and NAVFLOCHART-C, which perhaps could have been used at no cost rather than the AUTOFLOW software package procured from the vendor. Marine Corps officials informed us that no effort had been made to disseminate information relative to their experiences of using the AUTOFLOW software packages at their data processing installations. Moreover, we were advised that the coordination efforts by the Marine Corps for small ADP procurements had been limited to sub- mission of a monthly financial report to the Department of the Navy, showing the total dollars spent for data processing activities. The Marine Corps has attributed significant savings to the acquisition and use of the AUTOFLOW software packages for the purpose of documenting its computer programs. These savings have not been specifically measured by the Corps. Although the Marine Corps was not aware of the Government-owned automatic flowcharting software packages at the time of acquisition of AUTOFLOW, it is commendable that the Marine Corps combined re- quirements into a large-scale procurement to realize substantial savings in the prices paid for the products and in the costs elimina- ted for technical evaluations that would otherwise have been performed. 80 APPENDIX IV Department of Agriculture Washington, D.C. The Department of Agriculture rented the AUTOFLOW software package in June 1967 for use at its data processing center in Washington, D.C. This acquisition was made under the provisions of the fiscal year 1967 Federal Supply Schedule contract, without con- sidering other potential software packages and related services, since such information was not readily available at the data processing center. We were advised that this software package was initially procured to serve as a conversion tool because the center was in the process of upgrading its computer system. How- ever, the AUTOFLOW software package has been retained for use by the data processing center as a diagnostic tool and a documentation aid on new programming efforts undertaken by the Department. It is the view of Department officials that substantial savings have resulted from use of the proprietary software package. These savings, however, have not been specifically measured or documented. The Department of Agriculture has a total of 15 data processing facilities which provide services for approximately 25 operating groups. While each data processing organization has similar pro- cessing needs and each could possibly benefit from use of AUTOFLOW or another software package with similar capabilities, only the Washington, D.C., data processing center has acquired this package to date. We were advised by agency officials that there was no co- ordination of efforts among the 15 data processing centers prior to the initial acquisition of AUTOFLOW, nor had there been any effort made to disseminate information regarding the advantages and dis- advantages of using proprietary utility software packages in data processing operations. The data processing officials stated that each of the 15 data processing installations independently satisfied their needs, as each installation locally served various combinations of operating groups within the overall Department. Moreover, the software needs of each data processing installation are dependent upon the local work loads imposed by the various operating groups serviced by these respective centers. We believe that, at a minimum, coordination of effort is needed to satisfy computer software needs at the 15 data pro- cessing installations within the Department of Agriculture. Only in this manner can the Department decrease the potential for dupli- cations of effort, obtain like and favorable contractual arrangements with software vendors, and realize potential savings through bulk procurement of software products, as has been demonstrated by the Marine Corps. 81 APPENDIX IV QWICK-QWERY QWICK-QWERY is a proprietary software package marketed by the Consolidated Analysis Centers, Inc., Santa Monica, California, which has an advertised capability of retrieving, analyzing, and presenting data in desired formats from an unmodified user's data file structure. This software package is also advertised as a machine-independent system which operates on large-scale, general-purpose computers. The vendor submitted an application to GSA on March 13, 1969, for the inclusion of the QWICK-QWERY software package on the Federal Supply Schedule. A revised proposal was submitted by the vendor on August 28, 1969, and a Federal Supply Schedule contract was sub- sequently awarded for fiscal year 1971. Following are two examples in which Government agencies independently acquired the use of the QWICK-QWERY software package. GSA Washington, D.C. In October 1968 the GSA Region 3 data processing center, Washington, D-C., awarded a contract to the software vendor for the installation and rental of the QWICK-QWERY software package. The installation and annual rental prices were $3,000 and $10,800, respectively. This software package was acquired for use on a GE 400 series computer at the GSA Region 3 data processing center. The rental contract contained an option-to-purchase clause which remained in effect for the first 12 months following installa- tion. The clause provided for two purchase alternatives: one applying to the Region 3 facility and the other to all 10 GSA regional data processing installations. On June 13, 1969, GSA exercised the purchase option for the software package installed at their Region 3 facility. The purchase price, after applying rental credits, amounted to $22,950. As of January 1971, no action had been taken by GSA to exercise the purchase alternative for benefit of the other GSA regional computer installations. A Federal Supply Schedule con- tract (GS-OOS-84598) was finally awarded by GSA for this software product for fiscal year 1971. It is interesting to note that GSA, which did not initially ne- gotiate a Federal Supply Schedule contract for the QWICK-QWERY software package, was the first agency to procure the product for its own internal use. Department of Health, Education and Welfare Health Services and Mental Health Adminis- tration, Arlington, Virginia On April 21, 1969, the Health Services and Mental Health 82 APPENDIX IV Administration submitted a request for proposal to the vendor for the purchase of the QWICK-QWERY software package and the contractor's assistance in its implementation. The vendor responded with a pro- posal on April 30, 1969, entitled "Proposal to Public Health Service to Implement the QWICK-QWERY System on Public Health Service Data Files". The contractor proposed a price of $29,981, which included $27,000 for purchasing QWICK-QWERY and $2,981 for 4 man-weeks of consulting services. We were advised that, before a contract could be negotiated, the data processing installation became aware of the FPMR which required the agencies to obtain GSA approval on software package procurements when the package was not on the Federal Supply Schedule but was potentially useful elsewhere in the Government. GSA did not approve the agency request to purchase QWICK-QWERY. The agency subsequently issued a contract to the vendor for services in the preparation and tabulation of data concerning the use of health services by low-income individuals, including the use of QWICK- QWERY in the preparation of analytical tables. The contract, with a fixed price of $15,677, was effective on September 2, 1969. 1t appeared that this contract for services was necessary only because a Federal Supply Schedule contract was not promptly negotiated with the vendor; and the agency did not receive authori- zation from GSA to purchase the QWICK-QWERY software package so that it could perform its work on an in-house basis. NAVFLOCHART-C NAVFLOCHART-C is a Government-owned utility software package developed by the Department of the Navy, which automatically produces computer-generated flowcharts and cross reference listings from COBOL source programs. We were advised that this software package also enabled conversion of any program written in COBOL to the ANSI (American National Standards Institute) Standard COBOL and could be used in software diagnostics. The technique employed in this software package was originally developed in-house by the Charleston Naval Shipyard, and was up- dated in 1967 by the Department of the Navy to make it compatible with all computer systems having a minimum of 24,000 character positions of core memory. It was the intent of the Department of the Navy that this software package be used on a Navy-wide basis for the following reasons. --To obtain a better quality of program documentation. 83 APPENDIX IV --To relieve in-house programmer time for more complex programming efforts. --To promote standardization of program documentation and use of ANSI Standard COBOL within the Department of the Navy. We were informed by Navy officials that, prior to the modi- fication and updating of NAVFLOCHART-C, no consideration was given to other available software packages because the groundwork for the development of NAVFLOCHART-C had already been established. We were advised that this updating effort was not coordinated with GSA because the work was performed in-house rather than on a contract basis. Moreover, the GSA requirements for coordination were not established until after the in-house effort was well under way. The NAVFLOCHART-C software package is made available to Govern- ment and industrial ADP installations at no cost. The potential user provides the tape onto which the software package is reproduced by the Navy. Moreover, users can receive updated versions of the pro- gram at no cost by providing the tapes onto which the package is reproduced. The Department of the Navy has placed more than 200 copies of the NAVFLOCHART-C software package in Government and commercial data processing installations to date. These users include Federal, State, local and foreign governments, manufacturing concerns, hospitals, and universities. Navy officials advised us that dissemination of information on the availability and capabilities of its NAVF'LOCHART-C software package has been primarily by word of mouth. In August 1969, the Navy requested GSA to disseminate information on the availability and capabilities of its respective software package to other data processing installations within the Federal Government. This request stated that "Possibly the promulgation of this information may prevent the need for other agencies to purchase or 'reinvent' similar products-" We were informed by Navy officials that, as of January 1971, no effort had been made by GSA to disseminate information on the availability of the Government-owned NAVFLOCHART-C software package for data processing activities. We believe that there is a need for central agency cooperation in making known the availability of Government-owned software to all data processing installations within the Federal ADP community, in an attempt to achieve greater efficiencies and economies in Govern- ment ADP operations. 84 APPENDIX IV GOCHART The GOCHART software package is a generalized flowcharting system contractually developed for GSA, to satisfy an immediate need of the GSA data processing service centers and other Government agencies' needs for a flowcharting software package to be used on the Honeywell 200 series of computer systems. Although flowchart documentation packages were available at the time of this decision, it was deter- mined that none were compatible with the GSA Honeywell 200 computers. Since GSA estimated that 75 such systems were to be in use by the Federal Government during fiscal year 1967, substantial savings were expected to result from making such a package available for Government- wide use. Contract No. GS-005-73703 was awarded to the Systems Applica- tion Corporation in December 1967 for the development of the GOCHART software package. Final acceptance of the product was made on November 14, 1968, for $47,480. The GSA Federal Supply Service advertised the availability of the GOCHART software package for Government-wide use by means of the ADP Sharegram published by GSA on a regional basis for the greater Washington, D-C., area. This media was used to advertise the availability of GOCHART in the New England region during February 1970. GSA is providing this software package to users on a lease basis. This lease agreement provides for a quarterly rental of $300 for each single data processing location, resulting in annual rental costs of $1,200, and the following discounts for multiple locations under a single lease. Number of Discount for each locations additional locations 2 20% 3 30% 4 40% 5 (or more) 50% The typical lease arrangement further provides that a user agrees c to limit use of the GOCHART software package to the locations and organizations specified in the lease. GSA officials informed us that it was their policy that commercial placements of the GOCHART software packages be made only to the contractors that were performing Government work on a cost reimbursable basis. 85 APPENDIX IV The technique of having a generalized software product con- tractually developed in lieu of developing a customized software product to satisfy a data processing need is commendable. We believe, however, that greater efforts must be made to publicize the availability of the product in an attempt to minimize the extent of possible duplications of effort by other data processing installa- tions in obtaining or developing similar capabilities. SCERT (COMET) SCERT is a commercially available software product marketed by COMRESS, Inc. The acronym means Systems and Computers Evaluation and Review Technique. The original program was a series of decision theory techniques which could be used to assist in evaluating computer hardware/software within the specification environment of a proposed system to be programmed. In July 1964, the Air Force purchased this package under the name COMET (Computer Operated Machine Evaluation Technique). The purchase price was $173,730, and annual maintenance was $60,000 to $80,000 per year. The program was designed for use on the IBM 1410 computer system and was to be used in the validation and evaluation of computer systems by its Electronic Systems Division. Use of the product for other Government agency's needs was not precluded so long as the Air Force provided the service and protected the integrity of the data processing techniques. Such service was provided by the Air Force to other Government agencies. In 1968, COMRESS, Inc., developed an advanced and updated version of COMET (SCERT 50/COMET 50) to operate on different computer configurations. The Air Force planned to update its computer at the Electronic Systems Division from an IBM 1410 to a Burroughs B3500 third-generation computer. It was determined that converting the IBM 1410 COMET package to a package for use on the B3500 would be too costly. COMRESS, however, offered its SCERT 50 software package, designed for use on the IBM 360 computers, at no additional cost to the Air Force. Maintenance charges would approximate $35,000 to $40,000 annually. This offer was accepted and the Air Force abandoned the IBM 1410 program and the Electronic Systems Division subsequently rented IBM 360 computer time to use the COMET 50 package. The need for this package was expressed by other Government users, and GSA delegated to the Department of Defense, who in turn delegated to the Air Force, the authority to enter into a contract with COMRESS, Inc., for all Federal agencies' current and future needs. A contract for fiscal year 1970 was executed, and, at the date of our review, four agencies were obtaining the services from COMRESSunder the contract. APPENDIX IV It is commendable that GSA is using the expertise in Federal departments and agencies for negotiating Government-wide contracts for computer software. Care should be exercised, however, to ensure that Government-wide needs are considered by the negotiating agency at the time that such contracts are consummated. AUDITAPE AUDITAPE is a utility software package marketed by Haskins & Sells a certified public accounting firm. This software package was developed in 1965 and had an announced capability of manipulating large data files without expensive programming and with substantial flexibility by individuals having little or no specialized ADP exper- ience. The AUDITAPE was initially developed and provided by Haskins & Sells as an internal tool to be used during their audits. However, the software package was subsequently made commercially available because it was noted by the vendor that its clients and other organi- zations demonstrated a need for the AUDITAPE capabilities in their day-to-day operations. Moreover, this technique provided the firm with the opportunity to recover a portion of its developmental costs for the software package. GAO acquired the AUDITAPE software package in November 1967 for use in its audit activities. The negotiated procurement terms for use of AUDITAPE provided for quarterly rental payments for each program, based on the number of applications, with a minimum and maximum annual cost. Although the AUDITAPE system is restricted to use by only GAO employees under the terms of the agreement, such use is not restricted to any specific computer system or data processing installation. GAO has found that use of AUDITAPE in the performance of its audits has resulted not only in a more economical means of doing the work but also has provided greater accuracy, more in- formation, and experience in using new audit techniques. The terms of this.contractual arrangement differ from those normally associated with rental of computer software products in that they provide for a charge for each use of the product, subject to minimum and maximum annual charges, rather than for payment of a fixed rate for a stipulated period of time. Use of the product is limited to GAO needs rather than being restricted to any one central processing unit or data processing installation. 87 APPENDIX V FACTORS TO BE CONSIDERED IN MAKING SOFTWAREACQUISITION DECISIONS Throughout this report, we noted that only limited guidance had been given to Government agencies, and we have demonstrated a need for OMB to issue policy instructions and guidance to the heads of executive departments and agencies concerning the acquisition, management, and use of software products. Acquisition, management, and use of individual agency's software products is a complex under- taking and the integration of individual agency's software activities into a more economical Government-wide system may present problems. However, during our inquiries at Government and private industry in- stallations which had adopted strong central management software policies, we noted that the following operational and cost factors were con- sidered in reaching decisions on software needs. --Types of need. --Methods of satisfying needs. --Characteristics and reliability of software products. --Hardware considerations. --Quality of documentation, training, and maintenance. --Contractual terms. --Financial factors. All of these factors are important and, in our opinion, should be considered, among others, in the formulation of decisions leading to computer software acquisition and use within the Federal Government. TYPES OF NEED There are many different types of software needs and these various types of needs affect the method best suited to satisfy such needs. Thus, in an evaluation, consideration must be given to how the necessary software is to be used. Computer software may be needed for: --Unique purposes (applications software). --General purposes (operating systems and utility software). --Frequent use. APPENDIX V --Use limited to an installation. --Multiaccess use (service bureaus). --Multilocation use within an agency. . --Government-wide use. METHODS OF SATISFYING NEEDS Software progr-ms can be obtained in many different ways and from many different sources, such as: --Without separate charge from a system manufacturer. --Without charge or at a nominal cost from other units of the organization, other Government agencies, exchange libraries of user groups, and other users. --Sharing with other users or service bureaus. --Modification of available similar programs. --In-house development. --Contracting for in-house-developmental support (personnel). --Contracting for a custom-made program from software vendors. --Acquiring proprietary packages by purchase, leases based on usage, perpetual leases, or term leases. Care should be exercised to thoroughly evaluate the practicality and advantages of using existing software available at little or no cost to satisfy the particular type of need under consideration. + CHARACTERISTICS AND RELIABILITY OF SOFTWAREPRODUCTS When considering the acquisition of commercially available pro- prietary computer software products, it is necessary that the potential user place a certain degree of emphasis on the characteristics and reliability of the software products under consideration. 89 A thorough understanding of the functions and applications for which the software products are suited is necessary to ensure that the product is capable of performing the data processing needs of the immediate user and other Government agencies. Other considerations should include design features, quality, generality, and expandability of the program. Relative to the design features, many technical features should be evaluated depending on the type of program involved. For example, an . evaluation could consider the language used, file structure, multi- I file operation, record storage, predetermined formats, levels of hierarchy, availability of background, random access, remote teleprocessing, * timesharing, browsing, retrieval, input editing, controls, security provisions, audit trails, flexibility of producing demand reports, and any other feature complementary to the intended application. Although such considerations may not all be necessary for the fulfillment of the immediate needs of the data processing installations-' where the product is initially acquired for use --we believe that con- sideration should be given to all the above factors during the evalua- tion process and such data should be made readily available to other potential users within the Government upon request. This would help reduce a substantial amount of duplications of technical evaluations by several Government agencies. HA,RDbJARECONSIDERATIONS There are several commercially available computer software products that are capable of operating on many different types of computer con- figurations: whereas, others are limited for use on one or two types of computer systems. It should be a goal to acquire and use computer software products that are capable of processing data on several different computer configurations. In this manner, the potential for greater Government-wide use can be achieved. Among hardware items to be considered are: --The types of computer systems and configurations on which the software product can be operated. --The required core memory and peripheral equipment necessary for the package to operate. --The rate and accuracy of timing in the software product. c 90 APPENDIX V QUALITY OF DOCUMENTATION, TRAINING AND MAINTENANCE Much has been written on the subject of standards, formats and types of documentation. Generally documentation is available for the user operations and for the system and programming methodology. To illustrate, user-operations documentation would include such things as source data preparation, system description, run description and flowcharts, setup instructions, and description of anticipated actions. System documentation concerns itself with the broad description of the system with flowcharts and equipment needed, language used, controls, file structure, etc.; whereas, program documentation deals with the specific description of the logic tables, programs' conventions used, flowcharts, list of subprograms, run times, and other such programming specifics. To protect their proprietary rights, software vendors have a tendency to retain the contents and details of the documentation, providing only the bare essentials for installing and operating the packages. Government data processing users must, however, strive to acquire computer software products that are well documented in every detail to ensure that subsequent users can obtain a thorough under- standing of the programs. Also, such a quality of documentation would facilitate the expediency of future modifications in the software pro- duct on an as-needed basis. The problem of documentation, access to the proprietary program logic and procedures was discussed at the Myrtle Beach, South Carolina conference. It was reported that the Government must make sure to obtain adequate documentation to use the product in the first place, and provisions should be made to obtain the source language statements and program-maintenance documentation in the event that the vendor does not maintain its product at some future date. One suggested technique, in the conference report, was to deposit such documentation in a bank with some third party who could act as a custodian or a trust. Training for use of the software products by the vendors should be provided to the extent necessary for immediate use of the product upon delivery and installation. Some software vendors provide training for use of their products at no additional cost. The extent and quality of training for use of the software products can be evaluated through communication with other users. Whenever possible, provisions should be made in the acquisition agreements for the vendor to provide additional training when needed by new users of the subject software products within the Federal Government. When costs for training appear to be excessive, an attempt should be made to provide for in-house- training capabilities for new Government users of the respective software products. 91 APPENDIX V In procuring computer software products, consideration should be given to the type and quality of maintenance provided by the vendors. Items to be considered in each acquisition are: --The extent of maintenance services provided by the vendor, i.e., on-call or periodic maintenance. --Means for providing updates and related debugging processes for the software products. --The frequency of maintenance services necessary for use of the software product. CONTRACTUAL TERMS In executing business transactions with computer software firms who have not as yet negotiated Federal Supply Schedule contracts with the General Services Administration, Federal agencies should, at a minimum, obtain contractual terms as favorable as those provided by firms that have Federal Supply Schedule contracts. Moreover, care should be exercised to avoid rental terms for software products that are not consistent with the rental terms of the computer systems on which the product is intended for use. Currently, it is the practice of software firms to place re- strictions on the use of their software products. There is a great disparity, however, in the types of limited-use clauses being offered by various software vendors. For example, some software firms restrict the use of their products to specific central processing units, whereas, others restrict the use of their respective products to data processing installations, corporate entities, etc. When it is appro- priate to acquire a commercially developed product, consideration should be given to obtaining the most liberal and flexible arrangement. The Government should be free to use the product as best befits its current and future requirements. Care should also be given with respect to the liabilities of both parties for such things as loss of the rented software pro- duct, cost attributable to malfunctions of the programs, loss of data, etc. FINANCIAL FACTORS In addition to the financial aspects attributable to the in- house or contractual development of computer software versus the acquisition of commercially available computer software products, consideration should be given to all financial factors attributable to the use of such software products. For instance, consideration should be given to: 92 APPENDIX V --Quantity discounts for multiple procurements. --Costs for maintenance, training, and other support services. --Costs for modifications that may be necessary to use the software products. --The costs attributable to systems efficiency in using commercially available generalized computer software products versus custom de- signed software. Moreover, the magnitude of each procurement should have a substantial bearing on the cost per software product being acquired. Additionally, care must be exercised to ensure that the Federal Government benefits from any contributions made toward the development of the software product under consideration for acquisition. The several factors discussed above as warranting considera- tion in the acquisition of computer software products are all important. Pending the issuance of more specific central policy guidance and greater central management activity in these matters, we recommend that these factors be considered in making studies and reaching decisions on the acquisition of computer software for use in federally sponsored data processing activities. 93 APPEKDIX VI PLANNIKG NECESSARYFOR FUTURE MANAGEMENTOF SOFTWARE The history of automatic data processing activities is very short * The industry has grown at a tremendous rate since the late 1950's. Three generations of computer systems have been intro- duced to the market, and many advancements have been made in the state of the art for computer software. The use of general machine languages was introduced with the second generation of computer systems, which provided for a wider range of computer applications. Also, higher level languages, such as COBOL and FORTRAN, have been developed for general use, and near-human English languages are coming into use. These attempts for greater and more simple use of computers have been performed by many groups in an independent and uncoordinated manner. T‘nere is a need for planning to guide independent develop- ments of computer technology toward a common goal. Following is a discussion of factors that support the need for a mechanism for planning and managing such activities. GROWTHIN NEED FOR TECHNICAL PERSONNEL An acute shortage of computer programmers and system analysts exists within the data processing community. This condition has resulted from the rapid evolution of computer systems and an in- creasing demand on the use of data processing capabilities by many varied types of operations. It is expected that additional in- creases in computational needs will also be experienced during the next decade. The Federal Government, as well as other ADP users, has experienced a substantial increase in the use of technical personnel in its data processing operations since the mid-1950's. The total man-years expended annually has, from the mid-1950's, gradually increased to a level in excess of 136,500 man-years in fiscal year 1970. Our analysis of in-house programming efforts in the Federal Government over a 4- year period showed a 29.7-percent increase from 13,887 man-years in fiscal year 1966 to an estimated 18,019 man-years during fiscal year 1970. These statistics excluded man-years used for control systems and for Systems in classified physical locations. On July 1, 1970, the Blue Ribbon Defense Panel reported to the President and the Secretary of Defense that: APPENDIX VI "There is no significant software systems design capability in the Department. Such capability as exists is widely dispersed and focused on narrow spectrums, usually tied to specific applications. As a consequence, no effective mechanism exists for development of more flexible languages, compilers, **** Current practice makes the Department highly dependent on hardware manufacturers for design of systems s0ftwaxe.l' The report further pointed out that: "The numbers of skilled technical professionals in the ADP field needed to plan, specify and design major applications are not available in the Department. The skilled technical ADP professionals available within the Department of Defense are scattered among several organizations within the various components of the Department. There do not appear to be adequate plans for obtaining or training these professionals in sub- stantial numbers." This condition exists on a Government-wide scale in most all of the Federal departments and agencies. We believe that this un- coordinated and dispersed capability within the Federal Government and the individualistic demands placed upon computer systems have contributed to the phenomenal enlargement of programming efforts during the past 4 years. Moreover, little or no effort has been placed on building a software systems design capability or a capability to forecast the levels of effort necessary for good computer software management within the Federal Government. A question arises as to the extent of man-year levels of effort that will be necessary to fulfill software needs during the next decade and whether such large numbers of qualified people will be available if these uncoordinated management techniques are permitted to continue. It is important that plans be set to obtain the needed personnel resources and/or develop alternate plans to better manage the soft- ware asset we now have. The alternate plans should consider standardiza- tion of languages, modularity of programs, generalization of programs for use on various equipment, the generalization of programs for performing various applications, and other techniques leading to the reutilization of software products. NEED FOR STANDARDIZATION AND COMPATIBILITY A lack of standardization and compatibility exists in soft- ware used by the Federal users. This problem exists in the various 95 APPENDIX VI languages used by the data processing installations, as well as in data formats, techniques, and routines used for processing data, etc. This lack of standardization and compatibility in software has resulted from the apparent inability of computer manufacturers to agree upon standards for computer equipment and systems software and from the proliferation of numerous computer systems developed during the past decade. Also, the Federal Government has had to depend on the computer manufacturer for designing and providing much of its software. This tradition was established by the computer manufacturers when they provided equipment to customers under the total operational systems concept. (See app. I.) The rapid development of computer systems and software and current techniques employed for developing and obtaining programs have resulted in programming-pollution by the manufacturers and users. There are currently more than 125 computer software languages available yet two basic languages can be used for most general-purpose data processing needs; namely! COBOL and FORTRAN. COBOL, an English-like language suitable for most administrative-type data processing problems, is developed and maintained by a committee of representatives comprised of computer manufacturers and users. The FORTRAN language, the first to be used widely for solving numerical problems, has been implemented on almost all types of computer systems. Each manufacturer and user has been custom-designing programs to satisfy its immediate data processing needs, This approach has resulted in many versions of like computer programs being developed to satisfy the same need. We believe that it is necessary to more effectively use soft- ware. The new 370 series announced by IBM in July 1970 is ad- mittedly an extension of the concepts used in the third generation and merely provides for greater speeds and capacity. Most of the computer programs used on the third-generation equipment can be used on the 370 series of equipment with little or no modification. Also, RCA has announced new developments in some of its equipment. These developments permit the use of IBM program products on certain of RCA's computer systems with little or no modification. These evolutionary approaches to advancing the state of the art in com- putational sciences and the use of good management concepts will, we believe, promote greater and more effective use of computer re- sources. The software industry trends indicate that, to further implement this evolutionary concept, most of the fourth generation of programs APPENDIX VI will be developed in a modular nature, a procedure which will eliminate the necessity of writing complete routines each time a new or unique data processing need arises. For example, the following graphic presentation depicts one technique set forth in industry literature whereby a building-block technique is used to replace the existing hand-crafted art for developing computer programs: COMPUTERPROGRAMTO . . . ..COMPUTER..... SATISFY A DATA PROCESSING NEED . PROGRAM . . . . MAJOR SUBASSEMBLIES . . ESTABLISHED FROM OFF-THE-SHELF INPUT PR&ESS ACT (OR) COMPONENTS . . OUTPUT . . . . . . OFF-THE-SHELF-SOFTWARE COMPONETS . . . FROM VARIOUS VENDORS USED TO CON- . . . STRUCT THE MAJOR SUBASSEMBLIES INVENTORY OF SOFTWAREMODULES The introduction of such techniques for computer programming and the previously discussed announcements of two major computer manufacturers indicate that the time may be appropriate for the computer industry to coordinate its efforts and establish standards to ensure interaction and compatibility in its software products. In the past, the computer industry has been unable or not inclined to coordinate its efforts toward standardization and compatability. If such a condition persists in the future, we believe that the Federal Government-- as the largest user and the one most affected--must take steps to plan for acceptable standards for languages and techniques which will allow compatibility in the equipment and software it acquires. Also, efforts must immediately be made by the Government to establish standards for software documentation. Standardized documentation would facilitate interagency exchange of computer programs or modules. At the Myrtle Beach conference, previously mentioned, considera- tion was given to the proposition that software packages acquired for Government use ought to be supplied in standard languages to promote their utility and reduce their cost to the Government. It was pointed out that the Government's interests argue for the use of standard languages to facilitate the use of the product across a wide range of equipment models. USE OF COMPUTATIONAL RESEARCH Many man-years of effort are expended annually by the Federal Government and industry to research and develop the advancement of 97 APPENDIX VI the state of the art in data processing technology. The Federal Government has been a recognized leader in sponsoring computational research. Such research efforts, however, have been independently sponsored by the various Federal departments and agencies with little or no coordinating efforts Government-wide. There is no mechanism within management operations for identi- fying and managing the areas or extent of computational research sponsored by the Federal Government. When computational capabilities are researched and developed within an overall developmental project-- such as those in a weapons system --they are not specifically identified and are generally buried within the overall research and development effort. It is recognized that many of these efforts are directed toward dedicated computational capabilities. However, the knowledge gained in satisfying the immediate needs of the research efforts is sometimes later used in developing computer software for general-purpose use. (See app. I.) The lack of procedures to manage the computation research efforts was discussed in the July 1, 1970, Blue Ribbon Defense Panel Report to the President and the Secretary of Defense as follows: "NO office is charged with the responsibility to insure that research and development on ADP done by the Military Services or Defense Agencies, or under contract with them, is beneficially utilized Department-wide." Much has been done to date to make computers reactive to man's needs. As discussed in appendix I, the capability of computers has increased from hard-wired computational machines dedicated to mathema- tical analyses to the ability for man to verbally communicate with the machine. Although program languages of this nature have been developed, a need still exists for converting man's communication to machine-readable form. Currently, this technique requires the use of compilers, converters, etc., and of manpower to use them at each data processing installation. We believe that there is a need for the Federal Government to immediately plan and manage future research efforts for computer software. Some of these efforts should be directed toward: --Development of a more natural language for computers in an attempt to eliminate intermediary devices, such as compilers, converters, etc., in man-machine communi- cations. --Incorporation of a better mix of stored and machine programs, so that repetitious tasks could be machine- controlled rather than having to be written and in- corporated into each stored program. APPENDIX VI --Development and constant improvement in logic, design, algorithms and other disciplines used in developing computer programs. Such research activities should be coordinated with those of computer manufacturers in an effort to ensure effective results. Additionally, management of the Federal research efforts should provide for a central clearance organization to minimize duplication, coordinate joint ventures and interests, catalog on-going research and results, and establish Government rights in results of the re- search and the communication of such results to the user community. NEED FOR IMPROVEMENTS IN COMPUTERAPPLICATIONS Historically, computer manufacturers have been unable to provide applications programs to satisfy the needs of their customers and yet obtain maximum use of this machinery. Many of the programs offered with new equipment were originally custom designed for older equipment models and then "patched" so that they could be used on newly developed equipment. Also, manufacturers provided equipment so that existing programs could be used on such newly developed equipment in an emula- tion mode. Generally, new equipment developments provide for greater speed and capacity. Operating in an emulation mode reduces the speed of processing in the new machinery to a point where it can accommodate the speed capacity of the program being used thus decreasing the overall efficiency of newly acquired equipment. Such techniques were employed during the past decade due to the development of computer hardware at a faster pace than the development of the software. These types of activities and the rapid announcements of new computer equipment demonstrate a need to coordinate and manage the developments of computer programs so that an effective and efficient use of equipment on a Government-wide basis can be achieved. Some tools, such as commercially available computer software products, are available and can be efficiently used on computer systems in the Federal Government. Also, many applications are common to many users. In such cases, ex- pending the needed resources to centrally develop these application programs would be more beneficial than having each installation apply its limited resources on the same problems. We believe that other areas of concentration by the Federal Govern- c ment-- such as effective planning of data processing workflow, further development of systems software, and full use of real-time computer applications --are necessary for obtaining maximum efficiency from computer systems. These efforts should be centrally coordinated and managed by the Federal Government to ensure that all data processing installations benefit from new developments and techniques, which pro- vide improvements in computer applications. 99 APPENDIX VI NEED FOR PLANNING MECHANISMS An estimated annual ADP expenditure of $4.4 billion requires sound management from top officials within the Federal entity. Limited management policies exist for use of computers in the Federal Government with little or no coordination of activities in the acquisition and use of computer hardware and software for individual data processing activities. Although central policy guidance for determining the best means for acquiring computer hardware has been issued to agencies, no such action has been taken for computer software acquisition and management. Such central agency activity is necessary for effective future planning mechanisms in ADP management. It is recognized that each Federal department and agency has a separate mission to accomplish and must not be hindered in achieving its goals. Sound Government policies and practices dictate, however, that direction for management guidance must be centrally provided by experts. We believe that such planning can best be performed by a central executive agency especially organized to manage and administer ADP activities. The data processing activities of the Federal Government cost several billion dollars a year. There is little reason to expect much leveling-off of activities in the Federal ADP programs in the near future. On the contrary, indications are that greater use of ADP will be required in the years to come for Government purposes. Because of this huge and growing expenditure, we believe that stronger central guidance is essential for economical and efficient management of computer systems. We believe that OMB, under its authority assigned by Public Law 89-306, should sponsor the formulation of a master plan for the Government's ADP activities. 100 APPENDIX VII MANAGEMENTCONTROL Over the years8 GAO has issued a number of overall ADP management reports to stress the need for a strong organization to plan, coordinate, and control ADP activities. (See app. IX.) These reports, generally, were directed at the management of computer hardware and much has been done by the executive agencies and by legislation to provide better control over ADP equipment. Software represents an estimated $2 billion annual Federal expendi- ture and it too needs top-level-management control. NEED FOR SOFTWAREHANAGEMENT In the past, software was provided as part of the equipment and, as such8 software-management problems were not highlighted. Software now consists of a substantial part of the total ADP expendi- ture and usually can be separated. The need for management attention to software as a separate entity is now moxe pressing. The reconunen- dations included in prior GAO reports, although primarily addressed to the management of ADP equipment, apply equally well to the manage- ment of software. Throughout this report, we have discussed problems associated with the acquisition of software and the need to apply sound manage- ment principles to control this vast asset. We endorse the purposes of Public Law 89-306 for coordinating the purchasing function of ADP equipment into the GSA. The single-purchaser concept, if properly implemented, is a desirable feature of sound manage- ment. GSA, however has not been given absolute powers in acquiring ADP products, much less in managing the use of such products. NBS has played only a small role in the management leadership needed over software. Individual users have concerned themselves with the satisfaction of their own immediate needs, and such emphasis resulted in greater overall cost to the Government through inefficiencies characterized by duplications of efforts, misuse of resources, and failure to capitalize on the purchasing power of the total Federal Government. APPENDIX VIII RESUME OF PRIOR GAO GOVERNMENT-WIDE ADP MANAGEMENTREPORTS The General Accounting Office has issued several overall ADP reports to the Congress dealing with various management aspects of computer operations in the Federal Government. Generally, it was concluded in these reports that the vast Government investment in ! ADP resources needs high-level management. Following are the Government-wide ADP management reports issued by GAO: Survey of Progress and Trend of Development and Use of Automatic Data Processing in Business and Manauement Control Svstems of the Federal Government as of December 1957 I (B-1153691, dated June 27, 1958 . This report placed stress on the need for the Federal Government to establish a program that would provide a mechanism for central coordination for the development of ADP technology. GAO also placed emphasis on the need for individual agencies to undertake master planning for development of integrated agency systems, and it commented on numerous problems that required attention in individual agency electronic systems programs. Review of Automatic Data Processing Developments in the Federal Government (B-115369), dated December 30, 1960 In t'?is report, GAO again emphasized the need for more positive central planning of a long-range nature within the executive branch of the Government, in an effort to improve the overall management of ADP equipment on a Government-wide basis. GAO also suggested that Government agencies should give more consideration to purchasing ADP equipment, particularly in those instances where savings could be demonstrated over a period of several years. Study of Financial Advantages of Purchasing over Leasing of Electronic Data Processing Equipment in the Federal Government ; (B-1153691, , dated March 6. 1963 i This report again expressed the opinion that basic changes were needed in the Government's overall management system in order to realize substantial savings in the acquisition and use of computer 102 APPENDIX VIII systems by the Federal Government. GAO reiterated that the only practicable way in which coordinated management could be practiced to achieve these savings was through the establishment of a small, highly placed central management office in the executive branch of the Government. Review of PC Administration of Electronic Data Processing_ Systems in the Federal Government (B-115369) I dated April 30, 1964 This report reviewed some of the important Government-wide problems relating to the management and administration of electronic data processing facilities obtained and used by Federal agencies and their contractors. The review of these problems and the manner in which they could be resolved to the maximum financial advantage of the Federal Government reinforced an earlier GAO conclusion that an effective centralized management organization with appropriate authority and responsibility was needed to exercise control over procurement and use of data processing facilities and the related costs incurred by the Government. Management of Automatic Data Processing Facilities in the Federal Government (B-115369), dated August 31, 1965 In this report, GAO expressed its views 8n the conclusions reached by OMB in its report to the Congress regarding the management of ADP activities in the Federal Government. GAO again reiterated that the cost factors for Federal ADP activities were so significant in themselves as to warrant the establishment of a central office which would have appropriate authority and responsibility for pro- viding management coordination of ADP matters with the objective of minimizing costs. Maintenance of Au t@matic Data Processing Equipment in the Federal Government (B-115369), dated April 3, 1968 This report emphasized the need for the Federal Government to consider in-house maintenance of Government-owned ADP equipment in an effort to realize potential cost savings as well as other benefits derived from internally performing these activities. 103 APPENDIX VIII study of the Acquisition of Peripheral Equipment for Use with Automatic Data Processing Systems (B-115369), dated June 24, 1969 In this report, GAO emphasized the need for the Federal Government to capitalize on the substantial savings that could result by acquiring computer components from sources other than the computer system manufacturers. U.S GAO. Wash., D.C. 104
Acquisition and Use of Software Products for Automatic Data Processing Systems in the Federal Government
Published by the Government Accountability Office on 1971-06-30.
Below is a raw (and likely hideous) rendition of the original report. (PDF)