注：每一利益相关方（如开发方、需方、独立评价方等）的产品质量评价要求由其角色视角决定。 产品质量评价过程的输出包括：评价报告、对评价过程改进的结果和收益。 在图2中的评价资源包括GB/T25000系列标准（如GB/T25000.10、ISO/IEC25020、ISO/IEC25022、 ISO/IEC25023,GB/T25000.24、ISO/IEC25030,GB/T25000.40等）。 产品质量评价过程的约束可包括： a 特定用户的评价要求； 评价项目的进度表； 评价项目预算； d) 评价项目的环境； e 评价项目的工具和方法； f) 对评价报告的具体需求。 产品质量评价过程的资源可包括： a 适用的测量工具和方法； b） 适用的GB/T25000系列标准或SQuaRE系列国际标准； c 用于质量评价的人力资源； d) 用于质量评价的财力资源； e） 用于评价的信息系统； f 用于质量评价的知识库 软件产品质量评价参考模型适用于负责产品质量评价的人员，旨在适合但不限于开发方、需方和独 立评价方这样角色的组织。 产品质量评价可在开发或获取过程期间或之后进行

5.2软件产品质量评价目标实体

产品质量评价的目的因开发方、需方和独立评价方角色不同而不同。评价的目标实体界定取决于 平价目的。评价的目标实体分为静态产品和动态产品，见表1。 静态产品（中间产品或可交付产品）可包括： 质量需求规格说明； 软件设计说明； 程序源代码； 测试计划说明； 测试报告结果说明； 产品说明； 操作手册。 动态产品可包括： 在测试环境中进行动态测试的、可执行的中间产品； 一在运行环境中执行的可交付产品。 开发方在软件生存周期的每一开发阶段（如设计阶段、实现阶段和测试阶段）评审静态产品，以评价 中间产品质量是否达到了预期目的；开发方在单元测试阶段测试中间动态产品，在系统集成测试阶段测 式可交付动态产品 注1：对开发方来说，评价的目标实体是静态和动态的中间产品和/或可交付产品 为了确保产品的获取达到预期目的，需方在设计阶段和测试阶段评审静态产品。在验收或运行测 式阶段，需方测试动态产品。需方同时评价静态和动态产品GB／标准规范范本，以比较多个候选产品的质量并选择基于其 角色的更高质量的产品

GB/T25000.412018

注2：对需方来说，评价的目标实体是静态的和动态的中间产品和/或可交付产品。 独立评价方可评审静态产品和测试动态产品，以便评价产品质量，并基于其与产品质量评价请求方 所签订的合同出具评价报告。 注3：对独立评价方来说，评价的目标实体是基于其与请求方所签合同的静态和动态中间产品和/或可交付产品。

表1各角色的且标实体示例

根据各自的评价目的，开发方、需方和独立评价方可从静态和动态两种产品质量评价的视角执行各 种评价活动。

5.3.1开发方角色与职责

开发方在产品质量评价中的职责可包括： 保证开发的可交付产品的质量； 验收分包商提交的符合所需质量的定制软件产品； 从供方选择符合所需质量的商业现货软件产品； 提高测试过程的效率； 培训产品质量评价人员。 在定制软件产品实现时，开发方评价中间产品和可交付产品，以确保所开发软件产品的质量，包括 开发初期阶段的质量需求文档； 中间产品，如实现过程中的设计文档和程序源代码； 在测试期间，目标系统中包括的可交付软件产品。 当购买商业现货软件产品来适应可交付系统时，开发方评价并比较候选产品，以选择满足所需质量 产品。 开发方可利用产品质量评价结果来确保产品达到所需的质量标准，这些质量标准可由需方设定，或 是通过与其他产品比较来确定

5.3.2需方角色与职责

承担产品质量评价的需方的职责包括： 验收符合质量需求的定制软件产品； 选择具备可验收质量的商业现货软件产品； 提高运行的目标业务系统中动态产品的有效性； 提高获取过程的效率； 培训产品质量评价人员。 当获取定制软件产品时，需方评价中间产品或可交付产品，以确保所获取产品的质量。 当获取定制软件产品时，需方制定使用质量需求及产品质量需求，规定对供方的要求，并在获取前 安这些需求评价潜在的供方

当获取定制软件产品时，制定质量需求的目的是确保产品符合用户明确和隐含的需求，可能的活动 包： 在要求软件开发前，评审设计文档； 一在验收定制软件产品前，评审并测试可交付产品。 当获取商业现货软件产品时，需方评价候选的可交付产品，以便比较并选择产品， 当获取商业现货软件产品时，评价可用来比较候选产品，并确保所选产品满足质量需求，可能的活 动包括： 在选择意向产品前，评审可交付产品的文档； 为选择最符合质量需求的产品，对可交付产品进行测试。 在验收测试阶段，为了获取高质量的产品，需方进行产品测试 当改进目标系统所包含的运行产品时，为提高产品质量，需方评价动态产品，可能的活动包括： 在运行阶段评审静态可交付产品的质量； 在运行阶段测试动态可交付产品的质量 当评价目标系统所包含的运行产品时，对该产品进行测试并采用使用质量测度来测量 注1：操作人员可以是需方人员。运营产品目标系统的个人或组织，可以实施软件产品质量评价，以验证该产品在 各种操作条件下都符合质量需求，并指定对维护人员的变更要求 注2：维护人员可以是需方人员。维护产品目标系统的个人或组织，可以实施软件产品质量评价，以验证该产品质 量是否仍符合质量需求，特别是对可维护性和可移植性的需求

5.3.3独立评价方角色和职责

独立评价方的职责由其与请求方签订的合同界定，评价过程可以从开发方或需方的视角来执行。 独立评价方产品质量评价的职责可包括： 基于其与请求方所签的合同来评价目标产品； 保证产品质量评价报告的质量； 提高评价结果的质量； 提高评价过程的效率； 改进支持产品质量评价过程的信息系统； 培训产品质量评价人员。 在实施评价、提供适宜的评价方案和环境前，独立评价方根据合同评审评价的范围。 在评价目标产品时，为确保产品质量，独立评价方对中间产品或可交付产品进行评价。 独立评价方的评价可在开发方、需方或其他组织提出申请后执行

