GB/T 42560-2023 系统与软件工程 开发运维一体化 能力成熟度模型

　　ICS 35 . 080 CCS L 77

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 42560—2023

　　系统与软件工程 开发运维一体化

　　能力成熟度模型

　　System and s0ftware engineering—Devel0pment and 0perati0ns—

　　Capability maturity m0del

　　2023-05-23 发布 2023-12-01 实施

　　国家市场监督管理总局国家标准化管理委员会

　　

　　发

　　

　　布

　　GB/T 42560—2023

　　目 次

　　前言 Ⅲ

　　引言 Ⅳ

　　1 范围 1

　　2 规范性引用文件 1

　　3 术语 、定义和缩略语 1

　　3 . 1 术语和定义 1

　　3 . 2 缩略语 3

　　4 概述 4

　　4. 1 开发运维一体化 4

　　4. 2 能力成熟度模型 5

　　5 项目管理 11

　　5 . 1 估算与计划( ESP) 11

　　5 . 2 监控与调整(MC) 19

　　5 . 3 风险与机会管理(ROM) 22

　　5 . 4 供方管理(SM) 25

　　6 过程改进 27

　　6 . 1 组织治理 (GOV) 27

　　6 . 2 过程改进基础设施(PII) 32

　　6 . 3 过程资产管理(PAM) 34

　　6 . 4 过程管理(PROM) 37

　　6 . 5 效能管理(PERM) 42

　　6 . 6 组织级培训(OT) 46

　　7 支持和保障 48

　　7 . 1 度量和分析(MA) 48

　　7 . 2 根因分析和解决(CAR) 51

　　7 . 3 配置管理(CM) 55

　　7 . 4 安全管理(SEC) 58

　　7 . 5 决策分析和解决(DAR) 62

　　7 . 6 过程质量保障(PQA) 65

　　8 产品研发 67

　　8 . 1 产品规划(PDP) 67

　　8 . 2 需求工程(RQE) 71

　　8 . 3 架构与设计(AD) 74

　　I

　　GB/T 42560—2023

　　8 . 4 实现(IMP) 77

　　8 . 5 构建与集成(BI) 79

　　8 . 6 测试(TE) 81

　　8 . 7 持续集成和持续交付(CICD) 84

　　9 服务管理 87

　　9 . 1 战略服务规划(SSP) 87

　　9 . 2 服务交付(SD) 91

　　9 . 3 服务监控(SVCM) 95

　　9 . 4 服务连续性保障(SC) 99

　　10 基础设施 106

　　10 . 1 系统与工具规划(STP) 106

　　10 . 2 系统与工具支撑(STS) 109

　　10 . 3 环境支撑(ES) 112

　　附录 A(资料性) 能力域中英名称对照表 115

　　参考文献 117

　　Ⅱ

　　GB/T 42560—2023

　　前 言

　　本文件按照 GB/T 1 . 1—2020《标准化工作导则 第 1 部分:标准化文件的结构和起草规则》的规定起草 。

　　请注意本文件的某些内容可能涉及专利 。本文件的发布机构不承担识别专利的责任 。

　　本文件由全国信息技术标准化技术委员会(SAC/TC28)提出并归口 。

　　本文件起草单位:北斗天地股份有限公司 、中国电子技术标准化研究院 、南京大学 、华为技术有限公司 、网易(杭州)网络有限公司 、中兴通讯股份有限公司 、工银科技有限公司 、中国航天系统科学与工程研究院 、中国商用飞机有限责任公司北京民用飞机技术研究中心 、腾讯科技(深圳)有限公司 、杭州朗和科技有限公司 、南京中兴软件有限责任公司 、广东益安人防工程科技有限公司 、航天中认软件测评科技(北京)有限责任公司 、爱捷软件开发(深圳)有限公司 、震兑工业智能科技有限公司 、北京高质系统科技有限公司 、北京软件和信息服务交易所有限公司 、山东正中信息技术股份有限公司 、上海计算机软件技术开发中心 、云南电网有限责任公司信息中心 、神州数码系统集成服务有限公司 、普元信息技术股份有限公司 、中国电子科技集团公司第五十四研究所 、成都信息工程大学 、中国人民解放军军事科学院国防科技创新研究院 、北方民族大学 、北京邮电大学 、云南南天电子信息产业股份有限公司 、联通数字科技有限公司 、内蒙古东润能源科技有限公司 、成都新希望金融信息有限公司 、深圳市海德森科技股份有限公司 、江苏汤谷智能科技有限公司 。

