公司信息系统软件版本管理办法模版.doc

信息系统软件版本管理办法

第一章 总则

第一条 为加强软件版本管理，规范软件版本管理工作流程，提高版本运行维护质量,保证信息系统安全可靠高效地运行，特制定本办法。
第二条 本办法涉及的软件包括在线运行的软件和拟投产的软件。软件版本管理对象包括应用软件版本以及相关操作系统、数据库、中间件等基础软件。
第三条ﻩ软件版本管理是信息系统开发管理和日常维护管理工作的一个重要组成部分，本办法作为软件版本管理的重要依据,软件版本管理归口管理部门、业务支撑部门、风险管理部门、内审部门及各软件供应商要认真履行各自职责,严格执行软件版本管理的各项流程和规定,保障信息系统的安全稳定运行。
第四条 任何未经版本归口管理部门许可的软件版本不允许在生产环境使用。在商务合同中若涉及信息系统软件版本,应确认为版本归口管理部门允许使用的软件版本。因使用未经许可的软件版本而造成系统故障影响正常业务交易,相关部门及各厂商要承担相应的责任。
第五条 本办法由信息技术部负责解释和修订，自发文之日起开始执行。
第二章 组织与职责
第六条ﻩ软件版本管理实行总行集中管理体系。
第七条ﻩ信息技术部是信息系统软件版本的归口管理部门。
第八条 稽核监控部是信息系统软件版本管理的内审部门。
第九条ﻩ风险管理部是信息系统软件版本管理的风险控制部门。
第十条 信息系统软件版本管理工作还涉及软件提供商,软件提供商包括软件最终提供商、代理商和维保服务商（以下简称厂商）。
第一节 归口管理部门职责
第十一条归口管理部门负责制定和完善的软件版本管理办法。
第十二条归口管理部门负责制定信息系统软件版本管理工作的工作计划、工作要求和技术规范,并组织实施。
第十三条归口管理部门负责审批业务支撑部门上报的版本变更申请，组织进行资料审核和上线测试,安排试运行工作及全行推广实施。

第十四条归口管理部门负责建立软件版本信息库，发布软件版本管理各类信息;建立版本预警体系,发布软件版本缺陷信息和版本预警信息。
第十五条归口管理部门负责与业务支撑部门、风险管理部门、内审部门、厂商协调信息系统软件版本管理的相关工作。
第二节　业务支撑部门职责
第十六条版本管理业务支撑部门负责业务类需求的日常收集和集中收集。
第十七条版本管理业务支撑部门负责发起新版本的试运行申请。
第十八条版本管理业务支撑部门负责协助归口管理部门审核新版本发布资料（包括申请、厂家及仿真环境测试报告、版本说明文档、升级方案、测试方案等）,并协助归口管理部门开展新版本试运行测试工作。
第十九条版本管理业务支撑部门负责自查并督促其下属机构履行职责,严格执行版本管理相关制度和流程。
第三节 风险管理部门职责
第二十条版本管理风险管理部门负责重大版本发布前的风险评估。
第四节 内审部门职责
第二十一条版本管理内审部门负责监督和检查版本管理归口管理部门、业务支撑部门、风险管理部门和厂商是否严格执行版本管理的相关制度与流程。
第五节 厂商义务
第二十二条信息系统厂商应严格遵守软件版本管理的规章制度、技术规范。
第二十三条信息系统厂商应根据业务发展及运行维护的需要及时更新版本,保证在线运行的软件版本是允许使用的版本。
第二十四条信息系统厂商应配合软件版本归口管理部门进行软件仿真测试,及时提供各类运行维护及仿真测试所需的文件资料和技术咨询,并对这些材料的真实性、可靠性和实时性负责。在不具备相应仿真测试环境的情况下,厂商有义务提供仿真环境配合开展测试。
第二十五条信息系统厂商应配合进行试运行工作。厂商应根据版本变更情况选择能够测试所有升级功能点的分支机构，并结合用户量、安全性等的要求向提出试验点建议。
第二十六条信息系统厂商应配合做好信息系统软件版本管理工作,建立本厂家信息系统软件版本管理资料库信息，协助软件版本归口管理部门做好版本预警信息的发布与管理，提供必要的技术资料和技术支持。

