数据data 赋予基本测度、派生测度和（或）指标的值的汇集 LISO/IEC15939：2007，定义2.4 4.10 判定准则decision criteria 用于确定是否需要采取措施和进一步调查，或者用于描述给定结果置信度的阈值、目标或模式 [ISO/IEC15939:2007,定义2.7] 4.11 派生测度derivedmeasure 定义为基本测度的两个或多个值的函数测量。 [ISO/IEC15939:2007,定义2.8] 注1：改写1993年版计量学基本与通用术语国际词汇。 注2：使用数学函数的基本测度的转换也可考虑作为一个派生测度， 4.12 开发方developer 在软件生存周期过程期间，执行开发活动（包括需求分析、设计、测试直到验收)的个体或组织， 注：改写自ISO/IEC12207：2008，定义4.10。 4.13 标准分部 division ofstandards 构成系列标准，服务互补目的分部。 4.14 最终用户 enduser 最终受益于系统结果的单独个体。 注：最终用户可能是软件产品的常规操作员或是公众场合下的临时用户。 4.15 实体entity 通过测量其属性、表述其特性的对象。 示例：一个对象可能是过程、产品、项目或资源， [ISO/1EC15939:2007,定义2.9] 4.16 评价evaluation 实体满足其规定准则的程度的系统性判定。 [ISO/IEC12207:2008,定义4.12] 4.17 评价覆盖率 evaluationcoverage 评价特定软件产品质量需求的覆盖程度。 4.18 评价级别 evaluationlevel 在评价期间所采用的严格度，该严格度根据所用的评价技术和所达到的评价结果界定评价的泛 和彻底度。

为了获得对特定产品部件或整个产品实施规定测量的结果而描述由评价方采取动作的规程。

评价模块 evaluationmodule 用于测量软件质量特性、子特性或属性的评价技术包。 注：该包包含评价方法和技术、评价的输人、待测量和待收集的数据以及支持规程和工具。 4.21 评价记录 evaluation records 评价过程中所有的评价活动和取得的所有结果的客观记录证据。 4.22 评价请求方 evaluationrequester 请求评价的个体或组织。 4.23 评价工具 evaluationtool 在评价期间，可用于收集数据、解读数据或执行部分自动评价的设备。 注：这些工具的例子有：计算代码度量的源代码分析工具，生成形式化模型的CASE工具，运行可 环境，收集审查数据的检查列表，或者生成综合测度的报表。 4.24 评价严格度 evaluation stringency 软件产品质量特性和子特性满足软件产品预期使用临界要求的程度。 4.25 评价方 evaluator 实施评价的个体或组织。 4.26 失效failure 产品执行所要求功能的能力终止或它在先前规定的限度内无力执行所要求的功能。 注：改写IEEE610.12—1990中的定义。 4.27 故障fault 计算机程序中不正确的步骤、过程或数据定义。 [IEEE610.12—1990] 4.28 功能性需求 functional requirement 规定系统或系统部件应能执行的功能需求。 [IEEE 610.12—1990] 注：软件质量特性“功能性”可用来规定或评价某个功能的完备性、正确性、适合性和依从性。 4.29 隐含的要求 implied needs 可能未明确阐述，却是实际需要的要求。 注：当软件产品用于特定场合时一些隐含的要求才会成为显然的。 示例：隐含的要求包括：尽管没有明确阐述但通过其他明确的要求而隐含的需要，以及由于被认为 易见的而未明确阐述的需要。 4.30 独立评价方independentevaluator 独立于开发方和需方，实施某评价的个体和组织。 注：个体或组织作为待评价目标系统的开发方或需方时不能成为系统的独立评价方。独立评价 织，只要独立于开发方和需方。独立评价方可属于与开发方相同的组织

独立评价方independentevaluator