　　本文件主要起草人:张旸旸 、荣国平 、冯建 、张文渊 、徐毅 、陈谔 、胡继东 、钱湘隆 、郭栋 、袁玉宇 、朱少凡 、王芹 、殷柱伟 、翁扬慧 、王公韬 、赵国亮 、吴穹 、姚炳雄 、严亮 、庄园 、张建成 、沈颖 、李玲瑶 、赵一博 、王晓朋 、钱淑丽 、舒红平 、史殿习 、韩强 、刘亚 、张贺 、李强 、冯常健 、周天才 、温建波 、董冠涛 、汪辮 、陈晓敏 、张晔 、周长怀 、周启平 、雷晓宝 、代东洋 、张玉良 、许志国 、蔡立志 、马文 、沈伟 、王茹 、薛超 、丁静 、李杉杉 、匡宏宇 、陈杰 、张小燕 、苏春山 、于长钺 、熊辉 、宋雨伦 、刘全东 、赵永亮 、张华山 、刘丹 。

　　Ⅲ

　　GB/T 42560—2023

　　引 言

　　开发运维一体化对软件的价值赋以全新的概念,即以软件系统功能在生产环境中的部署并为用户持续提供服务作为价值判断依据 。在这一基本价值观的牵引下,需要组织打通不同部门之间的壁垒;建立项目或者团队的共同愿景;快速、持续地完成软件系统功能的策划、开发、交付以及运维,实现价值的持续流动 。

　　开发运维一体化作为软件开发和运维的一种新范式,已经越来越多地被当前主流组织采用,对软件产业的发展有着极其重要的作用 。为指导开发运维一体化在各行业更好地应用和落地,促进组织高效转型,推动产业持续发展,本文件提出了开发运维一体化的能力成熟度模型,汇集最佳实践,刻画组织开发运维一体化从不成熟走向成熟的路线图 。模型由能力域、能力以及实践集三层结构构成,包含项目管理、过程改进、支持和保障、产品研发、服务管理以及基础设施等六个能力域,共计 30 个能力,对软件开发运维一体化所涉及的相关角色、活动和具体实践进行了系统梳理和规定,能够有效指导各方围绕软件开发运维一体化展开活动 。

　　Ⅳ

　　GB/T 42560—2023

　　系统与软件工程 开发运维一体化

　　能力成熟度模型

　　1 范围

　　本文件规定了开发运维一体化能力成熟度的模型和内容 , 建立了能力成熟度框架 , 主要包括能力域分类和成熟度等级定义;围绕项目管理 、过程改进 、支持和保障 、产品研发 、服务管理和基础设施 6 大能力域 , 详细定义了归属于各个能力域的能力以及支撑不同能力的各个实践活动的具体要求 。

　　本文件适用于:

　　— 组织寻求供应商 , 以获取软件系统和服务的开发和运维 , 并要求确保软件开发质量 、效率及后期运维的质量 ;

　　— 希望展现其软件开发 、交付以及后期运维管理能力和成熟度的组织 ;

　　— 通过本文件的有效实施与运行来持续改进软件开发 、交付以及后期运维管理绩效的组织 ;

　　— 依据本文件的要求实施评估的第二方和第三方 。

　　2 规范性引用文件

　　本文件没有规范性引用文件 。

　　3 术语 、定义和缩略语

　　3 . 1 术语和定义

　　下列术语和定义适用于本文件 。

　　3 . 1 . 1

　　制品 artifact

　　由某一种软件开发和运维过程所使用的或产生的一种信息的物理件 。

　　注 : 制品的实例有模型 、源文件 、文字和二进制可执行文件等 。制品构成可部署构件的实现 。

　　[来源: GB/T 11457—2006 , 2 . 76 , 有修改] 3.1.2

　　胜任力 competency

　　能将某一工作中有卓越成就者与普通者区分开来的个体的深层次特征 。

　　注 : 可以是动机 、特质 、自我形象 、态度或价值观 、某领域知识 、认知或行为技能等任何能被可靠测量或计数的并且能显著区分优秀与一般绩效的个体特征 。

　　3.1.3

　　配置基线 configuration baseline

　　在解决方案或解决方案组件的生存周期的特定时间正式制定的配置信息 。

