IBM Systems Magazine, Power Systems - IBM i digital edition, February 2009 - 36

Tips & Techniques Software maintenance is harder than software development, but it’s critical to business success. 6Ydei eg^cX^eaZh [dg YViVWVhZ YZh^\c X]Vc\Zh# Adding fields to tables or moving them to different places in the information hierarchy may be done haphazardly, regardless of long-term impact and maintainability. This list isn’t meant to be comprehensive, but it does catalog a significant portion of what goes wrong with software in the long term. Looking for the larger meaning, we could say these problems arise due to lack of management focus or awareness and are often exacerbated by turnover. But it doesn’t have to be this way. Visionary management can implement processes that deal with these issues and incorporate them into the organization’s IT DNA over the long haul. While it’s possible, it’s not often practiced. Unlike software specification and development, by the admission of the leading software-maintenance researchers in the world, there’s no theoretical foundation for software maintenance. It’s a practice to be managed and improved, not a science. hotshot developers who just wanted to design new code? Chances are, they also shaped your software processes—and they did it for new development rather than maintenance. Programming for new development is very different from programming for maintenance. I encourage you to try some of these tips to improve your maintenance operation. GZdg^Zci i]Z hdjgXZ"bdY^[ ^XVi^dc egdXZhh# In new development, programmers create whole new blocks of source code. Reviews can be conducted easily by reviewing whole source members. In maintenance, however, one statement may be changed here, one over there, one added, one deleted, all over the place. All of these changes have to work together and, to review them well, you must see them together. New-development reviews add value by using multiple minds to ensure developers have covered requirements and caught mistakes. Maintenance has the additional mental burden of needing to apply system knowledge. You could easily make the argument that reviews are even more important in maintenance work. To keep the overhead of this task down, it’s important to systematize the preparation and execution. Maintenance work also carries the risk of introducing isolated, poorly thought-out changes. In conjunction with a change-management system or other tools, it’s important to review all changes being promoted from development by using some form of source-compare tool. Maintainers often try multiple candidate solutions before arriving at the one that works. It’s very easy for discarded changes to get left in the code and end up in production. Reviewing the changes being promoted is a critical step. IgVX`hdjgXZ# Through a change-management system and standardized practices, you should be able to maintain a history of changes to all source code and track it back to the original requirements and projects. A good change-management system should provide you with an inventory of all previous versions along with a facility to show the differences. Research has shown that understanding a program’s evolution is a significant benefit to program comprehension for maintainers. You should also implement a standardized tracking system that ties project features to code. This typically involves placing feature numbers into the source code in the form of comments by every change. >ckdakZhZc^dgYZkZadeZgh^cZc]VcXZbZciheZX^[^XVi^dch# Finding the maximum value of enhancements to existing Program Comprehension According to the Software Engineering Body of Knowledge (http://swebok.org/swebokcontents.html), “research indicates that some 40 percent to 60 percent of the maintenance effort is devoted to understanding the software to be modified.” If you consider the related belief that maintenance consumes 70 percent to 90 percent of the lifetime costs of software, you might conclude that understanding the software to be modified is the single most costly task in the life of a software application. The branch of software engineering devoted to this topic is known as program comprehension. Program comprehension takes two forms in assisting software maintainers: first, providing analysis of run-time information, and second, providing analysis of source code and other available artifacts. Relative to other languages, RPG has historically been pretty short on tools to aid this process. Program comprehension can significantly reduce the time maintainers spend analyzing code for changes or defects and improve the quality of their modifications. As staffs face turnover or cutbacks, and more unfamiliar hands grapple with large or complex programs, a good program-comprehension tool may be one of the wisest investments an RPG shop can make. Programming for Improved Maintenance But there’s another important improvement that can be made with little expenditure—some fresh thinking. Remember those 36 FEBRUARY 2009 ibmsystemsmag.com/ibmi

http://swebok.org/swebokcontents.html http://www.ibmsystemsmag.com/ibmi

IBM Systems Magazine, Power Systems - IBM i digital edition, February 2009

Table of Contents for the Digital Edition of IBM Systems Magazine, Power Systems - IBM i digital edition, February 2009