CS189A/172 - Winter 2008

offbeatnothingΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 6 μήνες)

63 εμφανίσεις

CS189A/172
-

Winter 2008

Lecture 15: Software Maintenance

Software Maintenance


What is software maintenance?



Software maintenance is the process of modifying the software
system or component after the delivery to correct faults, improve
performance or other attributes, or adapt to a change in
environment



Maintenance Is Costly


For most software, software maintenance occupies between 40 to 90
percent of total life cycle costs


A common mistake is to overlook maintenance costs:



In 1950s, when banks were hiring their first full
-
time programmers
they were worried about what these people will do after the
programs were written


Maintenance is challenging


When US banks introduced ATMs, existing banks had difficulty in
adapting their software to the new system, whereas new banks
writing software from scratch had an easier time


In UK two mergers of financial institutions were canceled due to
problems of integrating software from two different organizations


Types of Software Maintenance


Perfective maintenance


Changes required as a result of user requests to improve some of
the qualities of the software



Adaptive maintenance


Changes needed as a consequence of change in the environment
of the software such as operating system, hardware or change in
the requirements



Corrective maintenance


The identification and removal of faults in the software



Preventive maintenance


Changes made to software to make it more maintainable


Software Maintenance Issues


The important requirement for the client is that changes are
accomplished quickly and cost effectively



The reliability of the software should not be degraded by the changes



A program used in a real world environment has to change or it will
progressively become less useful



As a program keeps evolving its structure tends to become more
complex, extra resources must be devoted to preserving the semantics
and simplifying the structure



When the source code for the software changes, this has a ripple effect
since also the documentation, design and test suites have to change

Organizational Issues


Initial software development is product
-
oriented where the aim is
to deliver a product within budget and timescale



Software maintenance on the other hand is closer to a service



Some companies choose to outsource maintenance


not a good idea for the core products


outsourcing company will spend sometime assessing the
software before accepting the contract



Service level agreements between the customer and the
maintenance organization are used to define the service to be
provided during maintenance


Unfortunately for software products we are more likely to see
agreements in the form of
disclaimer

rather than
warranty

Process Models for Maintenance


Process management is defined as the direction, control and
coordination of work performed to develop a product or perform a
service



A common process model for software maintenance has four key
stages


Help desk:

The problem is received, a preliminary analysis
undertaken, and if the problem is sensible, it is accepted


Analysis:

A managerial and technical analysis of the problem is
undertaken to investigate and cost alternative solutions


Implementation:

The chosen solution is implemented and tested


Release:

The change (along with possibly others) is released to the
customer

IEEE Standard for Software Maintenance


IEEE Standard defines seven stages of software maintenance activity:


Problem Identification


Analysis


Design


Implementation


System Test


Acceptance Test


Delivery


Each of the seven activities have:


input life cycle products: inputs to this activity


output life cycle products: deliverables of this activity


activity definition


control: a set of quality control actions


metrics: the measurements that should be performed

IEEE Standard for Software
Maintenance: Analysis Phase


For example the analysis phase accepts a validated problem report,
initial resource estimates and project and system documentation



Analysis phase has two components


Feasibility analysis: Assess the impact of the modification,
investigate alternative solutions, assess short and long term costs,
compute benefit of making the change


Detailed analysis: Once a particular approach is chosen, in detailed
analysis phase, requirements for the modification, the software
components involved are identified, a test strategy and an
implementation plan is produced

IEEE Standard for Software
Maintenance: Analysis Phase


Analysis phase produces the following deliverables:


Feasibility report for problem reports


Detailed analysis report


Updated requirements


Preliminary modification list


Development, integration and acceptance test strategy


Implementation plan

Technical Aspects of Software
Maintenance


Certain technical issues are common to both software development
and maintenance


configuration management and version control (CVS, RCS)



Some technical issues are unique to software maintenance


to determine the cost of making a change to meet a software
change request



Impact Analysis


Ripple effect propagation is a phenomenon by which changes made to
a software component along the software life cycle (specification,
design, code, or test phase) have a tendency to be felt in other
components



Impact analysis


the task of assessing the effects for making the set of changes to a
software system


