Upload
zachariah-jayson
View
31
Download
0
Embed Size (px)
DESCRIPTION
Software Change. IS301 – Software Engineering Lecture # 25 – 2003-11-18 M. E. Kabay, PhD, CISSP Dept of Computer Information Systems Norwich University [email protected]. Topics. Program Evolution Dynamics Software Maintenance Architectural Evolution. Software Change (1). - PowerPoint PPT Presentation
Citation preview
Software Change
IS301 – Software EngineeringLecture # 25 – 2003-11-18
M. E. Kabay, PhD, CISSPDept of Computer Information Systems
Norwich University [email protected]
2 Copyright © 2003 M. E. Kabay. All rights reserved.
Topics
Program Evolution DynamicsSoftware MaintenanceArchitectural Evolution
3 Copyright © 2003 M. E. Kabay. All rights reserved.
Software Change (1)
Managing processes of software system change
4 Copyright © 2003 M. E. Kabay. All rights reserved.
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
5 Copyright © 2003 M. E. Kabay. All rights reserved.
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
6 Copyright © 2003 M. E. Kabay. All rights reserved.
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
7 Copyright © 2003 M. E. Kabay. All rights reserved.
Lehman’s Laws
Continuing Change Increasing ComplexityLarge Program EvolutionOrganizational StabilityConservation of Familiarity
8 Copyright © 2003 M. E. Kabay. All rights reserved.
Continuing Change
A program used in a real-world environment must necessarily change or it will progressively become less useful in that environment.
9 Copyright © 2003 M. E. Kabay. All rights reserved.
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.
10 Copyright © 2003 M. E. Kabay. All rights reserved.
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.
11 Copyright © 2003 M. E. Kabay. All rights reserved.
Organizational Stability
Over a program’s lifetime, its rate of development is approximately constant and independent of the resources devoted to system development.
12 Copyright © 2003 M. E. Kabay. All rights reserved.
Conservation of Familiarity
Over the lifetime of a system, the incremental change in each release is approximately constant.
13 Copyright © 2003 M. E. Kabay. All rights reserved.
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
14 Copyright © 2003 M. E. Kabay. All rights reserved.
Topics
Program Evolution DynamicsSoftware MaintenanceArchitectural Evolution
15 Copyright © 2003 M. E. Kabay. All rights reserved.
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
16 Copyright © 2003 M. E. Kabay. All rights reserved.
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
17 Copyright © 2003 M. E. Kabay. All rights reserved.
Tool/Problem Relation
Availability of a tool changes the
perception of what is possible
18 Copyright © 2003 M. E. Kabay. All rights reserved.
Types of Maintenance
Repair software faultsAdapt software to different operating
environment (e.g., new computer, OS)Add to or modify system’s functionality
19 Copyright © 2003 M. E. Kabay. All rights reserved.
Distribution of Maintenance Effort
20 Copyright © 2003 M. E. Kabay. All rights reserved.
Spiral Maintenance Model
21 Copyright © 2003 M. E. Kabay. All rights reserved.
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.)
22 Copyright © 2003 M. E. Kabay. All rights reserved.
Development/Maintenance Costs
23 Copyright © 2003 M. E. Kabay. All rights reserved.
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
24 Copyright © 2003 M. E. Kabay. All rights reserved.
Evolutionary Software
Rather than think of separate development and maintenance phases, evolutionary software software designed to evolve continuously throughout its lifetime.
25 Copyright © 2003 M. E. Kabay. All rights reserved.
Maintenance Process
26 Copyright © 2003 M. E. Kabay. All rights reserved.
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
27 Copyright © 2003 M. E. Kabay. All rights reserved.
Change Implementation
28 Copyright © 2003 M. E. Kabay. All rights reserved.
Emergency Repair
29 Copyright © 2003 M. E. Kabay. All rights reserved.
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
30 Copyright © 2003 M. E. Kabay. All rights reserved.
Maintenance Prediction
31 Copyright © 2003 M. E. Kabay. All rights reserved.
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
32 Copyright © 2003 M. E. Kabay. All rights reserved.
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
33 Copyright © 2003 M. E. Kabay. All rights reserved.
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
34 Copyright © 2003 M. E. Kabay. All rights reserved.
Topics
Program Evolution DynamicsSoftware MaintenanceArchitectural Evolution
35 Copyright © 2003 M. E. Kabay. All rights reserved.
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
36 Copyright © 2003 M. E. Kabay. All rights reserved.
Distribution Factors
37 Copyright © 2003 M. E. Kabay. All rights reserved.
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
38 Copyright © 2003 M. E. Kabay. All rights reserved.
Legacy System Structures
39 Copyright © 2003 M. E. Kabay. All rights reserved.
Layered Distribution Model
40 Copyright © 2003 M. E. Kabay. All rights reserved.
Legacy System Distribution
41 Copyright © 2003 M. E. Kabay. All rights reserved.
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”
42 Copyright © 2003 M. E. Kabay. All rights reserved.
Distribution Option Spectrum
43 Copyright © 2003 M. E. Kabay. All rights reserved.
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
44 Copyright © 2003 M. E. Kabay. All rights reserved.
User Interface Distribution
45 Copyright © 2003 M. E. Kabay. All rights reserved.
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.
46 Copyright © 2003 M. E. Kabay. All rights reserved.
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.
47 Copyright © 2003 M. E. Kabay. All rights reserved.
DISCUSSION