　　注 : 配置基线加上来自这些基线的已批准变更构成当前的配置信息 。

　　1

　　GB/T 42560—2023

　　3.1.4

　　配置项 configuration item

　　专为配置管理而设计的工作产品 , 在配置管理过程中被视为一个单独的实体 , 是配置管理活动管控的最小元素 。

　　3.1.5

　　开发运维-体化 development and operations

　　软件系统开发和运维的一种新的范式和方法学 。

　　注 : 开发运维一体化旨在打破软件系统开发和运维之间的壁垒 , 建立项 目和团队的共同愿景 , 从而快速地 、持续地完成软件系统功能的开发 、交付以及运维 。

　　3.1.6

　　熔断 fusing

　　当服务出现请求响应过慢或者其他错误时 , 通过切断导致服务异常的请求链路从而快速恢复服务的活动 。

　　3.1.7

　　迭代 iteration

　　依照实施 、反馈和改进再实施进行循环往复的过程和实践 。

　　注 : 其目的通常是为了持续稳定地逼近所需的 目标或结果 , 降低误判风险 。不仅用于开发活动 , 还可用于项 目 的策划 、执行 、验证和确认及回顾等活动中 。

　　3.1.8

　　成熟度等级 maturity level

　　用以刻画组织过程在满足组织级业务目标的能力 。

　　注 : 能力成熟度共分为五个级别 , 分别为初始级 、已管理级 、已定义级 、定量管理级和持续优化级 。具体参见 4 . 2 . 4 。 3.1.9

　　机会 opportunity

　　不确定性对目标达成的正面影响 。

　　3 . 1 . 10

　　组织过程资产 organizational process asset

　　用以支持组织过程的部署 、应用 、管理以及改进的制品和数据等 。

　　注 : 典型地 , 组织过程资产包括过程架构 、模板 、标准 、数据 、风险和机会库等 。

　　3 . 1 . 1 1

　　组织过程资产架构 organizational process asset architecture

　　过程类型和过程资产类型之间的结构性关系或框架 。

　　注 : 通过对过程的类型进行定义 , 同时对过程资产类型进行定义 , 按照合理的模式或框架建立二者的关联关系 , 即形成了过程资产架构 。

　　3 . 1 . 12

　　效能 performance

　　开发运维一体化过程和实践中持续地 、高质量地交付用户价值的能力 。

　　3 . 1 . 13

　　流水线 pipeline

　　将软件开发和运维过程按照合理的内在逻辑和关系拆分为若干专注于特定任务和目标的子活动 。注 : 软件开发运维一体化中的流水线通过选择并组合子活动以实现特定的业务 目标 , 其自动化和持续流动是实现

　　开发运维一体化的关键 。

　　2

　　GB/T 42560—2023

　　3 . 1 . 14

　　实践组等级 practice group level

　　用以刻画某个特定能力在满足该能力意图(参见每一个能力的能力说明)的程度和等级 。

　　注 : 一般实践组等级由一组实践来支撑,不同能力的实践组等级数量不等,最少两个级别,最多五个级别 。

　　3 . 1 . 15

　　质量门禁 quality gate

　　在定义的工作流中用于进行自动化看护的质量指标卡点 。

　　注 1 : 通过设置门禁关卡检查的方式保障质量,通常用于自动化的流水线中,通过工具或者人工方式检查所选定的质量指标实际值是否满足所设定的门禁条件 。

　　注 2 : 如代码检查的问题数量 、测试执行的通过率等,如果检查结果为不达标,则该门禁产生作用,可阻止流水线的继续执行 。

　　3 . 1 . 16

　　服务 service

　　基于软件系统的活动 、工作和职责的履行 。

　　注 1 : 服务是自包含的 、固有的 、离散的,可包含其他服务,一般是无形的产品 。

　　注 2 : 某些情况下,服务也可以是软件对外提供功能的一种形式,例如微服务架构 。

　　3 . 1 . 17

　　服务协定 service agreement

　　服务相关各方在履行服务的过程中需遵循的契约 。

　　3 . 1 . 18

　　服务治理 service governance

　　为确保服务能够可靠 、安全 、稳定地运行的相关管控活动 、绩效和风险管理的集合 。

　　3 . 1 . 19

　　服务等级协定 service level agreement

　　在一定开销下为保障服务的性能和可用性,服务提供商与用户间定义的一种双方认可的协定 。