translate the user identified problem into software terms, the
primary components of the system which must be altered to meet
the new requirement


figure out the changes that will be the consequence of the primary
change in all components not just code

Impact Analysis


Most modern programming languages and compilers will do some
static analysis to report the incompatibilities which result from changes
in one part of the code


an automated impact analysis to prevent undesirable ripple effects


Traceability


Traceability is a degree to which a relationship can be established
between two or more products of the development process, especially
products having a predecessor successor or master subordinate
relationship to one another



If software products are traceable, impact analysis will be easier


when you make a change in your design you would like to figure
out which software components will be effected by that change


Legacy Systems


Legacy systems


typically an old, large, heavily modified system


none of the original developers may still be around


the languages may be out of date



It is estimated that there 70 billion lines of COBOL code in existence
still doing useful work

Legacy Systems


Different options about the maintenance of legacy systems:


keep the legacy software, subcontract the maintenance to
companies who specialize on maintenance of legacy systems


replace parts of the software


re
-
implement from scratch


discard software and discontinue


freeze maintenance and phase in a new system


encapsulate the old system and call as a server to the new


reverse engineer the legacy system and develop a new software
suite


Reverse Engineering


Reverse engineering is 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 a higher
level of abstraction



Examples:


Producing call graphs or control flow graphs from source code


Generating class diagrams from the source code


Reverse Engineering


Two types of reverse engineering:



Redocumentation: the creation or revision of a semantically
equivalent representation within the same relative abstraction layer


For example adding indentation to the source code



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


Reverse Engineering


The main goal is to help with the program comprehension



Most of the time reverse engineering makes up for lack of good
documentation



Documentation required in the implementation phase and the
maintenance phase maybe different



Program documentation written in the implementation phase can be
very useful in the maintenance phase


Javadoc, docgen



Re
-
engineering


During the maintenance phase the product may need to be
restructured



Restructuring: the transformation from one representation to
another at the same relative level of abstraction, while preserving
the system’s internal behavior



Re
-
engineering: The examination and alteration of the subject
system to reconstitute it in a new form, and the subsequent
implementation of the new form

Re
-
engineering


Examples


Control flow restructuring to remove “spaghetti code”


Converting monolithic code to use procedures


Identifying modules and abstract data types


removing dead code and redundant variables


simplifying aliased/common or global variables


Refactoring


A reengineering technique called refactoring became quite popular
recently



Refactoring

is a change made to the internal structure of software to
make it easier to understand and modify without changing its
observable behavior


Refactoring: A Example


For example assume that you have a method which looks like:








class Promotion


choosePromotion(Account anAccount) {


switch (anAccount.getType()) {


case SILVER: ...


case GOLD: ...


case PLATINUM: ...


}


}

Refactoring: An Example


One can refactor this code by subtyping the
Account

class and
moving the
choosePromotion

method to the
Account
class





This would get rid of the switch statement in the code and make it
easier to maintain

class Account


choosePromotion() { ... }

Refactoring Catalog


The idea is that one can generalize refactoring transformations and
catalog them


similar to design patterns



There is a catalog of refactoring transformations in the following book:


“Refactoring: Improving the Design of Existing Code,” by Martin
Fowler, Addison Wesley



One can use this refactoring catalog to look for refactorings that are
applicable to a software system



Refactoring Catalog


Each entry in the catalog has five parts:


name
: useful in creating a vocabulary for refactorings


summary
: a summary of the situation where the refactoring would
be needed and a summary of what it does



motivation
: why the refactoring should be done, and the
circumstances when it shouldn’t be done


mechanics
: explaining how to carry out the refactoring


examples
: demonstrating how the refactoring works



Why Reverse or Re
-
Engineer a System?


Here are some reasons for reverse or re
-
engineering a software
system


To enforce product or process standards


To permit better maintenance management


To simplify complex software


Facilitating detection of errors


Removing side effects


Improve code quality


Production of up
-
to
-
date documentation


Preparing full test suites


Improving the performance


Bringing into line with practices elsewhere in the company


To allow major changes to be made


To discover design and requirements specification


To establish a reuse library


To introduce technical innovation such as new user interface