软件变更管理制度试行).pdf

《软件变更管理制度试行).pdf》由会员分享，可在线阅读，更多相关《软件变更管理制度试行).pdf（21页珍藏版）》请在三一文库上搜索。

1、软件变更管理制度（试行） 第一节总则 第一条为规范软件变更与维护管理，提高软件管理水平，优化软件变更 与维护管理流程，特制定本制度。 第二条软件变更与维护管理主要包括一般性变更、紧急变更、 用户测试、 版本控制、系统更新和权限管理等内容。 第三条本制度适用于中国铝业股份有限公司总部和各分子公司（含郑州 研究院） （以下简称“公司”） 。 第二节一般性变更流程 第四条需求部门提出系统变更需求， 并将变更需求整理成 变更申请书 （附件三），由部门负责人审批后提交给信息部。 第五条信息部负责接受需求、分析需求，并提出系统变更建议。信息部 负责人审批变更申请书 。 第六条信息部根据自行开发、合作开发和

2、外包开发的不同要求组织实现 系统变更需求，产生供发布的程序。 第七条信息部将所有的变更请求记录在任务管理表（附件四）中，并 按照优先级安排实施的先后次序进行跟踪处理。 第八条信息部负责对系统变更过程的文档进行归档管理，所有文档至少 保存三年。详细流程参见系统变更流程（附件一）。 第三节紧急变更流程 第九条对于紧急变更，需求部门可以通过电子邮件或传真等书面形式提 出申请。 第十条信息部按照事先明确的紧急变更定义做出判断，确定其优先级和 影响程度，并进行相应的处理。 第十一条紧急变更过程中应使用专设系统用户帐号，由专责部门或人员启 动紧急修改变更程序。信息部应对紧急变更的处理进行规范的文 档记录。

3、 第十二条在紧急事件处理完成后，必须补办正式、完整的文档。详细流程 参见紧急变更流程（附件二）。 第四节系统的版本控制 第十三条软件变更时，加强版本控制，确保每次在最新的代码基础上进行 更改。 第十四条应对下发的软件进行版本控制，由专责人员负责发布软件的版本 管理。 第五节系统变更的责权分离 第十五条应加强对运行环境的访问控制，只允许授权的用户访问运行环境 中的应用系统。通过物理和逻辑隔离的手段，控制对运行环境的 访问。 第十六条限制开发人员对运行环境中应用程序文件夹的访问权限，只有经 过授权的人员才拥有相应的权限。 第十七条对授权访问运行环境的人员进行详细记录，并定期进行检查。 第十八条普通

4、用户只能通过前台登录系统，不能通过后台进行操作。 第十九条系统维护人员不应该拥有前台应用程序的访问权限，更不应该在 前台应用程序中担任实际的操作任务。 第二十条禁止系统维护人员共享操作系统级别的账号。 第六节附则 第二十一条本制度由公司总部信息部负责解释和修订。 第二十二条本制度自发布之日起开始执行。 附件一系统变更流程 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应应应应应应 应 应应 应应 应 应 应应 应 应 应 应应 应 应 应 应 应应 应 应应 应 应 应 应应 应 应 应 应 应应 应 应 应应 应 应 应应 应

5、 应应 应应 应 应应应 应 应 应应应 应 应应 应 应 应应应 应 应 应 应应 应 应应 应应 应 应应 应 应 应 应应 应 应 应 应 应应应 应 应应 应 应 应 应 应应 应 应 应 应 应应 应 应应 应 应 应应 应 应 应应 应 应 应应 应 应 应应 应 应 应 应应 应 应 应 应 应应 应 应 应 应应 应应 应 应应 应应 应 应 应 应 应 应应 应 应 应 应 应 应 应 应应 应应 系统变更流程步骤： 一、任务提交和接受： 本流程中需求部门为应用系统构建时提出需求的业务部门，维护部门为负 责按照需求实际构建应用系统的信息部。流程如下： （一） 需求形成： 需求

6、方根据业务的需要，结合收到的其他用户部门要求，填写变 更申请书。 （二） 需求方负责人审批 需求方将变更申请书报请部门负责人签字批准后，经指定途径 提交给信息部相关系统维护人员。 （三） 需求评估 系统维护人员审查需求，会同相关开发负责人进行需求评估，产生 评估结果。 （四） 信息部负责人审批 系统维护人员将评估结果附在变更申请书后，报请部门负责人 签字批准后，正式向开发负责人下达任务。 如果任务实现由合作厂商完成，则由开发负责人按照与合作厂商签 订的技术服务合同，填写厂商维护申请单（附件五），报请部门 负责人签字批准后，正式向合作厂商下达任务。 （五） 任务登记 为了便于追踪各个系统变更需求