4.41 测量函数 measurement function 为组合两个或多个基本测度而执行的算法或计算。 [ISO/IEC15939:2007,定义2.20] 4.42 测量方法 measurement method 操作的逻辑序列，用以按规定标度量化的属性。 [ISO/1EC15939:2007,定义2.22] 注：改写1993年版计量学基本与通用术语国际词汇。 4.43 测量规程 measurementprocedure 组具体操作的描述，可按给定方法执行特定的测量。 [ISO/IEC15939:2007,定义2.23] 注：改写1993年版计量学基本与通用术语国际词汇。 4.44 测量过程 measurement process 在一个完整项目或组织的测量机构中确立、策划、执行和评价软件测量的过程。 [ISO/IEC15939:2007,定义2.24］ 4.45 观察observation 应用测量规程产生基本测度值的实例。 [1SO/1EC15939:2007,定义2.29] 4.46 操作方 operator 运行系统的个体或组织。 ［ISO/IEC12207:2008,定义4.22] 4.47 过程 process 将输入转化为输出的相互关联或相互作用的一组活动。 注：改写GB/T19000—2016，定义3.4.1。 4.48 使用质量 qualityinuse 在特定使用环境中，用户使用产品或系统满足特定用户在达到有效性、效率和满意度等方面的特定 目标的能力。 4.49 质量测度元素qualitymeasureelements 为了量化一个属性而通过该属性和测量方法所定义的测度建筑标准规范范本，包括有选择地通过一个数学函数的 转换。 4.50 质量模型qualitymodel 定义的特性集以及它们之间的关系集，为规约质量需求以及评价质量提供了一个框架 4.51 评定rating 把与软件产品质量特性相关的测量值映射到相应的评定级别。

软件产品softwareproduct

软件质量测量softwarequalitymeasure 对软件质量的内部测度、外部测度和软件使用质量测度的测量。 4.61 利益相关方stakeholder 在系统或系统特性有权利、份额权利或主张以满足其要求和期望的一方。 注1：改写自ISO/IEC15288：2015，定义4.1.44， 注2：利益相关方包括但不限于最终用户、支持方、开发方、生产方、培训方、维护方、部署方、需方、供方和监管方。 4.62 供方supplier 与需方签订协议，并按协议条款提供系统、软件产品或软件服务的个体或组织。 [1SO/IEC12207:2008,定义4.47] 4.63 系统 system 为达到一个或多个明确目的而组织起来的、相互作用的元素的组合体。 注1：一个系统可被认为是一个产品或它提供的服务， 注2：实际上，对系统含义的解释通常通过使用一个联合名词来阐明，如飞行器系统。或者，单词“系统”可简单地由 上下文相关的同义词来替代，如飞行器，虽然这可能使系统原则的观点不太明显 [ISO/IEC15288:2015,定义4.1.46] 4.64 过程目标targetofprocess 对软件产品或由软件产品执行的任务所应用的一个测量或评价过程。 4.65 测量单位unitofmeasurement 接药定定义和采用的具体量，其他同类量与这个量进行比较，用以表示它们相对于这个量的大小， ［ISO/1EC15939：2007.定义2.40 注：改写1993年版计量学基本与通用术语国际词汇。 4.66 用户 user 在系统使用过程中，与系统进行交互或从系统中获益的个人或组织。 注：用户可包括操作方、软件结果的接收方或软件的开发方或维护方， 4.67 确认validation 通过提供客观证据来证实针对某一特定预期用途或应用需求已经得到满足。 [GB/T19000—2016,定义3.8.13] 注1：“确认过的”一词用来表示相应的状况。 注2：在设计和开发中，确认涉及检查某个产品以确定是否符合用户需要的过程， 注3：确认通常是对最终产品在规定的使用条件下进行的。在早期阶段，也可能需要进行确认。 注4：如果有不同的预期用途，可以进行多重确认。 4.68 值value 通过执行测量，对实体的属性赋予数值或类别。 4.69 验证 verification 通过提供客观证据来证实规定需求已经得到满足

