The Application Maintenance Process

After a system has been developed and implemented, further modifications to that system are usually considered maintenance and should follow the guidelines described below. Even requests which result in new development or programs can sometimes be treated as maintenance requests when the scope of the request is limited.

Whether a request will result in a major or maintenance project is not always apparent at the time a request is made. For that reason, all requests go through an initial review. The initial review is conducted by one or more members of the Enterprise Systems management team. If the management team determines the request constitutes a major project it will be taken through the steps outlined in the chapter Application Development Process.

Maintenance projects are typically assigned to one or two analysts. While these projects follow the same steps as outlined in the development process for major systems, their limited nature does not warrant the management requirements of the larger project methodology. Consequently, a Project Manager is not assigned and the project plan is not detailed in Microsoft project.

To facilitate planning and documentation for maintenance projects, the analyst(s) makes use of the Analyst ADR Summary document. This document serves both as a checklist for the development process as well as a historical record of the project. The areas covered in the ADR summary replicate the same steps used in developing major systems.

Conception

The analyst records the reason for the request in terms of a business case. The narrative should answer the question of "why" the request is being made. In other words, what is the problem that needs to be solved or the opportunity to improve a process?

In most cases, it is necessary for the analyst to consult with the requestor to determine the root cause for the request as the request itself may only contain a desired solution. Upon completion, the analyst should share the narrative with the requestor to ensure that the problem or opportunity was understood and documented correctly.

Plan

The analyst should work with the requestor to develop a solution which can solve the problem stated in the conception step.

The plan narrative briefly describes the proposed solution. Although this section is at a general level, it should be comprehensive, that is, it should describe in general terms all of the new or modified modules, processes, and/or reports being proposed.

Upon completion, the analyst should share the narrative with the requestor to ensure that the solution is viable and correctly addresses the problem or opportunity.

Requirements (Functional Specification)

The analyst(s) should work with the requestor to develop the full set of requirements for the items listed in the plan.

The Functional Specification should be organized by component (module, screen, report, etc.) describing in detail each component's functions and processing flow. This description should not only include the special processes occurring within the module in question, but also their interactions with other processes, both inside and outside the system.

Refer to the Requirements section of the Application Development Process for details on the functional specification.

Upon completion of the requirements, the analyst should share the specification with the requestor to ensure that the specification correctly addresses the problem or opportunity.

Design (Technical Specification)

The Technical Specification encompasses both data and process design specifications. This involves decomposing the system described in the functional specification into its components or modules, describing in detail the logic and processing in each component, including all edit and validation criteria.

Refer to the Design section of the Application Development Process for details on the technical specification.

Upon completion of the design, the analyst should share the specification with the appropriate team leader or supervisor for approval.

Test Plan

Testing is conducted primarily to determine if the programs actually meet the functional requirements and perform without error. The analyst is initially responsible for testing, at least until after the possibility of abnormal terminations has been eliminated, all error conditions have been tested satisfactorily, and all action keys or buttons operate as labeled, and so forth.

The analyst should prepare and document a plan that ensures the programs are performing to the level mentioned above.

End-user testing is strongly encouraged. The analyst should work with the requestor to ensure this type of testing is performed. In most cases, the analyst should have the new software installed in a pre-production environment to support these tests.

Documentation

All programs must have some type of external documentation. At a minimum, online modules require help information and all batch and reporting programs should have job catalog entries.

The analyst should record what documentation will be added or modified as part of the request.

Implementation / Notes

The analyst should record the names of all objects to be moved to production. In addition, any special instructions for the production move (such as moving control data from the development environment) should also be noted.