7、的状态，维护人员需要对需求进行 登记。 信息部每周对任务管理表中的需求完成状态进行更新，以便信 息部负责人监控系统变更任务进度。 二、任务实现 信息部开发负责人（或由开发负责人会同合作厂商）根据变更申 请书的需求描述， 按照与软件开发流程同样的步骤，进行分析、设计、 编码、测试，最终完成系统变更需求。 三、任务验收及用户测试 （一） 任务验收以需求部门为主，信息部配合完成。 （二） 任务开发测试完成后， 由开发负责人通知维护人员，并提供可用于 验收测试的文档和程序升级包。 系统维护人员检查开发负责人提交 的资料是否完整、有效，版本是否最新，并对移交程序的内容进行 验收并形成记录。 （三） 维护

8、人员制定用户测试计划， 由需求部门按照测试计划构建验收测 试环境，进行验收测试并对测试内容进行记录。验收测试通过后， 由需求部门在验收报告书 （附件六）上出具验收结论并会同信 息部门签署下发意见。 （四） 如果任务实现由合作厂商完成， 则由开发负责人员在内部任务验收 完成后，根据需求部门的验收意见，在厂商维护申请单上出具 验收结论并会同需求部门签署下发意见。 四、程序下发及系统上线 （一） 下发程序经需求部门正式验收后由系统维护人员将要发布的程序 进行打包下发。程序下发前，系统维护人员需填写程序下发申请 表 （附件七）并经过维护部门负责人审批。 （二） 如果通过网络发布程序， 则需通过指定路径

9、或程序服务器发布，并 且对相关访问人员的权限进行控制。 （三） 下发程序接收公司的系统维护人员在收到下发的程序包后，联系需 求部门进行安装测试，测试结束后在系统上线申请表（附件八） 的“需求部门意见”中填写验收意见，并签字确认。 （四） 程序上线实施完毕以后，系统维护人员需填写升级情况反馈表 （附件九），填写完毕后将升级情况反馈表上报到上级公司信 息部程序下发人员。 （五） 各级公司系统维护人员应在软件程序变更上线前，严格遵照程序下 发要求，建立完善的“回退”计划（参见软件开发制度中试 运行计划的应急预案）以避免升级失败，并确保系统及时更新到 最新版本。 五、文档整理归档 系统变更任务结束后，

10、 由专门人员将整个过程中产生文档的最终版 本进行统一归档管理。 附件二紧急变更流程 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应 应应 应 应应 应 应 应 应应 应 应 应应 应 应应 应 应 应应 应 应 应 应应 应 应 应应 应 应应 应 应 应应 应 应 应应 应 应 应 应 应 应 应应 应 应 应 应应 应 应应 应 应 应应 应 应应 应 应应 应 应 应应 应 应 应 应 应应 应 应应 应 应 应应 应 应 应应 应 应 应 应 应 应应 应 应应 应 应 应/ 应应 应 应 应应 应 应 应 应 应

11、 应 应应 应 应 应应 应 应 应应 应 应 应 应应 应 应 应 应 应 应应 应 应 应 应应 应 应 应应 应 应应 应 应 应 应 应 应 应应 应 应 应 应应 / 应应 应 应应 应 应 应应 应 应 应 应应 应 应 应 / 应 应应 应 应应 应 应 应 应 应 应 应 应 应 应 应 应 应应 应 应 应 应应 应 应应 应 应 应应 应 应应 应 应 应应 应 应 应应 应 应 应 应 紧急变更流程步骤 紧急变更处理过程中的上报、请示、批准等需通过电子邮件、传真 等书面形式进行， 待问题解决后再按照一般系统变更流程补办各类文档 和审批记录。 一、 紧急变更的报告 用户部门

