GB∕T 37970-2019 软件过程及制品可信度评估 GB∕T37970-2019 标准压缩包解压密码：www.bzxz.net

ICS35.080
中华人民共和国国家标准
GB/T37970—2019
软件过程及制品可信度评估
Trustworthiness assessment for software process and artifact2019-08-30发布
国家市场监督管理总局
中国国家标准化管理委员会
2020-03-01实施
1范围
规范性引用文件
3术语和定义、缩略语
3.1术语和定义
缩略语
4软件可信度模型
模型概述
软件过程可信原则
软件制品可信原则
软件过程可信证据
软件制品可信证据·
5软件可信度等级
软件过程可信度等级·
软件制品可信度等级
软件过程可信度评估
软件过程可信度评估过程
过程证据的可信度评估
可信原则的可信度评估…
软件过程的可信度评估·
软件制品可信度评估
软件制品可信度评估过程
制品证据的可信度评估
软件制品的可信度评估….
附录A（资料性附录）
附录B（规范性附录）
附录C（规范性附录）
附录D（资料性附录）
参考文献
可信原则与CMMI过程域
软件过程证据
软件制品证据
软件可信度评估示例
GB/T37970—2019
本标准按照GB/T1.1-2009给出的规则起草GB/T37970—2019
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由全国信息技术标准化技术委员会（SAC/TC28）提出并归口。本标准起草单位：中国科学院软件研究所、中国电子技术标准化研究院、南京大学、中国科学院科技战略咨询研究院、厦门理工学院、上海计算机软件技术开发中心、重庆邮电大学、北京拓尔思信息技术股份有限公司、罗普特（厦门)科技集团有限公司、北京知道未来信息技术有限公司。本标准主要起草人：王丹丹、王德鑫、刘增志、赖宜亮、韦庆杰、吴登生、胡芸、冯志超、贺劫、王林章、崔建峰、张旸旸、王青。
GB/T37970—2019
质量形成于过程。软件可信的基本问题是需要有证据证明软件产品能够满足用户的需求，而这些证据散布于软件开发的整个生存周期。所以，软件是否可信不能仅依赖于对最终产品的测试，对软件可信的评估和确认需要软件开发过程中各类相关证据的支持。本标准旨在从软件过程及制品的角度，建立系统化的可信度评估模型，指导软件开发在过程中采集合适的数据，以形成证据，支持证据驱动下的软件可信度评估。
软件可信并非一个新的质量特性，而是对软件的功能性、安全性、可维护性、可靠性等各种质量特性满足需求的程度的测量。受传统行业全面质量管理理论的启发，本标准提出面向过程的方法，通过关注和提高软件开发过程的质量，来提高软件的可信度。CMMI是被业界广泛采用的软件过程管理框架，目前运行的CMMIV1.3包括22个过程域，用软件开发过程的知识技术解决软件管理流程，强调改进软件过程能力，提高软件过程的成熟度，从而帮助企业有预期地、稳定地在预算内按时交付满足用户要求的产品。
本着兼容国际流行技术的准则，提出软件过程可信原则覆盖CMMIV1.3的22个过程域，另外扩充了对可信实体的保障，并通过制品可信原则对软件过程的制品进行了可信增强。形成的软件过程及制品可信证据体系，将软件质量分解到软件开发的各个阶段和过程，有目标地采集过程数据，形成覆盖软件开发全过程的证据链，并最终对交付的软件产品满足预期质量目标的可信度进行评估。IN
1范围
软件过程及制品可信度评估
本标准规定了软件过程和制品可信度评估使用的模型、可信等级和评估方法GB/T37970—2019
本标准适用于指导开发软件产品的组织建立可信的软件过程，并采集数据，积累证据以支持对软件产品质量的信心。同时也适用于第三方评估认证机构建立评估方法，对目标软件产品及其开发组织开展第三方评估。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T19001一2016质量管理体系要求第10部分：
GB/T25000.10一2016系统与软件工程系统与软件质量要求和评价（SQuaRE）：%系统与软件质量模型
GB/T25000.23—2019
系统与软件产品质量测量
术语和定义、缩略语
3.1术语和定义
系统和软件工程
系统与软件质量要求和评价（SQuaRE）第23部分：
GB/T25000.10—2016、GB/T25000.23—2019和GB/T19001—2016界定的以及下列术语和定义适用于本文件。
process
为给定目的所执行的步骤序列，例如，软件开发过程。［GB/T11457—2006.定义2.1183]3.1.2
softwareprocess
软件过程
由组织或项目使用的，用以计划、管理、执行、监控和改进其软件相关活动的过程或过程的集合［GB/T11457—2006，定义2.1512]3.1.3
软件开发全过程
wholeprocessof softwaredevelopment软件开发中的需求、设计、编码和测试过程。注：与GB/T11457一2006中定义的开发过程相比，为便于可信指标的分类，软件开发全过程专指需求、设计、编码和测试四个过程
制品artifact
由某一种软件开发过程所使用的或产生的一种信息的物理件。制品的实例有模型、源文件、文字和S
GB/T37970—2019
二进制可执行文件。制品可构成可部署构件的实现［GB/T11457—2006.定义2.76]］3.1.5
processtrustworthiness
过程可信度
软件过程能够生产满足期望产品的信心度3.1.6
artifacttrustworthiness
制品可信度
软件过程产生的制品能够满足期望产品质量的信心度。3.1.7
entity
通过测量其属性表述其特性的对象。例如，一个对象可能是过程、产品、项目或资源。[GB/T20917—2007.定义3.9]
trustworthinessprinciple
可信原则
由一组过程活动产生的证据来支持的，用于保障可信的通用要求3.1.9
可信过程域
trustworthyprocessarea
以可信保障目标为导向的一类可信原则3.1.10
evidence
针对软件开发活动中留下的数据（如文档、各种形式的记录、证言等），进行计算得到的，用于表明活动的表现是否满足要求的测量数据。3.1.11
processevidence
过程证据
表征过程是否满足期望的过程可信度的证据。注：该证据的数据类型分为布尔型、数值型、百分比型和等级型3.1.12
制品证据
artifactevidence
表征制品是否满足期望的制品可信度的证据。注：该证据的数据类型分为布尔型、数值型、百分比型和等级型3.1.13
software quality characteristic软件质量特性
支撑软件质量的软件质量属性的类别[GB/T25000.10—2016，定义3.23]3.1.14
environment
支撑软件开发的计算机、系统软件、开发工具、网络、基础架构、数据管理设施等软硬件条件或要求。3.1.15
依从性
compliance
产品或系统遵循相关标准、约定或法规以及类似规定的程度3.1.16
形式化formalization
描述系统性质的基于数学的技术。3.1.17
规约specification
为满足某种需求而提供的解决方案。注：可称为规格说明。
3.2缩略语
下列缩略语适用于本文件。
CMMI：能力成熟度集成模型（CapabilityMaturityModelIntegration）PA：过程域(ProcessArea)
软件可信度模型
4.1模型概述
可信的基本要素包括可信的实体、可信的行为和可信的结果三个维度。GB/T37970—2019
可信保障目标为：实体可信、行为可信和结果可信。实体可信分解为开发活动中涉及的人、交互通道、环境以及使用的方法和工具；行为可信分解为开发过程中的行为管理、制品管理和文档支持；结果可信分解为对过程产品的验证和确认，其中“验证”关注合适的过程制品检验方法，“确认”关注过程制品的质量满足需求的程度。
以可信保障目标为导向确定了七类可信原则，即7个可信过程域。其中实体安全、开发支持、文档化、可管理、可追溯、可验证关注过程的可信，定义为过程可信过程域，其对应的可信原则定义为软件过程可信原则，共包含36个软件过程可信原则；制品可信关注过程制品的可信，定义为制品可信过程域，其对应的可信原则定义为软件制品可信原则，共包含1个可信原则。可信原则与CMMI过程域的对比参见附录A
每类可信过程域包含若干可信原则，每个可信原则由面向不同开发阶段或软件开发全过程的一组活动来保障，活动产生的数据形成证据来支持可信原则实现程度的评估。软件可信度模型见图1。
可信保障标
过程实
可信原则
过让程证期
（实体可伴
人/通道/环塔方法/工具
实体安全
[ 谷珠
安全评路
2级证培
开发支斯
环境支性
工具支持
3筑证据
（行为可信
行为管理制品苷理
可誉理
1详理制度www.bzxz.net
2．风班学所
可追潮
1．而状可追除
2段计奇消踪
过程可信
4氮证垢
泛证塔
软件可信度模型
文档支持
文档化
而求文档化
计文智花
[级证据
2级匠据
（结果可信）
可验证
1.形或化磁计
需状评计
3级证据
制品可信
1。战可信
制品可信
4您证据
5级亚接
GB/T37970—2019
可信原则对应的证据结构见表1。其中证据等级表示该证据从该级开始要求，其满足程度可不断提高，最高等级大于或等于证据等级。注：一级可信等级表示有关的活动已执行，但过程处于无定义和管理的状态下，对活动的可信没有要求，因此本模型没有一级过程证据。
表1可信原则的证据结构
证据类型
二级证据
三级证据
四级证据
五级证据
软件过程可信原则
证据2.1、证据2.2..
证据.1、证据.2..
证据4.1.证据4.2*
证据5.1、证据5.2
软件过程可信原则共有36个，按照可信过程域类别和软件开发阶段两个维度的分类组织见表2。横向维度表示软件过程可信原则涉及的软件开发阶段，包括需求，设计、编码、测试等必要的典型阶段，适合包括瀑布模型、敏捷开发在内的所有开发形式。各阶段的具体内容如下：a）环境：指支撑软件开发的计算机、系统软件、开发工具、网络、基础架构、数据管理设施等软硬件条件或要求，共8个可信原则：
需求：软件开发的需求阶段，包括5个可信原则；b)
设计：软件开发的设计阶段，包括5个可信原则；d）
编码：软件开发的编码阶段，包括5个可信原则；e)
过程域
测试：软件开发的测试阶段，包括4个可信原则；软件开发全过程：软件开发的需求、设计、编码和测试阶段，这部分的可信原则贯彻软件开发全过程，共9个可信原则。
表2软件过程相关的可信原则分类组织视图阶段
开发环境工具
重用支持
开源支持
采购支持
需求分析工具
设计工具
源代码
分析工具
测试工具
软件开发全过程
安全政策
安全管理策略
安全环境
信息安全工具支持
过程域
可管理
文档化
可验证
可追溯
知识共享
管理制度化
环境完整性
形式化验证
需求分析文档化
形式化需求验证
需求分析评审
可追踪性
实体安全过程域的可信原则
表2（续）
设计文档化
形式化设计
设计评审
可追踪性
实体安全过程域共有4个可信原则，包括：a)
源码文档化
形式化代码
源代码评审
源代码
可追踪性
测试文档化
测试评审
可追踪性
GB/T37970—2019
软件开发全过程
风险管理
测量与分析
配置管理
过程审计
安全政策：所有的软件开发者执行开发活动应遵守明确定义的安全政策：安全管理策略：生存周期活动的执行需要由至少两个有资格的开发人员的认同和参与；安全环境：应明确安全机制，保证全生存周期活动不会受到未授权方法影响；8
信息安全工具支持：根据清晰定义的安全策略，所有确定的软件生存周期活动应被软件工程环d
境自动控制。
4.2.3开发支持过程域的可信原则开发支持过程域共有8个可信原则，包括：a）
开发环境工具：软件工程环境和所有的软件工具应根据一个明确的选择策略来进行选择，选择策略中应考虑可信等级、成熟度、文档和源码的可获取性等因素；重用支持：是否要构建可重用的组件以及可重用的程度；b）
开源支持：开源软件应接受选择，清晰的选择政策应考虑可信等级、成熟度、文档、可获取的源c
码和软件许可协议；
采购支持：应与供应商建立采购合同以及评价采购产品质量的等级；d)
需求分析工具：应使用需求分析工具以支持需求规约、一致性检查和文档生成；设计工具：在设计中应采用设计工具以维护设计/需求的跟踪映射关系并生成设计文档：源代码分析工具：应使用测量复杂度和风格的源代码分析工具和步骤来分析所有开发的代码；测试工具：软件工程环境应包含一个创造、执行、文档化和分析测试完整的测试工具集。5
GB/T37970—2019
4.2.4可管理过程域的可信原则
可管理过程域共有8个可信原则，包括：a）知识共享：每个软件开发活动的组件，包括需求、源码、设计、测试、软件工具、方法和支撑活动等都应与至少两个人员相关，这些人员非常熟悉这些组件的细节、隐含的意义和所考虑的选择方案；
管理制度化：根据管理文档，应由有资格的人员对软件工程环境、软件工具和开发的软件进行b）
维护；
环境完整性：对于识别软件工程环境组件的变更应有一个明确的步骤，如果有需要，恢复环境c）
的完整性；
d）风险管理：与软件开发活动相关的风险都应被明确地识别，风险移除策略应被文档化：e）计划：对于所有软件开发活动的详细计划应在软件开发计划书中描述，软件开发的管理也应遵循计划书中所描述的方法；
测量与分析：应对软件过程和制品进行合适的测量和分析，以准确地理解过程和制品的状态，f）
及时了解过程的偏差，采取合理的纠正措施；g）配置管理：应建立一个配置管理系统，包括关于配置项识别、审核、控制和审计的明确机制和步骤。所有的配置项应保存在存放处以维护软件版本、软件修改请求和变更；h）过程审计：在全生存周期中负责软件开发过程的总体和阶段计划、任务分配、沟通、协调、跟踪、控制，保证任务质量和进度，并根据任务执行情况追溯到每一个开发环节。4.2.5文档化过程域的可信原则
文档化过程域共有4个可信原则，包括：a）需求分析文档化：除了软件需求规约和接口规约，所有帮助理解需求分析过程、重要的需求分析决策的原理等有用信息都应被文档化：b）设计文档化：除了软件设计说明书和接口设计说明书外，设计活动的特性、考虑到的重要的设计选择项和重要的设计理由都应被文档化；c）源代码文档化：源码和软件编码活动的特征应被文档化：d）测试文档化：除了软件测试计划书、软件测试描述书和软件测试报告以外，软件组件和配置项测试活动的特征也应被文档化
4.2.6可验证过程域的可信原则
可验证过程域共有8个可信原则，包括：a）形式化验证要求：按照形式化验证要求，所有的形式化规约和验证活动都应遵循一个合适的方法，包括使用形式化规药和验证工具、文档和同行评审等：b）形式化需求验证：除广非形式化的需求规约以外，需求文档应用一个形式化的框架来规药：c）需求分析评审：应由一个同行评审组对需求分析进行同行评审以保证软件需求分析的完整性-致性和正确性；
d）形式化设计验证：应对形式化的设计规约进行形式化设计验证以确保满足其需求；设计评审：应由一个同行评审组对设计进行同行评审以保证软件设计的完整性、一致性和正e)
确性；
f）形式化代码验证：形式化验证代码是否满足形式化规约，所有的形式化规约和验证活动都应遵6
GB/T37970—2019
循一个包含了使用形式化规约和验证工具、文档、同行评审和可跟踪映射的方法；源代码评审：应由一个同行评审组对源码进行同行评审以保证软件源码和计算机软件单元测g）
试的完整性、一致性和正确性；测试评审：应由一个同行评审组对测试进行同行评审以保证软件测试的完整性、一致性和正h)
确性。
可追溯过程域的可信原则
可追溯域共有4个可信原则，包括：需求可跟踪性：对于明确的系统需求或客户来源，所有的软件需求应保持可跟踪性；a）
设计可跟踪性：设计的各方面和需求应是互相可跟踪的；c)
源代码可跟踪性：所有的源码对于设计和计算机软件单元测试应是可跟踪的，设计对于源码也应如此；
d）测试可跟踪性：所用软件组件和配置项的测试对于需求应是可跟踪的，源码和需求对于组件和配置项的测试也应如此
4.3软件制品可信原则
软件制品可信原则只有一项。按照软件质量特性和软件生存周期阶段两个维度，软件制品可信原则对应证据的分类组织视图见表3。横向维度表示制品可信原则涉及的软件全生存周期，包括设计、编码、测试、交付、维护和软件开发全过程。纵向维度表示GB/T25000.102016定义的8个软件质量特性：功能性、性能效率、兼容性、易用性、可靠性、信息安全性、维护性和可移植性表3软件制品可信原则对应证据的分类组织视图可信
过程域
质量特性
功能性
性能效率
兼容性
易用性
可靠性
信息安全性
维护性
可移植性
软件过程可信证据
4.4.1概述
软件开发全过程
由于不同软件系统的可信要求不同，并不要求所有证据都要采集和测量，不同级别的证据支持不同级别的可信要求。例如，当软件的可信要求为三级时，只需要评估各个原则三级及三级以下的证据。软件可信度模型一共定义了133个过程证据，按照开发阶段和可信过程域所对应的两种等级分布，分别见7
GB/T 37970—2019
表4和表5。具体证据见附录B。
按照软件开发阶段表示过程证据的等级分布表4
开发阶段
软件开发全过程
可信过程域
实体安全
开发支持
可管理
文档化
可验证
可追溯
证据数总计
可信原则
可信原则
证据等级
按照可信过程域表示过程证据的等级分布证据等级
以下将从6个可信过程域的角度，提出软件过程可信原则的证据要求，4.4.2
实体安全过程域的可信证据
实体安全过程域共有4个可信原则涉及软件开发全过程，共包含14个可信证据4.4.2.2
软件开发全过程
软件开发全过程可信原则下的可信证据如下：a)
安全政策：安全政策的建立、安全相关政策的了解、培训的开展；证据数总计
安全管理策略：背景调查、人员对可信知识了解程度、信息安全管理的程度、项目遵循安全要求b）
的程度、安全管理相关培训的开展、共享监控机制：c
安全环境：安全工作环境标准的建立、软件过程和资产访问权限和环境的建立、网络服务安全性；
信息安全工具支持：自动化工具对权限控制的支持程度、组织结构对权限支持。d)
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。