软件变更管理制度(试行) -标准化文件发布号：（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII
软件变更管理制度（试行）
第一节总则
第一条为规范软件变更与维护管理，提高软件管理水平，优化软件变更与维护管理流程，特制定本制度。

第二条软件变更与维护管理主要包括一般性变更、紧急变更、用户测试、版本控制、系统更新和权限管理等内容。

第三条本制度适用于中国铝业股份有限公司总部和各分子公司（含郑州研究院）（以下简称“公司”）。

第二节一般性变更流程
第四条需求部门提出系统变更需求，并将变更需求整理成《变更申请书》（附件三），由部门负责人审批后提交给信息部。

第五条信息部负责接受需求、分析需求，并提出系统变更建议。

信息部负责人审批《变更申请书》。

第六条信息部根据自行开发、合作开发和外包开发的不同要求组织实现系统变更需求，产生供发布的程序。

第七条信息部将所有的变更请求记录在《任务管理表》（附件四）中，并按照优先级安排实施的先后次序进行跟踪处理。

第八条信息部负责对系统变更过程的文档进行归档管理，所有文档至少保存三年。

详细流程参见《系统变更流程》（附件一）。

第三节紧急变更流程
第九条对于紧急变更，需求部门可以通过电子邮件或传真等书面形式提出申请。

第十条信息部按照事先明确的紧急变更定义做出判断，确定其优先级和影响程度，并进行相应的处理。

第十一条紧急变更过程中应使用专设系统用户帐号，由专责部门或人员启动紧急修改变更程序。

信息部应对紧急变更的处理进行规范的文
档记录。

第十二条在紧急事件处理完成后，必须补办正式、完整的文档。

详细流程参见《紧急变更流程》（附件二）。

第四节系统的版本控制
第十三条软件变更时，加强版本控制，确保每次在最新的代码基础上进行更改。

第十四条应对下发的软件进行版本控制，由专责人员负责发布软件的版本管理。

第五节系统变更的责权分离
第十五条应加强对运行环境的访问控制，只允许授权的用户访问运行环境中的应用系统。

通过物理和逻辑隔离的手段，控制对运行环境的
访问。

第十六条限制开发人员对运行环境中应用程序文件夹的访问权限，只有经过授权的人员才拥有相应的权限。

第十七条对授权访问运行环境的人员进行详细记录，并定期进行检查。

第十八条普通用户只能通过前台登录系统，不能通过后台进行操作。

第十九条系统维护人员不应该拥有前台应用程序的访问权限，更不应该在前台应用程序中担任实际的操作任务。

第二十条禁止系统维护人员共享操作系统级别的账号。

第六节附则
第二十一条本制度由公司总部信息部负责解释和修订。

第二十二条本制度自发布之日起开始执行。

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

流程如下：
（一）需求形成：
需求方根据业务的需要，结合收到的其他用户部门要求，填写《变
更申请书》。

（二）需求方负责人审批
需求方将《变更申请书》报请部门负责人签字批准后，经指定途径
提交给信息部相关系统维护人员。

（三）需求评估
系统维护人员审查需求，会同相关开发负责人进行需求评估，产生
评估结果。

（四）信息部负责人审批
系统维护人员将评估结果附在《变更申请书》后，报请部门负责人
签字批准后，正式向开发负责人下达任务。

如果任务实现由合作厂商完成，则由开发负责人按照与合作厂商签
订的技术服务合同，填写《厂商维护申请单》（附件五），报请部
门负责人签字批准后，正式向合作厂商下达任务。

（五）任务登记
为了便于追踪各个系统变更需求的状态，维护人员需要对需求进行
登记。

信息部每周对《任务管理表》中的需求完成状态进行更新，以便信
息部负责人监控系统变更任务进度。

二、任务实现
信息部开发负责人（或由开发负责人会同合作厂商）根据《变更申请书》的需求描述，按照与软件开发流程同样的步骤，进行分析、
设计、编码、测试，最终完成系统变更需求。

三、任务验收及用户测试
（一）任务验收以需求部门为主，信息部配合完成。

（二）任务开发测试完成后，由开发负责人通知维护人员，并提供可用于验收测试的文档和程序升级包。

系统维护人员检查开发负责人
提交的资料是否完整、有效，版本是否最新，并对移交程序的内
容进行验收并形成记录。

（三）维护人员制定用户测试计划，由需求部门按照测试计划构建验收测试环境，进行验收测试并对测试内容进行记录。

