NB/Z 20289-2014 核电厂软件验证和确认计划编制指南

4.3.3.4在选择对产品作评价的技术时，宜考虑以下三种方法：

用户按口。且机八司秋1 内容、输入与输出的相对时间等。 b）硬件接口。宜分析软件产品与系统硬件部件间每个接口的逻辑特征。确定电子设备、固件、通 信设备及输出设备，然后确定这些接口的适用标准并验证当前的应用接口。 C 软件接口。宜分析与其他所需软件产品的接口（例如：数据管理系统、操作系统、或库），以 及与其他应用系统的接口。确定其它软件产品的适用标准和与其它应用系统的接口。验证软件 接口到其它应用系统软件接口的正确性

4.3.4.3规划接口分析时，应考虑

拉伸强度测试标准 接口的目的在技术上是否得到充分的和很好的理解？ 是否定义好了所有数据元素？

）接口的目的在技术上是否得到充分的和很好的理解？

NB/Z202892014

表3生命周期阶段的测试活动

4.3.5. 3.2测试计划

3.5.3.2.1测试计划清楚地说明测试活动的范围、方法、资源和进度，指出要求测试什么而不要求 侧试什么、要求执行的测试任务、责任人和风险。规划的关键点包括： 从一个测试阶段或等级到另一个阶段或等级的过渡： b) 估计测试用例数量和测试持续时间； 定义测试完成准则： d） 识别风险区域； e 配置资源。

NB/Z20289—20144.3.5.3.2.2需求阶段要执行的测试任务包括：策划以及生成系统测试计划和验收测试计划。由于这些测试试图证明满足运行概念和需求，在需求编制完成后就可开始V&V计划的编制，尽管完整的测试计划需要等到需求阶段其它V&V任务完成之后。更详细的测试程序和测试用例的准备工作在后期阶段进行。在设计阶段，系统设计文档是部件测试计划和集成测试计划编制的关键输入。测试计划编制得早，就会有充足时间来配置测试资源，并确保在实现之前识别任何不可测试的设计特性。确定方法、技术、工具是编制测试计划的一部分。从整体测试策略中得到方法。根据特定方法确定技术和工具。所选的具体方法、技术和工具由要求测试的软件类型（例如：应用软件、操作系统）、测试预算、风险评估、可用人员技能水平和可用时间决定。4.3.5.3.2.3在编制V&V测试计划时，V&V计划编制者宜回答下列问题：a）谁负责生成不同等级的测试设计、测试用例和测试程序？谁负责执行不同等级的测试？c)谁负责构建和维护测试平台？d)谁负责配置管理e)停止测试工作的准则是什么？f)重新启动测试工作的准则是什么？g)什么情况下将源代码纳入变更控制？h)哪些测试设计、测试用例和测试程序纳入变更控制？i)哪个等级的测试需要编写异常报告？4. 3. 5. 3.2. 4通常很难确定何停止测试或何时发现合理数的缺陷。事实上，希望发现全部的缺陷可能是不切实际的。因此，宜提供完成准则作为测试完成的指导。至少有两种常见类型的完成准则：第一种准则是测试用例完成，要求执行所有测试用例且未发现缺陷：第二种准则是故障预测。例如，由于测试的目的是发现缺陷，所以第二类准则可以是测试到发现了预定数量的缺陷（或反之，成功执行了一定数量的测试)为止4.3.5.3.3测试设计在设计阶段，测试计划完成之后应进行测试设计开发。测试设计细化测试计划的方法、确定所要求测试的特性、规定相关的测试用例和测试程序。只要有可能，测试宜设计成适应回归测试，即之前执行和验证过的测试能够在开发的后续节点或已安装系统维护期间重复执行。开展测试设计时，应考虑a)测试的所需特性b)规定的质量属性；c)负荷限值；d)强度测试；e)软件需要支持的配置；f)与已有或所规划系统部件的兼容性；g)系统的信息安全性；h)软件及其相关数据的存储容量限值；i)性能（例如：精确度、响应时间、吞吐量）：)可安装性，主要考虑在用户环境的可安装性：对应于规格书中的可靠性/可用性；1)软件或数据故障恢复；m）服务性需求；11

