软件售后维护计划模板Word格式.docx

软件售后维护计划模板Word格式.docx

《软件售后维护计划模板Word格式.docx》由会员分享，可在线阅读，更多相关《软件售后维护计划模板Word格式.docx（8页珍藏版）》请在冰豆网上搜索。

正式发布

文档信息及版本历史

文档信息

项目名称

<

项目名称>

项目编号

文档名称

存储位置

作者/修改者

描述

【目录】

1.概述

注意：

●所有的正文使用正文格式；

●每段的首行都使用Tab键缩进，不要使用空格进行缩进；

●建议所有的文档编写者完成文档修改后，需要完成以下工作：

确定当前版本、修改版本历史、更新目录、更新页眉、检查文档封面；

●文档中编号的建议：

本文档中基本上将标题都进行了编号，标题类的都使用数字型的分级编号；

若活动描述中还有项目编号，请使用符号编号，符号统一使用“●”；

●关于文件名命名问题：

在《命名规》发布前（发布后，按照此规要求命名），为了便于历史记录和查找，建议可以先按照以下方式命名：

✧提交小组文档：

文档名称+“_”+“日期简称”；

✧正式发布文档：

文档名称+“V”+版本号。

>

1.1编写目的

阐明本维护计划的目的。

<

如：

本文档制订<

的维护计划，为<

的维护活动提供依据。

1.2适用围

简要说明此维护计划的适用围。

本计划适用于<

维护项目的整个维护阶段，从什么时候到什么时候。

1.3术语和缩写

本小节应提供正确解释此维护计划所需的全部术语的定义、首字母缩写词和J解释。

这些信息可以通过引用项目词汇表来提供。

术语和缩写

解释

备注

1.4参考资料

本小节应完整列出此维护计划中其他部分所引用的任何文档。

每个文档应标有标题和备注。

列出可从中获取这些参考资料的来源。

这些信息可以通过引用附录或其他文档来提供。

2.角色和职责

此处填写本文档中所有要涉及到的角色，及其他的职责，角色命名需要统一按照EPG编写的文档规编写，角色还需要与下面的文档描述中出现的角色名称一一对应>

角色

职责

人员

客户代表

●提出维护要求

●确认维护结果

维护部门经理

●维护部门经理为所有产品指定维护工程师，维护工程师的多少根据机构的现状而定

维护工程师

●维护工程师接收客户的要求，并迅速响应，努力给客户一个满意的解答

●维护工程师及时消除产品中存在的缺陷，在资源允许的情况下，不断改善产品功能与质量

配置管理代表

●配置管理活动

QA代表

●QA代表对是否按照过程来执行维护进行质量保证的检查

3.维护信息

3.1客户信息

可以参照下面的格式来描述清楚维护项目单位及客户代表的详细信息>

名称

维护单位信息

维护单位名称

维护单位地址

维护单位邮编

维护客户代表信息

客户代表名称

所属部门名称

联系地址

联系（单位）

联系（其他）

E-Mail

3.2维护工程师信息

可以参照下面的格式来描述维护工程师的详细信息>

单位名称

单位地址

联系地址邮编

此处可以按照对该用户提供的不同的维护方式，如5*8，还是7*24提供不同的联系，如果维护约定维护方式为7*24，则要求提供非工作时间维护人员联系方式，且需要保证该联系方式7*24能联系到>

EMail

3.3维护系统信息

此处详细的描述维护系统的建立信息，如

●系统建设情况：

建设单位，建设时间，原项目经理名称；

●维护系统名称；

●系统主机情况；

●系统目前使用情况等>

4.维护围

此处详细的描述由维护工程师进行维护的围，此处要求尽量详细，可以罗列如下容：

●需要维护的模块列表；

●根据合同规定要求，描述本项目或产品的维护职责、维护期限、维护容等>

5.维护方式

此处详细的描述本项目或产品的维护方式，包括如下信息：

●维护时间：

5*8，还是7*24；

●维护方式：