[GB/T19000—2016,定义3.8.12 注1：“验证过的”一词用来表示相应的状况， 注2：在设计和开发中，验证是指对某项规定活动的结果进行检查的过程，以确定该活动对规定需求的符合情况

5软件产品质量评价参考模型

软件产品质量评价参考模型包括评价过程，以及关联的评价输人、评价约束、评价资源和评价输

2软件产品质量评价参

在第6章中阐述评价输入和评价输出。 软件产品质量评价过程的评价约束包括以下内容： a 特定用户要求； 资源； ） 计划表； d）成本； e） 环境； f） 工具和方法论； g）报告。 软件产品质量评价过程的评价资源包括以下内容： a 适用的测量工具、方法论和评价模块； b） 适用的SQuaRE文档（GB/T18905.6、GB/T25000.2、GB/T25000.10、ISO/IEC25022、ISO） IEC 25023、ISO/IEC 25030,GB/T 25000.41等); ） 软件产品质量评价的人力资源； 软件产品质量评价的经济资源； e） 软件产品质量评价的信息系统； 软件产品质量评价的知识数据库 软件产品质量评价参考模型适用于那些负责软件产品质量评价人员。该模型适合但不限于在软件 品中的开发方、需方和独立评价方角色。 软件产品质量评价参考模型意在评价开展前，形成清晰的目标和评价准则，依据ISO/IEC25030 生的软件产品质量需求规格说明为基础进行评价。ISO/IEC25030为软件产品质量需求规格说明给 了要求和建议。其他的SQuaRE文档如GB/T25000.10和ISO/IEC25022、ISO/IEC25023等也适

用于该参考模型。 软件产品质量评价可由开发方、需方或独立评价方在开发过程或获取过程期间、之后实施

软件产品质量评价过程描述了评价的过程和任务

图3软件产品质量评价过程

第6章详述了可用于指导软件产品质量评价输入、输出和补充信息的活动和任务。注意，第6章 出一般评价过程。 注：附录B给出了每个评价活动的输入、输出、约束和资源的关系图， 为了适应每个应用程序的独特性，为了避免不必要的或没有附加价值的工作，以及为了提供一利 牛建立必要信心的实用方法，评价过程的实施具备灵活性是必要的。 在第6章中提供了每个活动和任务的要求和建议

第6章详述了可用于指导软件产品质量评价输入、输出和补充信息的活动和任务。注意，第6章拟 提出一般评价过程。 注：附录B给出了每个评价活动的输入、输出、约束和资源的关系图， 为了适应每个应用程序的独特性，为了避免不必要的或没有附加价值的工作，以及为了提供一种对 软件建立必要信心的实用方法，评价过程的实施具备灵活性是必要的。 在第6章中提供了每个活动和任务的要求和建议

不同的角色（包括需方、开发方、独立评价方、供方、操作方和维护方）有不同的目的。 需方：当获取某个定制软件产品时，需方可以建立使用质量需求和软件质量需求，可对供方规定要 求，并可在获取前通过对照这些需求来评价潜在的购买行为。当获取某个待开发产品时，规定质量需求 的目的是确保该产品符合用户明确和隐含的要求。当购买某个软件产品时，评价可用于比较备选产品，

确保所选产品满足质量需求 开发方：当开发某个定制软件产品时，开发方通过评价中间软件产品或最终产品来确保开发的软件 质量。开发方可使用软件产品质量评价结果，以确保产品符合所要求的质量准则。该准则可由需方，或 与其他产品的比较来设置。 独立评价方：当评价某个目标软件产品时，独立评价方可评价中间软件产品或最终产品以保证软件 质量。当相关方需要理解、接受和信任评价结果时，独立评价方法的评价过程为实际执行的软件产品质 量评价提供了要求和建议。该过程用于评价方对某个软件产品执行独立的评价。评价可在开发方、需 方或其他方要求下实施。 供方：供方可以利用软件产品质量评价的结果来确保产品符合质量准则的要求。该准则可由需方， 或与相关产品的比较来设置。 操作方：个体或组织运营的软件产品是系统的一部份，可使用软件产品质量评价来确认质量需求在 可变操作条件下是否得到满足，并将任何有关需求的变更反馈给负责维护的人员。 维护方：个体或组织维护的软件产品是系统的一部份，可使用软件产品质量评价来确认质量需求是 否仍然满足，以及维护性和可移植性的需求是否可以实现

5.4生存周期中的质量