NB/7 202892014

n）用户指南； o 可用性和可接受性的人为因素； p）与其他系统部件的接口； 9) 硬件接口。

4. 3. 5. 3. 4 测试用例

测试用例和测试程序在实现阶段编制。测试用例规定了实际输入值和预期结果。测试用例编制的目 标是演练部件的逻辑和建立测试环境，以揭示错误、遗漏以及非预期结果。在编制测试用例时，希望产 生最少的测试用例但仍能满足测试目的。使用一个需求与测试用例相关的矩阵有助于确定完整性和 盖。

4.3.5. 3.5测试程腐

测试程序规定了为实现相关的测试设计，对系统进行操作并执行规定的测试用例所需的所有步骤。 对测试程序的讨论见GB/T9386一2008。

4.3.5.3.6测试执行

测试执行是演练测试程序。测试执行始于实现阶段的部件级测试。其余级别的测试（例如：集成测 试、系统测试、验收测试）在测试阶段执行。

NB/Z 202892014

NB/Z202892014

5.5.3软件完整性等级

项目内存在不同的软件完整性等级时，SVVP宜说明每个部件（例如，需求、详细功能、软件模 系统或其他软件部分）相对应的软件完整性等级

宜说明V&V工作所需资源的概况。计划编制者不宜重复各项任务的资源需求，而是宜概述总的资 源需求，并宜确定潜在的资源需求冲突、长期而重要的物项、资源的低效使用和可备选资源项。如果计 划非常小，所有资源信息可以在本条中描述，而不是在任务中讨论。在一个附录中收集详细资源信息可 能很有用。 资源类型包括人工或人员、设施、设备、实验室及其配置、工具（软件和硬件）、预算和资金需求、 文档、特定程序和条件（例如：保密、访问权限和/或控制）。 a） 使用图和表作为表现资源使用的一种有效方法。对日历时间或生命周期阶段的资源使用图可快 速理解不同任务或者阶段关联的相对工作量。对日历时间或生命周期阶段的资源使用表可助于 与项目其他工作预算或需求的资源使用进行比较； b 在设备和实验室概述中包括执行全部V&V工作所需设备类型、所需使用期限、特殊配置以及 其他外围设备； c）在概述的工具部分列山整个V&V工作中要使用的各种工具。工具可细分成软件工具和硬件工 具 d）在预算和资金需求中考虑所有资源，以及应对意外情况的额外工具和人员。

V&V任务中的职责有两个层次，一个是项自中分配给不同组织单位的总体职资，另一个是执行任 务的具体职责。总体职责概述可在SVVP的本节或项目其他级别的计划（例如项目管理计划）中描述。 如果在其他文件：中描述，则本条宜包括相关文件内容的概述和引用。本条可描述具体职责，或汇总SVVP 生命周期阶段中定义的职贵。

5.5. 6 工具、技术和方法

描述V&V方法、工具、技术及其在V&V工作中的作用，可来用微述或图形形式。宣包括技术或工 具描述的参考引用。可为软件工具的获取、开发和修改编制一个单独的工具计划。在这种情况下，SVVP 中本节宜引用该工具计划。如果要获取或开发一个工具，则在V&V进度中宜包括其获取或开发的进度， 确定是否有充足的时间和适当的任务。 在策划工具、技术和方法的使用时，应考虑： a）V&V工作所选方法的描述或参考； b）要求的人员经验和培训：

NB/Z202892014

5.6.2.1.3基线变更评估

基线变更评估可能是V&V工作期间所执行的最动态的任务。任何变更建议可能会影响之前完成的 大量开发工作和V&V工作。V&V任务宜对变更进行检查，以确定因变更所需重新执行的V&V工作的性 质和范围。由于各种变更不是同时产生的，SVVP不能事先对任何这类变更评估进行详细策划，但应能 够为变更建议发生时的资源配管提供总体指导

NB/7202892014

从事先对评审包的分析中提出问题； 评估Y&V对评审中所讨论变更的影响

5. 6. 3采购过程

5. 6. 3.1概述