6软件产品质量评价组织级要求和建议

软件产品质量评价参考模型描述了为达到评价目标而执行的评价过程并细化了评价活动和任务， 提供了活动和任务的目的以及补充信息，可用于指导产品质量评价（见GB/T25000.40）。该模型适合 但不仅限于作为产品开发方、需方和独立评价方的各种组织角色。 根据软件产品质量评价参考模型，评价宜基于产品质量需求说明，在评价前遵从ISO/IEC25030， 明确评价的目标和标准。产品质量需求反映了用户对预期产品的要求，并在开发之前予以界定（见 SO/IEC25030)。 GB/T25000.2适用于评价组，在软件开发、软件获取期间为所有产品质量评价项目提供组织范围 的支持，并由独立评价方予以实施。GB/T25000.2通过提供技术、工具、经验和管理技能，为负责实现

GB/T25000.412018

和管理软件产品质量需求说明及质量评价活动的组织提供要求和建议， 在开发和获取软件产品的过程中及之后，可由开发方、需方或独立评价方实施软件产品质量评价。 当产品被分解为主要组件时，对不同组件的需求可能有别于对整体产品的质量需求，因而需要不同的评 价准则。 软件产品质量评价可在软件实现过程的整个生存周期内定义的质量模型中进行，实现过程定义见 ISO/IEC12207:2008和ISO/IEC15288:2008

.2软件产品质量评价文档编制

对于产品质量评价，评价文档应详述评价活动的输人文档、约束、资源和结果相关的信息。为了保 平价结果，评价文档应详述评价过程和评价活动的实际结果 评价记录应包括对所执行活动的详细描述，并应包含在实施产品质量评价计划时管理产品质量评 斤需的充分信息。评价记录应包括用于阐明评价结果的任何中间数据。在评价计划所指定的评价记 中，也应包括评价过程中所作的决策。为有效保障产品质量评价的后续活动，评价记录应包含每项活 的充分信息， 产品质量评价报告应记录评价活动和评价结果。当使用某工具执行评价活动时，评价报告中应包 核工具的标识、供方和工具版本等参考信息。 评价记录中应包括所用工具更详细的参考信息，应包括工具的详细配置，以及能够重复评价活动获 目同中间结果所需的任何相关信息 注1：从开发方（不仅包括设计师，还包括程序员和测试人员）的视角，要记录的信息包括评价期间所用的： 设计说明（静态中间产品或可交付的产品）的评审结果 测试（程序单元测试、系统集成测试、产品发布前的运行测试）结果； 用作产品质量指标的任何预测模型说明； 所有分包开发方或测试方的组织以及这些组织生产的产品或任何制品的标识。 注2：从需方的视角，要记录的信息包括评价期间所用的： 设计说明（静态中间产品或可交付的产品）的评审结果 测试（运行阶段的系统测试、产品选型前的系统演示测试）结果； 用作产品质量指标的任何预测模型说明； 所有分包开发方或测试方组织以及这些组织生产的产品或任何制品的标识。 注3：从独立评价方的视角，要记录的信息包括评价期间所用的 设计说明（静态中间产品或可交付的产品）的评审结果； 测试（程序单元测试、系统集成测试、产品发布前的运行测试、运行阶段的系统测试、产品选型前的系统演 示测试）结果； 用作产品质量指标的任何预测模型说明

6.3不同角色组织级要求和建议

6.3. 1 一般要求

为确保评价结果的可重复性、可再现性、公正性及客观性，在组织内管理和支持评价项目的独立质 量评价组应在组织范围内为其活动提供足够的质量保证。 任何产品质量评价组所在的组织均应确定关联的软件产品质量评价责任，并将其纳入组织策略，且 宜履行下列职责： 采取组织方法支持具体的开发项目并提高评价过程的有效性； 构建全面质量管理体系和支持信息系统，以便从全面优化的角度来控制和支持具体的评价 项目； 建立评价过程的资源和基础设施：

从图2所示的产品质量评价参考模型的视角定义评价约束； 为创建评价计划和报告提供行业公用模板，以控制和支持具体的评价项目； 确定管理具体评价项目的共同策略、规则和条例； 构建和维护组织内项目使用的支持系统、标准和指南，包括管理和执行评价的工具和方法。 组织的作用包括：激励独立质量评价组成员、培训他们进行需求规格说明活动和评价活动、编制相 应的文档、确定或开发所需的方法及回答相关技术咨询。 技术管理与软件质量需求规格说明及评价过程、测度及工具的规划和管理有关，这包括组织内对需 求规格说明和评价技术经验的开发、获取、标准化、控制、转移和反馈的管理

6.3.2开发方组织级建议

开发方宜为组织内具体的开发项目组建独立的质量评价组，以实现其作用。独立质量评价组宜执 行组织方法，支持具体的评价项目，以确保设计和中间产品的质量，保证交付产品的质量，并提高开发和 平价过程的有效性， 测量集可能会导致生产软件系统的组织结构的改变。质量保证/控制组织或整个开发团队可能需 要针对测量应用和数据采集程序进行培训。 当测量的实施引起了开发过程的变更时，开发团队可能需要接受关于这些变更的培训。为实施测 量，可能需要确定、评价、获取、调适或开发硬件/软件工具

6.3.3需方组织级要求和建议

需方宜为组织内具体的获取项目组建独立的质量评价组，以实现其作用。组建独立评价组的需方 只应履行下列职责： 提供验收交付产品的标准化公用评价方法； 提供管理产品供方的标准化公用评价方法； 评价动态运行产品的有效性和质量； 采取组织方法支持具体的评价项目，以确保验收产品的质量并提高获取过程的有效性； 从产品质量的视角，提供商业现货软件产品清单或数据库及选择最适合产品的标准化公用比 较方法。 基于软件产品质量和使用质量的视角，目标控制项包括： 拟纳入实际运行系统的动态运行产品的质量； 实际使用产品的有效性或生产率； 验收产品的质量； 供方的技术水平； 软件产品开发的成熟度； 软件产品维护的成熟度； 为获取产品进行质量评价的人力资源

6.3.4独立评价方组织级要求