通过采集软件产品质量评价方法和工具的信息、开发和确认测度、标准化评价过程和测度等内容来 铺助评价的活动。 GB/T25000.2包含了对于支持软件产品质量评价的过程和对于通过例如评估每个评价项目和其 自身评价过程来改进组织层面评价过程的需求和指导 GB/T25000.41包含了对开发方、需方和评价方的具体要求和建议 GB/T18905.6规定了评价模块的结构和内容，评价模块记录了评价技术和对于应用该项技术的 规程。

6软件产品质量评价过程

本过程的目的是指导软件产品质量评价。 评价方应按照适当的、有组织的策略和步骤执行第5章中描述的软件产品质量评价过程的活动和 任务（见图3） 注1：图3是一个简化的视图，并没有显示所有特定活动或活动之间的迭代次数。 评价方应有合适的工具和技术执行软件产品质量评价。 注2：GB/T25000.2提供了软件产品质量评价中关于计划和管理组织方面的指导， 评价方应有允许数据收集和基于数据分析过程变动的一个基础设施。 参与评价的人员应具备必要的技能和培训。 为了保证评价结果的重复性、再现性、公正性和客观性，评价方应在组织周境下采取行动，为其活动 提供必要的保证，以获得足够的质量

软件产品质量评价的每个活动应被记录

评价记录应包括某个由评价方在执行软件产品质量评价计划期间实施的详细行动说明。 评价记录应包含软件产品质量评价管理所需要足够的信息 评价记录应包括以任何中间数据为基础的所有解释。在解释过程中作出的决定也应像在评价计划 中规定的那样列入评价记录。 为了后续软件产品质量评价活动的有效执行，记录应含有每个活动的足够信息。 为了给软件产品质量评价提供证明，并允许评价结果的重新处理，应保存记录。 软件产品质量评价报告应准备好评价活动和评价结果的记录。 注：附录C提供了一个评价报告的模版。评价报告格式可以采用标准格式（如GB/T25000.62等的行业通用格式） 或者可由评价方自己创建。 当某个工具被用来实施某项评价行动时，评价报告中应包含该工具的标识、工具供方的标识和工具 版本信息等参考资料， 在评价记录中，应包含使用工具更加详细的参考资料。该参考资料应包括工具的详细配置和能重 复获得相同中间结果的所有与评价活动有关的信息，

本活动的输人宜包括： a） 软件产品质量评价要求； b) 软件产品质量需求规格说明； 待评价软件产品（包括中间软件产品）。 本活动的输出宜包括： a）软件产品质量评价目的说明； b）软件产品质量评价需求规格说明； c）高层次软件产品质量评价计划

本活动的输人宜包括： a）软件产品质量评价要求； b） 软件产品质量需求规格说明； c）待评价软件产品（包括中间软件产品）。 本活动的输出宜包括： a）软件产品质量评价目的说明； b） 软件产品质量评价需求规格说明； c）高层次软件产品质量评价计划

软件产品质量评价目的作为进一步评价活动和任务的基础应当有案可查（记录）。 软件产品质量评价直接目的是开发和获取的软件是否满足用户和客户的要求。最终目的是确保该 品提供了要求的质量一一即符合用户（包括操作方、软件结果的接受方和软件的维护方）明确和隐含 的要求。 软件产品质量可在某个确定的贯穿与ISO/IEC12207软件生存周期过程和ISO/IEC15288系统 生存周期过程中定义的软件实施过程和获得过程相关的生存周期阶段的质量结构之内被评价。 注：附录D给出了本标准与ISO/IEC12207软件生存周期过程和ISO/IEC15288系统生存周期过程的对应关系， 可对某个中间产品或某个最终产品进行软件产品质量评价。 评价中间软件产品质量的目的是为了： a 保证产品质量； b 决定（是否）接受分包方的中间软件产品； ） 访问正在进行的开发项目的可行性； d 决定某个生存周期阶段的（是否）完成，以及决定何时把产品发送到下一阶段： e） 预测或估计最终软件产品的质量； 收集中间软件产品信息，以便控制和管理过程。 评价最终软件产品质量的目的是为了： a 决定（是否）接受产品：

