CESA-2021-1-026 软件服务能力模型与评估 征求意见稿 V2

ICS

CCS

团体标准

T/CESAXXXX—2021

软件服务能力模型与评估

Softwareservicecapabilitymodelandassessment

征求意见稿

在提交反馈意见时，请将您知道的相关专利连同支持性文件一并附上。

已授权的专利证明材料为专利证书复印件或扉页，已公开但尚未授权的专利申

请证明材料为专利公开通知书复印件或扉页，未公开的专利申请的证明材料为专利

申请号和申请日期。

2021-XX-XX发布2021-XX-XX实施

中国电子工业标准化技术协会发布

T/CESAXXXX—2021

前  言

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

草。

本文件由中国电子技术标准化研究院提出。

本文件由中国电子工业标准化技术协会、中国电子技术标准化研究院归口。

本文件起草单位：。

本文件主要起草人：。

III

T/CESAXXXX—2021

软件服务能力模型与评估

1范围

本文件提出了软件服务提供方在从事软件服务过程中的实践活动要求。

本文件适用于：

——服务供方对自身软件能力进行构建、监视、测量和评价；

——外部评价机构对服务提供方的软件能力进行评价。

本文件所描述的软件服务过程中的实践，可结合软件组织的规模、应用领域、组织结构形式以及商

业目标等实际情况加以剪裁。

2规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，

仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本

文件。

GB/T28827.6-2019信息技术服务运行维护第6部分：应用系统服务要求

3术语和定义

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

3.1术语和定义

3.1.1

组织organization

一个行政管理结构，在此结构内部，其人员作为一个整体共同管理一个或多个项目或工作组，由共

同一位高层管理人员负责，并且在相同方针下运作。主要从事软件开发和/或服务的实体。可能是一个

独立实体，也可能是更大的实体的一个组成部分。

3.1.2

战略strategy

组织为实现长期目标所使用的方法和行动。

注：通常包括为了实现目标而实施的重点工作和任务、内外部资源配置方式、管理模式、技术路线等。

3.1.3

组织绩效organizationalperformance

组织为实现其战略目标而展现在不同层面上的有效输出。

1

T/CESAXXXX—2021

3.1.4

组织过程资产organizationalprocessassets

组织里被认为对定义和实施的过程有用的制品，它们提供项目和开发、剪裁、维护以及实施过程时

使用。

3.1.5

重构refactoring

在不改变系统功能前提下，开发人员不断地优化代码结构：清楚重复代码，改善程序的可读性，简

化程序的复杂度，让代码变得更灵活。

3.1.6

持续集成continuousintegration

每当完成一个新任务时，就进行集成和构建，每天要做多次集成构建。

4软件服务能力模型概述

软件服务能力模型旨在通过提升软件开发服务和持续服务能力，帮助客户和用户提升软件的业务价

值。本模型借鉴吸收了软件工程、项目管理、组织治理、质量管理、敏捷方法、精益软件开发等领域的

优秀实践，为软件组织提供改进和评价软件能力的一个模型。软件服务能力模型框架结构见下图1。

组织战略

能力改进支持能力开发与转化

投资收益

需求开发与管理组织标准过程集成

技术解决方案发布与部署

价值

验证与确认运行维护

软件开发

人员过程

工具方法

持续服务

软件工程项目管控支持活动

能力

图1软件服务能力模型框架结构

2

T/CESAXXXX—2021

软件服务能力模型框架主要包括组织服务能力建设与管理能力、软件工程管理能力、持续服务能力、

项目管控能力和项目及组织支持活动能力等五方面组成。

5组织服务能力建设与管理能力

5.1组织战略

组织基于使命、愿景和商业目标，设定软件开发服务和持续交付服务工作的战略、方向和期望，确

保软件服务能力和业务目标与公司战略保持一致，确保过程得到建立和维护。

a)组织应分析内外部因素，面向软件服务业务发展需求，通过对业务的预估与优化分析，达成对

自身业务、行业趋势以及国际秩序变化等的判断，制定和市场需求一致的中长期的战略决策，

确定软件开发和持续服务能力建设的范围和边界，从而驱动组织软件能力的不断增长；

b)组织应围绕其战略，考虑内外部环境的变化，识别和调整可持续竞争优势的需求，优化业务基

础架构，驱动灵活的业务流程和应用，形成与可持续竞争优势相匹配的软件开发与持续交付服

务能力建设和改进目标；

c)组织应提供足够的资源用于建立、执行、改进和评价软件服务能力改进。资源可包括人员、资

金、工具、设备、设施、环境和消耗品，还包括最高管理层的时间和精力。最高管理层应排定

资源的优先级，以实现短期和长期目标，并推动实现可重复和一致的过程活动；

d)组织应确保软件服务能力改进过程中相关角色的职责和权限得到合理的划分、规定、沟通和理

解，并得到有效执行；

e)组织应对服务能力改进目标进行分解，识别能够反映软件服务能力的组织绩效指标，确定度量

