Craig L. Williams

Don McNeeley

BSA 400

March 31, 2002

Forward, Reverse, Re-engineering

            Various methodologies exist when working within the software development cycle.  Sometimes older code needs to be upgraded, or new requirements need to be reengineered onto new hardware.  Most projects involve at least two of these methodologies.  Let’s take a brief look at each of these methodologies before we address what important part management should understand about these software development methodologies and when they should be used within their company.

            Reverse Engineering is becoming more needed these days.  Old applications are being redefined after the original system analysts and programmers have retired or have left the company.  This method starts with an application that is working today.  However, you have to break into the code and figure out how the program is doing what.  This way you can define the specific requirements prior to upgrading the application.

            Re-engineering is when you take the requirements and modify them to fit a new code environment.  Lots of companies took the opportunity to Re-engineer some of their older code from old COBOL programs to newer code platforms during the Y2K conversion a few years ago.  These companies recognized the value of starting the work early and taking advantage of updating code while it was “cracked” open.  Others opted to just change the code to include a 4-digit year but leave the application running on the older COBOL code.  

            Forward engineering is when you change an application from its current form into something new using newer technology.  As an example, these companies that were reengineering the code during Y2K, might also forward engineer the code at the same time to take advantage of client-server environments available today.  These were generally not available in the 50’s and 60’s when the older COBOL code was originally written.

            Showing that all of these methodologies might need to be used at the same time is rather easy.  Take a look at the Y2K projects launched by various Fortune 500 companies during the late 80’s and early 90’s.  Some companies reversed engineered their existing applications to understand what the applications were doing and what the requirements were.  They then upgraded them for today’s environment by forward engineering them using client-server technology.  At the same time they also reengineered the code from older platforms to a newer one.

            Management needs to understand the differences between these methodologies to properly make the business decision when to use which.  Should an application be forward engineered, should it be reengineered or should they just leave it alone?  Any option will cost money.  So a return on investment (ROL) or a cost analysis (CA) will need to be completed for management.  These documents should point out clearly to management what the current costs are associated with leaving the application like it is today.  In a CA you can outline alternatives and advantages between options. 

            Some organizations might be in a better position, long term, by spending the time now to reverse engineer, reengineer and/or forward engineer an existing system.  At Quest Diagnostics, our Incoming Specimen Information System (ISIS) was developed and used at our Teterboro, New Jersey laboratory.  The Teterboro laboratory processes over 1 million specimens per month making it the largest medical laboratory in the United States.  The ISIS system has been modified and enhanced over the years to account for the changing regulatory requirements as well as changing laboratory requirements from new tests being added or modified (Dempsey).  The system was written in FORTRAN, which is rapidly becoming a dead computer language.  Thus, maintenance costs have risen over the years.  These costs include the scarcity of qualified programmers to maintain the code.  Many years ago, the system was reengineered from its original platform to a Compaq Alpha VMS platform (Allen). 

            Today, management has decided to standardize our 20 plus specimen processing front ends across the company into one application.  The “new” Intelligent Data Acquisition and Accessioning system (IDAA) was reverse engineered in January and February 2002 (Allen) by the programmers and analysts who maintain the existing ISIS system.  Currently they are working on the reengineering part.  They are taking the requirements, updating them for the new environment and redefining pieces that always needed work but they never had the time to rewrite.  Later, they will forward engineer the requirements into a new code that will be easier to maintain.

            The last step to this process will be the conversion and standardization of all specimen input applications to using the single “new” IDAA system.  Thus, quality of specimens will be assured through out the company when dealing with the handling and processing of specimens.

            Management understood that by spending the hundred’s of thousands of dollars now, they will benefit from increased productivity, increased customer satisfaction, increased employee satisfaction, decreased maintenance costs and decreased vulnerability from lack of programming support.  Now was the time to reengineer the application into a newer and more universal application through reverse engineering, reengineering and forward engineering methodologies.  Management understood these processes and decided it was within the best interests of the company to undertake the project now rather than stay with the status quo.


Allen, Jeff. Personal interview. March 2002.

Boyce, June. Personal interview. March 2002.

Company to Standardize Specimen Management Functions: OurQuest: Vol. 4, Number 115.

Quest Diagnostics Incorporated. 17 December 2001.

Dempsey, Nancy. Personal interview. March 2002.

Goldyn, Debbie. Personal interview. March 2002.

Kennedy, Ph.D., Ronald. Personal interview. March 2002

McNeeley, Don. Week Three Lecture. March 2002.