Chapter 11 Maintaining the System System evolution Legacy systems Software rejuvenation

Software maintenance  Maintenance: any work done to change the system after it is in operation Software does not degrade or require periodic maintenance like hardware However, software is continually evolving  Maintenance process can be difficult

Discussion question  If we build the system right in the first place, will it need to be maintained?

Maintenance is inevitable 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

Characterizing systems  Lehman’s system types (1980) S-system: formally defined, derivable from a specification. P-system: requirements based on approximate solution to a problem, but real-world remains stable. E-system: embedded in the real world and changes as the world does.

Maintenance effort  Typical systems (1983) Development time: 2 years Maintenance time: 5 to 6 years  Effort (1979) 39% of effort in development 61% of effort in maintenance  rule 20% of effort in development 80% of effort in maintenance

Software evolution vs. retirement  When is it time to let an aging system retire?

Maintenance versus retirement  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?

Legacy system  An application program which continues to be used because of the cost of replacing or redesigning it. The implication is that the system is large, monolithic and difficult to modify. If legacy software only runs on antiquated hardware the cost of maintaining the hardware may eventually outweigh the cost of replacing both the software and hardware unless some form of emulation or backward compatibility allows the software to run on new hardware.

Types of maintenance  Corrective: reactive modification of a software product performed after delivery. Correcting problems  Adaptive: modifications to keep software usable in a changing environment (hardware, peripherals, etc. Adapting to new enviroments  Perfective: to better meet the needs and desires of customers. Adding new features, changing interfaces, etc. Redesign  Preventive: modification to detect and correct latent faults in the software before they become effective faults Adding additional internal checks

Multiple-choice  A credit card company upgrades its system for handling credit card payments, and this requires a slight change to the type of data that the e-commerce program needs to send to it.  What type of maintenance is required? A.Corrective B.Adaptive C.Perfective D.Preventive

Multiple-choice  The customer has stated that the e-commerce program should be able to allow additional credit card companies should the business decide to make them available to shoppers in the future. However, the maintenance team realizes that the way the system handles credit card payments will not scale up if more credit card options are made available in the future.  What type of maintenance is required? A.Corrective B.Adaptive C.Perfective D.Preventive

Multiple-choice  An additional product line is added for customers to the e-commerce site.  What type of maintenance is required? A.Corrective B.Adaptive C.Perfective D.Preventive

Multiple-choice  When confirmation receipts are ed to customers following purchase, if the customer's name exceeds a certain length, then the does not get sent.  Note: This situation does not occur very frequently (at most, once a week)  What type of maintenance is required? A.Corrective B.Adaptive C.Perfective D.Preventive

Types of maintenance

Who Performs the Maintenance?  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 May feel over-confident, and ignore the documentation to help maintenance effort

Maintenance is hard  Interact with developers, customers, and users  Understand the big picture  47% of effort devoted to understanding the software  Good debugging skills  Good testing skills

Maintenance Problems  Staff problems Limited understanding Morale  Technical problems Artifacts and paradigms Testing difficulties

Modeling Maintenance Effort  M = p + K c-d M : total maintenance effort p : productive (development) effort C : complexity d : degree of familiarity K : empirical constant

Measuring complexity is difficult  Cyclomatic number (McCabe, 1976) Metric for the structural complexity of the source code

Cyclomatic Number  Linearly independent path = e - n + 2 e: edges, n : nodes

Software Rejuvenation  Tries to increase the overall quality of an existing system Re-documentation: static analysis adds more information Restructuring: transform to improve code structure Reverse engineering: recreate design and specification information from the code Reengineering: reverse engineer and then make changes to specification and design to complete the logical model; then generate new system from revised specification and design

Software Rejuvenation  Software rejuvenation is a proactive fault management technique aimed at cleaning up the system internal state to prevent the occurrence of more severe crash failures in the future. Reboot system