决定何时发布产品； C) 与相互竞争的产品进行比较； d) 从众多可选的产品中选择一种产品； e) 评估产品使用时积极和消极的影响； f) 调查确定失效的原因； g 决定何时增强或替换该产品

6.3.3获取软件产品质量需求

软件产品的利益相关方应被识别。 注1：为了识别所有的利益相关方，需要来自评价请求方的信息 注2：待识别的利益相关方可以是某个人、团体或组织，并尽可能参与评价。两种类型的利益相关方应被识别。 类是软件产品的利益相关方，如开发方、需方、独立评价方、用户、操作方、软件结果的接收方、维护方或供 方。另一类是需要软件质量信息、赞助评价和想要评价报告的评价请求方。 软件产品质量使用模型规定的质量需求应提供。 注3：GB/T25000.10根据质量特性和子特性定义了一个质量模型， 注5：如果现有的软件产品质量需求规格说明可用，则它可以被复用、审查和完善 基于约束（如评价预算、评价目标日期、评价目的以及软件产品使用临界），应定义质量评价覆盖软 产品质量需求的程度，以此产生软件产品质量评价需求。 注6：由于软件产品质量需求规格说明书可能在开发或获取过程中得到改进，因此可能有必要完善软件产品质量评 价，以使他们与评价目的相兼容

应识别与记录所有待评价的产品组件。 待评价的中间或最终软件产品（如需求规格说明、设计图和测试文档）的类型取决于生存周期所处 价段和评价的目的。例如，如果评价的目的是从替代产品中选择某个产品，则待评价的产品主要是最终 的软件产品或组件。在评价过程的初始阶段不可能确定一个详细的待评价产品清单，因为它还取决于 斤应用的测度以及在软件开发生存周期中所产生的成果。因此，宜识别在何时有可能被列入评价的软 件产品组件，可使初始列表能够随着评价活动的演化得到完善

6.3.5确定评价严格度

应定义评价严格度。 注1：定义严格度是为了按照软件产品预期用途和评价目的提供软件产品质量的信心。 评价严格度应该与一组建立了预期评价级别的特性和子特性有关，评价级别定义了所应用的评价 技术和达到的评价结果 注2：GB/T18492一2001定义了系统和软件完整性级别。软件所要求的完整性级别很大程度上决定了评价的严格 化和正规化， 注3：以下是根据不同的评价级别需求应用于功能性特性的评价技术级别从低到高的例子： a）功能性或黑盒测试； b）以清单为指导的开发文档的检查； c）遵循测试覆盖率准则的单元测试。 附录E给出了评价技术级别的参考

应定义评价严格度。 注1：定义严格度是为了按照软件产品预期用途和评价目的提供软件产品质量的信心。 评价严格度应该与一组建立了预期评价级别的特性和子特性有关，评价级别定义了所应用的评价 支术和达到的评价结果 注2：GB/T18492一2001定义了系统和软件完整性级别。软件所要求的完整性级别很大程度上决定了评价的严格 化和正规化， 注3：以下是根据不同的评价级别需求应用于功能性特性的评价技术级别从低到高的例子： a）功能性或黑盒测试； b）以清单为指导的开发文档的检查； c）遵循测试覆盖率准则的单元测试。 附录E给出了评价技术级别的参考

本活动的输人宜包括！

a） 软件产品质量评价目的说明； b） 软件产品质量评价需求规格说明； 高层次软件产品质量评价计划。 本活动的输出宜包括： a) 已选定质量测度规格说明； b 软件产品质量测度判定准则说明； C) 软件产品质量评价判定准则说明； 已修订的高层次软件产品质量评价计划

软件产品质量评价目的说明； b) 软件产品质量评价需求规格说明； 高层次软件产品质量评价计划。 本活动的输出宜包括： 已选定质量测度规格说明； b) 软件产品质量测度判定准则说明： 软件产品质量评价判定准则说明： d）已修订的高层次软件产品质量评

6.4.2选择质量测度