采购过程从获得系统、软件产品或软件服务的需求定义（例如需求说明）开始，持续到询价（或招 示）的准备和发布、供应商的选择、采购过程的管理，直到系统、软件产品或软件服务的验收。 根据采购过程确定V&V工作范围、规划供应商与采购方的接口、评审询价中所包括的系统需求初 稿、提供V&V任务结果支持采购方验收系统。在验收测试和安装完成后采购方的系统验收即告结束。 V&V采购支持活动贯穿王整个软件生命周期，与其他相关开发和V&V任务、输入和输出相配合。

5.6.3.2采购支持V&V

来购支持V&V活动涉及项目的启动、询价、合同准备、供应商监督、验收与结束。V&V工作应执 行图1中的如下任务： a)确定V&V.T作范围： b）规划供应商与V&V工作接口： ）系统需求评审； d)验收支持。

5. 6. 4. 1概述

供应过程从决定准备方案问复客户的询价或与采购方谈判、定案、签订提供系统、软件产品、软件 服务合同开始，然后继续确定项目执行流程和项目管理所需的和资源，包括制定项目计划、计划的执行 直至交付系统、软件产品、软件服务给采购方。 供应V&V工作是在合同签订前用供应过程的结果来确认询价的需求与合同需求保持一致并满足用 户需求。V&V计划的编制活动应按照合同（包括进度表）的要求修改和更新供应商和采购方的接口计 划。

5.6.4.2供应过程的V&V

V&V活动规划阐述开始、回复准备、合同、编制计划、执行和控制、评审、评估、交付和完成等 活动。 V&V工作应按照软件完整性等级，执行其等级所对应的最小任务。图1中任务包括： a）规划供应商与V&V工作的接口； b）合同验证。

5.6.5.1概念阶段V&V

5. 6. 5. 1. 1概迷

SVVP宜确定下列内容： a）概念、SRS和接口文档的格式及其发布组织： b） 作为需求规格书的一部分，确定索引和交叉引用方案以便于可追踪性分析； C）从叙述文件中摘录和确定单个需求的原则； d）SRS的验收条件，包括发布给配置控制的原则。 可能有些需求不能直接追踪到其他文件。每个后续开发阶段会产生新的信息，这些信息必须追踪到 随后阶段，但在之前的规格书中未明确提出或仅仅是隐含（例如：任务的并发执行、标准的错误恢复 序）。其中的一些要求可由SRS提出，而不是在概念文件中提出。宜在可追踪性矩阵中确定和包括所有 行生的满求。 SVVP宜规定在本阶段其他V&V任务完成之前确定SRS的可追踪性。如果需求的可追踪性分析是不 完整的，则评价SRS、进行接口分析、或规划测试是不确定的。尽管这些其他V&V任务可与可追踪性 分析同时执行，但在SRS的所有要求已被追踪之前，不能认为可追踪性分析已完成。

5.6.5.2.3软件需求评价

软件需求评价的目的是评估需求的技术特征、确定需求是否满足概念阶段定义的软件目的，并确保 规格书的正确性、完整性、清晰和一致性；另一个目的是确定是否缺失任何需求。当一个需求可绝对度 量时（例如：响应时间），则确认该需求对相关度量的正确性。评价宜确认需求在技术上的适当性。评 价SRS以确保所有需求对于自的准则是可测试的。 根据SRS的范围和复杂性，可能需要进行多项评价。每项评价会针对特定目的，可使用特定的技术 并由特定的人员参与。需要确定一个策路，以协调一份SRS的多次评价并汇总其结。 此外，评价的进度安排可能取决于其他评价需要使用的SRS特定部分的可用性。实际上，通常会有 多项工作同时进行，这些工作分别使用SRS的某些部分或使用未经确认的版本，以继续进行更详细级别 的开发（例如高层设计）或与之接口产品的开发。尽管如此，所有借况下，宜定义此类工作的限度

.2.4软件需求接口分

