More than half of the problems faced by maintenance people is due to the lack of understanding by the users, believes. Dr R Srinivasan

In this concluding part under maintenance, let us discuss some problems encountered in maintenance. Normally, in the currently running products, any change to be made is taken care of by the maintenance team. Because the systems are already operational, the maintenance team has to balance the need for change with the necessity for keeping a system accessible to users. I.e., the maintenance team has to find a solution without disturbing the users. Shari Lawrence Pfleeger in her book on, 'Software Engineering-Theory & Practice', cites three main problems in maintenance, that is staff problems, technical problems and management priorities. She says that in addition to balancing users needs with software and hardware, the maintenance team deals with the limitations of human understanding. The reason is that it is not always easy to study the documentation done by the developing group, grasp it well and implement the changes demanded by customer.

Parikh & Zvegrintzev, in their Tutorial on Software Maintenance, IEEE Computer Society in 1983, report that 47% of software maintenance effort is devoted to understanding the software to be modified. This will be very true particularly if any change requires checking of the number of interface among the modules. In the proceedings of ESCOM 1994, Gerlich and Denskat in their paper on, 'A cost estimation model for maintenance and high reuse', illustrate that if a system has "K" of them, there are:

k* (m-k) + k* (k-1)/2 interfaces to be evaluated for impact and correctness. So we should note that even a one line change to a system component may involve carrying out many tests to make sure that the change has no direct or indirect effect on another part of the system. Among the problems met with in maintenance, Leintz and Swanson indicate that more than half of the problems faced by V people is due to the lack of understanding by the users and this is where the members of the maintenance team must be flexible and co-operative in communication with the users for successful implementation of the changes asked for.

The productivity of the maintenance team may also be affected by technical problems. If the initial design and logic of the development team will find it almost impossible to handle the proposed changes during maintenance. A flawed or inflexible design may require more time for understanding, changing and testing, leading to inordinate delays which will not be accepted by the customer. Particularly in the case of Object Oriented Design, incremental changes must be made with utmost care because modifications may lead to a long chain of classes which hide others or it may get the objects redefined in conflicting ways. Pfleeger says that, in general design, specifications with low quality programs and documentation account for almost 10 percent of maintenance effort. Management priorities may often supersede the technical reasons. One such case is when there is a rush to get a product to the market soon without taking proper care of good design aspects or quality procedures. The developers or the maintenance team, as the case may be, will get encouraged to implement quick, inelegant and poorly tested changes. The result will be a patched product which will be difficult to understand and repair later.

One important point that should be followed by an organisation is to make sure that the morale of the maintenance team is always kept high. Leintz and Swanson studies indicate that11.9% of problems during maintenance result from low morale and productivity. They attribute the reason for such low morale to the second class status often accorded to the maintenance group. Many-a-times it is observed that the programmers feel that to design and develop a system is more challenging then keep it running. However, as mentioned in my earlier articles, the maintenance group should realise that they handle problems which developers never see. In the words of many software gurus, great skill and perseverance is required to track a problem to its source, in order to understand the intricacies of the system and to effect the necessary changes when called for. In some organisations, it is a practice to rotate among several development and maintenance projects, with a view to avoid the perceived stigma of the maintenance people.

(The author is Chief Technology Officer, Internet Component Management Group, Bangalore and can be contacted at: r.srinivasan@iCMGworld.com)