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

4.3.2可追踪性分析

4.3.2可追踪性分析

外墙外保温标准规范范本NB/Z202892014

当所有软件需求到概念文档和系统需求的追踪被验证时，才能进行后续从软件需求到所有开发描 述、用户文档、测试文档的可追踪性分析。分析每个追踪的一致性、完整性和正确性，以验证全部软件 需求已在软件中实现，并且关联到正确的设计、代码和测试信息。 4.3.2.3在执行可追踪性分析的过程中，容易发现一些错误，例如：需求没有设计条目、或设计条目 没有代码、或相反的情况。分析员应检查每一条追踪路径，以确保连接部分的正确性。为此，分析员应 理解需求和设计的意图。 可追踪性分析可用于支持配置管理、测试覆盖分析、V&V结果分析、回归测试、关键性评估和V&V 管理决策。可追踪性分析也有助于评价软件开发工作，以达到良好的软件工程实践。

4.3.3.3评价在所有阶段使用并针对所有类型的软件产品，包括用户文档、手册和项目其他文档。这 些文档可有许多形式，例如文本或图示和各种媒介，有纸质、磁带、软盘及计算机文件。这些范围的产 品类型与形式需要多种技术来执行和管理软件评价。 在评价系统产品时，从一个开发阶段到下一个评价的重点会发生变化。随着生产过程从概念到最终 产品，首先定义其功能需求，其次建立设计条目的组织和结构，然后编制所有可执行程序。在开发初期， 占主导的是“什么和为什么”、“如果一将会怎样”、“可选方案”和“更好或最好”这类问题，而在 后续开发阶段，“如何”、“正确性”和“一致性”这类问题会经常出现。

NB/Z202892014

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

a）用户接口。宜分析入与软件产品的接口，例如要求的屏幕格式、保护机制、页面布局和报告的 内容、输入与输出的相对时间等。 b）硬件接口。宜分析软件产品与系统硬件部件间每个接口的逻辑特征。确定电子设备、固件、通 信设备及输出设备，然后确定这些接口的适用标准并验证当前的应用接口。 软件接口。宜分析与其他所需软件产品的接口（例如：数据管理系统、操作系统、或库），以 及与其他应用系统的接口。确定其它软件产品的适用标准和与其它应用系统的接口。验证软件 接口到其它应用系统软件接口的正确性。

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

a）接口的目的在技术上是否得到充分的和很好的理解？ b）是否定义好了所有数据元素？

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

NB/7202892014

4. 3. 5.3.1概述

NB/Z202892014

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

4. 3. 5. 3. 2 测试计划

3.5.3.2.1测试计划清楚地说明测试活动的范围、方法、资源和进度，指出要求测试什么而不要求 试什么、要求执行的测试任务、责任人和风险。规划的关键点包括： 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软件设计接口分