Acronyms and Definitions from The Software Reengineering Assessment Handbook

(JLC-HDBK-SRAH Version 3.0)

 

Cyclomatic Complexity:  A measurement of the number of linearly independent paths through a program: the number of control verbs plus one.  (See "A Complexity Measure", IEEE Transactions on Software Engineering, SE‑2, 308‑320, 1976.

Data Reengineering:  Transformation of data from one format to another format (e.g., going from flat-file to relational database format) (Santa Barbara I).

Data Standardization:  The "process of reviewing and documenting the names, meanings, and characteristics of data elements so that all users of the data have a common, shared understanding of it.  Data standardization is a critical part of the DoD Data Administration Program, managed under DoD Directive 8320.1.  Data administration is the function that manages the definition and organization of the Department's data"  [Memorandum data October 13, 1993 subj: "Accelerated Implementation of Migration Systems, Data Standards, and Process Improvement," page 3].

Essential Complexity:  A measurement of the level of "structuredness" of a program. (See "Structured Real-Time Analysis and Design" by McCabe et. al., IEEE COMPSAC-85, October 1985.)

Existing Software:  Existing source code, assembly code, documentation, or code implemented in firmware being evaluated for potential reengineering.

Existing System:  The existing hardware, software, and/or firmware that is being evaluated for potential reengineering.

Forward Engineering:  The set of engineering activities that consume the products and artifacts derived from existing software and new requirements to produce a new target system (Santa Barbara I).

Note:  Notice the difference between software engineering and forward engineering.  An issue within the software reengineering community is whether the term "forward engineering" is needed since it implies the normal development life cycle sequence of events.  If this were true, then forward engineering and software engineering can be considered identical terms.  But forward engineering can be defined as using the output of reverse engineering.  This implies 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.

Function Points:  The unit of measure used in Function Point Analysis (FPA).  It is a technique for measuring the "size" of a software project or system.  It is based on the functionality of the software expressed in terms of five components:  (1) internal logical files, (2) external interface files, (3) external inputs, (4) external outputs, (5) external inquiries.  Each component is rated according to a qualifying criteria provided in the International Function Point Users Group (IFPUG) Counting Practices Manual (STSC Software Estimation Technology Report, "Appendix G," March 1993).

Initial Operating Capability (IOC):  The date at which operational acceptance testing is complete and when support begins.  The first capability attainment to imply effectively a weapon system, an item of equipment, or system of approved characteristics, and which is manned or operated by a trained, equipped, and supported military unit (Defense Systems Management College).

Legacy System:  One of a set of "other AISs...that duplicate the support services provided by the migration system."  [Legacy systems] are terminated, so that all future AIS development and modernization can be applied to the migration system (Deputy Secretary of Defense memorandum dated October 13, 1993; subj:  "Accelerated Implementation of Migration Systems, Data Standards, and Process Improvement," page 4).

Note:  The term "legacy software" arises from the fact that these systems are frequently unstructured, undocumented, and are the legacy of earlier, less mature days of software development.

Lines of Code (LOC):  A measure of the size of computer software; a significant cost driver for development and maintenance; see also SLOC. 

Note:  LOC as a size metric has been criticized as being ambiguous and even meaningless.  While it is widely used, it may not be wise to rely on it as a sole measure of size.  If a decision is made to use LOC, care should be taken to ensure it is consistently applied across projects and that differences in languages are taken into account.

Maintenance/Support:  The process of modifying the existing operational software while leaving its primary functions intact.  Software maintenance can be classified into two main categories: (1) Update, which results in a changed functional specification for the software product, and (2) Repair, which leaves the functional specifications intact.  In turn, Repair can be classified into three main subcategories: (2a) Corrective maintenance (of processing, performance, or implementation failures), (2b) Adaptive maintenance (to changes in the processing or data environment), and (2c) Perfective maintenance (for enhancing performance or maintainability) (Boehm 81).

Management Decision Process:  A process for assimilating the results of the Technical and Economic Assessments (typically by technical questionnaire scores or economic indicators) to select the recommended strategy for each program and for prioritizing the list of programs.

 Migration System:  "An existing automated information system (AIS), or a planned and approved AIS, that has been officially designed as the single AIS to support standard processes for a function."  "A migration system is designated (or selected) by the OSD Principal Staff Assistant(s) and their Defense Component counterparts whose function(s) the system supports, with the coordination of the DoD Senior Information Managements Official."  From Deputy Secretary of Defense (memorandum dated October 13, 1993 subj:  "Accelerated Implementation of Migration Systems, Data Standards, and Process Improvement," page 4).

New Development:  The engineering process of developing new software by starting over at the requirements analysis phase without reusing existing requirements specifications, design, or code.  An extreme case of redevelopment rarely occurring.

Program:  Computer software (source code, assembly code, or code implemented as firmware).

Redevelopment:  The engineering process of developing a new system by starting over at the preliminary design phase and reusing the existing requirements specifications.

Redocumentation:  The process of analyzing the system to produce support documentation in various forms including users manuals and reformatting the system's source code listings (Santa Barbara I).

Note:  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 existing source code, the resulting display can take the form of 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 MIL-STD-2167A, the standard for documenting DoD software development projects.

Reengineering:  The examination and alteration of an existing subject system to reconstitute it in a new form.  The process encompasses a combination of subprocesses (strategies) such as reverse engineering, translation, restructuring, data reengineering, redocumentation, forward engineering, and retargeting, (Santa Barbara I).

Remaining Life (years):  The required lifetime, starting when the reengineering effort begins.  The sum of the reengineering time plus the operational lifetime of the reengineered software.

Restructuring:  The engineering process of transforming the existing system from one representation form to another at the same relative abstraction level, while preserving the subject system's external functional behavior (Santa Barbara I).

Note:  In contrast to reverse engineering (which takes in source code and extracts design information which is a higher level of abstraction than the code), restructuring code leaves the system at the same abstraction level (within the life cycle) of "code," but radically rearranges the source code to fit a new paradigm such as structured analysis or object-oriented analysis.

 Restructuring is commonly used to mean taking unstructured code and making it structured.  Architecture level changes need their own term and include changes to interfaces of modules, reduction of global data, remodularization of functionality, etc.

Retargeting:  The engineering process of transforming, rehosting, or porting the existing system in a new configuration (Santa Barbara I).

Note:  The new configuration could be a new hardware platform, a new operating system, or a Computer Automated Support Environment (CASE) platform.  In some cases utilization of CASE tools will not require a change of platform and the term retargeting would be misleading in cases where only a software change in the support environment is performed.

Retirement:  Discontinuing use of a system, without revision (Santa Barbara I).

Reverse Engineering:  The engineering process of understanding, analyzing, and abstracting the system to a new form at a higher abstraction level (Santa Barbara I).

Note:  This higher abstraction level is understood within the context of the software system's life cycle.  For example, the classic waterfall development life cycle 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 life cycle.

Source Lines of Code (SLOC):  A metric for software size.  Generally defined as executable source code statements.  Specific definitions vary among parametric software estimating models, and depend on the implementing language (See Lines of Code).

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 or from CMS-2 to Ada) (Santa Barbara I).

Status Quo:  Continued maintenance (support) of the existing software.  In the Economic Assessment, this is always Strategy #1 (Santa Barbara I).

Systems Engineering:  The top level process of engineering a system (hardware and software) to meet overall requirements.

Technically Acceptable Strategy:  A strategy identified by the Technical Assessment Process as a candidate strategy for addressing the reengineering requirement.  It must be a strategy that meets all related technical requirements.

Technical Assessment:  A process for screening and evaluating attributes of an existing computer program to identify candidate strategies.  These candidate strategies then will be economically assessed.

Technical Indicators:  Metrics, derived during the technical assessment, that identify which candidate strategies have comparatively the greatest technical need to reengineer.