GB／T 25000.40-2018标准规范下载简介
GB／T 25000.40-2018 系统与软件工程 系统与软件质量要求和评价(SQuaRE) 第40部分：评价过程.pdfd）确定评价本身的任何弱点或遗漏，以及需要的任何额外评价； e）确定评价未覆盖的软件产品使用的任何选项。 注：“应用评价判定准则"任务是一个对软件产品质量的综合评价，而不是软件过程评估。评价结果可用于支持管 理决策，因为总结的质量是与诸如时间和成本等其他方面相比较的。管理决策包括软件产品的接受或拒绝，或 软件产品的发布或不发布
6.7.1 输入和输出
本活动的输人宜包括： a） 软件产品质量评价需求规格说明； b) 软件产品质量评价计划的实施结果； 软件产品质量评价方法说明； d）评价结果。 本活动的输出宜包括： a）软件产品质量评价报告DB11／T 1668-2019标准下载，
本活动的输人宜包括： 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是该活动的输入、输出、约束和资源的关系图
图B.4是该活动的输入、输出、约束和资源的关系图。
图B.5是该活动的输入、输出、约束和资源的关系
本附录给出了评价报告的结构和内容的指导意见。它总结了在本部分中的6.7.3阐明的报告要 求。此外，在报告中还需要纳人一些辅助信息。 以下的章节描述了评价报告各部分的内容
评价报告的本节包含所执行评价有天的标识信息。 评价方标识 本条包含了有关评价方的下列信息： a）评价方组织的名称； b）评价方组织的地址； c） 已执行评价的地点（如果与上述地址不同）； d） 负责评价的人员姓名。 评价报告标识 本条包含了有关报告的标识： a）报告的唯一标识（如序号）； b）报告中的页数。 此信息被复制到报告的每一页上。每个页面都是唯一标识的，例如通过使用某个页号 请求方和供方的标识 本条包含了有关评价的请求方和被评价软件产品供方的下列信息： 请求方组织的名称； b 请求方组织的地址； 软件产品供方的名称（如果与上述名称不同）； 软件产品供方的地址（如果与上述地址不同）
评价报告的本章包含了本部分6.3中所描述的评价需求。特别是，它包含了： a）产品应用领域的一般描述； b）产品用途的一般描述； c）被评价的质量需求和产品信息的列表，可能包括质量特性和评价级别的参考。
评价报告的本章包含了本部分6.4中所描述的评价说明，特别是，它包含了
a 评价的范围，参考产品描述；当产品描述不是公开可获得的文件，则将其附于报告后； b 评价需求所要求的信息和产品组件之间的互相参照； C 测量和验证说明； d）测量和验证说明和评价需求之间的映射
评价的范围，参考产品描述；当产品描述不是公开可获得的文件，则将其附于报告后 b） 评价需求所要求的信息和产品组件之间的互相参照； 测量和验证说明； d）测量和验证说明和评价需求之间的映射
评价报告的本章包含了本部分6.5中所规定的用于执行评价的评价方法文档。当评价方法被记录 在其他地方时，允许简单地包括一个参考指向那个文档。 注：当评价方法是一个标准（评价模块）或专有的，通常会使用评价方法的参考。 对于每一个收录在此的评价方法，提供了在产品组件上已应用该方法的标识
评价报告的本章包含了本部分6.7中所描述的评价结果，特别是，它包含了 a）评价结果本身： 必要时的中间结果或解释决策； 在评价期间使用工具的参考
当评价实施与软件产品开发同步进行时，评价过程参考模型的活动和任务可关联为软件生存周 程（ISO/IEC12207）和/或系统生存周期过程（ISO/IEC15288）的一部分任务和活动，具体过程 D.1
表D.1软件产品质量评价参考模型与软件和系统生存周期过程之间的典型关系
产品评价可能相关的工作的例子： 确立评价需求： a）评价目的可与项目目标一致； b）评价计划可针对需方与供方之间的谈判协议进行开发； c）评价计划可与质量管理流程相协调，或定制于质量管理流程； d）评价需求、评价范围和严格程度可在需求定义期间获得 规定评价： 评价可通过选择贯穿测量计划活动的测度来规定。 设计评价： 用于验证和确认的评审、集成和测试的计划，可用于设计软件产品质量评价。 执行评价： 评审、集成和测试的性能和结果可用于进行测量、评定测量值以及评估执行评价的结果 结束评价： 验证和/或确认的结果可用于准备和创建评价报告，和/或结果可递交传达至测量用户
由于在质量特性通用说明上，包括有关子特性和待评价案例的测度上似乎很难达成共识，评价需求 可为选定的质量特性规定评价级别。 评价级别与GB/T18492一2001中定义的软件完整性级别有关联。如果某个软件完整性级别分配 给某个已提交评价的软件产品，则该软件完整性级别可用于选择评价需求。特别是，与软件完整性级别 相关联的严格度可用来作为选择评价技术的指南。 一方面，评价级别与请求方对一个给定特性的重视程度有关。所选择的级别对于软件产品的假定 更用环境（如安全条件、安全约束、经济风险、应用约束）应该是有意义的。 另一方面，某个评价级别根据待应用的评价技术和待获得的评价结果来定义评价的深度或完全性。 因此，各级评价给出了软件产品质量不同的置信水平。每个特性可以独立选择相应的级别。 本附录提出命名为A、B、C和D四个级别。这些级别构成一个A作为最高级、D作为最低级的层 次结构。在A级，采用最严格的评价技术（考虑到合理的工作量和时间尺度）给予最高的信心，下降至 D级，所使用的方法严格性逐步减少，因而通常致力于评价的努力也减少了。 对于一个大产品的不同组件，每个软件特性的评价级别可能会发生变化（例如，很可能高可靠性要 求的关键组件要与系统的其他组件分开）。 E.2提出了选择评价级别作为产品使用周境功能的指导意见，E.3给出有助于选择评价技术的 参考。
可以针对每个相关的质量特性独立选择评价级别。在选择级别时，应考虑几个方面。例如，在适当 的时候，重要的是那些与产品的安全、经济、保密、环境以及市场营销有关的方面， 对于某个相关的质量特性，产品与该特性有关的需求不一致所涉及的风险和后果，以及高质量的效 益，应从所有相关方面进行评估。对于其中某些方面，表E.1、E.2、E.3和E.4提供了风险和待选择级别 之间的关系示例。当需要考虑多个方面时，应选择最严格的级别。 对于经济风险和市场效益问题，应考虑评价的成本
表E.1关于安全方面的评价级别示例
表E2关于经济方面的评价级别示例
表E.3关于保密方面的评价级别示例
表E.4关于环境有关方面的评价级别示例
E.3从评价级别中选择评价技术
为了详细制定集 和评价级别可被选择出的评价技术。针对每个质量特性，以下提出了一个从低要求级别到高要求级别 排列的技术评价清单， 功能性： a）功能性或黑盒测试； b）根据清单的开发文档的检查； 依据测试覆盖准则的单元测试。 性能效率： a）执行时间测量； b）基准测试； ） 确定算法复杂度的设计分析。 兼容性： a） 使用环境分析； b）潜在系统和接口验证； 32
c）软件需求分析。 易用性： a） 用户界面和文档检查； b) 接口标准符合性验证； 与真实用户进行使用实验。 可靠性： 特定编程语言工具的使用验证； b 软件设计和代码中的容错构造分析： 可靠性增长模型。 信息安全性： a） 软件部署环境分析； b）代码安全规则库检查； 软件安全设计分析。 维护性： ） 依据清单的开发文档的检查； b) 代码测度和编程规则验证； 开发文档元素间的可追溯性分析。 可移植性： a） 软件安装程序分析； 编码规则验证； C 软件设计分析
.1用户和技术产品文档《包括在线文档）的评审
产品文档可以提供所有必要的信息，以做出功能性和易用性，以及其他如移植性和可维护性需求的 评价。可不通过实际购买而有可能获得相关的软件产品文档，即通过借用文档或者购买文档集。虽然 对软件产品文档进行评审可能没有参加课程或培训有效，但它可能是最经济的，特别是如果评价方有相 关的专业知识
E.2基于供方课程与培训的评价
许多针对软件产品的产品课程，可通过供方，或第三方提供。在软件产品没有课程提供的情况下， 可能会安排有经验的用户或软件产品开发方进行专门的培训。产品课程或培训提供的好处是允许评价 方专注于特定领域，并在短时间内获得软件产品功能性和易用性的具体信息。通过评审软件产品的文 档可能会获得相同的信息，但可能会耗费更多的时间。课程或培训的额外费用需要与获取信息的效率 和课程材料的通用性相权衡
E.3软件工程过程的评估
建议以分阶段的方式对软件工程进行评审。当软件的完整性级别被认为是不需要软件工程过程进 行全面评价时，评审可以在第I或第Ⅱ阶段之后停止
E.4与供方评审运营历史
与供方对运营历史进行评审，可以提供一种非常有效的方法来表明软件产品的质量。就是通过评 审软件产品的销售数据和被使用在行业和应用中的细节来实现的。该评审还涉及软件修订的历史、维 户修订的方式、处理客户缺陷报告的方式和已知缺陷的详细信息。进行评审最简便的方式是通过对供 方的工程、销售和客户支持人员进行面谈，并检查任何支持的记录
E.4.2运营历史需求
产品运营历史需求如下： 销售数据至少在六个月以上，即在评价中使用的销售数量只包括在评价发生前六个月售出的 销售额。该准则基于的事实是，软件产品可能需要长达六个月的时间进行交付、安装、委托及 投入服务。 b 软件产品已经经过至少一次重大修订，并且在该修订上应该有可用的运营历史数据。这是基 于假设，软件产品的质量将取决于其已经通过优化的程度。 软件产品用户有一种途径是将缺陷报告反馈给供方，且有证据说明这种情况正在发生，以及由 此产生的处理正在被执行
F.5与客户评审操作历史
上获得的效果也许与从原型或甚至更加广泛的试用中获得的一样有用。进行评审最简使的方法是在客 卢的操作场所采访客户，并且甚至可能查看演示或支持记录 评价方与顾客进行操作历史的评审： 建立应用程序与所推荐应用的相似度； b） 试图查看操作中的软件产品或得到其他支持证据； 询问表单上的客户和由供方提供的支持质量； d）确定无错操作的数量
GBT25637.1-2010 建筑施工机械与装备 混凝土搅拌机 第1部分：术语与商业规格E.6供方能力、支持和质量体系的评审
F.7原型评价及其他评价方法
c）利用与可用的推荐应用程序相关的历
利用与可用的推荐应用程序相关的历史数据
EF.7.2其他评价方法
评价技术可以与评价水平和软件质量特性（参见附录B)有关。 评价级别可以对应软件的完整性级别。 附加的评价方法包括： a 软件体系结构设计的分析（维护性）； b） 软件的故障树分析（可靠性）； C 基于统计随机使用的软件产品测试（可靠性）； d） 用于检查语法和语义正确性的动态代码分析（可靠性）； e） 软件设计的危害分析（可靠性）； f 软件需求规格说明的评审（功能性）； g） 代码检查（功能性）； h 软件黑盒测试（功能性）； i） 基准测试（性能效率）； 需求可追溯性分析（维护性）； K 组件之间在接口处的模拟故障（可靠性）。 对于高完整性的复杂软件，软件设计的故障树分析或危害性分析可以用来隔离“关键”的软件模块 行评价，对应用程序完整性没有影响的软件，可免除严格评价的需要
附录G （资料性附录） 评价方法的成本效益排序示例 表G.1呈现了一个与具体产品质量特性有关的评价方法的相对有效性和总相对成本的定性估计排 序。这种有效性排序假设评价是成功且以适当严格度进行的。此表可用于选择需要进行评价的目标输 人DBJ50／T-341-2019标准下载，以充分评估针对那些软件需求规格说明中规定的产品质量特性的适用性。所需的评价可用来估计 产品评价的总成本
表G.1评价方法的成本效益排序示例
成本和效益排名显示的是执行评价的相对程度