[See the last page for template assistance.]

Maintenance Manual

<Project/Sub-project Title>

<Office/Group>

Prepared for

University Information Technology Services

Babbidge Library, Storrs CT

369 Fairfield Rd, Unit 2209

Storrs, CT 06269-2209

File Name: Document2

Overview

The Maintenance Manual provides maintenance personnel with the information necessary to maintain the system effectively. The manual provides the definition of the software support environment, the roles and responsibilities of maintenance personnel, and the regular activities essential to the support and maintenance of program modules, job streams, and database structures.

In addition to the items identified for inclusion in the Maintenance Manual, additional information may he provided to facilitate the maintenance and modification of the system. Appendices to document various maintenance procedures standards, or other essential information may be added to this document as needed.

TABLE OF CONTENT

1	INTRODUCTION	2

1.1	Purpose	2

1.2	Points of Contact	2

1.3	Project Reference	2

1.4	Glossary	2

2	Application DESCRIPTION	2

2.1	Business Overview	2

2.2	System Application	2

2.3	System Organization	2

2.4	Security	2

2.5	System Requirements Cross-Reference	2

3	Application System Support	2

3.1	Hardware	2

3.2	Software	2

3.3	Database	2

3.4	Networking	2

4	SUPPORT ENVIRONMENT	2

4.1	Equipment Environment	2

4.1.1	Computer Hardware	2

4.1.2	Facilities	2

4.2	Support Software	2

4.3	Database Characteristics	2

4.4	Personnel	2

5	SYSTEM MAINTENANCE PROCEDURES	2

5.1	Conventions	2

5.2	Verification Procedures	2

5.3	Error Conditions	2

5.4	Maintenance Software	2

5.5	Maintenance Procedure	2

5.6	Sanity Test	2

6	SOFTWARE UNIT MAINTENANCE PROCEDURES	2

7	batch processing	2

8	Change Management	2

9	Problem Management	2

10	Business System Monitoring	2

10.1	Monitoring Application via Server Logging Component	2

11	Security	2

12	Backup and Recovery	2

13	Disaster Recovery	2

14	Service Level Agreements	2

15	Contingency	2

15.1	PURPOSE	2

15.2	BACKGROUND	2

15.3	APPLICABILITY	2

15.4	SCOPE	2

15.4.1	Planning Principles	2

15.4.2	Assumptions	2

15.5	REFERENCES/REQUIREMENTS	2

16	CONCEPT OF OPERATIONS	2

16.1	SYSTEM DESCRIPTION AND ARCHITECTURE	2

16.2	LINE OF SUCCESSION	2

16.3	RESPONSIBILITIES	2

16.4	TESTING AND MAINTENANCE	2

16.4.1	Tabletop Testing	2

16.4.2	Technical Testing	2

17	NOTIFICATION AND ACTIVATION PHASE	2

18	RECOVERY OPERATIONS	2

19	RETURN TO NORMAL OPERATIONS	2

19.1	ORIGINAL OR NEW SITE RESTORATION	2

19.2	CONCURRENT PROCESSING	2

19.3	PLAN DEACTIVATION	2

20	implementation signoff	2

INTRODUCTION

This section provides general reference information regarding the Maintenance Manual. Whenever appropriate, additional information may be added to this section.

Purpose

This section describes the purpose of the manual and references the system name and identifying information about the system and its programs.

Points of Contact

This section identifies the organization(s) responsible for system development maintenance, and use. This section also identifies points of contact (and alternate if appropriate) for the system within each organization.

Project Reference

This table provides key contacts regarding <Project/Sub-project Title> issues that may arise.

Issue	Reference Organization	Contact Name
Networking
Database
Application

Glossary

[Provide a glossary with definitions of all terms, abbreviations, and acronyms used in the manual. If the glossary is several pages in length, place it as an appendix.]

Application DESCRIPTION

The Application Description Section gives a detailed description of the application. It is organized into business and technical descriptions:

Business Overview

[Give a short detailed description of the business need for this project.]

System Application

This section provides a brief description of the purpose of the system, the functions it performs, and the business processes that the system is intended to support. If the system is a database or an information system, include a general description of the type of data maintained, and the operational sources and uses of those data.

