0% found this document useful (0 votes)
6 views

Chap6 - Software Engineering

Uploaded by

tekia tekle
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views

Chap6 - Software Engineering

Uploaded by

tekia tekle
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 25

CHAPTER SIX

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

• corrective maintenance: correcting errors

• adaptive maintenance: adapting to changes in the


environment (both hardware and software)

• perfective maintenance: adapting to changing user


requirements

• preventive maintenance: increasing the system’s


maintainability
Key to maintenance is the development

• Higher quality  less (corrective) maintenance

• Anticipating changes  less (adaptive and


perfective) maintenance

• Better tuning to user needs  less (perfective)


maintenance

• Less code  less maintenance


Shift in type of maintenance over time
• Introductory stage: emphasis on user support
• Growth stage: emphasis on correcting faults
• Maturity: emphasis on enhancements
• Decline: emphasis on technology changes

Major causes of maintenance problems

• Unstructured code

• Insufficient domain knowledge

• 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

• Standards and guidelines: various types of standards and


guidelines can be developed to enhance the maintainability of
software

• like users manual etc will contribute to the


understandability and hence maintainability of the software6
Managerial Aspects of Software Maintenance
• Successful software maintenance, like all software
engineering activities, requires a combination of
managerial skills and technical expertise
• One of the most important aspects of software
maintenance involves tracking and control of maintenance
activities
• Maintenance activity for a software product usually occurs
in response to a change request filed by a user of the
product
• A change request is first reviewed by an analyst, either
closes the change request or submits to the control board
• The control board reviews and approves all change
requests
Configuration Management

• is concerned with tracking and controlling of the


work products that constitute a software product.
• Software tools to support configuration management
include configuration management data base and
version control
• A configuration management data base can provide
information concerning product structure, current
revision number, current status and change request
history for each product version.
Source-Code Metrics
• A software metric is a measure of some property of a
piece of software or its specifications.
• Most of the metrics incorporate easily computed
properties of the source code, such as the number of
operators and operands, the complexity of the control
flow graph, the number of parameters and global
variables in routines and the number of levels and
manner of interconnection of call graph.
• The approaches taken to compute a number or set of
numbers that measures the complexity of the code.
• Thus a program with measure 10 would be more
complex than a program with measure 5.
The maintenance process
• Maintenance is triggered by change requests from
customers or marketing requirements
• Changes are normally batched and implemented in a
new release of the system
• Programs sometimes need to be repaired without a
complete process iteration but this is dangerous as it
leads to documentation and programs getting out of
step

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

Program Modularised Original data


Original
documentation program
program

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

Automated source Automated r estructuring Restructuring plus


code conversion with manual changes architectural changes

Increased cost
Source code translation

• Involves converting the code from one language (or


language version) to another e.g. FORTRAN to C
• May be necessary because of:
– Hardware platform update
– Staff skill shortages
– Organisational policy changes
• Only realistic if an automatic translator is available
The program translation process

System to be System to be Re-engineered


re-engineered re-engineered system

Identify source Design translator Automatically Manually


code differences instructions translate code translate code
Reverse engineering
• Analysing software with a view to understanding its
design and specification
• May be part of a re-engineering process but may also
be used to re-specify a system for re-implementation
• Builds a program data base and generates information
from this
• Program understanding tools (browsers, cross-
reference generators, etc.) may be used in this process
The reverse engineering process

Program stucture
Automated diagrams
analysis
System
System to be Document Data stucture
information
re-engineered generation diagrams
store
Manual
annotation Traceability
matrices
Reverse engineering

• Reverse engineering often precedes re-engineering


but is sometimes worthwhile in its own right
– The design and specification of a system may be
reverse engineered so that they can be an input to
the requirements specification process for the
system’s replacement
– The design and specification may be reverse
engineered to support program maintenance
Data re-engineering

• Involves analysing and reorganising the data


structures (and sometimes the data values) in a
program
• May be part of the process of migrating from a file-
based system to a DBMS-based system or changing
from one DBMS to another
• Objective is to create a managed data environment
Approaches to data re-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

• Data re-engineering may involve changing the data


structure organisation without changing the data
values

• Data value conversion is very expensive. Special-


purpose programs have to be written to carry out the
conversion
The data re-engineering process

Program to be re-engineered Data


analysis

Entity name Data


modification re-formatting
Data Literal Default value Data
analysis replacement conversion conversion
Data definition Validation rule
re-ordering modification

Stage 1 Stage 2 Stage 3

Change summary tables Modified


data

You might also like