Download presentation
Presentation is loading. Please wait.
Published byPhilomena Naomi Craig Modified over 8 years ago
1
Chapter 8: Maintenance and Software Evolution Ronald J. Leach Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 1
2
Software Maintenance Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 2
3
Hardware and software maintenance are different Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 3 Typical “bathtub curve for hardware failures
4
Software must be maintained 1.Hardware platforms change or become obsolete. 2.Operating systems change or become obsolete. 3.Compilers change or become obsolete. 4.Language standards change or become obsolete. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 4
5
Software must be maintained 5.Communications standards change or become obsolete. 6.Graphical user interfaces change or become obsolete. 7.Related applications software packages change or become obsolete. 8.Relationships with developers of other applications or systems software change. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 5
6
Software must be maintained 9.Software defects noted by customers must be corrected. 10.Customers demand new features. 11.Software needs upgrades to be competitive with new competition. 12.Existing software errors must be prevented from occurring in new releases of the software. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015
7
How to Read Requirements, Design, and Source Code Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 7
8
Old adage: If the source code and any of the requirements, design, or documentation do not agree, they’re all wrong Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 8
9
Suggestions Look for similar cases Look at the IDE or CASE tool where the software was created Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 9
10
Corrective Maintenance Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 10
11
Corrective Maintenance Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 11 Observation that a problem exists. Documentation of the problem. Determination of importance. Prioritizing problems in order of importance. Determining which problems will not be repaired, due to insufficient resources. Solution of the problem.
12
Corrective Maintenance Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 12 Testing the system to see if the fix to this problem causes any other faults. Documenting the solution in source code. Documenting changes have been made to the original system design. Updating a database of information about software errors.
13
Fred Brooks ’ View ”…as a consequence of the introduction of new bugs, program maintenance requires far more system testing per statement written than any other programming. “ (“The Mythical Man Month”) Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 13
14
Fred Brooks ’ View, cont. ”Theoretically, after each fix, one must run the entire batch of test cases previously run against the system, to ensure that it has not been damaged in an obscure way. In practice, such regression testing must indeed approximate this theoretical idea, and it is very costly." (The Mythical Man Month”) Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 14
15
Adaptive Maintenance Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 15
16
Need to respond to changes In technology In the marketplace Even worse if the technology is disruptive Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 16
17
Software Evolution Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 17
18
Software Evolution Some software is so long-lived that its maintenance changes are best described as “evolution.” Especially true for rapidly changing technology environments Even true for COTS products and large-scale components Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 18
19
Buy vs. Build vs. Reuse vs. Reengineer Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 19
20
Always the decision to be made Factors include: – Total life cycle costs to date (presumed known) – Total life cycle costs expected in the future (only meaningful if the cost models used have been reasonably accurate – Technology assessment predictions Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 20
21
Always the decision to be made Factors include: – Total life cycle costs to date – Expected costs to buy – Expected costs to reuse – Expected costs to reengineer – Balancing the decision against the commitment of resources that could be used elsewhere Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 21
22
Typical cost allocation for short- lived software systems with minimal maintenance Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 22
23
Typical cost allocation for short- lived software systems with some maintenance Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 23
24
Typical cost allocation for short- lived COTS-based software systems with minimal maintenance Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 24
25
Typical cost allocation for COTS- based software systems that have to be replaced every few years Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 25
26
Suggestions Collect data on how projects spend money. Map this data over time to get a graphical image of how costs increased when new releases of COTS products occurred and had to be incorporated into a system. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 26
27
Suggestions, cont. Keep data on how much up-front systems analysis and COTS evaluation costs and how long they take. Consider the use of some less-expensive, junior-level personnel as part of the COTS evaluation team, at least for the second or third iteration of the COTS-based system. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 27
28
Suggestions, cont. Plan to reduce the number of senior-level people kept on long-term projects, by phasing in some of the more junior personnel. You’ll probably have to do it anyway, because talented people want professional growth! Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 28
29
Suggestions, cont. Make sure there are at least a few domain experts and senior software engineers always available, even if you have to pay more. Consultants may be of assistance in filling some portion, but not all, of this role. Learn from your mistakes! Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 29
30
Agile Development Case Study: Maintenance and Evolution Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 30
31
The nature of agile development Rapid development of well-tested software in cooperation with a “customer.” It is highly unlikely that any significant portion of the agile development team will be around the organization during maintenance. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 31
32
Agile development and maintenace Few agile developers work on software maintenance Maintenance requires considerable effort understanding programs before systems can be maintained. Little reliable data on the cost of maintaining agile systems. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 32
33
An opportunity Software developed using agile processes is often created faster than faster than similar projects using other methods. Are the agile projects “better?” Are total life cycle costs lower, higher, or the same? How can we tell what’s best for our organization? Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 33
34
The solution Use maintenance information to analyze quality and other metrics on different types of software development processes. The goal is process improvement. NOTE: this analysis of maintenance data is not part of an agile process, but it is part of software engineering! Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 34
35
Maintenance of the Major Continuing Software Development Project Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 35
36
Maintenance occurs after delivery What happens next in a software engineering course after the semester is over? New features Improved design Increased security … Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 36
37
Suggested new features Migrate to a new operating system Move to a new platform Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 37
38
Suggested new design Move to a Macintosh Move to a Linux or UNIX system Move some data to a tablet or smart phone Improve visualization Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 38
39
Improve security Always! Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 39
40
An opportunity The major continuing software development project used a particular software development process, perhaps different ones for different teams using other methods. How can we tell what worked best? Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 40
41
The solution Use maintenance information to analyze quality and other metrics on different types of software development processes. The goal is process improvement. NOTE: this analysis of maintenance data is a critical part of software engineering! Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 41
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.