Learning Objectives:
After studying this chapter, you should be able to:
• Define what is meant by system evolution, and understand how it affects the software development process.
• Define what is meant by a legacy system, and understand how its characteristics affect maintainence.
• Define impact analysis, and understand when, how, and why it is done.
• Describe software rejuvenation, and why it is necessary.
Summary:
Delivery of a system to the customer does not mark the end of the software
developers' involvement with the system. Rather, many systems require continuous change, extending even past delivery. In general, the more closely a system is tied to the real world, the more lik ely it will be to require changes (and the more difficult those changes will be to make). Software maintenance deals with managing change in this part of the life -cycle.
Performing maintenance requires its own set of skills, in addition to those required for software development. Maintainers interact continually with colleagues, customers, and users in order to effectively define problems and find their causes. Maintainers need to be good detectives, testing software thoroughly and hunting down the sources of failure. Maintainers also need to understand the “big picture” of how software systems, with many complex
interactions among their components, interoperate with the environment. Impact analysis, which builds and tracks links among the requirements, des ign, code and test cases, is necessary to evaluate the effects of a change in one component on the rest of the system.
Another important technique is software rejuvenation, which involves the redocumenting, restructuring, reverse engineering and reenginee ring of an existing system. The overall goal is to make hidden information explicit, so that it can be used to improve the design and structure of the code. Although complete rejuvenation is unlikely in the near future, it is being used
successfully in domains that are mature and well-understood, like information technology.
Measuring maintainability is difficult. A true measure of maintainability
requires evaluating the external behavior of a system and tracking the mean time between failures. However, waiting until the system fails is too late to be of much use to developers and maintainers. Instead, internal attributes of the code, such as size and structure, are used to predict those parts of a software system that are likely to fail, based on past history. Static code analyzers are tools that aim to assist in this identification process.
Exercises:
1. The “Millenium Bug” or “Y2K problem” is perhaps the most infamous software maintenance problem. Many computer systems represent the year as only two digits and are expected to have problems in the year 2000, when the value for the new year (“00”) is suddenly less rather than greater than the value for the previous year (“99”). Find a discussion of the Y2K problem written for nonscientists, for example, in a newspaper or popular
magazine. How many of the maintenance problems listed in section 11.3 are
accurately presented in the article? Are there issues in section 11.3 that contribute to the Y2K problem but are not given in the article?
2. The Software Engineering Laboratory (SEL) at NASA's Goddard Space Flight Center collects data from all phases of its software development projects.
When users fill out failure reports, they are asked to indicate the
severity of the defect according to the following scale: major defect with no workaround; major defect, but workaround exists; cosmetic defect. How can this information be used to help the SEL understand its maintenance process better?
3. Maintenance is an area of great interest to software engineering
researchers. Conferences and workshops such as ICSM (the International Conference on Software Maintenance) and WESS (the Workshop on Empirical Studies of Software maintenance) are devoted exclusively to maintenance issues, as is the Journal of Software Maintenance. R eview a recent conference proceedings or journal issue and summarize the types of problems maintenance research addresses.
4. Researchers with the Institute for Information Technology of the National Research Council, Canada, study maintenance by observing th e work
practices of software engineers who are engaged in maintenance projects. A paper by Janice Singer and Timothy Lethbridge summarizes the methods they use to collect this type of data. (J. Singer, T. Lethbridge (1996).
“Methods for Studying Maintenance Activities.” In Proceedings of the International Workshop on Empirical Studies of Software Maintenance,
Monterey, CA. Also available at http://wwwsel.iit.nrc.ca/projects/easse/).
Summarize this paper from the viewpoint of a software maintainer. How disruptive are the data collection methods likely to be to the
maintainer's work practices? What does the maintainer stand to gain by participating in such a study?
5. Revisit the program you wrote for exercise 1, Chapter 7. Change the underlying data structure of the stack to a linked list rather than an array, and the data type of the stack elements to a string rather than an integer. How hard was this to do? On what types of activities did you spend your time? Critique your earlier program in terms of maintenan ce effort, paying attention to ideas such as comments, modularity,
encapsulation, and others that affected the ease or difficulty of this task.
Answer Guidelines:
1. Many of the issues in section 11.3 relate in some way to the Y2K problem.
Some examples: The limits of human understanding are certainly applicable.
There is a definite limit to how quickly maintainers can approach a system that is unfamiliar to them and understand enough about it to make the correct changes for a maintenance problem. That diffic ulty is compounded when the system being maintained is old and the chances of missing
documentation or even source code have increased. Management priorities have been a major contribution to the problem. Since Y2K maintenance does not result in a new product but rather keeps an old product running,
management in many cases did not assign a high priority to maintenance in general and Y2K maintenance in particular. As a result, Y2K was often not a high priority until very close to the year 2000, when the p roblem was no longer avoidable. Morale has been a problem in some cases, in which
software practitioners were assigned part -time to handle the Y2K problem in addition to their other duties. This type of situation tends to reinforce the belief that Y2K mai ntenance is not an important or interesting task.
2. The severity scale helps the SEL understand better how its development process affects maintenance. It gives more information than simply
collecting the number of changes that have to be made during maintenance;
it allows some insight into whether most of the changes that have to be made are mostly small changes or large redesigns.
3. Common categories of software maintenance research include: program
understanding, predicting effort, predicting components like ly to require rework tool support.
4. By understanding the techniques that maintainers find useful in practice, this research hopes to provide a better idea of how software maintainers can benefit from tool support. That is, the point of this research is that tools should be created after the tool developers understand for which tasks maintainers really need support. The methods listed in this paper are at varying levels of intrusiveness; the authors understand that less intrusive means for collecting data wil l be more welcome by maintainers.
By participating in such a study, however, maintainers can expect that tools will be created that better address the requirements of the job they are undertaking.
5. Answers will vary depending on the quality of the original program. The exercise will be more useful if you have forgotten the details of the program since it was written, since then you will have to rely on reading the code, comments, and documentation. This situation is similar to that software maintainers face when working on code they themselves did not originally develop, or developed some time ago. It is hoped that you will find that this exercise to be easy if you have made the code well
documented, straightforward and easy to understand, and modular. Howe ver, some of these factors may be more important than others for your program, and other factors may also be a consideration.