[PDF](+36👁️) Télécharger DTIC ADA267117: Reengineering: An Engineering Problem pdf

AD-A267 117 Special Report


in iii'i uni mil mu


CMU/SEI-93-SR-5

Carnegie-Mellon University

Software Engineering Institute



♦


Reengineering:

An Engineering Problem


♦


Peter H. Feiler


July 1993


♦


♦


♦


♦s


DTIC

ELECTEI
JUL23 1993 I




♦


♦


^proved foe


* *-—


93 7 +


/

* 93-16589






Special Report
CMU/SEI-93-SR-5
July 1993


Reengineering:
An Engineering Problem


Peter H. Feiler

Software Engineering Techniques PnograrrV
Technology Division


Approved for public release.
Distribution unlimited.


Software Engineering Institute

Carnegie Mellon University
Pittsburgh, Pennsylvania 15213









This technical report was prepared for the


SEI Joint Program Office
ESC/ENS

Hanscom AFB, MA 01731-2116

The ideas and findings in this report should not be construed as an official
DoD position. It is published in the interest of scientific and technical
information exchange.

Review and Approval

This report has been reviewed and is approved for publication.


FOR THE COMMANDER



Thomas R. Miller, Lt Col. USAF
SEI Joint Program Office


The Software Engineering Institute is sponsored by the U S. Department of Defense
This report was funded by the U.S. Department of Defense.

Copyright © 1993 by Carnegie Mellon University.

Thi* document * available trough the Detente Technical Information Center OTIC provides access to and transfer of
scientific and technical information for DoD personnel, DoD contractors and potential contractors, and other U S Government
agency personnel and the* contractor* To obtain a copy, please contact OTIC cfrectly Defense Technical Information
Center, Attn FORA, Cameron Station, Alexandria, VA 22304-6145

