chapter 2: software maintenance omar meqdadi se 3860 lecture 2 department of computer science and...
TRANSCRIPT
![Page 1: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/1.jpg)
Chapter 2: Software Maintenance
Omar Meqdadi
SE 3860 Lecture 2
Department of Computer Science and Software Engineering University of Wisconsin-Platteville
![Page 2: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/2.jpg)
2
Topic Covered
System Types Software Change Strategies Maintenance Team Maintenance Problems Maintenance Cost
![Page 3: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/3.jpg)
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
![Page 4: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/4.jpg)
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
![Page 5: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/5.jpg)
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
![Page 6: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/6.jpg)
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)
![Page 7: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/7.jpg)
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
![Page 8: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/8.jpg)
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
![Page 9: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/9.jpg)
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.
![Page 10: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/10.jpg)
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
![Page 11: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/11.jpg)
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
![Page 12: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/12.jpg)
Novice Expert
Language expertise Domain expertise Comprehension strategies expertise The specific program expertise
Skills of The Maintainer
![Page 13: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/13.jpg)
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
![Page 14: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/14.jpg)
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
![Page 15: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/15.jpg)
Information Sources
Programmer’s knowledge Code Documentation Colleagues on the project
![Page 16: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/16.jpg)
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
![Page 17: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/17.jpg)
Keeping system documentation up-to-date
Answering questions about the way the modified system works
Maintenance Team Responsibilities
![Page 18: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/18.jpg)
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
![Page 19: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/19.jpg)
Unstructured code Insufficient knowledge about system and domain Insufficient documentation Bad image of maintenance department
Causes of Maintenance Problems
![Page 20: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/20.jpg)
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
![Page 21: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/21.jpg)
Development/Maintenance Costs
![Page 22: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/22.jpg)
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
![Page 23: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/23.jpg)
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
![Page 24: Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville](https://reader035.vdocument.in/reader035/viewer/2022062301/5697bff81a28abf838cbf313/html5/thumbnails/24.jpg)
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