需要收集的数据与信息，定期跟踪和管理组织绩效指标达成状况，以提供最高管理层管理和监

督改进过程的运行情况和改进建议。

5.2组织能力改进支持体系

组织基于对软件服务能力建设和改进的要求，需在组织层面建立常态化、制度化的改进机制和支持

体系。

a)组织应形成内部过程评价机制，定期或必要时对组织过程与过程资产当前的强项与弱项进行识

别；

b)组织应系统梳理问题及机会，确定并维护组织能力改进的目标；

c)组织应建立并维护过程行动计划，确保改进行动得到计划、实施，并保持监督和持续改进；

d)组织应确保改进的成果纳入组织级过程资产中，相关内容应在适用范围内部署、推广、跟踪、

改进；

e)组织应将组织能力改进过程中有益于组织或后续项目的经验汇总、分析、整理，有价值的部分

纳入组织级过程资产。

5.3组织标准过程

组织应建立一个清晰的组织标准过程架构，能够清楚的展示各个过程资产之间的关系。组织标准过

程应明确各类项目必须遵守的活动及要求。

a)组织应建立可用的，符合项目特点，并具有一定灵活性的组织标准过程。可以包括组织内部的

有效最佳实践，也可以是结合企业自身情况完善后的业界最佳实践及标准；

b)组织应建立定期完善修改组织标准过程的机制，明确不同过程的维护者；

c)组织应结合组织的业务领域特点，使用过程执行者熟悉的语言及方式描述过程；

3

T/CESAXXXX—2021

d)组织应建立约束违反过程情况发生的机制，建立有效的质量检查活动，在项目及组织中进行过

程符合的稽核；

e)组织应定期度量组织过程的执行效果，使过程执行者了解到过程及过程改进的价值。

5.4组织级能力开发与转换

组织应开展技术能力开发与转换工作，识别软件服务业务活动所需的人员知识、技能和过程能力，

提供培训确保人员具备相应能力；同时，建立人员能力发展、提升和转换机制，使人员能够自主且持续

地提升自身能力，获得发展机会。

a)组织应根据战略需要，建立并维护组织技术能力，识别组织人员执行业务活动所需的知识、技

能和过程能力；

b)组织应及时关注新模式、新方法、新过程、新工具等技术动态，保持对软件工程技术的当代最

高水平的了解，评价外部可获取的技术，必要时建立新技术引入计划，做好新技术的预研与转

化工作；

c)组织应建立软件服务相关的知识体系或培训课程体系，包括软件工程基础、针对所属领域的专

业知识与行业知识；

d)组织应结合培训需求及能力改进需要，制定组织级培训计划，培训内容覆盖管理、技术、工具、

过程及综合知识，确保人员具备执行任务所需的知识、技能和经验；

e)组织定期对培训管理、讲师库和培训教材库的可用性进行定期评估和改进；

f)建立人员的能力发展机制，不断提高人员执行指定任务和责任的能力；

g)建立能力提升与转换的机制，给予个人充足的动力去提升和转换自身的能力，评价人员对组织

知识与创新的贡献。

6软件工程管理能力

6.1概述

本章描述了软件开发与持续服务的工程过程要求。为了确保组织具备相应的服务能力并发挥其效

能，至少应建立以下过程：

a)软件生存周期管理；

b)需求开发与管理；

c)技术解决方案；

d)验证与确认；

e)集成；

f)发布与部署。

CMMI-DEV成熟度模型提供了过程目标和实践的描述，本部分中仅规定软件服务提供方实施过程化管

理后应达到的能力要求和关键指标。

对已按照CMMI-DEV成熟度模型要求建立软件过程能力改进能力的组织，宜按照本部分的要求对已建

立的过程实施改进。

6.2软件生存周期管理

软件生存周期包含了软件项目设计、开发、部署、运行、维护和退役等各个阶段的所有过程和活动，

生存周期模型规定了这些过程和活动的内容和目标，将过程和活动映像到一个整体的框架。软件生存周

期管理包括指导组织开发、使用、维护软件的生存周期模型的相关活动。组织通过使用软件生存周期来

4

T/CESAXXXX—2021

使组织的软件业务活动标准化，保证软件业务活动的完整性和有效性，提高管理的透明度、可控性和有

序性，降低开发成本，提升组织绩效。

a)组织应根据自身需求对要交付的软件产品和服务，定义适当的生存周期模型对其进行管理和维

护，如瀑布模式、敏捷模式等；

b)组织应将软件生存周期模型作为组织的标准过程描述的一部分进行文档化；

c)组织应建立并维护软件生存周期模型的剪裁准则与指南。包括项目或部分组织的特定需要而对

软件生存周期模型进行受控的变更、可能运用的选项以及在选项之间选择的准则等；

d)组织应定期对软件生存周期模型及其剪裁准则与指南的适宜性、有效性进行评审；

e)组织应通过分析软件业务过程各相关度量项数据来持续优化软件生存周期模型，使之更好地适