System Organization

This section provides a brief description of the system structure, major system components, and the functions of each major system component. Charts, diagrams, and graphics should be included as necessary.

Security

This section provides an overview of the system’s security controls and the need for security and protection of sensitive data. For example, include information regarding procedures to log on/off of the system, provisions for the use of special passwords, access verification, and access statuses as appropriate.

System Requirements Cross-Reference

This section contains an exhibit that cross-references the detailed system requirements with the system design document and test plan. This document, also referred to as a traceability matrix in other documents, assists maintenance personnel by tracing how the user requirements developed in the FRD are met in other products of the life cycle. Because this information is provided in the system design document, it may be appropriate to repeat or enhance that information in this section.

Application System Support

[Give as detailed a description as possible of the architecture. Include a diagram of the entire system, front end to middleware to backend and back to the front end.]

Hardware

Server Name	Purpose	Location

Table 1 – Hardware

Software

Server	All Software Residing On This Server

Table 2 – Software

Database

Database Instance Name	DB Type	Version	Server Name/Location

Table 3 - Database

Networking

[Provide a network diagram of the application.]

SUPPORT ENVIRONMENT

This section describes the operating and support environment for the system and program(s). A discussion of the equipment, support software, database characteristics, and personnel requirements for supporting maintenance of the system and its programs should be included.

Equipment Environment

This section describes the equipment support environment including the development, maintenance, and target host computer environments. Telecommunications and facility requirements, should be described, if any.

Computer Hardware

This section discusses the computer configuration on which the software is hosted and its general characteristics. The section should also identify the specific computer equipment required to support software maintenance if that equipment differs from the host computer. For example, if software development and maintenance are performed on a platform that differs from the target host environment, describe both environments. Any miscellaneous computer equipment required in this section, such as hardware probe boards that perform hardware-based monitoring and debugging of software and any telecommunications equipment should be described.

Facilities

This section describes the special facility requirements, if any, for system and program maintenance and includes any telecommunications facilities required to test the software.

Support Software

This section lists all support software - such as operating systems, transaction processing systems, and database management systems (DBMSs) - as well as software used for the maintenance and testing of the system. Include the appropriate version or release numbers, along with their documentation references, with the support software lists.

Database Characteristics

This section contains an overview of the nature and content of each database used by the system.

[Reference other documents for a detailed description, including the system design document as appropriate.]

Personnel

This section describes the special skills required for the maintenance personnel. These skills may include knowledge of specific versions of operating systems, transaction processing systems, high-level languages, screen and display generators, DBMSs, testing tools, and computer-aided system engineering tools.

SYSTEM MAINTENANCE PROCEDURES

This section contains information on the procedures necessary for programmers to maintain the software.

Conventions

This section describes all rules, schemes, and conventions used within the system. Examples of this type of information include the following:

System-wide labeling, tagging, and naming conventions for programs, units, modules, procedures, routines, records, files, and data element fields

Procedures and standards for charts and listings

Standards for including comments in programs to annotate maintenance modifications and changes

Abbreviations and symbols used in charts, listings, and comments sections of programs

If the conventions follow standard programming practices and a standards document, that document may be referenced, provided that it is available to the maintenance team.

Verification Procedures

This section includes requirements and procedures necessary to check the performance of the system following modification or maintenance of the system’s software components. The verification of the system-wide correctness and performance must be addressed.

[Present in detail, system-wide testing procedures. Reference the original development test plan if the testing replicates development testing. Describe the types and source(s) of test data in detail.]

Error Conditions

This section describes all system-wide error conditions that may be encountered within the system, including an explanation of the source(s) of each error and recommended methods to correct each error.

Error Description	Result	Possible Causes

Maintenance Software

This section references any special maintenance software and its supporting documentation used to maintain the system.

Maintenance Procedure

This section describes step-by-step, system-wide maintenance procedures, such as procedures for setting up and sequencing inputs for testing. In addition, present standards for documenting modifications to the system.

Sanity Test

Brief description that tests the application is up and running.