　　3 . 1 . 20

　　利益相关方 stakeholder

　　在系统或所属其特性中有权利 、份额 、声明或利益,以满足其需要及期望的个体或组织 。

　　示例 : 最终用户 、最终用户组织 、支持方 、开发方 、培训方 、维护方 、部署方 、需方 、供方组织和监管机构 。

　　注 : 某些利益相关方可具有相互对立或系统对立的利益 。

　　3 . 1 . 21

　　供方 supplier

　　与需方达成关于产品或服务供应协定的组织或个体 。

　　注 : 一般用于供方的其他术语有承包人 、生产者 、卖家 、供应商 。需方和供方有时可以是同一个组织的不同部分 。

　　3 . 1 . 22

　　任务 task

　　要求的 、推荐的或可允许的活动 。

　　注 : 其目的是为了支持一个或多个过程输出的达成 。

　　3 . 2 缩略语

　　下列缩略语适用于本文件 。

　　AD:架构与设计(Architecting anDDesigning)

　　3

　　GB/T 42560—2023

　　BI:构建与集成(BuilDing anD Integration)

　　CAR:根因分析和解决(Causal Analysis anD Resolution)

　　CICD:持续集成和交付(Continuous Integration & Continuous Delivery)

　　CM:配置管理(Configuration ManageMent)

　　DAR:决策分析和解决(Decision Analysis anD Resolution)

　　DevOps:开发运维一体化(DevelopMent anD Operations)

　　ES:环境支撑(EnvironMent Supporting)

　　ESP:估算与计划(EStiMating anDPlanning)

　　GOV:组织治理(GOVernance)

　　IMP:实现(IMPleMentation)

　　MA:度量和分析(MeasureMent anDAnalysis)

　　MC:监控与调整(Monitoring anDControl)

　　OT:组织级培训(Organizational Training)

　　PAM:过程资产管理(Process Asset ManageMent)

　　PDP:产品规划(ProDuct Planning)

　　PERM:效能管理(PERforMance ManageMent)

　　PGL:实践组等级(Practice Group Level)

　　PII:过程改进基础设施(Process IMproveMent Infrastructure)

　　PQA:过程质量保障(Process Quality Assurance)

　　PROM:过程管理(PROcess ManageMent)

　　ROM:风险与机会管理(Risk anD Opportunity ManageMent)

　　RQE:需求工程(ReQuireMent Engineering)

　　SC:服务连续性(Service Continuity)

　　SD:服务交付(Service Delivery)

　　SEC:安全管理(SECurity ManageMent)

　　SLA:服务等级协议(Service Level AgreeMent)

　　SM:供方管理(Supplier ManageMent)

　　SSP:战略服务规划(Strategic Service Planning)

　　STP:系统与工具规划(SysteMs anD Tools Planning)

　　STS:系统与工具支撑(SysteMs anD Tools Supporting)

　　SVCM:服务监控(SerViCe Monitoring)

　　TE:测试(TEsting)

　　4 概述

　　4 . 1 开发运维-体化

　　开发运维一体化(DevOps)以软件系统功能在生产环境中的部署并为用户持续提供服务作为价值实现的判断依据 。在这一基本价值观的牵引下,需要组织打通不同部门之间的协作壁垒;建立项目或者团队的共同愿景;快速 、持续地完成软件系统功能的开发 、交付以及运维,从而实现价值的持续流动 。一些基本约定如下 。

　　— 开发运维一体化概念涵盖的组织范围不局限于开发(或类似)和运维(或类似)两个部门,在共

　　4

　　GB/T 42560—2023

　　同愿景的引领下 , 其对应的组织范围可能(但不限于)扩展到安全 、合规 、人力资源等相关部门 。

　　— 开发运维一体化鼓励价值流的可视化 , 允许对“价值流”的概念按实际需要和上下文泛化 , 以鼓励多种形式 、层次以及对象的可视化 。

　　— 开发运维一体化鼓励通过搭建工具链来支持高等级自动化 。

　　— 为促进价值顺畅流动 , 在开发运维一体化的模式之下 , 应重视软件开发质量 。

　　4 . 2 能力成熟度模型

　　4 . 2 . 1 模型概述

　　本文件通过六项能力域 、30 项能力以及五级能力成熟度来描述开发运维一体化成熟度模型 , 见图 1 :

