信息化项目版本管理细则

1、Q/CSG-YNPG-XXXX-2015云南电网有限责任公司 发布2015-10XX-30XX 实施2015-XX10-30XX 发布云 南 电 网 有 限 责 任 公 司信 息 化 项 目 版 本 管 理 细 则 (2015版) Q/CSG-YNPG2180006-2015Q/CSG-YNPGXXXXXX-XXXX Q/CSG云南电网有限责任公司企业管理制度业标准1前 言为规范云南电网有限责任公司信息化项目版本配置管理工作，建立有序和规范的管理措施，提升信息系统运行管控质量，本细则发布实施后，原云南电网公司信息化项目版本管理细则（Q/CSG-YNPG-2-18-011-2014）同时予以废止

2、。本办法细则由云南电网有限责任公司信息部提出并归口。本办法细则由云南电网有限责任公司信息部负责起草。本细则由云南电网有限责任公司企业管理部易志生统一编号。本办法细则主要起草人：胡永华、普钢、马文、张羿、张富华本办法细则主要审核人：张叶、周兴东、黄文载本办法细则由杨卓批准。本办法细则由云南电网有限责任公司信息部负责解释。17云南电网有限责任公司信息化项目版本管理细则1 总则本细则规定了云南电网有限责任公司（以下简称公司）信息化项目建设的版本管理要求，为了加强对项目的版本管理，明确版本管理的职责分配、内容与标准和工作程序等相关内容和要求，按照“统一管理、统一规划、统一标准、统一建设”的信息化项目建

3、设原则，进一步提升公司信息化项目建设版本管理的整体水平，根据南方电网公司（以下简称“网公司”）信息化项目管理相关规定，特制定本细则。本细则适用于公司下达的二、三类信息化项目版本管理的工作，网公司下达的一类信息化项目设计阶段工作，按照中国南方电网有限责任公司系统版本管理办法（QCSG218017-2014）要求执行。2 规范性引用文件下列文件对于本文件的应用是必不可少的。下列文件的部分条款通过本文件的引用而成为本文件的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分；凡是不注日期的引用文件，其最新版本适用于本部分。中国南方电网有限责任公司系统版本管理办法

4、(QCSG218017-2014)中国南方电网有限责任公司公司企业架构管理办法(QCSG218019-2014)中国南方电网有限责任公司信息安全等级保护办理办法(QCSG218016-2014)中国南方电网有限责任公司信息安全防护管理办法(QCSG218014-2014)南方电网公司管理信息化推进项目群版本管理要求（办发201520号文）南方电网公司管理信息化推进项目群变更管理要求（办发201520号文）3 术语和定义3.1 配置项凡是纳入配置管理范畴的工作成果都是配置项。包括阶段工作成果以及项目管理文档。3.2 基线基线由一组已经审核通过的配置项组成，为随后的工作或变更提供参照基准。3.3

5、软件变更需求软件变更需求指系统上线运行后因系统存在缺陷、系统功能或性能需要完善所提出的需求。软件需求变更分为重大变更和非重大变更。3.4 重大软件变更本办法中涉及主版本号变更的软件变更为重大变更，其他则为非重大软件变更。软件版本号规定详见5.3.1软件标识管理规定。3.5 软件升级管理软件升级管理是由软件变更需求引起的需求变更申请与审批、软件开发与测试、软件发布管理及软件配置管理等活动的总称。软件升级管理的关键控制点是软件变更需求的审批、软件升级前的测试，执行软件发布前的审批等，最后完成配置管理以保证信息系统登记配置数据与实际相符。软件升级管理为提高信息系统生命周期管理水平（特别是提供了历史可

6、追溯能力）、提高信息系统质量提供有效的管理手段。3.6 向后兼容向后兼容又称向下兼容，在计算机中指在一个程序或者类库更新到较新的版本后，用旧的版本程序创建的文档或系统仍能被正常操作或使用，或在旧版本的类库的基础上开发的程序仍能正常编译运行的情况。3.7 支撑软件支撑各种软件系统开发与维护工作的软件，它主要包括环境数据库、各种接口软件和工具组。4 职责4.1 信息部4.1.1 负责审批重大版本变更申请；4.1.2 负责提出一类项目中止申请；4.1.3 负责审批非一类项目中止申请和发布项目中止批文；4.1.4 负责审批（会审）重大软件升级发布申请；4.1.5 负责组织信息系统运维管理单位完成软件开

