信息系统变更和布管理办法.docVIP

信息系统变更和发布管理办法 总 则 目的：本管理办法规定了XX银行（以下简称“我行”）信息系统的变更和发布管理，变更和发布管理作业操作流程和控制要点，确保变更需求的受理符合业务的优先需要，并使变更和发布过程规范化，控制变更对银行业务和已投产系统安全运行的不利影响。达到降低信息系统变更和发布风险的目的。保障信息系统的安全稳定运行，特制定本管理办法。 依据：本管理办法根据《XX银行信息安全管理策略》制订。 范围：本管理办法适用于我行信息系统变更和发布管理。 定义 软件产品：泛指信息技术开发的生产业务系统和管理信息系统等应用软件项目。 生产业务系统：指我行从事金融服务的应用网络系统，包括综合业务系统、国际业务系统、支付系统等银行对外营业的各种核心业务系统。 管理信息系统：指我行信息管理的计算机网络系统，具体指OA办公系统、信贷管理、报表系统等用来进行内部管理的应用软件系统。 业务部门：指我行总部相关业务部门。 遵循原则 监督制约原则：针对信息系统变更和发布管理工作中各个环节，建立相应的监督检查机制。 计划性原则：信息系统发布应纳入每年计算机应用计划，确保全行计算机系统资源、应用环境、维护力量、操作技能能满足系统安全、可靠运行的要求。 可行性原则：具有普遍适用性和可操作性。 风险控制原则： 若为新项目或新业务功能变更和发布，需进行以下风险分析： 备份机建设情况； 应用系统投产后的集中监控方案； 生产数据备份方案； 程序及系统备份方案； 数据库建库/建表/建索引方式等； 对其他系统的影响。 组织与管理 职责划分 需求部门： 提出需求，并确认《用户需求说明书》； 用户测试阶段确认用户测试计划、记录用户测试问题、确认用户测试报告； 接受用户培训并提出反馈。 科技信息部安全科： 在需求阶段审阅和提出IT风险控制、IT合规和IT稽核方面的要求，在项目开发阶段对有关IT风险控制、IT合规和IT稽核方面的测试结果进行审阅； 在项目实施后审阅阶段对有关IT风险控制、IT合规和IT稽核要求的实施效果进行审阅。 科技信息部运行维护中心： 负责受理所有变更和发布需求，会同IT其他相关部门（IT软件开发中心、安全科等）对变更和发布需求进行评估，并将评估意见向IT部门领导、业务部门领导汇报沟通，获取所需的授权； 在详细设计阶段审阅和提出网络、硬件、操作系统和数据库等方面的配置和容量要求； 在设计与编程阶段提供网络、硬件、操作系统和数据库的参数配置； 在测试阶段配合项目组设立网络、硬件、操作系统和数据库环境； 配合项目组对系统进行联合测试，把信息系统版本软件、相关配置文件、标准数据和相关文档提供给测试评估中心； 将信息系统发布到使用部门，系统上线时会同项目组搭建生产系统并进行程序移植，组织定期对变更和发布效果进行分析和总结。 接收管理和备份软件开发中心提供的源程序、相关标准数据、配置文件、相关文档； 科技信息部软件开发中心： 负责设计、编程、纠错和开发质量控制，编制《系统设计规格书》； 落实项目管理制度和业务操作手册的编制工作，参加制定上线方案制定，编制《上线实施计划》； 负责系统切换上线的技术支持工作； 负责项目验收资料整理汇总，配合项目验收工作。 科技信息部测试评估中心： 负责对需要测试评估的软件进行分析测试； 负责提交测试分析报告。 信息系统变更 信息系统变更，指由于新增信息系统功能、系统逻辑改变、系统错误修正、系统补丁安装及版本更新、系统配置修改及业务参数修改等原因，而对已投产系统进行局部改变的一切活动。已投产系统变更需求主要来源于以下几种情况： 由于业务快速发展，业务部门对现有已投产系统的功能或设置进行变更或通过新增功能来满足需求； 用户在使用过程中发生的一些操作错误，或技术人员、监控管理软件自动发现的故障或事件，需要通过安装程序补丁或修改配置等操作进行修改； 厂商定期发布的系统补丁，涉及系统的功能、性能、安全漏洞，需要在已投产系统中进行安装； 由于系统容量扩充或与已投产系统存在数据交换或数据共享的其他已投产系统发生变化后引发的已投产系统变更。 信息系统变更的提出，必须由申请部门（用户部门或IT部门）填写《已投产系统变更流程单》（附件1）第一部分，申请信息。在申请信息填写阶段的主要工作内容包括： 申请人需选择变更类型； 描述变更内容和目的； 是否存在其他措施满足变更需求； 如不实施变更可能对客户、合规、外部利益相关方、内部管理和操作、安全控制、系统可用性和数据准确性的影响； 选择变更的急迫性。 申请部门主管审批签字后提交IT运行维护中心进行处理。 IT运行维护中心收到变更申请后，和变更申请部门充分沟通，理解变更需求的合理性，审阅变更的影响和急迫性，并会同IT其他相关部门（IT软件开发中心、安全科等）对可行的变更实施方案和变更对已投产系统的影响做出评估，