Computer Systems Software Reengineering: Technology A Case Study and Lessons Learned U.S. DEPARTMENT OF COMMERCE National Institute of Mary K. Ruhl and Mary T. Gunn Standards and Technology NIST NIST i PUBUCATiONS 100 500-193 1991 V DATE DUE '11// fr . — >^c"n.u, jnc. i(8-293 ~ 1— NIST Special Publication 500-193 Software Reengineering: A Case Study and Lessons Learned Mary K. Ruhl and Mary T. Gunn Computer Systems Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899 September 1991 U.S. DEPARTMENT OF COMMERCE Robert A. Mosbacher, Secretary NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY John W. Lyons, Director Reports on Computer Systems Technology The National Institute of Standards and Technology (NIST) has a unique responsibility for computer systems technology within the Federal government. NIST's Computer Systems Laboratory (CSL) devel- ops standards and guidelines, provides technical assistance, and conducts research for computers and related telecommunications systems to achieve more effective utilization of Federal information technol- ogy resources. CSL's responsibilities include development of technical, management, physical, and ad- ministrative standards and guidelines for the cost-effective security and privacy of sensitive unclassified information processed in Federal computers. CSL assists agencies in developing security plans and in improving computer security awareness training. This Special Publication 500 series reports CSL re- search and guidelines to Federal agencies as well as to organizations in industry, government, and academia. National Institute of Standards and Technology Special Publication 500-193 Natl. Inst. Stand. Technol. Spec. Publ. 500-193, 39 pages (Sept. 1991) CODEN: NSPUE2 U.S. GOVERNMENT PRINTING OFFICE WASHINGTON: 1991 For sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, DC 20402 Abstract This report is aimed at managers and technical personnel (both Federal Government and industry) who need to understand: • the concepts and issues of software reengineering, • the use of Computer-Aided Software Engineering (CASE) tools in the reengineering process, • and the application of this technology to organizational problems. Software reengineering involves the use of existing software and documentation to specify requirements, design, documentation, and to produce software for a target platform. CASE tools are expected to play an important role in automating parts of the reengineering process. In this report software reengineering and other related terms are defined and possible benefits that relate to this technology are described. The use of CASE tools for reengineering are examined. A case study that examines the feasibility and cost-effectiveness of software reengineering is described. Study results are addressed along with recommendations for organizations that are considering the use of reengineering. Keywords CASE (Computer-Aided Software Engineering) tools, design recovery, reengineering strategies, reverse engineering, software reengineering. Acknowledgments Special thanks to Wayne McCoy and Bruce Rosen of NIST for their valuable comments and guidance. We would also like to thank our reviewers: Dolores Wallace, and Neva Carlson of NIST; George Baird and Dr. Paul Oliver of Booz, Allen, and Hamilton Inc.; and Dolores Martinez, Cathy McKinney, Dan Scott, and George Wall of IRS. iii Executive Summary Software reengineering involves the use of existing software and documentation to specify requirements, design, documentation, and to produce software for a target platform. Many Federal government agencies and other organizations are evaluating the migration of older software to more powerful, more open computing environments. Additional system concerns include the high cost of software maintenance, the need to gain a better understanding of existing systems, and the impact of reduced computer systems budgets. Federal agencies are looking to software reengineering as a solution to these problems. A case study conducted by the National Institute of Standards and Technology (NIST) and the Internal Revenue Service (IRS) indicates that software reengineering can be a cost-effective, viable solution for extending the lifetime of an application system. The degree to which it is cost-effective depends on the goals for reengineering, the condition of the original application system and documentation, available automated tool support, and the involved personnel. The context for reengineering should be established in terms of the corporate goals for the organization before undertaking the task of reengineering. It is also important to clearly define the system goals and motivations for reengineering. Clearly defined goals are needed to determine a suitable approach for reengineering. A variety of approaches can be employed to gain the benefits of reengineering. These approaches differ by the amount of design that is to be retained from the original system, the organization's reengineering goals, the condition of the current system, and the resources to be allocated to the project. Before determining a reengineering approach, the application system should undergo a thorough evaluation to determine what is worth retaining for future use and what is not. During the evaluation, data definitions and usage, code, documentadon, maintenance history, and appropriate metrics should be analyzed to determine the current condition of the system. The case study indicates that full support for software reengineering from CASE tools is currently lacking in several aspects. Most currently available CASE tools are directed at one particular aspect of software reengineering and are targeted for a certain environment. Therefore, expectations for automated support from CASE tools must be realistic. Provisions in terms of personnel, effort and tools must be made to compensate for the lack of full support of the reengineering process by currently available off-the-shelf tools. Performing reengineering requires a highly trained staff with experience in the current and target system, the automated tools, and the specific programming languages involved. Application system experts must be involved throughout the reengineering process; they are essential for design recovery. Software reengineering is a complex and difficult process. The success of an organization's application of this technology wiU be determined by the level of commitment made by the organization. iv Table of Contents 1. Introduction 1 2. Software Reengineering and CASE Technology 2 2. 1 Definitions and Related Terms 2 2.2 Motivations For Reengineering 3 2.3 The Use of CASE Tools for Reengineering 4 2.4 The Repository 5 3. A Government Case Study 7 3.1 Background and Goals 7 3.2 Technical Approach 8 3.3 Issues 9 3.4 Findings 10 3.4.1 Process 10 3.4.2 Metrics Analysis 11 3.4.3 Reengineering Tools 12 4. Conclusions and Recommendations 13 4.1 General 13 4.2 Corporate, System, and Reengineering Goals 15 4.3 Condition of Original System and Documentation 17 4.4 Resources 20 4.4.1 Automated Tool Support 20 4.4.2 Personnel 22 5. Final Remarks 23 6. References 25 Appendix A: Function Point Analysis 27 Appendix B: Result Metrics Analysis 29 Appendix C: Glossary 33 V 1. Introduction Many federal agencies are faced today with the problem of operating and maintaining obsolete software and hardware. Gains in microprocessor, operating system, and communication technologies have enabled faster and more flexible computing than that which was possible when many of today's operational government systems were created. To achieve improvements in system operation and performance while protecting their software investment, many organizations want to migrate existing software to new computing platforms. The high cost of software maintenance (enhancement, adaptation to new environments, and error correction) is another problem facing many organizations. Usage of disciplined design, implementation, testing and maintenance methodologies helps to ease the maintenance costs, but estimates for software maintenance are still high — consisting of 60 to 80% of today's total software cost. The documentation of a software system is rarely up-to-date. Changes to the code are typically made without a corresponding change to the documentation. Inconsistency between documentation and code can make software maintenance difficult. In addition, the documentation may be incomplete. Unrecorded information may be known only to those who deal with the system on a daily basis and this information can become lost over the years due to personnel changes. Inconsistent and incomplete documentation complicates and lengthens the maintenance process and cause a dependence on certain system personnel for operation. In the 1960s, 80% of the total system cost (amount expended over the lifetime of the system) was appropriated for hardware and 20% for software. In 1985 these estimates had been reversed, with software consuming 80% of the system budget [FAIR85]. The reasons behind this trend are the dramatic decrease in hardware costs (due to advances in semiconductor fabrication technology), the labor-intensive nature of software, and the increase in personnel costs. The proportion of expenditure on software emphasizes the importance of structure and maintainability of software, and demands that software have a long lifetime. There is another economic factor driving the use of software reengineering. Cuts in government and industry budgets have reduced