The maintenance group has to play a much larger role then the development team because change require an intimate knowledge of the entire architecture and the necessary interface between different modules of the system, says, Dr R Srinivasan

CONTINUING Our discussion on maintenance, the more difficult a program is to understand, the more difficult it will be to maintain. If there no uniform standard across the team in writing the code and also if the system is not based on good software architecture, the cost to maintain will become high. The total software cost incurred from the time of system creation, maintenance and retirement is called the "Life Cycle Cost". The decision to maintain, reengineer/rebuild or replace is normally based on the comparison of life cycle costs for the old, reengineered and new systems. This is typically true in the case of legacy systems, which have to be evaluated according to the present day technologies available and their business needs meeting the cost versus performance.

Shari Pfleeger raises nine questions before deciding to discard the old systems or to adapt to the latest technologies The questions are: is the cost of maintenance too high, is the system reliability unacceptable, can the system no longer adapt to further changes within a reasonable amount of time, is the system still beyond further constraints, are the system functions of limited usefulness, can other systems do same job better, faster and cheaper, and is the cost of maintaining the hardware high to justify it with cheaper and newer hardware?

The question normally faced by many is - who performs the maintenance? It happens that the team that has been responsible for development will not be able to perform maintenance once the system becomes operational. Often a separate maintenance team is formed and after handing over the necessary know-how and body of knowledge, this team takes charge and ensures that the system runs properly. This kind of arrangement has both positive and negative aspects. The team involved in development will be more familiar with the system architecture, design, coding and the system's key functions. But they have to keep in mind that a separate team may be involved in maintenance and so should keep all the documents in a way to be understood easily. If this is not done, it may result in the need for deploying more people or resources to tackle a problem when it occurs. Looking at the positive side of having a separate maintenance team, a fresh new team, comprising analysts, programmers, designers (sometimes including one or two members of the development team), may be more objective. We have already article that maintenance does not mean just fixing the problems.

The maintenance team of today will face more challenges than the development team. Pfleeger says that when we develop systems, our main focus is in producing the code that implements the requirements and works as per the plan. At each stage the developers continuously refer to the work produces at the earlier stage, the characteristic of software life cycle development. In short, development simply involves looking back in in a careful and controlled manner. On the other hand, the maintenance group not only looks back at the developed product for periodic maintenance, but also keeps a watch on the present by establishing a working relationship with users and operated regarding their satisfaction level of the product. The team should also look forward to anticipate things that might go wrong and also to consider functional changes as per the new requirements of the user as dictated by the market. Thus maintenance has a broader scope with more to track and control, because changes require an intimate knowledge of the entire architecture, the code structure and interfaces between different modules of the system. Thus the maintenance group has to play a much larger role than the development team.

Of course, it should be remembered that maintenance processes vary considerably depending on the types of software being maintained, the development process used in an organisation and the people involved in the process. The traditional software life cycle exhibits maintenance to start after software is deployed. This is not strictly true because software maintenance depends on and begins with user requirements. Thus the principal of good software development should also incorporate good maintenance process right from the planning stage of the project. It therefore implies that to lower the maintenance cost, we have to build quality aspects from the very start itself. As Pfleeger says, "Trying to force good design and structure into an already built system is not as successful as building the system correctly in the first place".

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