ICS 35.020 L 07 吉 DB22 林 省 地 方 标 准 DB 22/T 1945—2013 信息系统运行维护技术服务规范 应用软件部分 Information system operating and maintenance technology service specification part of Application software （本稿完成日期：） 2013 - 12 - 04 发布 吉林省质量技术监督局 2013 - 12 - 31 实施 发 布 DB22/T 1945—2013 前 言 本标准按照GB/T 1.1-2009 给出的规则起草。 本标准由吉林省标准研究院提出。 本标准由吉林省质量技术监督局归口。 本标准起草单位：吉林省标准研究院、长春市博鸿科技服务有限责任公司。 本标准主要起草人：王曼、胡维汉、李莉、丁玉维、刘慧明、李瑞瑞、梁锋、宋宗亮、许柏成、崔 涧、杨磊、马群。 I DB22/T 1945—2013 信息系统运行维护技术服务规范 应用软件部分 1 范围 本标准规定了本规范中应用软件系统运行维护技术服务规范，包括应用软件系统运行维护技术服务 体系结构、基本流程和运行维护的管理规范。 本标准主要适用于使用单位对应用软件系统运行维护技术服务工作，其他关联单位可参照本标准执 行。 2 规范性引用文件 下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文 件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 GB 1526-89 ( ISO 5807－1985 ) 信息处理－数据流程图、程序流程图、系统流程图、程序 网络图和系统资源图的文件编制符号及约定 GB/T 5271 信息技术 词汇 GB/T 11457-1995 软件工程术语 3 术语和定义 GB/T 5271、GB/T 11457-1995界定的以及下列术语适用于本文件。 3.1 软件配置管理 software configuration management 通过在软件生命周期的不同的时间点上对软件配置进行标志并对这些被标志的软件配置项的更改 进行系统控制，从而达到保证软件产品的完整性和可溯性的过程。 3.2 例行检查程序 routine test procedure 按照软件运行维护服务协议或规则进行的常规测试。 3.3 软件更新 software update 对原有软件进行问题修复、功能优化、界面修改、性能提升等方面的操作形成对原有版本的小范围 的升级，不涉及架构的变更，会保留上一个版本的大部分功能和使用习惯等。 3.4 软件升级 software upgrad 1 DB22/T 1945—2013 软件厂商在原有版本可用的前提下，为了更好的满足用户需要而对原有软件在功能、界面、性能、 用户交互性等方面做出的大范围的升级，可能涉及架构和界面的整体修改，会变更原有软件已形成的用 户使用习惯。 3.5 商品型应用软件 commercial software 作为商品在软件市场流通的应用软件产品。在信息系统中视为一个可直接采购并安装投入使用的软 件。商品型应用软件可能涉及补丁程序或升级处理，因此，应建立运维跟踪记录。 3.6 开发型应用软件 custom software 以可供分享的自由软件、或共享软件、免费软件为基础，自主或委托进行了二次开发的应用软件， 以及自主或委托开发的面向应用的软件。开发型应用软件在测试期和运行期间内可能发现“缺陷或隐 患”，在诊断并修订后形成开发型应用软件的补丁程序或升级版本。 3.7 补丁程序 patch 为修复原有系统在功能和易用性上的问题、对原有程序或存在 BUG 进行修改和补充形成的程序， 通常可自由安装和卸载。 4 服务规范 4.1 服务体系结构 应用软件系统运行维护的服务体系结构如图 1 所示。 2 DB22/T 1945—2013 图1 服务体系结构 4.2 基本流程 4.2.1 例行测试维护 4.2.1.1 例行测试 按照软件系统运行维护服务内容进行，依据例行检查程序执行的常规测试活动。例行测试流程如图 2所示。 3 DB22/T 1945—2013 图2 例行测试流程 例行测试流程的关键点主要包括如下方面： a) 开展例行测试前应先制定测试计划及测试用例； b) 测试人员按计划依据用例执行测试； c) 测试人员对测试结果进行分析，对有需维护的功能则移交给维护工程师处理； d) 维护工程师在软件维护后发现有缺陷不能解决，申请进入缺陷诊断与修复； e) 例行测试完成后应编制例行测试报告，并与例行测试过程中产生的文档一并归档。 4.2.1.2 例行维护 按照软件开发或提供厂商规定的维护手册或软件测试规程实施的软件维护活动。例行维护流程如图 3所示。 4 DB22/T 1945—2013 图3 例行维护流程 例行维护流程的关键点主要包括如下方面： a) 开展例行维护前应制定例行维护实施方案； b) 维护工程师对记录的维护情况进行分析，对在维护后发现系统有缺陷，则向技术主管申请进入 缺陷诊断与修复流程； c) 例行维护完成后应编制例行维护报告，并与例行维护过程中产生的文档一并归档。 4.2.2 缺陷诊断与修复 5 DB22/T 1945—2013 按照软件开发或提供厂商提供的测试检查方法、测试检查工具或第三方测试工具，按测试规范对软 件进行缺陷诊断与修复的活动。对于诊断流程发现的缺陷按缺陷诊断和处理办法能够解决的缺陷问题在 此流程范围内解决。缺陷诊断与修复流程示如图4。 图4 缺陷诊断与修复流程 缺陷诊断与修复流程的关键点主要包括如下方面： a) 技术主管接受问题申请后，应对问题进行初步诊断； b) 技术主管经检查分析，对属于异常的缺陷则移交给软件开发方或提供方修复，对于属于常见问 题则进行技术支持； c) 缺陷诊断与修复完成后应编制缺陷诊断与修复报告，并于缺陷诊断与修复过程中产生的文档一 并归档。 4.2.3 日常运行 日常运行应当按规范时间，定点启动。日常运行流程如图5所示。 6 DB22/T 1945—2013 图5 日常运行流程 日常运行流程的关键点主要包括如下方面： a) 日常运行开始前应维护工程师先查阅系统日常运行记录； b) 在日常运行工作中，操作人员处理运行过程中的随机事件，对不能解决的事件移交给维护工程 师处理； c) 维护工程师对在维护后发现系统有缺陷，则向技术主管申请转入缺陷诊断与修复流程； d) 日常运行完成后应编制日常运行报告，并于日常运行过程中产生的文档一并归档。 4.2.4 定期测试维护 7 DB22/T 1945—2013 定期维护的规范维护周期依据应用软件的使用手册和运行规范设定。其周期一般应考虑周、月和季 度测试维护三个基本类型。不同周期类型的测试内容可以有不同的简要或详细程度。 定期测试维护基 本流程如图6所示。 图6 定期测试维护流程 8 DB22/T 1945—2013 定期测试维护流程的关键点主要包括如下方面： a) 定期测试维护开始前应先查阅软件系统日常运行记录； b) 测试人员对定期测试记录进行分析，对有需要维护的系统功能则移交维护工程师进行维护； c) 维护工程师对在维护后发现系统存在缺陷，则申请转入缺陷诊断与修复流程； d) 定期测试维护完成后应编制定期测试维护报告，并与定期测试维护过程中产生的文档一并归 档。 4.2.5 软件信息变更 软件信息变更流程如图7所示。 图7 软件信息变更流程 软件信息变更流程的关键点主要包括如下方面： 9 DB22/T 1945—2013 a) 软件信息变更申请由资料管理员和维护工程师整理、提出，经技术主管或变更管理决策组分析 和审批； b) 对于不完善的软件信息变更申请需整理后重新提交申请； c) 经批准同意的软件信息变更实施后应进行信息变更后发布； d) 软件信息变更完成后应将变更过程中产生的文档归档； e) 变更管理决策组应包括使用单位、开发或提供单位。 4.2.6 软件系统恢复安装 应用软件系统出现不能正常工作的情况，需对系统实施恢复安装操作。软件系统恢复安装流程如图 8所示。 10 DB22/T 1945—2013 图8 软件系统恢复安装流程 软件恢复安装流程的关键点主要包括如下方面： a) 维护工程师提出系统恢复申请； b) 技术主管审核申请并全程监督； c) 维护工程师进行恢复安装前检查、恢复系统后测试； d) 系统正常运行后系统恢复申请单、故障原因分析记录、恢复安装记录等过程文档的存档。 4.2.7 财务管理 财务管理流程如图9所示。 图9 应用软件财务管理流程 应用软件财务管理流程的关键点主要包括如下方面： a) 维修工程师提出预算内或预算外申请，交由技术主管审核； b) 技术主管进行申请审核，并做出预算方案交由财务部门审核； c) 财务部门对预算方案进行审核，如果预算方案不通过，则返回给技术主管重新制定； d) 如果预算方案通过，则移交采购部门进行采购； 4.3 应用软件系统运行维护 11 DB22/T 1945—2013 4.3.1 例行测试 应用软件系统例行测试是信息系统运行维护的常规活动。依据测试对象和测试手段的设计。例行测 试基本工作流程参照4.2规范的模式执行。 4.3.2 运维管理 4.3.2.1 事件管理 事件管理的主要目标是尽快恢复应用软件的正常服务并减少对信息系统的不利影响，尽可能保证最 好的服务质量和可用性。事件管理流程通常涉及事件的侦测和记录、事件的分类和支持、事件的调查和 诊断、事件的解决和恢复以及事件的关闭。 4.3.2.2 问题管理 问题管理的主要目标是预防问题的再次发生，并将未能解决的事件的影响降低到最小。问题管理流 程包括诊断事件根本原因和确定问题解决方案所需要的活动，通过合适的控制过程，尤其是变更管理和 发布管理，负责确保解决方案的实施。 4.3.2.3 配置管理 配置管理负责核实基础设施中实施的变更以及配置项之间的关系是否已经被正确记录下来；确保配 置管理数据库能够准确地反映现存配置项的实际版本状态。 4.3.2.4 变更管理 变更管理实现所有系统的变更，变更管理应记录并对所有要求的变更进行分类，应评估变更请求的 风险、影响和业务收益。其主要目标是以对服务最小的干扰实现有益的变更。 4.3.2.5 发布管理 发布管理负责对应用系统、文档、流程等进行规划、设计、构建、配置和测试，以便为实际运行环 境提供一系列的发布组件，并负责将新的或变更的组件迁移到运行环境中。其主要目标是保证运行环境 的完整性被保护以及正确的组件被发布。发布管理应包