Computing and SE II Chapter 13: Software Maintenance Er-Yu Ding Software Institute, NJU.

Computing and SE II

Chapter 13: Software Maintenance

Er-Yu DingSoftware Institute, NJU

Main Contents

1. What is software maintenance?2. Life cycles and maintenance3. Problems of software maintenance4. The maintenance process5. Legacy Systems, Reverse Engineer

and Re-engineering

1. What is Software Maintenance?

• Software Evolution‘Software development does not stop when a system is delivered but continues throughout the lifetime of the system’ . (Sommerville, 2004)

• The system changes relate to changing business and user needs

• The system evolves throughout its lifetime through a seamless process

• The process is a spiral process involving requirements, design & implementation throughout the lifetime of the system


• IEEE91 Definition:– the process of modifying the software

system or component after delivery to correct faults, improve performance or other attributes, or adapt to a change in the environment.

• SM is concerned with modifying software once it is delivered to a customer


• Four categories:1. Perfective maintenance: changes required as a

result of user requests (a.k.a. evolutive maintenance)

2. Adaptive maintenance: changes needed as a consequence of operated system, hardware, or DBMS changes

3. Corrective maintenance: the identification and removal of faults in the software

4. Preventative maintenance: changes made to software to make it more maintainable

• The majority of SM is concerned with evolution deriving from user requested changes.


2. Life cycles and maintenance



2. Life cycles and maintenance---Initial development

• first version of the software system is developed– may be lacking some features

• software architecture is established– likely to persist thought the rest of the life of the

program• in one documented instance, we studied a program

that underwent substantial changes during its 20 years of existence, but it still possesses the architecture of the original first version.

• programming team acquires the knowledge of– application domain, user requirements, role of the

application in the business process, solutions and algorithms, data formats, strengths and weaknesses of the program architecture, operating environment, etc.

– crucial prerequisite for the next phase of evolution.

2. Life cycles and maintenance--- challenges for initial

development• To build evolvable software– in the evolvable architecture, ‘the cost of

making the change is proportional to the size of the change, not to the size of the overall software system’

– evolvable software can handle unanticipated changes

• ‘design for change’ should be predominantly aimed at strategic evolution, not code level servicing

2. Life cycles and maintenance--- Design for change

• A strategy to set a certain rules during the Software development.

• It eases the maintainability of the system• Three main Factors that we have to

ensure during the design of the Software: – Understandability, – Modifiability,– Stability.

2. Life cycles and maintenance--- Evolution

• goals– to adapt the application to the ever-changing user

and operating environment– to correct the faults in the application– to respond to both developer and user learning

• inevitability of evolution [Lehman]• program grows during evolution [Lehner,

Lehman]• business setting of evolution– user demand is strong– the organization is supportive– return on investment is excellent– both software architecture and software team

knowledge make evolution possible

2. Life cycles and maintenance---Servicing

• the program is no longer evolvable• changes are limited to patches and wrappers

– they are less costly– they further deteriorate the architecture.

• Senior designers and architects do not need to be available

• Tools and processes are very different from evolution

• A typical engineer will be assigned only part of the software to support– will have partial knowledge of the system.

2. Life cycles and maintenance--- Phase-out and close down

stages• phase-out– no more servicing is being undertaken, but the system

still may be in production– the users must work around known deficiencies

• close-down– the software use is disconnected– the users are directed towards a replacement.

• business issues:– Can any of the software be re-used?– ‘exit strategy’ is needed.– once an organization commits to a system, changing to

another is expensive, technically difficult, and time consuming.

– What to do with corporate data?

2. Life cycles and maintenance--- System Assessment

• To determine whether a business still needs a system the system needs to be assessed for:• business value and system quality

• Low quality, low business value – system should be scrapped

• Low quality, high business value – should be re-engineered or replaced

• High quality, low business value – normal maintenance unless maintenance expensive then scrap

• High quality, high business value – normal maintenance

2. Life cycles and maintenance--- Strategic Guidelines for Implementing

Alternatives• Scrap the system completely The system is not making an effective

contribution to business processes

• Leave the system unchanged and continue with regular maintenance Choose when the system is still required, is

relatively stable and has few change requests


Alternatives

• Complete redesign and rewrite» Use when:

more than 20% of the program must be changed program is being upgraded to new technology

» Do not use when: the design and function of the program is not known

• Restructuring to improve maintainability» use on highly maintenance prone programs


Alternatives

