Reengineering Definitions

The Joint Logistic Commanders Computer Resources Management group (JLC/CRM) authorized and sponsored a DoD policy workshop in Santa Barbara, California in 1992. Now known as SB-1, this workshop formally defined software reengineering terminology for the DoD. These definitions are in quotes below. The asides attempt to clarify these formal definitions.

Systems Engineering:

"The top level process of engineering a system to meet overallrequirements."

Software Reengineering:

"The examination and alteration of an existing subject system toreconstitute it in a new form. This process encompasses a combination of sub-processes such as reverse engineering, restructuring, redocumentation, forward engineering, and retargeting."

Aside: The new form of the subject system could be structured code - from "spaghetti" code; design information in graphical form - from input code; or the translation of the source code from one language to another while preserving the system's functionality.

Reverse Engineering:

"The engineering process of understanding, analyzing, and abstracting the system to a new form at a higher abstraction level."

Aside: This higher abstraction level is understood within the context of the software system's lifecycle. The classic waterfall development lifecycle calls for requirements/specifications followed by design, code, test, implement, and maintain. Thus, if we start with the code, reverse engineering will extract design information which is at a higher abstraction level in the lifecycle.

Forward Engineering:

"Forward engineering is the set of engineering activities that consume the products and artifacts derived from legacy software and new requirements to produce a new target system."

Aside: Notice the difference between software engineering and forward engineering. A hot topic within software reengineering circles is whether we even need the term "forward engineering" since this implies the normal development lifecycle sequence of events. If this was the extent of forward engineering, then forward engineering and software engineering can be considered identical terms. But we define forward engineering as using the output of reengineering. This implies that some reengineering must have occurred prior to the forward engineering activity. For example, the most common forward engineering activity involves the generation of source code from design information which was captured by a previous reverse engineering activity.

Data Reengineering:

"Tools that perform all the reengineering functions associated with source code (reverse engineering, forward engineering, translation, redocumentation, restructuring/normalization, and retargeting) but act upon data files."

Aside: As in source code reengineering, data reengineering must have a goal or target configuration. We call this a target meta model. For example, relational data bases (RDBs) are a desirable target meta model (currently, less than 5% of all data files are RDBs). Data reengineering tools help to translate flat files and hierarchical files to RDB's. Each reengineering activity for source code has a corresponding activity in data reengineering. Reverse engineering of data captures the design information of data files. Restructuring data could normalize that data. Data translation can move data files from a flat file configuration to a relational data base. And retargeting data files assists the migration of data to new platforms.

Data name rationalization (DNR):

Is a special case of data reengineering. DNR tools enforce uniform naming conventions across all software systems. DoD studies predict a 100 to 1 reduction in data names if such names were standardized and controlled across all services [Connall 92]. As Lt. General Peter Kind remarked at STC 94 "standard data is as important as standard equipment".

Redocumentation:

"The process of analyzing the system to produce support documentation in various forms including users manuals and reformatting the systems' source code listings."

Aside: Sometimes, the output of reverse engineering is thought to be the same as redocumentation. After all, when reverse engineering captures the design information from the legacy source code, the resulting information usually includes data flow diagrams, control flow charts, etc. The difference between redocumentation and reverse engineering is that the redocumentation usually generates system documentation according to a standard. For example, there are redocumentation tools that create documentation for DoD-STD-2167A - a DoD software documentation standard.

A special case of redocumentation tools are reformatting tools. Otherwise known as "pretty printers", reformatters make source code indentation, bolding, capitalization, etc. consistent thus making the source code more readable.

Restructuring:

"The engineering process of transforming the system from one representation form to another at the same relative abstraction level, while preserving the subject system's external functional behavior."

Aside: Recall that reverse engineering can extract design information from source code. Design is a higher level of abstraction than code (ref. most lifecycle charts). Restructuring code leaves the system at the same abstraction level (i.e. the coding level) but radically rearranges the source code to fit a new paradigm such as structured code or object-oriented code.

Retargeting:

"The engineering process of transforming and hosting or porting the existing system in a new configuration."

Aside: The new configuration could be a new hardware platform, a new operating system, or a CASE platform. A good rule of thumb is that if more than 20-30% of the software must be changed during a retargeting project, then redeveloping the software specifically for the new platform might be a better strategy.

Source Code Translation:

"Transformation of source code from one language to another or from one version of a language to another version of the same language (e.g., going from COBOL-74 to COBOL-85)."

Business Process Reengineering:

"The fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service, and speed." Hammer and Champy

Aside: Tools that support BPR include process modelers (and simulators) that allow organizations to run what-if scenarios on their key business processes. Other BPR tools enable an organization to set goals and gather information about current or projected processes.