评价方应选择能覆盖所有软件质量评价需求的质量测度。 软件产品质量评价需求宜分配至相关软件产品组件，这种方式可将软件产品质量的评价定义到每 一个合适的质量测度。 为了取得评价结果，结合待实施的活动，软件产品质量评价方法应记录。当评价方法的描述是基于 某个软件工具的使用，该工具应在评价计划中标识。该标识应至少包括工具的名称、版本信息和来源 例如供方）。评价方法的描述应通过对产品组件待应用方法的标识来完成。当评价说明需要测量专家 来分析解释结果时，则应规定解释程序。 注1：GB/T18905.6规定了如何将评价方法、技术信息、评价输入、测量、收集的数据元素等信息包装成评价模块 附录F提供了常见评价方法的示例 注2：在这一阶段，评价方法与评价说明中的要素有关，即评价方法与评价需求有关。当每种评价方法都计划应用 于提交评价的各种产品组件时，可能会发生几个评价方法都应用于相同的产品组件或由共同部件组成的 产品。 注3：当评价需求涉及评价级别时，附录G提供了作为评价级别功能使用的评价技术和经过考虑的质量特性的 指导。 注4：ISO/1EC25020提供了一个可应用于解决软件质量测度选择与构建的软件产品质量测量参考模型。 注5：像ISO/IEC25030中规定的一样，在软件质量需求规格说明过程期间，那些量化指标，可能有必要使用质量测 度作为参考来规定质量需求。 严格测量要求产品间，或与标准值进行可靠的比较。测量规程宜以其声称的足够的精度来测量软 件质量特性（或子特性），以允许设定准则并进行比较。当比较不同属性的产品时，来自检查表和专家意 见的数据或许不可靠。测量工具或人为因素引起的可能的测量误差，宜予以考虑。 注6：GB/T25000.22、GB/T25000.23和GB/T25000.24给出了可以作为测度或适应特定要求的测度实例。 注7：要求的测量类型取决于评价的目的。如果主要目的是了解和纠正不足，可以对软件进行几项测量，以监测和 控制改进。各种不同的测度可用于这些目的，包括检查表和专家意见。基本要求是测量能正确识别软件中任 何变化对质量的影响， 评价说明应包含： a） 涉及产品描述中所标识的产品组件的评价范围； b） 实施评价所需的信息和产品组件及列人产品描述的其他相关文档之间的互相参考； 待实施测量和验证的说明以及待实施产品组件的参考； d） 测量和验证说明与评价需求之间的映射，以及标准参考或所列的每一个测量或验证的理由，

6.4.3确定质量测度判定准则

应定义选定单项测度的判定准则。 注：判定准则是用来确定是否需要行动或进一步调查，或是描述一个给定结果的置信水平的数字阅值或目标。 些数字阅值或目标通常将会在关于质量需求和相应的评价准则中设定。用户也可以使用基准、统计控制限

历史数据、客户需求或其他 受的阅值时，则实施附加的缺 陷检测和消除活动。该信息在其他地方有记： ；那个合适的参考位置（参见ISO/IEC25020）

6.4.4确定评价判定准

用分尖 注1：总结质量可与诸如时间、成本等其他方面作比较，因此评估准则可以进一步应用于支持管理决策 注2：为了评估产品的质量，需要对不同特性的评价结果进行总结，

6.5. 1 输入和输出

本活动的输人宜包括： a） 软件产品质量评价需求规格说明； b) 软件产品质量需求规格说明； C) 已选定质量测度（评价模块）规格说明； 软件产品质量测度判定准则说明； e) 软件产品质量评价判定准则说明； f 已修订的高层次软件产品质量评价计划。 本活动的输出宜包括： a）详细的软件产品质量评价计划； b) 软件产品质量评价方法说明

6.5.2策划评价活动