需求接口分析的目标是确保对软件的所有外部接口和软件功能间的内部接口已作了完整和正确规 定。随着软件复用和标准软件部件使用更为频繁，内部接口分析的重要性有所增加。 根据SRS的形式和是否有工具可用，接口分析可采用手动或自动的方式进行。宜提供机制以确保： 接口数据的来源和接收者得到准确描述： 通过接口发送和接收数据的协议是准确和完整的 SRS对接口的规定与接口的文档是一致的。 需求接口分析中，除了SRS，宜包括描述外部接口的文件，例如接口定义文件、数据字典及相关的 SRS文档，也宜包括分析单独求间内部接口的技术。 宜规定接口文档的接受（包括发布到配置控制）准则。准则包括为确保可追踪性的格式符合性指导， 全部不完整需求（例如待定项）的完整解决方案计划、完成接口分析的提示

5.2.5系统测试计划生成和验收测试计划生成

需求阶段进行的与V&V测试任务有关的工作包括规划和生成系统测试计划和验收测试计划。因为 这些测试的目的是为了证明满足运行概念和需求，因此，在编制需求后就可开始规划测试计划，但完整 的测试计划要等到需求阶段其它V&V任务完成之后才能完成。更详细的测试程序和测试用例的准备工 作在后期阶段进行。

NB/Z20289—2014用于可追踪性分析和接口分析的信息矩阵或其它组织形式的信息对系统和验收测试计划是有用的，这些信息的设计宜包括对测试计划和测试程序的引用。测试计划宜经过评价和验证，以确保全部计划的条件和所开发软件的特性都经过充分测试从而满足V&V自的。系统测试主要目标是确认软件、概念文件和系统规格书中无缺陷和遗漏。可能需要对特定部分的测试（例如：性能、信息安全性、可靠性、可用性）进行规划。验收测试主要目标是用户确认软件符合预期，这些预期反映在运行概念、功能需求和质量属性等方面。验收测试的另一个目的是确定软件能够成功安装并能被预期用户操作、有适合的文档且可维护。如果有可能，建议用户或用户代表参与相应验收测试计划的编制。除了总体测试需求之外，系统和验收测试计划还宜确定下列事项：一系统测试所需的全部输入文档及传递这些文件给V&V人员的协议，这些文件宜包括系统需求规格书、接口需求文件、运行环境和用户手册；一测试中止准则，可包括所涉及的需求部分、发现的错误数、统计的可靠性目标等；一见证测试的规定。5.6.5.3设计阶段V&V5.6.5.3.1概述设计阶段是在软件生命周期中完成架构、软件部件、接口和相关数据的设计和形成文档，并验证其满足需求的时期。在本阶段消除设计错误会大大减少后续代码中出现的缺陷，并降低生命周期后期的产品和项目风险。设计阶段V&V也间接提供了机会，可以找出之前未发现的需求中的错误的。尽管简单产品的设计在步内完成是可能的，但设计常常是多步骤的过程。第一层次设计是规定架构特性（例如，主要子系统及其接口）。后续设计步骤通过逐步细化，直到对子系统作了充分规定，可以开始软件编码为止。设计可用多种形式表达，包括文本、图形、伪代码、或这些形式的组合和其他。除了解决如何组织和构建所需系统的问题外，设计者还有广泛的质量目的需要考虑，包括：a)纵贯所有设计层次对需求进行追踪，确保无遗漏或多余；构建设计以便符合系统日的和预期产品质量属性：描述所有硬件、操作员接口和软件接口：证明设计符合所有适用标准、规范和约定；确定设计在完全集成时满足需求；设计文件的编制应使得代码编写人员和产品后期维护人员能够理解：g)设计中包含为规划、设计和执行测试所需要的足够信息：h)控制设计配置并确保所有文档的完整和交付，特别在使用混合媒介时（例如：图表、文本规格书）。满足上述目的可以保证设计中体现所有需求、设计满足需求、设计是可测试的并会形成可测试代码。V&V计划编制者的职责是为设计工作的产品（包括中间生成的规格书）选择V&V任务，以确保实际满足了这些目标。V&V计划编制者为规定特性的每个设计层次选择适合的V&V任务及其对应的方法。尽管每个设计层次的V&V任务会有重复，使用的V&V方法或技术是可以不同的。例如，一个算法选择的评价可能适合于高层设计，而该算法的数学分析可能更适合于详细设计。V&V工作范围由设计工作的复杂性决定。在规划设计阶段V&V任务时，应考虑：a）项目计划规定的职责（例如支持关键设计评审）；b）设计方法；c）设计标准；21