应和指导组织的软件业务过程。

6.3需求开发与管理

需求开发与管理的目的是挖掘、分析并建立用户需求、产品需求与组件需求，确保利益相关方取得

一致理解，并调整需求、计划和工作产品。

a)组织应定义与需求开发过程一致的活动，包括需求获取、需求分析、需求描述和需求确认等活

动；

b)组织应将用户需求、产品需求和产品组建需求文档化，并划分需求优先级。包括利益相关方的

需要、不同的产品生存周期阶段（如验收测试准则）和产品属性（如响应性、安全性、可靠性、

可维护性等）相关的需要、设计解决方案（如产品集成、特定架构模型的使用等）的选择及所

带来的约束等；

c)组织应不断对需求进行挖掘、细化说明、分析并确认，并保留确认的相关文档。可以用故事、

场景、用例、产品需求列表以及产品功能演示等形式进行；

d)组织应保持与开发、记录和维护需求和活动或工作产品之间的双向可追溯；

e)组织应确保需求是必要且充分的；

f)组织应在利益相关方的需求和约束条件之间取得平衡。

6.4技术解决方案

技术解决方案的目的在于选择、设计并实现对需求的解决方案。

a)组织应开发备选解决方案与选择准则；

b)组织应开展软件开发、采购、重用分析，基于选择准则，选择软件产品组件解决方案；

c)组织应建立编码规范，开展代码审查。确保代码编写符合标准规范，满足软件需求和软件设计；

d)组织应建立代码重构规范。成立代码重构专题小组，根据软件产品常见的问题，参考业界优秀

实践，指导代码重构的过程、方法、操作指南等内容。在全面推广之前，需要通过程序员的评

审，并在小范围内做试点。根据反馈，完善代码重构过程；

e)建立软件需求与软件设计与实现要素之间的双向可追溯性。确保软件需求与软件概要设计之间

的一致性；确保软件单元与软件详细设计之间的一致性。

6.5验证与确认

验证与确认确定软件系统或部件的需求是否完成和正确，每一阶段产品是否实现在上一阶段规定的

需求或条件，以及最后的产品或部件是否依从规定的需求的过程。确认选定的解决方案和组件能够满足

需求，证实选定的解决方案和组件在目标环境下能够实现其预期的用途。

a)验证的活动主要包括各种技术文档的同行评审、单元测试、部件测试、配置项测试、集成测试、

系统测试等质量控制活动；

5

T/CESAXXXX—2021

b)确认的活动主要包括试运行、模拟、验收测试等活动；

c)组织应尽早开展持续性的确认活动，有助于确保对正确的产品实施验证；

d)组织应保持对新产品的架构、耦合性强的设计、难度大的模块设计等变更成本高的技术文档（架

构）执行同行评审。执行同行评审应满足以下要求：

1)对所评审工作产品应建立明确的入口标准。被评审的工作产品应是满足一定标准和质量要

求的，增加评审价值；

2)应给所有的评委足够的时间做好评审前的准备。根据评审内容多少，需要给每个评委足够

的时间在评审前做好准备，保证评委对所评价的工作产品有必要的了解，甚至已经识别出一些

问题点。

3)赋予评委不同的角色。除了工作产品作者外，评审宜设立5类重要角色：评审组长、上游

映射者、下游使用者、阅读者和记录员。所有评委需要有足够的技术或业务背景知识，但不一

定要是“全能”专家；评审组长保证整个评审过程的有效执行。映射者则重点关注被评审工作

产品和其依据的上游文档的具体映射，发现遗漏、多余和不一致的问题。使用者则从使用角度

发现被评审工作产品的问题。阅读者则用有效的方式，保证所评审工作产品的内容都被覆盖到

了。记录员则在评审结束时记录效率相关数据。实际执行中，一个评委可以担当多个角色。

4)制定评审计划。在制定评审计划时，需要根据评审规模，依据评审速率（如设计页数/小时、

代码行数/小时等）安排评审的投入时间，保证必要的评审有效性（发现足够缺陷）。

5）使用检查单。根据工作产品做的能力、产品特点制定检查单，有效的评审需要有针对性强

的检查单。

6）发现缺陷是第一目标。评审的首要目的是尽可能的发现缺陷，并确保发现的问题都被修复

关闭。

7）收集评审效率数据并给出结论，判断是否需要复评。评审中收集缺陷、投入时间等效率数

据能够帮助组织更好的制定评审计划，分析后也能指出评审短板，对后续的改进提供输入。

8）对所评审工作产品应建立明确的出口准则。应定义好明确的出口准则，包括对缺陷和问题

的修复确认。

e)组织应分析与同行评审的准备、实施与结果相关的数据。建立完善各类方法的效率基线：收集

各类评审的投入及产出数据，建立各种方法的投入产出基线，并明确各基线的使用场景。

6.6集成

集成的目的是将产品组件集成至更复杂的产品组件或配装成完整的产品。按照所定义的集成方案和