独立评价方组织宜履行下列职责： 为具体的评价项目组建独立评价组，以实现其作用； 采取组织方法支持具体的评价项目，以确保提交结果的质量并提高评价过程的有效性； 基于评价请求方的要求，为支持具体的评价项目建立组织的基础设施和资源； 根据合同和以往类似具体评价项目的经验，从开发方、需方或独立评价方的视角提供基础 设施。

GB/T25000.412018

注1：为了从有经验和知识的专家视角提供有效、可靠的评价，独立评价组促进对执行产品质量评价的最佳方法和 工具的调适 注2：最典型的独立评价者是来自需方和开发方机构以外的专家，他们基于任何用户（如需方和开发方）的申请，客 观地评价产品，并维护用于软件产品质量评价的公共信息数据库，以便使用不同利益相关方的信息，

7开发方评价过程要求和建议

7开发方评价过程要求和建议

本章定义了对开发方在开发生存周期中，实际实施产品质量评价的要求和建议。 本章的要求和建议适用于正计划开发新产品或升级现有产品，并打算用自已的技术团队执行产品 质量评价的组织。其侧重采用通过测量在生存周期中开发的中间产品能预测可交付产品质量的指标， 本章的要求和建议在应用于开发过程时，评价方应考虑下列具体问题： 产品质量评价直接支持符合用户和客户需求的软件开发 当开发方正策划和开展软件产品质量测量和评价时，开发方的过程宜予以考虑。 注1：有关生存周期过程的描述参见ISO/1EC12207：2008，包括的活动描述参见6.4和7.1。 注2：软件产品质量评价过程概述参见GB/T25000.40。 开发方应有软件支持过程和活动来配合评价活动 注3：软件支持过程的描述参见ISO/IEC12207：2008，特别包括质量保证过程（7.2.3）、软件验证过程（7.2.4）、软件 确认过程（7.2.5）和软件审核过程（7.2.7）。 许多数据分析方法需要来自相似开发条件并具有可比质量需求的以前项目的数据。 因此，开发方宜利用其组织以前项目使用过的类似开发模型，且不排除补充的需求，以达到开发方 的的。

本活动的输人宜包括： a）产品质量评价需求； b）产品质量需求规格说明； 适用的测量工具和方法； d）待评价的产品，包括中间产品和可交付产品。 本活动的输出宜包括： a）产品质量评价目的说明； b）产品质量评价需求说明； 高层次的产品质量评价计划， 所有待评价的产品部件均应予以标识并记入文档。 从开发方的视角，产品信息还包括静态产品，例如： 产品规格说明； 程序源代码； 操作手册； 产品说明。

本活动的输人宜包括： a）产品质量评价需求； b）产品质量需求规格说明； 适用的测量工具和方法； d）待评价的产品，包括中间产品和可交付产品， 本活动的输出宜包括： a）产品质量评价目的说明； b）产品质量评价需求说明； 高层次的产品质量评价计划， 所有待评价的产品部件均应予以标识并记入文档 从开发方的视角，产品信息还包括静态产品，例如 产品规格说明； 程序源代码； 操作手册； 产品说明

7.2.2明确评价目的

产品质量评价的目的应基于开发方角色编入文档，并作为下一步评价活动和任务

价的目的应基于并发方角色编入文档，并作为下一步评价活动和任务的基础。并发方

GB/T25000.41—2018

同时评价静态和动态中间产品以及可交付产品，以实现其作用 静态和动态中间产品质量评价的目的可包括： 保证中间产品设计的质量； 提高中间产品的质量； 保证中间产品的质量； 预测或估计可交付产品的质量： 确定测试期间中间产品故障原因； 确定是否从分包商验收中间产品； 确定产品生存周期阶段是否结束，以及产品何时进人下一阶段； 收集中间产品信息，以控制和管理开发过程； 评估开发项目的持续可行性； 提高设计、实现和测试过程的效率； 为产品质量评价项目培训人员。 静态和动态可交付产品质量评价的目的可包括： 确保可交付产品的质量； 确定产品发布的时间； 评估产品使用的正面和负面影响； 为选用系统产品而从备选产品中选择产品； 为选用系统产品而比较相互竞争的产品

在软件产品质量评价之前，评价方应标识产品开发的利益相关方，宜根据质量特性和子特性（见 GB/T25000.10）定义质量需求，且产品质量需求规格说明应提供 评价设计文档时，产品质量需求宜采用外部质量测度和/或使用质量测度来定义； 一评价中间产品时，产品质量需求宜采用内部质量测度来定义； 一评价可交付产品时，产品质量需求宜采用外部质量测度和/或使用质量测度来定义， 评价方宜根据目标实体的每个质量特性和子特性审查产品的质量需求， 评价方应定义产品质量评价覆盖具体软件产品质量需求的程度，同时结合产品质量需求，以确定产 品质量评价需求。这一决策宜基于评价预算、评价目标日期、评价目的和产品使用临界等约束。在评价 的初始阶段，评价方宜研究和确定质量需求，以便策划和实施评价 开发方宜通过各个相关的质量特性和/或子特性，同时建立产品质量需求和使用质量需求。开发方 宜评价质量需求规格说明的完备性和正确性，以确保产品质量评价规定了所有必要的需求和排除了不 必要的需求。在产品交付前，开发方需针对这些需求对产品进行评价。 为使软件产品质量满足明确和隐含的需求，全力查明并指定所有相关质量特性的充分详细的隐含 需求是必要的。质量需求规格说明宜由需方进行评估，而由最终用户评估指定的隐含要求。 用户对原型产品的体验往往导致对使用质量需求更为准确地陈述。通过在开发过程中对中间产品 规定软件产品质量的内部测度要求，开发期间软件产品质量评价宜用于预测和验证产品质量。 对特定目标用户的可交付产品的软件产品质量的测度值，可随后对照初始需求进行评价，目的是在 开发过程的尽早阶段发现预期产品存在的质量问题。 开发方宜确定软件产品质量内部测度的需求。当使用软件产品质量的内部测度需求时，开发方对 比宜使用与软件产品质量的外部测度需求相关的质量模型来标识，并使用软件产品质量的内部测度需 求来验证开发过程中中间产品的质量。为了开发的目的，定义软件产品质量的内部测度需求可使中间 产品的质量得到验证

GB/T25000.412018

7.2.4标识待评价产品部件

