DOCUMENT RESUME 03389 - [A2593734] Millions in Savings Possible in Converting Programs from One Computer to Another. FGMSD-77-34; B-115369. September 15, 1977. 14 PF. + 3 appendices (45 pp.). Report to the Congress; by Elmer . Staats, Comptroller General. Issue Area: Automatic Data rocessing. Changeover to Other ADP Systems 107) Contact: Financial and c-neral Mnagemtnt Studies Div. Budget Function: iscellaneoi,L. Automati Data Processing (1001). Organization Concerned: Department of COLmerce; Department of Defense; General Services Admiristration; Office of Management and Budget. Congressional Relevance: Coagress. Authority: Brooks Act (P.L. 39-306). Frequently, computer poqrams must be converted to make them run on a computer different fr-z the one for which they were originally devised. The annual Fedeial cost of such conversions is estimated at more than $450 million; over $100 million of this coulu be saved. Findings/Conclusions: The following factors tend to increase conversion costs: lack of readily available software conversion expertise in the Government; poor quality of software to be converted; inadequate flowcharts and other explanatory data; selection of nonstandardized equipment; and lack of programmer productivity aids. The Navy and the General Services Administration (GSA) are planning a Federal center for software conversion. This center could provide the know-how that is needed in software conversion and make it readily available to all agencies. Recommendations: The Office of Management and Budget should assist in establishing a Federal center for software conversion. When such a center is established, GSA should be able to require independent conversion estimates by the center for expensive agency procurements which have significant conversion costs. The center could also assist agencies in converting programs collected by GSA's recently established Federal Software Exchange Center. Beads of Federal agencies should emphasize quality and standards in new software development, including both the programs themselves and their documentation. The National Bureau of Standards should select and publish a set of programmer productivity aids for Government-wide use to improve the productivity of computer programmers on both original development of software and software conversion. (Author/SC) 3 ' REPORT TO THE CONGRESS ,- BY THE COMPTROLLER GENERAL - ." 't( ( (It " - OF THE UNITED STATES - Millions In Savings Possible In Converting Programs From One Computer To Another Office of Management and Budget Nationai Bureau of Standards Frequently, computer programs must be con- verted to make them run on a computer dif- ferent from the one for which they were origi- nally devised. The annual Federal cost of such conversions is estimated at more than $450 million. GAO estimates that over $100 mil- lion of this could be saved. Further savings will depend on future developments, some technological in nature. FGMSD-77-34 SEPTEMBER 15, 1977 COMPTROLLER GENERAL OF THE UNITED STATES WASHINGTON. D.C. 20548 B-115369 To the President of the Senate and the Speaker of the House of Representatives This report describes (1) the problems Federal agencies have in converting computer programs from one computer to another, (2) the annual cost and savings possible in this activity, and (3) how the savings can be realized. We made our review 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). We are sending copies of the report to the Director, Offic? of Management and Budget; the Secretaries of Commerce and Dfense; and the Administrator of General Services, who are addressed specifically by our recommendations, and to other interested parties. mptroller Gen al of the United States COMPTROLLER GENERAL'S MILLIONS IN SAVINGS POSSIBLE REPORT TO THE CONGRESS IN CONVERTING PROGRAMS FROM ONE COMPUTER TO ANOTHER Office of Management and Budget National Bureau of Standards D I G E S T In the early days of computers, the price of the equipment was the largest part of the costs. The programs which made the equipment operate cost relatively little. Today the program.-- software as they are called in the data pro- cessing community--cost considerably more than the equipment in most systems. One part of software cost that is large and not directly productive is called conversion cost. This is incurred to make programs devised for one computer work on another computer of a different make or model. Conversion costs should be reduced. If you buy a new stereo phonograph, you expect your present library of stereo records to play on it. This is because turntable speeds and record grooves are the same on all makes of phonographs. You cannot expect such a carryover where computers and computer programs are con- cerned. There is ittle standardization in com- puters; even different models of the same make may not un each other's programs without some changes. Considerable work is often necessary to make old programs "play" on a new computer. Admit- tedly, this analogy is simplistic--computers and phonographs differ greatly in complexity-- but it gives an idea of the situation. The effort needed to make computer programs work on a new computer varies greatly from case to case but, in the aggregate, is quite large. No good figures are available on Federal conversion costs as such, but GAO estimates them at about $45G million a year. GAO esti- mates that about 24 percent--over $100 million-- could be avoided in today's environment. (See pp. 3 and 4.) FGMSD-77-34 IRL.Sht. Upon removal, the report i cover date should be noted hereon. The following factors tend to increase conver- sion costs. (See pp. 5 to 7.) -- Lack of readily available software conversion expertise in the Government. -- Poor quality of the software to be converted, including unnecessary use of features peculiar to an old computer which do not work on the new one. -- Inadequate flowcharts and other data (called documentation) which explain the working of the software to be converted. -- Selection of new computer equipment that re- quires more work on conversion because equip- ment has not been standardized among manufac- turers. -- Lack of "programer productivity aids," or a set of tools and techniques to be used by programers, which could reduce the amount of human effort needed in conversion. Not all of these factors are readily controll- able, but GAO estimates that costs in the current environment can reasonably be reduced about 24 percent with good conversion planning and prac- tices. Since such a reduction offers savings estimated at over $100 million a year and be- cause better conversions would result in prompt- er, more effective Government services, the work needed to bring about better conversions, although considerable, will be worthwhile. The Navy and the General Services Administration are planning a Federal center for software conver- sion. (See app. I). The center could provide the know-how that is needed in software conversion and make it readily available to all agencies. To reduce conversion costs, GAO recommends that (see pp. 11 and 12): ii -- The Office of Management and udget assist in establishing a Federal center for software conversion. When such a center is established,the General Services Administration should be able to require independent conversion estimates by the center for expensive agency procurements which have significant conversion costs. The center could also assist agencies in converting programs collected by General Services Adminis- tration's recently established Federal Software Exchange Center. -- Heads of Federal agencies emphasize auality and standards in new software development, including both the programs themselves and their documentation. -- The National Bureau of Standards select and publish a set of programer productivity aids for Government-wide use to improve the pro- ductivity of computer programers on both original development of software and software conversion. Several agencies provided written comments on the matters discussed in this report. They generally agreed with GAO's conclusions and recommendations. (See pp. 12 to 14.) Yr S_ Lhet iii .. Contents DIGEST i CHAPTER 1 INTRODUCTION 1 Roles of various agencies I Scope of review 2 2 SOFTWARE CONVERSION IS A FREQUENT AND COSTLY UNDERTAKING 3 Why a better approach to software conversion is needed 3 Problems ir.software conversion 4 Ways in which software conversion costs can be reduced 7 3 CONCLUSIONS, RECOMMENDATIONS, AND AGENCY COMMENTS 10 Conclusions 10 Recommendations 11 Agency comments 12 APPENDIX I Where computer software is now, and how it got there 15 II Details of the separate sources of in- formation 27 III Agency comments 43 ABBREVIATIONS ADP automatic data processing COBOL, Common Business Oriented Language DOD Department of Defense GAO General Accounting Office GSA General Services Administration HEW Department of Health, Education, and Welfare NBS National Bureau of Standards OMB Office of Management and Budget CHAPTER 1 INTRODUCTION This report discusses the conversion of applications software, including its costs, causes of problems, and possible improvements. Applications software automates the tasks of users--such as payroll, accounting, and statis- tical calculations. Software conversion is the act of mak- ing computer programs run on some computer other than the one for which they were originally devised. The reason for converting existing application pro, nts, instead of witing new ones for the new computer, is that it is usually quicker and cheaper. Application programs are converted when (1) a replacement computer has been acquired and (2) where it is desired to shire a program that was written at another place. Recent congressional hearings 1/ were concerned with the treatment of conversion costs n automatic data processsing (ADP) procurement, but this report deals with conversion matters in general, not procurement policy alternatives. ROLES OF VARIOUS AGENCIES The basic law governing Federal ADP management is the Brooks Act, Public Law 89-306. Undrr this act, the General Services Administration (GSA) is responsible for procuring and maintaining Federal ADP resources. GSA receives techni- cal advice from the Secretary of Commerce primarily through the National Bureau of Standards (NBS) and both these agen- cies receive fiscal and policy guidance from the Office of Management and Budget (OMB). In or role of aiding the Congress, we are concerned with the management of Federal ADP and with computer soft- ware conversion as a frequent and expensive activity. 2/ Our past reports to the Congress have recommended im- provements in ADP management on a Government-wide basis and at specific agencies. 1/House Committee on Government Operations "Administration of Public Law 89-306, Procurement of ADP Resources by the Federal Government," October 1, 176. 2/For a discussion of the present state of computer applications programs, see app. 1. I SCOPE OF REVIEW Our review included questionnaires to Federal programers and supervisors 1,', interviews with experts, and a study uf the literature. The questionnaires were administered to 2,005 programers and 465 supervisors of ADP functions at 43 Federal computer installations, including business and scientific ones. Twenty-six were Department of Defense (OD) installations and 17 were not. The purpose the questionnaires was to obtain information on Federal conversion problems and remedies and cost estimating data from working level employees directly involved in the process. We discussed conversion problems with recognized software experts from both the Government and the private sector. We also made an extensive study of literature on software in general and software conversion in particular. Our review yielded an extensive bibliography, a soft- ware glossary, and a provisional planning checklist for software conversion projects. All are available on request. For copies, write to: U.S. General Accounting Office Attn: FGMSD-ADP 441 G Street NW. Washington, D.C. 20548 1/See app. II for some detail of our sources. 2 Chapter 2 SOFTWARE CONVERSION IS A FREQUENT AND COSTLY UNDERTAKING Software conversion is a frequent and expensive part of Federal ADP operations. Replacement computers are bought and installations must convert to them. Also, programs that are shared must be modified before they will work on the receiving installations' systems. Each situation requires a conversion effort which can range from trivial to enormous. WHY A BETTER APPROACH TO SOFTWARE CONVERSION IS NEEDED To assess the importance of software conversion, we asked about its frequency both in our questionnaires and our discussions with experts. We found that conversion to replacement systems is very common in Federal agencies, although at any one installation 7 years is the average time between computer system replacements. Federal organi- zations contacted during this review cited conversion problems as a major concern. On our questionnaires, over three-fourths of the supervisors and over two-thirds of the programers indicated that they had worked on at least one conversion to a replacement system, while one-half of the supervisors and one-third of the programers indicated that they had been involved in at least one conversion of a program brought in from another instal- lation. The Federal cost of software conveLsion for all ADP categories is estimated to be over $450 million annually. Its potential for reduction in today's environment is estimated to be over $100 million annually. This saving is available sol2ly from doing the samne jobs better in the current environment. Other alternatives, such as buying or sharing software, also have a great potential for more software cost avoidance, but such savings cannot now be quantified. We know of no good figures available on what the conversion of computer programs costs the Government each year or how much of it could be saved by better conversion techniques. Consequently, we could not make a precise determination of what either the costs or the potential savings might be. Recognizing, however, 3 that estimates are often useful in judging whether propo- sals are worthwhile, we made the best estimates we could of costs and potential annual savings. Admittedly, they are based on many approximations, but we believe they are reasonable, and they are supported by several consultants' estimates of conversion costs which were about the same as ours. In making our estimate, we determined that the Federal Government spends about $6 billion a year on software for all types of ADP and that about half of this, or $3 bil- lion, is spent for maintaining and converting computer programs after the software is acquired. We estimated that conversion costs to replacement systems are one- seventh of the $3 billion, or over $425 million, using 7 years as the typical life of a hardware system and 1 ear as the typical time it takes to completely convert an installation. Aother $25 million was estimated for converting programs acquired elsewhere (foreign pro- grams) for use on installation computers. The $25 mil- lion estimate is based upon programers' estimates of the percentage of their ime they spend on converting foreign programs, the number of programer and systems analyst staff-years reported to GSA, and the estimated average cost of a software staff-year. Thus, a total of over $450 million is arrived at for converting computer pro- grams. To get an idea of how much of this amount could be sa-ed by better techniques, we obtained estimates from programers and their supervisors through our auestionnaire and, separately, from experts wa contacted in the fields of computer program development and oftware conversion. The programers and their supervisors estimated that over 40 percent could be saved, while the experts' estimates averaged about 24 percent. We believe the experts, with their broader experience in the complexities of overall design and conversion work, have a better total perspective of the problem, and their more conservative estimate is probably more realistic. Using the experts' percentage, we estimated the potential savings in conversion costs in the current environment as over $100 n.illion. Our suqges- tions for achieving these savings are discussed later in this chapter. PROBLEMS IN SOFTWARE CONVERSION General costs Software conversion costs are incurred in several ways, including delays in user tasks, labor, retraining, inter- 4 ference, morale, and documentation. Each is discussed briefly below. -- Delay in automating user tasks. This cost of th conversion process isfT icult to estimate but may be the most important in some cases. If a conversion project is late, the user does not get the task(s) automated at the expected time. Hence, the adverse impact on the user's work or his clients may be great. -- Prpramer and analyst labor. This is the maior direct cost of conversion. We estimated that a typical staff- year of this type, with overhead and computer support, cost $33,000 in fiscal year 1976. --Retraining. This cost, which will be reater wFen the conversion is to a replacement system of a different vendor, includes retraining of system programers, computer operations staff, applications programers, users, and management. The retraining needed i, the case of converting a program from another installation depends entirely upon specifics of te situation, including the uality and size of th- program being converted, the degree of communication between originator and recipient, and the knowledge and motivation of the responsible programers at the receiving installation. -- Interference with other uses of the computer. A lengthy conver sion-efort may serousl-'yinterfere with other work that is scheduled :tobe done on the computer at the same time. On the other hand, the conversior could suffer if other work has priority. -- Employee morale. Employee morale may suffer durinq a conversion, especially if (a) there are indications of poor planning or (b) prolonged overtime is involved. -- Chaging documentation. This cost is very situation dependent. If original documentation is good and kept in a machine-readable form, it will be easier to change, but if documentation is poor, signi- ficant time and effort could be required to change it. Software conversion problems identified in our review -- Lack of readily available software conversion expert'se. Both t - uestionnaire … respondents 5 and the experts identified the lack of Federal software conversion experts and knowledge as the most important causes of problems in con- verting programs from other installations and significant causes of problems with conversions to replacement systems. Experts cited the fact that the typical installation which performs a conversion with its own staff is using people who very rarely do conversions since computers are generally replaced only every 5 to 10 years. The experts said that conversion would be better done by specialists. A Federal conversion center was often suggested as a solution. -- Poor ouality of the software to be converted to replacement systems and of its documenta- tilon. Since programs are usua-ly converted by persons other than their authors, either aspect of quality can vastly complicate the conversion. Poor quality of existing software has resulted from management failures to require excellence in software development and documentation, and to consider eventual conversion in the development of new software. Poor quality of the software includes code that is needlessly complex and difficult to understand and that uses unneces- sary computer resources. Failure to consider eventual conversion results in programers being allowed to unnecessarily use features of the cur- rent computer's programing languages that will not work on another make. -- Lack of standardization among manufacturers. Manufacturers typicalTy offer ADP systems and programing lnguages with features which are unique to their equipment. In the past, pro- gramers have been frequently allowed to, and have sometimes needed to, use such features. Thus, an installation's software inventory typically includes programs using such unique features, which do not conform to standards. If the replacement system is made by a different vendor, the unique features of the original vendor usually will not work on the replacement system, and partial reprograming is necessary to make them work. Better adherence to standards in software development to reduce the use of vendor- unique features would reduce this problem. 6 -- Lack of staff conversion experience, knowledge, or interest. Ths pro-em results because a given installation very seldom experiences conversion to a new system. (A 7-year system life is often cited.) Thus, due to normal turn- over, many of the employees who worked on a prior conversion may not be there for the next one. Also, people who are very skilled on one manufacturer's systems may know nothing of an- other's. Another staffing problem is that many programers and analysts are not interested in conversion. They perceive developing new soft- ware as more challenging and creative than con- version. -- Lack of programer productivity aids. Programer productivity aids can automate much of the drudgery of both writing original programs and conversion, Some can even provide partial translation from one manufacturer's programing language to that of another. If these aids are not present and used, programers must do much more by hard. The roblems identified for conversion of programs from other installations were basically similar to those identified for conversion to replacement systems. They included poor quality of the material to be converted and the conversion staff's lack of knowledge. However, there was the added problem of programs from other installations not being adequately studied before the decision was made to bring them in to see if they matched the needs of the recipient. In these cases, there was not only a conver- sion effort but also a modification effort much larger than if more suitable programs had been chosen. This prob- lem indicates that careful study is needed before the deci- sion is made to share programs from other installations. WAYS IN WHICH SOFTWARE CONVERSION COSTS CAN BE REDUCED There are several ways to improve software conversion which apply generally to both types of conversion. It would be helpful, for agencies anticipating a conversion project, to be able to turn to recognized impartial experts who could aid them in avoiding the com- mon pitfalls. We believe that significant savings would result if a center of expertise were available to such agencies to assist with conversions. The expert assistance 7 would include impartial evaluation of conversion aspects of procurements, selection of contractors to perform conver- sions, project management of the teams actually doing the conversions (either agency or contractor), and transfer of lessons learned from one conversion to another and from one agency to another. Such a center could also actually do conversions--requiring a larger staff than if conversions were not done by the center--and assist agencies that want to share software from the Federal Software Exchange Center. The Navy and GSA are now developing a cooperative agreement to establish such a center. We believe that such action would be a step in the right direction. More emphasis on quality in the original development of software and documentation would ease eventual conversion problems. Means of attaining better uality include better enforcement of documentatior. and other standards, adoption of the new software technologies 1/, better training for programers and systems analysts, and adoption of productivity aids. The possible greater cost of higher quality software development would be more than offset by (1) easier and cheaper future conversion and modification of the software, (2) fewer errors in the supported user tasks, and (3) more feasibility of sharing the software by multiple users. Also, the productivity improvements available from the new programing technologies and cooperative efforts to develop software for groups of users indicate that higher quality software need not necessarily cost more, and may in fact be cheaper, than the old method. More widespread use of automated programer product- ivity aids would also ease software conversion and origi- nal software development problems. These aids, which are already sold in the marketplace, include translation pro- grams which automate part of the translation process, text editors, which ease the "manual revision" part of conversion, and programs which can scan another program and print a flowchart for it. 1/See app. I, pp. 21 and 22. 8 Conversion costs can also be reduced by management recognition that most production programs will eventually be converted to newer equipment. Therefore, it is prudent to make every effort to avoid the use of vendor-unique features present in programing languages. Such avoidance will aid in reducing the conversion costs involved in new equipment procurement, and facilitate maximum competition. 9 CHAPTER 3 CONCLUSIONS, RECOMMENDATIONS, AND AGENCY COMMENTS CONCLUSIONS Software is the most costly element of modern ADP systems. It is both the ighest single cost of devel- oping an automates system and the system component with the most potential for adverse impact on the user tasks it supports. Malfunctions in these tasks have a potential for cost impact greater than the cost of developing the software. The conversion of software to replacement hardware systems is a recurring, frequent, and costly activity in the Federal Government. Program conversions among installations are now much less frequent, but greater sharing of software would increase them. Reduction of the time and effort needed for this type of conversion would encourage software sharing. More effort devoted today to developing better quality software and documentation would ease eventual conversion problems. Means of attaining better quality include better enforcement of standards (for programing languages, programing practices, and documentation), adoption of the new programing technologies, better train- ing for programers and systems analysts, and adoption of productivity aids. The greater cost of developing higher quality soft- ware would be offset by (1) easier and cheaper future conversion of the software, (2) fewer errors in the sup- ported user tasks, and (3) the increased feasibility of sharing the software by multiple users. Also, the savings from cooperative efforts to develop software for groups of users, and the productivity improvements possible with new programing technologies, mean that developing better software need not necessarily cost more chan the old methods. More widespread use of programer productivity aids would also ease both software conversion and ori- ginal software development problems. These aids in- clude automatic translation programs and programs which automatically scan another program and print a flowchart for it. 10 Management, anticipating eventual conversion, can direct that vendor-unique features be avoided where poss- ible 1/ in developing new applications for existing equip- ment. By avoiding such use, eventual conversion to replace- ment equipment of other manufacturers will be eased. We estimate that in today's environment $100 million can be saved annually thrcugh the use of techniques and activities cited above. We believe that achievement of these savings could be facilitated through establishing a Federal center for software conversion which would provide a pool of expertise for agency assistance. In the long run, even more savings in the software area may be attained as a result of other actions, especially standardization of more high-level languages and further im- provements in programing and documentation techniques. We plan to monitor these developments and report on them as appropriate. RECOMMENDATIONS We recommend that OMB assist in establishing a center of Federal expertise for software conversion. The services provided by this center should include impartial estimates of the conversion implications of system procurement alter- natives, contracting for software conversion, some capability to actually perform conversions, and a mechanism for transfer of lessons learned to future software conversions, develop- ments, and procurements. GSA should be able to require in- dependent conversion estimates by the center for expensive agency procurements which have significant conversion costs. 1/In cases where vendor-unique features must be used, we believe that management should require (1) that such use be justified by savings in operating costs, (2) that the justification be documented, and (3) that the use of the unique features be isolated into separable parts of the program (called modules). 11 We also recommend that the heads of Federal agencies emphasize quality in software development, promote stand- ards more vigorously, and require both their in-house staff and their contractors to observe standards. Standards to be promoted include programing languages, documentation, and programing practices. The guidelines recently published by NBS (FIPS PUB 38) 1/ offer a reference for documentation. Programing practices standards should include restriction of the use of vendor-unique features in software development. 2/ We recommend that NBS select and publish a standard set of programing productivity aids for Government-wide use. These aids would ease both the original development of software and its later maintenance and conversion. Here, "standard set" means standard in the sense that each aid's features and uses would appear the same to programers no matter which make of computer it was in- stalled on. AGENCY COMMENTS We asked HEW, DOD, CommeLce (NBS), OMB, and USA to comment on our preliminary report. Their replies, which indicated general agreement, are shown in ap- pendix III and discussed below. The Inspector General, HEW, said that he had no substantive comments. The Deputy Assistant Secretary of Defense (Comp- troller) said that he ajreed that sufficient benefit would accrue to make implementing our recommendations worth- while, even though he was "less optimistic about the po- tential for hard dollar savings" than we are. 1/Federal information processing standards publication 38. 2/Another possible means of restricting the use of vendor-unique features is that of requiring vendors to sell the Government programing language compilers which include only the standard lanquaqe (no special features unique to the vendor). This would force programers to avoid special features by removing them completely. 12 The Assistant Secretary for Administration, Commerce, concurred with our three recommendations. She stated that NBS recognizes the need for greater use of productivity aids and will work in this area as priorities dictate and re- sources allow. The Associate Director for Administrative Management, OMB, commended the report and agreed to support the establish- ment of a conversion center. He raised the question of whether or not the center should be the only source of conversion ser- vices Fderal agencies would be allowed to use. He suggested that agencies be allowed to use other sources as a way of sub- jecting the proposed center to competitive pressure. He also indicated that he feels the Federal Computer Performance Eval- uation and Simulation Center is an example of how to arrange the conversion center. In general, we agree that an arrangement like the above center has (i.e., agencies voluntarily requesting assistance) is appropriate for the conversion center. However, we be- lieve GSA should be able to require an independent estimate by the conversion center for expensive agency procurements in which conversion is a significant component of the total cost. We modified the report to clarify this matter. The Administrator of GSA supported our conclusions and recommendations, but said that we should have discussed con- version in terms of the broader problem of management plan- ning for future needs. We also realize that conversion oc- curs in a broader context of related matters, but feel that our report covers a subject which warrants attention and ac- tion. He said that while adoption of our recommendations would be beneficial, it would not substitute for good ADP installa- tion management. We agree. The Administrator discussed some software conversion problems, including mixes of agency-developed and contractor- developed software, and "efficient nonstandard programs." We realize that many Federal ADP installations have software developed by outside sources as well as by their own pro- gramers. We realize also that data base management systems are written in assembly languages (nonstandard) in the cur- rent state of the art and would not normally be converted. Concerning the use of uniaue features of programing lan- guages--which we advise against--the Administrator said that these features often provide advantages over the near term. We do mention that they must sometimes be used. However. the experts we consulted during our review felt that the near- term advantages of unique programing features are often 13 overrated and contribute unnecessarily to increased long-term costs without really reducing short-term costs. The Administrator disagreed with our suggestions to use industry-provided application software, saying that its lower- ing costs and speeding implementation are the exception, not the rule. During our review, we found that many users of pur- chased software are satisfied and intend to buy more. Also, user groups--including those of the International Business Machines Corporation and the Control Data Corporation--repeat- edly discuss purchased software as a viable and commonly used alternative to software written by the organization's own pro- gramers. It is true that such software . 'st often be modified, but modification can be much cheaper thai. writing complete new software. The Administrator said that it would have been helpful if we had more fully discussed the involvement of programing language standards with conversion. We are aware of the im- portant effect of standards (or lack of them) on conversion. We agree that better standards, together with compliance mechanisms, would greatly reduce the problem. We are now studying the Federal Information Processing Standards Program and will report our results to the Congress. 14 APPENDIX I APPENDIX I WHERE COMPUTER SOFTWARE IS NOW AND HOW IT GOT THERE In 1951, the Census Bureau installed the first business type computer in the ederal Government. The computer itself was expensive, large, and delicate. Its programing was done in machine language by a problem solver untrained in programing. The cost of this soft- ware was small compared to the cost of the hardware it controlled. From that beginning, software hs evolved until it is now generally the most costly single part of an ADP system; programing is recognized as a separate occupation which can be taught and managed; and there exists a very large invest- ment in programs running on current computers, many of which will eventually be converted to run on other computers. Several characteristics and issues in the software area were identified repeatedly in the literature and by practitioners. iMPORTANCE OF APPLICATIONS SOFTWARE An industry grout concerned with the future of ADP recently predicted that bv 1985 software will be about 90 percent of the total cost of a computer system. Also a recent GAO report, "Improvements Needed in Managing Automated Decisionmaking by Computers Throughout the Federal Government" (FGMSD-76-5, April 23, 1976), found that "software problems" are a major cause of expensive malfunctions of automated systems. Many administrative applications are automated in virtually every agency of the Government, and it is applications softwa:e that drives this automation. The Federal Government alone spends about $6 billion a year on computer software and now has large inventories of computer programs, many of which will eventually be converted to run on another computer system. This annual cost includes software conversion projects which are frequently expensive. For example, a single Navy con- version project reported approximately -- 100 staff-years of effort, -- a total direct labor cost of about $1.2 million, and -- conversion of 400 applications programs over a 12-month period. 15 APPENDIX I APPENDIX I Software conversion costs and difficulties are fac- tors in many procurements of new computer systems. The difficulty of conversion is often cited as a reason to buy a replacement computer from the same vendor. WHY SOFTWARE HAS BECOME SO IMPORTANT Two causes have made software a relatively larger part of ADP systems costs: one is increasing complexity and quantity of software functions demanded by users and the other is decreasing hardware cost. The first is due to the increased use of computers by laymen who want convenient automation which is tailor- ed to (1) their problem at hand and (2) their conven- ience--not the convenience of the machine or its pro- gramers. The ew user-oriented applications are very different from older clerical applications, such as payroll, which were the original uses of business auto- mation. Programs which provide user convenience are more complex, and since users demand convenience, the programers' work is becoming more complex. Besides more complex software, there is simply a de- mand for more software; there are more computers, and they all need software to make them run. With less ex- pensive computers, more organizations find more automation attractive, and again more software is needed. The growth in use of computers is shown by the following table. Comeuters_installed 1965 1970 1975 U.S. Government 2,412 5,277 8,649 Nationwide 23,000 70,000 175,000 Programers emp1oyed Nationwide 80,000 175,000 215,000 The steady decline in the cost of pocket calculators illustrates the second cause (cheaper hardware). The cal- culators use technology similar to that of computers, which are also going through similar decreases in cost per task done. The decreasing cost of electronic computing hardware makes software a proportionately larger part of the total costs of ADP systems. 16 APPENDIX I APPENDIX I TRADITIONAL PRODUCTION AND USE OF APPLICATIONS SOFTWARE Software development The life cycle of a unit of computer software is tided into development time and operational time. Development time ends when the software is in production automation of the user's task. Traditionally, a software Development project has had these characteristics: -- It cost more than was expected and ran late. Adding more people to late projects often did not restore them to schedule. -- The first production version delivered was really a prototype in conventional engineering terms. Besides the software itself being a prototype, its documentation was often sketchy or missing. -- Because a prototype was delivered, the postdevel- opment costs of fixing and modifying hare typi- cally been as great as the development cost and sometimes far greater. Several factors contributed to the situation. First, the invisible nature of both the work process and its product made software projects very difficull to manage and predict. Second, the explosive growth of the use of computers created a great demand for programers which, in turn, demanded the use of many new programers, most of whom learned on the job. Frequently, low productivity and poor quality of product resulted. Third. there was little idea then of how to train programers properly. Many were largely self-taught. Fourth, a tradition grew of programers as secretive craftspersons whose product3 during development, were their own property. Fifth, little attention was given to reducing some of the clerical tasks of programing. Programers' productivity was low because much of their time was occupied with such things a key- punching and running errands rather than programing. Software operation The operational part of the life cycle lasts from the beginning of production with the first version to the time that the software is replaced] or discarded. 17 APPENDIX I APPENDIX I During this period, costs other than normal processing ones may be incurred to correct errors in the software, to modify it to add new functions, or to convert it to run on another computer. They are all postdevelopment costs. Corrections of errors and modifications are commonly combined under the term "maintenance." The percent of programer time spent on maintaining software developed in the traditional way has been estimated from 20 percent to 80 percent. Software conversion costs are those special post- development costs which are incurred to make the software run on some other computer than the one for which it was written. They include delays in users' tasks, retrain- ing, programing labor, interference with other uses of the computer, documentation revision, and possibly lowered employee morale. We feel that 50 percent of total software costs is a representative value for all postdevelopment software costs, including conversion. LARGE GOVERNMENT INVESTMENTS IN ADP Federal investments in ADP to date include: -- Computer equipment. The table on page 16 shows the large number of computers now in place. GSA's reported fiscal year 1975 Federal ADP inventory shows almost $3 billion in owned hardware and over $1 billion in leased hardware. these computers, and theiz software, range from early to recent models. -- Pr'rams. There are now large numbers of com- . r'application programs in Federal agencies. -remendous effort has been spent on developing these programs; documenting, maintaining, and modifying them; and training operators and users. While the total investment cannot be estimated with any accuracy, its magnitude is indicated by the inventory of programs at the National Institutes of Health Computer Center in Bethesda, Maryland. At a recent meeting, NIH representatives indicated that this single installation has about 40,000 programs, with an estimated 10 million lines of code. 18 APPENDIX I APPENDIX I Using an original development cost of $8 per line of code would yield a software development cost over the years of about $80 million for just this one installation. While this figure is only an estimate, the inventory certainly represents a large expenditure. --Training. GSA reported that 33,694 Federal staff- years were spent on systems analysis and programing in fiscal year 1975. The cost of training that number of persons in the current methods of developing soft- ware, programing languages, and knowledge of pecific programs is difficult to estimate but is certainly very large. A SOFTWARE INDUSTRY NOW EXISTS In the early days of computers, almost all appli- cations software was developed by programmers who were employed by organizations operating the computers. Now, a separate industry produces applications software to sell. At a recent industry conference, the publisher of a software journal pointed out that total software in- dustry sales have grown from $4.5 million in 1970 to $750 million in 1975, that there are now 400 firms that sell software, and that about 3,500 different software packages are offered by these firms; of these, 2,200 are application oriented. A strong point in favor of using software that is already developed is that it is much less expensive to convert it to the new user's computer, if that is necessary, than to develop similar software anew. In some cases, new development can cost 10 times as many dollars and take 10 times as long. Many common tasks have been automated with programs gen- eralized so as to be useful to many organizations. This software industry is an alternative to Govern- ment agencies' producing their own applications software; use of this alternative could lower costs and speed im- plementation dates. SOFTWARE PROBLEMS GENERALLY Historically, projects to develop original software as well as conversion projects have been completed later than scheduled or at a higher cost than predicted, or both. Many causes contribute to this situation--some 19 APPENDIX I APPEND"' I managerial, some sociological, and some technical, as discussed below. Managerial The software field is still relatively new and lacks accurate means both in measuring its product- ivity and predicting its production. Workers who produce software practice an ill-defined and diffi- cult-to-quantify craft. They are commonly con- sidered to be in demand and difficult to retain and to manage effectively. Customers (end users) for whom the software is created often do not have a good definition of the process or function that they want automated. Changes requested after projects have started, which seem trivial to the customers, have often caused major rework efforts with consequent delays and increased costs. Socicloaical The experts and literature that we consulted indi- cated that many computer programers view themselves as craftsmen, with strong feelings of "I'd rather do it myself." This attitude was echoed by the programers who responded to our questionnaire. Traditionally, the programers' attitude was indulged because they were scarce. There is a feeling that if a program written elsewhere is brought into an installation then the local people must not be competent. This feeling has fre- quently caused installations to duplicate programing that had already been done elsewhere. Technical Programs are often designed and written hastily to meet deadlines and tested and documented inadeauate- lv or not at all. Thus, quality is sacrificed for ur- gency. Programs have been typically devised to run on one specific computer for the local task(s) of its owners. Little or no consideration is given to the prob- able eventual conversion of the programs. Eaca manufacturer supplies aids to programers which include features peculiar to that manufacturer's equip- ment. When programs written with these tools are to be converted to another manufacturer's equipment, these peculiarities must be replaced because they no longer work. This causes problems and increases costs. 20 APPENDIX I APPENDIX I Federal ADP procurement methods, intended to insure competition among prospective hardware suppliers, make it very possible that an installation's replacement computer will be purchased from a different manufacturer than the one the present computer was purchased from. For a vari- ety of reasons, it is more difficult to convert programs running on one make of equipment to another make than to convert them to a later model of the same make. Finally, mechanisms for transfer of technical knowledge about conversions from one Federal agency to another are primi- tive. Another problem with both technical and sociolo- gical aspects is documentation, which is material pre- pared to explain a computer program. Documentation is human-readable material over and above the actual code which drives the computer. Since the programer usually has a requirement to make the program work as soon as possible, documentation is often deferred until after the program is running. Once a given program is running, a new programing task may cause the work of documenting the first program to be shunted aside. Also, programers tend to shirk documentation, because it is less creative than actual programing. When that first program is later modified or converted, the work is usu- ally done by someone other than the originator. When documentation is missing, incomplete, or obsolete, the program conversion effort often must duplicate a great deal of the original development work. NEW SOFTWARE TECHNOLOGIES The recognition of a software crisis in the mid-1960s caused considerable attention to the need for improving both the management and the technology of computer software. Several organizations undertook projects to devise better methods. Their efforts have produced a group of software innovations, collectively referred to as the new software technologies, which include the following concepts: -- Software engineering: the idea that an engineering approach can be used in devel- oping software, as it has been in developing hardware. Software engineering includes many methods for the controlled design and devel- opment of high-quality software, including 21 APPENDIX I APPENDIX I both management approaches, such as chief programer teams, and technical approaches, such as structured programing. -- Chief programer team: a small team consisting, as a minimum, of a very superior programer as a leader, a backup programer, and a programing librarian or programing secretary. The team is supported by an automated facility called a development support library. -- Structured programing: a way of arranging the actual code of computer programs (by their authors) so that they will b more easily understood by others who must later maintain and modify them. -- Development support library: an automated facility which is used to maintain software development files, including programs, data, and documentation. The library is maintained, according to a standard set of procedures, by a trained person who is sometimes called a programing librarian or programing secretary. A number of organizations have reported significant improvements in terms of productivity, ease of main- tenance, and reduced errors in software development by adopting these techniques. STANDARDIZATION EFFORTS There have been a number of efforts to standardize facets of ADP, including software. A unique effort was the adoption of the American National Standards Insti- tute 1968 standard for the Common Business Oriented Language (COBOL) as a Federal Information Processing Standard. As of late 1977, COBOL is the only programing language for which a Federal standard exists. Attempts to comply with this standard have reduced the uifferences between different vendors' versions of COBOL. Meanwhile, technology has advanced. A 1974 COBOL standard has been adopted which is considerably different from the 1968 ver- sion. Some existing COBOL programs require modification before they will work with the 1974 version of COBOL. This modification is also a type of conversion. 22 APPENDIX I APPENDIX I ORGANIZATIONS' VESTED INTERESTS IN EXISTING METHODS The vested interests of users, data processing entities, standards groups, and management hierarchies are other factors in the software area. Organizations have adopted ADP, with its attendant investment in goods and people, as a part of their structures and a component of their budgets. Other organizations have been estab- lished to regulate the users. Both the adoption and the establishment were long, slow processes, and considerable inertia may now exist against sweeping changes. CURRENT EFFORTS TO ADDRESS SOFTWARE CONVERSION ON A GOVERNMENT-WIDE BASIS Some efforts currently address software conversion on a Government-wide basis. They include work by GSA, the Navy, the Air Force, and the House Committee on Govern- ment Operations. Each is discussed below. In October 1975, GSA received a contractor's study en- titled "Feasibility Study For Development of a Program Toward Competitive Procurement of Higher-Order ADPE." The relevant findings are paraphrased below: -- The movement of a particular ADP system workload to another ADP system (conversion) appears to be the major impediment to i ring full and open competi- tion in a procurement to replace or upgrade ADP be- cause of its costs. The cost of conversion is con- trolled by a number of factors, including inadequate or improper documentation, personnel not available to complete or correct documentation, programs writ- ten for specific hardware characteristics, programs not written in higher level language 1/, and pro- grams in higher level language using nonstandard or machine-dependent programing techniques. --While there is basic agreement 3mong ADP vendors and users alike that conversion problems are the main stumbling block to competition, there is little …-------------------------- l/Higher level languages provide a programed with a more con- venient means of writing a program which is then trans- lated automatically into a code that the machine can follow directly. 23 APPENDIX I APPENDIX I information available on the subject. Conversion experience is either not transferable or closely held. Hardware vendors do have considerable documentation and experience in conversion but tend to treat it as proprietary. -- Effective management is the kev to minimizing con- version costs. Since system life is in the range of 5 to 10 years, it is imperative that ADP manage- ment plan for system replacement. -- The first basic management tool to be implemented should be effective program library controls and reporting procedures. Any replacement upgrade rec- ommendation logically must be preceded by a study which determines that higher capability is needed. Such a study must include, as key elements, the condition, and efficiency on existing equipment, of the application programs. Proper program li- brary procedures would contribute significantly to the study by supporting statements about the number of programs to be converted, locating similar con- verted programs in other libraries, and showing whether or not programing standards are followed. -- The next management tool that should be implement- ed is a standard for machine-indepenuent program- ing [languages] and systems design to prevent equipment lock-in to single vendors. Both his- tory and the anticipation of the future indicate that machine-independent software is cheaper in the long run. -- A third management tool is the elimination of interim ADP equipment upgrades. These indicate failures of ADP management. Private-sector ser- vices could be used for workload that exceeds the present system while a replacement is OcL ight. -- A fourth tool is the charging of conversion costs to ADP operations instead of to the procurement process. ADP management is responsible for the status of the software, and the status of that software, including adeauate documentation and higher level language, affects operations today as well as in the future. Charging conversion costs to procurement hides ADP management pro- blems and virtually eliminates competitive pro- 24 APPENDIX I APPENDIX I curements. [GAO comment: This viewpoint is in opposition to many ADP managers, who claim that conversion cost should be considered part of the cost of each procurement alternative.] The Information Systems Division, Office of the Chief of Naval Operations, studied the costs reauired to convert its installations' operations into regional data processing service centers. The size of this effort (13,000 programs totaling about 8 million lines of code and associated files) and the presence of software con- version as a recurring Navy problem led to a feasibility study of a centralized conversion team in the Navy. The report, entitled "Feasibility and Desirability of Estab- lishing a Centralized Conversion Team Within the Navy," recommended that a centralized Navy conversion staff be established. It was to provide Navy installations with -- workload analysis and planning, -- general consulting, -- training in conversion techniques, -- "hands on" conversion performance, and -- contractor selection and contract manage- ment for conversions done by contractors. The study group was unable to ,quantify the savings that a centralized staff would effect but stated that they were certain that savings in money and staff time would result. At GSA's request the Navy's Federal COBOL Compiler Testing Service 1/ did a "Feasibility Study of a Federal Data Processing Service Center for Computer Systems Conver- sion Support" which suggested a Federal entity for software conversion to provide two categories of service to client agencies--analysis and solicitation. A cooperative venture with GSA was suggested similar to, but separate from, the Federal COBOL Compiler Testing Service. 1/The Federal COBOL Compiler Testing Service tests vendors' versions of COBOL to see if they comply with the Federal Standard. 25 APPENDIX I APPENDIX I In December 1976, GSA representatives indicated that an Interagency Agreement and Federal Property Management Regulation were planned. The U.S AeL :orce made a study of software conver- sion for its fiscal year 1976 Worldwide ADP Single Man- agers' Conference. The study, entitled "ADP Con- version Cost," recommended that: -- Conversion costs which can be clearly and fully satisfied and documented be included in the overall costs that are to be con- sidered in the selection of equipment ac- cording to GSA's Federal Management Cir- cular 74-5. --Air Force Regulation 300-2, paragraph 4g, be clarified by the addition of the words "and conversion" to read: "Total life cycle costs (not to exceed 8 years), including costs of acquisition and conversion, must be considered in determining whether the procurement should be sole-source or competitive." [GAO comment: This conflicts with the finding of the GSA contractor study cited above.] -- Conversion cost tracking be added to Air Force ADP Project management to accumulate data to improve future conversion estimates. -- The question of software system redesign be separated from that of software conversion. In June and July 1976, the House Committee on Government Operations, headed by Congressman Jack Brooks, held hearings on Federal ADP operations. On October 1, 1976, the Committee issued a report entitled "Adminis- tration of Public Law 89-306, Procurement of ADP Re- sources by the Federal Government." The hearings and the report surfaced conversion to replacement systems as a major concern in the management of Federal ADP. 26 APPENDIX II APPENDIX II DETAILS OF THE SEPARATE SOURCES OF INFORMATION This appendix presents details from our sources of information--experts and literature, and the question- naire data collection. While our sources substantially agreed about causes of problems and remedies, and these are shown in the text, there were minor differences of detail and emphasis. These slight differences reflected the different perspectives and orientations of the sources. Substantial agreement emerged on the major points, however. EXPERTS AND LITERATURE Causes of problems Experts and literature identified the following as major causes of software conversion problems: -- Lack of readily available software conversion expertise. Such expertise-is neeaea-and concepts of it ranged from that of consulting, which would estimate conversion costs to guide procurements, to that of an entity which would actually perform conversions for agencies. A contractor-operated entity to perform conversions was also suggested. -- Poor planning of conversions. Unreasonable demands of users and failures of programing management to estimate resources correctly, to schedule realistically, and to assign trained people to conversion projects were all cited as consequences of pcgr planning. Another plan- ning difficulty cited was that of allowing conversions to be complicated by demands for modifications to the software being converted. -- Procurement policy. Several experts criticized the Federa1low-b'1d hardware procurement policy, saying that ignoring conversion aspects of a procurement decision heavily penalizes organiza- tions that must convert their applications to another manufacturer's computer. (Our comment: We believe that, if software development antici- pated eventual conversion and took measures such as sharply reducing the use of vendor-unique 27 APPENDIX II APPENDIX II features by programers, this problem would be much less important.) -- Vendor-unique features. These features are plen- ifuiln older appications software. They are of standardization among there because of a lack features of vendors. and include vendor-unique programing languages (called extensions), depend- ence on unique hardware, etc., and were used to make original development easier or to make pro- grams use fewer computer resources. Modifying a program that contains vendor dependencies to remove them may be easy or it may be so dif- ficult that writing a completely new program is easier than converting the old one. However, the original writing of the program can often be planned to avoid such dependencies. -- Poor uality of the material to be converted. This category Incu-ed poor quaTity of T(i7he computer programs themselves and (2) their documentation. Poor quality of the programs can include errors and omissions, inefficiency, and incomprehensibility to anyone but the author. Poor quality of documentation may mean that it (1) does not exist, (2) is incom- plete, or (3) is obsolete. (Obsolete docu- mentation means that changes to the documentation have not kept up with changes to the software.) Perhaps the worst case is that of a currently dated documentation that was not brought up to date before it was reprinted. It looks current, but it is not. Facili- -- Absence of productivityaid facilities.in many ties ldeniified as missing and neede conversion situations include interactive term- inals, automatic translation programs, and aids for the manipulation of source code. The first quicker response to aid provides programers with tests of the converted programs, and the other two automate some of the work of changing the program. There -- Lack of people trained in conversion. mechanism today for seems to be no effective transmitting conversion experience from one project to another. We know of no formal training in conversion available within the Government. Frequently, junior people are 28 APPENDIX II APPENDIX II assigned to conversion projects. One reason is that conversion is deemed a less presti- gious task; therefore, senior programers avoid it. On the other hand, the private sector has several firms which specialize in conversion services. -- Confusion of conversion effort by concurrent reesign. Sometmes- the task of converting software becomes entangled with augmenting or redesigning it. Conversion means making the software produce the same outputs on the new computer (from the same set of inputs) as on the old one. Augmentation means to add func- tions to the program. Redesign may add func- tions or achieve the old functions in a dif- ferent manner. The often difficult task of conversion is frequently further complicated by concurrent user requests for augmentation or redesign. Suggestions for improvement by ex2erts and literature Experts' recommendations for conversion improve- ments varied, depending upon their backgrounds. Ven- dors' ideas included using their own products or serv- ices; persons in standards organizations recommended greater emphasis on standards; and a member of a DOD central software design agency recommended further cen- tralization of software development. However, agreement emerged on some points, which are discussed below. -- Federal center for conversion. Several experts eel that a FederaI center for software conver- sion would be extremely valuable. They offered various oncepts, from that of a small group which would estimate conversion costs for spec- ific procurements to that of a larger entity. Both would estimate and actually perform the below-listed services for client agencies. Concepts of its organization ranged from that of a completely Federal staff and facility, through a Government-owned contractor-operated facility, accompanied by an interagency agree- ment on management. Such a Federal center for conversion could: i. Assess conversion aspects of specific pro- curements or upgrades by client agencies. 29 APPENDIX II APPENDIX II 2. Contract for software conversion services for client agencies. 3. Cut conversion costs by performing con- versions for less skilled agencies. 4. Train in-house conversion teams from client agencies. 5. Help client agencies evaluate the suitability to their needs of using other software than that proposed for conversion. -- System procurement alternatives. Some of the experts felt that conversion costs should be given more consideration in the selection of large systems because (1) the high cost of conversion to a new vender may cancel any hardware savings and (2) conversion difficulty may cause a long, expensive delay in user func- tions. Such a consideration of conversion costs and time implies that some impartial entity should estimate them. This entity should have extensive experience with large-scale conver- sions. -- Human factors. Most of the experts identified these as crucial to the success of both software development and software conversion. Selection, retention, and continued training of analysts and programers are felt to be deficient. The large variaticn in ability to create software should be recognized, and better means of identifying and training good performers should be developed. Modern productivity aids should then be used to support the good performers. -- Software development that anticipates conversion. Software deveiopmenl project managers can antici- pate eventual conversions and take steps to reduce problems with them. Such steps can include stand- ards for programing practices, such as limiting programers' use of vendor-unique features, and re- quiring better documentation. -- Further centralization of original software design and development. This offers a large potential for savings through eliminating redundant software development and the ability of the central devel- oper to concentrate resources, the cost of which 30 APPENDIX II APPENDIX II will be s red by multiple installations. Such centralize ion could reduce conversion costs--a better job could be done of design and implemen- tation because multiple users would share its increased cost. Such centralization may implv displacing programers from field installations. Management and organization must recognize and sup- port technical methods before their potential will be realized. "- thwhile technical methods identified by experts nd in literature include: -- Government-wide distribution of automated conver- sion-aids and coversion manuaiTs. Such programs an other materials coul be selected, for the COBOL and FORTRAN / languages, from items al- ready developed. Management emphasis should ac- company their dissemination. -- Standards for roqraming practices. These should be forced for new software development, for both Federal and contractor-developed software. (Some agencies are already active here.) These standards could include the new programing technologies for software creation and some restrictions on the use and documentation of programing language features peculiar to a particular hardware vendor. -- Programer productivity aids. These should be in- stalled and their use encouraged wherever pos- sible. They include programs which print flow- charts of other programs and interactive term- inals. -- Training. Systems analysts, programers, and man- agers should be trained in the new programing technologies. Management should encourage their use in both software creation and conversion. l/Formula Translator. 31 APPENDIX II APPENDIX II THE QUESTIONNAIRE DATA COLLECTION Administration The questionnaire data collection was done to assess: --Working-level perceptions of the causes of soft- alue of var- ware conversion problems, and the .- ious means of improvement. -- The importance and frequency of conversion--how uften programers are involved in it, etc. -- Data on some related matters, including prcqramer demographics, language usage, training available, and programex activity breakdown. The mechanics of administration emphasized respon- dent anonymity as much as possible to get honest input from the working level. The questionnaire was admin- istered in a classroom situation by our reoresenta- tives. The respondents were briefed, and the question- naires were collected immediately after completion. Thus, local hierarchies had no way of knowing what a given in- dividual wrote on a questionnaire. Two quite similar questionnaires wre administered-- one to programers and the other to their supervisors. At a given installation, the supervisor group and the pro- gramer group were separated during the completion of their respective questionnaires. To give the respon- dents maximum flexibility, most questions were con- structed with a blank "other" choice where respon- dents could write in their own answers, as well as a convenient choice of answers. Our representatives who administered the uestion- naires reported that: -- There was no evidence of special selection of respondents by their local hierarchies. -- There was no evidence of rebriefing of the re- spondents on the subject. -- Respondents did not see copies ui the uestion- naire ahead of time. -- In almost all cases, respondents were favorably disposed toward the effort and indicated some interest in the subject. 32 APPENDIX II APPENDIX II -- In some cases, respondents expressed consider- able interest in the subject, including de- sire to see the results. Processing of the questionnaires further confirmed the respondents' interest in and good motivation toward the subject: -- Almost all of the collected questionnaires were completed carefully enough to be useful (1,983 out of 2,005 programer questionnaires and 458 out of 465 manager questionnaires). -- The last question on each questionnaire (left completely blank for respondents' other dis- cussion) was written in by over 21 percent of the programers and over 33 percent of the super- visors (after they had ompleted over 30 other questions). Also, there were numerous write-ins to the blank choices made available in the pre- ceding questions. -- A number of caustic write-in answers, such as "This questionnaire is a waste of time," showed that the respondents believed that they would be anonymous. Description _of sites and respondents The data collection reached 43 different ADP in- stallations, 2,005 programers, and 465 supervisors. The sites ranged from the smallest one, where 2 pro- gramer and 2 supervisor questionnaires were collected, to the largest one, where 325 programer and 91 manager questionnaires were collected. Figures 1 through 6 describe the sites and respondents. Figure 1 Site visited Region DOD Non-DOD Total Kansas City 16 10 26 San Francisco 3 6 9 Detroit 7 1 8 Total 26 17 43 33 APPENDIX II APPENDIX II Figure 2: Site populations by region: Average Average programers supervisors Region per site per site Kansas ity 60 12 San Francisco 39 11 Detroit 13 7 Figure 3: Experience of respondents-years in at- rocessing: Number with Mean Median Mode over 3 years Programers 9.2 8.1 8.0 a/1,565 out of 1,976 Supervisors 12.6 13.2 15.0 a/ 398 out of 458 Fi ure 4: Experience f respondents--years in_present vetob: Number with Mean Median Mode over 3 years Programers 5.1 4.1 1.0 a/1,100 out of 1,962 Supervisors 5.3 3.9 1.0 a/ 242 out of 457 Figure 5: Programers' and systems analysts' categorzaton of their present jo s: Category Number Percent Definite business orientation 645 32.5 Definite scientific orientation 312 15.8 All other answers, such as "senior analyst," "coder," etc. 1,026 51.7 Total a/1,983 100.0 a/The numbers of respondents differ in figures 3, 4, and 5 because slightly different numbers of people answered the questions. 34 APPENDIX II APPENDIX II Figure 6: Programers and systems analysts' experience with various prp1ami199guages: Extensive Moderate work work No work Language experience experience experience (percent) (percent) (percent) COBOL 59.3 18.8 21.7 Assembly 38.0 24.5 37.4 FORTRAN 28.0 17.9 54.0 Machine language 14.4 32.8 52.8 Data management languages 6.6 11.1 82.3 JOVIAL 6.2 2.1 91.7 BASIC 6.0 11.5 82.4 PL/I 3.2 5.7 91.0 RPG 2.7 12.4 84.9 ALGOL 1.9 2.8 95.2 GPSS 0.4 3.1 96.6 SIMSCRIPT 0.1 0.9 99.1 Causes of software conversion problems Both groups evaluated two lists of causes of conver- sion probiems--one list for conversion to a replacement system and the other for conversion of foreign programs. Both groups' choices on the lists were ranked by count- ing those who answered that a choice was "at least mod- erately important." Figures 7 through 10 show super- visors' major causes of difficulty for replacement sys- tems, programers' major causes for replacement systems, supervisors' major causes of difficulty of converting foreign programs, and programers' major causes for con- verting foreign programs, respectively. Figure 7 shows that the supervisors ranked poor documentation of the old application programs as the most important cause of difficulty of conversion to replacement systems. A close second was the inad- equate weighting of conversion considerations in selecting the replacement system to which the soft- ware had to be converted. The five highest ranked causes shown can be regrouped into two broad cate- gories: (1) poor quality of the material to be con- verted, which includes the first, third, and fifth causes and (2) poor choice of the replacement sys- tem, which includes the second and fourth causes. 35 APPENDIX II APPENDIX II Figure 7: Supervisors' major causes of problems with conversion to re acenient systems: Percent ranking cause important Cause_of_problems 87.4 Inadequate or missing documenta- tion of application programs. 87.1 Conversion considerations are not adequately weighted in the sys- tem selection process. 83.1 Many application programs are mono- lithic and "patched;" that is, they are NOT well structured, modular, or well organized. 82.0 Policy of selection of low bidder could force us to accept a less compatible system, such as one made by a different manufacturer. 79.2 Combination of personnel turnover and poor documentation has made many application programs vir- tually unintelligible. Figure 8 shows that the programers selected the same five causes as most important, with the same two ranked first and second, as the supervisors. The third, fourth, and fifth choices are in different order, but the differences are slight. Figure 8: Pro2ramers' maor causes of problems with conversion o replacemen t systems: Percent ranking cause important Cause of roblems 80.3 Inadequate or missing documentation of application programs. 77.4 Conversion considerations are not adequately weighted in the system selection process. 36 APPENDIX II APPENDIX II 73.4 Policy of selection of low bidder could force us to accept a less compatible system, such as one made by a different manufacturer. 73.2 Combination of personnel turnover and poor documentation has made many application programs vir- tually unintelligible. 73.1 Many application programs are mono- lithic and "patched"; that is, they are NOT well structured, modular, or well organized. Figure 9 shows that the supervisors rank to add new features to foreign programs as the the need highest cause of difficulty with their conversion. These five causes can be regrouped into three broad categories: -- Selection of unsuitable foreign software for conversion (first and fifth causes). --Poor quality of the material to be converted (second and third). -- Differences between vendors' products (fourth). Figure 9: Supervisors' major causes of problems with conversio--o- o oreg_ ams: _(note _a Percent ranking cause important Cause of problems 75.7 The task of conversion is complicated by the frequent need to add new fea- tures to the programs being converted. 73.7 Foreign programs are often poorly or inadequately documented. 72.5 Foreign source code is often poorly organized or does not contain embed- ded comments/notes/remarks; therefore, it is hard to read and comprehend. a/A foreign program was defined on the questionnaire as a program brought in from nother installation. 37 APPENDIX II APPENDIX II 67.0 Differences in the features readily available with different vendors' operating systems affect the conver- sion of applications programs. 62.9 Foreign programs need too' much modification to the needs of another installation to be worth it. Figure 10 shows that the programers ranked their own lack of knowledge highest, with documentation a close second. The programers' five causes can be re- grouped into four broad categories: -- Lack of knowledge of conversion (first choice). --Poor quality of the material to be converted (second and fourth choices). -- Poor management (third choice). -- Unsuitable material to be converted (fifth choice). We believe that the sligntly different opinions of the programrL3 reflect t-he fact that they and the super- visors hve a somewhat different perspective on con- version projects. (The supervisors ranked the "lack of knowledge" choice at 56.0, showing that they consider it considerably less important thai any of their own top choices.) ----------- ------- Figure 10: Proramers' major causes of roblems with converslonof foreign rams: Percent ranking cause important Cause of proolems 76.8 People assigned to conversion projects often have little knowledge of what they might encounter. 76.5 Foreign programs are often poorly or inadequately documented. 38 APPENDIX II APPENDIX II 72.7 Programers' supervisors allow them- selves to be talked into unreasonable deadlines. 70.7 Foreign source code is often poorly organized or does not contain embed- ded comments/notes/remarks; there- fore, it is hard to read and compre- hend. 70.2 The task of conversion is complicated by the frequent need to add new fea- tures to the programs being converted. ----------- --------- --- …- ------------ Figure 11 shows that the supervisors ranked better train- ing for programers as the most valuable source of improvement of conversion to replacement systems. The five means can be regrouped into three. -- Improvement of the performance of programers doing the work (first, third, and fourth choices). -- More consideration of conversion in the selec- tion of replacement systems (the second). -- Improvement of management (the fifth). The strong ranking given to the three choices in the first category indicates that the supervisors feel that programer training would be a very valuable means of improvement. Figure 11: Supervisors' major means of improving conversion tore/cement systems: Percent ranking method valuable Method of improvement 88.7 Better training for programers i.n superior programing practices. 83.7 More weight to conversion cost and problems in the selection of replacement systems. 82.7 Better training for programer in conversion problems and tech- niques. 39 APPENDIX II APPENDIX II 82.7 Ability to send the conversion team to appropriate specific training before starting work. 81.7 Better training for installation managers in conversion planning and estimating. Figure 12 shows that the programers also value train- ing highly, for themselves (highest), for their super- visors, and for user management. These five choices can be combined into (1) training for programers (first, second, and fourth) and (2) training for management (third and fifth). This result indicates that the programers attach even more importance to training than their supervisors do. We believe that the slight difference seen between the programer and superviscr evaluations is due to their different perspectives. The managers' probable involve- ment with the selection decision gives them a broader view. The emphasis on training here, coupled with the im- portance of the poor quality cause, indicates that train- ing programers to do a better job of originally writing programs is valued highly as a way to reduce future trou- ble with converting those programs. Figure 12: Programers' mjor means of improving converson r -tements:ste n eiace Percent ranking method valuable Method of improvement 83.4 a/Better training for programers in superior programing prac- tices. 80.8 Better training for programers in conversion problems and tech- niques. 77.8 Better training for installation a/These were defined for the respondents in a previous aues- tion, which they were referred to. 40 APPENDIX II APPENDIX II managers in conversion planning and estimating. 76.8 Ability to send the conversion team to appropriate specific training before starting work. 74.4 Required training for user/ customer management to increase their awareness of the possible implications of their requests and deadlines. Figure 13 shows that the supervisors value training highly in the area of conversion to foreign programs also. Again, the means can be regrouped: -- Better training in conversion (first and third choices). -- Better enforcement of documentation practices (second). -- More attention to conversion in selection of software (fourth). -- Better management (fifth). Of these, the first and second are aimed at improving the original quality of the material to be converted, and the others are aimed at better conduct of the conversion effort itself. Figure 13: Supervisors' maor means of improving Percent rankig conversion o Toroelgnprograms: Percent ranking method valuable Method of improvement 86.6 Better training for programers in superior programing practices. 84.1 Better enforcement of good documentation practices. 83.3 Ability to send the conversion team to appropriate specific training before starting work. 41 APPENDIX II APPENDIX II 81.1 More weight to conversion costs and problems in the selection of foreign programs to be converted. 80.4 Better trainir for installation managers in conversion planning and estimating. Figure 14 shows that the programers also value train- ing highly. They selected four of the same five most im- portant causes and ranked them somewhat differently. As with the supervisors' choices, the first is aimed at im- proving what will eventually be converted better deve- lopment), as is the third; the other three ae aimed at better conduct of the conversion itself. Figure 14: Proramers' maor means of improvin¶ conversion o.f oreign prorams: Percent ranking method valuable Method of improvement 84.7 Better training for programers in superior programing prac- tices. 80.7 Better training for programers in conversion problems and techniques. 79.1 Better enforcement of good docu- mentation practices. 78.9 Better training for installation managers in conversion planning and estimating. 78.7 Ability to send the conversion team to appropriate specific training before starting work. 42 APPENDIX III APPENDIX III DEPARTMENT OF HEALTH, EDUCATION, AND WELFARE OFFICE OF THE SECRETARY WASH INOTON, D.C. Slad JUlT 1 1911 Mr. Gregory J. Ahart Director, Human Resources Division U.S. General Accounting Office Washington, D.C. 20548 Dear Mr. Ahart: The Secretary hs asked that I respond to your request for our comments on 'o3ur draft report, "Federal Spending for Conversion of Computer rograms Could Be Reduced." We have carefully re- viewed your report and have no substantive comments. Thank you for the opportunity to review this draft report before its publication. Sincerely yours, omas D.Morris Inspector Gneral 43 APPENDIX III APPENDIX III ASSIANT SCRETARY OF one WAINeVTON, D.C. 01. MAY 13 1977 Mr. D. L. Scantlebury Director, Division of Financial 6 General Management Studies General Accounting Office Washington, D. C. 20548 Dear Mr. Scantlebury: This is in reply to your letter to the Secretary of Defense regarding your report dated April 8, 1977, on "Federal Spending for Conversion of CoMputer Programs Could be Reduced," OSD Case #4597. While we are somewhat less optimistic than you about the potential for hard dollar saving as estimated in your draft, we support the contention that sufficient benefit will accrue to warrant establishment of a conversion center, vigorous promotion of quality and standards in software development, and standardization of software tools. Sincerely, P. Welsch Deputy Assisfint Secretary of Defense 44 APPENDIX III APPENDIX III .~ %.. I UNITED STATES DEPARTMENT OF COMMERCE The Asistnt SecrearyVfr Adminstration Washington., D.C. 20230 5 JUL 77 Mr. Henry Eschwege, Director Community and Economic Development Division U. S. General Accounting Office Washington, D. C. 20548 Dear Mr. Eschwege: We have reviewed the draft report to Congress, entitled "Federal Spending for Conversion of Computer Programs Could Be Reduced" and concur in the three recommendations contained therein. With regard to the recommendation concerning establishment of a Federal software conversion center, we believe this subject was exhaustively studied by the Department of Defense and the General Services Administration. This center is currently being used by several Federal agencies, including this Department in our Employee Information System conversion project. [See note below.] Concerning the recommendation that the National Bureau of Standards select a set of tools and techniques for Government-wide use to improve the productivity of computer programmers, NBS recognizes the need for greater use of productivity aids and will devote its efforts in this area as priorities dictate and resources allow. Sincerely, Assistant Secretary for Administration GAO note: The Navy's Federal COBOL Compiler Testing Service is doing some conversion work, but as of this writing, there is no interagency agreement for- mally establishing the conversion center itself. 45 APPENDIX III APPENDIX III UNITED STATES OF AMERICA GENERAL SERVICES ADMINISTRATION WASHINGTON. DC 2005 June 9, 1977 Honorable Elmer B. Staats Comptroller General of the United States General Accounting Office Washington, DC 20548 Dear Mr. Staats: We have reviewed the GAO draft report entitled "Federal Spending for Conversion of Computer Programs could be Reduced", and offer the attached comments. If there are any questiona, please let us know. Sincerely, oel W Solomon Adinistrator Attachments Keep Freedom in Tour Fuiure With U.S. Savirks Bonds 46 APPENDIX III APPENDIX III GSA COMMENTS GAO Draft Report "FEDERAL SPENDING FOR CONVERSION OF COMPUTER PROGRAMS COULD BE REDUCED" A The GAO report identifies some of the major problems encountered in software conversion and recommends that a Federal Center be established for software conversion. In particular, it cites poor DP management practices, (conversion planning and training), enforcing the use of standard higher-level programming languages, and the lack of good documentation as contributing substantially to the software conversion problem. Overall the report is a credible effort addressing a complex subject and we support its conclusions and recommendations. Yet its treat- ment of conversion is too narrow. Taken by itself, many of the observations and recommendations are true but the principal and underlying factor complicating the conversion issue is the lack of planning -- the management trade-off of major long term benefits at the expense of near term costs. Conversion and all its underlying symptoms (such as lack of documentation and unique programming features) are a result of a failure of management to adequately plan for future needs, even if it increases near term costs. The rport should recognize this broader problem and note that conversion is but one of its sub-issues. While adoption of the report recommendations would address some of the software conversion problems, it would not serve as a viable substitute for implementation of good DP management at the installation level. * The report is supportive of efforts to establish the Federal Conversion Support Center. The proposed functions of the Center will more than satisfy GAO's recommendations. However, there are complex software conversion problems, not directly discussed in the report, which the Center will be confronting: Conversion of systems which are compris d of various software programs developed by the incumbent equipment vendor, proprietary software firms, as well as the user agencies. GSA/ADTS 47 5/31/77 APPENDIX III APPENDIX III Conversion of efficient non-standard programs (such as proprietary data base management packages and to higher level standard languages which, if accomplished, could be extremely costly. [See GAO note below.] Although the Center will dramatically improve the present conversion environment, its establishment will not serve as a panacea anc result in the immediate resolution of all Federal ADP conversion cost issues. Many of the pr¢rblems confronted by the ADP cornmunity will require in-depth analyse.s and evaluations before the Government can expect to see the situation improved or the problems resolved. * The report indicates that te use of unique programming features add considerably to the ccnversion effort required and that programmers should not use these features (or that at least they should be more closely controlled). While valid, the report fails to recognize that these unique features often provide programming and operational advantages over the near term. * The report suggests that use of industry provided applications software cculd lower costs and speed implementation. This i the exception and not the rule. Generalized software packages can sometimes satisfy small applications requirements but frequently require modifications to fit specific needs. * Data processing activities do not adhere to existing established Federal programming language standards. For example, although a Federal standard exists for COBOL, some data processing activities have waived this requirement and other(s) use vendor extensions to the standard COBOL, which make application software programs vendor dependent and incompatible with one another. These practices pose significant software conversion evaluation problems with any follow-on procurement. It would be helpful if this type of problem were addressed more fully in the report. GAO note: Deleted material is not relevant to this final report. 48 APPENDIX III APPENDIX III [See GAO note 1.] A copy of the questions included in the report would have been helpful. [See GAO note 2.] [See GAO note 3.1 GAO notes: 1. Deleted comments are not relevant to this final report. 2. The questionnaires were omitted from the report to e- duce its bulk. 3. Deleted comment is not relevant to this final report. 49 APPENDIX III APPENDIX III EXECUTIVE OFFICE OF THE PRESIDENT OFFICE OF MANAGEMENT AND BUDGET WASHINGTON, D.C. 003OI JUN 3 0 1977 Mr. D. L. Scantlebury Director, Division of Financial and General Management Studies U. S. General Accounting Office Washington, D.C. 20548 Dear Mr. Scantlebury: We are in receipt of your draft report entitled "Federal Spending for Conversion of Computer Programs Could be Reduced" transmitted by your letter of April 8, 1977. Mr. Lance has asked that I provide you with OMB's comments. We believe this report sheds some valuable light on a subject which has been of substantial concern to OB over the last few years. We are particularly pleased that you have provided an estimate of both the total cost of soft- ware conversion ($450 million) and an etimate of possible savings that can be ahieved by proper management (24%). At a convenient point, I would like to have my taff gain a better understanding of the basis for this stiate so that we can work towards achieving the savings which you identified. With respect to your recommendation that OMB support the establishment of a software conversion center, we agree. We understand that GSA and Navy are currently involved in negotiations to set up a center which would provide the serviLcs you recommend. One aspect of this recomen- dation, however, is unclear. We are uncertain whether you believe the center should, by regulation, be made the exclusive source for the various conversion services it will perform, i.e., estimates, contracting, performing conversion, or experience transfer. We have found that any publicly funded service monopoly has a tendency over time to degrade in performance and cost effectiveness unless it is subjected to some degree of competitive pressure. If this is intended in your recommendation we would suggest that this aspect be re-examined. We believe the Federal Computer Performance EValuation and Simulation Center provides an excellent example of how a center of expertise can, through the force of competition, review itself and maintain efficiency. It 50 APPENDIX III APPENDIX III does not have exclusive jurisdiction ever any of the services it provides but it has a steadily increasing demand for its ervices because of the quality of its products. We would also call to your attention the views which OMB expressed in a letter to the Chairman of the Government Operations Committee (copy enclosed). OMB's responses to Committee recommendations 10 through 14(See GAO note.) are particularly relevant to the subject matter of this report. Sincerely, Wae Gr ista Associate Director for Administrative Management Enclosure GAO note: The deleted recommendations are not relevant to the subject matter of this report. 51 APPENDIX III APPENDIX III January 19, 1977 Honorable Jack Brooks Chairman, Committee on G <-ignment Operations House of Representatives Washington, D.C. 20515 Dear Mr. Chairman: This letter is in response to your letter of October 5, 1976 requesting OMB views on House Report No. 94-1746 entitled Administration of Public Law 89-306, Procurement of ADP Resources by the Federal Governrifnt." Our comments and suggestions in regard to each of the 19 recommendations contained in the report are enclosed. The hearings conducted by your Committee last summer and the subsequent report have served to identify a number of significant problems in the management of Federal ADP re- sources. These problems must be addressed and we have taken positive steps to do so. Due to the significant impact which the recommendations could have on the future direction of Federal ADP manage- ment, OMB invited the larger ADP user agencies and a number of trade associations to provide comments on the Committee's recommendations. The responses which we received are enclosed for your information. It is apparent from these responses that there is a strong consensus regarding the significance of the pro- blems outlined in the report, but there is a wide divergence of views as to the causes of these problems. There are also strong differences of opinion regarding some of the solutions proposed. In short, there is agreement on the need to address these problems but no consensus on how to solve them. In concluding the hearings on July 1, 1976, you indicated that "o]nly time will tell whether these hearings will have a beneficial effect" and expressed the hope that "the report to follow will provide the necessary impetus 52 APPENDIX III APPENDIX III for the future ainistration of the law." We believe the report has achieved that initial objective. A of recommendations have already been implemented or number are in the process of being implemented. Where there are differences of opinion regarding some of the proposed solutions, we have either suggested alternatives or have taken steps to identify workable alternatives. We would also like to stress that there is no quick solu- tion to many of the complex issues which you have identified. For example, the development, coordination and implementation of standards, which are a prerequisite to the solution of a number of the problems identified, are not easily or quickly achieved in an area of rapidly changing technology. Similarly, the development, coordi- nation and implementation of an effective long range planning process will not be brought about easily or quickly. These, and other basic reforms needed, will require a sustained effort by the Federal ADP Community accompanied by extensive consultation with the Congress, the private sector, State/local governments and others which would be affected by such reforms. As OMB Deputy Director Paul O'Neill indicated during his testimony, we look forward to working in close with the Committee in furtherance f our mutual cooperation objectives of making effective use of computer technology. With best wishes. Sincerely yours, /t/ Jlam T.Lo James T. Lynn Director Enclosures cc: Secretary of Commerce Administrator, GSA 53 APPENDIX III APPENDIX III (See GAO note, p. 51) Recommendation 10 - NBS must develop necessary hardware and software standards to insure maximum economies and efficiencies in the procurement and utilization of ADP resources. OMB agrees with this recommendation. We believe that the Federal ADP standards program needs to be strengthened to achieve greater efficiency and eco.,omy. Such strengthening of the standards program must, however, be accomplished in a manner which will not stifle competition or preclude the Government from taking advantage of new technology. Comments received from agencies and representatives of industry are very supportive of this recommendation and pro- vide many constructive suggestions on approaches to achieving an appropriate balance between the sometimes conflicting objectives of reducing cost, exploiting technological develop- ment and encouraging competition. A number of actions to strengthen the standards program have been initiated by OMB and NBS. In general, they focus on: o A reappraisal of the goals and objectives of various ongoing standards development activities. o A greater emphasis on defining the potential benefit pf proposed standards or guidelines before undertaking the development of such standards or guidelines. o A prioritizing of these activities so that resources can be focused on those activities which will produce the greatest benefits. 54 APPENDIX III APPENDIX III A greater emphasis on clearly prescribing (in the applicable FIPS PUB) all policies, responsibilities and administrative actions required for appropriate implementation of each standard or guideline. These include: - Whether the standard is mandatory or voluntar. - Specific implementation actions which agencies are expected to take. - The conditions or criteria under which waivers to mandatory standards may be granted. - The procedures for granting waivers. - The time frame for implementation. - The requirements for use or disposition of existing inventories of nonstandard supplies, hardware or software. - Requirements for including the standard in procure- ments by GSA and/or the agency. o Establishing a process for monitoring implementation of each standard and evaluating whether it is meeting its intended objective and, subsequently revising the standard, as appro- priate, based on operational experience or changing conditions. o A greater emphasis n evaluating technology trends and their mplicatins in regard to the Federal ADP standards program. Recommendation 11 OMB must establish procedures for the effective enforcement of ADP standards and designate GSA as the agency to enforce compliance with such standards. OMB is in complete agreement with what we believe to be the objective of this recommendation - to achieve compliance with mandatory standards - but only partially agrees with the proposed means for achieving this objective. We believe that the Department of Commerce (NBS) under P.L. 89-306, E.O. 11717 dated May 9, 1973, and the policy guidance provided to the Secretary of Commerce by OMB in a letter dated December 15, 1966 has adequate authority for the Federal ADP standards program. In our view, NBS has the responsibility to develop and implement the type of standards program en- visioned by P.L. 89-3"' and E.O. 11717 and this would necessarily entail, among other things, the articulation of the goals and objectives of such a program (e.g., compatibil- ity in equipment), the development of appropriate standards 55 APPENDIX III APPENDIX IIL or guidelines to achieve those goals and objectives, the development of the means for assuring the effective imple- mentation of these standards or guidelines and the development of the means to monitor and evaluate the impact of such standards or guidelines. We believe that P.L. 89-306 con- templates that the exercise of this authority by the Department of Commerce (NBS) be undertaken in coordination with industry, the user agencies, GSA and OMB in order to ensure that the requirements of these entities are met and to permit effective implementation. Some questions have recently been raised by representatives of the Department of Commerce in regard to the scope of responsibility and authority in particular matters vested in the Department of Commerce (NBS) by P.L. 89-306, L.O. 11717 and related OMB policy guidance. We will explore and resolve these questions with the Department in conjunction with our plans to reissue OMB Circular No. A-71 as indicated in response to recommendation 3. We are satis- fied that the standards or guidelines contemplated can be effectively implemented through existing authorities, but should the need for additional authority become evident, such authority shall be sought. In our view, good management requires that overall respon- sibility for the Federal ADP standards program be retained by one organization and not be divided. It has been and continues to be our belief that the Department of Commerce (NBS) is the logical organization to carry out these responsibilities. Retaining the overall responsi- bility for the Federal ADP standards program within the Department of Commerce (NBS) does not, in our view, pre- clude the Department from coordinating, assigning, or delegating certain authorities for developing, implementing or monitoring compliance with individual standards to the agencies, GSA or others as appropriate. We believe the method for implementing individual standards will depend upon the nature of the standard. For example, we would agree that mandatory standards which affect products or computational services purchased by the Federal Government should e implemented largely through GSA procurement regu- lations. On the other hand, we question whether GSA should categorically be nade responsible for "enforcing" all FIPS PUB's including those which provide guidance to agencies on the use or management of their ADP resources. Such assign- ment, depending on the nature of the standard, could be in conflict with the provisions of the Act which precludes GSA from interfering in agency use of ADP. Further study of this question is necessary. 56 APPENDIX III APPENDIX III We believe that determinations on the most appropriate means for implementing Federal ADP standards must be made on a case-by-case basis. We are working with NBS to establish a program for proceeding with analysis as outlined in our response to recommendation 10. Recommendation 12 - All ADP procrams should be converted to higher level langua es except in those cases where OMB specifically determines that the national interest requires otherwise. (MB agrees that more emphasis should be placed on agency use of high level languages since such languages facilitate the conversion of software from one hardware system to another and reduce the costs inherent in such conversions. However, precise criteria must be established for determining whenmore it is in the national interest to use high level languages, either in the conversion of existing software or in writing new software. Agency comments indicated general agreement with the recom- mendation that greater use be made of high level languages but urged that mandatory use of high level languages be limited to new software. They expressed the concern that, even were it possible to do so, the conversion of all existing software to higher level languages would be very costly, unnecessary and counterproductive to the goals of economy and efficiency. Most agencies that commented on recommendation 12 felt that existing software should be converted only when it is economical and efficient to do so. We believe that the appropriate way to implement this recommenda- tion is to have NES: o Establish standards, or refine existing ones, on the use of high level languages for new software. o Establish criteria to determine under what conditions existing software should be converted to high level languages. We believe that this is a more appropriate way to approach the problem than having OMB review software on a case-by- case basis to determine if it is in the national interest to convert it. As indicated in our response to recommendations 10 and 11. the NBS guidance should include appropriate mechanisms for implementing and monitoring compliance with the standards. Given the advantages that can accrue from the use of high level languages we believe that NBS should place a high riority on efforts in this area. 57 APPENDIX III APPENDIX III Recommendation 13 - Software conversion costs should not be considered in the evaluation of bids for the procurement of ADP systems except to the extent that such costs involve direct out-of-pocket costs for program conversion. OMB and the agencies have had some difficulty formulating a response to this recommendation since the meaning of the phrase "direct-out-of-pocket" costs is unclear. It is our understanding that this recommendation: o Stems from a concern that agencies frequently justify less than fully competitive procurement on the grounds that software conversion would be too costly to consider alter- natives requiring such conversion. o Assumes that the implementation of recommendation 12 will significantly reduce software conversion costs. o Is intended as an interim measure to enhance competition until such time that recommendation 12 is implemented. As indicated in our response to recommendation 12 we endorse the use of high level languages and the development of appro- priate standards for converting existing software and writing new software. The approach recommended by OMB would permit the orderly conversion to high level languages in an economic and efficient manner over a period of time. This approach and the other steps we are taking, such as promoting functional specifications, promoting research on standardized data base management systems and improving long range planning, should reduce the costs of conversion and lead to fuller competition in ADP procurements. OMB believes that this recommendation should not be implemented prior to the conversion of most software to high level languages. If agencies were required to ignore the costs of software con- version in the current environment they might be placed in the position of having to select a significantly more costly alter- native without any offsetting public benefit. This would, of course, be contrary to the P.L. 89-306 goal of economy. OB believes that ADP procurements should be conducted in a manner such that each ADP system is evaluated on the basis of its total system life cycle costs, including software conversion costs and the least cost alternative is selected. Generally, the agencies took issue with the Committee's recommendation and expressed the view that all costs associated with converting from one system to another should be considered and that it would be unfair to have an agency absorb software conversion costs. 58 APPENDIX III APPENDIX III We believe that it is GSA's responsibility to develop a costing methodology for ADP procurements which will provide guidance on what cost elements should be considered in comparing alternative systems and under what conditions specific costs may be excluded. We would urge GSA to work closely with the Committee staff in order to assure that the staff's intentions regarding direct out-of-pocket costs are fully considered. We also understand that the GAO has undertaken research in this area. When the results of this research become available GSA should review the GAC efforts and take action to implement appropriate recommendations. Recommendation 14 - Research should be undertaken pursuant to OMB's direction aimed at the development and use of management information systems which contribute to competitive ADP procurements and utilization. OMB agrees that research relative to the development and use of standardized data base management systems should be undertaken. Standardized data base management systems should ultimately facilitate the conversion of data files from one hardware system to another and lead to greater opportunities for competitive procurements. P.L. 89-306, E.O. 11717 and the OMB policy letter of December 15, 1966 assign the responsibility for the Federal ALP standards program including ADP research to the Department of Commerce. The National Bureau of Standards has recently created a task force to study problems associated with data base management systems. We will work closely with NBS in this area. (See GAO note, p. 51) (91306) 59
Millions in Savings Possible in Converting Programs From One Computer to Another
Published by the Government Accountability Office on 1977-09-15.
Below is a raw (and likely hideous) rendition of the original report. (PDF)