现场维护、支持、定期（要求写出周期）巡检等与维护用户的约定；

●维护响应时间要求：

描述与维护用户约定的维护响应时间要求，对于不同维护请求的不同的响应时间等>

6.配置管理计划

此处详细描述本维护项目的配置管理计划，如：

●配置管理服务器信息；

●配置管理目录设置计划；

●本项目的配置管理流程。

6.1配置管理服务器

此处详细描述本维护项目的配置管理服务器信息>

6.2配置项标识

参照《命名规》，确定该项目的命名规则，说明该项目产品的命名、标记和编号方法>

针对不同的文档类型说明如下：

●全局性的文档，如维护计划

格式<

-<

文档名称>

.文档扩展名

示例：

维护项目-维护计划.doc

●模块相关的文档

-模块名称.文档扩展名

维护项目-测试用例-报表模块.doc

●与时间相关的文档，比如会议纪要，维护月报等

格式：

-时间.文档扩展名

维护项目-会议记录-050421.doc

●个人相关的文档，比如个人工作计划，工时统计等等（此类文档直接用总项目名称即可，工时统计表入库时不需要分项目组，采用统一的目录0860）

-作者-时间.文档扩展名

维护项目-工时统计表-四-050822-050828.xls

●正式对外发布的配置项，除了要遵守上述的命名原则外，还要添加文档的版本标识，具体见《命名规》。

例如：

维护项目-维护计划V1.0.doc

6.3配置库结构

01技术文件

011需求（注：

可放置“需求规格说明书”、“需求跟踪矩阵”等与需求相关的容（包括会议纪要等））

012设计（注：

可放置“技术预研报告”、“系统概要设计报告”、“界面设计说明书”、“模块设计说明书”、“数据库设计说明书”等与设计相关的容）

013代码（注：

可放置“代码审查报告”、“单元测试报告”、“集成测试报告”、“源程序”等相关的容）

014部署（注：

可放置“部署计划”、“用户手册”、“维护手册”、“培训资料”|“发布说明”、“产品包”、“客户验收报告”等相关的容）

015试运行记录（注：

可放置“试运行记录”、“试运行客户回访单”、“试运行报告”、“应用软件维护记录”、“用户现场巡检表”等相关的容）

02维护记录（注：

可放置“会议纪要”、“用户现场巡检表”等相关的容）

03需求变更（注：

可放置“需求变更单”等相关的容）

04维护报告（注：

可放置“维护计划”、“维护报告”、“故障报告”等相关的容）

05配置管理（注：

可放置“配置项入库单”、“配置项清单”、“基线配置项清单”等相关的容）

6.4访问权限

说明项目组每个成员对配置库中的配置项的访问权限>

6.5变更控制

此处填写该项目的变更控制委员会CCB的成员：

建议有客户代表、维护工程师、维护部经理，及部门经理等>

7.维护沟通计划

此处描述在维护过程中的沟通计划，如：

●定义《维护状态报告》提交相关人员计划；

●等>

8.风险管理计划

8.1工作产品列表

成果物

责任人员

《风险管理计划》（《维护计划》中）

维护负责人

《维护报告-风险列表》

8.2风险管理

此处容包括：

如何进行风险的识别、如何进行风险分析（具体分析容参加《维护报告--风险列表》）、识别风险后，项目经理如何进行风险应对和跟踪管理。

如果风险可能性或影响程度发生了变化，或者发现了新的项目风险，或者项目本身发生了重大变化（重大变化包括新增的项目特性，系统目标平台变化），则需要重新按定义的风险管理过程进行风险分析、计划、跟踪执行。

风险识别人

风险识别频率

识别方式

风险分析责任人

风险更新频率

（项目经理、QA代表、必要时包括用户代表、部门经理等）

风险识别的周期，可以是每两周或者一月等

使用检查单或者通过“头脑风暴”等模式

风险状态的更新周期可以是每两周或者一月等

9.计划评审

此处记录维护计划的评审计划，评审人员，评审结果>