开发方应基于产品质量评价的目的标识和记录待评价的目标产品部件， 在保证可交付产品质量时，评价的目标实体宜是下列静态和动态的可交付产品： 产品规格说明： 程序源代码； 操作手册； 可交付产品描述； 测试结果（系统集成测试、产品发布前的运行测试）； 用于测试的可执行程序。 在提高产品质量和开发过程效率时，评价的目标实体宜是下列静态和动态的中间产品： 设计文档； 产品规格说明； 程序源代码； 测试（单元测试、系统集成测试）文档； 用王测试的可执行程序

7.2.5定义评价严格度

开发方应基于产品质量需求规格说明定义每个目标产品组件的评价严格度。 在设计评审阶段评价需求规格说明时，应从外部视角定义每个产品的质量特性和使用质量特性的 平价严格度；在实现阶段评价中间产品时，应从内部视角定义每个产品质量特性的评价严格度；在单元 则试阶段评价可交付产品质量时，应从内部视角定义每个产品质量特性的评价严格度；在原型开发或系 统集成测试阶段评价可交付产品时，应从外部视角来定义每个产品质量特性和使用质量特性的评价严 各度。 评价严格度宜与建立预期评价级别的特性和子特性集合相关联，该评价级别确定了应用的评价技 术和可达到的评价结果

7.3. 1 输入和输出

本活动的输人宜包括： a）产品质量评价需求规格说明； b）产品质量需求规格说明； c）高层次的产品质量评价计划 本活动的输出宜包括： a）选定的质量测度说明； 6 产品质量测度判定准则说明； c）产品质量评价判定准则说明：

已修订的、高层次的产品质量评价计划 从开发方的视角，产品信息还包括静态产品，例如： 产品规格说明； 包括静态和动态中间产品和可交付产品的目标实体清单

7.3.2选择质量测度（评价模块）

评价方应选择覆盖所有软件产品质量评价需求的质量测度，应基于产品质量评价的目的确定每个 待评价目标产品部件的产品质量测度。 在设计评审阶段评价需求规格说明时，质量测度应从外部质量测度集和使用质量测度集中选择。 在实现阶段评价中间产品时，质量测度应从内部质量测度集中选择。 在单元测试阶段评价中间可交付产品时，质量测度应从内部质量测度集中选择。 在系统集成测试阶段评价可交付产品时，质量测度应从外部质量测度集和使用质量测度集中选择， 产品质量评价需求宜分配到每个产品组件，这些组件可赋予用于评价产品质量的适当质量测度 产品质量评价方法应记人文档，并考虑为达到评价结果而进行的活动， 当指定的评价方法基于使用软件工具时，应在评价计划中标识该工具。工具标识至少应包括工具 的名称、版本标识及其来源（如供方、开发方）。评价方法的描述应包括应用该方法的产品组件的标识。 在规定评价时，为了解释结果需要对测度进行专家分析，并应规定解释程序。为了对目标产品属性 的测量值和标准值进行可靠地比较，需要进行严格地测量， 测量规程宜能以其声称的足够精度来测量软件产品的质量特性（或子特性），以便允许设定标准并 进行比较。当比较不同属性的产品时，来自检查表和专家意见的数据可能不可靠。对测量工具或人为 差错造成的可能测量误差，宜规定允许的误差范围。 评价说明应包括： 关于产品描述中所标识产品组件的评价范围； 实施评价所需的信息和目标产品组件以及列入产品说明的其他相关文档之间的交叉引用； 一 待实施测量和验证的规格说明，以及对自标产品组件的引用说明； 测量和验证的规格说明与评价需求之间的映射，以及引用标准或所列每个测量或验证的理由 因为有些测度只能随着软件产品设计的演变才能被选择，这项任务通常主要在评价中间产品的质 量时送代执行。软件属性的内部测度可以用作中间产品的质量指标。特别地，软件属性的内部测度经 常用作可交付产品的质量指标；但是，内部质量测度值和外部质量测度值之间并没有经验证的一般或直 接关系。然而普遍认为，质量指标谨慎使用时可提供有用的指导。使用质量指标让软件开发方能在开 发早期发现可能的质量问题，并立即采取修正措施 目标系统和软件产品的应用领域、所用开发方法和工具、项目组织和企业文化都存在差异，因此，不 存在适用于一切软件开发工作的通用已知质量指标集，某些质量指标在一个组织中有用，而在其他组织 中则不然。 对于软件产品质量外部测度的每一需求，在开发期间均为其选用一个或多个软件属性来表示。通 过内部测度赋予目标软件属性的值，用来控制其在开发期间的质量。 评价方应定义软件属性的内部测度集，使其： 覆盖相关的每个中间产品和活动； 适合应用领域和开发采用的方法； 覆盖已识别的产品和开发风险。开发风险的例子包括：不确定的需求规格说明、尚未解决的已 发现问题、进度滞后等。 内部测度集宜包括适当的内部测度，作为预测中间产品质量的趋势测度。当定期采用适当的内部 测度时，某些测度对标识软件开发过程中产品质量的趋势有用。此类趋势测度的示例有：每周或其他单

GB/T25000.412018

应时间“测试已完成的模块数”“已解决的问题数”“已变更的需求数”。 评价方应定义与软件属性的外部测度相关或与质量需求对应的软件属性内部测度集，这些属性的 为部测量值被用作产品质量特性或子特性的指标。宜为下列两种目的分析有关的中间产品和收集内部 测量数据： 评价中间产品的质量，以确定其是否满足质量需求； 预测可交付产品的质量。 ISO/IEC2502n可用来指导选择质量测度。 评价方应描述所定义质量指标的预测模型，即这些指标和软件属性外部测度之间的关系。指标与 其要测量的属性并不需要严格地一一对应，然而指标和相关属性之间的关系宜明确界定。为了有效地 管理使用，指标数量宜保持在低水平，并宣优先考虑现有过程（如配置管理或系统集成测试）中已收集数 据所支持的指标。 评价方应规定执行测量的条件，这意味着确认其值影响测量的其他属性，并定义这些属性的值。根 据定义，软件属性的内部测度值可独立于其他属性获得

7.3.3确定产品质量测度判定准则