d) 设计的关键部分或困难部分； ) 需要证明的设计假设（或对证明的引用）； 存在需要大量分析的复杂算法； g) 需要规模和性能分析的资源约束（例如：可用的计算机硬件、时间限制）； h) 需要信息安全性分析的数据库加密和访问需求； i 设计层次（即，对于高层和详细设计，可能适合采用不同V&V任务和方法）： j 部件测试和集成测试需要采用不同的方法； k 执行设计V&V任务的组织； D 设计的媒介和格式。 V&V进度计划宜兼顾设计V&V任务中产生的意见和发现的异常。此外，可能会揭示出潜在风险。 宜更新所识别风险的清单，并宜在制定的测试计划中得到反映。

5.6.5.3.2软件设计可追踪性分析

无论使用手动还是白动的方法进行追踪，都应执行需求和设计间的双向追踪，以确保 a 需求无遗漏或重复设计： b）不存在多余的设计部分； c）由多个设计部分满足的需求是完整的和一致的。 宜对每个相互追踪关系的正确性、致性、完整性和准确性进行评估，以确保： 一需求的所有条件已被设计： 需求和设计间技术上的相互关系是正确的 所发现的需求和设计间的多个相互关系中任何一个都是必需的。

5.6.5.3.3软件设计评价

5.3.4软件设计接口3

对软件设计每个级别执行设计接口分析。在策划设计接口分析时，应考虑： a 数据项的使用（例如，输入和输出）是否一致、完整？ b) 接口是否正确、完整和必需？ 在设计部分中发送数据项的使用是否正确？ 在数据传输中，系统资源的使用是否正确？（例如，宜由引用启动的数据传输是否通过数值调 用？） e 用户接口设计是否易于理解？软件是否提供适当帮助？软仆是否检测用户错误并对错误提供 清晰的响应？ 是否为关键接口（特别是用户接口)建立了样机？若是，是否对样机进行了彻底和独立的评价？ 是否对关键特性进行了适当证明？ g 是否为有效的配置管理设计接口？ h 无接口的地方是否需要一个接口？

5.6.5.3.5部件测试计划生成和集成测试计划生成

NB/Z202892014

5, 6. 5. 3. 6 ±测试设计生

5.6.5.4.3源代码评价

依据预期风险和关键性级别，源代码评价可采用多种评价技术（例如，评审、走查、检查）进行。 在策划源代码评价时，应考虑： a 通过代码部件的关键性分析确定需要评价的代码 b 确保代码编写标准可理解； 确保在编写代码之前，代码编写标准对于人员是可用的； 确定如何评价代码质量属性； e）确定能用的代码分析工具。

NB/Z 202892014

5.4.4源代码接口分析

5.6.5.4.4.1源代码接口分析的目的是评估各部件间和部件内的信息流和控制流。本任务可结合源代 码可追踪性分析的结果使用。本任务的输出是描述部件接口的不一致性和错误。对于发现难于在测试中 隔离的错误，接口分析很有效。这些错误的实例是： a）引用了但未定义的软件组件； b）定义了但未引用的软件组件： c）不正确的参数个数； d） 数据类型不匹配； e 数据限制不匹配； 其他数据使用异常； g 控制流不一致。 5.6.5.4.4.2在策划源代码接口分析时，宜考虑： a） 物理单位精度： b）同等参照物； c）粒度： d）控制流； e） 定时需求； f 数据传输： g）命名约定。

5.6.5.4.5源代码文档评价

针对源代码评价源代码文件的目标是确保文档正确反映源代码的实际实现。代码相关文作可包括程 序支持手册、用户手册和运行手册。由于生命周期阶段的缘故，这些文件经常以文件草案形式出现并不 断被修改。在策划源代码文档评价时，应考虑： a）除了评审技术准确性、完整性、一致性外，也需要评审用户功能； 确保文档的编制级别对读者是适合的： C 确定文档的可用性方面（例如：索引、目录、术语、标题、格式等）没有问题： d 考虑新用户是否可使用该文档执行任务（或工作）： e 确保文档能处理错误纠正过程； f 确保有后续工作完成草本文件。

