(高清版)GBT 28808-2021 轨道交通 通信、信号和处理系统 控制和防护系统软件

代替GB/T28808—2012国家市场监督管理总局国家标准化管理委员会I Ⅲ V 1 1 23.1术语和定义 2 6 7 8 85.2人员能力 5.3生命周期和文档 6软件保证 6.1软件测试 6.2软件验证 6.3软件确认 6.4软件评估 6.5软件质量保证 6.6修改和变更控制 216.7支持工具和语言 7通用软件开发 7.1通用软件的生命周期和文档 7.2软件需求 7.3架构和设计 7.4组件设计 7.5组件实现及测试 7.7整体软件测试/最终确认 8应用数据或算法的开发 8.2输入文档 8.3输出文档 8.4要求 9软件部署和维护 9.1软件部署 41ⅡGB/T28808—20219.2软件维护 42附录A(规范性)技术和措施的选择准则 45附录B(资料性)技术的目标和描述 附录C(规范性)软件角色的职责和关键能力 附录D(资料性)文档控制概要 Ⅲ——附录C对应IEC62279:2015的附录B;62279:2015的附录C。·用等同采用国际标准的GB/T·用等同采用国际标准的GB/T表A.9和表C.11):·用修改采用国际标准的GB/TV ●表A.12中，第2个序号9和序号10,改为序号10和序号11。 VVj)组织和个人能力方面的相应考虑。系统安全需求规格说明识别了分配给软件的所有安全功能，同时性等级。图1给出了应用本文件时的一系列实用的步骤并说明如下：和7.5;d)接受和部署软件，见7.7和本文件对支持工具(见6.7)和由应用数据或算法配置的系统(见第8章)也作出了要求。本文件不强制要求使用特定的软件开发生命周期，在5.3、图3、图4和7.格式化表格针对软件安全完整性等级列出了各种技术/措施符合附录A的要求。与该表格交叉引周期，设计、开发、验证/测试软件1GB/T19001质量管理体系要求(GB/T19001—2016,ISO9001:2015,IDT)2ISO/IEC90003:2014软件工程ISO9001:2008应用于计算机软件的指南(Softwareengineer-ing—GuidelinesfortheapplicationofISO9001:2008tocomputersoftwa客户customer3以功能独立于应用软件的形式存储在只读存储器或半永久性存储器(例如flash存储器)中的45测试人员tester测试testing开发过程中的两个或多个产品之间可建立关系的程度，特别是那些构6M:强制(Mandatory)NR:不推荐(NotRecommended)789ASRASRASRRQM,DES,IMPINT,TSTVER,QAMASRRQM,DES,IMPINT,TSTVEINT,TST,VER,QAM,VALd)软件组件的集成人员和测试人员可向项目经理或确认人员报告。e)验证人员或质量保证经理可向项目经理或确认人员报告。f)确认人员不应向项目经理报告。也就是说项目经理不能影响确认人员的决策，但确认人员应阶段软件架构系统开发阶段(外部的)系统架构描述软件架构和设计阶段(7.3)软件维护阶段(9.2)软件部署阶段(9.1)软件部署指南软件集成阶段(7.6)软件组件设计阶段(7.4)软件组件设计规格说明软件组件测试规格说明2)每个活动的进入和退出准则；3)每个活动的输入和输出；4)主要质量活动；5)每个活动的责任实体。2)分发范围；3)归档。f)对正在开发或已经交付的软件组件的变更的影响分析；i)执行前的授权。当工具被用于替代人工操作时，工具输出的所选择的工具能协同工作。如果一个工具的输出具备合适的内容和格式作为后续工具的自动输6.7.4.3所有的T2和T3类工具应有清晰定义了工具行为、所有命令或使用约束的规格说明或产品6.7.4.4对于每个T3类工具，应可获得这a)组织内或其他组织在类似的环境中和对类似的应用成功使用的经历的适当组合；e)可避免或检测和控制工具引入的失效的其他适当方法。b)工具手册的版本；f)测试用例及其后续分析的结果；g)预期结果和实际结果之间的差异。a)有一个对其适用性进行过评价的翻译器，包括在适当情况下，根据国际或国家标准进行的c)包含使设计或编程错误便于检测的特性；编程语言是软件或设计表示法中的一种。翻译器将软件或设计表示(如文可为某个特定的应用项目或一类应用项目对翻译器进行评价。针对后一应可获得有关工具预期使用和合理使用的所有必要信息。对于特定项目的工具6.7.4.1、6.7.4.2、6.7.4.3、6.7.4.10工具类型正在开发产品的安全完整性等级1.在类似环境下成功使用的证据；或1.工具的开发或获取，遵循本文件中与特定应用的安全完整性等级2.运行一个广泛认可的、具有确定性结果3.对系统使用各种不同的工具，比较工作产品的性能，检查其差异1)既有软件旨在实现的需求；2)既有软件关于环境的假设；3)与软件其他部分的接口。7.3.4.14软件架构规格说明应选择表A.3中的技术和措施，所选组合应被证明是满足4.8和4.9的1)时间约束和正确操作的要求；2)对异常的管理。f)如果适用的话，为接口缓冲区分配的内存，以及内存不能被分配或所有缓冲区溢出的检测g)功能之间存在的同步机制(见e)]。来自和去往接口的所有数据应根据数据类型在整个数值的范围内定义，h)所有指定数据的等价类以及使用这些数据的每个软件功能的定义和说明。c)软件组件之间的接口；g)错误报告机制。7.3.4.24软件设计规格说明应选择表A.4中的技术和措施，所选组合应被证明是满足4.8和4.9的b)语言应用过程中可能会产生的、而在验证过程中不可检知的错误的避免措施或检测措施(见7.5和7.6)。这类失效是通过对语言的所有特征的分析得出的。2)组件间的信息流；3)顺序和时间相关信息；5)数据结构和属性。1)所要求性能的可行性；2)进一步验证时的可测试性；3)允许作进一步改进时的可维护性。8.4.1.4应用准备计划应从表A.11选取技术和措施，所选组合应被证明是满足4.8和4.9的集合。进行的V&V活动和证据可替代对该部分应用数据/算法的V&V,这些结果应汇集在应用准备验证报8.4.1.7应用准备计划应包括V&V活动，以确保应用工具和通用软件互相兼容，且与8.4.2.2特定应用的需求应包括所考虑安装活动的特定要求(如某个信号系统的轨道布置、信号机位9.2.4.4可维护性应作为软件的固有属性，特别是遵循7.3、7.4和7.5的要求进行设计。应采用以及9.2.4.10中的特定要求9.2.4.16应选择表A.10中的技术和措施。所选组合应被证明是满足4.8和4.9的集合。进行管理。题时系统的整体完整性。(规范性)表A.1～表A.11与本文件的正文条款相关联，用以说明符合性的实现方法。其中较低级别的表条款表格也引用了资料性附录B。对每项技术或措施的要求是相同的。类似地，软件SIL3和SIL4对每项技术或措施的要求也是相同——“HR”表示该项技术或措施在该安全完整性等级下是强烈推荐的。如果不使用该项技术或措 ——“NR”表示该技术或措施在当前安全完整性等级下是肯定不推荐的。如果该技术或措施被使当一个或多个技术或措施被选择时，技术或证计划引用的另一个文档中说明，除非表格的附注有其他的要求。这些附注可阶段文档1.软件质量保证计划2.软件质量保证验证报告3.软件配置管理计划5.软件确认计划6.软件需求规格说明7.整体软件测试规格说明阶段文档9.软件架构规格说明10.软件设计规格说明11.软件接口规格说明12.软件集成测试规格说明13.软件/硬件集成测试规格说明14.软件架构和设计验证报告15.软件组件设计规格说明R16.软件组件测试规格说明R17.软件组件设计验证报告R18.软件源代码和支持文档19.软件组件测试报告R20.软件源代码验证报告21.软件集成测试报告22.软件/硬件集成测试报告23.软件集成验证报告整体软件测24.整体软件测试报告25.整体软件测试验证报告26.软件确认报告27.工具确认报告R29.应用需求规格说明30.应用准备计划(见注2)31.应用测试规格说明(见注2)32.应用架构和设计(见注2)33.应用准备验证报告34.应用测试报告36.应用数据/算法验证报告37.软件发布和部署计划RRRR表A.1生命周期和文档(5.3)(续)阶段文档软件维护RRRRR注1:根据5.3.2.11和5.3.2.12,可对不同的文档进行合并。注2:文档30、31、32的推荐程度是HR还是R,取决于它们在过程中定义的重要性和验证发生的时机。如在系统范畴，数据仅需要验证而不用测试，而更多功能性属性则需要测试和验证。这种情况下，虽然标注的是注3:对于软件评估计划和软件评估报告，见6.4.1.2。注4:软件质量保证报告包含在GB/T28809—2012所规定的质量管理报告中。参考条目1.形式化方法(基于数学方法)RRRRRRRRRRR软件需求规格说明应包括采用自然语言和任何必要的形式化或半形式化符号对问题进行描本表列出了为清晰和精确定义规格说明所需的附加要求。应选择其中一种或多种技术以满参考条目1.防御性编程RRRRRRRRRRRRRRRR表A.3软件架构(7.3)(续)参考条目10.向前恢复11.故障恢复重试机制RRRR12.存储执行实例 RR13.人工智能故障纠正14.软件动态重构15.软件错误影响分析RR16.功能弱化RR17.信息隐藏18.信息封装R19.完全定义的接口MM RRRRRR23.由计算机辅助设计和规格说明RRR对于软件SIL3和SIL4,认可的技术组合如下所——1、7、19、22,以及4、5、12、21中之一；——1、4、19、22,以及2、5、12、15、21中之一。对于软件SIL1和SIL2,认可的技术组合如下：1、19、22,以及2、4、5、7、12、15、21中之一。其中一些项点可在系统级进行规定。检错码可根据GB/T24339(所有部分)的要求使用。表A.4软件设计和实施(7.4)参考条目1.形式化方法RRRRMMMMMM7.可分析程序8.强类型编程语言RR表A.4软件设计和实施(7.4)(续)参考条目10.编程语言R11.语言子集12.面向对象编程RRRRR13.面向过程编程R14.元编程RRRRR对于软件SIL3和SIL4,认可的技术组合是4、5、6、8,以及1、2中之一。对于软件SIL1和SIL2,认可的技术组合是3、4、5、6,以及8、9、10中之一。参考条目1.形式化证明 RR RRRRRMMRR表A.21RMM10.接口测试对于软件SIL3和SIL4,认可的技术组合是3、5、7、8,以及对于软件SIL1和SIL2,认可的技术组合是5,以及2、3、8中之一。注1:1、2、4、5、6和7适用于验证活动。注2:3、8、9和10适用于测试活动。参考条目1.功能/黑盒测试RR表A.7整体软件测试(6.2和7.7)参考条目1.性能测试MMMMRRRR对于软件SIL1和SIL2,认可的技术组合是1和2。参考条目1.静态软件分析RRR3.因果图RRRRR RRRRRR应选择表中一个或多个技术来满足选用的软件安全完整性等参考条目RMMMMM3.符合ISO/IEC90003RRRRR4.公司质量体系MMMMMMMMMMRRMMMM该表适用于不同角色和所有阶段。参考条目1.影响分析RMMMM参考条目1.表格化的规格说明方法RRRRR2.应用专用语言RRRRRRMMMMMRMMRRRR7.正式设计评审R8.(数据)正确性的形式化证明RRR对于软件SIL1和SIL2,认可的技术组合是1和4。对于软件SIL3和SIL4,认可的技术组合是1、4、5、7或2、3、注：B.29的描述是针对程序的，而此处第8项技术/措施应用于数据正确性的形式化证表A.12编码规范(7.3,表A.4)参考条目1.编码标准MMRRRRRRRR6.有限制使用递归RR R10.限制子程序参数数量RRRRR11.限制使用全局变量MM技术3、4和5可作为经过确认的编译器或翻译器的一部分而得到认可。参考条目1.基于边界值分析的测试用例RRRRRRRRR-—RRRRR RR测试用例分析是在子系统级并基于规格说明和/或规格说明和代码进行的。参考条目1.基于因果图的测试用例执行RR2.原型设计/动画 RRRRRRRRR仿真的完整性取决于软件安全完整性等级、复杂度和应用情参考条目RRRRRRRRRRRR7.汇编语言RRRRRRRRRRRRRRR参考条目10.语句列表RRRRR不需要为排除特定编程语言做出的决定进行合理的解注1:评估编程语言适用性的有关信息，参见B.54“合适的编程语言”。注2:如果某特定语言不在表中，不意味着被自动排除在外，遵守B.54。注3:与选定语言相关的运行时系统(run-timesystems)是运行应用程序所必需的，根据软明其使用是合理的。参考条目1.功能块图RRRRR2.顺序功能图3.梯形图RRRRR4.状态图R参考条目1.数据建模RRR2.数据流图RR3.控制流图RRR4.有限状态机或状态转换图5.时间Petri网RRRRRRRRR9.原型设计/动画RRRR10.结构图RR11.顺序图R应至少选择一项HR技术。参考条目1.雪崩/压力测试RR表A.19静态分析(表A.5,表A.8,表A.21)参考条目1.边界值分析RRRRRR5.错误推测 RRRR6.走查/设计评审参考条目1.信息隐藏R3.参数个数限制RRRRR4.完全定义的接口RMM只有在没有数据访问的通用策略时，宜使用信息隐藏和信息封表A.21代码测试覆盖率(7.5,表A参考条目1.语句RRRRRRR RR对于每个安全完整性等级，都应为进行的测试开发一种覆盖率的量化方法。用以支持对测试所外技术的必要性进行判断。对于软件SIL3和SIL4,组件级别的测试覆盖率应根据2、3,或2级别的测试覆盖率应根据2、3、4、5中的一可使用其他合理的测试覆盖率标准。这些标准依赖于软件架构(见表A.3)和编程语言(见表A.15和表A.16)任何不可测试的代码都应使用适当的技术证明其正确性，如表A.19中的静态分析。注1:第2～5项技术/措施可自动实现语句覆盖。注2:该表中的测试覆盖准则用于基于结构的(基于代码的，白盒)测试。功能(基于规格说明，措施见表A.14。注3:高覆盖率百分比通常难以达到。通过执行边界值(B.4)、等价类和输入划分测试(B.18)用较少的测试实现充分的覆盖率。注4:2和3的区别取决于实践中编程语言的级别和组合条件的使用。比如按照编译后的结表A.22面向对象的软件架构(表A.4)参考条目1.应用领域概念到架构类的可 RRRRRRRRR当使用已有的框架和设计模式时，既有软件的需求需适合于这些框架和模注1:面向对象的方法呈现的信息和过程式的方法不同，下面的列表包含需要具体考虑的建——了解类层次结构，以及在调用给定的方法(包括使用现有的类库)时需要执行的软件函数的标识；——基于结构的测试(表A.13)。注2:对部分即将开发的软件，其框架可能存在于已成功解决了类似任务且为开发人员所熟么该框架的使用被认为是良好实践行为。表A.23面向对象的详细设计(表A.22)参考条目1.类应只有一个对象 RRR2.仅当派生类是其基本类的细 R3.通过编码标准限制继承深度RRRRRRR一一一个类只负责一项职责，即关注密切关联的数据和对这些数据的操作。避免对象之间的循环依赖。(资料性)借助引入方法和过程模型的组合以及某种在线安全性和可靠性分析，以便B.1.2描述尤其是在以功能性或者描述性的方式运用模型和方法的组合时，本方法可有B.2.2描述f)不宜将复杂计算作为分支和循环的判定依据；g)分支和循环的判定与模块输入参量的关系宜简单；d)受影响的装置各自调到它们的最大速度或最低速度；程序的输入域被划分成若干输入类别。测试宜包括每个类别的边界值和极限的输入域的边界与程序的边界是否一致。在直接和间接转换中，0值的使用通常容易出错，应特别a)除数为0;输入(参数)的边界通常直接对应于输出范围的边界。宜编写测试用例使得输含元素，只有1个或2个元素的链表。B.5.2描述法意味着要在所谓良好定义的检查点频繁保存内部的状态。可以完整方式(对B.7.2描述如果使用的检查表中存在与正在处理的系统无关的问题，那么该问题宜控制流分析识别代码中没有遵循良好编程实践的可疑区域。对程序进行分析b)打结代码。具有良好结构的代码，其控制图可通过连续的图形缩减简化到单个节点。而结构为了识别冗余系统或冗余子系统中，由于冗余部件同一时间出现相同为了维护设备的安全，计算机系统经常在硬件和多数表决中使用冗余通过记录、确认和分析各个项目和人员的相关数据来促进软件过程的改进织的战略目标决定的。这些目标可能是针对某一特定的软件开发方法的性的评价。B.12.2描述数据记录和分析是软件过程改进的重要组成部分。有效数据的记录是了为了达到预期的准确性，数据记录和确认过程应与开发同时进行，比如作为配置控制过程的一部分。B.13.2描述1)检查变量的取值范围；2)尽可能检查数据值的合理性；从程序功能方面和变量的物理意义两方面看，这三条建议有应区分只读和可读/写的参数，并检查对它们的访问。函数应以1)检查具有物理意义的输入变量和中间变量的合理性；2)检查输出变量的作用效果，最好直接观察相关系统状态的变化；3)软件应检查其配置，这包括检查预期硬件是否存在及其可访问性，也包括检查软件自身的a)语言的合理性；b)适用时的范围和基础标准；c)编码标准变更程序；d)潜在故障的分析和建议的处理方法；e)对避免错误的限制；N个版本可在不同的计算机上面并行运行，也可在一台计算机上运行所有版本，并对结实验和分析研究表明，N版本编程并不总是如期望的那样有N版本编程的两个选择是设计多样性和功能多样性。设计多样不同的方式设计，但实现相同的功能。功能多样性包括以功能上不同的系统的逻辑架构应能映射到系统可用资源的子集。体系架构需要将逻辑体系架构重新映射到剩下仍在工作的受限资源上。尽管这种想法传统上仅限b)可根据程序内部结构来定义等价类。在这种情况下，等价类的结果是由程序的静态分析确定对于一个n比特信息片段，生成一个k比特的编码块使得错误能被检测、纠正。不同的编码类型b)循环码；B.20.2描述虑系统是否足够健壮。面板上的按钮是否可过快或过频繁地按动?如果两个按钮同时按压，会发生什么?B.21错误播种将一些已知的错误类型插入到程序中，而后在测试条件下使用测试用例执行程部分播下的错误，那么测试用例集就不够充分。已发现的播种错误数与播已发现的真实错误数与真实错误总数之比。这提供了一种评估剩余错误对所有播种错误的检测可能表明测试集是否充分，或者播种错误是否太容易B.22事件树分析为了以图形方式建立模型对系统中初始事件后可能发展的事件序列进B.22.2描述B.23菲根(Fagan)审查法断言编程方法遵循检查前置条件(在执行语句序列之前，检查初始条件的有效性)和一个后置条assert<后置条件>;B.25.2描述a)重要软件组件识别是根据组件规格说明，确定每个软件组件需要的分析深度(在单个指令行、1)组件名称；2)考虑到的错误；3)模块级错误的后果；5)违反的安全准则；6)错误危害程度；7)建议的错误检测方法；8)如果检测方法被执行，仍会违反的准则；9)检测方法执行后的残余危害程度。c)综合。综合识别剩余的不安全场景和给出每个模块的危害程度所需的确认工作量。B.26.2描述故障检测是基于冗余(主要用于检测硬件故障)和多样性(软件故障)复杂系统是由子系统组成的。故障检测、诊断和补偿的效率取决于影响故障传播的子系统之间相一个系统。产生的系统模型称为有限状态机(FSM)。通常它被画成所谓的状态转换图，展示系统如何这些是关键系统的重要属性，可对它们进行检查。支持这些检查的工具为了改进复杂系统行为的描述，对基本FSM进行逻辑上是严格推理的(每个步骤都遵循推理规则，因此可通过机械过程进行检验)在于它们提供了一种象征性地检查数字设计(无论是硬件或软件)的整个状态空间a)将形式化方法应用于大部分细节都被抽象掉c)分析变量是离散的且范围急剧减少的软件和硬件模型；e)使尽可能多的验证(工作)自动化。技术也能很好地服务于生命周期的不同阶段。例如，定理证明用于分析快速转换级电路描述的正确性也许是最好的，而代数推导方法用于分析将设计细在本附录中，给出了几个形式化方法的例子。这些例子并不详尽。所描述的序进程(CSP)、通信系统演算(CCS)、高阶逻辑(HOL)、时序规格说明语言(LOTOS)、代数规格说明语B.28.2.2描述CSP为进程系统的规格说明提供一种语言，并为验证进程的实现满足其规格说明提供证据(这些过顺序或并行地组合进程来建模的。进程可通过通道进行通信(同步或交换数据),并且只有当两个进CSP理论被直接应用于InmosTransputer体系架构中，并且通过occam语言1可直接在Trans-puter的网络上实现一个基于CSP方法描述的系统。B.28.3.1目标B.28.3.2描述顺序运行或并行运行的独立进程构成的网络。或者是并行形式建模。进程可通过端口进行通信(类似的高级抽象描述(称为痕迹)开始，可对系统进行逐步求精细化成其整体行为是整个系统所要求的通信B.28.4.2描述HOL是指一种特殊的逻辑符号及其机器支持系统，这二者都是由剑桥大学计算机实验室开发的。LOTOS基于CCS,附加了一些源自相关的代数学如CSP和电路微积分(CIRCAL)的特征。它通过结合另外一个基于抽象数据类型语言ACTONE的组件，克服了CCS在处理数据结构和数值表达式B.28.6.2描述OBJ是一种代数规格说明语言。用户以代数方程认。执行本质上就是通过等式替换(重写)进行的功能评估，等式替换一直持续到获得特定的输出值。阶谓词逻辑进行了扩展。这些操作符可用来限定有关系统的一些断言。例如：安全属性可能需要包含一个计算机程序。在时态逻辑中并不明确处理量化的时间间隔和约束，绝对定时应通过创建额外的时间状态作为状态定义的一部分来处理。B.28.8.2描述VDM是一种基于数学的规格说明技术和一种用于对实现进行细化的技术，这种技术允许对规格集合理论结构上定义了不变量(谓词),而在该状态上的操作是根据系统状态通过指定它们的前置和后规格说明的实现是借助目标语言的数据结构对系统状态进行具体化和借助目标语言的程序对操作进行细化来完成的。具体化和细化的步骤将产生验证它们的正确性的义务。是否履VDM主要是用于规格说明阶段，但也可用于设计和实现阶段生成源程序。它只能被用于顺序程B.28.9Z方法Z方法是一种用于顺序系统的规格说明语言符号和设计技术，该技术在将一个Z方法规格说明开B.28.9.2描述构来建模的，在该状态下的操作是根据系统状态通过指定它们的前置和后置条件来建模的。可证实操为B方法),可和Z方法联合使用。如同VDM,B方法的目的是对一个系统或软件进行形式化建模，并证明系统或软件的行为符合在自动生成一套证明义务(从B方法模型提取的假设中要正式证明的逻辑断言)。这些证明义务a)存在满足模型静态和动态特性的数据；c)数据和操作的细化(如必要的话可和B0伪代码一起)不能违背用抽象机器编写的规格说明；模型检查是检查一个给定的结构是否为给定逻辑公式的模型的过程。该概念某一重要类型的模型检查方法已经发展为形式化系统的算法验证。这是通过验证结构(通常来自硬件或软件设计)是否满足形式化规格说明(通常是时态逻辑公式)来实现的。这种结构通常用工业硬件描述语言或专用语言作为源代码描述。这样的一个。节点表示系统的状态，边表示可能改变状态的转换，而基本命题形式上该问题可表述如下：给定一个期望的性质，表示为时态逻辑公式P,以及一个初始状态为SB.29形式化证明B.29.2描述在程序的不同位置声明了许多断言，它们被用作程序中各条路径的前置条件其适合于具有小型数据库和内部状态快速变化的实时系统。假定，系统状态这种技术给出将被系统执行的各种功能的优先级。设计保证了在执行所有系统功能的资源不足a)只对变更的组件进行再验证；b)对所有识别出的受影响的组件进行再验证；c)对整个系统进行再验证。所有软件组件都可以全局访问的数据可能被其中的任何组件意外地或错误程序进行操作。这种方法允许修改内部结构或者增加另外的程序而不影响其余软件的功能行为。例(如使用不同的查找方法或者在硬盘上存储名字),很多编程语言都直接支持抽象数据类型的概念，但是无论使用哪种编程语言，基本原则都是适B.34接口测试为了证明子程序的接口不包含任何错误或任何可能导致软件在特定应a)所有接口变量处于其极限值；b)所有接口变量分别处于其极限值c)每个接口变量处于值域中的所有值而其他变量处于正常值；d)所有变量的所有值的组合(这可能只是小的接口才可行);如果接口不包含检测错误参数值的断言，这些测试就特别重要。在B.35语言子集B.35.2描述可采用不同的方法存储执行路径。Hash编码方法可用于将执行序列映射成单个大数或数字序B.37度量而导致的过度延时或过长的响应时间。为避免这种情况，工程师通常设计系分(如50%),从而降低资源匮乏的可能性。c)识别基本的和可选的性能需求和成功准则；a)每个需求的失效概率；为了便于测试，通常采用自动帮助。它们关注测试数据提供和测试输各个测试工具、测试执行和测试监督是由上面描述的详细测试目标决关于任何测试对象行为的概率数据也可是源自操作经验。只要满足B.42过程仿真a)为被测系统提供其安装时存在的所有输入；为了根据给定的约束条件检查实现系统的可行性。将规格说明人员对系统的解释跟客户沟通，以B.44恢复块B.44.2描述执行第二个段，称之第一替补项。它之后也紧随一个验收测试，并和第一段的情况同样处理。如果需系统和软件的需求规格，包含特定功能的内存和响应需求，也许制。需要执行分析以确定在平均和最坏情况下的分布要求。该分析要求估计B.46.2描述在检测到故障或错误条件时，尝试通过重新执行相同的代码来恢复情况。在完备。重试技术通常用于通信故障或错误恢复，重试条件可从通信协议错误(B.47安全袋B.47.2描述安全袋是一个外部监视器，根据不同的规格说明在一台独立计算计算机执行安全的、但未必正确的操作。安全袋持续地监控主计算机，防止系软件配置管理的目的是确保当那些可交付项发生变化时，成组的开发付项的每个版本，和不同可交付项的不同版本之间的每一个关系。这种结果记个可交付项的变更对其他可交付项的影响。特别是，可从一致的组件版本中可B.49.2描述这样的语言通常允许从基本的语言数据类型(如INTEGER、REAL)来定义用户自定义数据类型，这些用户自定义类型可和基本类型完全相同的方式使用，但是要进行严格检类型。即使它是由另外的编译单元建立起来的，这些检测也要求强加到整个程强类型语言也支持良好的软件工程实践的其他方面，如易分析的控制结构(如IF…THEN…在程序分析的基础上，选择一组输入数据，以便测试所选程序元素的大部分d)线形代码序列和跳转[LCSAJ(LinearCodeSequenceAndJump)]是代码语句的任意线性序B.51.2描述树形图的形式显示。它们描述了怎样按程序单元结构图显示了程序单元之间的关系，而不包括这些单元激活顺序的任何信息。画这些图时使用以从数据流图派生的结构图表示系统的一级结构，结构图上的每个框代表了数据流图中的一个泡。B.52结构化方法结构化方法的主要目的是通过关注生命周期的初期阶段来提高功能，而另一些方法(如MASCOT、JSD、实时Yourdon)更适于过程控制和实时应用(趋向于更安全-标识问题和系统实体(如过程和数据流)的支持符号往往是精确的，但这些实体执行的处理功能倾向于使用非正式的符号来表达。但是有些方法部分使用(数学上的)形式化符号(如JSD使用正则表达结构化表示法的另一个好处是其可见性，允许用户根据其强大B.53结构化编程以一种对软件组件进行实用分析的方式设计与实现软件组件。该分析宜能发现所有重要的组件软件组件的结构复杂度宜最小化，宜避免复杂的分支。循环约束和分支数简单相关。宜将软件组件划分成适当的小模块，这些模块之间的交互宜是b)翻译期间的检查d)参数检查B.57面向对象编程面向对象编程是基于现实世界中的抽象而不是基于计算抽象来思考软件的一种全新的基本方法。面向对象编程将软件组织成一个对象集合，该集合包区和方法，并允许增加一些私有数据和一些对需求的可追踪性是系统确认时的一个重要考虑因素，并提供手段允许它在b)从设计对象到对其进行实例化的实现对象的可追踪性；c)从需求和设计对象到为了保证系统正确和安全运行的运行维护对象元编程是指某类计算机程序的编写，这类计算机程序写或者操纵其他程序(或者自身)作为它们的反射是促进元编程的一种很有价值的语言特性。把编程语言自身作为一级数据类型(如在Lisp元编程通常通过两种方式之一工作。第一种方法是通过应用程序接口(API)来将运行时引擎的内B.60.2描述SFC元素允许将应用算法单元划分为一组由有向连线连接的步和转换。每个步与一组动作相关联，而每个转换与一个转换条件相关联。由于SFC元素需要存储状态信息，所以使B.62梯形图见GB/T15969.3—20B.64状态图状态图表或状态图用于描述系统的行为。状态图可描述事件发生时某个对计算机科学技术中数据建模是使用数据建模技术，通过形式化的数据模型软件工程中的数据模型是一个描述如何表示和访问数据的抽象模型。域的数据对象，以及数据对象之间的关系。数据库模型的一些典型应用包括在计算机科学中，控制流图(ControlFlowDiagram或C任何执行过程中该块是不可达的，因此是不可达代码，可被安全地删除。如果从(也被称为假边)被添加到图中，只为了保留出口块后置支配所有块的属性的边。它是不可能遍历如果从进入点的每个路径通过M块到达了N块，就说M块支配N块。输入块支配所有块。如果从块N到出口的每条路径都应经过块M,则称块M后置支配块N。出口块后置支配所有如果块M直接支配块N,且没有诸如M支配P,P再支配N这样的中间块P,则称块M直接支配以一种允许通过抽象降低复杂性的方式来表示软件程序和相关的软件价。UML经常用于所谓的模型驱动开发，并得到商业产品的支持。这种开发风格旨在通过使用高级UML是一种标准化的通用建模语言，起源于面向图形的软件规格说明语言和面向对象的编程语言的使用。以传统为基础，UML重用了许多其前身的概念和方法。依据一个或多个图表类型编写模虽然UML是一种通用建模语言，但通过外廓(profile)可实现对特定领域的解释。通过细化标准的UML概念，外廓使得通过使用外廓中定义的扩展来作出这样的解释成为可能。通过这种方式，领域专用语言(DSL)是一种编程、规格说明或建模语言，它是为解决特定应用领域题，或采用某种特殊技术而特别创建的语言。本语言基于与该领域相关的概念序员的生产率和最终产品的质量。代码生成典型的实现方式为使用DSL作为输入的应用生成器。2.应负责软件需求规格说明。3.应建立和维护与系统级需求之间的追踪性。4.应确保需求规格说明和软件需求处于变更和配置管理之下，包括状态、版本和授权状态。5.应确保软件需求规格说明(针对用户需求和应用的最终环境)的一致性和完整性。7.应理解本文件的要求。1.应将指定的软件需求转换成可接受的解决方案。3.应定义或选择设计方法和支持工具。4.应应用合适的设计原则和标准。8.应确保设计文档处于变更和配置管理的控制下。1.应具备应用领域的工程化能力。2.应掌握安全设计原则。3.应具备设计分析和设计测试方法的能力。4.应有能力在给定环境中根据设计约束进行工作。6.应理解硬件平台、操作系统和接口系统的约束。1.应将设计解决方案转换为数据/源代码/其他设计表2.应将源代码转换为可执行代码/其他设计表3.应运用安全设计原则。7.应开发和维护实现文档，包括应用方法、数据类型和清9.应保持所生成或修改的数据/代码处于变更和配置管理的控制之下。2.应具备实现语言和支持工具方面的能力。3.应能运用指定的编码标准和编程风格。4.应理解硬件平台、操作系统和接口系统施加的所有约5.应理解本文件的相关条款/子条款。1.应规划测试活动。2.应开发测试规格说明(目标和用例)。3.应确保测试对象与指定软件需求之间的追踪性，以及测试用例与指定测试对象之间的追踪性。4.应确保规划的测试被实施，指定的测试被执行。5.应识别对预期结果的偏离，并将其记录在测试报告7.应在报告中记录结果。8.应选择软件测试设备。1.在需要开展测试的领域应具备相应的能力，如软件需求、数据、代码等方2.应掌握各种测试和验证方法/理论，并能在给定的周境中确定最合适的方3.应能从给定的规格说明中导出测试用例。4.应具备分析思维能力和良好的观察技能。5.应理解本文件的相关条款/子条款。表C.5验证人员1.应制定软件验证计划(可能包含质量事宜),说明需要验证的内容和什么类型的过程(如评审、分析等)和测试需要作为证据。核对。3.应识别异常，在风险(影响)项中评价这些异常，将其进行记录并传达给相关的变更管理机构进行评估和决策。4.应对验证过程(评审、集成和测试)进行管理，按要求确保活动的独立性。6.应编制验证报告，说明验证活动的结果。1.应具备验证实施(例如软件需求、数据、代码)的能2.应掌握各种验证方法/理论，并能在给定的周境中确定最合适的方法或方法组合。3.应能从给定的规格说明中推导出验证的类型。4.应具备分析思维能力和良好的观察能力。5.应理解本文件的相关条款/子条款。1.应使用软件基线管理集成过程。2.应基于设计人员编写的组件规格说明和架构来开发软件集成测试规格说明和软件/硬件集成测试规格说明，说明必要的输入组件、集成活动的顺序以及由此产生的集成组3.应开发和维护有关集成活动的记录。4.应识别集成异常，记录并将其传达给相关变更管理机构进行评估和决5.应编写开发组件和整体系统集成报告，说明集成的结果。1.应具备组件集成领域的能力，如相关的编程语言、软件接口、操作系统、数据、平台、代码2.应具备各种集成方法论，并能在给定的周境中确定最合适的方法或方法组3.应能理解各个中间层所需的设计和功能。4.应能从一组集成的功能推导出集成测试的类型。5.应具有较强的分析思维能力和良好的系统层次的观察能6.应理解本文件的相关条款/子条款。1.应在预期应用环境中建立对软件的系统理解。2.应制定确认计划，指定软件确认的基本任务和活动并与评估人员达成一致。3.应根据预期的环境/使用，评审软件需求。5.应评价软件过程和所开发的软件符合本文件，包括指定的安全完整性等级的要求。9.应根据风险(影响)对所有偏离进行评审和分类，记录偏离并提交给负责变更管理和作出决策的机构。10.应根据预期的用途对软件的适用性提出建议，并视情况指出所有的应用约12.如适用，应在各个开发阶段对整个项目(作为通用开发过程的实例)进行审核、审查或评审。14.应审查开发解决方案是否可