软件变更管理制度(试行)
第一节 总则
第一条
第二条
第三条
第四条
第五条
第六条
第七条
第八条
第九条
第十条
为规范软件变更与维护管理,提高软件管理水平,优化软件变更与维护管理流程,特制定本制度。
软件变更与维护管理主要包括一般性变更、紧急变更、用户测试、版本控制、系统更新和权限管理等内容。
本制度适用于中国铝业股份有限公司总部和各分子公司(含郑州研究院)(以下简称“公司”)。
第二节 一般性变更流程
需求部门提出系统变更需求,并将变更需求整理成《变更申请书》(附件三),由部门负责人审批后提交给信息部。
信息部负责接受需求、分析需求,并提出系统变更建议。信息部负责人审批《变更申请书》。
信息部根据自行开发、合作开发和外包开发的不同要求组织实现系统变更需求,产生供发布的程序。
信息部将所有的变更请求记录在《任务管理表》(附件四)中,并按照优先级安排实施的先后次序进行跟踪处理。
信息部负责对系统变更过程的文档进行归档管理,所有文档至少保存三年。详细流程参见《系统变更流程》(附件一)。
第三节 紧急变更流程
对于紧急变更,需求部门可以通过电子邮件或传真等书面形式提出申请。
信息部按照事先明确的紧急变更定义做出判断,确定其优先级和
第十一条
第十二条
第十三条
第十四条
第十五条
第十六条
第十七条 第十八条 第十九条
第二十条
第二十一条影响程度,并进行相应的处理。
紧急变更过程中应使用专设系统用户帐号,由专责部门或人员启动紧急修改变更程序。信息部应对紧急变更的处理进行规范的文档记录。
在紧急事件处理完成后,必须补办正式、完整的文档。详细流程参见《紧急变更流程》(附件二)。
第四节 系统的版本控制
软件变更时,加强版本控制,确保每次在最新的代码基础上进行更改。
应对下发的软件进行版本控制,由专责人员负责发布软件的版本管理。
第五节 系统变更的责权分离
应加强对运行环境的访问控制,只允许授权的用户访问运行环境中的应用系统。通过物理和逻辑隔离的手段,控制对运行环境的访问。
限制开发人员对运行环境中应用程序文件夹的访问权限,只有经过授权的人员才拥有相应的权限。
对授权访问运行环境的人员进行详细记录,并定期进行检查。 普通用户只能通过前台登录系统,不能通过后台进行操作。 系统维护人员不应该拥有前台应用程序的访问权限,更不应该在前台应用程序中担任实际的操作任务。
禁止系统维护人员共享操作系统级别的账号。
第六节 附则
本制度由公司总部信息部负责解释和修订。
第二十二条 本制度自发布之日起开始执行。
附件一 系统变更流程
4
系统变更流程步骤:
一、任务提交和接受:
本流程中需求部门为应用系统构建时提出需求的业务部门,维护部门为负责按照需求实际构建应用系统的信息部。流程如下: (一) 需求形成:
需求方根据业务的需要,结合收到的其他用户部门要求,填写《变更申请书》。
(二) 需求方负责人审批
需求方将《变更申请书》报请部门负责人签字批准后,经指定途径提交给信息部相关系统维护人员。
(三) 需求评估
系统维护人员审查需求,会同相关开发负责人进行需求评估,产生评估结果。
(四) 信息部负责人审批
系统维护人员将评估结果附在《变更申请书》后,报请部门负责人签字批准后,正式向开发负责人下达任务。
如果任务实现由合作厂商完成,则由开发负责人按照与合作厂商签订的技术服务合同,填写《厂商维护申请单》(附件五),报请部门负责人签字批准后,正式向合作厂商下达任务。
(五) 任务登记
为了便于追踪各个系统变更需求的状态,维护人员需要对需求进行登记。
信息部每周对《任务管理表》中的需求完成状态进行更新,以便信息部负责人监控系统变更任务进度。 二、任务实现
信息部开发负责人(或由开发负责人会同合作厂商)根据《变更申请书》的需求描述,按照与软件开发流程同样的步骤,进行分析、设计、
编码、测试,最终完成系统变更需求。 三、任务验收及用户测试
(一) 任务验收以需求部门为主,信息部配合完成。
(二) 任务开发测试完成后,由开发负责人通知维护人员,并提供可用于
验收测试的文档和程序升级包。系统维护人员检查开发负责人提交的资料是否完整、有效,版本是否最新,并对移交程序的内容进行验收并形成记录。
(三) 维护人员制定用户测试计划,由需求部门按照测试计划构建验收测
试环境,进行验收测试并对测试内容进行记录。验收测试通过后,由需求部门在《验收报告书》(附件六)上出具验收结论并会同信息部门签署下发意见。
(四) 如果任务实现由合作厂商完成,则由开发负责人员在内部任务验收
完成后,根据需求部门的验收意见,在《厂商维护申请单》上出具验收结论并会同需求部门签署下发意见。
四、程序下发及系统上线
(一) 下发程序经需求部门正式验收后由系统维护人员将要发布的程序
进行打包下发。程序下发前,系统维护人员需填写《程序下发申请表》(附件七)并经过维护部门负责人审批。
(二) 如果通过网络发布程序,则需通过指定路径或程序服务器发布,并
且对相关访问人员的权限进行控制。
(三) 下发程序接收公司的系统维护人员在收到下发的程序包后,联系需
求部门进行安装测试,测试结束后在《系统上线申请表》(附件八)的“需求部门意见”中填写验收意见,并签字确认。
(四) 程序上线实施完毕以后,系统维护人员需填写《升级情况反馈表》
(附件九),填写完毕后将《升级情况反馈表》上报到上级公司信息部程序下发人员。
(五) 各级公司系统维护人员应在软件程序变更上线前,严格遵照程序下
发要求,建立完善的“回退”计划(参见《软件开发制度》中《试运行计划》的应急预案)以避免升级失败,并确保系统及时更新到
最新版本。
五、文档整理归档
系统变更任务结束后,由专门人员将整个过程中产生文档的最终版本进行统一归档管理。
附件二 紧急变更流程
8
紧急变更流程步骤
紧急变更处理过程中的上报、请示、批准等需通过电子邮件、传真等书面形式进行,待问题解决后再按照一般系统变更流程补办各类文档和审批记录。
一、 紧急变更的报告
用户部门人员或其他人员发现系统异常,导致业务处理无法正常进行,必须迅速处理解决时,应及时将问题报告给信息部。
如公司信息部相关人员判定此问题需进行程序紧急变更,则报相关负责人要求执行程序紧急变更流程。
二、 紧急变更的启动
信息部相关负责人接到紧急变更申报后,指定紧急变更任务负责人(通常为应用系统管理人员),负责解决本次的紧急变更问题。紧急变更任务负责人根据重要性和紧迫性区分变更的优先级,组织人员采取相应的处理措施。
三、 紧急变更的处理
紧急变更流程涉处理同一般程序变更流程处理步骤。其中包括需求分析、程序设计、程序实施、程序测试、程序验收,但需使用专设的系统用户账号进行紧急变更处理,并进行紧急变更的记录。
四、 紧急变更程序的下发/上线
紧急变更任务负责人组织完成变更处理后,尽快向公司信息部相关负责人报告,并提出下发/上线申请,经批准后,进行程序下发/上线操作。
五、 补办文档和领导审批记录
紧急问题得到妥善解决后,需要分别补办各类文档和审批记录,其中包括:
(一) 问题发现人填写的紧急问题变更申请,其中包含问题发现人对
问题的描述。
(二) 问题发现人所在部门的负责人对申请审批的记录。 (三) 公司信息部相关负责人对需求的审批和任务分派记录。 (四) 开发人员书面的设计方案和公司信息部相关负责人对设计方案
的审批记录。
(五) 需求部门/信息部的测试记录和签字确认的测试结果。 (六) 程序下发/上线专责人员填写的下发/上线申请和公司信息部相
关负责人的审批记录。
信息部负责人指派专人定期对紧急变更记录文档进行检查,
六、 文档整理归档
按照一般问题系统变更流程的要求,各级公司将紧急事件变更整个过程中的各类文档进行统一归档管理
附件三 变更申请书
11
12
附件四 任务管理表
任务管理表
附件五 厂商维护申请单
注:该表格一式两份,甲乙双方各执一份。
附件六 验收报告书
注:该表格一式两份,需求部门、信息部双方各执一份。
附件七 程序下发申请表
附件八 系统上线申请表
中国铝业信息技术管理制度
附件九 升级情况反馈表
21
软件变更管理制度(试行)
第一节 总则
第一条
第二条
第三条
第四条
第五条
第六条
第七条
第八条
第九条
第十条
为规范软件变更与维护管理,提高软件管理水平,优化软件变更与维护管理流程,特制定本制度。
软件变更与维护管理主要包括一般性变更、紧急变更、用户测试、版本控制、系统更新和权限管理等内容。
本制度适用于中国铝业股份有限公司总部和各分子公司(含郑州研究院)(以下简称“公司”)。
第二节 一般性变更流程
需求部门提出系统变更需求,并将变更需求整理成《变更申请书》(附件三),由部门负责人审批后提交给信息部。
信息部负责接受需求、分析需求,并提出系统变更建议。信息部负责人审批《变更申请书》。
信息部根据自行开发、合作开发和外包开发的不同要求组织实现系统变更需求,产生供发布的程序。
信息部将所有的变更请求记录在《任务管理表》(附件四)中,并按照优先级安排实施的先后次序进行跟踪处理。
信息部负责对系统变更过程的文档进行归档管理,所有文档至少保存三年。详细流程参见《系统变更流程》(附件一)。
第三节 紧急变更流程
对于紧急变更,需求部门可以通过电子邮件或传真等书面形式提出申请。
信息部按照事先明确的紧急变更定义做出判断,确定其优先级和
第十一条
第十二条
第十三条
第十四条
第十五条
第十六条
第十七条 第十八条 第十九条
第二十条
第二十一条影响程度,并进行相应的处理。
紧急变更过程中应使用专设系统用户帐号,由专责部门或人员启动紧急修改变更程序。信息部应对紧急变更的处理进行规范的文档记录。
在紧急事件处理完成后,必须补办正式、完整的文档。详细流程参见《紧急变更流程》(附件二)。
第四节 系统的版本控制
软件变更时,加强版本控制,确保每次在最新的代码基础上进行更改。
应对下发的软件进行版本控制,由专责人员负责发布软件的版本管理。
第五节 系统变更的责权分离
应加强对运行环境的访问控制,只允许授权的用户访问运行环境中的应用系统。通过物理和逻辑隔离的手段,控制对运行环境的访问。
限制开发人员对运行环境中应用程序文件夹的访问权限,只有经过授权的人员才拥有相应的权限。
对授权访问运行环境的人员进行详细记录,并定期进行检查。 普通用户只能通过前台登录系统,不能通过后台进行操作。 系统维护人员不应该拥有前台应用程序的访问权限,更不应该在前台应用程序中担任实际的操作任务。
禁止系统维护人员共享操作系统级别的账号。
第六节 附则
本制度由公司总部信息部负责解释和修订。
第二十二条 本制度自发布之日起开始执行。
附件一 系统变更流程
4
系统变更流程步骤:
一、任务提交和接受:
本流程中需求部门为应用系统构建时提出需求的业务部门,维护部门为负责按照需求实际构建应用系统的信息部。流程如下: (一) 需求形成:
需求方根据业务的需要,结合收到的其他用户部门要求,填写《变更申请书》。
(二) 需求方负责人审批
需求方将《变更申请书》报请部门负责人签字批准后,经指定途径提交给信息部相关系统维护人员。
(三) 需求评估
系统维护人员审查需求,会同相关开发负责人进行需求评估,产生评估结果。
(四) 信息部负责人审批
系统维护人员将评估结果附在《变更申请书》后,报请部门负责人签字批准后,正式向开发负责人下达任务。
如果任务实现由合作厂商完成,则由开发负责人按照与合作厂商签订的技术服务合同,填写《厂商维护申请单》(附件五),报请部门负责人签字批准后,正式向合作厂商下达任务。
(五) 任务登记
为了便于追踪各个系统变更需求的状态,维护人员需要对需求进行登记。
信息部每周对《任务管理表》中的需求完成状态进行更新,以便信息部负责人监控系统变更任务进度。 二、任务实现
信息部开发负责人(或由开发负责人会同合作厂商)根据《变更申请书》的需求描述,按照与软件开发流程同样的步骤,进行分析、设计、
编码、测试,最终完成系统变更需求。 三、任务验收及用户测试
(一) 任务验收以需求部门为主,信息部配合完成。
(二) 任务开发测试完成后,由开发负责人通知维护人员,并提供可用于
验收测试的文档和程序升级包。系统维护人员检查开发负责人提交的资料是否完整、有效,版本是否最新,并对移交程序的内容进行验收并形成记录。
(三) 维护人员制定用户测试计划,由需求部门按照测试计划构建验收测
试环境,进行验收测试并对测试内容进行记录。验收测试通过后,由需求部门在《验收报告书》(附件六)上出具验收结论并会同信息部门签署下发意见。
(四) 如果任务实现由合作厂商完成,则由开发负责人员在内部任务验收
完成后,根据需求部门的验收意见,在《厂商维护申请单》上出具验收结论并会同需求部门签署下发意见。
四、程序下发及系统上线
(一) 下发程序经需求部门正式验收后由系统维护人员将要发布的程序
进行打包下发。程序下发前,系统维护人员需填写《程序下发申请表》(附件七)并经过维护部门负责人审批。
(二) 如果通过网络发布程序,则需通过指定路径或程序服务器发布,并
且对相关访问人员的权限进行控制。
(三) 下发程序接收公司的系统维护人员在收到下发的程序包后,联系需
求部门进行安装测试,测试结束后在《系统上线申请表》(附件八)的“需求部门意见”中填写验收意见,并签字确认。
(四) 程序上线实施完毕以后,系统维护人员需填写《升级情况反馈表》
(附件九),填写完毕后将《升级情况反馈表》上报到上级公司信息部程序下发人员。
(五) 各级公司系统维护人员应在软件程序变更上线前,严格遵照程序下
发要求,建立完善的“回退”计划(参见《软件开发制度》中《试运行计划》的应急预案)以避免升级失败,并确保系统及时更新到
最新版本。
五、文档整理归档
系统变更任务结束后,由专门人员将整个过程中产生文档的最终版本进行统一归档管理。
附件二 紧急变更流程
8
紧急变更流程步骤
紧急变更处理过程中的上报、请示、批准等需通过电子邮件、传真等书面形式进行,待问题解决后再按照一般系统变更流程补办各类文档和审批记录。
一、 紧急变更的报告
用户部门人员或其他人员发现系统异常,导致业务处理无法正常进行,必须迅速处理解决时,应及时将问题报告给信息部。
如公司信息部相关人员判定此问题需进行程序紧急变更,则报相关负责人要求执行程序紧急变更流程。
二、 紧急变更的启动
信息部相关负责人接到紧急变更申报后,指定紧急变更任务负责人(通常为应用系统管理人员),负责解决本次的紧急变更问题。紧急变更任务负责人根据重要性和紧迫性区分变更的优先级,组织人员采取相应的处理措施。
三、 紧急变更的处理
紧急变更流程涉处理同一般程序变更流程处理步骤。其中包括需求分析、程序设计、程序实施、程序测试、程序验收,但需使用专设的系统用户账号进行紧急变更处理,并进行紧急变更的记录。
四、 紧急变更程序的下发/上线
紧急变更任务负责人组织完成变更处理后,尽快向公司信息部相关负责人报告,并提出下发/上线申请,经批准后,进行程序下发/上线操作。
五、 补办文档和领导审批记录
紧急问题得到妥善解决后,需要分别补办各类文档和审批记录,其中包括:
(一) 问题发现人填写的紧急问题变更申请,其中包含问题发现人对
问题的描述。
(二) 问题发现人所在部门的负责人对申请审批的记录。 (三) 公司信息部相关负责人对需求的审批和任务分派记录。 (四) 开发人员书面的设计方案和公司信息部相关负责人对设计方案
的审批记录。
(五) 需求部门/信息部的测试记录和签字确认的测试结果。 (六) 程序下发/上线专责人员填写的下发/上线申请和公司信息部相
关负责人的审批记录。
信息部负责人指派专人定期对紧急变更记录文档进行检查,
六、 文档整理归档
按照一般问题系统变更流程的要求,各级公司将紧急事件变更整个过程中的各类文档进行统一归档管理
附件三 变更申请书
11
12
附件四 任务管理表
任务管理表
附件五 厂商维护申请单
注:该表格一式两份,甲乙双方各执一份。
附件六 验收报告书
注:该表格一式两份,需求部门、信息部双方各执一份。
附件七 程序下发申请表
附件八 系统上线申请表
中国铝业信息技术管理制度
附件九 升级情况反馈表
21