GB／T 25000.40-2018标准规范下载简介

GB／T 25000.40-2018 系统与软件工程 系统与软件质量要求和评价(SQuaRE) 第40部分：评价过程.pdf简介：

GB/T 25000.40-2018，全称为《系统与软件工程 系统与软件质量要求和评价(SQuaRE) 第40部分：评价过程》，是中国国家标准化管理委员会发布的关于系统与软件质量管理和评估的标准。该标准主要针对软件开发和维护过程中的质量评价，它提供了一个框架和方法，用于系统和软件的质量评估、测量和报告。

该部分详细描述了如何对系统和软件的质量进行评估，包括但不限于软件的可靠性、可维护性、效率、性能、安全性、可扩展性、用户友好性等方面。它强调了质量评价过程的重要性，包括制定评价计划、执行评价活动、收集和分析数据、生成评价报告，并提供了如何根据评价结果改进软件质量的指导。

标准的目的是帮助软件开发和维护团队更好地理解质量要求，确保他们的产品或服务符合用户和业务的需求，提高整体的软件质量，并促进持续改进。它适用于软件开发过程的各个阶段，包括需求分析、设计、实现、测试和维护等。

GB／T 25000.40-2018 系统与软件工程 系统与软件质量要求和评价(SQuaRE) 第40部分：评价过程.pdf部分内容预览：

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

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

本附录给出了评价报告的结构和内容的指导意见。它总结了在本部分中的6.7.3阐明的报告要 求。此外，在报告中还需要纳人一些辅助信息。 以下的章节描述了评价报告各部分的内容

评价报告的本节包含所执行评价有天的标识信息。 评价方标识 本条包含了有关评价方的下列信息： a）评价方组织的名称； b）评价方组织的地址； c） 已执行评价的地点（如果与上述地址不同）； d） 负责评价的人员姓名。 评价报告标识 本条包含了有关报告的标识： a）报告的唯一标识（如序号）； b）报告中的页数。 此信息被复制到报告的每一页上。每个页面都是唯一标识的，例如通过使用某个页号 请求方和供方的标识 本条包含了有关评价的请求方和被评价软件产品供方的下列信息： 请求方组织的名称； b 请求方组织的地址； 软件产品供方的名称（如果与上述名称不同）； 软件产品供方的地址（如果与上述地址不同）

评价报告的本章包含了本部分6.3中所描述的评价需求。特别是，它包含了： a）产品应用领域的一般描述； b）产品用途的一般描述； c）被评价的质量需求和产品信息的列表《户外严酷条件下的电气设施 第5部分：操作要求 GB 9089.5-2008》，可能包括质量特性和评价级别的参考。

评价报告的本章包含了本部分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 软件产品已经经过至少一次重大修订，并且在该修订上应该有可用的运营历史数据。这是基 于假设，软件产品的质量将取决于其已经通过优化的程度。 软件产品用户有一种途径是将缺陷报告反馈给供方，且有证据说明这种情况正在发生，以及由 此产生的处理正在被执行

《泵站设计规范 GB50265-2010》F.5与客户评审操作历史

上获得的效果也许与从原型或甚至更加广泛的试用中获得的一样有用。进行评审最简使的方法是在客 卢的操作场所采访客户，并且甚至可能查看演示或支持记录 评价方与顾客进行操作历史的评审： 建立应用程序与所推荐应用的相似度； b） 试图查看操作中的软件产品或得到其他支持证据； 询问表单上的客户和由供方提供的支持质量； d）确定无错操作的数量

E.6供方能力、支持和质量体系的评审

F.7原型评价及其他评价方法

c）利用与可用的推荐应用程序相关的历

利用与可用的推荐应用程序相关的历史数据

GBT 51368-2019标准下载EF.7.2其他评价方法

评价技术可以与评价水平和软件质量特性（参见附录B)有关。 评价级别可以对应软件的完整性级别。 附加的评价方法包括： a 软件体系结构设计的分析（维护性）； b） 软件的故障树分析（可靠性）； C 基于统计随机使用的软件产品测试（可靠性）； d） 用于检查语法和语义正确性的动态代码分析（可靠性）； e） 软件设计的危害分析（可靠性）； f 软件需求规格说明的评审（功能性）； g） 代码检查（功能性）； h 软件黑盒测试（功能性）； i） 基准测试（性能效率）； 需求可追溯性分析（维护性）； K 组件之间在接口处的模拟故障（可靠性）。 对于高完整性的复杂软件，软件设计的故障树分析或危害性分析可以用来隔离“关键”的软件模块 行评价，对应用程序完整性没有影响的软件，可免除严格评价的需要