自标产品选定的每个质量子特性或特性的判定级别，均应利用定义的映射由每个选定测度的测量值来 确定。 在通过设计评审评价需求规格说明时，应为每个产品质量特性和使用质量特性定义质量测度判定 准则；在实现阶段评价中间产品时，应为产品质量特性定义质量测度判定准则；在单元测试阶段评价中 间可执行产品时，应为产品质量特性定义质量测度判定准则；在系统集成测试阶段评价可交付产品时

7.3.4确定产品质量评价判定准则

通过汇总评定（质量测度）结果评价目标产品的判定准则应根据目标产品的质量需求来确定。评价 方宜制定进一步汇总的程序，不同质量特性各有其准则，每个准则都可以是根据单个子特性和质量测度 成质量子特性和质量测度的加权组合。汇总结果宜用作产品质量评价的基础。 在通过设计评审评价需求规格说明时，应为每个产品质量特性和使用质量特性定义质量评价判定 则；在实现阶段评价中间产品时，应为产品质量特性定义质量评价判定准则；在单元测试阶段评价中 产品质量时，应为每个产品质量特性和子特性定义质量评价判定准则；在系统集成测试阶段评价可交 寸产品时，应为每个产品质量 评价翔正准则

7.4. 1输入和输出

本活动的输人宜包括： a）产品质量评价需求规格说明； b）产品质量需求规格说明； 选定的质量测度（评价模块）规格说明： d）产品质量测度判定准则说明； 产品质量评价判定准则说明； 已修订的、高层次的产品质量评价计划 本活动的输出宜包括：

a）详细的产品质量评价计划； b）产品质量评价方法， 应标识和记录评价中要包括的所有产品部件， 从开发方的视角看，有关产品的信息还包括静态产品，例如： 产品规格说明； 程序源代码； 操作手册； 产品说明

7.4.2策划评价活动

确定的产品质量评价活动应考虑人员、软件工具和计算机等资源的可用性来安排进度。评价方宜 基于评价目的和评价的目标实体制定产品质量评价计划。开发方宜使用软件产品质量的内部或外部测 度来制定产品质量评价计划，使其符合静态或动态产品、中间产品或可交付产品的质量要求， 每个开发阶段的产品质量评价计划宜包括目的、对象、时间、人员、地点、方法、费用和数量（Why： What,When，Who,Where,Howto,HowmuchandHowmany)等因素，如下所示： 每个产品生存周期质量评价的目的； 待评价的目标产品部件； 评价活动，包括各开发阶段涉及的进度和资源； 各开发阶段对应评价活动的责任； 一产品质量评价的地点和环境； 一用于评价的测度、方法和测量工具； 一预算。 当目标实体是静态产品时，评价方法是基于软件产品质量内部测度的设计评审；当目标实体是动态 品时，评价方法是基于软件产品质量外部测度和使用质量测度的测试（单元测试、系统集成测试）。 产品质量评价活动应在软件开发生存周期中适时进行。设计文档和需求规格说明的评价宜在实际 开发的最早阶段进行，以获得高质量的产品并提高软件开发的效率。为开发新产品宜开发并评价原型 产品，以验证实现符合质量要求的高质量新产品的可行性。 评价计划不宜有重复的任务。评价计划宜包括评价过程中的决策点，以此确定何时及为何可以完 成（即验收或拒收标准）和/或停止， 为了减少出错风险和计划的评价工作量，宜至少考虑： 评价预算； 评价方法和适合的标准； 评价工具； 评价活动，包括涉及的进度和资源。 评价计划应包括评价目的。评价计划宜考虑组织的评价周境（见GB/T25000.2一2018范围中评 价支持小组的角色和GB/T25000.2一2018附录A）。评价计划宜包括： 产品质量评价的目的： 参与评价的组织，如独立评价组织、产品开发方和需方组织； 评价预算； 评价所预期的信息产品； 评价里程碑的时间表； 各评价参与方的责任； 评价环境；

GB/T25000.412018

评价方法和工具； 产品质量测度判定准则； 产品质量评价判定准则； 一采用的标准； 评价活动。 在评价的早期阶段，评价计划中的一些项目只能在一个高层次上定义。因此，评价计划应随评价活 动的开展逐步修订，并提供允许计划调整或细化的附加信息。开发方应确定在哪些生存周期的过程和 活动中，将实现产品属性的测量和评价。内部属性的测量和评价通常在开发过程中进行。开发方应考 念评价对软件开发活动的任何影响，测量集可能通过数据采集的需要引起开发过程中的变化 当测量结果不确定或遇有警告时，开发方应定义应急措施，如额外的评价。为实施测量，开发方可 能需要分配、评价、验收、调适或者开发硬件或软件工具。 测量集还可能意味着开发软件系统的组织结构变化， 负责质量保证/控制的组织或整个开发团队可能需要进行有关应用测量与数据采集程序方面的培 变化的普训

本活动的输人宜包括： a 详细的产品质量评价计划； b）产品质量评价需求规格说明； 产品质量需求规格说明； d 已选定质量测度说明； 产品质量测度判定准则说明； 产品质量评价判定准则说明； 产品质量评价方法说明； h）待评价的产品（包括中间产品）。 本活动的输出宜包括： a）产品质量测量结果； b）产品评估及评价结果。 从开发方的视角看，有关产品的信息还包括静态产品，例如 产品规格说明； 程序源代码； 操作手册； 产品说明

评价方宜根据评价计划测量静态和动态产品（如需求规格说明、设计图和测试文档、可执行产品）的 质量。 在测量静态产品时，宜评审目标实体。评价方宜指派适合人员进行设计评审，并宜根据产品质量评 价计划的设计评审结果来记录测量值。有关设计评审的附加信息宜记人文档，如下： 检测到的问题清单； 用于设计评审的检查表（包括测度的判定准则）