第二十七条信息系统厂商应指定专门的版本管理联系人与软件版本归口管理部门衔接,以便配合进行软件的升级实施和及时跟踪处理升级过程中或者升级后出现的各种故障。
第二十八条信息系统厂商有义务在升级过程中按照的要求配合完成各项工作，包括协助软件版本归口管理部门模拟重现升级或试运行期间出现的和软件版本相关的故障。
第二十九条信息系统厂商有义务在工程招标书中,承诺按照版本管理相关制度和流程履行投标方的义务。
第三章　版本管理内容与流程
第三十条信息系统软件版本分为版本和补丁。版本是指软件系统中的核心部分发生结构性变化、应用部分新增若干功能而生成的软件版本。补丁是指软件系统中不涉及核心部分的变化,只是应用部分的故障修复或功能完善而生成的软件版本。
第三十一条版本管理的各项工作必须按照规定的操作流程执行,各相关部门应认真履行本部门的职责,做好部门之间的衔接和协调。
第三十二条版本管理工作内容主要包括需求管理、认证管理、变更管理、评估管理和信息管理。其中,需求管理是通过收集、整理和分析版本的新特性需求或未修复缺陷，引导厂家新版本开发,确定待认证的版本；认证管理是依据技术规范,对厂家待认证版本的符合性和可用性进行认证,并对已认证版本进行更新或废止管理;变更管理是对生产运行版本变更的技术审核和流程管控；评估管理是对生产运行版本的版本能力、缺陷等方面的评价和管理；信息管理是对全行软件版本信息及版本管理工作各环节输出信息的动态管理,主要包括信息的收集、整合、关联、更新、价值挖掘和全行共享,是版本管理各项工作的基础。
第一节 需求管理
第三十三条版本需求管理主要分为业务类需求管理和运行维护类需求管理两大类,两大类需求的特点如下:
(一)ﻩ业务类需求：包括对原有业务模型、业务流程进行变更完善的需求，对新业务模式、新业务功能的支撑需求以及与业务推广能力相关的需求等；
（二)ﻩ运行维护类需求:包括运维监控类需求、系统软件版本缺陷和问题解决需求等与运行维护工作直接相关的需求；
第三十四条运行维护类需求由信息技术部系统运行中心（以下简称运行中心）牵头收集整理，业务类需求由信息技术部系统开发中心（以下简称开发中心)牵头收集整理,最终由软件版本归口管理部门负责进行统一梳理后落实到建设项目中,组织技术规范的修订。