7、发、测试与软件发布实施工作；4.1.6 负责确认重大软件升级发布前的测试结果。 4.2 业务部门（公司职能部门）4.2.1 负责审批（会审）软件升级发布申请；4.2.2 负责审批（会审）重大软件升级发布申请。4.3 项目管理办公室4.3.1 负责审核项目建设过程中版本变更申请；4.3.2 负责审核项目的配置项交付计划。4.3.3 PMO业务组4.3.3.1 提出项目实施业务要求、指导意见；4.3.3.2 负责对配置项交付计划进行专业审核；4.3.3.3 负责对新增基线版本进行专业审核；4.3.3.4 负责对配置项进行专业审核；4.3.3.5 负责对业务类的变更申请分析影响及专业审核；4.3.3

8、.6 负责对业务类的变更方案进行专业审核；4.3.3.7 指导、解决实施过程中出现的业务问题。4.3.4 PMO技术组4.3.4.1 提出项目实施技术要求、指导意见；4.3.4.2 负责对配置项交付计划进行专业审核；4.3.4.3 负责对新增基线版本进行专业审核；4.3.4.4 负责对配置项进行专业审核；4.3.4.5 负责对技术类的变更申请分析影响及专业审核；4.3.4.6 负责对技术类的变更方案进行专业审核；4.3.4.7 指导、解决实施过程中出现的技术问题。4.3.5 PMO综合管理组4.3.5.1 负责组织审核项目的配置项交付计划；4.3.5.2 负责组织审核项目的基线版本； 4.3.

9、5.3 负责组织审核项目的配置项； 4.3.5.4 负责组织审核的变更影响分析及变更申请；4.3.5.5 负责组织审核变更方案；4.3.5.6 负责变更实施效果评估。4.4 项目建设单位4.4.1 负责发布基线版本；4.4.2 负责项目的一般变更申请审批；4.4.3 负责非一类项目中止的申请负责。4.4.4 项目组4.4.4.1 作为实施阶段建设主体，在PMO领导下，遵照公司管理制度，组织开展实施阶段的各项工作，对实施成果负责；4.4.4.2 负责编制配置项交付计划；4.4.4.3 负责建立和维护配置库；4.4.4.4 负责建立阶段成果版本和新建基线版本申请；4.4.4.5 负责收集变更需求并

10、提出变更申请；4.4.4.6 负责编制变更方案；4.4.4.7 负责对变更方案的具体实施工作。4.5 信息系统运维管理单位4.5.1 信息中心、各供电局信息管理部门均属于信息系统运维管理单位；4.5.2 负责全面管理并推进软件系统升级工作，协调和处理软件系统升级中存在的问题；4.5.3 负责审核信息系统运维单位提交的软件变更需求申请，审核通过后向业务归口部门上报软件变更申请，重大软件变更需求需上报信息部审批（会审）；4.5.4 负责根据批准的软件变更需求组织执行软件的开发实施工作，包括组织软件开发、版本号的确认等工作；4.5.5 负责组织软件升级的测试工作，审批测试申请，监督并检查软件测试工作

11、的结果及实施情况；4.5.6 负责审批信息系统运维单位提交的发布申请，进行审核后向业务归口部门上报软件发布申请，重大软件发布申请需上报信息部审批（会审）；4.5.7 负责组织执行信息系统的配置管理工作。4.6 信息系统运维单位4.6.1 信息中心、各供电局信息系统运行维护部门及信息系统运维服务外包单位均属于信息系统运维单位。4.6.2 负责收集汇总公司业务部门、用户的软件变更需求及系统缺陷和完善性需求，进行内部审核后向信息系统运维管理单位上报软件变更申请。4.6.3 负责提交软件测试申请，审批通过后配合开展软件测试工作。4.6.4 负责提交软件发布请求，进行内部审核后向信息系统运维管理单位上报

12、软件发布申请。4.6.5 负责执行软件发布实施工作。5 管理内容和方法5.1 版本管理5.1.1 总体要求5.1.2 版本管理是对项目实施各个阶段所形成的各类配置项的管理工作，不限于软件代码。在项目开展各个阶段，所有需要经过审核和审批的项目活动、目标、计划、方案、报告、人员组成的变动等工作，均应按照变更管理流程执行变更工作，并完成对应变更方案的确定，记录在配置库中。5.1.3 版本管理的各类对象应按照版本配置流程（附录1）保存在配置库中。5.1.4 配置计划5.1.4.1 版本配置工作应由项目组确定配置管理负责人及职责，识别基线和配置项清单并编制配置项交付计划（模板参见附录5），在项目建设单位