在测量动态产品时，宜测试可执行产品的目标实体。评价方宜指派适合的人员进行测试，并宜根据 产品质量评价计划的测试结果记录测量值。有关测试的附加信息宜记人文档，如下： 检测到的缺陷清单； 一测试计划； 一测试文档（包括测度的判定准则）。 测量结果宜在开发生存周期中适时向组织报告，并在下一开发阶段加以考。当不能接受测量结 果时，在问题得到解决之前，开发活动不宜转入下一阶段。评价报告宜在下一开发阶段之前提交。 为了提高产品质量和开发效率，检测到的产品质量问题宜在下一开发阶段之前记入文档并加以解 决。检测到的产品质量问题应在尽早的开发阶段加以解决，避免遗留问题到以后的并发阶段，以便有效 地提高产品质量和开发效率。 开发方应按评价计划将所选择的产品质量测度应用于产品和组件，以得到测量标度上的值。在开 发期间进行质量监测和控制，收集内部属性的实际值。在值不符合预期的情况下分析原因，使开发方理 解存在的问题并作出反应。开发方应根据定义的数据收集活动收集所定义的内部属性的实际测量值。 当产品质量需求变更时.开发方应重新考虑评价规格说明和评价设计

7.5.3应用产品质量测度判定准则

在软件开发生存周期中，为了评价静态和动态产品（如需求规格说明、设计图和测试文档、可执行产 品），应将基于质量需求的产品质量测度判定准则应用于测度值。 在设计评审阶段评价需求规格说明时，应将质量测度判定准则应用于每个产品质量特性和使用质 量特性的测度值；在评价静态中间产品时，应将质量测度判定准则应用于产品质量特性的测度值；在评 价动态可交付产品时，应将质量测度判定准则应用于每一个产品质量特性和使用质量特性的测度值。 注1：在评价静态中间产品时，质量测度判定准则可用作检测到的问题数的限制， 注2：在评价动态可交付产品时，质量测度判定准则可用作检测到的缺陷数的限制

7.5.4应用产品质量评价判定准则

在软件开发生存周期中，为了评价静态和动态产品（如需求规格说明、设计图和测试文档、可执行产 品），应将基于质量需求的产品质量评价判定准则应用于使用质量特性和子特性汇总值的结果 注1：在评价静态中间产品时，质量评价判定准则可基于评审检测到的间题汇总值进行限制， 注2：在评价动态中间产品时，质量评价判定准则可基于单元测试检测到的缺陷汇总值进行限制。 判定准则集应汇总到子特性和特性，产生的评估结果作为对产品符合质量需求程度的声明。评价 结果宜： a 建立产品能满足评价需求的适当可信度： b 确认针对评价要求的任何具体缺陷，以及确定这些缺陷范围所需的任何附加评价； 确定产品使用的任何特定限制或条件； d）确定评价本身的任何弱点或疏漏，以及所需的任何附加评价； e）确定评价未覆盖的产品使用上的任何选项。 在软件开发期间，通常根据评价计划中确定的里程碑进行数次评价。评价结果对于支持软件开发 生存周期下一阶段的管理决策是重要的，如需求是否需要变更或开发过程需要更多资源。 开发方宜使用所定义指标的实际值来估计可交付产品的质量，并宜考虑开发方组织此前类似质量 需求项目的经验。质量预测取决于经验证的指标，开发方组织需要首先收集多个项目的指标值和产品 测度值，以获得经验证的指标集。 开发方宜使用实际值来监控趋势，以识别开发风险，并在开发完成后进行产品质量评价，收集产品 属性的实际值。如果可能，可以在开发完成前测量产品组件。开发方宜将测量和评价的结果适当地反

遗到相继的产品开发、维护或下一次软件开发的任务或阶段

7.6.1 输入和输出

本活动要求的输人如下： a）产品质量评价需求规格说明； b）产品质量评价计划的实际结果； c）产品质量评价方法说明； d）评价结果 本活动的输出宜包括： a）产品质量评价报告。 从开发方的视角看，有关产品的信息还包括静态产品，例如 产品规格说明； 程序源代码； 操作手册； 产品说明

7.6.2评审评价结果

GB/T25000.412018

评价方和请求方应联合评审评价结果。评价组应评审静态可交付产品（如需求规格说明、设计图和 测试文档）的评价结果。评审的目标实体是静态中间产品或可交付产品（如需求规格说明、设计图和测 试文档）的评价结果。 评价方宜基于评价过程和结果的记录进行评审，并可考虑有关评价的必要信息，以进行恰当的 评审。 评价方宜指派独立评价组织进行评审，并宜指派合适人员进行评审 评审静态产品质量评价的结果，宜基于质量评价计划和评价报告。关于评审的附加信息可能必要 的有： 检测到的问题清单； 一用于设计评审的检查表（包括测度的判定准则）。 评审动态产品质量评价的结果，宜基于质量评价计划和评价报告。下列关于评审的附加信息宜是 必要的： 检测到的缺陷清单； 测试文档（包括测度的判定准则）。 评审产品质量评价的结果，宜在开发生存周期中适时进行，评审报告宜在下一开发阶段之前提交， 为了达到可交付产品的质量和提高开发效率，评价结果的质量宜通过评审来确保和改进。 在开发生存周期中，评审宜由开发前期阶段和后期阶段的人员联合执行。评价组应评审评价结果 以及所应用评价过程、指标和测度的有效性，并宜使用评审反馈来改进评价过程和评价技术（评价模 块）。在有必要改进评价模块时，宜包括对额外指标的数据收集，以便加以验证供日后使用

7.6.3编制评价报告

评价方宜根据产品质量评价计划 品（如需求规格说明、设计 呈序）的最终评价结果来创建质量评价报告 产品质量评价报告宜根据固定的质量评价计划创建，产品质量评价报告宜包括基于质量评价证