验收测试通过
后，由需求部门在《验收报告书》（附件六）上出具验收结论并
会同信息部门签署下发意见。

（四）如果任务实现由合作厂商完成，则由开发负责人员在内部任务验收完成后，根据需求部门的验收意见，在《厂商维护申请单》上
出具验收结论并会同需求部门签署下发意见。

四、程序下发及系统上线
（一）下发程序经需求部门正式验收后由系统维护人员将要发布的程序进行打包下发。

程序下发前，系统维护人员需填写《程序下发申
请表》（附件七）并经过维护部门负责人审批。

（二）如果通过网络发布程序，则需通过指定路径或程序服务器发布，并且对相关访问人员的权限进行控制。

（三）下发程序接收公司的系统维护人员在收到下发的程序包后，联系需求部门进行安装测试，测试结束后在《系统上线申请表》（附
件八）的“需求部门意见”中填写验收意见，并签字确认。

（四）程序上线实施完毕以后，系统维护人员需填写《升级情况反馈表》（附件九），填写完毕后将《升级情况反馈表》上报到上级
公司信息部程序下发人员。

（五）各级公司系统维护人员应在软件程序变更上线前，严格遵照程序下发要求，建立完善的“回退”计划（参见《软件开发制度》中
《试运行计划》的应急预案）以避免升级失败，并确保系统及时
更新到最新版本。

五、文档整理归档
系统变更任务结束后，由专门人员将整个过程中产生文档的最终版本进行统一归档管理。

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

一、紧急变更的报告
用户部门人员或其他人员发现系统异常，导致业务处理无法正常进行，必须迅速处理解决时，应及时将问题报告给信息部。

如公司信息部相关人员判定此问题需进行程序紧急变更，则报相关负责人要求执行程序紧急变更流程。

二、紧急变更的启动
信息部相关负责人接到紧急变更申报后，指定紧急变更任务负责人（通常为应用系统管理人员），负责解决本次的紧急变更问题。

紧
急变更任务负责人根据重要性和紧迫性区分变更的优先级，组织人员
采取相应的处理措施。

三、紧急变更的处理
紧急变更流程涉处理同一般程序变更流程处理步骤。

其中包括需求分析、程序设计、程序实施、程序测试、程序验收，但需使用专设
的系统用户账号进行紧急变更处理，并进行紧急变更的记录。

四、紧急变更程序的下发/上线
紧急变更任务负责人组织完成变更处理后，尽快向公司信息部相关负责人报告，并提出下发/上线申请，经批准后，进行程序下发/上
线操作。

五、补办文档和领导审批记录
紧急问题得到妥善解决后，需要分别补办各类文档和审批记录，其中包括：
（一）问题发现人填写的紧急问题变更申请，其中包含问题发现人对问题的描述。

（二）问题发现人所在部门的负责人对申请审批的记录。

（三）公司信息部相关负责人对需求的审批和任务分派记录。

（四）开发人员书面的设计方案和公司信息部相关负责人对设计方案的审批记录。

（五）需求部门/信息部的测试记录和签字确认的测试结果。

（六）程序下发/上线专责人员填写的下发/上线申请和公司信息部相关负责人的审批记录。

信息部负责人指派专人定期对紧急变更记录文档进行检查，
六、文档整理归档
按照一般问题系统变更流程的要求，各级公司将紧急事件变更整个过程中的各类文档进行统一归档管理
附件三变更申请书
附件四任务管理表
附件五厂商维护申请单
附件六验收报告书
验收报告书
中国铝业股份有限公司
需求部门
对应任务书编号对应的变更申请书编号
系统名称
系统名称英文缩写系统版本
任务完成情况栏*由信息部根据任务完成实际情况填写*
任务名称
实际开始时间实际完成时间
实际工作量人天，合人月
本次任务实际
税前开发费用
（含报酬）
*注明小写金额和大写金额*
￥元，（大写）
【任务完成情况】：*由信息部简要概述任务完成情况*
【提交文档清单】：*由信息部提交相关文档清单*
需求部门接受人签字：信息部提交人签字：
日期：日期：
验收过程信息栏*由信息部根据验收过程填写*
验收开始时间验收完成时间
验收地点
需求部门
验收人员
角色/职责
信息部
协助人员
角色/职责
附件七程序下发申请表
附件八系统上线申请表
附件九升级情况反馈表。