软件维护计划.docxVIP

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