Maintenance: Who, Why, Where, When and How?
Donald J. Reifer
There are commonly accepted answers to the questions about who performs software maintenance, why, where, when and how. Table 1 provides some insight into both the perceived and real answers. The purpose of the table is to help debunk some of the misperceptions about software maintenance that have been popularized in the literature that we have found to be incorrect.
Table 1. Who Does Maintenance, Why, Where, When and How?
Table 1 is an eye-opener to many readers. For example, our research team found that many staffed their maintenance teams with senior engineers because these people were the only ones who could address the older technologies (languages, design concepts, etc.) used in such applications. It is important to appreciate that a mix of experience and skills is needed for maintenance as newer people bring skills that are needed to deal with the newer technologies. Another misperception was that most of the maintenance work was out-sourced. While true for commercial projects, we found that government shops were in-sourcing maintenance work because they could do it cheaply. Based on such realities, the Table confirms that maintenance considerations should dominate during development because updating the software is often a harder job than generating it in the first place. Let us look at what some of these considerations should be prior to, during transition to and after turnover to maintenance.
As Part of Development
Planning for transition from software development to maintenance1 and architecting for maintainability2 are two of the steps that can make the job of software maintenance easier. Unfortunately, shortcuts are often taken and these steps are not completed in many organizations. The net result is that products that are being transitioned to software maintenance are very difficult to modify and improve. Many have to be reengineered because of these shortfalls.
Planning for transition is needed so that the maintenance shop can get ready when the product transitions from development and is turned over to maintenance. The key consideration is determining if the product satisfies its requirements, is stable and ready to be transitioned to maintenance. Some form of readiness review is often held to make this determination. In more mature shops, a transition checklist is also developed to identify the criteria which will be used to make this assessment. For example, products may be transferred to maintenance without the tests and test cases needed to revalidate them once they are operational. Needless to say, many organizations need to form a working group to develop these criteria and agree on the checklist.
As Table 1 also highlights, facilities are often different as are the teams performing the work. Planning enables the software maintenance shop to acquire the resources it needs to address future program updates, get ready to make fixes and handle needed performance issues in a timely manner especially when people, tools and equipment do not transition from the development organization to maintenance. It also enables the organization to tailor its existing process infrastructure to address the requirements of the release. For example, the release may have to be distributed to multiple geographically separated sites each configured slightly differently to account for variations in equipment, software and operating environments. Procedures therefore are needed to configure, tailor and baseline the resulting versions of the release before they are distributed to customer sites.
Why differences exist in tooling, equipment and facilities is a common question. The reasons are simple. Specialized tools that they rely on have been generated by developers over time and commercial packages for which the organization holds licenses may have to be retained because of intellectual property concerns. In addition, developers may simulate/emulate new equipment as it is being developed or acquired in parallel until it is available for use in the field. In contrast, the equipment and facilities used for software maintenance often mimic that used operationally in order for testing to be as realistic as possible especially when actual user representatives are present to run the tests. It is interesting to note that requirements and design concerns seem to drive much of the work accomplished during software development. Software maintenance differs in that testing is the driving force behind the majority of work performed during this life cycle phase.
Planning also enables the maintenance shop to acquire staff resources with the skills, knowledge and abilities to update and fix the software. Organizations cannot assume that key staff will transition along with the system to keep it operational. Most development shops retain their key personnel because their talents may be in short supply. Even if they did move with the system, they might have the wrong skill set for the job. For example, they may be skilled in object-oriented design when the need is for machine level programmers because issues with drivers or bios may have arisen as changes were being made to the applications code.
As the product nears completion, it is typically transitioned to maintenance. Unfortunately, sometimes such a transition consists of throwing the code over the wall and saying "the software is yours, good luck." This is particularly true when planning for transition and turnover from development to maintenance is either done poorly or not at all. Such a transition frequently occurs when schedule pressures force delivery of products that are not quite ready for prime time. Even worse, the code that is delivered is provided without a list of open items and issues that need to be resolved. Proper planning would help mitigate these problems.
When planned properly, considerable effort may be expended to determine whether or not the software product is ready for transition. This starts with some form of readiness review where the criteria and checklists developed by the working group to determine whether agreements about what constitutes acceptable transition are assessed and adjudicated. Such checklists often focus on product considerations like the following:
- Have all functional and performance requirements been satisfied?
- Does the product work as intended in its operational environment?
- Has the documentation agreed-upon been furnished in its desired form?
- Have all high priority defects been fixed and has an open problem list been furnished with the deliverable?
- Have functional, physical and requirements baselines been created for the configurations?
- Has a configuration index containing a listing of all components in the deliverable (e.g., a bill of materials) been furnished along with "make" and "configure" instructions?
- Has a list of open problems and/or issues that need to be resolved been provided?
Unfortunately, as the list of questions infers, many organizations often do not include test products on their transition checklist. Because testing can consume as much as sixty to seventy percent of the maintenance effort, this oversight often causes a lot of unnecessary extra effort. Because the tests needed to revalidate the software are not provided, the maintenance team more often than not has to reinvent them. A better approach would be to ensure that a regression test baseline is included on the checklist and that those tests and test cases needed to address it are delivered during the transition period. There will be a lot to say about testing in later Chapters because this is an area where improvement is often needed.
Often, organizations realize that their software products were delivered prematurely during the first year of maintenance. It is not hard to figure out why. Development shops often practice what I call the exhaustive rule of software, i.e., they test their products until either their budgets or people are exhausted and then deliver the package to the maintainers to fix. It is far easier for most developers to deliver a marginal product then face management’s wrath for delivering late or over budget. The consequences of failure just do not seem that extreme.
In response, maintenance organizations assume that the product will be unstable and need an undue amount of attention during its first year operation. The more experienced shops plan for this and alert their support staff that they may need to provide more user support and training than the norm. They then generate frequent patch releases as they get the software working to satisfy user expectations which often translate to "at the least the capability that existed in the last release." They address the critical problems first and put those that can wait on the backlog. They focus on performance issues (too slow, too much overhead, etc.) because that is the area where many of the problems that users complain reside.
As already mentioned, the lack of tools, equipment and facility often makes maintenance difficult to accomplish at turnover. So does the lack of people with the skills needed to perform maintenance actions. These shortages happen in even the most well-endowed maintenance shops. Then, as shortcuts taken during development become apparent, actions taken to correct problems are hampered by lack of support from the development shop. This should not be surprising because as development projects shut down, people are reassigned and become unavailable. As a consequence, questions remain unanswered as the maintenance team attempts to reach some form of closure as users exert pressure to move on with the fixes.
1Kroll, P. and Kruchten, P., Rational Unified Process Made Easy, Addison-Wesley, 2003.
2NASA, Public Lessons Learned 0838.
Certain names and logos on this page and others may constitute trademarks, servicemarks, or tradenames of
Taylor & Francis LLC. Copyright © 20082012 Taylor & Francis LLC. All rights reserved.