过程通过逐次组装产品组件，以一个阶段或一个增量迭代阶段的方式完成完整的产品集成。

a)集成的主要活动包括集成的准备活动、使用和记录的集成方案和过程、使用产品组件的单次构

建或迭代的构建、验证并确认每个构建；

b)组织应对需求分析及设计活动中确定的接口要求进行管理，确保模块间、系统间的兼容性。

c)组织宜使用自动化的方式进行持续集成。测试的自动化及版本控制，可以逐步支持团队做到全

面的自动的持续集成，对已完成的产品组件使用自动化构建和持续集成，以提高集成效率和质

量。持续集成系统应具备以下能力：

1)提供统一的代码库。将所有的源代码保存在单一的位置，让开发人员都能从中获取最新的

源代码（以及以前的版本）；

2)自动构建并能做到快速构建的能力。应支持自动化创建脚本，使创建过程完全自动化，让

开发人员都可以输入较少命令就能完成系统的创建；

3)自动测试的能力。应支持测试自动化，开发人员都可以输入较少命令就能运行一套完整的

系统测试。在持续集成里面创建不仅是传统的编译和连接，还应包括自测试，自测试的代码是

6

T/CESAXXXX—2021

开发人员提交源码的时候同时提交的，是针对源代码的单元测试。应将所有自测试代码整合到

一起形成测试集，在所有的最新的源码通过编译和连接之后还应通过测试集才算是成功创建。

测试集宜支持模拟生产环境的自动测试，并且具备自动化的部署能力；

4)每个开发人员可随时向代码库提交代码。所有开发人员应在本地机器上做本地构建，成功后

再提交到版本控制库中。任何人都可以只输入一条命令就可以开始主创建。团队成员都可以很

容易并及时获取最新可执行的应用程序，清楚最新集成情况；

5）每次代码提交后都会在持续集成系统上触发一次构建。提倡开发人员频繁地签入（checkin）

修改过的代码，读取源代码、编译、连接、测试，整个创建过程都应自动完成。通过测试的创

建才是成功的构建，修复失败的构建是优先级最高的任务。

6.7发布与部署

通过规范的发布部署工作，将软件成果物（软件、硬件、及增量包等）高效、完整地交付客户。

a)组织应按验收要求将软件成果物进行整理打包，并对软件研发过程中涉及的变更请求、已知错

误和问题进行影响评估，完成系统发布；

b)组织应安排实施人员对软件系统进行部署应用；

c)组织应对部署不成功的软件进行回退或按要求提供补救措施；

d)组织应根据变更管理需求或已知问题，对发布后软件进行变更管理；

e)组织应对发布后软件进行跟踪管理，对发布后数据进行量化分析，对软件开发及发布的不断优

化提供决策支持。

7持续服务能力

本部分应符合GB/T28827.6-2019的规定。

8项目管控能力

8.1概述

软件项目管理覆盖了项目启动与准备、项目策划、监视与控制、项目收尾等阶段，以及供应商管理

和风险与机遇管理过程。

8.2项目准备与启动

项目准备与启动的目的是协调相关方期望，确定相关方需求及项目范围和目标，取得对项目的授权，

明确项目团队，发布项目章程。

a)识别项目机会，明确项目类型。在项目准备与启动阶段，应进行必要的商业论证。商业论证能

从商业角度决策项目是否值得组织投入。包括项目交付物的目标市场、市场定位、市场份额、

主要竞争对手，与竞品的优劣分析等。在商业论证中，应同时对业务需求和成本效益进行分析，

论证项目的合理性；

b)确定项目目标。在项目准备与启动阶段，应明确项目的目标。项目目标是项目成功与失败的标

准，也是指导项目前进的重要依据。项目目标应与组织的战略目标保持一致。项目目标可以包

括价值目标、技术目标、商业目标等；

c)识别利益相关方。识别利益相关方是定期识别项目相关方，分析和记录他们的利益、参与度、

相互依赖性、影响力和对项目成功的潜在影响的过程；

7

T/CESAXXXX—2021

d)组织任命项目经理，制定项目立项报告（任务书）。制定项目立项是编写一份正式批准项目并

授权项目经理在项目活动中使用组织资源的文件的过程。主要作用是，明确项目与组织战略目

标之间的直接联系，确立项目的正式地位，并展示组织对项目的承诺；

e)召开启动会议。项目启动会议应作为项目启动的标志。

8.3项目策划

项目策划的目的是开发和维护指导项目实施的各项计划，并获得各利益相关方对计划的承诺。项目

策划的目的是定义和细化工作目标，建立工作范围，定义管理策略和方法，定义项目的生命周期，估算

实现目标所需的工作量、成本、工期和资源，建立有效的项目计划，以为项目执行提供依据，增加满足

目标的可能性。

a)项目计划参数的估算得到建立与维护；

1）建立顶层的工作分解结构WBS，以估算项目范围；

2）建立并维护工作产品与任务属性的估算；

b)使用组织的标准过程集和剪裁指南来开发项目过程，保持更新，并遵循项目过程；