SOFTWARE UNIT MAINTENANCE PROCEDURES

[For each software unit within the system, provide the information requested.] If the information is identical for each of the software units it is not necessary to repeat it. If the information in the areas discussed below is identical to information provided in Section 4, System Maintenance Procedures, then reference that area. This section should contain the following:

Unit Name And Identification — [Provide the name or identification of each software unit that is a component of the system. Repeat the following information for each unit name.]

Description — [Provide a brief narrative description of the software unit. Reference other sections within the life cycle that contains more detailed descriptive material.]

Requirements Cross-Reference — [Include the detailed user requirements satisfied by this particular software unit. It may he a matrix that traces the system requirements from the FRU) through the system design document and test plan for the specific software units. Other life cycle documentation may be referenced as appropriate.]

Conventions — [Describe all rules, schemes, and conventions used within the program. If this information is program-specific, provide that information here. If the conventions are all system-wide, discuss them Section 4. If the conventions follow standard programming practices and a standards document, that document may be referenced here.]

Verification Procedures — [Include the requirements and procedures necessary to check the performance of the program following modification or maintenance and addresses the verification of program correctness, performance and detailed testing procedures. If the testing replicates development testing, it may be appropriate to reference the original development test plan.]

Error Conditions — [Describe all program-specific error conditions that may be encountered provide an explanation of the source(s) of each error, and recommend methods to correct each error. If these error conditions are the same as the system-wide error conditions described in Section 4.3, Error Conditions. that section may be referenced here.]

Listings — [Provide a reference to the location of the program listings.]

batch processing

The following table displays all the batch processes associated with <Project/Sub-project Title>

Batch Name	Description	Filename and Location (Server Name, Directory)	Scheduling Tool Used	Day & Time Batch is Run	Language Written

Table 4 - Batch Processes

Change Management

Who is responsible for managing changes to the application?

Problem Management

Who is responsible for managing problems of the application?

Business System Monitoring

The rest of this section is examples of what should go in here for Business System Monitoring. Just replace with application specific information.

Monitoring Application via Server Logging Component

Server Log Messages

Log messages in <App Server> is a useful way to analyze systems and detect problems, and to track down the source of a fault.

These files are the source for the logging component of <App Server> administration console, they can be examined for possible problems. Among the three types of log files, server log file <App Server> .log is the one examined most.

Each log message in a server log file consists of the values of the attributes described below:

Message Attributes

Timestamp: The time and date when the message originated, in a format that is specific to the locale.

Severity: Indicates the degree of impact or seriousness of the event reported by the message. See the details for Message Severity described below.

Subsystem: This attribute denotes the particular subsystem of <App Server> that was the source of the message. For example, <App Server> API, EJB, RMI, JMS.

Server Name: For this deployment, the server name is <App Server Name> .

Machine Name: The machine which hosts the <App Server> .

Transaction ID: These four attributes identify the origins of the message. Transaction ID is present only for messages logged within the context of a transaction.

User ID: The user from the security context when the message was generated.

Message ID: A unique six-digit identifier. Message IDs through 499999 are reserved for <App Server> system messages.

Message Text: Short Description of the message.

Message Severity:Each <App Server> log messages have an attribute called severity which reflects the importance or potential impact on users of the event or condition reported in the message. Defined severities are described below. Severities are listed in order of severity with Emergency being the highest severity.

Informational: Used for reporting normal operations.

Warning: A suspicious operation or configuration has occurred but it may not have an impact on normal operation.

Error: A user error has occurred. If the subsystem is “<Application> API”, it indicates <Application> application has a serious error, it usually needs human involvement to resolve the problem. Otherwise, the error message is from subsystems of <App Server> , The system or application is able to handle the error with no interruption, and limited degradation, of service.

Notice: A warning message: A suspicious operation or configuration has occurred which may not affect the normal operation of the server.

Critical: A system or service error has occurred. The system is able to recover but there might be a momentary loss, or permanent degradation, of service.

Alert: A particular service is in an unusable state while other parts of the system continue to function. Automatic recovery is not possible; the immediate attention of the administrator is needed to resolve the problem.