5.6.5.4.6测试用例生成

5.6.5.4.7测试程序生成

NB/7202892014

关于测试程序的总体讨论参见4.3.5。关于测试程序编制的进一步讨论见GB/T9386一2008。

5.6.5.4.8部件测试执行

5. 6. 5.5.2验收测试程序生成

验收测试程序规定一组测试用例的执行步骤，用于对软件项进行分析以评价一组特性。对测试程序 的总体讨论参见4.3.5。对测试程序的进一步解释见GB/T93862008

5.6.5.5. 3测试执行

5. 6. 5. 5. 3. 1概述

NB/Z202892014

5.6.5.5.3.2集成测试热行

G. 5. 5. 3. 4 验收测试我

5.6.5.6安装与调试阶段V&V

5. 6. 5. 6. 1 抵述

5.6.5.6.1.1安装与调试阶段是软件生命周期中软件产品集成到其运行环境中，以及通过测试以确保 其按要求执行的时期。安装的特征包括安装人员、安装过程持续时间、安装现场的数量、系统的版本号 及其配置的充分性。 安装程序将完整和经测试过的应用程序置于满足用户对该系统使用要求的运行环境中。有时该过程 独立于开发，并由不同于开发和测试该应用程序的组织执行（例如，由现场或客户支持工程师）。某些 清况下，安装及调试由软件最终用户执行。有时安装发生在最初交付的系统上添加一个或多个子系统， 在每次安装后都应进行用户验收测试。在提交验收测试之前，每个子系统宜与之前的子系统适当集成。 安装可能需要重复无数次，每个软件版本在每个场地都要重复一次安装。一个产品可能需要针对每 个现场进行大量裁减（例如：设置现场相关的参数、构建现场相关的命令表）。每个现场可能有不同的 安装程序。 安装与调试V&V程序能确保： 每个现场相关的配置是正确的和完整的： 每个现场的安装指导对配置的说明是确的和完整的 所编制的安装指导对预期安装人员的专业水平是适当的： 面向用户的检验测试能充分证明安装是令入满意的： 交付安装的软件与通过V&V的软件是完全相的

NB/Z20289—2014安装和调试V&V的职责可以在开发组织和用户组织之间分割。用户可以在安装中起主要作用。分配给用户组织的V&V活动宜充分定义并形成文档。可以进行一次预安装V&V以确定并验证在安装中的用户V&V程序。由于上述种种原因，规划安装与调试V&V进度可能是困难的。如果该软件应安装在很多现场，可能有必要提前制定一个安装总体进度，再针对每个具体安装根据时间或资源要求进行调整。一个程序流程图或检查单可能有用。5.6.5.6.1.2在编制安装与调试V&V计划时，应考虑：a）验证准确性和完整性。采用准确性和完整性控制确保在安装之前、期间及之后数据的完整性。例如，如果重新规定一个数据文件的格式，则宜规划一个测试以证明重定格式以后文件的完整性是得到保证的。如果需要维护控制的全部，则宜对照最初控制对最终控制进行验证；维护和验证安装评审跟踪。验证已记录所有在安装期间发生的过程和变更；c)确保之前系统的完整性。多数情况下，所安装软件是现有系统的一个替代。验证安装过程允许现有系统继续运行直到正式接受和宣布运行新系统为止。某些时段可能有必要同时运行两个系统，或在新系统出故障时维持旧系统；d）验证符合安装或调试标准。确保安装和调试是按照适用标准、规程和指南执行的。5.6.5.6.1.3安装与调试V&V经常使用的可选任务包括但不限于下列几个方面：a）回归分析与测试，评审安装和调试中产生的变更。回归分析与测试验证影响程序其他部分的基本需求和设计假设未受违背：b)仿真。测试操作员规程，仿真测试也有助丁甄别任何安装问题。在要求交付多个现场相关的软件版本时，此技术在交付前可能特别有用：c）测试认证，测试认证用以（证明软件产品（尤其在关键系统中）与经过V&V的软件产品是完全相同的。在安装完成之前产生所有安装测试结果是很重要的，此测试（或调试)的目的是确定安装是否成功。同其他测试一样，通常意味着在测试开始之前就宜预测测试结果。5.6.5.6.2安装配置审核安装配置审核可分为三个子任务：a）配置审核，确定安装包中有为正确安装和运行软件所需的所有软件产品。安装包通常包括一份安装计划及调试程序、案例、预计结果、源代码清单和其他开发文档、操作员指导、最终用户文档。b）现场相关参数分析，验证软件已针对安装现场进行了适当裁剪，为此可能需要对针对现场裁剪软件的参数值、指令表、配置文件或其他方式进行分析和验证。如果有针对现场开发的代码，则不管它是为安装而开发的，还是作为操作系统的一部分（例如：设备驱动程序）而开发的，均宜在开发过程中进行V&V。c）确证分析，验证所安装软件与开发期间经过V&V的软件一致。可能需要通过审核跟踪检查、文件比对或其他方法，以证明所交付软件与经过V&V的软件是相符的。5.6.5.6.3V&V最终报告生成尽管在整个软件生命周期中都应执行V&V，但投运之前的V&V工作可以随着软件安装与调试完成而结束。投入运行之后，另外的组织会执行维护期间的V&V，这需要文档和职责的交接。在前期V&V完成之后，均宜编制一份V&V最终报告，汇总V&V工作的活动和结果。SVVP的第5.7部分规定了最终报告的格式。报告有下列用途：27