c)使用项目过程、组织过程资产和度量库制定计划并保持更新；

d)识别和协商依赖关系；

e)使用统计与其他量化技术来开发过程并保持更新，以实现质量与过程性能目标；

f)基于敏捷Scrum框架加上极限编程的计划活动也可满足项目策划相关最佳实践要求：

1）进入迭代（Sprint）前的大版本计划、小版本计划和迭代计划初步确定了项目范围及发布

节点、核心资源要求等。在迭代过程中应对产品需求列表的细化，可使用扑克牌估算（Cohn2010）

出用户故事的故事点数，迭代计划时的调整及用户故事任务的识别等活动，可以实现项目计划

参数的估算得到建立与维护；

2）敏捷团队在迭代前及迭代中应依据产品需求列表中的本次发布需求实现用户故事，估算出

所需工作量（软件项目中的主要成本）。项目所需其他预算应在做版本规划时识别出来，并在

迭代过程中根据实际情况做出调整；

3）不断识别迭代过程中的项目潜在风险。每日例会中识别出来的障碍就是会影响到迭代目标

实现的风险，重要的风险会记录在敏捷岛中以便跟踪处理；

4）在建立敏捷支持环境时，需明确技术、管理及其他项目使用或产出的数据存储及使用方式。

每个迭代的完成标准（Done）应包含需要归档的文档（数据）；

5）在版本规划时应识别项目所需资源（人、设备、开发测试环境等），在迭代过程中需将资

源缺乏问题作为障碍提出并解决；

6）利益相关人及敏捷团队的关系会在敏捷社区中进行定义，并在社区迭代中不断维护；

7）敏捷的项目计划，由版本计划、迭代计划，加上白板的任务认领及跟踪情况构成。

8.4监视与控制

监视与控制的目的是通过各种监控方式了解项目进展，当发现实际与计划存在显著偏离时采取合适

的纠正行动，以提高实现项目目标的可能性。

a)使用项目计划和项目过程管理项目。可从规模、工作量、进度、资源、知识和技能以及预算等

方面对比项目计划跟踪实际结果；

b)跟踪已识别的利益相关方参与和承诺情况；

c)当实际结果相较于计划结果存在显著差异时，识别并记录问题，采取调整措施并管理直至关闭；

d)基于敏捷Scrum框架下高频率的审查和调整的活动，也可满足项目监视与控制相关最佳实践要

求：

8

T/CESAXXXX—2021

1）迭代评审会、迭代回顾会和每日站立会让团队能够及时了解敏捷团队的任务执行情况，识

别相应阶段的问题并解决；

2）使用产品需求列表、迭代需求列表和燃尽图表示当前实际与计划的偏离情况，根据偏离程

度制定调整方案；

3）需设计好敏捷岛，将关键的利益相关人、风险等展示出来，在迭代中提醒团队。

8.5项目收尾

项目收尾的目的是根据项目目标判定项目的各项工作是否已达成，判定项目是否可结束。同时总结

项目的经验教训，为组织贡献过程相关信息和过程资产，通过改进组织过程和过程资产提高后续项目的

投资收益比，为开展新工作释放组织资源。

a)组织应建立项目收尾工作标准，以确保项目团队根据组织要求和项目实际情况，明确项目收尾

工作的流程和准则以及相关利益相关方，确保项目收尾工作顺利进行；

b)组织应依据项目已建立的各项目标，通过度量与分析总结目标的实际达成情况，并总结相关经

验教训，收集、整理和记录必要的资产信息和改进建议。

8.6供应商管理

组织确定并管理外包服务供应商，对供应商进行了解、选择、开发、使用和控制。

a)组织应建立外包计划，确定外包方案。外包方案的复杂性和详略程度应与计划外包的价值和相

关风险相匹配。通常包括：应满足的技术要求、工作内容说明、用于评估解决方案的过程和标

准的描述、在外包合同中的条款和条件、关于如何回应供应商的指导、供应商和组织完成询价

过程的时间表、处理问题的程序以及联络人等。组织根据计划外包的变化，及时更新外包方案；

b)组织根据外包解决方案，使用招标方式向潜在供应商征求解决提案，帮助各个潜在供应商做出

一致的、准确的和完整的回应，使组织能够有效和客观地比较和评估供应商，建立组织的合格

供应商目录，组织根据供应商的绩效及时维护合格供应商目录；

c)组织在确定潜在合格供应商时应考虑：外包范围和要求、外包策略、组织内部政策、法规要求。

在某些情况下，组织可根据经验、专业知识、过去的表现等预先验证首选供应商的资格。从首

选供应商列表中选择供应商可以减少招投标所需的工作量和时间；

d)组织根据供应商实施外包合同的质量、进度、响应速度、支持能力以及对组织软件开发过程的

贡献，定期评价供应商的绩效，支撑组织对供应商是否保留合格供应商资格作出决策。

8.7风险与机遇管理

