STEP 15. SYSTEM MAINTENANCE PLAN
Table of Contents
SYSTEM MAINTENANCE PLAN Instructions
This section should provide a clear structure from which development will transition this software to maintenance. Known issues should be identified
(such as enhancements to be included in future releases) along with any specific system environment setup necessary to run the application. This could involve such items as required DLLs, OCX, and ActiveX components that are necessary for the system to operate as designed. The transition plan should be considered as early as possible in the design and development phase of the new system so that existing and required components necessary to support legacy applications can be identified for compatibility reasons.
This section should provide a plan for developing training for the maintenance staff. This is an essential step that differs from the training provided to the systems end-users. It should be noted that the maintenance staff might not be fully aware of the requirements that were identified as the impetus for the development of the new system. As such, the maintenance staff will not have the understanding of the business requirements that the system addresses. Therefore this training should not only review the systems features, but also the business rules that precipitated its design. In addition, this training should identify the underlying database functionality and any special processing or co-dependencies of the database.
This section should provide an overview of the installation instructions. This should include network installation, database setup and initialization, backup & restore processes, user setup (passwords and so forth), and client setup.
This section will provide a documented overview of the software that was either developed or purchased in support of the application. It should also identify the tools that were used in the development of the system. This would include such items as the version and the names of the software (i.e., Visual Basic 6.0, Visual Interdev X.X). In addition, any enhancements to the development software should be identified. This would include such items as VB Controls, third party products for the generation of graphics or such things as ActiveX components.
The actual software, ready to be loaded into Visual SourceSafe for version control, should accompany this overview document. The maintenance staff will verify that each component to be deployed either on the network or the client’s local machine has been provided and that the date and time stamps coincide. If not, the system will be rejected.
The system maintenance staff would like to generate the executable that is to be used for final testing so that we can track the date and time that the executable was generated. This will be used for final confirmation that what was tested is what is implemented.
This section should provide the maintenance staff with documentation identifying the system design along with the "requirements" document. In addition, documentation should be provided to include an overview of each module/program that has been developed. This will include the name of the program along with its function. This function should identify the module/program purpose along with the data that it uses and outputs that are generated. If appropriate, the program should also identify if it is a called function. It would also be advantageous to include a structure chart identifying each of the overall processes included in the application. For example:
This section should identify all COTS application that was purchased in support of this application. A document should be provided identifying each COTS package and its use in the system.
The Maintenance staff should also be provided a detailed database design showing the interdependencies of the tables along with both the foreign and primary keys identified. A data flow diagram should also be included in the documentation. In addition, each table should be identified as to its usage along with each field defined not only for its data type but its usage. As necessary, a document outlining the various database views, stored procedures and triggers should be provided.
This section should provide a plan identifying how the new system will integrate with existing applications. This should be tested well in advance of the actual production implementation and should be conducted in an isolated lab. Upon completion of this integration testing, both AIM and maintenance will approve the process.