• Partial restructuring integrated with adaptive maintenance

» use for orderly improvement with each system release

• Retirement of the system and complete redevelopment

» Use when: moving to a new technology the costs of maintaining the software and the hardware

exceed the cost of re-development

3. Problems of software maintenance

---Software Maintenance is important

• Direct software costs– Major economic importance: 40 – 90% of the

total lifecycle costs– 50-80% of the time of an estimated one

million programmers or programming managers spent on maintenance. ... [Corbi89]

– for every $1 allocated for a new development project, $9 will be spent on maintenance for the life cycle of the project. [Mit]

– …


---Software Maintenance is important

• It is necessary to add, to the direct cost of maintenance, the consequences of the maintenance...– Deterioration of software

• Lost of software structure because of maintenance• May imply software “death” and its benefits• May have catastrophic consequences

– Client dissatisfaction• Difficulty to deal with all the modification requests

• Even if indirect costs are difficult to estimate, they often play a major role


--- Software maintenance is problematic

• Problems of software maintenance– a neglected topic !– Too many factors– Maintainability is difficult to measured– Requirements is volatile


--- A neglected topic• No interest• Industry

– Do you want to work in a software maintenance project ?

– Few resources devoted to software maintenance teams– 90% of managers complain about the employees lack

of interest• Research

– Projects focus on development– Only few conferences and books on software

maintenance• University

– Almost no courses on software maintenance


---Too many factors• What Influences Maintainability?– Application type– System novelty– Turnover of maintenance staff– System life span– Hardware characteristics– Design, code, documentation, and

testing


--- Maintainability is difficult to measured• Respect of Metrics

– Software maintenance should be measured and managed using metrics to reach a quality software.

– However, we don't know how to measure maintainability because it’s a service.


--- Requirements is volatile • Requirements are the foundation of the software release process.– Changing requirements during the

software maintenance process impacts the cost, schedule, and quality of the resulting product.

– Build model to make planning of customer communications (predictions).

• A focus is made on non volatile requirements.

4. The Maintenance Process

begins when a request for change is initiated by a user

ends when the system passes testing, is accepted by the user and is released for operation

in between there are many activities that must be planned and co-ordinated by use of

Change Management

4. The Maintenance Process

Seven-step approach [IEEE-1219]:– Step 1 - Problem/modification identification, classification, and

prioritization.• Change Management

– Step 2 - Analysis• Step 2.1 feasibility analysis

– Impact Analysis• Step 2.2 detailed analysis

– System Release Planning– Step 3 – Design (the Changes)– Step 4 - Implementation

• Code the Changes– Step 5 - Regression/system testing– Step 6 - Acceptance testing.– Step 7 - Delivery

• System Release

4. The Maintenance Process ---Step 1 - Change Management

– to uniquely identify, describe and track the status of each requested change

– in an organisation» change requests are recorded and tracked

through all stages of the maintenance process in a Change Management Tracking System

» Project Management and the Quality Assurance team receive information about the status of the Change Requests

4. The Maintenance Process --- Step 1 - Change Management …

Change Request » basic tool (manual or electronic) of change

management

» documents all information about changes

» updated throughout the maintenance process to help manage the system release for the analysis of the types and frequency of

defects to communicate to maintainers, managers and

clients

4. The Maintenance Process --- Step 2.1 - Impact Analysis

An Impact Analysis– identifies all systems/system products affected by a

change request – develops an estimate of the resources needed to

accomplish the change

Steps:1. Evaluate Change Requests

2. Estimate Resources

4. The Maintenance Process --- Step 2.1 - Impact Analysis ...

Aims:• to determine the scope of the requested change for

planning and implementation of the change• to develop accurate estimates of resources• to analyse cost/benefits of the change• to communicate the complexity of the change


1. Evaluate Change Requests• look for potential impact on:

- existing systems, other systems, hardware, documentation, data structures and humans

• without analysis of the changes the change may insert defects that are not immediately apparent

Problems:• documentation doesn’t exist and must be created• documentation is out of date or incorrect leading to

incorrect design decisions


2. Estimate Resources

In an organisation, a project manager must estimate:

– Number of people required to complete the system– The equipment required eg PCs, printers, copiers etc– Other facilities such as offices, support staff etc– Cost of the system etc


To Estimate Resources need to know:– Size of required changes measured as

– LOC and/or– Function Points and/or– Proxies such as classes and routines

(Impact Analysis will give this information)

– Historical information– eg Productivity Rate, Average LOC per Routine