风险与机遇管理是实现组织软件业务目标的基本能力。应对风险与机遇，为提高软件开发能力、增

加业务价值以及防止不利影响奠定基础。风险与机遇管理旨在专注于对组织软件业务领域的相关风险与

机遇进行识别、分析和管理。

a)识别和使用有助于风险与机遇的识别和分析,以发现影响目标实现能力的不断变化的环境；

b)定义和使用分析和处理风险与机遇的参数，识别高优先级的风险与机遇，以最大化成本效益可

能性的方式实现目标；

c)制定和持续更新风险与机遇管理策略，系统化的风险与机遇管理方法有助于避免问题并利用机

遇来提高实现目标的可能性；

d)制定和持续更新风险与机遇管理计划。将风险的影响降至最低，并最大限度地增加机遇的效益

以实现目标；

e)通过实施已计划的风险与机遇管理活动来管理风险与机遇。有效的风险管理可以减少业务目标

实现不可预见事件的发生，并通过利用机遇以来提高业务价值；

9

T/CESAXXXX—2021

f)持续收集组织风险和组织机遇数据，建立组织级风险库和机遇库。及时访问风险与机遇数据有

助于组织做出明智的决策，为组织达成目标提供更好帮助。

9项目及组织支持活动能力

支持过程是利益相关方按支持目标所从事的一系列相关活动集。支持过程有助于提高系统或软件产

品的质量。支持过程可由使用的组织实施；或作为一种服务，由一个独立的组织来实施；也可做为软件

项目的一项规定内容。为了确保组织具备相应的服务能力并发挥其效能，至少应建立以下过程：

a)质量管理；

b)配置管理；

c)度量分析管理；

d)文档管理。

9.1质量管理

质量管理活动分为组织级质量管理和项目级质量管理两个层级。

组织级质量管理旨在围绕组织的战略规划和业务目标，规划建立和优化组织级质量管理体系、质量

和过程绩效目标，开展组织级质量管理活动，客观评价组织质量体系的执行情况（体系审核）。

项目级质量管理评价对于项目的成功至关重要，质量评价可以根据适用的过程描述、标准和规程，

来检查已执行的过程和所产生的工作产品，并对发现的问题进行跟踪和解决，以最大限度地提高业务效

益和客户满意度。

a)组织级质量管理典型实践活动包括：

1）在组织级设立质量管理机构，明确组织级质量管理的职责，为系统开展组织级质量管理活

动、提升组织的质量管理能力，提供组织级资源和职责保障；

2）组织级质量管理机构为落实组织质量方针、实现质量目标，为履行组织级质量管理职责、

开展组织级质量活动，识别组织级质量管理活动和活动相关方，进行任务分解、权限和职责分

配、进度安排等，支撑组织级质量管理活动得到系统有序开展；

3）对组织的质量体系、组织级过程、产品或项目级的质量管理活动的输出和发生质量问题，

向组织管理层提供书面的质量问题报告和改进建议报告；

4）对组织的质量体系、组织级过程、产品或项目级的质量管理活动的输出和发生质量问题，

建立综合问题分析机制，给出系统解决建议，为治理层、业务管理层提供可见的体系过程质量、

产品质量、项目情况的书面报告，为各级决策和持续改进提供依据。

b)项目级质量管理典型实践活动包括：

1）项目应确定相对独立的质量管理人员和相关职责，开展质量管理活动；

2）项目应根据历史质量数据，开发、持续更新并遵循质量保证计划，并通过关注经常出现的

问题领域，降低成本并提高质量；

3）项目质量管理人员应在整个项目过程中，根据记录的过程和适用标准客观评价选定的已执

行过程和工作产品（成果），并通过识别和解决整个过程执行中的问题，提供高质量解决方案；

4）项目质量管理人员应组织对质量和不合规问题的沟通，并确保解决问题；

5）应对项目质量保证活动的信息进行记录；

6）在质量保证活动中识别并记录改进机会。

9.2配置管理

10

T/CESAXXXX—2021

配置管理过程是通过配置标识、配置变更控制、配置状态记录与报告和配置审核等活动，建立并维

护整个软件生存周期产生工作产品的完整性、一致性和可追溯性。

a)组织应制定配置管理策略；

b)标识并定义由过程或项目所产生的全部工作产品，并形成基线；

c)对工作产品/项的修改和发布，进行了控制；

d)对各相关方均是可用的，做了必要的修改和发布；

e)记录并报告了工作产品/项的状况和修改请求；

f)确保了每一软件项的完备性和一致性；

g)对每一软件项的存储、处置和交付进行了控制。

9.3度量管理

使用度量和分析来管理项目以保证项目过程和成功，或达成组织业务目标、提升组织绩效。

a)组织或项目应根据需要定义度量项，明确各度量项的获取方式，获取这些度量项并记录度量数

据；

b)组织应明确度量项的操作性定义，并根据需要持续更新度量项的操作性定义；

c)组织或项目应根据操作性定义获取指定的度量数据，并进行分析；

