1、正式发布文档信息及版本历史文档信息项目名称项目编号文档名称存储位置作者/修改者描述【目录】1. 概述注意: 所有的正文使用正文格式; 每段的首行都使用Tab键缩进,不要使用空格进行缩进; 建议所有的文档编写者完成文档修改后,需要完成以下工作:确定当前版本、修改版本历史、更新目录、更新页眉、检查文档封面; 文档中编号的建议:本文档中基本上将标题都进行了编号,标题类的都使用数字型的分级编号;若活动描述中还有项目编号,请使用符号编号,符号统一使用“”; 关于文件名命名问题:在命名规发布前(发布后,按照此规要求命名),为了便于历史记录和查找,建议可以先按照以下方式命名: 提交小组文档:文档名称+“_”
2、+“日期简称”; 正式发布文档:文档名称+“V”+版本号。1.1 编写目的阐明本维护计划的目的。 如:本文档制订的维护计划,为的维护活动提供依据。1.2 适用围简要说明此维护计划的适用围。本计划适用于角色职责人员客户代表 提出维护要求 确认维护结果维护部门经理 维护部门经理为所有产品指定维护工程师,维护工程师的多少根据机构的现状而定维护工程师 维护工程师接收客户的要求,并迅速响应,努力给客户一个满意的解答 维护工程师及时消除产品中存在的缺陷,在资源允许的情况下,不断改善产品功能与质量配置管理代表 配置管理活动QA代表 QA代表对是否按照过程来执行维护进行质量保证的检查3. 维护信息3.1 客户
3、信息可以参照下面的格式来描述清楚维护项目单位及客户代表的详细信息名称维护单位信息维护单位名称维护单位地址维护单位邮编维护客户代表信息客户代表名称所属部门名称联系地址联系(单位)联系(其他)E-Mail3.2 维护工程师信息可以参照下面的格式来描述维护工程师的详细信息单位名称单位地址联系地址邮编此处可以按照对该用户提供的不同的维护方式,如5*8,还是7*24提供不同的联系,如果维护约定维护方式为7*24,则要求提供非工作时间维护人员联系方式,且需要保证该联系方式7*24能联系到EMail3.3 维护系统信息此处详细的描述维护系统的建立信息,如 系统建设情况:建设单位,建设时间,原项目经理名称;
4、维护系统名称; 系统主机情况; 系统目前使用情况等4. 维护围此处详细的描述由维护工程师进行维护的围,此处要求尽量详细,可以罗列如下容: 需要维护的模块列表; 根据合同规定要求,描述本项目或产品的维护职责、维护期限、维护容等5. 维护方式此处详细的描述本项目或产品的维护方式,包括如下信息: 维护时间:5*8,还是7*24; 维护方式:现场维护、支持、定期(要求写出周期)巡检等与维护用户的约定; 维护响应时间要求:描述与维护用户约定的维护响应时间要求,对于不同维护请求的不同的响应时间等6. 配置管理计划此处详细描述本维护项目的配置管理计划,如: 配置管理服务器信息; 配置管理目录设置计划; 本项
5、目的配置管理流程。6.1 配置管理服务器此处详细描述本维护项目的配置管理服务器信息6.2 配置项标识参照命名规,确定该项目的命名规则,说明该项目产品的命名、标记和编号方法针对不同的文档类型说明如下: 全局性的文档,如维护计划 格式-.文档扩展名示例: 维护项目-维护计划.doc 模块相关的文档-模块名称.文档扩展名 维护项目-测试用例-报表模块.doc 与时间相关的文档,比如会议纪要,维护月报等 格式:-时间.文档扩展名 维护项目-会议记录-050421.doc 个人相关的文档,比如个人工作计划,工时统计等等(此类文档直接用总项目名称即可,工时统计表入库时不需要分项目组,采用统一的目录0860
6、)-作者-时间.文档扩展名 维护项目-工时统计表-四-050822-050828.xls 正式对外发布的配置项,除了要遵守上述的命名原则外,还要添加文档的版本标识, 具体见命名规。例如: 维护项目-维护计划 V1.0.doc6.3 配置库结构01 技术文件011 需求 (注:可放置 “需求规格说明书”、“需求跟踪矩阵”等与需求相关的容(包括会议纪要等)012 设计 (注:可放置“技术预研报告”、 “系统概要设计报告”、“界面设计说明书”、“模块设计说明书”、“数据库设计说明书”等与设计相关的容)013 代码 (注:可放置“代码审查报告”、“单元测试报告”、“集成测试报告”、“源程序” 等相关的
7、容)014 部署 (注:可放置“部署计划”、“用户手册”、“维护手册”、“培训资料”|“发布说明”、“产品包”、“客户验收报告”等相关的容)015 试运行记录 (注:可放置“试运行记录”、“试运行客户回访单”、“试运行报告”、“应用软件维护记录”、“用户现场巡检表”等相关的容)02 维护记录 (注:可放置“会议纪要”、“用户现场巡检表”等相关的容)03 需求变更 (注:可放置“需求变更单”等相关的容)04 维护报告 (注:可放置“维护计划”、“维护报告”、“故障报告” 等相关的容)05 配置管理 (注:可放置“配置项入库单”、“配置项清单”、“基线配置项清单” 等相关的容)6.4 访问权限说明
8、项目组每个成员对配置库中的配置项的访问权限6.5 变更控制此处填写该项目的变更控制委员会CCB的成员:建议有客户代表、维护工程师、维护部经理,及部门经理等7. 维护沟通计划此处描述在维护过程中的沟通计划,如: 定义维护状态报告提交相关人员计划; 等8. 风险管理计划8.1 工作产品列表成果物责任人员风险管理计划(维护计划中)维护负责人维护报告-风险列表8.2 风险管理此处容包括:如何进行风险的识别、如何进行风险分析(具体分析容参加维护报告-风险列表)、识别风险后,项目经理如何进行风险应对和跟踪管理。如果风险可能性或影响程度发生了变化,或者发现了新的项目风险,或者项目本身发生了重大变化(重大变化包括新增的项目特性,系统目标平台变化),则需要重新按定义的风险管理过程进行风险分析、计划、跟踪执行。风险识别人风险识别频率识别方式风险分析责任人风险更新频率(项目经理、QA代表、必要时包括用户代表、部门经理等)风险识别的周期,可以是每两周或者一月等使用检查单或者通过“头脑风暴”等模式风险状态的更新周期可以是每两周或者一月等9. 计划评审此处记录维护计划的评审计划,评审人员,评审结果
copyright@ 2008-2022 冰豆网网站版权所有
经营许可证编号:鄂ICP备2022015515号-1