– Time required to complete the system changes– Size of system and productivity rate

4. The Maintenance Process --- Step 2.2 - System Release Planning

Aims:» to establish the schedule of system releases» to determine the contents of a system release

System Release/Version Description Document» describes the contents / timing of a system release» communicates between maintainers and users» used by operations to plan hardware, operational procedures

and backup procedures

4. The Maintenance Process --- Step 3 - Design Changes

Aims:• to develop a revised logical and physical

design analyse and design the changes update the documentation update the configuration management

system update the change request for management

• to design the changes for each of the different types of maintenance

4. The Maintenance Process --- Design Changes …

For Corrective Maintenance:– includes all repairs of defects in an existing system

Defects can stem from:» requirements specification errors» design errors» coding errors

About 80% of all problems stem from requirements and design

4. The Maintenance Process --- For Corrective Maintenance …

Problems repairing defects:» cleanly repairing a defect

repairing a defect has a 20-50% change of introducing another defect

because: Ripple-effect may be overlooked person who makes the repair is not generally the

person who wrote the code» increased testing

Every solution causes new problems

4. The Maintenance Process --- Design Changes ...

For Adaptive Maintenance: Aims to evolve systems to meet user and business needs– Essentially the same as a new development except

that system understanding is needed first» Requirements then Design: - Systems, Data, Program and

Module

At each stage conduct design and code reviews.

4. The Maintenance Process --- Design Changes ...

For Perfective Maintenance ... – includes all efforts to polish or refine the

quality of the software or the documentation

– includes re-engineering» rewriting and upgrading documentation» restructuring poorly written code

– important that the improvement reduces the system maintenance costs

4. The Maintenance Process --- Step 4 – Code the Changes

Aim: to clarify existing code and simplify changing it

Re-Engineering Source Code• Restructuring• Redesign and rewrite code

• Remember design and code reviews

4. The Maintenance Process --- Step 5,6 – Test the Changes

Maintenance / Development DifferencesFor Maintenance:

only changes need to be reviewed only new test cases that exercise the changes need to be

developed existing and new test cases are required to test the changes test results are compared against previous test results

(Regression Testing)

4. The Maintenance Process --- Step 7 - System Release

Aims:• package the system for release including:

documentation software training other products hardware

• deliver the system to the user install with backup procedures

5. Legacy Systems, Reverse Engineer and Re-engineering

---Legacy Systems• Legacy problems – a legacy system is typically:

– very old and large– has been heavily modified – based on the old technology– documentation not be available– none of the original members of the software

development team may still be around– often support very large quantities of live data– the software is often at the core of the business

and replacing it would be a huge expense.• Dealing with legacy system is very hard and

there are some solutions.


--- Legacy Systems• Solutions for the legacy system:– discarding the legacy system and building

a replacement system;– freezing the system and using it as a

component of a new larger system; – carrying on maintaining the system for

another period; – modifying the system to give it another

lease of life– Reverse Engineer the legacy system and develop

a new software suite. the most fruitful solution!


--- Reverse Engineering• Definition: Reversing Engineering

– The process of analyzing a subject system to identify the system’s components and their inter-relationships, and to create representations of the system in another form or at higher levels of abstraction.( by Chikofsky & Cross)

• Two types of Reverse Engineering:1. Redocumentation: the creation or revision of a

semantically equivalent representation within the same relative abstraction layer;

2. Design Recovery: involves identifying meaningful higher level abstractions beyond those obtained directly by examining the system itself.

• The main motivation is to provide help in program comprehension


--- Reverse Engineering• reverse engineering has been successfully applied include– identifying reusable assets – finding objects in procedural programs – discovering architectures – deriving conceptual data models – detecting duplications – transforming binary programs into source

code – renewing user interfaces – parallelizing sequential programs – Translating, downsizing, migrating and

wrapping legacy code


--- Re-engineering• “Software Re-engineering is any activity that: (1) improves one’s

understanding of software, or (2) prepares or improves the software itself, usually for increased maintainability, reusability, or evolvability.”

• Re-engineering can involve:• Re-documenting• Organising and restructuring the system• Translating to a more modern programming language• Modifying the structure of the data

• The old system forms the specification for the new system


---Reverse engineering and re-engineering.

The End

• Recommend papers–《 software maintenance 》

• The next lecture– Project Management

Computing and SE II Chapter 13: Software Maintenance Er-Yu Ding Software Institute, NJU.

Documents