Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and...
-
Upload
shannon-sparks -
Category
Documents
-
view
224 -
download
1
Transcript of Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and...
Chapter 2: Software Maintenance
Omar Meqdadi
SE 3860 Lecture 2
Department of Computer Science and Software Engineering University of Wisconsin-Platteville
2
Topic Covered
System Types Software Change Strategies Maintenance Team Maintenance Problems Maintenance Cost
3
Software Changes
Software change is unavoidable New requirements emerge when the software is used The business environment changes Errors must be repaired New equipment must be accommodated The performance or reliability may have to be improved
A key problem for organisations is implementing and managing change to their legacy systems
4
Software Change Strategies
Software Maintenance Changes are made in response to changed requirements but the
fundamental software structure is stable Maintenance does not normally involve major changes to the
system’s architecture
Software Re-engineering No new functionality is added to the system but it is restructured and
reorganised to facilitate future changes
Architectural Transformation The architecture of the system is modified generally from a
centralised architecture to a distributed architecture
These strategies may be applied separately or together
Program evolution dynamics: the empirical study of the process of system changes
After major empirical studies: Lehman and Belady proposed that there were a number of
‘laws’ which applied to all systems as they evolved There are sensible observations rather than laws. They are applicable to large systems developed by large
organisations. Perhaps less applicable in other cases
Program Evolution Dynamics
6
Lehman’s System Types
S-system: formally defined, derivable from a specification Matrix manipulation
P-system: requirements based on approximate solution to a problem, but real-world remains stable Games (e.g., Chess) program
E-system: embedded in the real world and changes as the world does Software to predict how economy functions (but economy
is not completely understood)
7
Changes During the System Life Cycle
S-system: un-changed P-system: incremental change
An approximate solution Changes as discrepancies and omissions are identified
E-system: constant change
Examples of Change During Software Development
Activity from which Initial change results Artifacts requiring consequent change
Requirement analysis Requirement specification
System design Architectural design specificationTechnical design specification
Program design Program design specification
Program implementation Program codeProgram documentation
Unit testing Test plansTest scripts
System testing Test plansTest scripts
System delivery User documentationOperator documentationSystem guideProgrammer’s guideTraining classes
Lehman’s Laws
Law Description
Continuing change A program that is used in a real-world environment necessarilymust change or become progressively less useful in thatenvironment.
Increasing complexity As an evolving program changes, its structure tends to becomemore complex. Extra resources must be devoted to preservingand simplifying the structure.
Large program evolution Program evolution is a self-regulating process. Systemattributes such as size, time between releases and the number ofreported errors is approximately invariant for each systemrelease.
Organisational stability Over a programΥs lifetime, its rate of development isapproximately constant and independent of the resourcesdevoted to system development.
Conservation offamiliarity
Over the lifetime of a system, the incremental change in eachrelease is approximately constant.
Continuing growth The functionality offered by systems has to continually increaseto maintain user satisfaction.
Declining quality The quality of systems will appear to be declining unless theyare adapted to changes in their operational environment.
Feedback system Evolution processes incorporate multi-agent, multi-loopfeedback systems and you have to treat them as feedbacksystems to achieve significant product improvement.
Is the cost of maintenance too high?
Is the system reliability unacceptable?
Can the system no longer adapt to further change, and within a reasonable amount of time?
Is system performance still beyond prescribed constraints?
Are system functions of limited usefulness?
Can other systems do the same job better, faster or cheaper?
Is the cost of maintaining the hardware great enough to justify replacing it with cheaper, newer hardware?
System Maintenance vs. Decline
Separate maintenance team May be more objective May find it easier to distinguish how a system should work
from how it does work Part of development team
Will build the system in a way that makes maintenance easier
Problem: May feel over confident, and ignore the documentation to
help maintenance effort
Who Performs Maintenance
Novice Expert
Language expertise Domain expertise Comprehension strategies expertise The specific program expertise
Skills of The Maintainer
Information Needs
Domain expert’s view Concepts of the domain and their relations Scope and boundaries of the program Goals of the program
User’s view Constraints
Size Timing
Operations of the program Installation
Information Needs
Programmer’s view Dependency graph Program parts (classes, functions) and their dependencies
(call, use inheritance) Algorithms: How are the goals accomplished? Representations: How are entities and relations of the
domain reflected in the program? Resource allocation: Memory size, timing
Information Sources
Programmer’s knowledge Code Documentation Colleagues on the project
Program Comprehension: Understanding the system Traceability: Locating information in system documentation Perform the required changes
Extending existing functions to accommodate new or changing requirements
Adding new functions to the system Finding the source of system failures or problems Locating and correcting faults Restructuring design and code components Rewriting design and code components Deleting design and code components that are no longer useful
Maintenance Team Responsibilities
Keeping system documentation up-to-date
Answering questions about the way the modified system works
Maintenance Team Responsibilities
Staff Problems Limited understanding (47% of effort is spent on
understanding) Management priorities: rushing a new product to the
market Morale: “second-hand” status accorded to maintenance
team Technical Problems
Artifacts and paradigms (e.g., legacy, non-OO) Testing difficulties (some systems must be available
around a clock)
Maintenance Problems
Unstructured code Insufficient knowledge about system and domain Insufficient documentation Bad image of maintenance department
Causes of Maintenance Problems
Usually greater than development costs Affected by both technical and non-technical
factors Increases as software is maintained.
Maintenance corrupts the software structure so makes further maintenance more difficult.
Ageing software can have high support costs (e.g. old languages, compilers etc.)
Maintenance Costs
Development/Maintenance Costs
Parikh and Zvegintzov (1983) Development time: 2 years Maintenance time: 5 to 6 years
Fjedstad and Hamlen (1979) 39% of effort in development 61% of effort in maintenance
80-20 rule 20% of effort in development 80% of effort in maintenance
Development/Maintenance Costs
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
Maintenance Cost Factors
Application type System novelty Turnover and maintenance staff ability System life span Dependence on a changing environment Hardware characteristics Design quality Code quality Documentation quality Testing quality
Factors Affecting Maintenance Effort