d)组织或项目应根据度量数据的分析报告，识别偏差等问题，并采取行动加以解决；

e)组织应建立并更新组织级的度量库，定期收集度量数据，汇聚到组织级度量库，分析度量数据，

并运用度量和性能数据来分析组织性能，确定性能的改进需求，并实施改进。

9.4文档管理

文档过程是一个记录由某一过程或活动产生信息的过程。

a)制定标识软件产品或服务的生存周期中所要产生的文档；

b)标识编制软件文档的标准；

c)标识由过程或项目产生的文档；

d)对全部文档的内容和目的进行规定、评审和批准；

e)根据已标识的标准，制作可用的文档；

f)按定义的准则维护了文档。

10评价方式与方法

10.1评价流程

10.1.1确定评价需求

a)确定评价目的

无论需方、供方、第三方在发起软件服务能力评价时，不同的评价目的对期望的评价结果的要求

不同，需综合考虑评价的整体场景、指标的选用、权重的设置及结果的应用等因素。

主要评价目的包括：

1)由需方发起的，针对某个软件服务项目的质量情况进行评价，从而对服务供方在此项目上

的服务成效进行评价；

2)由供方发起的，针对自身所提供的所有软件服务项目的质量情况进行评价，从而分析差异，

改进供方组织的服务能力；

3)由第三方发起（例如行业监管机构），针对某行业或某类型的软件服务项目进行客观公正

11

T/CESAXXXX—2021

评价，并得出在行业内或某服务类型的评价对比结果。

因此在进行软件服务能力评价时，宜先确定评价目的。

b)确定评价途径

评价的发起组织，可以根据评价目的需要及自身实施能力，选择不同的评价途径。

1)评价发起方可以通过自身资源执行评价过程，侧重于自身期望的评价结果。

2)评价发起方可以委托专业机构进行评价，以期望获得供方、需方及社会认可的评价结果。

10.1.2评价准备

a)确定服务类别

本文件主要针对软件开发服务和软件持续交付服务进行评价。

b)制定评审方案

1)评价者根据评价目的及评价活动的其他特点，确定实施步骤与时间安排、评价方法等，形

成评价方案；

2)评价者应从操作性、经济性、科学性、有效性等角度出发，对评价方案进行论证优化。

3)评价者可根据实际需求在一定范围内公开评价方案或其部分内容。

10.1.3评价实施

a)确定评价体系

1)评价者应根据评价目的、评价方案、评价对象特点等，在5.2~9.5中筛选合适的评价实践

并进行组合、剪裁、细化；

2)应选取合适的权重测算方法，为上述评价体系赋权，形成评价体系。

b)采集、加工客观证据/数据；

c)评价者应根据评价方案，确定数据采集的内容范围，实施数据采集并对所采集的客观证据/数

据进行验证；

d)评价者应对通过验证的客观证据/数据进行加工，将其转化为统一、可操作、易分析的客观事

实情况。

10.1.4准备评估发现

评价者应根据实践结合客观事实满足情况进行评估，得出软件服务能力的强项与弱项。

10.1.5形成评价结果

a)评价者应根据评估发现及其他信息，分析得出真实、准确的评价结论并对其进行描述；必要时

可在此基础上提出相关建议，形成评价结果；

b)评价者应对评价结果进行包括错误核查、误差分析、合理性验证等在内的质量稽核；

c)评价活动完成后，评价者应为评价对象或（和）相关方提供评价结果。

10.2评价方法

10.2.1权重测算方法

常用的权重测算方法主要包括层次分析法、专家咨询法、对偶比较法、变异系数法、熵值法等。

10.2.2客观证据/数据采集方法

常用的数据采集方法主要包括现场查验、资料查阅、问卷调查、会议座谈、独立访谈等。

12

T/CESAXXXX—2021

10.2.3数据加工方法

常用的数据加工方法主要包括除重、降噪、归类、格式转换、标引等。

10.3评价结果

a)内容

1)评价结果应包含：

——评价对象情况；

——评价方案（含评价目的、评价范围、评价准则、评价方法等）；

——评审依据；

——评价活动过程；

——评价发现及解释；

——评价结论及描述；

——评价时间；

——评价者情况。

2)根据评价活动需求与特点，评价结果宜包含：

——针对评价对象、相关方的工作建议；

——评价发现、评价结论及其他内容的使用建议及使用限制。

3)评价者宜使用图表等表现形式，直观地反映评估发现、评价结论及其他内容。

4)评价者应保护顾客信息，防止泄露、丢失；在发生或可能发生泄露、丢失时，应立即采取

补救措施。评价者不应以挪用、出售等形式非法向其他组织或个人提供顾客信息；当评价

结果确需引用顾客案例或相关内容时，评价者应视评价结果的公布、使用范围等，对其进

行处理。

b)形式

1)评价结果主要应以评价报告的形式呈现；根据需求，亦可以包括工作建议、工作方案、基

础数据、过程文件等。

