内部控制~信息系统变更处理规章制度方针.doc
《内部控制~信息系统变更处理规章制度方针.doc》由会员分享,可在线阅读,更多相关《内部控制~信息系统变更处理规章制度方针.doc(7页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。
1、.软件变更管理制度 第一节 总 则 第一条 为规范软件变更与维护管理,提高软件管理水平,优化软件变更与维护管理流程, 特制定本制度。 第二条 本制度适用于应用系统已开发或采购完毕并正式上线、且由软件开发组织移交给应 用管理组织之后,所发生的生产应用系统(以下简称应用系统)运行支持及系统变 更工作。 第二节 变更流程 第三条 系统变更工作可分为下面三类类型:功能完善维护、系统缺陷修改、统计报表生成。 功能完善维护指根据业务部门的需求,对系统进行的功能完善性或适应性维护;系 统缺陷修改指对一些系统功能或使用上的问题所进行的修复,这些问题是由于系统 设计和实现上的缺陷而引发的;统计报表生成指为了满足
2、业务部门统计报表数据生 成的需要,而进行的不包含在应用系统功能之内的数据处理工作。 第四条 系统变更工作以任务形式由需求方(一般为业务部门)和维护方(一般为信息部门 的应用维护组织和软件开发组织,还包括合作厂商)协作完成。系统变更过程类似 软件开发,大致可分为四个阶段:任务提交和接受、任务实现、任务验收和程序下 发上线。 第五条 因问题处理引发的系统变更处理,具体流程参见问题处理管理制度 。 第六条 需求部门提出系统变更需求,并将变更需求整理成系统变更申请表 (附件一) , 由部门负责人审批后提交给系统管理员。 第七条 系统管理员负责接受需求并上报给IT主管。IT主管分析需求,并提出系统变更建
3、 议。IT经理根据变更建议审批系统变更申请表 。 第八条 系统管理员根据自行开发、合作开发和外包开发的不同要求组织实现系统变更需求, 将需求提交至内部开发人员、合作开发商或外包开发商,产生供发布的程序。 第九条 实现过程应按照软件开发过程规定进行。系统变更过程应遵循软件开发过程相同的 正式、统一的编码标准,并经过测试和正式验收才能下发和上线。 第十条 系统管理员组织业务部门的系统最终用户对系统程序变更进行测试,并撰写用户.测试报告 (附件二) ,提交业务部门负责人和IT主管领导签字确认通过。 第十一条 在系统变更完成后,系统管理员和业务部门的最终用户共同撰写程序变更验收报 告 (附件三) ,经
4、业务部门负责人签字验收后,报送IT经理审批。 第十二条 培训管理员负责对系统变更过程的文档进行归档管理,变更过程中涉及的所有文档 应至少保存两年。 第三节 紧急变更流程 第十三条 对于紧急变更,需求部门可以通过电子邮件或传真等书面形式提出申请。 第十四条 信息技术部根据重要性和紧迫性做判断,确定其优先级和影响程度,并进行相应处 理。 第十五条 紧急变更过程中应使用专设的系统用户账号,由专责部门或人员启动紧急修改变更 程序。信息技术部应对紧急变更的处理进行规范的文档记录。 第十六条 在紧急事件处理完成后,必须在一周内补办正式、完整的文档,其中包括问题发现 人填写的紧急变更申请、问题发现人所在部门
5、负责人对该申请的审批、需求部门/ 信息技术部测试记录(包括签字确认测试结果) 。 第四节 系统变更的权责分离 第十七条 系统变更过程中,应采取各种措施保证维护环境程序代码访问权限受到良好控制。 这些措施包括: 1、通过系统用户的授权管理,确保只有特定人员能进行系统维护工作; 2、如果使用专用程序开发工具,只有授权人员才能使用程序开发工具(通过只有 特定开发人员拥有程序开发工具) ; 3、通过对源代码的访问控制,限制只有授权人员才能获得源代码以进行系统维护; 4、在进行自有系统的程序变更时,应建立版本控制制度确保每次在最新的代码基 础上进行更改,当多名程序员同时进行更改工作时,能够进行适当协调;
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 内部 控制 信息系统 变更 处理 规章制度 方针
限制150内