第三十五条需求收集分为两种：日常收集和集中征集。
(一)日常收集:业务类需求由需求提交部门发起,开发中心收集整理，运行维护类需求由运行中心不定期向综合部提交新需求并填写《软件版本需求汇总表》(见附表一）作为附件。
(二)集中征集:在专项治理工作中,由专项治理工作归口管理部门发起、在规定时期内征集各方需求，然后统一汇总整理,向需求归口管理部门提交新需求并填写《软件版本需求汇总表》（见附表一)作为附件。
第二节 认证管理
第三十六条软件新版本的认证过程包括仿真环境测试和生产环境试运行测试。
第三十七条仿真环境测试主要测试内容包括：版本差异化测试(新增功能测试、功能变更测试、故障修复有效性测试）、新版本回归性验证测试(即原有功能点的测试)、新版本的升级过程测试、性能测试、业务功能测试等。由厂商自行组织的内部测试也应涵盖上述测试内容。
第三十八条 原则上,业务类需求导致的新软件版本由信息技术部开发中心组织进行仿真环境测试;运行维护类需求导致的新软件版本由信息技术部运行中心组织进行仿真环境测试。如果新版本包含以上两方面的需求，则由软件版本归口管理部门统一组织新版本的仿真环境测试。新版软件正式开始测试前，厂商应向上述部门提交相关技术资料和说明书。说明书中应包含以下内容：
(一）软件版本变更的原因及必要性,新版软件与旧版软件的差异性说明、新增功能说明、新版软件对硬件环境的要求、涉及第三方的软件版本说明;
(二)维护手册及有关资料变更部分；
(三)新版软件对所在平台及所承载业务的影响以及对相连的系统的影响以及相关接口（包括第三方接口)变化的说明文档；
(四)新版本的历史应用情况，已知缺陷、隐患或与需求(含商务需求、设计需求、业务需求、运维需求等）不符之处并列出解决方案；
(五）对新版软件进行测试的测试方案，包括测试所用的软硬件环境、测试项目及具体测试方法步骤、测试环境要求及预期结果；
(六)详细的升级方案及针对各种异常情况的应急预案，升级失败的应急回退方案等；
(七)厂商内部测试情况报告。
第三十九条对于信息系统软件新版本的仿真环境测试原则上应在提供的仿真环境中进行,对不具备测试条件的，厂商须提供相应的仿真环境。厂商应在测试前,配合进行仿真环境的准备工作。仿真环境应能对版本进行尽量完整的测试。
第四十条对于仿真环境下无法测试的测试用例，经归口管理部门审核后可在试运行阶段再进行测试。
第四十一条因版本质量问题导致不能完成测试或测试报告结论为不通过的,需由厂商修改问题后重新测试。测试完成后测试单位应向软件版本归口管理部门提交新版本的测试报告《DXＣ系统ＤXＣ版本测试报告》（见附表三）。测试报告文档应包含内容:
(一)测试原因
(二）测试环境拓扑图
（三)测试所需软硬件及其他工具（可选)
(四）基本连接和配置（可选）
（五)测试项目及具体测试方案
（六)测试结论(包含测试情况如何,该版本功能是否完善,是否符合申请内容以及升级建议等)
第四十二条对于测试中不满足要求的项目,厂商应给出相应的改进承诺和时间表。
第四十三条完成版本测试后，业务支撑部门应向软件版本归口管理部门提出试运行建议申请,并填写《DＸＣ系统DXＣ版本试运行建议表》(详见附表四）,由软件版本归口管理部门发布新版本的试运行通知。
第四十四条信息系统的试运行升级申请应至少在升级日期前七个工作日提交到软件版本归口管理部门，软件版本归口管理部门在收到升级申请后的四个工作日内完成批复,试运行准备时间不少于三个工作日。在紧急情况下,试运行申请至少提前四个工作日提交到软件版本归口管理部门,软件版本归口管理部门在收到申请后两个工作日内完成批复，试运行准备时间不少于两个工作日。升级方案所需要的内容具体参见第三章第三节变更管理。
第四十五条软件版本归口管理部门组织审核测试报告、升级方案及试运行资料,并填写《ＤXC系统DXC版本试运行资料审核报告》(详见附表五）。
第四十六条重大版本变更厂商在试运行升级时应派专人在现场给予技术支撑,协助定位解决问题。
第四十七条软件版本归口管理部门负责组织开展试运行工作,密切关注新版本的运行情况，业务支撑部门应按照试运行测试要求和用例进行完整测试，及时填报测试结果。原则上，试运行时间应不少于三个月。试运行结束后,提交《DXC系统DXC版本试运行报告》(详见附表六)。
第四十八条试运行测试完成、确认新版本安全稳定后，由信息技术部在运维管理系统发布新版本相关信息。
第四十九条在新版本运行期间若出现涉及危害平台安全、影响业务运行、对客户感知造成重大影响的问题，由业务支撑部门填写《DXC系统ＤXC版本软件变更申请表》(见附表七）,软件版本归口管理部门在两个工作日内审核回复,组织厂商、信息技术部执行版本回退或修复工作。
第五十条厂商应在版本升级后五个工作日内提交版本升级故障分析报告。
第五十一条厂商用于投标的软件版本以及新工程中使用的软件版本,均需由厂商向软件版本归口管理部门提出新版本测试申请，按本节管理要求开展测试认证。软件版本归口管理部门和总行验收领导小组应在工程验收时对其使用的软件版本进行检查、把关，确认工程项目中所使用的软件版本是经过测试认证的。
第三节 变更管理
第五十二条版本变更主要指版本和补丁的投入与使用,管理工作主要包括版本升级、补丁输入的申请与审批、版本升级方案（含应急措施、测试用例等)的制定与审批、升级成功后的资料移交和更新等。
第五十三条软件版本升级按发起方不同分为两种：
（一）软件版本归口管理部门安排布置的版本升级任务，主要是为了满足总行提出的对全行信息系统的基础建设或维护的需求；
(二)业务支撑部门主动提交的版本升级申请(《DXC系统软件变更申请表》(见附表七)),主要是为了满足某个业务需求。
第五十四条为了保证平台安全稳定运行,原则上每种平台每月升级次数不超过一次，承载不同业务的平台不安排在同一时间升级；
第五十五条软件版本归口管理部门发布批准使用新版本的信息后，总行各业务部室或分支机构可以根据实际情况更换新版本。
第五十六条升级方案包含但不限于以下内容:
（一)升级目的
(二)升级内容
(三)各方工作人员职责
（四)升级各步骤的时间估算
(五)升级涉及范围及对业务的影响
(六）具体升级步骤

1．升级准备工作及注意事项
2.升级操作详细步骤
３.升级应急预案和应急预案启动条件
４.业务测试用例
(七)升级完成核对的内容及步骤
(八)备品、备件的升级(升级时间、地点、方式)
（九)运行观察
（十)资料归档
第五十七条升级过程中间出现升级方案中未预料到的业务中断或中断时间超出预定时间等异常情况时,软件升级工作应立即停止，按照升级方案中的应急预案进行操作,并逐级上报。
第五十八条在升级结束后业务支撑部门将升级完成情况汇总,填写《ＤXC系统DXC版本使用情况汇总表》(见附件八），在升级完成一周后上报软件版本归口管理部门备案。
第五十九条升级结束后,厂商必须向移交:
(一)各级用户密码;
（二)监控和应用软件的安装程序(必须经过测试)；
(三)设备的详细配置资料；
(四)设备维护手册的追加与变更。
第四节 评估管理
第六十条评估管理是对生产环境运行版本的评估，主要包括版本能力、版本缺陷和预警等的管理和评价。版本评估结果是对已认证版本进行更新或废止的重要依据。
第六十一条版本变更后,软件版本归口管理部门需跟踪新版本的使用情况,组织版本运行评估工作，对新版本满足业务功能、运行维护管理等需求的能力进行评估。如果新版本能力不足、且认证库中已存在满足需求的版本,则可将此已认证版本作为目标版本适时实施版本变更；如果新版本能力不足、且认证库中不存在满足需求的版本,则将关于新版本使用中所出现问题的评估结果提交版本管理归口管理部门。软件版本归口管理部门对评估结果进行分析，对于当前暂不需要解决的版本遗留问题进行汇总；否则输出至需求归口管理部门进行处理。
第六十二条预警定义：预先对因设备软硬件版本缺陷而可能导致业务系统或设备（含在线设备和拟投产运行的设备)不能正常运行的因素进行警示并防范。版本缺陷的预警管理是保证在线安全、稳定运行的重要措施之一。
第六十三条软件版本归口管理部门根据全行在线版本的业务和维护支撑能力、缺陷发生数量及影响、版本变更次数及原因、上线时间等因素,于每年12月２0日之前提交年度版本运行评估报告。
第五节　信息管理
第六十四条建立软件版本信息管理体系,实现全行软件版本信息及版本管理工作各环节输出信息的收集、整合、关联、共享、价值挖掘和动态管理。
第六十五条软件版本归口管理部门按照统一的版本信息模型,每月初通过运维管理系统提交“全行软件版本使用情况汇总表”（见附表八)并对汇总信息进行入库和维护更新管理。
第六十六条软件版本归口管理部门及时发布版本信息,以便各分支机构和总行各业务部室正确选择使用的版本。各相关单位负责收集、整理、分析辖区内软件版本相关信息，并进行及时更新。版本信息库上包括但不限于以下所示:
(一)各厂商的软件版本的状况,包括:版本编号、功能变更说明书、上线测试报告、核准上线日期等。
(二)各厂商的软件版本在生产环境中的运行情况,包括：投入运行时间、版本分布情况、主要设备配置、版本的问题等。
（三)版本问题登记,包括：软件版本、问题发生时间、原因、现象、影响、排除方法、排除时间及善后处理意见等。
(四)其它相关资料，包括:技术标准、企业规范、新业务、新功能的需求汇总、论文资料等。

