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

系统与软件工程开发运维一体化能力成熟度模型2023-05-23发布2023-05-23发布I Ⅲ 12规范性引用文件 3.1术语和定义 13.2缩略语 34概述 44.1开发运维一体化 44.2能力成熟度模型 55项目管理 5.1估算与计划(ESP) 5.2监控与调整(MC) 5.3风险与机会管理(ROM) 225.4供方管理(SM) 6过程改进 6.1组织治理(GOV) 276.2过程改进基础设施(PI) 6.3过程资产管理(PAM) 346.4过程管理(PROM) 376.5效能管理(PERM) 6.6组织级培训(OT) 467支持和保障 7.1度量和分析(MA) 487.2根因分析和解决(CAR) 7.3配置管理(CM) 7.4安全管理(SEC) 7.5决策分析和解决(DAR) 627.6过程质量保障(PQA) 658产品研发 8.1产品规划(PDP) 8.2需求工程(RQE) 718.3架构与设计(AD) 748.4实现(IMP) 8.5构建与集成(BI) 8.6测试(TE) 8.7持续集成和持续交付(CICD) 849服务管理 9.1战略服务规划(SSP) 9.2服务交付(SD) 9.3服务监控(SVCM) 9.4服务连续性保障(SC) 9910基础设施 10.1系统与工具规划(STP) 10.2系统与工具支撑(STS) 10.3环境支撑(ES) 附录A(资料性)能力域中英名称对照表 参考文献 系统与软件工程开发运维一体化1范围本文件规定了开发运维一体化能力成熟度的模型和内容，建立了能力成熟度框架，主要包括能力域分类和成熟度等级定义；围绕项目管理、过程改进、支持和保障、产品研发、服务管理和基础设施6大能力域，详细定义了归属于各个能力域的能力以及支撑不同能力的各个实践活动的具体要求。本文件适用于：——组织寻求供应商，以获取软件系统和服务的开发和运维，并要求确保软件开发质量、效率及后期运维的质量；——希望展现其软件开发、交付以及后期运维管理能力和成熟度的组织；——通过本文件的有效实施与运行来持续改进软件开发、交付以及后期运维管理绩效的组织；——依据本文件的要求实施评估的第二方和第三方。2规范性引用文件本文件没有规范性引用文件。3.1术语和定义下列术语和定义适用于本文件。由某一种软件开发和运维过程所使用的或产生的一种信息的物理件。能将某一工作中有卓越成就者与普通者区分开来的个体的深层次特征。在解决方案或解决方案组件的生存周期的特定时间正式制定的配置信息。2专为配置管理而设计的工作产品，在配置管理过程中被视为一个单独的实体，是配置管理活动管控的最小元素。开发运维一体化developmentandoperations软件系统开发和运维的一种新的范式和方法学。当服务出现请求响应过慢或者其他错误时，通过切断导致服务异常的请求链路从而快速恢复服务的活动。依照实施、反馈和改进再实施进行循环往复的过程和实践。成熟度等级maturitylevel用以刻画组织过程在满足组织级业务目标的能力。不确定性对目标达成的正面影响。组织过程资产organizationalprocessasset用以支持组织过程的部署、应用、管理以及改进的制品和数据等。组织过程资产架构organizationalprocessassetarchitecture过程类型和过程资产类型之间的结构性关系或框架。开发运维一体化过程和实践中持续地、高质量地交付用户价值的能力。将软件开发和运维过程按照合理的内在逻辑和关系拆分为若干专注于特定任务和目标的子活动。3用以刻画某个特定能力在满足该能力意图(参见每一个能力的能力说明)的程度和等级。在定义的工作流中用于进行自动化看护的质量指标卡点。基于软件系统的活动、工作和职责的履行。服务相关各方在履行服务的过程中需遵循的契约。为确保服务能够可靠、安全、稳定地运行的相关管控活动、绩效和风险管理的集合。服务等级协定servicelevelagreement在一定开销下为保障服务的性能和可用性，服务提供商与用户间定义的一种双方认可的协定。在系统或所属其特性中有权利、份额、声明或利益，以满足其需要及期望的个体或组织。与需方达成关于产品或服务供应协定的组织或个体。3.2缩略语下列缩略语适用于本文件。AD:架构与设计(ArchitectingandDesigning)4BI:构建与集成(BuildinganCAR:根因分析和解决(CausalAnalysisandResoCICD:持续集成和交付(ContinuousIntDAR:决策分析和解决(DecisionAnalysisIMP:实现(IMPlementation)MC:监控与调整(MonitoringandControl)PAM:过程资产管理(ProcessAsPERM:效能管理(PERformancPGL:实践组等级(PracticeGroupLPI:过程改进基础设施(ProcessImprovementPROM:过程管理(PROcessManagement)RQE:需求工程(ReQuirementEngineering)SSP:战略服务规划(Strategic开发运维一体化(DevOps)以软件系统功能在5本文件通过六项能力域、30项能力以及五级能力成熟度来描述开发运维一体化成熟度模型，见——30项能力见表1列表及附录A;图1也展示了DevOps中各能力与成熟度等级的关系，各成熟度等级包含的能力及对应实践不实践示例在第5章～第10章有相应的描述。6成熟度二级成熟度三级成熟度四级PGI.1PGL2PGI.3PGL47能力组织级培训战略服务规划8表2能力实践组等级演进表●在四级基础之上(即包含所有四级实践)●应用统计方法或其他量化技术来识别影响过程输出结果的一般原因，优化、提升过四级●在三级基础之上(即包含所有三级实践)●应用统计方法或其他量化技术识别并消除引发过程性能波动的特殊原因，提升过已定义级●在二级基础之上(即包含所有二级实践)●有横跨多个项目或部门的标准流程定义和相应的裁剪规范●项目或团队持续使用和贡献组织过程资产已管理级●有满足能力全部意图和价值的实践集，支持能力相关过程定义所需●定义的过程具有明显的可重复特征●识别项目或团队的各类目标，管控针对目标的进度以及偏差●有满足能力意图和价值的初步方法●尚没有完整的、系统的实践集以充分支持能力所包含的意图和价值DevOps能力成熟度模型可拆分为能力域、能力以及实践集三层结构见图2。整个模型包含六个能力域，分别为项目管理、过程改进、支持和保障、服务管理、产品研发以及基础设定关联的能力所组成，作为一个抽象整体，体现了组织进行过程改进的基本单元。9显的借鉴和参考意义。若干有关联关系的最佳实践组成的集合是支撑能力意图和价值达成的基本●所有能力(供方管理除外)均满足实践组等级(PGL)等级四级●所有能力(供方管理除外)均满足实践组等级(PGL)等级已定义级●所有能力(供方管理除外)均满足实践组等级(PGL)等级已管理级●ESP、MC,SM、PERM、GOV、PI、CM、MA、TE、CICD,BI,SD,PQA和STS应满足 关系的理解的深入，项目估算方法及其运用可能会发生改变。典型属性包括复杂性、难度针对关键产物，参考任务属性，使用多种方法开展资源估算。通常由团队成员执行自下而上的是一种反复进行的活动。在开发和运维的整个生存周期内，如果有新的可用信息，将会对资源进行——定期评估个体的工作负荷以确保与资源匹配，根据需要调整个体承诺，以改善并避免过度使用经过实践检验的组织资产来实施估算和计划可以有效地融入组织层面其他项目的优秀做——人员配置管理关键依赖关系和活动，监控工作环境以识别问题，与受影响的利益相关方一起管理和解决 -风险数据库；高级管理层确保选定的决策是由统计和定量分析驱动的，且与绩效、实现质量和流程绩效目标 一套过程不可能适合所有的项目和场景，因此通过定义裁剪规范和指南，并及时地进行维护更 -解决机会和问题并传达结果。-价值流图； 构建端到端的数据度量体系，覆盖研发运维各个过程领域的过程性质的指标，以及结果性质的效能数据、分析模型和研发工具链、工作流程、管理机制等深度融合，相关数据可以有效刻画DevOps过程能力对组织业务目标的支持状况，从而为识别效能相关的重要改进提供基础。鼓励自战略培训需求是侧重于长远的组织级能力的培养。根据发展规划，可以识别出需要什么样的人 ——支持修改和改进意见，与相关人员根据度量结果就业务目标达成情况、背后的原因进行讨解决根因问题可以有效地避免问题的反复发生或促进好的实践被深刻认识，进而在更多场合被根据分析结果，根据组织过程制定处理选定的结果的行动建议。这些行动建议旨在消除根本原创建并发布基线，代码基线与制品应有关联关系。除代码外，需求、设计等文档也应有基线。开发和运维过程中均包含安全合规的需求，以安全需求的识别为起点，设计——安全测试用例—-组件管理；在决策时充分调研和考虑备选方案。达成对备选方案、其潜在影响和必要决定的共识非常通过关注最重要的决策来降低成本。并非每个决策都足够重要到需要基于准则的决策过程的程—与受影响的利益相关方沟通规则和指南。可以同时使用多种方法来评价和做出基于准则的决策，确保当前条件下的最佳解决方案可以被—-不合规报告；工。需求工程的作用主要表现在：增强了项目涉众对复杂产品特征在细节和相互依赖关系上的理 本实践的开展意图为识别并消除架构设计与各类需求之间的偏差和相应风险，最大限度减少缺 —-概要设计说明书；——采用GitFlow模式。——收集和分析代码质量，制定代码度量指标，通过整合当前版本所有代码仓代码质量度量数——组织级的环境更新。优化组织级的环境应不断优化效率和质量，效率和质量均高于项目级 BI的完整性记录为持续优化效率和质量提供了数据支撑。组织级平台提供了横向数据对比的有 ——行为驱动开发(BDD,BehaviorDrivenDevelopme在DevOps流程开展CICD活动。——CI应通过后才能触发CD。 前项目中可调用的实际资产，在必要时可依据时间规划来估算未来一定时间内的资产投入基于统计等量化技术可以更加精确地对战略服务进行有效评估，从而使得计划变得更加科学有服务交付是服务管理生存周期中必不可少的重要环节。项目组或相关干系人通过制定的服务协服务协议应在开始提供服务之前建立。随着时间的推移，服务协议可以根据服务交付结果进行——建立服务交付方法，服务交付方法识别并描述了对成功交付服务至关重要的资源、流程和——内部状态报告模板，让主要利益相关方能够了解服务当前进行状态，保证服务交付的顺利——总结服务交付经验并形成知识库。知识库可以帮助组织人员在服务交付过程中遇到问题 监控工具可以帮助决策者更好地做出分析，并在运行出现偏离或者异常时做出科学的判断和决 评估组织内不同角色的监控目标。评估组织内不同角色对监控的需求以及需要达到的目 ——通过量化数据建立快速决策表。根据量化的数据建立服务异常时处理的流程和方式决策链——建立有效的规则，实时同步机制。建立各个服务治理的规则在不同环境之间有效的同步机 在服务故障时，处理速度决定了客户的满意度，在服务正常的情况下进行应急 —建立组织级服务治理平台。基于评审后的服务治理建设方案，可通过自研或基——评估组织内的服务变更流程。通过服务变更需求对组织内的服务变更环节进行整体性的梳——组织级服务变更流程说明。通过收集的变更需求建立的符合组织流程的服务变更流程说——服务故障应急处理团队联系说明。给出各个应急流程处理人员的关键人员信息的联系方——连续性风险评估系统。给出服务当前运行数据，可根据风险评估系统计算服务连续性风险DevOps鼓励开发运维活动通过自动化流水线的方式来提高工作效率，因此工具自动化也是 ——需求价值流数据可视化。在系统与工具中实现全流程的数据可视化，归集各个工具中的数能力估算与计划(EstimatingandPlanning