标准规范下载简介
NB／Z 20289-2014 核电厂软件验证和确认计划编制指南.pdfNB/Z202892014
表3生命周期阶段的测试活动
4. 3. 5. 3. 2 测试计划
3.5.3.2.1测试计划清楚地说明测试活动的范围、方法、资源和进度建筑防烟排烟系统技术标准(GB 51251-2017)的疑问及答疑，指出要求测试什么而不要求 试什么、要求执行的测试任务、责任人和风险。规划的关键点包括： a 从一个测试阶段或等级到另一个阶段或等级的过渡； b） 估计测试用例数量和测试持续时间； 定义测试完成准则； d 识别风险区域； 配置资源。
NB/Z202892014
4.3.5.3.2.2需求阶段要执行的测试任务包括：策划以及生成系统测试计划和验收测试计划。由于这 些测试试图证明满足运行概念和需求，在需求编制完成后就可开始V&V计划的编制，尽管完整的测试 计划需要等到需求阶段其它V&V任务完成之后。更详细的测试程序和测试用例的准备工作在后期阶段 进行。 在设计阶段，系统设计文档是部件测试计划和集成测试计划编制的关键输入。测试计划编制得早， 就会有充足时间来配置测试资源，并确保在实现之前识别任何不可测试的设计特性。 确定方法、技术、工具是编制测试计划的一部分。从整体测试策略中得到方法。根据特定方法确定 技术和工具。所选的具体方法、技术和工具由要求测试的软件类型（例如：应用软件、操作系统）、测
NB/Z202892014
n) 用户指南： o) 可用性和可接受性的人为因素； 与其他系统部件的接口； 9）硬件接口。
n) 用户指南： o) 可用性和可接受性的人为因素； 与其他系统部件的接口； 9）硬件接口。
4.3.5.3.4测试用例
测试用例和测试程序在实现阶段编制。测试用例规定了实际输入值和预期结果。测试用例编制的目 标是演练部件的逻辑和建立测试环境，以揭示错误、遗漏以及非预期结果。在编制测试用例时，希望产 生最少的测试用例但仍能满足测试目的。使用一个需求与测试用例相关的矩阵有助于确定完整性和覆 盖。
4.3.5.3.5测试程序
测试程序规定了为实现相关的测试设计，对系统进行操作并执行规定的测试用例所需的所有步骤。 对测试程序的讨论见GB/T9386一2008。
4.3.5.3.6测试执行
测试执行是演练测试程序。测试执行始于实现阶段的部件级测试。其余级别的测试（例如：集成测 试、系统测试、验收测试）在测试阶段执行。
NB/Z 202892014
为每项V&V任务分配可共同承担的具体职责（例如：接受输入、执行任务、分析结果、报告 结果、根据结果进行决策）； 在职责交叉的情况下，进行精确分配； 使用图表指示V&V工作的控制和数据流，以明确职责。
5. 5. 2 主进度
5.5.3软件完整性等级
宜说明V&V工作所需资源的概况。计划编制者不宜重复各项任务的资源需求，而是宜概述总的资 源需求，并宜确定潜在的资源需求冲突、长期而重要的物项、资源的低效使用和可备选资源项。如果计 划非常小，所有资源信息可以在本条中描述，而不是在任务中讨论。在一个附录中收集详细资源信息可 能很有用。 资源类型包括人工或人员、设施、设备、实验室及其配置、工具（软件和硬件）、预算和资金需求、 文档、特定程序和条件（例如：保密、访问权限和/或控制）。 a）使用图和表作为表现资源使用的一种有效方法。对日历时间或生命周期阶段的资源使用图可快 速理解不同任务或者阶段关联的相对工作量。对日历时间或生命周期阶段的资源使用表可助于 与项目其他工作预算或需求的资源使用进行比较； 6 在设备和实验室概述中包括执行全部V&V工作所需设备类型、所需使用期限、特殊配置以及 其他外围设备； c）在概述的工具部分列出整个V&V工作中要使用的各种工具。工具可细分成软件工具和硬件工 具； d）在预算和资金需求中考虑所有资源，以及应对意外情况的额外工具和人员。
V&V任务中的职责有两个层次，一个是项目中分配给不同组织单位的总体职责，另一个是执行任 务的具体职责。总体职责概述可在SVVP的本节或项目其他级别的计划（例如项目管理计划）中描述。 如果在其他文件中描述，则本条宜包括相关文件内容的概述和引用。本条可描述具体职责，或汇总SVVF 生命周期阶段中定义的职责。
.5. 6工具、技术和方
描述V&V方法、工具、技术及其在V&V工作中的作用，可采用叙述或图形形式。宜包括技术或工 具描述的参考引用。可为软件工具的获取、开发和修改编制一个单独的工具计划。在这种情况下，SVVP 中本节宜引用该工具计划。如果要获取或开发一个工具，则在V&V进度中宜包括其获取或开发的进度 确定是否有充足的时间和适当的任务。 在策划工具、技术和方法的使用时，应考虑： a）V&V工作所选方法的描述或参考； b）要求的人员经验和培训：
NB/Z202892014
6. 2.7.2.1 需求以适应运行环境和开发环境。裁剪时宜考虑下列方面： a) 软件开发环境和方法； b) 被V&V的软件大小和复杂性； C) 风险管理考虑； d) 执行V&V任务的组织和人员数量； e 执行V&V任务的人员与其他开发人员、管理人员及用户间的关系； SVVP所需的批准：
NB/Z202892014
5.6.2.1.3基线变更评估
基线变更评估可能是V&V工作期间所执行的最动态的任务。任何变更建议可能会影响之前完成的 大量开发工作和V&V工作。V&V任务宜对变更进行检查，以确定因变更所需重新执行的V&V工作的性 质和范围。由于各种变更不是同时产生的，SVVP不能事先对任何这类变更评估进行详细策划，但应能 够为变更建议发生时的资源配置提供总体指导。
NB/Z202892014
在变更建议中宜规定基线变更评估的要求。变更建议宜指出异常（如有）的严重性、变更的紧迫性 及所影响的系统，以便确定软件的关键性。
2.1.4V&V的管理评审
5.6.2.1.5评审支持
V&V可以通过多种方法和任务来提高管理和技术评审的有效性。多数情况下，一次评审会议与下一次 评审会的这些方法和任务相似。因此，SVVP这部分不需要为所支持的每次评审提供详细的计划，但是， 可包含准备评审时的总体指导，以及一些看似必要的特殊评审信息（例如，列出评审包的各项评审内容）。 策划评审支持活动时，应考虑： a）评审文档包与规定的评审需求的符合性、完整性、一致性、可追踪性，以及确定开口项； b）制定议程，以覆盖未解决的异常、缺陷、未解决的开口项，以及技术备选方案和折中研究。 执行V&V任务的人员参与评审时可能包括下列工作： 一提问以澄清要点或确定未解决问题：
NB/Z202892014
从事先对评审包的分析中提出问题；
从事先对评审包的分析中提出问题； 评估V&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工作应执 行图1中的如下任务： a确定V&V工作范围； b）规划供应商与V&V工作接口； c）系统需求评审； 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 开发过程
5.6.5.1概念阶段V&V
5. 6. 5. 1. 1概述
概念阶段确定所开发系统的缘由、定义系统的性质，并列举其目标和由技术约束和商务约束 的风险。
NB/Z202892014
概念阶段的评价宜（确认系统的目标对所考虑用户的需求及预期的技术和商业优势做出了规定）。 这些目标可用多种形式表述，可包括需求说明、商业案例、可行性研究及系统定义。 V&V确定风险和限制时应列举可能阻止系统开发的所有技术、商业或政策考虑。宜对项目做出初 步规划，概要描述每个可选方案的人员、时间及预期成本。此外，宜规定管理系统及其开发的任何法规 和政策。可包括可选方案，连同其优势和劣势
5.6.5.1.2概念文档评价
5.6.5.2需求阶段V&V
5.6.5.2. 1概述
5.6.5.2.2软件需求可追踪性分析
需求可追踪性分析的一个目标是确定SRS完全满足概念文件中规定的所有能力。第二个目标是确定 那些需求逐一满足了概念的要求。第三个目标是确定SRS的结构以使需求能够追踪到后续开发阶段。 SRS可追踪性分析确保SRS对软件系统所有必要的部分都作了规定，而且，确定这些部分在SRS中的位 置以便在后续开发步骤中能够被遵循，还可确定不存在不可追踪的需求。
NB/Z202892014
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的某些部分或使用未经确认的版本，以继续进行更详细级别 的开发（例如高层设计）或与之接口产品的开发。尽管如此，所有情况下，宜定义此类工作的限度
需求接口分析的目标是确保对软件的所有外部接口和软件功能间的内部接口已作了完整和正确规 定。随着软件复用和标准软件部件使用更为频繁，内部接口分析的重要性有所增加。 根据SRS的形式和是否有工具可用，接口分析可采用手动或自动的方式进行。宜提供机制以确保： 一接口数据的来源和接收者得到准确描述； 一通过接口发送和接收数据的协议是准确和完整的； SRS对接口的规定与接口的文档是一致的。 需求接口分析中，除了SRS，宜包括描述外部接口的文件，例如接口定义文件、数据字典及相关的 SRS文档，也宜包括分析单独需求间内部接口的技术。 宜规定接口文档的接受（包括发布到配置控制）准则。准则包括为确保可追踪性的格式符合性指导， 全部不完整需求（例如待定项）的完整解决方案计划、完成接口分析的提示
5.6.5.2.5系统测试计划生成和验收测试计划生成
需求阶段进行的与VV测试任务有关的工作包括规划和生成系统测试计划和验收测试计划。因为 这些测试的目的是为了证明满足运行概念和需求，因此，在编制需求后就可开始规划测试计划，但完整 的测试计划要等到需求阶段其它V&V任务完成之后才能完成。更详细的测试程序和测试用例的准备工 作在后期阶段进行。
NB/Z202892014
d 设计的关键部分或困难部分； e) 需要证明的设计假设（或对证明的引用）； f 存在需要大量分析的复杂算法； g) 需要规模和性能分析的资源约束（例如：可用的计算机硬件、时间限制）： h) 需要信息安全性分析的数据库加密和访问需求： i) 设计层次（即，对于高层和详细设计，可能适合采用不同V&V任务和方法）； j 部件测试和集成测试需要采用不同的方法； k) 执行设计V&V任务的组织： 1) 设计的媒介和格式。 V&V进度计划宜兼顾设计V&V任务中产生的意见和发现的异常。此外，可能会揭示出潜在风险， 宝更新所识别风险的清单，并宜在制 划中得到反映
5.6.5.3.2软件设计可追踪性分析
无论使用手动还是自动的方法进行追踪，都应执行需求和设计间的双向追踪，以确保： a 需求无遗漏或重复设计； b） 不存在多余的设计部分； c）由多个设计部分满足的需求是完整的和一致的。 宜对每个相互追踪关系的正确性、一致性、完整性和准确性进行评估，以确保： 需求的所有条件已被设计； 需求和设计间技术上的相互关系是正确的； 所发现的需求和设计间的多个相互关系中任何一个都是必需的
5.6.5.3.3软件设计评价
.3.4软件设计接口分
对软件设计每个级别执行设计接口分析。在策划设计接口分析时，应考虑： 数据项的使用（例如，输入和输出）是否一致、完整？ 接口是否正确、完整和必需？ C 在设计部分中发送数据项的使用是否正确？ d) 在数据传输中，系统资源的使用是否正确？（例如，宜由引用启动的数据传输是否通过数值调 用？） 用户接口设计是否易于理解？软件是否提供适当帮助？软件是否检测用户错误并对错误提供 清晰的响应？ 是否为关键接口（特别是用户接口)建立了样机？若是，是否对样机进行了彻底和独立的评价？ 是否对关键特性进行了适当证明？ 名 是否为有效的配置管理设计接口？ h） 无接口的地方是否需要一个接口？
5.6.5.3.5部件测试计划生成和集成测试计划生成
NB/Z202892014
5.6.5.3.6测试设计生成
5.6.5.4.3源代码评价
依据预期风险和关键性级别，源代码评价可采用多种评价技术（例如，评审、走查、检查）进行。 在策划源代码评价时，应考虑： a 通过代码部件的关键性分析确定需要评价的代码 确保代码编写标准可理解； c 确保在编写代码之前，代码编写标准对于人员是可用的； 确定如何评价代码质量属性； e 确定能用的代码分析工具
NB/7202892014
,5.4. 4源代码接口分
5.6.5.4.4.1源代码接口分析的目的是评估各部件间和部件内的信息流和控制流。本任务可结合源个 码可追踪性分析的结果使用。本任务的输出是描述部件接口的不一致性和错误。对于发现难于在测试中 隔离的错误，接口分析很有效。这些错误的实例是： a）引用了但未定义的软件组件； b）定义了但未引用的软件组件； c）不正确的参数个数； d）数据类型不匹配； e） 数据限制不匹配； f) 其他数据使用异常； g）控制流不一致。 5.6.5.4.4.2在策划源代码接口分析时，宜考虑： a） 物理单位精度； b） 同等参照物； c）.粒度； d）控制流； e）· 定时需求； f） 数据传输； g）命名约定。
5.6.5.4.5源代码文档评价
针对源代码评价源代码文件的目标是确保文档正确反映源代码的实际实现。代码相关文件可包括程 序支持手册、用户手册和运行手册。由于生命周期阶段的缘故，这些文件经常以文件草案形式出现并不 断被修改。在策划源代码文档评价时，应考虑： a 除了评审技术准确性、完整性、一致性外，也需要评审用户功能； 确保文档的编制级别对读者是适合的； ? 确定文档的可用性方面（例如：索引、目录、术语、标题、格式等）没有问题； d 考虑新用户是否可使用该文档执行任务（或工作）； e) 确保文档能处理错误纠正过程； n 确保有后续工作完成草本文件。
5. 6. 5. 4. 6测试用例生成
5. 6. 5. 4. 7测试程序生成
NB/Z 202892014
关于测试程序的总体讨论参见4.3.5。关于测试程序编制的进一步讨论见GB/T93862008。
5.6.5.4.8部件测试执行
5.6.5.5测试阶段V&V
5.6.5.5.2验收测试程序生成
验收测试程序规定一组测试 软件项进行分析以评价一组特性。对测试程序 的总体讨论参见4.3.5。对测试程序的进
5.6.5.5.3测试执行
5. 6. 5. 5. 3. 1 概述
在测试阶段，部件逐步集成。集成的部件依照测试计划、测试用例和测试程序逐步测试。对 及别的测试，在配置管理下，软件从控制环境中取得，然后返回控制环境，
NB/Z 202892014
5. 6. 5. 5. 3. 2集成测试执行
5.6.5.5.3.3系统测试执行
5.6.5.5.3.4验收测试执行
5.6.5.6安装与调试阶段V&V
5. 6. 5. 6. 1 概述
.6.5.6.1.1安装与调试阶段是软件生命周期中软件产品集成到其运行环境中，以及通过测试以确保 其按要求执行的时期。安装的特征包括安装人员、安装过程持续时间、安装现场的数量、系统的版本号 及其配置的充分性。 安装程序将完整和经测试过的应用程序置于满足用户对该系统使用要求的运行环境中。有时该过程 独立于开发，并由不同于开发和测试该应用程序的组织执行（例如，由现场或客户支持工程师）。某些 青况下，安装及调试由软件最终用户执行。有时安装发生在最初交付的系统上添加一个或多个子系统， 在每次安装后都应进行用户验收测试。在提交验收测试之前，每个子系统宜与之前的子系统适当集成。 安装可能需要重复无数次，每个软件版本在每个场地都要重复一次安装。一个产品可能需要针对每 个现场进行大量裁减（例如：设置现场相关的参数、构建现场相关的命令表）。每个现场可能有不同的 安装程序。 安装与调试V&V程序能确保： a）每个现场相关的配置是正确的和完整的； b） 每个现场的安装指导对配置的说明是准确的和完整的； 所编制的安装指导对预期安装人员的专业水平是适当的； d) 面向用户的检验测试能充分证明安装是令人满意的； e 交付安装的软件与通过V&V的软件是完全相同的。
NB/Z202892014
安装和调试V&V的职责可以在开发组织和用户组织之间分割。用户可以在安装中起主要作用。分 配给用户组织的V&V活动宜充分定义并形成文档。可以进行一次预安装V&V以确定并验证在安装中的 用户V&V程序。 由于上述种种原因，规划安装与调试V&V进度可能是困难的。如果该软件应安装在很多现场，可 能有必要提前制定一个安装总体进度，再针对每个具体安装根据时间或资源要求进行调整。一个程序流 程图或检查单可能有用。
5.6.1.2在编制安装与调试V&V计划时，应
6.5.6.3V&V最终报告
尽管在整个软件生命周期中都应执行V&V，但投运之前的V&V工作可以随着软件安装与调试完成 而结束。投入运行之后，另外的组织会执行维护期间的V&V，这需要文档和职责的交接。在前期V&V 完成之后，均宜编制一份V&V最终报告，汇总V&V工作的活动和结果。SVVP的第5.7部分规定了最终 报告的格式。 报告有下列用途：
NB/Z202892014
a）作为系统维护V&V的起点； b）可作为项目人员获取经验教训的载体或改进后续项目开发过程或V&V过程的途径； c）引起对开发、安装或运行中重要未解决异常的注意。 通常最终报告的编制可通过查阅和总结V&V工作过程中编制的任务报告、异常报告和阶段性总结 报告进行。
5. 6.6运行与维护过程
5. 6. 6. 1. 1概述
5.6.6.1.2SVVP修订
5.6.6.1.2SVVP修订
NB/7.202892014
在维护期间，由于软件中所发现的问题和所要求的新功能不断变化，需要定期编制新的SVVP或升 版SVVP。相关组织可以决定，依照项目需要（例如针对每个重要软件版本修订SVVP）或定期（例如 每半年修订一次SVVP）重新规划V&V。
5. 6. 6. 1. 3异常评价
5.6.6.1.5阶段任务重复
NB/Z 202892014
5. 7.2要求的报告
这些可选报告可能是一些特殊V&V研究的结果，也可能是预期活动之外其他活动的结果。由于这 些报告风格各异，对其格式和内容无特定的指导。与所有V&V报告一样，可选报告也要求及时和正确 发布。报告宜确定V&V活动的目的，描述所使用的方法，汇报其在相应级别上的结果。
NB/7202892014
8.2.2报告的方法与准
NB/Z 202892014
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时间
5.8.3任务重复策略
作为V&V工作输入的软件产品会经常变化，变化原因是由于纠正异常、性能改进、需求变化及澄 清等。在做出变化时，通过执行之前的任务或开始新的任务而重复V&V任务。需要重复执行V&V任务 以确保已正确实现规划的变更、所有文档完整且最新、在软件执行中无不可接受的变更。 管理程序宜包括在评价变更时适当配置V&V资源的准则。若无这些程序，资源在个或更多地方 可能超出合理的限度，以至于损害到整个项目。
NB/Z202892014
当一项V&V任务输入变化时，确定应重新执行此任务程度的准则可能包括变更、关键性、费用、 进度或质量影响的评估。历史数据也可能对规划有益。 选择准则时，要考虑的问题可能包括： a）响应变更时开发文档的哪些部分需要重新评价？例如，软件需求规格书的修订需要评审整个文 档？还是仅评审由开发者指定的、为响应异常报告而修订的部分？ b）当更改软件时，需要何种程度的回归测试？（部件？集成？系统？验收？） c）是否有必要重复V&V任务，直到解决所有异常？（对于非关键异常，这可能是不必要的或不 实际的） d）此V&V工作持续到运行和维扩阶段吗？如果不是，哪些点的变更是被认为是维护和超出当前 V&V范围?
5. 8. 5 控制程序
NB/7 202892014
5.8. 6 标准、规范和约定
SVVP中本节确定管理V&V任务实际执行的标准、规范和约定。应确定新的及现有的标准、规范和 约定。这可能包括指导V&V任务的文件和这些V&V任务中用于评价软件产品的文件。宜考虑内部和外 部文档。 适用的标准、规范和约定的举例如下： a 软件的需求、设计、实现、测试和文档编制的标准，针对这些标准对软件进行评价； b V&V任务的详细程序； 软件评价中使用的详细检查单； d） 评审和审核标准； e V&V程序的质量保证需求； 合同中要求的所有标准、规范和约定； 根据项自环境，可能需要特定的标准、规范和约定如下
NB/Z 202892014
NB/Z 202892014
NB／T 10150-2019 北方农村户用太阳能采暖系统技术条件表A.1SIL等级指定
表A.3阐明了表A.1和表A.2所示的基于风险的方案。根据错误的后果和促使该错误出现的运行状 态出现的可能性的组合，对表中的每个单元指定了SIL等级。一些单元反映了不止一个SIL等级，这表 明可根据系统应用和缓解风险的建议来选择SIL等级的最终制定。对于一些工业应用，出现可能性的分 类的定义可表示为由分析导出或从系统需求导出的概率图。
表A.3SIL等级指定的图例
NB/Z 202892014
角定执行V&V任务的方法。一项V&V任务可能使用多个方法（例如：源代码评价中使用的代码 享法分析）。一个特定的方法可能用于多个任务（例如：设计和源代码评价中的时序分析）。可 表、表格或其他图示展示V&V方法与任务间的相互关系。
NB/7202892014
应确定每个任务的输出。一项V&V任务的输出（至少）被3类人员使用，分别是执行其他V&V 任务（包含生命周期其他阶段的任务）的人员、执行其他开发任务人员、管理者。这些人员需要产品状 态的技术反馈，以决定如何进行开发工作。应满足这些人员可能需要的不同特定信息需求： a）执行其他V&V任务的人员需要详细的技术信息，以完成这些任务； b）开发人员需要已验证或确认开发产品的反馈：
05北京邮电大学风雨操场工程施工组织设计下（第十一章至第十六章NB/Z202892014
c）管理者需要进度、资源使用、产品状态、已识别风险的汇总信息。 V&V输出包含任务报告、异常报告、测试文档、计划和阶段总结报告。 V&V输出是V&V工作的实际产品，宜细心规划。 规定V&V任务输出时，应考虑： 每个输出的形式和格式（适用于输入的准则也适用于输出，例如：标准、媒介）； 每个输出的目的地（特定的人员或组织成员）； 每个输出的交付进度（输出应及时提交）； 每个输出的状态（例如：发布的输出草稿版或仅正式版）； 每个输出的生命期（例如：给定报告作为后续阶段的输入使用，或成为参考的存档文件） 输出的配置管理需求。