Chap6 - Software Engineering
Chap6 - Software Engineering
Software Maintenance
&
Reengineering
Software Maintenance
• The process of modifying a software system or component
after delivery; to correct faults, improve performance or
other attributes, or adapt to a changed environment
• Thus it is concerned with
correcting errors found after the software has been
delivered
adapting the software to changing requirements,
changing environments, …
Modifying a program after it has been put into use
Kinds of maintenance activities
• Unstructured code
• Insufficient document
Enhancing Maintainability
• Many activities during software development enhance the
maintainability of software product.
Analysis activities
Standards and guidelines
Design activities
Implementation activities
Supporting documents
10
Software Re-engineering
• Reorganising and modifying existing software systems
to make them more maintainable
• Re-structuring or re-writing part or all of a legacy system
without changing its functionality
• Applicable where some but not all sub-systems of a
larger system require frequent maintenance
• Re-engineering involves adding effort to make them
easier to maintain. The system may be re-structured and
re-documented
When to re-engineer
• When system changes are mostly confined to part of the
system then re-engineer that part
• When hardware or software support becomes obsolete
• When tools to support re-structuring are available
Re-engineering advantages
• Reduced risk
– There is a high risk in new software development. There
may be development problems, staffing problems and
specification problems
• Reduced cost
– The cost of re-engineering is often significantly less than
the costs of developing new software
The re-engineering process
Reverse
engineering
Data
Source code Program reengineering
translation modularisation
Program
structure
improvement
Structured Reengineered
program data
Re-engineering cost factors
• The quality of the software to be re-engineered
• The tool support available for re-engineering
• The extent of the data conversion which is required
• The availability of expert staff for re-engineering
Re-engineering approaches
Automated progr am Program and data
restructuring restructuring
Increased cost
Source code translation
Program stucture
Automated diagrams
analysis
System
System to be Document Data stucture
information
re-engineered generation diagrams
store
Manual
annotation Traceability
matrices
Reverse engineering
Approach Description
Data cleanup The data records and values are analysed to improve their quality.
Duplicates are removed, redundant information is deleted and a consistent
format applied to all records. This should not normally require any
associated program changes.
Data extension In this case, the data and associated programs are re-engineered to remove
limits on the data processing. This may require changes to programs to
increase field lengths, modify upper limits on the tables, etc. The data itself
may then have to be rewritten and cleaned up to reflect the program
changes.
Data migration In this case, data is moved into the control of a modern database
management system. The data may be stored in separate files or may be
managed by an older type of DBMS.
Data problems
• Data naming problems
– Names may be hard to understand. The same data
may have different names in different programs
• Field length problems
– The same item may be assigned different lengths
in different programs
• Record organisation problems
– Records representing the same entity may be
organised differently in different programs
• Hard-coded literals
• No data dictionary
Data value inconsistencies
Data inconsistency Description
Inconsistent default Different programs assign different default values to the same logical data
values items. This causes problems for programs other than those that created the
data. The problem is compounded when missing values are assigned a
default value that is valid. The missing data cannot then be discovered.
Inconsistent units The same information is represented in different units in different
programs. For example, in the US or the UK, weight data may be
represented in pounds in older programs but in kilograms in more recent
systems. A major problem of this type has arisen in Europe with the
introduction of a single European currency. Legacy systems have been
written to deal with national currency units and data has to be converted to
euros.
Inconsistent validation Different programs apply different data validation rules. Data written by
rules one program may be rejected by another. This is a particular problem for
archival data which may not have been updated in line with changes to
data validation rules.
Inconsistent Programs assume some meaning in the way items are represented. For
representation example, some programs may assume that upper-case text means an
semantics address. Programs may use different conventions and may therefore reject
data which is semantically valid.
Inconsistent handling Some programs reject negative values for entities which must always be
of negative values positive. Others, however, may accept these as negative values or fail to
recognise them as negative and convert them to a positive value.
Data conversion