12、人员或其他人员发现系统异常，导致业务处理无法正常进 行，必须迅速处理解决时，应及时将问题报告给信息部。 如公司信息部相关人员判定此问题需进行程序紧急变更，则报相关 负责人要求执行程序紧急变更流程。 二、 紧急变更的启动 信息部相关负责人接到紧急变更申报后，指定紧急变更任务负责人 （通常为应用系统管理人员） ，负责解决本次的紧急变更问题。紧急变 更任务负责人根据重要性和紧迫性区分变更的优先级，组织人员采取相 应的处理措施。 三、 紧急变更的处理 紧急变更流程涉处理同一般程序变更流程处理步骤。其中包括需求 分析、程序设计、程序实施、程序测试、程序验收，但需使用专设的系 统用户账号进行紧急变更处理，

13、并进行紧急变更的记录。 四、 紧急变更程序的下发 / 上线 紧急变更任务负责人组织完成变更处理后，尽快向公司信息部相关 负责人报告，并提出下发 / 上线申请，经批准后，进行程序下发/ 上线操 作。 五、 补办文档和领导审批记录 紧急问题得到妥善解决后， 需要分别补办各类文档和审批记录，其 中包括： （一） 问题发现人填写的紧急问题变更申请，其中包含问题发现人对 问题的描述。 （二） 问题发现人所在部门的负责人对申请审批的记录。 （三） 公司信息部相关负责人对需求的审批和任务分派记录。 （四） 开发人员书面的设计方案和公司信息部相关负责人对设计方案 的审批记录。 （五） 需求部门 / 信息部的测

14、试记录和签字确认的测试结果。 （六） 程序下发 / 上线专责人员填写的下发/ 上线申请和公司信息部相 关负责人的审批记录。 信息部负责人指派专人定期对紧急变更记录文档进行检查， 六、 文档整理归档 按照一般问题系统变更流程的要求，各级公司将紧急事件变更整个 过程中的各类文档进行统一归档管理 附件三变更申请书 变更申请书 中国铝业股份有限公司 需求部门 任务书编号格式： RWSN- 年份- 序号 厂商维护申请单编号对应的厂商维护申请单编号，厂商维护申请单下 达后补录 系统名称 系统名称英文缩写系统版本 任 务 提 交 栏*由需求部门填写 * 任务名称 建议开始时间建议完成时间 任务紧急程度普通紧

15、急特急 【任务概述】 ：*如包含多项内容，按顺序列出* 【附加文档】 ：*由双方确认的需求说明书、变更说明书或系统BUG 管理表 * 【需求部门意见】 ： 申请人签字：日期： 部门负责人签字：日期： 任 务 接 收 栏*由信息部填写 * 任务性质 A:开发 B:改正性维护（识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的 误使用） C:适应性维护（因外部环境或数据环境的变化引发的修改） D:完善性维护（因用户对软件功能提出新的功能和性能需求引发的修改） E:其他（上述以外的修正） 计划开始时间计划完成时间 处理优先级排队优先紧 急 任务实现方式自行开发外包开发 合作开发 预计工作量人天，

16、合人月 本次任务计划费 用预估 i. * 注明小写金额和大写金额 * ii.￥元， （大写） 【变更风险评估】 ：*任务实现对现有系统运行性能和功能等方面带来的影响评估* 对原有系统的数据和程序是否有可能破坏的风险？ 对原有系统的安全设计是否有可能破坏的风险？ 对整个网络的构架是否有可能破坏的风险？ 其他可能存在的风险？ 【信息部意见】 ： 系统维护负责人签字：日期： 部门负责人签字：日期： 附件四任务管理表 任务管理表 日期 变更申请书 编号 厂商维护申 请单编号 需求部门系统名称任务名称 信息部 负责人 任务状态备注 附件五厂商维护申请单 厂商维护申请单 甲方（委托方）中国铝业股份有限公司

17、 乙方（受托方） 任务书编号格式：系统名称英文缩写-RWSW- 年月-序号 变更申请书编号对应的变更申请书编号 系统名称 系统名称英文缩写系统版本 任 务 下 达 栏*由甲方填写 * 任务名称 任务性质 A:开发 B:改正性维护（识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误 使用） C:适应性维护（因外部环境或数据环境的变化引发的修改） D:完善性维护（因用户对软件功能提出新的功能和性能需求引发的修改） E:其他（上述以外的修正） 计划开始时间计划完成时间 处理优先级排队优先紧急 预计工作量人天，合人月 本次任务计划税 前开发费用预估 （含报酬） iii. * 注明小写金额和大写金