NB/Z 202892014

a）作为系统维护V&V的起点： b）可作为项目人员获取经验教训的载体或改进后续项目开发过程或V&V过程的途径： c）引起对开发、安装或运行中重要未解决异常的注意。 通常最终报告的编制可通过查阅和总结V&V工作过程中编制的任务报告、异常报告和阶段性总结 报告进行。

5. 6. 6 运行与维护过程

5. 6. 6. 1. 1概述

5. 6. 6. 1. 2 SVVP 修订

NB/Z 202892014

这些可选报告可能是一些特殊V&V研究的结果，也可能是预期活动之外其他活动的结果。由于这 些报告风格各异，对其格式和内容无特定的指导。与所有V&V报告一样，可选报告也要求及时和正确 发布。报告宜确定V&V活动的目的，描述所使用的方法，汇报其在相应级别上的结果。

工程计价标准规范范本NB/Z202892014

一具有批准发布异常报告的职责和权限的人员。 有些情况下，V&V活动与软件质量保证活动一起执行，例如，V&V人员提供审核支持、出席评审 会议、监督测试。在这些情况下，SVVP宜规定V&V异常报告是否需要重复其他组报告的问题。例如， 如果V&V人员监督测试并认为测试组织的测试事件报告已充分，则不必为该测试提供一份单独的V&V 异常报告。然而，测试人员提供的报告有任何不充分的情况时，则是V&V异常报告的课题。

5. 8. 2.3异常报告分发

SVVP应包括一个异常报告的分发清单。宜清晰规定异常报告的分发计划，包括每份报告提交给谁、 在何种情况、因何种原因。 报告宜分发给需要相关信息、需要追踪和需要行动的人。如果报告的分发基于优先权，则宜规定优 先级并建立分发准则。 分发清单依赖于V&V工作的组织和独立程度。例如，如果执行V&V任务的人员独立于开发组，则 异常报告宜分发给开发组和用户（或开发组的更高管理层）

航空标准5.8.2.4异常解决的方法与准则

异常的解决可能导致文档、软件或硬件的变更。异常的解决可作为一项复杂的、主观的且消耗资源 为任务。 每一项关键异常都应得到妥善解决之后，V&V工作才可以正式进入到生命周期下一个阶段。 SVVP应规定确定异常关键性及其影响的程序，以及解决异常报告提交者与负责解决异常的人之问 异的程序。 SVVP中宜规定异常报告相关的职责和授权，宜包括： a）响应异常报告的职责； b）.评价响应与解决异常的授权； c）追踪异常报告状态（未解决、已解决）的职责。 为更有效，此处的职责与授权的规定应与SVVP中其他地方定义的组织和职责一致。（见5.5.5和C.8）

5. 8. 2. 5时间