Emergency: The server is in an unusable state. This severity indicates a severe system failure or panic.

Log Messages from Application in addition to the messages from native <App Server> subsystems, <Application> API application also logs the following messages to <App Server> log file (located in D:\UITSDir\log).

Security

[Document any specific security procedures or permissions for the application.]

Backup and Recovery

[Document any Backup and recovery procedures for the application.]

Disaster Recovery

[Document any disaster recovery procedures.]

Service Level Agreements

Document any SLAs you have with the client or any business partner.

Contingency

PURPOSE

This <Project/Sub-project Title> Contingency Plan establishes procedures to recover the <Project/Sub-project Title> following a disruption. The following objectives have been established for this plan:

Maximize the effectiveness of contingency operations through an established plan that consists of the following phases:

Notification/Activation phase to detect and assess damage and to activate the plan

Recovery phase to restore temporary IT operations and recover damage done to the original system

Reconstitution phase to restore IT system-processing capabilities to normal operations.

Identify the activities, resources, and procedures needed to carry out <Project/Sub-project Title> processing requirements during prolonged interruptions to normal operations.

Assign responsibilities to designated UITS personnel and provide guidance for recovering <Project/Sub-project Title> during prolonged periods of interruption to normal operations.

Ensure coordination with other UITS/UCONN staff that will participate in the contingency planning strategies.

Ensure coordination with external points of contact and possible vendors who will participate in the contingency planning strategies.

BACKGROUND

This <Project/Sub-project Title> Contingency Plan has been developed as required under the UITS SDLC program which requires the establishment and implementation of procedures for responding to events that damage systems containing electronic protected university information.

APPLICABILITY

The <Project/Sub-project Title> Contingency Plan applies to the functions, operations, and resources necessary to restore and resume UITS’s <Project/Sub-project Title> operations as it is installed at. The <Project/Sub-project Title> Contingency Plan applies to UITS and all other persons associated with <Project/Sub-project Title> as identified under Section 2.3, Responsibilities.

SCOPE

Planning Principles

Various scenarios were considered to form a basis for the plan, and multiple assumptions were made. The applicability of the plan is predicated on two key principles.

UITS’s facility in , is inaccessible; therefore, UITS is unable to perform <Project/Sub-project Title> processing for the Department.

A valid contract exists with an alternate site that designates that site in <Project/Sub-project Title>, as the UITS’s alternate operating facility.

UITS will use the alternate site building and IT resources to recover <Project/Sub-project Title> functionality during an emergency situation that prevents access to the original facility.

The designated computer system at the alternate site has been configured to begin processing <Project/Sub-project Title> information.

The alternate site will be used to continue <Project/Sub-project Title> recovery and processing throughout the period of disruption, until the return to normal operations.

Assumptions

Based on these principles, the following assumptions were used when developing the IT Contingency Plan.

The <Project/Sub-project Title> is inoperable at the UITS computer center and cannot be recovered within 48 hours.

Key <Project/Sub-project Title> personnel have been identified and trained in their emergency response and recovery roles; they are available to activate the <Project/Sub-project Title> Contingency Plan.

Preventive controls (e.g., generators, environmental controls, waterproof tarps, sprinkler systems, fire extinguishers, and fire department assistance) are fully operational at the time of the disaster.

Computer center equipment, including components supporting <Project/Sub-project Title>, are connected to an uninterruptible power supply (UPS) that provides 45 minutes to 1 hour of electricity during a power failure.

<Project/Sub-project Title> hardware and software at the UITS UCONN site are unavailable for at least 48 hours.

Current backups of the application software and data are intact and available.

The equipment, connections, and capabilities required to operate <Project/Sub-project Title> are available at the alternate operating facility in <City, State>.

Service agreements are maintained with <Project/Sub-project Title> hardware, software, and communications providers to support the emergency system recovery.

The <Project/Sub-project Title> Contingency Plan does not apply to the following situations:

Overall recovery and continuity of business operations. A Business Resumption Plan (BRP) or Continuity of Operations Plan (COOP) would have to be devised and approved by another department of the university.

