The case for reverse engineering

Abstract

It may seem hard to choose between two software products, but studying their databases can reveal a clear winner and save you years of grief. The most productive way to reverse engineer a database is to build a model that conveys the software's scope and intent. For a clean database, you'll most likely want to prepare a model; for a flawed and poorly documented database, it may be best to stop after studying the style and quality of the database structure. At OMT Associates, we generally construct models-usually expressed as Unified Modeling Language (UML) object models. We typically organize reverse engineering into three phases-implementation recovery, design recovery, and analysis recovery. Reverse engineering is more than just a process for studying databases; it has profound implications for software development in general. You might view the reverse engineering of vendor databases as a creative response to the so-called software crisis. The current approach of preaching methodology and discipline isn't working, Software quality and development productivity still badly lag behind our desires. Database reverse engineering gives us both a carrot and a stick. The flaws and excellence of various products become more obvious and more heavily influence product success and failure. For a large corporation, the cost of the evaluation (as little as a few person-weeks) is trivial compared to the millions spent buying and deploying new software.