Escolar Documentos
Profissional Documentos
Cultura Documentos
HEX GROUP
“The Inevitable”
SOFTWARE EVOLUTION
Motivation for studying software evolution
Motivation for studying software evolution
3
Motivation for studying software evolution
4
Motivation for studying software evolution
5
Motivation for studying software evolution
6
OBJECTIVES
To explain why change is inevitable if software systems are to remain useful
7
SOFTWARE CHANGE
Software change is inevitable
A key problem for organisations is implementing and managing change to their existing
software systems.
8
IMPORTANCE OF SOFTWARE EVOLUTION
Organizations have huge investments in their software systems - they are critical
business assets.
To maintain the value of these assets to the business, they must be changed and
updated.
9
THE SPIRAL MODEL OF EVOLUTION
10
PROGRAM EVOLUTION DYNAMICS
Program evolution dynamics is the study of the processes of system change.
After major empirical studies, Lehman and Belady proposed that there were a
number of ʻlawsʼ which applied to all systems as they evolved.
There are sensible observations rather than laws. They are applicable to large
systems developed by large organisations. Perhaps less applicable in other cases.
11
LEHMAN’S LAWS
Continuing change
A program that is used in a real-world environment necessarily must change or become
progressively less useful in that environment.
Increasing complexity
As an evolving program changes, its structure tends to become more complex. Extra resources
must be devoted to preserving and simplifying the structure.
12
LEHMAN’S LAWS
Organisational stability
Over a program’s lifetime, its rate of development is approximately constant and independent of the
resources devoted to system development.
Conservation of familiarity
Over the lifetime of a system the incremental change in each release is approximately constant.
Continuing growth
The functionality offered by systems has to continually increase to maintain user satisfaction.
13
LEHMAN’S LAWS
Declining quality
The quality of systems will appear to be declining unless they are adapted to changes in their
operational environment.
Feedback system
Evolution processes incorporate multi-agent, multi-loop feedback systems and you have to
treat them as feedback systems to achieve significant product improvement.
14
LEHMAN’S SYSTEM TYPES
S-SYSTEM: static
The type of software evolution which works exactly according to the requirements and
specification, the chances of getting changes are very little.
Example a calculator
P-SYSTEM: practical
requirements based on approximate solution to a problem, but real-world remains stable.
15
LEHMAN’S SYSTEM TYPES
E-SYSTEM: embedded
The type of software evolution which works on real world problems and changes
as the world changes.
1
6
APPLICABILITY OF LEHMAN’S LAWS
Small organisations;
1
7
SOFTWARE CHANGE STRATEGIES
Software maintenance
Changes are made in response to changed requirements but the
fundamental software structure is stable
Architectural transformation
The architecture of the system is modified
Generally from a centralised to a distributed architecture
Software re-engineering
No new functionality is added to the system but it is restructured and
reorganised to facilitate future changes
These strategies may be applied separately or together
1
8
SOFTWARE MAINTAINANCE
Modifying a program after it has been put into use
Maintenance does not normally involve major changes to
the system’s architecture
Changes are implemented by modifying existing
components and adding new components to the system
1
9
MAINTAINANCE IS INEVITABLE
The system requirements are likely to change while the system is being
developed because the environment is changing. Therefore a delivered
system won't meet its requirements!
Systems are tightly coupled with their environment. When a system is
installed in an environment it changes that environment and therefore
changes the system requirements.
Systems MUST be maintained therefore if they are to remain useful in
an environment.
2
0
TYPES OF MAINTAINANCE
2
1
ISO/IEC 14764 - maintenance types
•. Corrective
• Maintenance to repair software faults Fault repair
(17%)
• Adaptive
• Maintenance to adapt software to a Software
Functionality
addition or
different operating environment adaptation modification
(18%) (65%)
• Perfective
• Maintenance to add to or modify the
system’s functionality
23
SYSTEM EVOLUTION VS DECLINE (case study)
Consider the case of Nokia and the Symbian OS
Symbian is a discontinued mobile operating system (OS) and computing
platform designed for smartphones.
As a pioneer that established the smartphone industry, it was the most popular
smartphone OS on a worldwide average until the end of 2010.
The Symbian Foundation disintegrated in late 2010 and Nokia took back control of
the OS development.
In February 2011, Nokia, by now the only remaining company still supporting
Symbian outside Japan, announced that it would use Microsoft's Windows Phone
7 as its primary smartphone platform, while Symbian would be gradually wound
down.
24
MAINTENANCE TEAM RESPONSIBILITIES
understanding the system
locating information in system documentation
keeping system documentation up-to-date
extending existing functions to accommodate new or changing
requirements
adding new functions to the system
finding the source of system failures or problems
25
MAINTENANCE TEAM RESPONSIBILITIES
locating and correcting faults
answering questions about the way the system works
restructuring design and code components
rewriting design and code components
deleting design and code components that are no longer useful
managing changes to the system as they are made
26
MAINTENANCE PROBLEMS
Staff problems
Limited understanding
Management priorities
Morale
Technical problems
Artifacts and paradigms
Testing difficulties
27
FACTORS AFFECTING MAINTENANCE EFFORT
Application type
System novelty
Turnover and maintenance staff ability
System life span
Dependence on a changing environment
Hardware characteristics
Design quality
Code quality
Documentation quality
Testing quality
28
MEASURING MAINTAINABILITY
29
MAINTENANCE COSTS
Usually greater than development costs (2* to 100* depending on the application)
Affected by both technical and non-technical factors
Increases as software is maintained
Maintenance corrupts the software structure, making further maintenance more
difficult
Ageing software can have high support costs
(e.g. old languages, compilers etc.)
Think of your software as continuously evolving
30
DEVELOPMENT/MAINTENANCE COSTS
31
MAINTENANCE COST FACTORS
Team stability
Maintenance costs are reduced if the same staff are involved with them for some time
Contractual responsibility
The developers of a system may have no contractual responsibility for maintenance so there
is no incentive to design for future change
Staff skills
Maintenance staff are often inexperienced and have limited domain knowledge
Program age and structure
As programs age, their structure is degraded and they become harder to understand and
change
32
MAINTENANCE PREDICTION
Maintenance prediction is concerned with assessing which parts of the system
may cause problems and have high maintenance costs.
Change acceptance depends on the maintainability of the components affected
by the change;
Implementing changes degrades the system and reduces its maintainability;
Maintenance costs depend on the number of changes and costs of change
depend on maintainability
33
MAINTENANCE PREDICTION
34
CHANGE PREDICTION
Predicting the number of changes requires and understanding of the
relationships between a system and its environment.
Tightly coupled systems require changes whenever the environment
is changed.
Factors influencing this relationship are :
Number and complexity of system interfaces;
Number of inherently volatile system requirements;
The business processes where the system is used.
35
COMPLEXITY METRICS
Predictions of maintainability can be made by assessing the complexity of system
components.
Studies have shown that most maintenance effort is spent on a relatively small
number of system components.
Complexity depends on
Complexity of control structures;
Complexity of data structures;
Object, method (procedure) and module size.
36
PROCESS METRICS
Process measurements may be used to assess maintainability
Number of requests for corrective maintenance;
Average time required for impact analysis;
Average time taken to implement a change request;
Number of outstanding change requests.
If any or all of these is increasing, this may indicate a decline in maintainability.
37
SOFTWARE EVOLUTION Process
Evolution processes depend on
The type of software being maintained;
The development processes used;
The skills and experience of the people involved.
Proposals for change are the driver for system evolution. Change
identification and evolution continue throughout the system lifetime.
38
CHANGE IDENTIFICATION AND EVOLUTION
39
THE SYSTEM EVOLUTION PROCESS
40
CHANGE IMPLEMENTATION
41
URGENT CHANGE REQUESTS
Urgent changes may have to be implemented without going through
all stages of the software engineering process
If a serious system fault has to be repaired;
If changes to the systemʼs environment (e.g. an OS upgrade) have
unexpected effects;
If there are business changes that require a very rapid response (e.g.
the release of a competing product).
42
EMERGENCY REPAIR
43
CONFIGURATION CONTROL PROCESS
Problem discovered by or change requested by user/ customer/developer, and recorded
Change reported to the Configuration Control Board (CCB)
CCB discusses problem: determines nature of change, who should pay
CCB discusses source of problem, scope of change, time to fix; they assign
severity/priority and analyst to fix
Analyst makes change on test copy
Analyst works with librarian to control installation of change
Analyst files change report
44
CHANGE CONTROL ISSUES
Synchronization: When was the change made?
Identification: Who made the change?
Naming: What components of the system were changed?
Authentication: Was the change made correctly?
Authorization: Who authorized that the change be made?
Routing: Who was notified of the change?
Cancellation: Who can cancel the request for change?
Delegation: Who is responsible for the change?
Valuation: What is the priority of the change?
45
IMPACT ANALYSIS
Impact analysis is the evaluation of the many risks
associated with the change, including estimates of effects on
resources, effort, and schedule.
Work product
any development artifact whose change is significant, e.g.
requirements, design and code components, test cases, etc.
the quality of one can affect the quality of others
Horizontal traceability
relationships of components across collections of work
products
Vertical traceability
relationships among parts of a work product
46
ARCHITECTURAL EVOLUTION
There is a need to convert many legacy systems from a centralised
architecture to a distributed (e.g., client-server) architecture
Change drivers
Hardware costs. Servers are cheaper than mainframes
User interface expectations. Users expect graphical user interfaces
Distributed access to systems. Users wish to access the system from different,
geographically separated, computers
47
SOFTWARE REENGINEERING
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
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
48
REENGINEERING 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
49
FORWARD VS REENGINERING
50
REENGINERING PROCESS
51
REENGINEERING PROCESS ACTIVITIES
Source code translation
Convert code to a new language.
Reverse engineering
Analyze the program to understand it;
Program structure improvement
Restructure automatically for understandability;
Program modularization
Reorganize the program structure;
Data reengineering
Clean-up and restructure system data.
52
REENGINEERING APPROACHES
Automated progr am Program and data
restructuring restructuring
Increased cost
53
REENGINEERING COST FACTORS
The quality of the software to be reengineered.
The tool support available for reengineering.
The extent of the data conversion which is required.
The availability of expert staff for reengineering.
This can be a problem with old systems based on technology
that is no longer widely used.
54
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
PROGRAM RESTRUCTURING – SPAGHETTI LOGIC
-- Complex condition
if not (A > B and (C < D or not ( E > F) ) )...
-- Simplified condition
if (A <= B and (C>= D or E > F)...
Program modularisation
• The process of re-organising a program so that related program parts
are collected together in a single module
• Usually a manual process that is carried out by program inspection
and re-organisation
Recovering data abstractions
• Many legacy systems use shared tables and global data to save
memory space
• Causes problems because changes have a wide impact in the system
• Shared global data may be converted to objects or ADTs
• Analyse common data areas to identify logical abstractions
• Create an ADT or object for these abstractions
• Use a browser to find all data references and replace with reference to the
data abstraction
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
Why reverse engineer
• 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
LEGACY SYSTEM EVOLUTION
● Organisations that rely on legacy systems must choose a strategy for
evolving these systems
● Scrap the system completely and modify business processes so that it is
no longer required;
● Continue maintaining the system;
● Transform the system by re-engineering to improve its maintainability;
● Replace the system with a new system. The strategy chosen should
depend on the system quality and its business value.
LEGACY SYSTEMS
❍ Low quality, low business value
These systems should be scrapped.
❍ Low-quality, high-business value
These make an important business contribution but are expensive to
maintain. Should be re-engineered or replaced if a suitable system is
available.
❍ High-quality, low-business value
Replace with COTS, scrap completely or maintain.
❍ High-quality, high business value
Continue in operation using normal system maintenance.
BUSINESS ASSESSMENT
Assessment should take different viewpoints into account
System end-users;
Business customers;
Line managers;
IT managers;
Senior managers.
Interview different stakeholders and collate results.
QUALITY ASSESSMENT
Business process assessment
How well does the business process support the
current goals of the business?
Environment assessment
How effective is the systemʼs environment and how
expensive is it to maintain?
Application assessment
What is the quality of the application software
system?
Key points
Software change strategies include software maintenance,
architectural evolution and software re-engineering
Lehman’s Laws are invariant relationships that affect the
evolution of a software system
Maintenance types are adaptive, perfective, and corrective
Key points
The costs of software change usually exceed the costs of
software development
Factors influencing maintenance costs include staff stability, the
nature of the development contract, skill shortages and
degraded system structure
Architectural evolution is concerned with evolving centralised
to distributed architectures
Re-engineering reorganizes and modifies existing software
systems to make them more maintainable
THANK YOU