Emergency evacuation of personnel. The Occupant Evacuation Plan (OEP) is the responsibility of the Public Safety department.

Any additional constraints should be added to this list.

REFERENCES/REQUIREMENTS

[Any existing university contingency polices should be added here.]

[Any other applicable federal policies should be added.]

[Any other applicable departmental policies should be added.]

CONCEPT OF OPERATIONS

SYSTEM DESCRIPTION AND ARCHITECTURE

[Provide a general description of system architecture and functionality. Indicate the operating environment, physical location, general location of users, and partnerships with external organizations/systems. Include information regarding any other technical considerations that are important for recovery purposes, such as backup procedures. Provide a diagram of the architecture, including security controls and telecommunications connections.]

LINE OF SUCCESSION

UITS sets forth an order of succession, in coordination with the order set forth by the Department to ensure that decision-making authority for the <Project/Sub-project Title> Contingency Plan is uninterrupted. The Chief Information Officer (CIO) is responsible for ensuring the safety of personnel and the execution of procedures documented within this <Project/Sub-project Title> Contingency Plan. If the CIO is unable to function as the overall authority or chooses to delegate this responsibility to a successor, the Deputy CIO shall function as that authority. To provide contact initiation should the contingency plan need to be initiated, please use the contact list below. [Continue description of succession as applicable.]

Contact List

#	Name	Office Phone	Home Phone	Cell Phone	Email
1	<Click here and enter data>	<Click here and enter data>	<Click here and enter data>	<Click here and enter data>	<Click here and enter data>
2	<Click here and enter data>	<Click here and enter data>	<Click here and enter data>	<Click here and enter data>	<Click here and enter data>
3	<Click here and enter data>	<Click here and enter data>	<Click here and enter data>	<Click here and enter data>	<Click here and enter data>
4	<Click here and enter data>	<Click here and enter data>	<Click here and enter data>	<Click here and enter data>	<Click here and enter data>
5	<Click here and enter data>	<Click here and enter data>	<Click here and enter data>	<Click here and enter data>	<Click here and enter data>
14	<Click here and enter data>	<Click here and enter data>	<Click here and enter data>	<Click here and enter data>	<Click here and enter data>

RESPONSIBILITIES

The following teams have been developed and trained to respond to a contingency event affecting the IT system.

The Contingency Plan establishes several teams assigned to participate in recovering <Project/Sub-project Title> operations. The team is responsible for recovery of the <Project/Sub-project Title> computer environment and all applications. Members of the team include personnel who are also responsible for the daily operations and maintenance of <Project/Sub-project Title>. The team leader directs the team.

[Continue to describe each team, their responsibilities, leadership, and coordination with other applicable teams during a recovery operation.]

The relationships of the team leaders involved in system recovery and their member teams are illustrated in Figure XX below.

[Insert hierarchical diagram of recovery teams. Show team names and leaders; do not include actual names of personnel.]

[Describe each team separately, highlighting overall recovery goals and specific responsibilities. Do not detail the procedures that will be used to execute these responsibilities. These procedures will be itemized in the appropriate phase sections]

TESTING AND MAINTENANCE