13、审核后，由项目组建立配置库。5.1.4.2 配置项交付计划通过审核后向所有项目相关人员进行宣贯计划。 5.1.5 配置库管理5.1.5.1 项目组应合理建立配置库，并分配权限。发生项目变更时，项目组负责新建配置库并更新权限设置。PMO和项目建设单位抽查配置库的建立和权限分配情况。5.1.5.2 配置库需应定期进行备份。5.1.5.3 不同项目要求建立独立的配置库，同一系统版本的多个项目的配置库可进行集成。5.1.6 基线管理5.1.6.1 对于需要新增基线的版本配置，应由项目组根据配置项交付计划提出基线建立申请（模板参见附录6），由PMO综合管理组组织审核， PMO技术组、PMO业务组参与，负

14、责专业审核工作，审核后由建设单位发布。5.1.6.2 项目组负责依据发布后的版本完成配置库的更新工作。5.1.7 配置状态监控5.1.7.1 首次基线发布后开始对系统建设进行配置项状态监控。5.1.7.2 项目组负责监控项目配置管理活动情况、配置项的状态，完成配置项状态报告（模板参见附录7）。5.2 变更管理5.2.1 项目建设过程中，当建设内容和下达计划不一致时，应按照变更管理的要求进行调整，详见变更流程图（附录2）。变更后的内容应作为不同版本保存在配置库中。5.2.2 变更范围5.2.2.1 项目建设过程中，应严格控制各类变更。变更按类别分为：需求变更、设计变更、资金变更、进度变更、人员变

15、更和项目中止；按性质分为重大变更和一般变更，重大变更是指投资金额调整、技术方案重大调整、项目建设内容调整或项目中止，其他均是一般变更。5.2.3 变更申请5.2.3.1 系统建设中存在变更需求时，由项目组负责收集各方需求并提出变更申请单（模板参见附录8）。5.2.3.2 项目组依据变更内容的差异将业务类变更申请提交给PMO业务组审核；技术类变更申请提交给PMO技术组审核；其他类变更的申请提交给PMO综合管理组进行审核。5.2.3.3 涉及重大变更，变更申请均需提交至公司信息部进行审批。5.2.4 变更审查5.2.4.1 PMO各个小组针对不同类型的变更申请进行审核。审核中应包含变更影响分析。变

16、更影响分析须包括变更可行性论证、成本评估、资源评估、进度评估等内容。5.2.4.2 PMO各个小组在进行项目的变更申请审核中，如发现属于重大变更需提交至公司信息部进行审批，给出对变更申请的审批意见。5.2.4.3 PMO各小组在进行项目的变更申请审核中，确认是一般变更需提交至建设单位进行审批，给出对变更申请的审批意见。5.2.5 变更实施5.2.5.1 变更申请审核通过后，如变更类型为“项目中止”，应按照项目中止流程处理。其他类型的变更，应由项目组负责编制变更方案（模板参见附录9）。5.2.5.2 由PMO综合管理组负责组织对变更方案的审核，审核中PMO技术组和PMO业务组对变更方案进行专业审

17、核。审核完成后，由PMO综合管理组给出变更方案的审核意见。5.2.5.3 项目组依据审核通过后的实施方案开展变更实施。项目组再实施变更活动前需发布项目变更通知，确保变更方案中的资源需求及时到位，并调整相应的进度计划。5.2.5.4 项目组实施变更活动需同时启动版本配置流程，规范变更实施过程。5.2.6 变更监控5.2.6.1 项目组对变更实施活动进行监控，并记录变更实施的状态，确保实施工作受控。在实施完成后，由PMO小组对变更实施效果进行评估。5.2.6.2 对计划、方案的变更效果应在下一阶段的工作报告中进行确认，确保变更完成后项目管理和系统建设纳入正常轨道。变更实施后，应在对应工作报告中包含

18、“变更效果评估”的内容。5.2.6.3 变更效果评估需对变更成果进行确认，确保变更完成后项目管理和系统建设纳入正常的轨道。5.2.7 项目中止5.2.7.1 因各种原因导致无法按计划实施需要进行中止的在建项目，公司信息部或网公司信息部应组织开展项目中止工作。5.2.7.2 一类项目中止由公司信息部以正式文件向网公司信息部提出申请，经网公司信息部正式文件审批后，建设单位办理项目中止后续手续。5.2.7.3 非一类项目中止由建设单位以正式文件向公司信息部提出申请，公司信息部审核后，以项目中止批文文件批复，项目建设单位办理项目中止后续手续（流程见附录3）。5.3 软件版本升级管理5.3.1 软件标识