第四章 监督与检查

第六十七条版本管理内审部门将适时组织检查信息系统的软件版本管理工作情况，并及时通报检查结果；结合本年度全行在线版本管理各项工作情况，于每年底发布全行年度在线版本管理工作情况通报。对于因版本管理不善或使用未经许可的软硬件版本而造成的业务中断故障、用户投诉及经济损失等,内审部门将视具体情况对相关部门、负责人或直接责任人给予通报批评，并反映在部门考核指标中。
第六十八条归口管理部门在进行“外包商服务质量评估”时,应将厂家软件版本运行评估情况及对版本管理工作的支撑情况作为评估内容之一,并将评估结果作为采购评标的重要考虑因素;在维保合同中应增加版本管理工作相关要求的条款，并进行相关考核;对于因厂家原因造成的业务中断故障及由此产生的损失，将视具体情况对相关厂家给予处罚并追究相关责任。
ﻬ附表一:DXC业务软件需求汇总表

业务名称

厂商名称

设备版本

需求提交部门联系人

联系电话

需求概述

需求时间要求

需求详细描述:

需求概述:
需求时间要求：
需求详细描述:

需求提交部门审批意见：

　 　　　 　　 　 　 　 　 　 　 签名:
信息技术部审批意见:

　 　 　 　 　 　 　 　　 　 签名:

