Software Re-engineering

Preface The essence of software re-engineering is to improve or transform existing software so that it can be understand, controlled, and used anew. The need for software re-engineering has increased greatly, as heritage software systems have become obsolescent in terms of their architecture, the platforms on which they run, and their suitability and stability to support evolution to support changing needs. Software re-engineering is important for recovering and reusing existing software assets, putting high software maintenance costs under control, and establishing a base for future software evolution. The growth in cost and importance of software to NASA, and the aging of many of the Agency's important software systems, has necessitated software re-engineering efforts. This technical report is designed to give the reader an overview of the concepts, approaches and risks of re-engineering. It is intended to serve as a basis for understanding software re-engineering technology. The information is primarily compiled from experts referenced at the end of the report, modified by approaches taken by NASA Projects. Section 8, however is new. It discusses Hybrid Re-engineering, an approach used by some NASA projects to combine the use of Commercial-Off-The-Shelf (COTS) software with new software development. The technical reports concludes with some industry lessons learned.

[1]  Linda H. Rosenberg,et al.  A Software Quality Model and Metrics for Identifying Project Risks and Assessing Software Quality , 1996 .

[2]  John E. Gaffney,et al.  Software Function, Source Lines of Code, and Development Effort Prediction: A Software Science Validation , 1983, IEEE Transactions on Software Engineering.

[3]  David A. Gustafson,et al.  A software re-engineering process model , 1992, [1992] Proceedings. The Sixteenth Annual International Computer Software and Applications Conference.

[4]  H. M. Sneed,et al.  A study on the effect of reengineering upon software maintainability , 1990, Proceedings. Conference on Software Maintenance 1990.

[5]  W. Stephen Adolph,et al.  Cash Cow in the Tar Pit: Reengineering a Legacy System , 1996, IEEE Softw..

[6]  James H. Cross,et al.  Reverse engineering and design recovery: a taxonomy , 1990, IEEE Software.

[7]  Eric J. Byrne Software reverse engineering: A case study , 1991, Softw. Pract. Exp..

[8]  Robert B. Grady,et al.  Practical Software Metrics for Project Management and Process Improvement , 1992 .

[9]  H. M. SNEED,et al.  Economics of software re-engineering , 1991, J. Softw. Maintenance Res. Pract..

[10]  M. K. Ruhl,et al.  Software Reengineering: A Case Study and Lessons Learned , 1991 .

[11]  R. S. Arnold,et al.  Software restructuring , 1989, Proc. IEEE.

[12]  Harry M. Sneed,et al.  Planning the Reengineering of Legacy Systems , 1995, IEEE Softw..

[13]  J. Manzella,et al.  Concept of re-engineering life-cycle , 1992, Proceedings of the Second International Conference on Systems Integration.

[14]  Capers Jones Applied Software Measurement: Global Analysis of Productivity and Quality , 1991 .

[15]  E. J. Byrne A conceptual foundation for software re-engineering , 1992, Proceedings Conference on Software Maintenance 1992.

[16]  Wojtek Kozaczynski,et al.  Automated support for legacy code understanding , 1994, CACM.