审静态产品和测试动态产品的结果。为保证产品质量评价报告的质量，应评审质量评价结果， 产品质量评价报告因评价的目标实体不同而异 静态产品的质量评价报告宜包括： 检测到的问题清单； 设计评审所用的检查表（包括测度的判定准则）。 动态产品的质量评价报告宜包括： 检测的缺陷清单； 测试计划； 测试文档。 产品质量评价报告，宜在下一开发阶段之前适时向组织提交。例如，静态中间产品（如测试规格说 )的质量评价报告，宜在测试之前提交。静态和动态可交付产品的质量评价报告，宜在产品发布之前 交。 产品质量评价报告宜宣由有关的利益相关方确认。在开发生存周期中，宜由开发的前一阶段和后 段的人员联合评审产品质量评价报告。 根据用途，产品质量评价报告宜包括： a） 产品质量评价需求； b 产品质量需求； 产品质量评价计划； d 执行测量和分析的结果； e） 制定评价计划时的中间结果或判定说明； f 评价活动中的任何限制、约束、不足或例外，及其后续对产品使用、配置、修改或一般性维护的 影响； g） 评价方及其资质； 评价产品版本之间的任何差异，以及相应的评价输入，即文档或课程； 1） 出现缺陷情况时的解决方案或变通方法； 能够重复或复现评价的任何其他必要的信息； k）评价结果。 作为对产品质量评价活动的分析结果，质量评价报告宜确定： a） 每个缺陷、任何相关分析，以及每个缺陷是如何解决的。缺陷的解决方案可包括以下事实： 其中一种评价方法保证该缺陷不属重大缺陷； 某个令人满意的“变通方法”被发现可以减轻该缺陷的影响；例如，修改产品，禁用或删除 不需要的功能，采用逆向工程再生遗漏的设计需求； 原始需求不是强制性的，该缺陷是可接受的； 如果产品的使用受到特定条件或界限的控制，该缺陷可以接受； 需要附加的评价工作，以解决评价中的不足或差距。 b）为解决任何已确认的缺陷而执行的任何附加产品质量评价： 确定某个缺陷的范围或影响； 建立零缺陷的信心； 验证某个变通方法在技术上可行和/或合适且可接受； 且为修正缺陷做出了一项或多项设计变更，就立即验证软件是否正确且性能可接受。 c）在有必要限制或控制产品使用时，界限是否： 干扰产品满足应用程序的强制性要求； 影响应用程序的设计、预算和进度；

GB/T25000.412018

需有额外的评价工作； 引入应用程序中任何失效的可能性。 d）对产品质量评价范围的任何例外和/或对每个评价结果的限制，例如： 该评价不包括对产品功能的详细评审； 只要成功地完成了对产品所需功能的全面评价，则认为本产品符合所要求的完整性级别。 e）所有评价活动的综合结果允许对产品的评价作出总体结论。 对产品质量评价报告的意见应予以处理，并纳入报告的最终版本

7.6.4评审产品质量评价并向组织提供反馈

评价方宜向组织报告静态产品（如质量评价报告、需求规格说明、设计图和测试文档）和动态产品质 量评价的最终结果，以便在下一开发或评价项目中复用， 评价方宜利用数据库中的公共信息系统，参考以前类似评价项目的有关信息，以使执行下一评价项 。评价方宜反馈有关评价项目实际结果的信息，如专门知识、人员简介和其他有用的信息，以使重用 年支持下一评价项目。开发方应使所收集的数据在组织的其他评价项目中可用 评价方应评审评价结果和所应用的评价过程、指标和测度的有效性，宜使用评审的反馈意见，以改 进评价过程和评价技术（评价模块），并宜在有必要改进评价模块时，包括对额外指标的数据收集，以便 以验证供日后使用。 注1：质量评价的评审和反馈在GB/T25000.2中描述 注2：产品质量评价的结果可用于获得不同的开发过程、设计方法或CASE工具满足质量需求程度的反馈

7.6.5处置评价数据

评价方宜评审并处置静态产品（如需求规格说明、设计图和测试文档）和动态产品质量评价的最终 结果，以便在下一开发或评价项目中复用。 评价方宜利用公共信息系统或数据库，参考以前对静态产品和动态产品质量评价的实际结果，并在 平价完成后，应按请求方的要求来处置数据和评价项。 依据数据类型，应以下列方法之一进行处置： 提交评价的文档应返还请求方，或存档至规定期限，或以安全的方式销毁； 评价报告和评价记录应存档至规定期限； 所有其他数据均应存档至规定期限，或以安全方式销毁。 当对某些数据所规定的存档期限到期时，应再次规定一个存档期限，或以安全方式销毁

8需方评价过程要求和建议

在获取“商业现货”产品、定制产品或现有产品修改版本时，需方产品质量评价过程的方法包括对产 品质量进行系统测量和评价的要求、建议和指南。 该过程由正计划获取或重用现有或预开发产品的组织使用，也应用于决定产品的验收或从备选产 品中选择产品（产品可以是独立的，也可以是系统的一部分或可能是更大产品的部件）。 当应用获取过程时，评价人员应考虑以下具体问题： 需方宜同时评价静态产品和动态产品，以发挥其作用。 需方宜评价静态产品，以达到下列目的： 改进获取产品的质量需求； 恭取之前确定产品的设计说明

需方宜同时评价静态产品和动态产品，以达到下列目的： 比较并选择商业现货产品； 验收开发方提供的定制产品； 提高获取过程的效率； 培训产品质量评价人员。 需方应以支持各种过程和活动的方式来配合评价活动。 许多数据分析方法需要以类似条件、类似质量要求获得的以前项目的数据。因此，需方宜应用所属 组织在以前项目中采用的类似获取模式，不排除附加要求，以达到需方目的。同一属性集也宜应用于考 慧数据分析的项目。 产品质量需求表达了用户对意向产品的要求，并在获取之前定义（见ISO/IEC25030）

本活动的输入和输出见7.2.1。 从需方的视角考虑，产品信息包括静态产品，例如： 产品规格说明； 操作手册； 产品说明。

本活动的输人和输出见7.2.1。 从需方的视角考虑，产品信息包括静态产品，例如： 产品规格说明； 操作手册； 产品说明。

8.2.2明确评价且的

产品质量评价的目的应基于需方角色编制文档，作为下一步评价活动和任务的基础。需方宜特别 评价静态和动态可交付产品，以发挥其特定的作用 评价静态中间产品质量的目的可包括： 提高需求规格说明的质量； 提高获取过程的效率； 培训产品获取的质量评价人员 评价静态和动态可交付产品质量的目的可包括： 验收高质量的产品； 决定是否验收来自开发方的定制产品； 评估产品使用的正面和负面影响； 从供方选购商业现货产品； 从候选产品中选择； 与竞争性产品进行比较； 评估现有产品修改需求。 从需方视角看，评价过程通常是获取过程的一部分，如ISO/1EC12207：2008所定义。在这种情况 下，评价目的宜确定为： 后续的获取过程以及如何与供方沟通评价输入需求； 产品是否将用于特定应用、特定应用的集合或通用范围的应用； 产品是否已经由第二方或第三方进行过评价，或是否计划以后实施评价活动。 注：参见图3、图4中的评价和获取组合过程的示例