ﻬ
附表二：软件版本测试申请表

业务名称

申请厂商

设备型号

当前版本

新版本

版本变更原因

相关文档(含版本说明书)

使用单位意见

　 　　　 　 　　年 月　　 日
信息技术部审批意见

　 　 　 　　 　 　　 　 年 　月 　日

ﻬ附表三：DXC系统DXC版本／补丁测试报告
1．测试概况
测试目的

2.测试环境
网络结构图

3.测试内容
对测试情况的描述

4．测试结论
测试通过或测试不通过，测试不通过请说明原因。
ﻬ
附表四：DＸＣ业务DXC版本试运行建议表

业务名称

申请单位

联系人

联系电话

厂商

新版本号

申请时间

申请原因：

试运行基本情况（该业务平台与其他系统的联调能力、用户容量,设备数量及原版本号等):

升级方案是否具备:
总行信息技术部批复：

　 　　 　 　　 　 　 　 　 　 　 　批复人：
　　 　　 　 　 　 　 　 　　 　　　 　 　 日期:
信息技术部运行中心意见:

　　　 　 　　 　　　 　 批复人:
　 　 　 　　 　 　 　 　 　　 　　 　 　　　　　 日期：

附表五:ＤXＣ业务DＸC版本试运行资料审核报告

业务名称

设备型号

测试版本

测试单位

测试时间

版本变更原因及内容

测试报告审核
测试报告项目
支撑单位意见
测试环境是否合理

测试项目是否足够

测试结论是否满足试运行条件

升级方案审核
升级方案资料
支撑单位意见
是否包含操作时间

是否包含对话务的影响

是否包含联系人资料

是否包含回退方案

是否包含拨测内容

试运行建议表审核
试运行资料
支撑单位意见
试运行基本情况是否满足试运行要求

ﻬ附表六：ＤＸＣ业务系统试运行报告

业务名称

试运行名称

设备厂商和型号

运行时间

版本信息

运行情况:

业务实施情况:

ﻬ附表七:DXC软件变更申请表

业务名称

申请单位

设备型号

当前版本

新版本

版本变更原因

版本测试情况

试运行运行情况

升级指导书

升级计划

使用部门意见

　 　 　　 　 　 　 年 　月　 日
信息技术部审批意见

　 　　 　 　 　 　 　 年 月 日

附表八：DXC业务系统软件版本使用情况汇总表
业务名称

厂商

设备型号

版本信息

业务运行情况:

业务名称

厂商

设备型号

版本信息

业务运行情况:

业务名称

厂商

设备型号

版本信息

业务运行情况：

填表人

填报日期

审核人

审核日期