SOFTWARE ENGINEERING TECHNIQUES

LESSON 21:

Topics Covered shown in figure. Rather than start with a written specification,
Software re-engineering, Source code translation, Program the old system acts as a specification for the new system.
restructuring, Software Configuration management, Configura-
tion management activities, Software versions, Version Control,
Change control Process
Objectives
Upon completion of this Lesson, you should be able to:
• Know what is Software re-engineering
• Know what is source code translation and program
restructuring
• Know what is software configuration management and the
various configuration management activities
• Know what is a software version and the change control
process.
Software Re-engineering
Systems that have been in the field for a long time evolve and
mutate in ways that were never planned. As enhancements are
added, bugs fixed, and piece-meal solutions tacked on, the once
elegant system grows into something unmanageable and
expensive to maintain.
These old systems that must still be maintained are sometimes
The costs of re-engineering depend on the extent of the work
called legacy systems. These legacy systems may have been the
that is carried out. Other factors affecting costs are; the quality of
best that technology had to offer. But, as mission requirements
the software, tool support available, extent of data conversion,
change and better technology becomes available, the users are
availability of expert staff.
faced with the difficult problem of reconciling the large
investments they have already made in their existing systems The alternative to re-engineering a software system is to
against the promise of better designs, lower cost of mainte- redevelop that system using modern software engineering
nance, cheaper technology and large improvements in techniques. Where systems are very badly structured this may be
capabilities. Most of the legacy systems may be poorly struc- the only viable option as the reengineering costs for these
tured and their documentation may be either out of date or systems are likely to be high.
non-existent. The developers of these systems having left the The following suggestions may be useful for the modification
organization, there may be no one in the organization who of the legacy code:
really understands these systems in detail. These systems were • Study code well before attempting changes.
also not designed for change. Another problem is the non-
• Concentrate on overall control flow not coding.
availability of requirements, design and test cases.
• Heavily comment internal code.
Software re-engineering is concerned with taking existing legacy
systems and re-implementing them to make them more • Create Cross References
maintainable. As a part of this re-engineering process, the • Build Symbol tables
system may be redocumented or restructured. It may be • Use own variables, constants and declarations to localize
translated to a more modern programming language, imple- the effect of change.
mented on existing hardware technology. Thus, software
• Keep detailed maintenance document.
re-engineering allows us to translate source code to a new
language, restructure our old code, migrate to a new platform • Use modern design techniques.
(such as client server), capture and then graphically display Source Code Translation
design information, and redocument poorly documented Simplest method is to translate source code to another pro-
systems. gramming language. The target language may be an updated
The critical distinction between re-engineering and new software version of the original language (Basic to Visual Basic) or may
development is the starting point for the development as be a completely different language (FORTRAN to JAVA).

© Copy Right: Rai University

76 3E.253
Source level translation may be required for the following ii. Efficiency driven restructuring: This involves restructuring.

SOFTWARE ENGINEERING TECHNIQUES