GB/T25000.412018

图3商业现货产品的评价/获取过程示例

定制软件或改版现有软件的评价/获取过程示

评价过程可与下面概括的获取过程（在ISO/IEC12207：2008中定义）相结合，以使评价结果有助 达到获取的最终目标： 启动一一确定待获取产品的软件需求、获取计划及验收策略和标准； 需求计划（标书）编制一一获取需求规格说明和相关文档： 合同的编制和更新一一供方选择、合同编制和谈判，以及合同变更控制； 供方监控一一在合同执行期间所实施的评价活动，以保障产品的验收和交付； 验收和完成一一在可交付产品的验收和交付期间实施的活动。 需方需要同时定义评价过程和获取过程，以达到获取期间的评价要求。在较大系统的开发周境下，

评价过程可与下面概括的获取过程（在ISO/IEC12207：2008中定义）相结合，以使评价结果有助 达到获取的最终目标： 启动一一确定待获取产品的软件需求、获取计划及验收策略和标准； 需求计划（标书）编制一获取需求规格说明和相关文档； 合同的编制和更新一一供方选择、合同编制和谈判，以及合同变更控制； 供方监控一一在合同执行期间所实施的评价活动，以保障产品的验收和交付； 验收和完成一一在可交付产品的验收和交付期间实施的活动。 需方需要同时定义评价过程和获取过程，以达到获取期间的评价要求。在较大系统的开发周境下，

GB/T25000.412018

8.2.3获取软件产品质量需求

图5从需方角度的产品质量评价过程概览

除了7.2.3的要求外，还包括如下要求。 需方应标识产品的最终用户。需方宜基于评价的目标实体定义产品质量需求。 在评价设计文档时，宜使用软件产品质量内部测度定义产品质量需求；在评价动态可交付产品时， 宜使用软件产品质量的外部测度和/或使用质量测度定义产品质量需求。 产品质量需求规格说明构成了获取过程中招标阶段获取需求及实施后续产品质量评价的基础

8.2.4标识待评价产品部件

除了7.2.4的要求外，还包括如下要求。 在改进已验收产品质量或现有运行产品生产率时，评价的目标实体宜包括静态和动态可交付产品， 例如： 产品规格说明； 操作手册； 一产品说明； 一在运行阶段，纳人运行系统的可执行产品。 产品质量评价中包括的所有产品部件，均应予以标识和记人文档， 注1：从需方的视角，有关产品的信息还包括静态产品，例如： 一质量评价计划 一质量评价报告。 注2：例如，当评价的目的是从备选产品中选择产品时，待评价的产品主要是可交付产品或组件。 需方待使用和获取的候选产品是能集成到大型系统的组件，或是能独立使用的软件产品。分类 如下： a） 商业现货软件产品； b）为其他应用或广泛的常见应用所开发或获取的现有产品； c）定制产品或现有产品的修改版本。 对于拟集成到大型系统的软件配置项，软件需求需定义每一个配置项。在其他情况下，系统与软件 配置项是一致的，并且可认为是等效的；待获取的硬件配置项可能包含软件，如驻留在固件（即ROM， PROM)中的操作系统。当现有软件以这种方式形成硬件的主要组成部分时，通常需要与硬件配置项 起评价。 此外应考虑： a 供方或需方是否愿意并能够提供所需的文档、设备、工具、软件、课程和/或培训以及与此相关 的成本； b） 是否存在访问各种机密或专有信息的条件； 供方和第三方是否愿意并能够提供专业咨询及相关的成本设备设计图纸，包括差旅费； d 评价方是否具备根据评价需求开展评价所需的专业知识，以及获得此类专业知识的预算； e） 是否需要确定产品适合于全面测试的任何预测试

8.2.5定义评价严格度

除了7.2.5的要求外，还包括如下要求。 从需方的视角，关于产品评价严格度的信息还包括静态产品，例如： 产品的需求规格说明。 评价过程的范围通过访问第三方所做评价活动的结果（只要结果是可信的）可予缩小，该评价活动 可以包括此前已有的认证、产品质量评价和/或过程评估。例如： 可将产品开发的软件工程过程标准化，以满足ISO/IEC12207、ISO/IEC90003或其他行业标 准的要求； 供方软件开发所遵循的质量体系可由第三方依据ISO9001的要求进行认证； 产品可由第三方根据GB/T25000.40或GB/T25000.51进行符合性评价； 供方可验收产品开发的软件过程能力，可由第三方根据ISO/IEC15504进行符合性评估； 软件产品可作为大型系统开发阶段的一部分进行功能性评价；

档案标准GB/T25000.412018

可能已经针对具有不同完整性需求的另一应用评价过该软件产品； 在对以前由其他方主持的评价评审之后，与其评价需求相应的覆盖级别是必要的； 由组织内的其他方通过非正式或正式的评价活动对产品进行过评价。 为获得和解释对目标应用的产品质量评价结果所需的附加成本和时间，可影响该方法的可行性 为了充分信任他方的评价结果，可能仍有必要咨询评价方或供方， 评价过程可广泛地应用于获取需求、完整性需求和评价组目标。例如： 软件包需方可能希望只采用GB/T25000.51来评价软件包； 产品需方可采用GB/T25000.40独立评价； 小型或独家需方可能需要不太正式的评价过程及最低限度的评价文档： 对于消费类软件，评价过程的目标可能仅仅是从类似产品中选择、测试和获取一种产品。于是 将正式的获取过程简化为直接购买且不签署合同。 采用ISO/IEC12207：2008中给出的裁剪指南和拟获取特定产品所需的完整性级别，也能将评价 过程中的获取过程加以裁剪。获取具有高完整性要求的整套软件系统，通常均需要应用全套获取活动 和任务，以及ISO/IEC12207：2008中规定的相应供应过程的活动和任务。一般来说，随着完整性级别 任务的点数也宜随之增加

本活动的输人和输出见7.3.1 从需方的视角考虑，产品信息还包括静态产品，例如： 候选产品和供方的清单； 实际安装数量； 所演示的且标系统