文件编号: 修订状态：2.0 文件名称 制订人 软件维护计划 付明正 审核人 批准人 制订日期 审核日期 质量部 分发部门 质量部 批准日期 制订部门 1.
适用范围
本标准适用于软件生存周期的运行和维护阶段，主要供管理人员和维护人员使用
2.
职责
•维护管理员接收维护申请并对之进行评价
•系统管理员负责审批日常维护计划，并对执行惜况进行监督 •维护决策者负责最终维护审査批准工作 • 维护人员：负责系统日常的维护工作
3.维护计划
3・1•维护活动
为了有效地进行软件维护，最开始应该做一些组织工作： •首先建立维护的人员机构
•申明提出维护申请报告的过程及评价的过程 •为每一个维护申请规定标准的处理步骤
•建立维护活动的登记制度以及规定评价和评审的标准
311.维护人员机构
第1页共6页
文件编号: 修订状态：2.0 维护申请
在维护活动开始之前就明确维护责任是十分重要的，可以大大地减少维护过程中 可能出现的混乱。每个维护申请通过维护管理员转告给系统管理员，系统管理员 一般都是对程序（某一部分功能的程序）特别熟悉的技术人员，他们对维护申请 及可能引起的软件修改进行评估，并向修改控制决策机构（一个或一组管理者） 报告，曲他们最好确定是否采用维护活动。
3.1.2.维护申请报告
•维护申请报告或软件问题报告（或叫软件缺陷报告）山提出申请的用户填写。 •用户必须完整的说明软件产生问题的悄况，包括数据输入、错误清单以及其 他相关材料 •对于适应性维护和完善性维护应该给出一个简短的需求规格说明书。最终由 维护管
理员和系统管理员评价用户提出的维护申请表。
•经批准后才能开始维护工作，一个维护申请被核准后，维护请求表就成为外 部文档
作为规划本次维护任务的依据。
3.13.维护修改报告
•依据维护申请表，软件组织内部应该制定出一个软件修改报告，需要有以下 信息：
（1）满足维护申请表中提出的要求所需的工作量
(2) 维护要求的性质 (3) 维护要求的优先次序
第2页共6页
文件编号: 修订状态：2.0 (4) 与修改有关的背景数据
•在拟定进一步维护汁划前，把软件修改报告提交给控制决策结构审査批准。
3.1.4.维护流程
一个看似很小地方的修正可能对全局系统产生重大影响。每当软件修正后，验证 分析不仅要对此修正进行验证，还要确认此修正对整个软件系统的影响程度。同 时涉及到该软件的修改，评审、验证和风险分析，软件修改前后的差别对比，新 软件版本号，这些都将形成文字记录，工作流程如下：
第3页共6页
文件编号: 修订状态：2.0
上图维护流程说明:
1） 使用者因为各种原因需要对已经产生的数据进行修改，提出维护申请。 2） 提出申请部门负责人需要对情况进行核实，并确认。
3) 维护工程师(一般山软件开发组专人负责)接收到确认后的维护请求，分析并 提出修
第4页共6页
文件编号: 修订状态：2.0 改方案。
4) 技术部门负责人对方案进行审核，确保方案的安全性和正确性。 5) 数据库管理员对系统数据进行备份。(具体操作由方案确定) 6) 运维管理员对维护操作进行模拟验证。(具体操作山方案确定) 7) 维护管理员按照方案进行修改操作。完成维护后，需通知用户验证。 8) 维护申请提出用户对维护结果进行反馈和评价。
3.1.5.维护复审
•当一项软件维护任务完成之后，进行一次维护复审，维护复审需要考虑一下 问题：
(1) 依照当前状态，在设讣、编码和测试是否合理 (2) 这次维护活动中主要障碍有哪些
•维护复审的U的在于促进未来的维护工作，同时也为有效管理软件组织提供
重要的反馈信息。无论是哪一种类型的维护，都要进行以下工作： ⑴修改软件设讣
(2) 设计复审
(3) 对源代码的必要修改 (4) 单元测试
(5) 集成测试，包括回归测试 (6) 验收测试(公司内容的验收) (7) 软件配置复审
3・2•维护记录
《缺陷管理记录》
重点说明是否存在遗留未解决缺陷、针对遗留缺陷或潜在缺陷解决方案。
第5页共6页
文件编号: 修订状态：2.0 《软件缺陷分析报告》
重点说明软件版本号、缺陷类型、缺陷概述、操作步骤、实际结果、预期结果。 《缺陷分析评审》
输出缺陷管理相关评审记录。 《剩余缺陷风险管理记录》
软件确认应当保证软件满足用户需求和预期LI的，且软件已知剩余缺陷的风险 均可接受。输出软件已知剩余缺陷风险管理记录。
其他有关软件的配置文档：当完成维护活动时，对软件系统或者其软件项的任何 更改。
第6页共6页
因篇幅问题不能全部显示，请点此查看更多更全内容