The key concepts of software maintenance both parallel and extend concepts from software development. Similar to software development, software maintenance is concerned with requirements, design, coding, testing, delivery, and the ongoing project management concerns: resource allocation, configuration management, and quality assurance. However, all of these concerns are within a context of a system that is already in operation. There is an element of building in place: making changes without adversely affecting what is already there. Clearly, building in place requires careful planning and execution around a well-defined and logical process.
Software maintenance revolves around the maintenance request (MR). Unlike the change request (CR) in software development, which results in modifications to the major project artifacts, the MR is the driving project artifact. An initiation of an MR is what starts the process of evaluation, change, and approval: determining what the requirements of the change are, designing and implementing the change, and testing and approving the change to be accepted into a new version of the system. In software maintenance, the project artifacts are created to satisfy the MR. Since the MR and its resolution process is so important in the maintenance phase of the system lifecycle, the process should be documented clearly.
Although the initiation of MRs drive all successive activities in the maintenance process, every activity in the software maintenance phase, including the handling of MRs is listed in the software maintenance plan. Just as the software development plan describes the rationale behind the project management in a development project, the maintenance plan details how activities should be managed in a maintenance effort. The MRs address the technical issues of a change, but the maintenance plan addresses all of the other real-world organizational issues: what is and is not going to be maintained, who will be performing maintenance, how maintenance will be conducted, where the maintenance will be performed. In addition, it details the resource allocation: budget, cost, schedule, and staffing. In essence, the maintenance plan describes how the manager and team will conduct and control the maintenance effort.
A key concept that pervades the maintenance effort is configuration management. Configuration management has three major aspects: configuration identification, change control, and status accounting and auditing. Change control is the element of configuration management that allows the system to evolve in a stable manner. Meanwhile, if something happens during evolution and one has to revert back to a previous (stable) version, the historical aspect of change control then becomes more important to help move the system back to a controlled and stable state. Configuration management is the bridge between software development and software maintenance. Software maintenance involves understanding the current system well enough to make changes to the system, whether they be corrections or enhancements and having proper and consistent configuration management during development and into maintenance is invaluable.
The transition from development into maintenance is described in a transition plan. The transition plan addresses how the system will be transferred from the development team to the maintenance team. In addition to the obvious fact that the maintenance team needs to be brought up to speed on the current state of the system, the transition plan describes how the project artifacts, source code, and software development tools will be transferred to the maintenance team. Since so much in the development phase affects what the maintenance team will inherit in in the maintenance phase, one should consider maintenance from the early stages of development where a significant portion of a system’s maintainability is determined.
The software lifecycle should be viewed as a whole. Although they are often treated as separate efforts, software development and software maintenance all lead back to the same system: a system that will always be evolving over time, regardless if it is under development or in maintenance. Unless the system is being retired, change is inevitable and the system will continue to evolve and one needs to be aware of how to manage that change through process, planning, execution, and evaluation.