已确定的软件产品质量评价活动应考虑诸如人员、软件工具和计算机等资源的可用性来调度 注1：在评价方法的时序安排上，重要的是要认识到各种评价方法之间存在高度的相互依赖性，即一种方法获得的 信息可能会影响另一种方法的焦点。由于评价的性质是送代的，随着信息的获取，间题可能需要重新审视，因 此评价计划在评价时可能会改变。例如，当评价开展时，更详细级别的评价可能通常被视为不必要的或是一 个额外的要求。 注2：软件产品的评价可以分阶段地在开发生存周期的不同节点进行，或者在生存周期的某一节点一次性进行。不 同的个体或团体可能负责执行评价的不同部分。当评价是分阶段进行时，评价活动的步骤在每个阶段都重 复，直到无需进一步的工作为止 在评价中，评价计划宜不存在重复任务。评价计划宜定义评价过程中的决策点，以确定评价何时和 可被认为是完成（即接受或拒绝准则）和中止。为了降低错误的风险和减少计划的评价工作量，宜至 考虑以下项目： a）评价预算； b）评价方法和适合的标准； ）评价工具； d）评价活动，包括涉及的计划表和资源。 评价计划应包括评价目的。评价计划宜在组织内考虑评价周境（见GB/T25000.2一2018中评价 待组的角色和GB/T25000.2一2018的附录中的质量评价项目计划模板）。评价计划宜包括以下： a）软件产品质量评价的目的：

b 参与评价的组织，如独立评价组织、软件产品开发方和需方组织单位； c） 评价预算； d) 期望来自评价的信息产品； e） 评价里程碑计划表； f) 参与评价的各方责任； g） 评价环境； h） 评价方法和工具； i 软件产品质量测量判定准则； j 软件产品质量评价判定准则； k） 采用的标准； 1） 评价活动。 在早期评价期间，评价计划的某些项目只能在高层次上定义。因此，评价计划应随着评价活动的发 展而修订，并提供允许该计划调整或细化的补充信息。 注3：在连续的评价活动和任务中，高层次的评价计划逐步细化为详细层次的计划

本活动的输人宜包括： 详细的软件产品质量评价计划； b） 软件产品质量评价需求规格说明； c 软件产品质量需求规格说明； d 已选定的质量测度规格说明； 软件产品质量测度判定准则说明； f) 软件产品质量评价判定准则说明： 软件产品质量评价方法说明； h) 待评价的软件产品（包括中间软件产品）。 本活动的输出宜包括： a） 软件产品质量测量结果； b）评价结果

6.6.3应用质量测度判定准则

软件产品质量测度的判定准则应用于测度值。

6.6.4应用评价判定准

判定准则的集合应归纳为特性和子特性，产 评价结果宜： a) 建立一个软件产品能够符合评价需求的合适置信度； b) 确定关于评价要求的任何具体缺陷和确定这些缺陷范围所需的任何额外评价； c) 确定对软件产品使用的任何特殊限制或条件；

判定准则的集合应归纳为特性和子 平价结果宜： 建立一个软件产品能够符合评价需求的合适置信度； b 确定关于评价要求的任何具体缺陷和确定这些缺陷范围所需的任何额外评价； c） 确定对软件产品便用的任何特殊限制或条件：

d）确定评价本身的任何弱点或遗漏，以及需要的任何额外评价； e）确定评价未覆盖的软件产品使用的任何选项。 注：“应用评价判定准则"任务是一个对软件产品质量的综合评价，而不是软件过程评估。评价结果可用于支持管 理决策，因为总结的质量是与诸如时间和成本等其他方面相比较的。管理决策包括软件产品的接受或拒绝，或 软件产品的发布或不发布

6.7.1 输入和输出

本活动的输人宜包括： a） 软件产品质量评价需求规格说明； b) 软件产品质量评价计划的实施结果； 软件产品质量评价方法说明； d）评价结果。 本活动的输出宜包括： a）软件产品质量评价报告，

本活动的输人宜包括： a）软件产品质量评价需求规格说明； b) 软件产品质量评价计划的实施结果； c）软件产品质量评价方法说明； d）评价结果。 本活动的输出宜包括： a）软件产品质量评价报告

6.7.2评审评价结果

评价方和需方应对评价结果进行联合评审

评价方和需方应对评价结果进行联合评宜

6.7.3编制评价报告

