software change

Software Change

IS301 – Software EngineeringLecture # 25 – 2003-11-18

M. E. Kabay, PhD, CISSPDept of Computer Information Systems

Norwich University [email protected]

mailto:[email protected]

2 Copyright © 2003 M. E. Kabay. All rights reserved.

Topics

Program Evolution DynamicsSoftware MaintenanceArchitectural Evolution


Software Change (1)

Managing processes of software system change


Software Change (2)

Software change inevitableNew requirements emerge when software usedBusiness environment changesErrors must be repairedNew equipment must be accommodatedPerformance or reliability may have to be

improvedKey problem for organizations:

Implementing and managing change to legacy systems


Software Change StrategiesSoftware maintenance

Response to changed requirementsFundamental software structure stable

Architectural transformationGenerally from centralized architecture to

distributed architectureSoftware re-engineering

No new functionality addedRestructured and reorganizedTo facilitate future changes

Strategies may be applied separately or together


Program Evolution Dynamics

Study of processes of system changeLehman and Belady

Major empirical studyProposed ‘laws’ applying to all systems as

they evolvedSensible observations rather than laws

Applicable to large systems developed by large organizations

Perhaps less applicable in other cases


Lehman’s Laws

Continuing Change Increasing ComplexityLarge Program EvolutionOrganizational StabilityConservation of Familiarity


Continuing Change

A program used in a real-world environment must necessarily change or it will progressively become 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 are 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.


Applicability of Lehman’s Laws

Not yet been establishedGenerally applicable to

Large, tailored systems Developed by large organizations

Not clear how they should be modified forShrink-wrapped software productsSystems that incorporate significant

number of COTS componentsSmall organizationsMedium sized systems


Topics



Software Maintenance

Modifying program after it has been put into useDoes not normally involve major changes to

system’s architectureChanges are implemented by

Modifying existing components and Adding new components to system


Maintenance Inevitable

System requirements likely to change while system being developed Because environment changingTherefore delivered system won't meet its

requirements (!)Systems tightly coupled with their environment

When system installed in environment it changes that environment

Therefore changes system requirementsSystems MUST be maintained if they are to

remain useful in their environment


Tool/Problem Relation

Availability of a tool changes the

perception of what is possible


Types of Maintenance

Repair software faultsAdapt software to different operating

environment (e.g., new computer, OS)Add to or modify system’s functionality


Distribution of Maintenance Effort


Spiral Maintenance Model


Maintenance Costs

Usually greater than development costs (2* to 100* depending on application)

Affected by both technical and non-technical factors

Increases as software maintainedMaintenance corrupts software structure

thus making further maintenance more difficult

Ageing software can have high support costs (e.g. old languages, compilers etc.)


Development/Maintenance Costs


Maintenance Cost Factors

Team stability$$ reduced if same staff involved with them

for some timeContractual responsibility

Developers of system may have no contractual responsibility for maintenance

So no incentive to design for future changeStaff skills

Maintenance staff often inexperienced and may have limited domain knowledge

Program age and structureAs programs age, their structure degraded

and they become harder to understand and change


Evolutionary Software

Rather than think of separate development and maintenance phases, evolutionary software software designed to evolve continuously throughout its lifetime.


Maintenance Process


Change Requests

Change requests for system changes From users, customers or management

In principleAll change requests should be carefully

analyzed Part of orderly maintenance process

In practice, some change requests must be implemented urgentlyFault repairChanges to system’s environmentUrgently required business changes


Change Implementation


Emergency Repair


Maintenance Prediction

Assessing which parts of system may cause problems and have high maintenance costs

Implementing changes degrades system and reduces its maintainability

Maintenance costs depend on number of changes and

Costs of change depend on maintainability


Maintenance Prediction


Change Prediction

Predicting number of changes requires and understanding of relationships between system and its environment

Tightly coupled systems require changes whenever environment changed

Factors influencing this relationship Number and complexity of system interfacesNumber of inherently volatile system

requirementsBusiness processes where system used


Complexity Metrics

Predictions of maintainability can be made by assessing complexity of system components

Studies have shown that most maintenance effort spent on relatively small number of system components

Complexity depends onComplexity of control structuresComplexity of data structuresProcedure and module size


Process Metrics

Process measurements may be used to assess maintainabilityNumber of requests for corrective maintenanceAverage time required for impact analysisAverage time taken to implement change

requestNumber of outstanding change requests

If any or all of these increasing, this may indicate decline in maintainability


Topics



Architectural Evolution

Need to convert many legacy systems from centralized architecture to client-server architecture

Drivers for change:Hardware costs: Servers cheaper than

mainframesUser interface expectations: Users expect

graphical user interfacesDistributed access to systems: Users wish

to access system from different, geographically separated, computers


Distribution Factors


Legacy System Structure

Ideally, for distribution, there should be clear separation between user interface, system services and system data management

In practice, these are usually intermingled in older legacy systems


Legacy System Structures


Layered Distribution Model


Legacy System Distribution


Distribution Options

The greater the amount of processing shifted from server to client, the higher the costs of architectural evolution

Simplest distribution modelUI distribution Only user interface implemented on client“Thin client”

Most complex optionServer simply provides data managementApplication services implemented on client“Fat client”


Distribution Option Spectrum


User Interface Distribution

UI distribution takes advantage of local processing power

on PCs to implement graphical user interface

Where there is clear separation between UI and application then legacy system can be modified to

distribute UIOtherwise, screen management middleware

can translate text interfaces to graphical interfaces


User Interface Distribution


UI Migration Strategies

Strategy + -Window management system

Access to all UI functions.

No restrictions on UI design.

Better UI performance

Platform dependent.

May be more difficult to achieve interface consistency.

Web browser Platform independent.

Lower training costs due to user familiarity with WWW.

Easier to achieve interface consistency.

Potentially poorer UI performance.

Interface design is constrained by facilities provided by Web browsers.


Homework

Read Chapter 27 thoroughly using the full SQ3R techniques.

Begin studying Chapter 28 on software re-engineering using the Survey-Question phases of SQ3R in preparation for Thursday’s class.

For Tuesday the 2nd of Dec, complete exercises 27.1 through 27.8 for a total of 24 points. Expect to answer these questions in about ¼ to ½ a page of text each.


DISCUSSION

software change

Documents