　　— 六项能力域 , 包括项目管理 、过程改进 、支持和保障 、产品研发 、服务管理以及基础设施 ;

　　—30 项能力见表 1 列表及附录 A;

　　— 五级能力成熟度 , 详情见表 2 。

　　图 1 也展示了 Devops 中各能力与成熟度等级的关系 , 各成熟度等级包含的能力及对应实践不同 , 如成熟度二级要求 ESP、MC、SM、PERM 等 13 项能力应达到实践组等级二级 , 具体能力的分级及实践示例在第 5 章 ~第 10 章有相应的描述 。

　　5

　　GB/T 42560—2023

　　图 1 开发运维一体化能力成熟度模型

　　6

　　GB/T 42560—2023

　　表 1 能力域与能力列表

　　能力域

　　能力

　　项目管理

　　估算与计划

　　监控与调整

　　风险与机会管理

　　供方管理

　　过程改进

　　组织治理

　　过程改进基础设施

　　过程资产管理

　　过程管理

　　效能管理

　　组织级培训

　　支持和保障

　　度量和分析

　　根因分析和解决

　　配置管理

　　安全管理

　　决策分析和解决

　　过程质量保障

　　产品研发

　　产品规划

　　需求工程

　　架构与设计

　　实现

　　构建与集成

　　测试

　　持续集成和交付

　　服务管理

　　战略服务规划

　　服务交付

　　服务监控

　　服务连续性

　　基础设施

　　系统与工具规划

　　系统与工具支撑

　　环境支撑

　　7

　　GB/T 42560—2023

　　表 2 能力实践组等级演进表

　　PGL

　　特征

　　基本要求

　　五级

　　持续优化级 (optiMizing)

　　● 在四级基础之上(即包含所有四级实践)

　　● 应用统计方法或其他量化技术来识别影响过程输出结果的一般原因,优化 、提升过程性能以更好地支持组织业务目标的达成

　　四级

　　定量管理级 (Quantitively ManageD)

　　● 在三级基础之上(即包含所有三级实践)

　　● 应用统计方法或其他量化技术识别并消除引发过程性能波动的特殊原因,提升过程稳定性和对过程输出结果的预测能力

　　三级

　　已定义级(DefineD)

　　● 在二级基础之上(即包含所有二级实践)

　　● 有横跨多个项目或部门的标准流程定义和相应的裁剪规范

　　● 项目或团队持续使用和贡献组织过程资产

　　二级

　　已管理级 (ManageD)

　　● 有满足能力全部意图和价值的实践集,支持能力相关过程定义所需

　　● 定义的过程具有明显的可重复特征

　　● 识别项目或团队的各类目标,管控针对目标的进度以及偏差

　　一级

　　初始级(Initial)

　　● 有满足能力意图和价值的初步方法

　　● 尚没有完整的 、系统的实践集以充分支持能力所包含的意图和价值

　　4 . 2 . 2 能力域 、能力和实践

　　Devops 能力成熟度模型可拆分为能力域 、能力以及实践集三层结构见图 2 。整个模型包含六个能力域,分别为项目管理 、过程改进 、支持和保障 、服务管理 、产品研发以及基础设施 。 能力域由若干有 一定关联的能力所组成,作为一个抽象整体,体现了组织进行过程改进的基本单元 。

　　8

　　GB/T 42560—2023

　　图 2 能力域 、能力 、实践集结构图

　　能力是由一组有关联关系的若干实践组成,作为一个抽象整体(即实践集),实现一个或者多个事先定义的意图或目标 。表 1 列出所有的能力域以及相应的能力 。

　　实践也称最佳实践,是模型的最基本组成单位,描述了开发运维一体化特定环节中具备广泛认同的实践,包括方法 、工序以及工具等 。这些最佳实践对其他应用开发运维一体化模式的团队和个体具有明显的借鉴和参考意义 。若干有关联关系的最佳实践组成的集合是支撑能力意图和价值达成的基本单位 。

　　4 . 2 . 3 模型视图

　　模型视图由能力域组合而成 。 通过构建不同的视图,模型可以支持不同的应用场景和应用领域 。本文件定义的模型提供两类视图,即推荐方式和定制方式 。本文件目前仅支持一种视图,即表 1 中除了供方管理能力之外,其他能力均应包含在内 。

　　a) 推荐方式:本方式由按照内在逻辑关系事先定义的若干能力域组合而成 。推荐方式的视图由

　　9