Software Deployment, Maintenance Evolution

(1)

Software Deployment,

Maintenance &

Evolution

(2)

Deplo

ymen

t

(3)

Definition

 The delivery, assembly and management at a

site of the resources necessary to use a version

of a software system  make a software

system available to its users

 A software system is a coherent collection of artifacts, such as executable files, source code, data files, and documentation, that are needed at a site to offer some functionalities to the end

users

w

ar

e

De

ploy

ment,

& Ev

oluti

(4)

Urgency

 Software systems are no longer merely

stand-alone applications

 Increasingly, software systems are the integration of a collection of components, both executable and data, possibly dispersed over numerous heterogeneous networked nodes

Soft

w

ar

e

De

ploy

ment,

Maintenance

& Ev

oluti

(5)

Processes

(6)

Processes

 Release

 Interface between developers and actors/users

 The software is assembled into packages

containing sufficient metadata to describe the resources on which it depends

 It includes packaging and advertising

 Installation

 The software is transferred to the customer and configured in preparation for activation

 Activation

 The process of starting the software execution or putting in place triggers that will execute the

software at an appropriate time

(7)

Processes

 De-Activation

 In many systems this is required prior to

adaptation or reconfiguration where a piece of software must be passivated and rendered non-invocable  the inverse of activation

 Update

 The process of changing a piece of installed

software usually triggered by the release of a new version by the developers

 Special case of installation  de-activation and re-activation

 De-Installation

 Removing the deployed software from the machine on which it was deployed

 Obsolence (De-Release)

(8)

Deployment Issues

 Change management  introducing hardware

and software changes

 Dependencies management among software

components

 Large-scale content distribution  network reliability

 Interoperability of heterogeneous platforms

 Deployment coordination and customization 

big-bang or incremental  Internet integration

(9)

Deployment Challenges

 Mobile applications

 Heterogeneity and number of the devices

 Intermittent network connections

 The lack of centralized control

 Personal owned

w

ar

e

De

ploy

ment,

& Ev

oluti

(10)

Main

tenance

(11)

Definition

 The modification of a software product after

delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment (IEEE)

 The modification of a software product after

delivery to correct faults, to improve performance or other attributes (ISO/IEC)

 The software product undergoes modification to

code and associated documentation due to a problem or the need for improvement. The objective is to modify the existing software product while preserving its integrity

w

ar

e

De

ploy

ment,

& Ev

oluti

(12)

Examples

 many, many systems had to be updated

 language analyzers (find where changes need to be made)

 Anti-Virus Software

 don't usually have to update software, but must send virus definitions

 Web-based applications

 73% of total cost of e-commerce used to re-design the website after its first

(13)

Examples

 Windows NT

 30 million LOC added within 6 years

w

Growth of Windows NT

0

1992 1993 1994 1995 1996 1997 1998 1999 2000

Year

WINDOWS NT 3.51

WINDOWS NT 3.1

WINDOWS NT 3.5

(14)

Types

 Adaptive

 changes in the software environment (DBMS, OS)

 Perfective

 new user requirements

 Corrective

 diagnosing and fixing errors

 Preventive

 prevent problem in the futures (increasing software maintainability and reliability)

 Facts:

 75% on adaptive and perfective; 21% on corrective; 4% on preventive

(15)

Processes

 Depending on the types of software being

maintained, the development processes used in an organization and people involved in the

(16)

Difficulties

 Factors adversely effect maintenance

 Lack of models or ignorance of available models (73%)

 Lack of documentation (67.6%)

 Lack of time to update existing documentation (54.1%)

 Other factors (1994 study)

 Quality of original application

 Documentation quality

 Rotation of

(17)

Difficulties

 More factors (Yip ’95 study)

 Lack of human resources

 Different programming styles conflict

 Lack of documentation and tools

 Bad maintenance management

 Documentation policy

 Turnover

w

ar

e

De

ploy

ment,

& Ev

oluti

(18)

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

(19)

E

v

olution

(20)

E

volutio

n



What i

s evoluti

on

??

(21)

Definition

 Changing a software product after delivery to adapt such system to the ever-changing user

requirements and operating environment  the

system operates in or address a problem or activity of a real world

 Software maintenance  bug fixing or error

correction

 Software evolution  adaptive and perfective

w

ar

e

De

ploy

ment,

& Ev

oluti

(22)

Software Change

 Software change is inevitable

 New requirements emerge when the software is used

 The business environment changes

 Errors must be repaired

 New computers and equipment is added to the system

 The performance or reliability of the system may have to be improved

 A key problem for all organizations is

implementing and managing change to their existing software systems

(23)

Urgency

 Organisations 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  The majority of the software budget in large

companies is devoted to changing and evolving existing software rather than developing new software

w

ar

e

De

ploy

ment,

& Ev

oluti

(24)

L

ehman’s Law

A program that is used in a real-world environment must necessarily change, or else 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.

Large program evolution

Program evolution is a self-regulating process. System attributes such as size, time between releases, and the number of reported errors is

approximately invariant for each system release. Organizational

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.

Declining quality The quality of systems will decline unless they are modified to reflect changes in their operational environment.

(25)

Stage Model : Software Life Cycle

w

ar

e

De

ploy

ment,

& Ev

oluti

on

Initial development

Evolution

first running version

evolution changes

Servicing

code decay

servicing patches

Close-down Phase-out

servicing discontinued

(26)

Versioned Stage Model

Close-down Version 1 Initial development

Close-down Version 2 Phase-out Version 2

Phase-out Version 1 Servicing Version 1

Evolution Version 1

evolution changes

Evolution Version . . . Evolution Version 2

evolution of new version

evolution changes

servicing patches

Servicing Version 2

(27)

Initial Development

 Developing the first version

 System architecture proposed even with some

lack features

 System knowledge acquired: application domain,

user requirements, data formats, algorithms, operating environment, etc.  crucial for the evolution

w

ar

e

De

ploy

ment,

& Ev

oluti

(28)

Evolution

 The stage in a software system’s life cycle where

it is in operational use and is evolving as new requirements are proposed and implemented in the system

 The first version already released successfully

 Successful in the marketplace

 User demand is strong

 Revenue streams are buoyant

 The organization is supportive

 ROI is excellent

Soft

w

ar

e

De

ploy

ment,

Maintenance

& Ev

oluti

(29)

E

volutio

n

: ROI

(30)

Evolution

 Adapts the application to the ever-changing user and operating environment

 Adds new features

 Corrects mistakes and misunderstandings

 Responds to both developer and user learning

 Program usually grows during evolution

 Both software architecture and software team

knowledge make evolution possible

Soft

w

ar

e

De

ploy

ment,

Maintenance

& Ev

oluti

(31)

Servicing

 Software maturity  no longer evolvable

 The software remains useful but the only changes made are those required to keep it

operational i.e. bug fixes and changes to reflect

changes in the software’s environment  small

tactical change

 No new functionality is added

 Code decay  loss of system knowledge due to

the loss of key personnel  system goes to servicing

(32)

Phase-out and Close-down

 Phase-out

 no more servicing is being undertaken

 system still may be in production/use

 Close-down

 the software use is disconnected

 towards replacement

 an ‘exit strategy’ is needed :

 changing to another system requires retraining  what to do with long-lived data?

Soft

w

ar

e

De

ploy

ment,

Maintenance

& Ev

oluti

(33)

Software Deployment, Maintenance Evolution