Date post: | 06-Apr-2018 |
Category: |
Documents |
Upload: | nawrasunivers |
View: | 237 times |
Download: | 0 times |
of 28
8/3/2019 Chapter 6 Software Evolution and Maintenance
1/28
Chapter 6
Software Evolution and Maintenance
8/3/2019 Chapter 6 Software Evolution and Maintenance
2/28
Software evolution
Software evolution is the inevitable change of adeployedsoftware product over its lifetime.
Software change occurs due to:
New requirements emerge when the software is used
Business environment changes
Errors that must be repaired
New computer hardware
Improving the performance/reliability of the system
The implementation and management of changeis critical for organizations.
8/3/2019 Chapter 6 Software Evolution and Maintenance
3/28
Software Evolution
Software evolution is the set of activities, both technical and managerial, that ensures
that software continues to meet organisational and businessobjectives in a cost effective way.[Research Inst. On Sw.Evolution]
all programming activity that is intended to generate a newsoftware versionfrom an earlier operational version[Lehman&Ramil 2000]
The application ofsoftware maintenance activities andprocesses that generate a new operational software version
with a changed customer-experienced functionality orproperties from a prior operational version together with theassociated quality assurance activities and processes, and withthe management of the activities and processes [Ned Chapin1999]
8/3/2019 Chapter 6 Software Evolution and Maintenance
4/28
Types of software evolution
Was software
changed?
1. Training
2. Consultive
3. Evaluative
NoWas source code
changed?
1. Reformative2. Updative
Yes
NoWas function
changed?
1. Groomative
2. Preventive
3. Performance
4. Adaptive
Yes
No
1. Reductive
2. Corrective
3. Enhancive
Yes
8/3/2019 Chapter 6 Software Evolution and Maintenance
5/28
Types of software evolution
Did the activities change the software? No.(Training) Did the activities use the software as a subject for
stakeholder training?
(Consultive) Did the activities use the software as a basis for
consultation?(Evaluative) Did the activities involve evaluating the software?
Did the activities change the code? No.(Reformative) Did the activities make the non-code
documentation conform more closely to the stakeholdersneeds?
(Updative) Did the activities make the non-codedocumentation conform more closely to the system asimplemented?
8/3/2019 Chapter 6 Software Evolution and Maintenance
6/28
Types of software evolution
Did the activities change the customer-experiencedfunctionality? No.
(Groomative) Did the activities change maintainability orsecurity?
(Preventive) Did the activities avoid or reduce futuremaintenance activities?
(Performance) Did the activities alter software performancecharacteristics or properties?
(Adaptive) Did the activities change the technology or
resources used?
8/3/2019 Chapter 6 Software Evolution and Maintenance
7/28
Main reasons why software evolves
changes in user requirements
user-requested extensions as well as modifications
bug fixes
scheduled routine fixes
emergency fixes (more costly due to heavy pressure) changes in data formats
Y2K, Euro, tax rates, postal codes,phone numbers, ...
new standards: UML, XML, COM,DCOM, CORBA, ActiveX, WAP
hardware changes
efficiency improvements Changeddata formats
(18%)
Bug fixes
(21%)
Hardware
changes (6%)
Efficiency
improvement
s (4%)
Changed
user
requirement
s (42%)
8/3/2019 Chapter 6 Software Evolution and Maintenance
8/28
Software maintenance
Software maintenance is the process ofchanging a system after it has been delivered.
Post-delivery maintenance is any change to anycomponent ofthe product (including
documentation) after it has passed theacceptance test.
Maintenance does not normally involve majorchanges to the systems architecture.
Changes are implemented by modifying existingcomponents and adding new components to thesystem.
8/3/2019 Chapter 6 Software Evolution and Maintenance
9/28
Software Maintenance
Modifying a program after it has been put into
use
Maintenance does not normally involve majorchanges to the systems architecture
Changes are implemented by modifying existing
components and adding new components to the
system
8/3/2019 Chapter 6 Software Evolution and Maintenance
10/28
Software Aging (...)
Reasons why software ages maintenance
ignorant surgery and architectural erosion
inflexibility from the start insufficient or inconsistent documentation
deadline pressure
duplicated functionality (code duplication)
lack of modularity ...
Possible solution: reengineering
8/3/2019 Chapter 6 Software Evolution and Maintenance
11/28
Legacy systems - definitions
From the perspective of vogue (advances in
technology) even completely functional and
well maintained system is considered legacy if
developed on obsolete technology [Perspectives
on Legacy System Reengineering, SEI CMU, 1995]
From the economic perspective a system is
considered legacy if it could not follow the rate ofchange in business domain [Alderson, CACM,
1999]
8/3/2019 Chapter 6 Software Evolution and Maintenance
12/28
Problems with legacy systems
Often run on obsolete hardware
hard to maintain, improve, and expand
general lack of understanding of the system: no one left to explain how it works
documentation or manuals getting lost over the
years.
Integration with newer systems difficult
8/3/2019 Chapter 6 Software Evolution and Maintenance
13/28
Reasons for keeping legacy systems
(despite the problems)
The costs of redesigning the system are prohibitive
because it is large, monolithic, and/or complex.
The system requires close to 100% availability, so it
cannot be taken out of service The way the system works is not well understood.
The user expects that the system can easily be replaced
when this becomes necessary.
The system works satisfactorily, and the owner sees no
reason for changing it.
8/3/2019 Chapter 6 Software Evolution and Maintenance
14/28
8/3/2019 Chapter 6 Software Evolution and Maintenance
15/28
Types of Maintenance
1)Corrective maintenance to repair software faults.
Changing a system to correct deficiencies in the way itmeets its requirements.
2)Adaptive maintenance to respond to changes in operating
environment. Changing a system so that it operates in a different
environment (computer, OS, etc.) from its initialimplementation.
Different tax codes, government laws, etc.
3)Perfective maintenance to improve product functionality.
Modifying the system to satisfy new requirements
This is the biggest maintenance cost (approximately 65%).
8/3/2019 Chapter 6 Software Evolution and Maintenance
16/28
Maintenance costs
Maintenance costs are usually greater thandevelopment costs by a factor of 2 to 100!
The costs arise from both technical and non-technical factors. A deployed system is expensive to change and get
permission to change. High cost of breaking analready working system.
Maintenance costs increase over time and as the
system evolves. Reasons: Maintenance changes degrades the original systemstructure.
Aging software results in high support costs.
8/3/2019 Chapter 6 Software Evolution and Maintenance
17/28
Quick-fix Pressures
All too often, software changes duringmaintenance are subject to pressures to achievea quick-and-dirty solution rather than aconsidered but slower change.
Such pressures arise naturally for changes inresponse to fault reports where it is urgent thatthe user can resume use of the correctedsoftware, or where changes in the user
requirements mean that continued use of thecurrent version of the software creates problemsfor the user.
8/3/2019 Chapter 6 Software Evolution and Maintenance
18/28
Maintenance Cost Factors
1. Team stability Maintenance costs are reduced if the same staff are
involved with them for some time.
2. Contractual responsibility
The developers of a system may have no contractualresponsibility for maintenance so there is no incentive todesign for future change.
3. Staff skills
Maintenance staff are often inexperienced and have limited
domain knowledge.4. Program age and structure
As programs age, their structure is degraded and theybecome harder to understand and change.
8/3/2019 Chapter 6 Software Evolution and Maintenance
19/28
Maintenance Programmers
60-70% of the total cost of a product is maintenance, but manyorganizations use junior programmers for maintenance.
Maintenance is one of the most difficult aspects of softwareproduction because it involves aspects of all other workflows.
Analysis Must find potential fault given only user defect report,source code, and hopefully some documentation.
Requires superb debugging skills to find fault anywhere in product.
Design On finding a fault, how to fix it without introducing a
regression fault (a new fault caused by changing the product)?
Minimizing new faults requires documentation that is often notpresent.
Implmentation Programmer changes the source code. Testing - Test that the modification works correctly with new and
existing test cases and document changes.
8/3/2019 Chapter 6 Software Evolution and Maintenance
20/28
Maintenance Programmers
Major skills are required for corrective maintenance Super diagnostic skills
Super testing skills
Super documentation skills
For adaptive and perfective maintenance, the maintenanceprogrammer must go through the requirements,specification, design, and implementation and integrationworkflows using the existing product as a starting point.
When programs are developed, each of these workflowsare produced by specialized experts.
A maintenance programmer must be expert in all the areasand also in testing and documentation!
8/3/2019 Chapter 6 Software Evolution and Maintenance
21/28
The Rewards of Maintenance
Maintenance is a thankless task in every way: Maintainers deal with dissatisfied users.
If the user were happy, the product would not need maintenance.
The users problems are often caused by the individuals whodeveloped the product, not the maintainer.
The code itself may be badly written. Post delivery maintenance is despised (detested, hated) by manysoftware developers.
Unless good maintenance service is provided, the client will takefuture development business elsewhere.
Post delivery maintenance is the most challenging aspect of
software production and the most thankless. The user frequently does not understand that maintenance can be
difficult, or all but impossible for some requests.
8/3/2019 Chapter 6 Software Evolution and Maintenance
22/28
Maintenance Conclusion
Maintenance is a major cost for software and must beplanned for during the entire life cycle.
Design workflow use information-hiding techniques
Implementation workflow good coding style
Documentation must be complete, correct, and current.
During maintenance, maintainability must not becompromised.
No form of maintenance
Is a task for an unsupervised beginner, or
Should be done by a less skilled computer professional Maintenance is so critical and challenging that the bestpeople should be put on the task and rewarded accordingly.
8/3/2019 Chapter 6 Software Evolution and Maintenance
23/28
System Evolution Process
It is important that an organization have a process tomanage system evolution.
It is not acceptable for changes to be made directly tothe implementation!
Software changes should go through the usual steps ofspecification, design, implementation, and testing.
Urgent changes may have to be implemented withoutgoing through all stages of the software engineeringprocess.
e.g. handle serious faults, hardware/OS failure Must make sure to go back and document and analyzeafter change has been made!
8/3/2019 Chapter 6 Software Evolution and Maintenance
24/28
System Evolution Process Diagram
8/3/2019 Chapter 6 Software Evolution and Maintenance
25/28
Legacy System Evolution
Evolving legacy systems is especially complex as long-lived
systems are extremely costly to replace.
Strategies:
Scrap the system completely and modify businessprocesses so that it is no longer required.
Continue maintaining the system.
Re-engineer the system to improve its maintainability
Replace the system with a new system. The strategy chosen depends as much on business and
risk factors as it does on technical factors.
8/3/2019 Chapter 6 Software Evolution and Maintenance
26/28
The Reverse Engineering Process
A simple reverse engineering process, to designlevel, may involve the following steps:
identify and document each procedure orsubroutine in the code (in purely functional
terms) derive a structure chart for these by analysis of
the calls between them
identify and document the data that flows
through this hierarchy of procedures redocument, and rename if necessary, the data
and procedures in application-oriented terms
8/3/2019 Chapter 6 Software Evolution and Maintenance
27/28
Program understanding and program
visualization tools can provide significant help
in steps 1 to 3.
Introduction of judicious (careful) abstraction,
such as: omitting minor procedures obviously
introduced at the coding stage, or ignoring
secondary parameters such as array sizes, etc.,is important for effective design recovery
8/3/2019 Chapter 6 Software Evolution and Maintenance
28/28
Reverse Engineering in relation to other activites