2)评价结果通常应为书面形式。

13

T/CESAXXXX—2021

目  次

前  言.............................................................................................................................................................III

1范围.....................................................................................................................................................................1

2规范性引用文件.................................................................................................................................................1

3术语和定义.........................................................................................................................................................1

4软件服务能力模型概述.....................................................................................................................................2

5组织服务能力建设与管理能力.........................................................................................................................3

5.1组织战略.....................................................................................................................................................3

5.2组织能力改进支持体系.............................................................................................................................3

5.3组织标准过程.............................................................................................................................................3

5.4组织级能力开发与转换.............................................................................................................................4

6软件工程管理能力.............................................................................................................................................4

6.1概述.............................................................................................................................................................4

6.2软件生存周期管理.....................................................................................................................................4

6.3需求开发与管理.........................................................................................................................................5

6.4技术解决方案.............................................................................................................................................5

6.5验证与确认.................................................................................................................................................5

6.6集成.............................................................................................................................................................6

6.7发布与部署.................................................................................................................................................7

7持续服务能力.....................................................................................................................................................7

8项目管控能力.....................................................................................................................................................7

8.1概述.............................................................................................................................................................7

8.2项目准备与启动.........................................................................................................................................7

8.3项目策划.....................................................................................................................................................8

8.4监视与控制.................................................................................................................................................8

8.5项目收尾.....................................................................................................................................................9

8.6供应商管理.................................................................................................................................................9

8.7风险与机遇管理.........................................................................................................................................9

9项目及组织支持活动能力...............................................................................................................................10

9.1质量管理...................................................................................................................................................10

9.2配置管理...................................................................................................................................................10

9.3度量管理...................................................................................................................................................11

9.4文档管理...................................................................................................................................................11

10评价方式与方法.............................................................................................................................................11

10.1评价流程.................................................................................................................................................11

10.2评价方法.................................................................................................................................................12

10.3评价结果.................................................................................................................................................13

II

T/CESAXXXX—2021

软件服务能力模型与评估

1范围

本文件提出了软件服务提供方在从事软件服务过程中的实践活动要求。

本文件适用于：

——服务供方对自身软件能力进行构建、监视、测量和评价；

——外部评价机构对服务提供方的软件能力进行评价。

本文件所描述的软件服务过程中的实践，可结合软件组织的规模、应用领域、组织结构形式以及商

业目标等实际情况加以剪裁。

2规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，

仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本

文件。

GB/T28827.6-2019信息技术服务运行维护第6部分：应用系统服务要求

3术语和定义

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

3.1术语和定义

3.1.1

组织organization

一个行政管理结构，在此结构内部，其人员作为一个整体共同管理一个或多个项目或工作组，由共

同一位高层管理人员负责，并且在相同方针下运作。主要从事软件开发和/或服务的实体。可能是一个

独立实体，也可能是更大的实体的一个组成部分。

3.1.2

战略strategy

组织为实现长期目标所使用的方法和行动。

注：通常包括为了实现目标而实施的重点工作和任务、内外部资源配置方式、管理模式、技术路线等。

3.1.3

组织绩效organizationalperformance

组织为实现其战略目标而展现在不同层面上的有效输出。

1

T/CESAXXXX—2021

3.1.4

组织过程资产organizationalprocessassets

组织里被认为对定义和实施的过程有用的制品，它们提供项目和开发、剪裁、维护以及实施过程时

使用。

3.1.5

重构refactoring

在不改变系统功能前提下，开发人员不断地优化代码结构：清楚重复代码，改善程序的可读性，简

化程序的复杂度，让代码变得更灵活。

3.1.6

持续集成continuousintegration

每当完成一个新任务时，就进行集成和构建，每天要做多次集成构建。

4软件服务能力模型概述

软件服务能力模型旨在通过提升软件开发服务和持续服务能力，帮助客户和用户提升软件的业务价

值。本模型借鉴吸收了软件工程、项目管理、组织治理、质量管理、敏捷方法、精益软件开发等领域的

优秀实践，为软件组织提供改进和评价软件能力的一个模型。软件服务能力模型框架结构见下图1。

组织战略

能力改进支持能力开发与转化

投资收益

需求开发与管理组织标准过程集成

技术解决方案发布与部署

价值

验证与确认运行维护

软件开发

人员过程

工具方法

持续服务

软件工程项目管控支持活动

能力

图1软件服务能力模型框架结构

2

T/CESAXXXX—2021

软件服务能力模型框架主要包括组织服务能力建设与管理能力、软件工程管理能力、持续服务能力、

项目管控能力和项目及组织支持活动能力等五方面组成。

5组织服务能力建设与管理能力

5.1组织战略

组织基于使命、愿景和商业目标，设定软件开发服务和持续交付服务工作的战略、方向和期望，确

保软件服务能力和业务目标与公司战略保持一致，确保过程得到建立和维护。

a)组织应分析内外部因素，面向软件服务业务发展需求，通过对业务的预估与优化分析，达成对

自身