The Business Owner and System Developer/Maintainer shall establish criteria for validation/testing of a Contingency Plan, an annual test schedule, and ensure implementation of the test. This process will also serve as training for personnel involved in the plan’s execution. At a minimum the Contingency Plan shall be tested annually (within 365 days). The types of validation/testing exercises include tabletop and technical testing. Contingency Plans for all application systems must be tested at a minimum using the tabletop testing process (http://www.bcmpedia.org/wiki/Test_-_Tabletop). However, if the application system Contingency Plan is included in the technical testing of their respective support systems, then that technical test will satisfy the annual requirement.

Tabletop Testing

The primary objective of the tabletop test is to ensure designated personnel are knowledgeable and capable of performing the notification/activation requirements and procedures are done in a timely manner. The exercises include, but are not limited to:

Testing to validate the ability to respond to a crisis in a coordinated, timely, and effective manner, by simulating the occurrence of a specific crisis; and

Crisis communications and call tree verification.

Technical Testing

The primary objective of the technical test is to ensure the communication processes and data storage and recovery processes can function at an alternate site to perform the functions and capabilities of the system within the designated requirements. Technical testing shall include, but is not limited to:

Process from backup system at the alternate site;

Restore system using backups; and

Switch voice and data telecommunications to alternate processing site.

NOTIFICATION AND ACTIVATION PHASE

This phase addresses the initial actions taken to detect and assess damage inflicted by a disruption to <Project/Sub-project Title>. Based on the assessment of the event, the plan may be activated by the <Contingency Planning Coordinator>. In an emergency, UITS‘s top priority is to preserve the health and safety of its staff before proceeding to the Notification and Activation procedures.

Contact information for key personnel is located in Appendix A. The notification sequence is listed below:

The first responder is to notify the <Contingency Planning Coordinator>. All known information must be relayed to the <Contingency Planning Coordinator>.

The <systems manager> is to contact the <Damage Assessment Team> and inform them of the event. The <Contingency Planning Coordinator> is to instruct the Team Leader to begin assessment procedures.

The <Damage Assessment Team> is to notify team members and direct them to complete the assessment procedures outlined below to determine the extent of damage and estimated recovery time. If damage assessment cannot be performed locally because of unsafe conditions, the <Damage Assessment Team> is to follow the outline below:

Damage Assessment Procedures:

[Detailed procedures should be outlined to include activities to determine the cause of the disruption; potential for additional disruption or damage; affected physical area and status of physical infrastructure; status of IT equipment functionality and inventory, including items that will need to be replaced; and estimated time to repair services to normal operations.]

Upon notification from the Contingency Planning Coordinator, the <Damage Assessment Team Leader> is to …

<The Damage Assessment Team> is to ….

Alternate Assessment Procedures:

Upon notification from the Contingency Planning Coordinator, the <Damage Assessment Team Leader> is to

<Damage Assessment Team Leader> is to

When damage assessment has been completed, the <Damage Assessment Team Leader> is to notify the <Contingency Planning Coordinator> of the results.

The <Contingency Planning Coordinator> is to evaluate the results and determine whether the contingency plan is to be activated and if relocation is required.

Based on assessment results, the <Contingency Planning Coordinator> is to notify assessment results to civil emergency personnel (e.g., police or fire department) as appropriate.

The Contingency Plan is to be activated if one or more of the following criteria are met:

<Project/Sub-project Title> will be unavailable for more than 48 hours

Facility is damaged and will be unavailable for more than 24 hours

Other criteria, as appropriate

If the plan is to be activated, the <Contingency Planning Coordinator> is to notify all Team Leaders and inform them of the details of the event and if relocation is required.

Upon notification from the <Contingency Planning Coordinator>, Team Leaders are to notify their respective teams. Team members are to be informed of all applicable information and prepared to respond and relocate if necessary.

The <Contingency Planning Coordinator> is to notify the <off-site storage facility> that a contingency event has been declared and to ship the necessary materials (as determined by damage assessment) to the alternate site.

The <Contingency Planning Coordinator> is to notify the <alternate site> that a contingency event has been declared and to prepare the facility for the <Organization’s> arrival.

The <Contingency Planning Coordinator> is to notify remaining personnel (via notification procedures) on the general status of the incident.

RECOVERY OPERATIONS

This section provides procedures for recovering the application at the alternate site, whereas other efforts are directed to repair damage to the original system and capabilities.

The following procedures are for recovering the <Project/Sub-project Title> at the alternate site. Procedures are outlined per team required. Each procedure should be executed in the sequence it is presented to maintain efficient operations.

Recovery Goal

[State the first recovery objective as determined by the Contingency Plan. For each team responsible for executing a function to meet this objective, state the team names and list their respective procedures.]

<Team Name>

Team Recovery Procedures

<Team Name>

Team Recovery Procedures

<Team Name>

Team Recovery Procedures

Recovery Goal

[State the second recovery objective as determined by the CP. For each team responsible for executing a function to meet this objective, state the team names and list their respective procedures.]

<Team Name>

Team Recovery Procedures

<Team Name>

Team Recovery Procedures

<Team Name>

Team Recovery Procedures

Recovery Goal

[State the remaining recovery objectives (as determined by the CP). For each team responsible for executing a function to meet this objective, state the team names and list their respective procedures.]

RETURN TO NORMAL OPERATIONS

This section discusses activities necessary for restoring <Project/Sub-project Title> operations at the UITS‘s original or new site. When the computer center at the original or new site has been restored, <Project/Sub-project Title> operations at the <alternate site> must be transitioned back. The goal is to provide a seamless transition of operations from the <alternate site> to the computer center.

ORIGINAL OR NEW SITE RESTORATION

[Procedures should be outlined, per necessary team, to restore or replace the original site so that normal operations may be transferred. IT equipment and telecommunications connections should be tested.]

<Team Name>

Team Resumption Procedures

<Team Name>

Team Resumption Procedures

CONCURRENT PROCESSING

[Procedures should be outlined, per necessary team, to operate the system in coordination with the system at the original or new site. These procedures should include testing the original or new system until it is functioning properly and the contingency system is shut down gracefully.]

<Team Name>

Team Resumption Procedures

<Team Name>

Team Resumption Procedures

PLAN DEACTIVATION

[Procedures should be outlined, per necessary team, to clean the alternate site of any equipment or other materials belonging to the organization, with a focus on handling sensitive information. Materials, equipment, and backup media should be properly packaged, labeled, and shipped to the appropriate location(s). Team members should be instructed to return to the original or new site]

<Team Name>

Team Testing Procedures

<Team Name>

Team Testing Procedures

Appendix A: Maintenance Manual Approval

The undersigned acknowledge that they have reviewed the <Project/Sub-project Title> Maintenance Manual and agree with the information presented within this document. Changes to this Maintenance Manual will be coordinated with, and approved by, the undersigned, or their designated representatives.

[List the individuals whose signatures are desired. Examples of such individuals are Business Owner, Project Manager (if identified), Designated Approving Authorities and any appropriate stakeholders. Add additional lines for signature as necessary.]

Signature:	Date:
Print Name:
Title:
Role:

Signature:	Date:
Print Name:
Title:
Role:

Signature:	Date:
Print Name:
Title:
Role:

APPENDIX B: REFERENCES

[Insert the name, version number, description, and physical location of any documents referenced in this document. Add rows to the table as necessary.]

The following table summarizes the documents referenced in this document.

Document Name	Description	Location
<Document Name and Version Number>	<Document description>	<URL or Network path where document is located>

APPENDIX C: KEY TERMS

The following table provides definitions and explanations for terms and acronyms relevant to the content presented within this document.

Term	Definition
[Insert Term]	<Provide definition of term and acronyms used in this document.>

Maintenance plan signoff

The terms and conditions of the Functional Requirements Document apply in full to the services and products provided under the Implementation Plan.

[Client name]	[Services provider name]
Full name	Full name
Title	Title
Signature	Signature
Date	Date

Revision History

Version	Date	Summary of Changes	Author	Revision Marks (Yes/No)
0.1	Initial revision.

[Note: This template is provided to assist authors with the UITS SDLC.

Blue or black text within arrow brackets (< >) should be customized before publishing this document. Be sure to change the color of the text to black before publishing this document.

Blue text within square brackets ([ ]) provides instructions and guidance and should be deleted before publishing this document.

This document uses automatic fields:

Viewing Automatic Fields
If you cannot see the automatic fields in this document, select Tools>Options, and then choose the View tab; in the Field Shading drop-down list, choose Always.

Customizing Automatic Fields
To customize the automatic fields in this document, select File>Properties and then replace the information in brackets (< >) with the appropriate information for this document; be sure to also customize the Custom properties by choosing the Custom tab, selecting a property, changing its value, and then clicking Modify. Repeat this for each custom field. Click OK to close the dialog.

Updating Automatic Fields
You can update the automatic fields with new, customized information by selecting Edit>Select All (or Ctrl+A) and then pressing F9, or by simply clicking on a field and pressing F9. This must be done separately for Headers and Footers (View>Header and Footer, Ctrl+A, F9). See MS Word help for more information on working with fields.]