Chapter 6 Software Evolution and Maintenance

8/3/2019 Chapter 6 Software Evolution and Maintenance

1/28

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.


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]


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


5/28


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?


6/28


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?


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/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.


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


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


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]


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


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.


14/28


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%).


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.


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.


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.


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.


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!


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.


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.


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!


24/28

System Evolution Process Diagram


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.


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


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


28/28

Reverse Engineering in relation to other activites

Chapter 6 Software Evolution and Maintenance

Documents

Transcript of Chapter 6 Software Evolution and Maintenance