19、管理规定5.3.1.1 软件标识由软件名称和软件版本号组成，其中软件名称即省公司统一开发或实施时定义的软件名称（或简称）；软件版本号由四部分组成，包括主版本号、次版本号、内部版本号和修订号，四个组成部分都必须是十进制整数。5.3.1.2 软件标识的格式为：软件名称软件版本号。5.3.1.3 软件版本号的格式为：主版本号.次版本号.内部版本号.修订号。5.3.2 主版本号5.3.2.1 具有相同名称但不同主版本号的程序集不可互换，且无法实现向后兼容性。5.3.2.2 在满足以下任一条件时，应对软件的主版本号进行升级，使软件标识中的主版本号数值加1：（1） 软件无法满足现有生产、管理需求前提下的扩

20、容改造；（2） 软件功能发生大量更改或新增；（3） 软件主体结构发生变化，或数据库中主要数据表结构被大量修改；（4） 软件的其他重大变更。5.3.2.3 主版本号升级后，次版本号、内部版本号和修订号置0。5.3.3 次版本号5.3.3.1 如果两个程序集的名称和主版本号相同，而次版本号不同，表示软件功能存在新增或修改，且该软件具有向后兼容性。5.3.3.2 在满足以下任一条件时，应对软件的次版本号进行升级，使软件标识中的次版本号数值加1：（1） 软件功能存在新增或修改；（2） 软件性能与之前版本存在较大差异。5.3.3.3 次版本号升级后，内部版本号和修订号置0。当次版本号递增达到25时，下一

21、版本软件必须对主版本号进行升级。5.3.4 内部版本号5.3.4.1 内部本号的变更表示对相同源程序文件所作的重新编译，适用更改硬件、系统软件、支撑软件等运行环境后进行重新编译的情况，每次重新编译均应使软件的内部版本号数值加1。5.3.5 修订号5.3.5.1 主、次版本号都相同但修订号不同的程序集应是完全可以互换的，适用于仅对以前发布的程序集进行消缺，消除软件中的错误和安全漏洞，不影响已有功能的版本，修订版本号不设上限。5.3.6 软件变更需求申请、审批5.3.6.1 信息系统运维单位负责收集汇总公司业务部门、用户的软件变更需求及系统缺陷和完善性需求，制定实施计划，明确技术方案及进度计划，内

22、容应包括：软件开发模块及对原系统的影响范围；软件开发、测试、版本升级的进度计划与分工安排，进行内部审核后向信息系统运维管理单位上报软件变更需求申请单（模板参见附录10）。引起软件主版本号或次版本号升级的变更需求，需提交软件升级开发需求规格说明书。5.3.6.2 信息系统运维管理单位审核信息系统运维单位提交的软件变更需求申请单，审核通过后向业务归口部门上报软件变更申请。5.3.6.3 业务部门对软件变更需求申请单进行审批。重大软件变更申请经业务部门审批通过后，还需提交至信息部会审。5.3.7 软件开发及测试5.3.7.1 信息系统运维管理单位按审批通过后的实施计划组织软件开发工作。5.3.7.2

23、 软件开发过程应符合软件工程管理要求，必须完成需求分析、设计、编码、开发方独立测试和整合测试等过程。5.3.7.3 软件开发完成后，由信息系统运维单位提交测试申请，信息系统测试申请表（模板参见附录11），运维管理单位审批测试申请并组织开展软件升级的功能、性能及安全测试工作，监督并检查软件测试工作的结果及实施情况。其中，涉及主版本号变更的软件版本，必须开展功能、性能及安全测试；涉及次版本号变更的软件版本，必须开展功能测试，并根据软件新增或修改功能的重要程度、对软件系统的影响大小等因素，选择开展性能及安全测试。功能测试必须由省公司业务部门（或省公司业务部门组织各供电局业务部门）参与并确认测试结果满足软件变更需求。对于重大软件变更，必须经由第三方测试机构进行软件测试，测试结果需要信息部审核确认。5.3.7.4 软件开发与测试应形成软件升级文档软件配置项清单（模板参见附录12）。其中，软件发布说明应包括如下内容：（1）软件标识；（2）发布形式，发布形式类型包括：-全发布：整个软件系统经过重新构建、测试，可直接安装使用；-增量发布：包含相对于上一个全发布之后的变动部分；-包发布：把几个发布合在一起执行，以减少发布的频率。（3）软件升级内容：相对于上一版本的修改内容概要；（4）软件升级部署步骤：描述软件升级安装及配置的步骤；（5）还原方案：描述新版本软件安装不成功的情况下还