reasons [SOMMOO]: A function or algorithm to make it more efficient. A
i. Hardware platform update: The organization may wish to simple example is the replacement ‘of an IF-THEN-
change its standard hardware platform. Compilers for the ELSEIF-ELSE construct with a CASE construct as shown
original language may not be available on the new in figure 8.9. With the CASE statement, only one Boolean
platform. variable is evaluated, whereas with the IF- THEN-ELSEIF-
ii. Staff Skill Shortages: There may be lack of trained ELSE construct, more than one of the Boolean
maintenance staff for the original language. This is a expressions may need to be tested during execution thereby
particular problem where programs were written in some making it less efficient.
non-standard language that has now gone out of general Restructuring a Program
use. (Hi) Adaption-driven restructuring: This involves changing the
iii. Organizational policy changes: An organization may decide coding style in order to adapt the program to a new program-
to standardize on a particular language to minimize its ming language or new operating environment, for instance
support software costs. Maintaining many versions of old changing an imperative program in PASCAL into a functional
compilers can be very expensive. program in LISP. Another example is the transformation of a
Translation can be done either manually or using an automation program functions in a sequential environment to an equivalent
tool. but totally different form of processing in a parallel environ-
ment.
One of the most sophisticated tools available to assist this
process is the REFINE system [MARK94] that incorporates Exercises
powerful pattern matching and program transformation 1. What is re-engineering? Differentiate between re-
capabilities. It is therefore possible to define patterns in the engineering and new development
source code, which should be converted, REFINE recognizes 2. Discuss the suggestions that may be useful for the
these and replaces them with the new constructs, although, modification of the legacy code.
manual intervention is almost always required to tune &
3. Explain various types of restructuring techniques. How
improve the general system.
does restructuring help in maintaining a program?
IF Score> = 75 THEN Grade: = 'A' ELSEIF 4. Explain why single-entry, single-exit modules make testing
Score> = 60 THEN Grade: = 'S' ELSEIF easier during maintenance
Score> = 50 THEN Grade: = 'C' ELSEIF
Score> = 40 THEN Grade: = '0' ELSE Configuration Management
Grade = 'F' The software may be considered as configurations of software
END components. These software components are released in the
form of executable code whereas supplier organization keeps
the source code. This source code is the representation of an
CASE Score of executable equivalent, but which one? Source Code can be
75, 100: Grade: = 'A' 60, modified without there being any effect upon executable
74: Grade: = 'S'; 50, 59: versions in use and, if strict controls are not kept, the source
Grade: = 'C'; 40, 49: code which is the exact representation of a particular executable
Grade: = '0'; ELSE
Grade: = 'F' END version may no longer exist. The means by which the process
of software development & maintenance is controlled is called
configuration management. The configuration management is
Program Restructuring different in development maintenance phase of life cycle due to
This involves transforming a system from one representational different environments. Software maintenance is undertaken in
form to another without a change in the semantics or function- the environment of a live system in use by a probably large user
ality. The transformation would usually be to a more desirable base. Potential effects upon a live system are much more
format. immediate than those upon a system still under development.
Due to maintenance activities, the programs become complex This, configuration management is concerned with the develop-
and difficult to understand. To control this increase in complex- ment of procedures and standards for cost effective managing
ity, the source code needs to be restructured. There are various and controlling charges in an evolving software system.
types of restructuring techniques & some are discussed below: Configuration Management Activities
i. Control flow driven restructuring: This involves the The activities are divided into four broad categories [T AKA96].
imposition of a clear control structure within the source 1. The identification of the components and changes.
code and can be either inter modular or intra-modular in
2. The control of the way by which the changes are made.
nature. This makes the program more readable and easier
to understand. However, the program may still suffer from 3. Auditing the changes.
a lack of modularity whereby related components of the 4. Status accounting-recording and documenting all the
program may be dispersed through the code. activities that has taken place.

© Copy Right: Rai University

3E.253 77
 The following documents are required for these activities: The changed software is handed over to the software configura-
SOFTWARE ENGINEERING TECHNIQUES

• Project Plan tion team and is incorporated in a new version of the system
• Software requirements specification document
• Software Design specification document
• Source Code listing
• Test plans/procedures/test cases
User Manuals
All components of the system’s configuration are recorded
along with all relationships and dependencies between them.
Any change-addition, deletion or modification-must be
recorded and its effect upon the rest of the system’s compo-
nents should be checked. After a change has been made, a new
configuration is recorded. There is a need to know who is
responsible for every procedure and process along the way and it
is a management task both to assign these responsibilities and
to conduct audits to see that they-are carried out.
Software Versions
During software maintenance, there will be at least two
versions of the software system; the old version and the new
version (s). Since a software system is comprised of software
components, there will also be two or more versions of each
component that has been changed. Thus, the software mainte-
nance team has to cope with multiple versions of the software.
We can distinguish between two types of versions namely
revisions (replace) and variations (variety).
Version Control
During the process of software evolution, many objects are
produced, for example files, electronic documents, paper
documents, source code, executable code and bitmap graphics.
A version control tool is the first stage towards being able to
manage multiple versions. Once it is in place, a detailed record Notes
of every version of the software must be kept. This comprises
the
• Name of each source code component, including the
variations & revisions,
• The versions of the various compilers and linkers used,
• The name of the software staff who constructed the
component, The date and the time at which it was
constructed.
Change Control Process
It will be appropriate if changes to software can be predicted.
Change control process comes into effect when the software and
associated documentation are delivered to configuration
management change request form (as shown in figure 8.10),
which should record the recommendations regarding the
change. The recommendations may include assessment of the
proposed change, the estimated costs and how the change
should be implemented. This form is submitted to a Change
Control Authority (CCA), which decides whether or not the
change is to be accepted. If change is approved by the CCA, it is
applied to the software. The revised software is revalidated by
the Software Quality Assurance (SQA) team to ensure that the
change has not adversely affected other parts of the software.

© Copy Right: Rai University

78 3E.253