Copres of this document are also available Ihrough (he National Technical Information Service For information on ordenng
please contact NTIS directiy National Technical Information Service, U S Department of Commerce, Spnngfield, VA 22161

Cooies of #11$ document are also available from Research Access Inc 800 Vima 1 St-eet P-rtsburqh PA I5?i2 T P i 0 r‘'i-ie

4 ‘" '■'' 'oc, j c' ’ ^ a ‘ 6 S' C ~* * 4 *" “' • x.c.4 ** ^


a ay tr


■ **vV - v •










Table of Contents


1 Executive Summary 1

2 Introduction 3

2.1 Definition 3

2.2 Context 5


3 A Reengineering Framework 7

3.1 The Current System State 8

3.2 The Desired System State 9

3.3 System Understanding 9

3.4 Evolutionary Migration Path 12

3.5 An Engineering Framework 14

4 State of the Practice 17


5 Opportunities for Improvement of Reengineering 19

5.1 Advancement of State of the Art 20

5.2 Advancement of Software Engineering Practice 21

5.2.1 Technology Trends 21

5.2.2 Engineering of Technology 22

5.2.3 Community Consensus Building 24

5.2.4 Transition Infrastructure 25


6 SEI Role in Improving Reengineering Practice

6.1 Ongoing SEI Software Engineering Activities

6.2 Potential SEI Reengineering Activities

7 Conclusion

8 Acknowledgments
References


DT7.


CMU/SEI-93-SR-5


Accesion For


NTIS CRA&I
OTIC TAB
Unannounced
Justification


I


□


By.

Distribution/


Availability Codes


Dist


m


Avail and/or
Special


27

27

29

31

33

35


i






jj


CMU/SEI-93-SR-5








List of Figures


Figure 2-1: Common View of Reengineering 4

Figure 3-1: Reengineering Problem Solving 7

Figure 3-2: Creating System Understanding 10

Figure 3-3: Representing System Understanding 10

Figure 3-4: Engineering Technology Base 12

Figure 3-5: System Evolution 13

Figure 5-1: Software Engineering Technology Maturity 19


CMU/SEI-93-SR-5


hi









Reengineering: An Engineering Problem


Abstract: This paper discusses a plan that addresses how the Software
Engineering Institute (SEI) may assist the Department of Defense (DoD) in
reengineering its large software-intensive systems. This plan is based on a
view of reengineering as an engineering problem to improve the cost-effective
evolution of large software-intensive systems. This view of reengineering,
which takes the whole software engineering process into account, fosters a
growth path by leveraging promising emerging software engineering
technologies. Reengineering also builds on the industry's improvement in its
ability to manage the software engineering process, an accomplishment of SEI
work in the Capability Maturity Model (CMM) and its key process areas.


1 Executive Summary

In the last several years, there has been significant discussion about the legacy of software
systems and reengineering. As a result of this attention, reengineering tools have begun to ap¬
pear. Their focus is primarily on deriving information from code of legacy systems (reverse en¬
gineering), on restructuring and retargeting code, and on mapping derived design information
into a new implementation. In particular, a number of tools exist to migrate information systems
implemented in COBOL to new platforms and to upgrade their data representation into a rela¬
tional form.

While reengineering tools will help in certain aspects of reengineering, reengineering is no
more about tools than engineering is about tools. Just as engineering implies a disciplined pro¬
cess supported by engineering methods and automated tools, reengineering practice requires
a disciplined process supported by methods and tools. In short, reengineering is viewed as an
engineering problem that requires a quantitative analysis of the problem and consideration of
engineering tradeoffs in its solution.

In response to Advanced Research Projects Agency (ARPA) guidance, the SEI proposes to
provide a leadership role in defining and advancing best reengineering practice, taking advan¬
tage of current SEI activities in software engineering technologies and related ARPA activities
such as Domain Specific Software Architecture (DSSA), Software and Technology for Adapt¬
able Reliable Systems (STARS), the Virginia Center of Excellence, as well as Air Force activ¬
ities such as Central Archive for Reusable Defense Software (CARDS) and Software
Technology Support Center (STSC).


CMU/SEI-93-SR-5


1






The SEI proposes the following key activities to support the DoD's reengineering of large soft-
ware-intensive legacy systems:

• Develop a reengineering maturity framework. This framework identifies and
assesses the maturity of software engineering technologies in support of
reengineering and establishes quantitative methods as decision aids in
engineering tradeoff analyses. The technology results of this activity lead to
products such as a guide to best reengineering practice, a reengineering
technology roadmap, and a reengineering improvement strategy that
leverages reuse and domain-specific architectures initiatives.

• Accelerate the evolution of a taxonomy of domains and architectures and its
reduction into reengineering practice. Such a taxonomy is considered
essential for successful evolution of a software technology base and for
effective identification and promotion of dual use software technology.

Domain models and domain-specific architectures allow for more effective
reengineering beyond code-level program transformation.

• Identify and analyze desirable and undesirable system properties, their root
causes, and their effects. These include properties of legacy systems as well
as future systems. A catalog of such system properties is the basis for a
systematic (engineering) approach to effective system understanding of
legacy systems and their evolution strategies. An understanding of these
properties is an essential ingredient in the quantitative methods associated
with the reengineering maturity framework.

• Accelerate the evolution of the design record concept toward practical use.

The design record concept provides a focus for capture, representation, and
visualization of system information and knowledge. The SEI can become a
critical link between innovative technology research as directly sponsored by
ARPA and its reduction into state-of-the-practice technology. The results of
this task directly contribute to the evolution of a codified body of knowledge,
an essential element of any discipline.

The proposed activities will not only accelerate the advancement of reengineering practice,
but also contribute to the advancement of megaprogramming.

The purpose of this paper is to put the proposed activities in context. This is accomplished by

• defining reengineering and its context (Chapter 1),

• discussing a reengineering framework from a problem-solving perspective
(Chapter 2),

• summarizing the state of practice in reengineering (Chapter 3),

• outlining opportunities for improvement of reengineering (Chapter 4), and

• summarizing the activities proposed by the SEI (Chapter 5).


2


CMU/SEI-93-SR-5








2 Introduction


In the last few years, the world has realized that the number of large systems being built from
scratch is rapidly diminishing while the number of legacy systems in use is very high. New sys¬
tem capabilities are created by combining existing systems. At the same time, the context in
which these systems have been built has changed. Changes range from changes in the ap¬
plication environment in which these systems operate (e.g., new sensors) to changes in hard¬
ware and software technologies (e.g., dramatic increases in processor speed and memory,
high-level languages, improved methods). Some of the technologies used when these sys¬
tems were built can hinder the system’s ability to evolve to meet ever-changing demands in a
cost-effective way. As a result of these problems, a number of technology solutions have
sprung up under a variety of labels, including reengineering, reuse, recycling, modernization,
renovation, reconstitution, reverse engineering, design recovery, redocumentation, respecifi¬
cation, redesign, restructuring, and retargeting. For a summary of software reengineering
technology, the reader is referred to [Arnold 93].

2.1 Definition

In this paper we are building on Chikofsky’s work on a taxonomy [Chikofsky 90], the results of
the First Software Reengineering Workshop of the Joint Logistics Commanders Joint Policy
Coordinating Group on Computer Resources Management [Santa Barbara 92], as well as in¬
sights from ARPA sponsored work including STARS, DSSA and from European efforts spon¬
sored under the auspices of ESPRIT, Eureka (Eureka Software Factory), and the Institute for
Systems and Software Technology of the Frauenhofer Geseilschaft [ISST 92].

Definitions for reengineering found in the literature include:

• the examination and alteration of an existing system to reconstitute it into a
new form and the subsequent implementation of the new form;

• the process of adapting an existing system to changes in its environment or
technology without changing its overall functionality;

• modification and possible further development of an existing system;

• improvement of a system through reverse engineering (and restructuring)
followed by forward engineering.

Figure 2-1 illustrates a taxonomy of terms related to reengineering by Chikofsky. In this com¬
monly-accepted taxonomy, software system abstractions are represented in terms of life-cycle
phases. Shown are requirements, design, and implementation. The traditional process of de¬
veloping a system by creating these abstractions is referred to as forward engineering. Re¬
verse engineering is the process of analyzing an existing system; identifying system
components, abstractions, and interrelationships; and creating the respective representations.
Redocumentation and design recovery are two forms of reverse engineering. Redocumenta¬
tion refers to the creation and revision of representations at the same level of abstraction, while


CMU/SE1-93-SR-5


3



design recovery refers to the utilization of external information including domain knowledge in
addition to observations of the existing system to identify meaningful higher levels of abstrac¬
tion. The third process con .ponent of reengineering is restructuring. Restructuring is the trans¬
formation of represent ,uons at the same level of abstraction while preserving the system’s
external behavior.. ,eengineering is an engineering process to reconstitute an existing system
into a new form through a combination of reverse engineering, restructuring, and forward en¬
gineering.



9


Figure 2-1: Common View of Reengineering

Reengineering relates closely to maintenance, which is generally viewed as cons.rting of cor¬
rective, perfective, preventive, and adaptive maintenance. According to ANSI/IEEE Std 729-
1983, software maintenance is the “modification of a software product after delivery to correct
faults, to improve performance or other attributes, or to adapt the product to a changed envi¬
ronment." In this paper we use the term system evolution to include software maintenance.

For the purposes of this paper, we take an encompassing view of reengineering as addressing
the engineering problem of (improving) cost-effective evolution of large software intensive sys¬
tems, both existing and future, through appropriate application of effective best-practice engi¬
neering methods and tools. Evolution of many existing systems is considered as not being
cost-effective and cannot keep pace with changes in the application (domain) environment
and changes in the computing environment and software engineering technology. The term
legacy system has been attached to systems with such characteristics. Changes in the appli¬
cation environment (the external environment the application system operates in) as well as
in the implementation environment (the hardware/software platform) have to be assumed as
a given and have to be accommodated (engineering for change). This need for engineering
for change applies to both existing systems and new (or future) systems.

CMU/SEI93SR-5


4
















2.2 Context


The focus of this paper is on technical aspects of reengineering. However, economic, man¬
agement, and acquisition aspects play as important a role in the successful improvement of
the capability to reengineer legacy systems.

The cost of incremental change to a legacy system needs to be reduced. Criteria for deciding
on the need for reengineering range from heuristics such as age of code and excessive main¬
tenance personnel training cost (as found in a 198'’ NIST document) to parameterized cost
models (see [ISST 92, Santa Barbara 92]). Improvement in this cost is anticipated by investing
more than the minimal amount into reflecting the requested change. The additional investment
would go into improving the way the system has been engineered with the result of smaller
incremental cost in the future. If several legacy systems have to be reengineered, their simi¬
larities can be captured in a common reusable architecture, treating them as a family of sys¬
tems rather than isolated point solutions. The cost models for reengineering, together with
better understanding of the effectiveness of different engineering techniques, will allow soft¬
ware engineers to make reasonable engineering tradeoffs as they choose a particular evolu¬
tionary reengineering strategy for a legacy system.

Engineering effectiveness is influenced by how well an organization is able to manage its en¬
gineering process and improve its engineering capability. SEI has provided leadership for gov¬
ernment and industry to improve these organizational software process capabilities through
work on the Capability Maturity Model (CMM) and its use as an assessment and improvement
tool. In the context of this paper we assume that the reader understands the relevance of such
capabilities for an organization’s ability to systematically, efficiently, and effectively reengineer
legacy systems.

Successful improvement of legacy systems through reengineering also requires attention to
improvements in the acquisition process and to legal concerns. The Joint Logistics Command¬
ers Joint Policy Coordinating Group on Computer Resources Management is holding a work¬
shop series to address acquisition issues at the policy level. For further discussion of these
and other inhibitors to successful transition of improved software engineering practice see the
work done on transition models by SEI and others [Przybylinski 91; Leonard-Barton 88].


CMU/SEI-93-SR-5


5








3 A Reengineering Framework


In this paper we have cast reengineering as an engineering problem. Problem solving involves
an understanding of the problem, i.e., a clear understanding of the root causes in terms of its
existing state, an understanding of the desired state, and a path (plan) to evolve from the cur¬
rent state to the desired state. Figure 3-1 illustrates this. The current state reflects properties
of the existing system and the process by which the system is engineered (developed and
maintained). A subset of those properties is undesirable, reflecting the problem to be solved.
System understanding reflects the process of creating and maintaining an understanding of a
system (through analysis, elicitation, and capture). System evolution represents the engineer¬
ing activity of migrating the existing system to the desired state. Based on an understanding
of the current and desired system state and available (re)engineering technology, an analysis
making engineering tradeoffs by considering technical, management, and economic risks and
constraints results in a (re)engineering plan. During the execution of this plan (i.e., the actual
evolution of the system through engineering activity), the plans may be reassessed taking into
consideration changes in the context (e.g., technical changes such as promising new technol¬
ogies or economic changes such as budget reductions or increases).



CMU/SEI-93-SR-5






3.1 The Current System State

The root causes for the lack of cost-effective evolution fall into two categories: management
of the engineering process and the engineering process itself. Management of the engineering
process is addressed by SEI's work on CMM and will not be elaborated here. The second cat¬
egory represents technology root causes, i.e., the engineering process, methods, and tools. It
will be the focus of further discussion.


The technology root causes manifest themselves in a number of ways. Some examples are:

• Data structures not cleanly implemented. Assumptions that a specific
element of shared memory (e.g., Fortran COMMON) is used as the
communication mechanism.

• System representations such as architectural and design descriptions
reflecting the application domain and the implementation approach may
never have been created or documented; the documentation (and
sometimes even the source code) is out of date.

• Assumptions about the application environment have been hardcoded in the
implementation. Examples include assuming a point solution including fixed
number and types of real-world objects.

• The computing environment evolved through several generations. For
example, early hardware platforms were memory-limited, resulting in a
number of sometimes (in today's view) convoluted implementation “tricks,"
such as overlay, instruction reuse, and cryptic user interaction. No operating
system support was assumed. Today's computing environments typically
consist of COTS standard operating systems, DBMS, window systems, and
networking support, and are geared toward a high degree of interactiveness
and “user-friendliness."

• The implementation technology has evolved from machine code with
absolute addressing; to symbolic assembler, high-level algorithmic
languages (COBOL, FORTRAN, ALGOL); to languages supporting data
abstraction, modularity, information hiding, concurrency support, data
modeling capabilities, etc. Design and implementation methods have been
coming and going, each leaving its trademark in the code of legacy systems.

This code may or may not accommodate the changes demanded from
systems today.

Legacy systems also have a number of properties that are worth preserving. Examples
include:


• Legacy systems are deployed and have undergone the scrutiny of real users
with respect to their functionality meeting their real needs.

• Nonfunctional properties such as performance and accuracy have been fine-
tuned.


e


CMU/SEI-93-SR-5





• Corrective maintenance has resulted in “hardened” code and a wealth of test
and validation capabilities.

• System history exists in the form of original designers, current and past
maintainers, as well as bug report and change order records.

In many cases some of the root causes and their implications may be understood by some
experts, but are not documented and available to the majority of software engineers. Informa¬
tion about systems is quite limited, usually to the source code and/or executable, an opera¬
tions manual, and people maintaining the system.

3.2 The Desired System State

The desired system state is a combination of properties of the existing system to be main¬
tained, properties expected of a system as part of state-of-the-art software engineering prac¬
tice and implementation technology, and properties that have their roots in changing
environments and are reflected in the system history, but may not have been explicitly ex¬
pressed by the system user. Examples of maintained properties are functionality, perfor¬
mance, and accuracy. Examples of properties resulting from best practice software
engineering and implementation technology include portability, modularity, structure, readabil¬
ity, testability, data independence, documented system understanding, openness (open sys¬
tem), interoperability, and seamless integration. Properties that address continuous change
and provide flexibility include localization of information regarding certain different types of
change in both the application domain and the implementation, introduction of virtual machine
abstractions, and parameterization (dynamic as well as generation technology), COTS, and
reuse of components. Properties that encourage reuse of existing engineering know-how in¬
clude the existence of domain models, domain-independent software architectural principles,
domain-specific architectures, and adaptable components.

The desired system state may be known to system users, system maintainers, original system
builders, and best software engineering practice experts. The customer (user) may not neces¬
sarily be aware of all the potentially desired properties and may only be willing and able to in¬
vest in some. Some desired properties can be provided with proven technology, while others
depend on emerging technology whose maturity for practical application has not been dem¬
onstrated.

3.3 System Understanding

The current state of an existing system and its desired state represent an understanding of the
system. This understanding is based on artifacts of the existing system; knowledge and expe¬
rience with the system as it may exist in users', maintainers', and original builders' heads; and
documented system history in the form of bug reports and change records. Figure 3-2 illus¬
trates the sources of information for system understanding. The artifacts are source code,
manuals, and the executing system. The knowledge and experience with the system include
understanding of engineering decisions, rationale, and possible or considered alternatives, as


CMU/SEI-93-SR-5


9






well as undocumented history and (typically nonfunctional) properties such as performance,
robustness, work-arounds, etc. History provides insight into robustness of system compo¬
nents, types, and frequency of changes in the environment (and implementation).



Capture, representation, currency, and accessibility of this system understanding is a big chal¬
lenge. Figure 3-3 illustrates a framework for representation of such system understanding. A
central component of system understanding is the system design records that document sys¬
tem representations at different levels of abstraction. This is complemented with rationale for
design decisions, the software engineering process and methods used, and the evolution his¬
tory. Let us first elaborate on models of (software) systems.



10


CMU/SEI-93-SR-5




















These representations are models of the system. Models reflect views of the system focusing
on certain aspects with different degrees of detail. The purpose of a model is to present a view
that is understandable, i.e., not too complex. This is accomplished by the model capturing
those abstractions that are relevant from a particular perspective. Some models focus on ar¬
chitectural issues while other models focus on data representation, behavioral, reliability and
performance aspects of a system. Examples of models are domain models, domain-specific
architectures, real-time timing models such as rate monotonic analysis (RMA), performance
models based on queuing theory, etc.

Models have different degrees of formality and may have the ability to be executed. The mod¬
els may reflect designs (i.e., the notation they are expressed in needs to be transformed into
executable implementations), or they may be executable and capture all the desired user func¬
tionality and can act as prototype implementations, which can be made more robust or efficient
through reimplementation (i.e., transformation into a modeling notation that more appropriate¬
ly satisfies the need).

As more than one system is considered, models can show their similarities and differences.
Systems can be grouped into families. Some models focus on information about the applica¬
tion domain (domain models) while others focus on the implementation architecture. Domain
models and domain-independent architectural modeling principles are combined to create do¬
main-specific architectures. Those architectures are populated with components and adapt¬
ed to the particular application needs. The result is a technology base of models that can be
(re)used for a number of systems, leveraging existing engineering know-how. Domain analy¬
sis and architectural analysis contribute to the population of this technology base, while appli¬
cation engineering can get adapted to utilizing these models (see Figure 3-4). Furthermore,
the technology base can be expanded by the emergence of new modeling concepts, e.g.,
safety modeling.

While some models represent the executing system itself, other models reflect constraints the
system must satisfy. Those are models used to validate desired system behavior. Examples
of such models are assertions validated in design reviews or verification, or translated into test
suites and test data validating the behavior of the running system. When reengineering a leg¬
acy system, such test and validation models exist and have stood the test of time. They can
be leveraged for verification and validation of the desired system. Depending on the particular
migration path to the desired system, alternatives to full regression testing may be considered.
One example is validation of functional equivalence at a certain level of abstraction through
comparison of event traces [Britcher 90].

Engineering decisions, rationale, and alternatives complement these models. They may be
captured through elicitation processes such as IBIS [Microcomputer Corporation (MCC)]. The
models together with the engineering knowledge are known in other engineering disciplines
as experience modules.


CMU/SEI-93-SR-5


11







In this idealized view, the amount of engineering information available to the engineer grows
tremendously, resulting in information overload. In order to cope with this situation an intelli¬
gent intermediary (intelligent engineering assistant or engineering associate) will become es¬
sential to the successful utilization of the system understanding. Technologies that are
potential contributors to this notion of intelligent assistant include case-based reasoning and
intelligent tutoring.

3.4 Evolutionary Migration Path

The understanding of the system, both the current and the desired system state, is the tech¬
nical basis for determining the particular reengineering strategy to be chosen. It requires anal¬
ysis, considering alternatives, and making engineering tradeoffs. Such a technical engineering
analysis consists of two major components: choosing the degree of legacy leverage, i.e., what
can be taken over and what has to be newly created; and choosing the approach for migrating
over to the desired system, i.e., how to introduce the changes into the system. The reengineer¬
ing case study by Britcher [Britcher 90] nicely illustrates that no single approach is appropriate,
but engineering tradeoffs need to be considered.


12


CMU/SEI-93-SR-5


















Legacy leverage refers to the ability to utilize (recycle) as much as possible of the existing sys¬
tem in the process of evolving to the desired system. Both the existing and the desired system
can be described in terms of a collection of models. For the legacy system, code exists. Other
models may have to be derived from the code or other information sources. Certain abstrac¬
tion may not exist in the legacy system or may reflect undesirable properties. The goal is to
eliminate undesirable properties while at the same time introduce desirable properties. Choic¬
es have to be made as to which legacy system models to ignore, which ones to transform, and
which ones to leave intact. This is illustrated in Figure 3-5. The choices are driven by our un¬
derstanding of the legacy and desired system properties as well as their reflection in the dif¬
ferent models. In concrete terms this means that in some cases, undesirable properties of
legacy systems can be eliminated by massaging the code or transforming the data represen¬
tation, while in other cases a new architecture or data model has to be developed and only a
few system components can be translated into the new implementation language.




Architecture



Design



Figure 3-5: System Evolution


The change can be introduced in a number of ways. The following are three classic approach¬
es, but hybrid approaches are possible:

• Big Bang Approach: The desired system may be built separately from the
legacy system, although parts of the legacy system may have been recycled.

Once completed the new system is put into operation while the old system is
shut down.


CMU/SEI-93-SR-5


13









• Phase-out Approach, also known as Incremental Development: The

architecture of the desired system may be created and a skeleton
implementation developed. A mapping between the data representation of
the legacy and the desired system, implemented as a two-way
transformation filter allows the skeleton desired system to run as a shadow
of the “live” legacy system, while parts of the desired system implementation
are completed and incrementally added to the skeleton. This approach
incrementally phases out pieces of the legacy system.

• Phase-in Approach, also referred to as Evolutionary Development: The

legacy system code may be restructured to introduce modularity and
partitioning. Desired system properties are incrementally introduced into the
existing system resulting in an incremental evolution of both the architecture
and the system components.

Validation of the desired system can utilize existing testing capabilities. Validation can be de¬
composed into validating that the desired system still provides equivalent functionality and de¬
tection of bugs in the reimplementation.

The choice of the particular reengineering strategy is affected by the risks the alternative ap¬
proaches. Risks to consider are:

• Perceived and actual undesirable and desirable system properties

• Ability to eliminate or reduce undesirable system properties

• Maturity of technology inserted into the system

• Introduction of new technology to system maintainers (reengineers)

• Impact of introduction of the reengineered system

• Impact of system changes on performance and robustness

• Cost and time of reengineering

In summary, reengineering is an engineering activity that involves system understanding and
evolution through application of appropriate engineering practices. The framework outlined
here does not promote particular techniques but accommodates emerging technologies as
they mature.


3.5 An Engineering Framework

The framework presented above in the context of reengineering can be used as an engineer¬
ing framework for software intensive systems. A full discussion of this point is beyond the
scope of this paper. The following characterization of different software engineering processes
and paradigms serves to quickly illustrate the validity of this claim:

• New system development: The system to be improved in the application
environment may be a system performing without computer support. This
legacy system has desirable properties to be maintained and undesirable
properties to be overcome. For example, for many information systems the
data model of the legacy system, though not documented, may be directly
applicable to the desired system. In traditional life-cycle terminology this is


14


CMU/SEI-93-SR-5




referred to as the requirements phase. Software recycle is applicable only if
parts of *he legacy system are computer-based. For the introduction of the
new system the same migration alternatives may be considered as
discussed in the context of reengineering.

• Reengineering of future systems: Change in the application environment
and the implementation environment are givens. When a new system is
being defined, customers often focus on the functionality needed to address
their particular problem at that time. Many of the types of changes that will
occur over the lifetime of the system and their implications on desirable
system properties are not considered during requirement definition.
Reengineering of future systems implies that engineering for change and up-
to-date maintenance of a system understanding (system design records)
occurs from the outset. Engineering for change requires an understanding of
commonly-accepted changes as well as an anticipation of paradigm shifts
due to new technology and localization of assumptions about certain
environment constants.

• Open systems: The open systems concept has gained momentum over the
last few years, as reflected in organizations such as X-Open, Open Systems
Foundation (OSF), and the User Alliance for Open Systems. This concept
permits interoperability, allows rapid technology insertion and upgrade,
encourages alternative solutions to be applicable, and provides one
solution applicable in a number of systems. Characteristics of open systems
are modularity and standard interfaces. These are desirable properties of
both legacy and future systems as they reduce system cost.

• Reuse: Reuse is an engineering activity that focuses on the recognition of
commonalities of systems within and across domains. It consists of the
creation of models with different abstractions (ranging from code
components to domain models) and their use during the engineering of an
application. Thus, the focus is on the growth and utilization of the technology
base.

• Evolutionary development: Evolutionary development focuses on
designing the architecture of a system in such a way that the capabilities
offered to the user can grow incrementally. New capabilities may be
introduced through prototyping of new system components (possibly utilizing
different implementation technology). Such prototypes interoperate with the
operational system and may get hardened through incremental
reengineering.

• Megaprogramming: Megaprogramming focuses on recognition of system
commonalities at high levels of abstraction (e.g., architecture) and creation
of system instances through parameterized automatic composition or
generation.

• Model-Based Software Engineering (MBSE): The objective of MBSE is to
improve the effectiveness and efficiency of producing software intensive
systems through better utilization of engineering experience and system
understanding. MBSE focuses on the use of engineering product models as
the primary means for improving the construction and maintenance of
software.


CMU/SEI-93-SR-5


15








4 State of the Practice


In many cases an organization with legacy system problems has a low level of maturity, i.e.,
has an ad hoc management process as well as an ad hoc engineering process and is in search
of the silver bullet in the form of the right reengineering tool. Much of the focus of reengineering
technology has been on tools. Availability of tools has been market driven. A majority of tools
attempt to satisfy the needs of the MIS community. This community has a vast number of leg¬
acy systems and the dominating implementation language is COBOL.

Summaries of reverse and reengineering markets and technologies are documented in re¬
ports such as [R-EvHa 90]. Categorizations of reengineering tools can be found in [IEEE 90]
and [lEEENews], as well as organizations categorizing tools such as Air Force Software Tech¬
nology Support Center (AF STSC).

Reverse engineering (redocumentation) tools range from code formatters and cross-reference
generators to data flow and call graph generators. Analysis tools examine data structures,
identify unreachable code, and check for compatibility with language variants, e.g., compati¬
bility with different C compilers. Other types of analysis tools focus on providing statistical
measures of “goodness” of code, e.g., McCabe metrics.

Restructuring tools are available for code translation, mostly for translation between different
variants of COBOL, but also for translation between languages. Another form of restructuring
supported by tools is data restructuring between representations, e.g., from a hierarchical to
a relational representation.

In a 1983 document NIST has provided criteria for deciding on the need for reengineering.
Such criteria range from age of code (greater than 7 years) to programs being emulated and
training cost of maintenance personnel being too high. More elaborate decision aids involve
economic cost models. The draft DoD Reengineering Economics Handbook is one example
of such tools.

The SEI has developed a curriculum module on maintenance/reengineering as part of the
Master of Software Engineering (MSE) curriculum development. This curriculum module re¬
flects current practice and is being used in MSE programs at universities as well as in continu¬
ing education programs. Furthermore, there are a number of commercial offerings of
reengineering courses and seminars, as well as practitioner conferences on the topic.

A number of other technologies contribute to the practice of reengineering, but are sometimes
not discussed in that context. Examples include:

• Rate Monotonic Analysis (RMA) as a real-time performance analysis
technique. The SEI has been instrumental in turning the underlying theory
into practical application.


CMU/SEI-93-SR-5


17





• Use of structural modeling and resulting models in the flight simulation
community. The SEI has been instrumental in moving that community from
Fortran and 60s programming techniques to Ada and modem software
engineering practices.

• Component reuse through component libraries. Libraries for generic
components (e.g., stacks and queues), as well as for special application
domains (e.g., numerical algebra algorithms or missile guidance software
(CAMP)) exist. In some areas generation technology (e.g., parsers) toolkit
technology (DBMS and UIMS), and higher level languages (e.g., 4GL, SQL)
have evolved and been put into practice.

• Quality of the system is improved through engineering process approaches
such as the cleanroom method and design or code inspections. Other key
process areas (KPA) as outlined in the CMM such as configuration
management (CM) can also greatly impact an organization’s ability to keep
legacy systems up-to-date.

The SEI has projects in several other technical areas actively engaged in impacting practice
(e.g., Ada adoption, domain analysis and reuse, software architectures, process definition, CM
system concepts, environment integration and adoption, fault tolerance, Ada/SQL, risk as¬
sessment and mitigation). These complement the SEI activities surrounding the CMM, orga¬
nizational change, transition management, and software engineering education.


18


CMU/SEI-93-SR-5







5 Opportunities for Improvement of Reengineering


Improvement of reengineering practice has a number of facets. As pointed out earlier, this pa¬
per focuses on the technical aspects of reengineering and its advancement. The technical as¬
pect can be subdivided into advancement of state-of-the-art of reengineering technology and
advancement of reengineering practice. The first focuses on innovative research resulting in
the creation of new technological solution with potential for practical use. The second focuses
on reduction of promising technologies into engineering practices by creating awareness and
understanding, by reducing risk through trial use, and by improving practitioners through im¬
provement and training programs. As part of its transition roie the SEI focuses on advancing
best practice (including assessment of advances of state-of-the-art) and on facilitating the ad¬
vancement of common practice.

Advancement in reengineering practice is measurably accomplished through improvement in
the software process as outlined in the CMM, i.e., the management of software engineering,
whose key practice areas are spread across the five CMM levels, and a placeholder for soft¬
ware development processes at level 3. In short, the CMM represents a Process Maturity
Scale (PMS). Actual engineering of software is driven by a second scale that reflects increas¬
ing sophistication of software technology and its methodical (systematic) application. In this
paper we refer to this scale as the Software Engineering Technology Maturity Scale (TMS).
Figure 5-1 illustrates this scale in five units


1

2

3

4

5

Ad hoc

Repeatable

Defined

Evaluating

Optimizing

informal

Common

artifacts

Domain spec,
architectures
Generators

Formal

Quantitative

Cause/effect

Technology

tradeoff


Figure 5-1: Software Engir*eering Technology Maturity


Progression through the units of this scale reflects:

• increasing levels of abstraction,

• increasing degree of formalism with theoretical foundation,

• increasing automation, and

• increasing optimization.

Lire la suite

• Taille
  1.91 MB
• Nombre de pages
  15