Reverse Engineering (The Beginning Stages)

What is reverse engineering?  Visualize walking into any company that has a ten year old application that they still use today and was written in Visual Basic 6 code.  They want the application upgraded to .NET code.  You have zero requirements, zero documentation about the application, and the current VB 6 application is actually broken and does not perform the duties it was intended to do.  Are you walking out the front door yet?  If not, in order to successfully convert the application, you will have to use reverse engineering.  Walking backwards in time (reverse) and figure out how the current application behaves (engineering).  Now let’s patch it all back up and improve this dinosaur application.

1. The first thing you need to do is automatically pull or create a current database diagram. What are the names of each table and each column name?  The properties of each column can come in handy as well.  The table relationships are also another highly recommended candidate.  Now that you have your database diagram, from the big picture view, analyze the data in front of you.  Does anything strange stand out?  A first name column name that has a length property of 80,000 characters?  Do any of the table relationships seem odd or out of place?  Run queries against the tables to ensure you do not have 50 empty tables for example.  You aren’t required to fix every single little thing that is wrong with the current database; you are just looking for red flags that may make the upgrade process a nightmare of sorts.   Always be on the lookout for potential road blocks.
2. Obtain all documentation that you can find, if any, even old specifications. If you are lucky enough to have archives, it is now time to dig through them to see what is going to be of value to you today.  Requirements and screen prints may prove useful, put those in one pile and items such as old meeting minute notes from 2009 are probably not going to buy you anything, put those in the other pile.  It is probably a good idea to see if you can find a self-help guide if one is listed on the current web-site.
3. Now it is time to start documenting the flow of the application via the web side of the house. Start on the landing page and screen print each page of the application and all the different flows through the application that a user can take.  Yes, you are essentially creating a help guide, but a more advanced one.  I recommend making comments at the top of the page such as, “I clicked this link on the landing page to be navigated to the login.aspx page.”  Via descriptive text and pictures you are displaying the entire flow of the application.  I highly recommend doing this in a test environment unless you have permission to be in the production environment due to data reasons.  After ensuring that test and production builds are a replica of each other.   <Side Hint: If your application contains any type of Reporting – always start with Reporting – as it can be the trickiest part of the entire application.>  If you get stuck at trying to figure out how a certain flow in the application works, you can refer to your pile of interesting documentation you were able to compile and if you have no documentation, it is time to dig into the code.
4. Take your web side of the house document (application screen prints) and have it peer reviewed for grammatical errors or flows that do not make sense. It is suggested to have a non-technical user review this, hopefully someone who knows how to use a computer at least, but is not a full blown Developer.  A Project Manager, a Business Analyst whom is not familiar with this application.  Fix the mistakes that they point out.
5. After that, the application screen prints need a high level review by a subject matter expert (SME) on the application or the Business User of the application. Adjust for the changes they may find.  They are really only making sure you did not miss a huge chunk of functionality or a certain flow.
6. Time to dig deep into the code. You will need a copy of the code base to explore and to create a Code Design document.  For the Code Design document you are pretty much going to follow your previous screen prints created.  It is recommended to use Visio or a similar tool for this process.  For example:
   • I’m on the Landing page (Front End)
     • What is the URL for the landing page? Landing_Page.action
     • What is the landings page code behind file name? Landing_Page.jsp
   • I click a link and I am now on the Login page (Front End)
     • What is the URL for the login page? Login_Page.action
     • What is the logins page code behind file name? Login_Page.jsp
   • How do the Landing page and the Login page talk to each other? (Back End)
     • What is the action between the two pages? Login.java

Front End URL:  → Landing_Page.action Landing_Page.jsp	Back End  → Login.java	Front End URL:     Login_Page.action Login_Page.jsp

7. Create the System Design Document that will tie all of your documentation together. What is contained in a System Design Document:
   1. Revision History
   2. Document Overview
   3. Scope
   4. Audience
   5. Project Executive Summary
   6. System Overview (URL’s & User Types/User Matrix)
   7. System Architecture
   8. Software Design
   9. Database Design
   10. Glossary
8. KINKOS print – This document can now be given to a Business Analyst to create requirements for the application re-write.