根据评价报告的预期使用，宜包括下列项目： 软件产品质量评价需求； b） 软件产品质量需求； 软件产品质量评价计划； d 实施测量和分析的结果； e） 中间结果或解释判定，当评价计划有规定时： f 评价活动中的任何限制、约束、不足或例外，包括后续它们对于软件产品的使用、配置、修改或 一般性维护的影响； g） 评价方及其资质； h 评价产品版本之间的任何差异，以及相应的评价输人；即文档或课程； 不足情况下的解决方案或变通方法； 能够重复或再现评价的任何其他必要信息； k）评价结果， 注1：附录C给出了评价报告编制的参考模板 作为评价活动的分析结果，评价报告宜确定： 每一个缺陷、任何相关的分析，以及每一个缺陷如何被解决。缺陷的解决可能包括如下事实 1） 其中一种评价方法为该缺陷不是主要缺陷提供了保证； 2） 某个令人满意的“变通方法”被发现是可以缓解缺陷的影响；例如，对产品的修改，禁用或 删除不需要的功能性，利用逆向工程再生遗漏的设计需求； 3） 最初的需求并非强制的，并且该缺陷是可以被接受的； 4） 如果软件产品的使用将会被特定条件或限制所控制，则该缺陷是可以接受的； 5 需要进行额外的评价工作，以解决评价中的不足或差距。 b）为解决任何已查明的缺陷而进行的任何额外评价：

1）确定某个缺陷的范围或影响； 2）建立没有缺陷的信心； 3）验证某个变通方法在技术上是可行的和/或合适的和可接受的； 4）一旦某个设计更改或一些更改已经被用于纠正缺陷时，验证该软件的正确和可接受的 性能。 c 在有必要限制或控制软件产品使用的情况下，该限制是否： 1）干扰软件产品符合应用程序强制性要求； 2）影响应用程序的设计、预算和时间表； 3）需要额外的评价工作； 4）引入应用程序中失败的任何可能性， d 任何评价范围和/或每个评价结果限制的除外，如： 1）“这个评价不包括对产品功能性的详细检查。”； 2）“假如产品的所需功能性全面评价成功完成，则这个软件产品被视为符合所需的完整性 级别。”。 e）全部评价活动的综合结果，允许给予软件产品的评价一个总体结论。 注2：大量的操作历史可以弥补一个缺陷软件工程过程。 对评价报告的结论应予以处理，并列入报告的最终版本

6.7.4评审质量评价并向组织提供反馈

评价方应评审评价结果和评价过程、指标和应用测度的有效性。应使用评审的反馈意见，以提高评 价过程和评价技术（评价模块）。当有必要改进评价模块时，宜包括额外指标的数据收集，以便在今后使 用中验证它们。 注：质量评价评审和反馈在GB/T25000.2中有描述

6.7.5处置评价数据

当评价完成时，数据和评价项目应根据请求方的需求进行处置。 根据数据类型应按以下的方式之一处置： 提交评价的文档应返回给请求方，或者以某个指定的时间段存档，或者以某种安全的方式 销毁； b）在某个指定的时间段，评价报告和评价记录应存档； 所有其他数据应以某个指定的时间段存档或以某种安全的方式销毁。 对于一些数据，当指定的归档时间段过期时，则应再次以某个指定的时间段存档或以某种安全的方 销毁。

与GB/T18905.1一2002中评价过程的对比

本部分修订了GB/T18905.1一2002中的评价过程，其主要技术差异如下： a）标准术语部分作了调整、修改、增删和补充。 D 标准提出了软件产品质量评价参考模型电力弱电施工组织设计，该模型要求每个评价过程应包括评价输入、评价约 束、评价资源和评价输出。 标准用角色的概念重新梳理了需方、开发方、独立评价方、维护方、操作方、供方等内容。 d）标准在评价过程中增加了“结束评价”活动。 标准修订后章节内容变化见表A.1。

B.1是该活动的输入、输出、约束和资源的关系图

附录B （资料性附录） 活动的输入、输出、约束和资源的关系图

图B.2是该活动的输入、输出、约束和资源的关系

图B.1确立评价需求

图B.3是该活动的输入、输出、约束和资源的关系

B.3是该活动的输入、输出、约束和资源的关系图

bs标准图B.4是该活动的输入、输出、约束和资源的关系图。

图B.5是该活动的输入、输出、约束和资源的关系