18、额* iv.￥元， （大写） 【任务概述】 ：* 如包含多项内容，按顺序列出* 【附加文档】 ：* 由双方确认的需求规格说明书、变更说明或系统BUG 管理表 * 【甲方意见】 ： 开发负责人签字：日期： 信息部负责人签字：日期： 任 务 接 收 栏*由乙方填写 * 【乙方意见】 ： 项目负责人签字：日期： 负责人签字：日期： 任 务 完 成 情 况 栏*由乙方填写，双方签字确认 * 实际开始时间实际完成时间 实际工作量人天，合人月 本次任务实际税 前开发费用（含 报酬） *注明小写金额和大写金额 * ￥元， （大写） 【完成情况】 ：*由乙方简要概述任务完成情况 * 【提交文档】 ：*由乙方提

19、交的技术文档、测试文档、使用文档与程序代码等* 甲方开发负责人签字：乙方项目负责人签字： 日期：日 期： 任 务 验 收 情 况 栏*由甲方填写，双方签字确认 * 【验收结论】 ： * 由甲方根据验收报告出具验收结论* 甲方开发负责人签字：乙方项目负责人签字： 日期：日期： 甲方负责人签字：乙方负责人签字： 日期：日期： 注：该表格一式两份，甲乙双方各执一份。 附件六验收报告书 验收报告书 中国铝业股份有限公司 需求部门 对应任务书编号对应的变更申请书编号 系统名称 系统名称英文缩写系统版本 任 务 完 成 情 况 栏*由信息部根据任务完成实际情况填写* 任务名称 实际开始时间实际完成时间 实

20、际工作量人天，合人月 本次任务实际税 前开发费用（含 报酬） *注明小写金额和大写金额 * ￥元， （大写） 【任务完成情况】 ：*由信息部简要概述任务完成情况* 【提交文档清单】 ：*由信息部提交相关文档清单 * 需求部门接受人签字：信息部提交人签字： 日期：日 期： 验 收 过 程 信 息 栏*由信息部根据验收过程填写 * 验收开始时间验收完成时间 验收地点 需求部门 验收人员 角色 / 职责 信息部 协助人员 角色 / 职责 任 务 验 收 情 况 栏*由需求部门根据验收情况出具 * 【验收意见】 ：*由需求部门项目负责人出具对实际验收结果的意见* 任 务 验 收 结 论 栏*由需求部门

21、出具，双方负责人签字确认* 【验收结论】 ：*由需求部门根据验收意见出具任务验收结论* 【下发意见】 ：*由需求部门根据验收结论出具程序下发意见* 需求部门负责人签字：信息部负责人签字： 日期：日期： 注：该表格一式两份，需求部门、信息部双方各执一份。 附件七程序下发申请表 程序下发申请表 中国铝业股份有限公司 申请方 申请表编号 系统名称 系统名称英文缩写系统版本 申 请 栏*由申请方填写 * 版本类型升级补丁其他实施日期 【情况说明】 ： 【附件】：*如升级说明文档，下发程序 * 申请人签字：日期： 下 发审批 栏*由审批方填写 * 【需求部门意见】 ： 负责人签字：日期： 【信息部意见】

22、 ： 负责人签字：日期： 附件八系统上线申请表 系统上线申请表 中国铝业股份有限公司 申请方 申请表编号 系统名称 系统名称英文缩写系统版本 上 线 申 请 栏*由申请方填写 * 版本类型升级补丁其他实施日期 【情况说明】 ： 【附件】：*如升级说明文档，上线程序 * 【上线计划】 1. 工作条件 2. 进度表 任务名称及其描述开始时间结束时间参加人员 任务 1 任务 2 【应急预案】 ： 1 分析引发上线失败的潜在原因 2 预防措施 3 事件处理 4 回退计划 5 组织机制 应急处理人员角色职责 申请人签字：日期： 上 线 审 批 栏*由审批方填写 * 【需求部门意见】 ： 负责人签字：日期： 【信息部意见】 ： 负责人签字：日期： 附件九升级情况反馈表 升级情况反馈表 中国铝业股份有限公司 公司名称 反馈表编号 系统名称 系统名称英文缩写系统版本 情 况 反 馈 栏 目标版本实施日期 升级结果升级完成升级失败升级延迟 / 未进行 【系统参数说明】 ：*包括运行环境、应用系统版本 * 【升级过程说明】 ： 【升级问题情况】 ： 下发实施人签字：日期： 实施人上级主管签字：日期：