Chapter 8: Maintenance and Software Evolution Ronald J. Leach Copyright Ronald J. Leach, 1997, 2009, 2014,

Software Maintenance Copyright Ronald J. Leach, 1997, 2009, 2014,

Hardware and software maintenance are different Copyright Ronald J. Leach, 1997, 2009, 2014, Typical “bathtub curve for hardware failures

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,

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,

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

How to Read Requirements, Design, and Source Code Copyright Ronald J. Leach, 1997, 2009, 2014,

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,

Suggestions Look for similar cases Look at the IDE or CASE tool where the software was created Copyright Ronald J. Leach, 1997, 2009, 2014,

Corrective Maintenance Copyright Ronald J. Leach, 1997, 2009, 2014,

Corrective Maintenance Copyright Ronald J. Leach, 1997, 2009, 2014, 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.

Corrective Maintenance Copyright Ronald J. Leach, 1997, 2009, 2014, 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.

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,

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,

Adaptive Maintenance Copyright Ronald J. Leach, 1997, 2009, 2014,

Need to respond to changes In technology In the marketplace Even worse if the technology is disruptive Copyright Ronald J. Leach, 1997, 2009, 2014,

Software Evolution Copyright Ronald J. Leach, 1997, 2009, 2014,

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,

Buy vs. Build vs. Reuse vs. Reengineer Copyright Ronald J. Leach, 1997, 2009, 2014,

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,

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,

Typical cost allocation for short- lived software systems with minimal maintenance Copyright Ronald J. Leach, 1997, 2009, 2014,

Typical cost allocation for short- lived software systems with some maintenance Copyright Ronald J. Leach, 1997, 2009, 2014,

Typical cost allocation for short- lived COTS-based software systems with minimal maintenance Copyright Ronald J. Leach, 1997, 2009, 2014,

Typical cost allocation for COTS- based software systems that have to be replaced every few years Copyright Ronald J. Leach, 1997, 2009, 2014,

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,

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,

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,

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,

Agile Development Case Study: Maintenance and Evolution Copyright Ronald J. Leach, 1997, 2009, 2014,

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,

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,

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,

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,

Maintenance of the Major Continuing Software Development Project Copyright Ronald J. Leach, 1997, 2009, 2014,

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,

Suggested new features Migrate to a new operating system Move to a new platform Copyright Ronald J. Leach, 1997, 2009, 2014,

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,

Improve security Always! Copyright Ronald J. Leach, 1997, 2009, 2014,

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,

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,