GB∕T 28808-2021 轨道交通 通信、信号和处理系统 控制和防护系统软件.pdf

ICS45.060CCSS04圍中 华 人 民 共 和 国 国 家 标 准GB/T288082021代替GB/T288082012轨道交通通信、信号和处理系统控制和防护系统软件RailwayapplicationsCommunication,signalingandprocessingsystemsSoftwareforrailwaycontrolandprotectionsystems(IEC62279:2015,MOD)2021-12-31发 布2022-07-01实 施lllilllill发 布.乂、刮 涂GB/T288082021次目前言m引言v1范 围2规 范 性 引 用 文 件3术语、定义和缩略语3.1术语和定义3.2缩 略 语4目 标、一致性和软件安全完整性等级5软件管理和组织5.1组织、角色和职责5.2人员能力5.3生命周期和文档6软 件 保 证6.1软件测试6.2软件验证6.3软件确认6.4软件评估6.5软件质量保证6.6修改和变更控制6.7支持工具和语言7通用软件开发7.1通用软件的生命周期和文档*7.2软件需求7.3架构和设计7.4组件设计7.5组件实现及测试7.6集 成7.7整体软件测试/最终确认8应用数据或算法的开发8.1目 标8.2输入文档8.3输出文档8.4要 求9软件部署和维护9.1软件部署22678811111414151618192122252525273133343537373737374141GB/T2880820219.2软件维护附录A(规范性）技术和措施的选择准则附录B(资料性）技术的目标和描述附录C(规范性）软件角色的职责和关键能力附录D(资料性）文档控制概要参考文献424556879395nGB/T288082021言刖本文件按照GB/T1.1一2020标准化工作导则第1部分:标准化文件的结构和起苹规则的规定起草。本文件代替GB/T288082012轨道交通通信、信号和处理系统控制和防护系统软件，与GB/T288082012相比，除结构调整和编辑性改动外，主要技术变化如下删除了下列术语和定义:3.3可用性、3.5设计机构、3.7元索、3.11避错、3.16产品、3.18可靠性、3.19需求可追溯性目标（见2012年版的第3章）；b)增加了下列术语和定义：3.1.4组件、3.1.5配置管理员、3.1.6客户、3.1.8实体、3.1.16集成、3.1.17集成人员、3.1.18既有软件、3.1.19开源软件、3.1.21项目管理、3.1.22项目经理、3.1.23可靠性、3.1.24鲁棒性、3.1.25需求经理、3.1.26需求管理、3.1.30安全功能、3.1.33软件基线、3.1.34软件部署、3.1.41测试人员、3.1.42测试、3.1.43T1类工具、3.1.44T2类工具、3.1.45T3类工具(见3.1);更改了软件管理和绀织的独立件要求（见第5章，2012年版的第5章、第6章、第7章）；d)增加了软件部署和软件维护方面的要求（见5.1);增加了参与软件开发的角色的定义和个人能力的要求(见5.2);f)增加了有关工具的新条款（见6.7)g)增加了整体软件测试及相应要求（见7.7);h)更改了对软件开发输出成果物的要求（见附录A，2012年版的附录A);i)增加了附录C，进一步明确软件角色的关键能力及其职责（见附录C)。本文件使用新起草法修改采用IF：C62279:2015轨道交通通信、信号和处理系统控制和防护系统软件。本文件与IEC62279:2015相比做了下述结构调整：3.1.9对应IEC62279:2015的3.1.10；3.1.10对应IEC62279:2015的3.1.113.1.11对应IEC62279:2015的3.1.9；附录B对应IEC62279:2015的附录D，并增加了每一个目标和描述的章条编号；附录C对应IEC62279:2015的附录B;附录D对应IEC62279：2015的附录C。本文件与IEC62279:2015的技术性差异及其原因如下：关于规范性引用文件，本文件做了具有技术性差异的调整，以适应我国的技术条件，调整的情况集中反映在第2章“规范性引用文件”中，具体调整如下：用等同采用国际标准的GB/T19000代替了ISO9000:2015(见6.5.4.2)；用等同采用国际标准的GB/T19001代替了ISO9001:2008(见5.1.2.1、5.2.2.3、6.4.1.2、表A.9和表C.11)用修改采用国际标准的GB/T25000.10代替了ISO/IEC25010(见9.2.4.4、表C.11)。本文件做了下列编辑性改动：删除了第2章规范性引用文件清单中的IEC62278:2002；增加了描述以指明附录D(见5.3.2.14)增加了缩略语“APr“CFG”“DSL”*“LCF”:a)c)e);inGB/T288082021更改了参考文献；更改了IEC62279:2015中的错误：6.6.3中“(见9.2.4.11)”改为“(见9.2.4.10)”；表A.1中，“见注2”符号原标注在第29、30、31号文档，改为标注在第30、31、32号文档；表A.8中“软件分析技术(6.3)”改为“软件分析技术(6.2)”；表A.9中，参考条目中的“7.1”改为“6.5”；表A.12中，第2个序号9和序号10,改为序号10和序号11。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。本文件由国家铁路局提出。本文件由全国牵引电气设备与系统标准化技术委员会(SAC/TC278)归口。本文件起草单位：中车株洲电力机车研究所有限公司、同济大学、中国铁道科学研究院集团有限公司标准汁量研究所、北京全路通信信号研究设计院集团有限公司、中国铁道科学研究院集团有限公司通信信号研究所、北京和利时系统工程有限公司。本文件主要起草人：周志飞、刘布麒、徐中伟、赵天时、邱兆阳、张萍、汪小亮、李文波。本文件及其所代替文件的历次版本发布情况为：2012年首次发布为GB/T288082012；本次为第一次修订。IVGB/T288082021引言本文件与GB/T21562和GB/T28809配套使用。GB/T215622008适用于大范围的轨道交通系统，而GB/T28809适用于整个轨道交通控制和防护系统中可能存在的单个系统的批准过程。本文件关注于为提供满足安全完整性要求的软件而采用的方法，该安全完整性是通过更全面的考虑后陚予软件的。本文件提供一系列有关开发、部署和维护方面的要求，任何用于轨道交通控制和防护应用的安全相关软件都应遵守这些要求。本文件规定了有关组织结构、组织之间的关系以及开发、部署和维护活动中涉及的职责分工等方面的要求，同时本文件也提供了人员资质和专业知识的准则。本文件的关键概念是软件安全完整性等级（SIL)。本文件标识了五个软件安全完整性等级:SIL0SIL4,其中SIL0为最低等级，SIL4为最高等级。软件失效带来的风险越高，软件安全完整性等级就越高。本文件明确了五个软件安全完整性等级的技术和措施，SIL0SIL4所X的技术和措施在附录八的规范性表格中列出。本文件中SIL1和SIL2所需的技术要求相同，SIL3和SIL4所需的技术要求相同。对于某个给定的风险，本文件并没有给出哪种软件安全完整性等级是合适的指导意见。闪为该决策取决于多个因素，包括应用的性质、其他系统承担的安全功能的范_，以及社会及经济因索。将安全功能分配到软件的过程由GB/T21562和GB/T28809定义。本文件规定了满足这些要求的必要措施。GB/T21562和GB/T28809要求采用系统性的方法以：a)识别危害、评估风险并基于风险准则作出决策；b)确定必要的风险降低措施以满足风险接受准则；c)为必要的安全防护措施定义一个全面的系统安全需求规格说明，以实现所需的风险降低；d)选择一个合适的系统架构；e)规划、监督和控制所必需的技术和管理活动，这些技术和管理活动把安全需求规格说明转化成安全完整性得到确认的安全相关系统。在将规格说明分解到由安全相关的系统和组件组成的设计当中时，需要对安全完整性等级作进一步分配，并最终形成所需要的软件安全完整性等级。以S前的技术发展水平，无论是质S保证措施(所谓的故障规避措施和故障检测措施）的应用还是软件故障容忍方法的应用，都无法保证软件的绝对安全。尚无途径证明一个相对复杂的安全相关软件中不存在缺陷，特别是规格说明的缺失和设计的缺陷。应用于开发高完整性软件的原则，包括但不限于：a)自 顶 向 下 的 设 计 方 法；b)模块化；c)开发生命周期每个阶段的验证；d)经过验证的组件和组件库；e)清晰的文档与可追踪性；f)可审核的文档；g)确认；H)评 估；0配置管理和变更控制；VGB/T288082021j)组织和个人能力方面的相应考虑。系统安全需求规格说明识别了分配给软件的所有安全功能，同时确定了这些安全功能的安全完整性等级。图1给出了应用本文件时的一系列实用的步骤并说明如下：a)定义软件需求规格说明，同时考虑软件架构；软件架构是为软件和软件安全完整性等级制定安全策略的地方，见7.2和7.3;b)根据软件质量保证计划、软件安全完整性等级和软件生命周期，设计、开发和测试软件，见7.4和7.5c)在目标硬件上进行软件集成和软硬件集成，以及功能验证，见7.6;d)接受和部署软件，见7.7和9.1;e)在软件生命周期的运行阶段，如果软件需要维护，如适用，重启本文件进行处理，见9.2。许多活动与软件开发交叉进行，这些活动包括:测试(见6.1)、验证（见6.2)、确认（见6.3)、评估（见6.4)、质ft保证（见6.5)，以及修改和变更控制（见6.6)。本文件对支持工具(见6.7)和由应用数据或算法配置的系统（见第8章）也作出了要求。本文件对软件开发过程中涉及的角色的独立性和个人能力（见5.1、5.2和附录C)也作出了要求。本文件不强制要求使用特定的软件开发生命周期，在5.3、图3、图4和7.1给出了示范的生命周期和文档集。格式化表格针对软件安全完整性等级列出了各种技术/措施符合附录A的要求。与该表格交叉引用的是附录B给出的技术词汇，它对每项技术/措施的目标和内容作了简要描述。VIGB/T288082021获取该系统的系统需求规格说明、系统安全需求规格说明、系统架构描述和系统安全计划识别分配给软件的所有安全功能评审分配给软件的所有安全功能并搞定软件的安全完整性等级形成软件箱求规格说明和软件架构规格说明根据软件质量保证计划、软件安全完整性等级和软件生命周期，设计、开发、验证/测试软件实施软件确认并移交给系统工程师系统运行软件维护图1软 件 路 线 图 示 例GB/T288082021轨道交通通信、信号和处理系统控制和防护系统软件1范 围1.1本文件规定了轨道交通控制和防护应用中使用的可编程电子系统软件开发所需的过程和技术要求。它适用于任何有隐含安全性的领域。这些系统可能通过采用专用微处理器、吋编程逻辑控制器、分布式多处理器系统、大规模集中处理器系统或者其他架构来实现。1.2本文件只适用于软件以及软件与软件所在系统之间的交互。1.3本文件与被认定为对安全没有任何影响的软件无关，即软件失效不会影响任何已识别的安全功能。由于在风险评估甚至危害识别时存在不确定性，因此引入了SILO的概念。对于安全性影响低于SIL1功能的软件部分，至少要满足本文件SILO的要求。1.4本文件适用于轨道交通控制和防护系统屮使用的所有安全相关软件，包括：a)应用程序设计；b)操作系统；c)支持工具；d)固件。应用程序设计包括高级程序设计，低级程序设计和专用程序设计（如：可编程逻辑控制器的梯形逻辑）。1.5本文件也涉及了既有软件和工具的使用。如果要使用该类软件，则要满足7.3.4.7和6.5.4.16中对既有软件的特定要求，以及6.7中对工具的要求。1.6根据本文件的任何版本开发的软件，都被视为符合本文件规定，不受针对既有软件的要求约束。1.7本文件考虑了目前流行的以适用多种应用场合的通用软件为基础进行应用设计的情况，这些通用软件通过数据、算法或二者同时配置后，为应用生成可执行的软件。第1章第6章和第9章既适用于通用软件也适用于应用数据或算法。第7章仅适用于通用软件，第8章仅适用于应用数据或算法。1.8本文件不涉及商务问题，商务问题宜作为合同的基本部分提出。但在任何商务活动中都需仔细考虑本文件的所有条款。1.9本文件不是追溯性的，主要应用于新的开发，对于既有系统，仅当进行大的修改时才进行全面应用，对于小的变更，仅需要应用9.2。评估人员需要分析软件文档中提供的证据，以便确认对软件变更范围和性质的认定是否充分。当对既有软件进行升级或维护时，宜应用本文件。2规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该H期对应的版本适用于本文件;不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T19000质 量 管 理 体 系 基 础 和 术 语GB/T190002016,ISO9000:2015,IDT)GB/T19001质 量 管 理 体 系 要 求GB/T190012016,ISO9001:2015,IDT)GB/T25000.10系 统 与 软 件 工 程 系 统 与 软 件 质 量 要 求 和 评 价SQuaRE)第10部分：系统与软件质量模型GB/T25000.102016,ISO/IEC25010:2011,MOD)GB/T288082021ISO/IEC90003:2014软件工程ISO90012008应用于计算机软件的指南Softwareengineer-ingGuidelinesfortheapplicationofISO9001:2008tocomputersoftware)3术语、定义和缩略语3.1术语和定义下列术语和定义适用于本文件。3.1.1评估assessment确定软件是否满足规定的要求并就软件是否符合预期目的作出判断的分析过程。注1:该软件可能涉及过程、文档、系统、子系统硬件和/或软件组件。注2:安全评估关注但并不限于系统的安全性1性。3.1.2评估人员评估方开展评估活动的实体。assessor3.1.3商用现货软件commercialoff-the-shelf(COTSsoftware由市场驱动的需求所定义、可商业获得且已被广大商业用户证明其用途合适的软件。3.1.4组件component软件的组成部分，在软件架构和设计方面具有良好定义的接口和行为。注：软件组件遵循下列准则：a)按照“组件”的要求（见附录A中表A.20)进行设计；b)覆盏了一组特定的软件需求子衆*c)在配置管理系统中被淸晰地标识并具有独立的版本，或作为拥有独立版本的组件集合（例如子系统）的一部分。3.1.5配置管理员configurationmanager实施并开展文档、软件和相关工具配置管理活动（包括变更管理）的实体。3.1.6客户customer采购轨道交通控制和防护系统(包括软件）的实体。3.1.7设计人员designer对特定需求进行分析并将其转化成可接受的且具有相应安全完整性等级的设计方案的实体。3.1.8实体entity敉行本文件所定义的某个角色的个人、团体或组织3.1.9错误error与预期设计的偏差，这种偏差可能导致非预期的系统行为或失效。2GB/T2880820213.1.10失效failure观察到的行为与要求的行为之间出现的不可接受的偏差。3.1.11故障fault可能导致系统出错的异常状态。注：故障可能是随机性的或者系统性的。3.1.12故障容忍faulttolerance在存在有限数量的软件或硬件故障的情况K，系统仍能继续正确提供规定服务的内在能力。3.1.13固件firmware以功能独立于应用软件的形式存储在只读存储器或半永久性存储器（例如flash存储器）中的软件。3.1.14通用软件genericsoftware只要提供与特定应用相关的数据和/或算法就完全可应用于多种安装环境的软件。3.1.15实现人员implemcnter将特定设计转换为具体物理实现的实体。3.1.16集成integration根据架构规格说明和设计规格说明组装软件和/或硬件部件，并对组装的单元进行测试的过程。3.1.17集成人员integrator实施软件集成活动的实体。3.1.18既有软件pre-existingsoftware先于H前正在考虑的应用而开发出来的软件，包括商用现货(COTS)软件和开源软件。3.1.19开源软件opensourcesoftware对公众开放的、没有版权限制或版权限制宽松的源代码。3.1.20可编程逻辑控制器programmablelogiccontroller；PLC具备用于存储指令的用户可编程存储器并能实现规定功能的固态控制系统。3.1.21项目管理projectmanagement项目的管理行为和/或技术行为，包括安全方面的。3.1.22项目经理projectmanager实施项目管理的实体。3GB/T2880820213.1.23可靠性reliability某个项在规定的条件下和规定的时间内执行所要求功能的能力。3.1.24鲁棒性robustness某个项检测并处理异常情况的能力。3.1.25需求经理requirementsmanager实施需求管理的实体。3.1.26需求管理requirementsmanagement引出需求、文档化需求、分析需求、确定需求优先级并对需求达成一致意见，控制需求变更并与利益相关者沟通的过程。注：需求管理是贯穿项目的一个持续过程。3.1.27风险risk导致伤害的事故和事件（由危害引起）的发生概率与伤害严重程度的组合。3.1.28安全性safety避免对人造成伤害的不可接受等级的风险。3.1.29安全主管部门safetyauthority负责证明安全相关软件或服务遵守相关法定安全要求的机构。3.1.30安全功能safetyfunction实现部分或整个安全需求的功能。3.1.31安全相关软件safety-relatedsoftware执行安全功能的软件。3.1.32软件software由程序、规程、规则、数据和任何与系统运行有关的文档组成的智力产物。3.1.33软件基线softwarebaseline软件发布所需的且完整一致的源代码、可执行文件、配置文件、安装脚本和文档的集合。注：编译器、操作系统、既有软件和相关工具的有关信息作为基线的一部分存储。这可使组织能重建定义的版本并在维护阶段的增强或升级时作为将来发布的输入*3.1.34软件部署softwaredeployment移交、安装并激活已经过发布和评估的、可交付使用的软件基线。3.1.35软件生命周期softwarelifecycle从软件构思开始到软件不再使用为止的时间周期。4GB/T288082021注：典型的软件生命周期包括需求阶段、设计阶段、测试阶段、集成阶段、部署阶段和维护阶段。3.1.36软件可维护性softwaremaintainability软件能被修改以纠正故障，改善性能或其他特性，或适应不同环境的能力。3.1.37软件维护softwaremaintenance软件部署后针对软件采取的活动或活动集合，其目的是增强或纠正软件的功能性。3.1.38软件安全完整性等级softwaresafetyintegritylevel一组分级数字，它决定了应运用于软件的技术和措施。注：将安全相关软件分为五个安全完整性等级，o为低等级，4为a卨等级。3.1.39供应商supplier设计和建造轨道交通控制和防护系统(包括软件或软件只作为其一部分）的实体。3.1.40系统安全完整性等级systemsafetyintegritylevel表示包含硬件和软件的集成系统满足其指定安全要求所需置信度的分级数字。3.1.41测试人员tester执行测试活动的实体。3.1.42测试testing在受控条件下运行软件，对照相应的沿求规格说明以确定其行为和性能的过程。3.1.43T1类 工 具toolclassT1不产生直接或间接贡献于软件可执行代码（包括数据）输出的工具。注：T1类工具的示例包括文本编辑器或无自动代码生成功能的需求或设计支持工具、配置控制工具#来源：GB/T20438.42017,3.2.11，有修改3.1.44T2类 工 具toolclassT2支持对设计或可执行代码的测试或验证，其错误可能不会暴露缺陷，但也不会直接在可执行软件中产生错误的工具。注：T2类工具的示例包括测试框架生成器、测试覆盖率测量工具、静态分析工具。来源：GB/T20438.42017,3.2.11,有修改3.1.45T3类 工 具toolclassT3产生直接或间接贡献于软件可执行代码(包括数据）输出的工具。注：T3类工具的示例包括源代码编译器、数据/算法编译器、在系统操作期间可更改设定值的工具，源代码程序与生成的B标码之间关系不明确的优化编译器，将可执行的“nm-time包”合并到可执行代码中的编澤器。来源：GB/T20438.42017，3.2.11，有修改3.1.46可追踪性traceability开发过程屮的两个或多个产品之间可建立关系的程度，特别是那些构成前代/后代或者主要/次要5GB/T288082021关系的产品之间。3.1.47确认validation一种进行分析然后基于证据进行判断的过程，用于确定某个项（如过程、文档、软件或应用）是否符合用户需求，尤其是在安全和质量方面，并强调预期环境下操作的适用性。3.1.48确认人员validator负责确认的实体。3.1.49验证verification检査特定开发阶段的输出项（过程、文档、软件或应用）是否满足该阶段中关于完整性、正确性和一致性的要求并根据证据作出判断的过程。注：验证主要是基于对输出文挡（设计、开发、测试文忾等）的评审。3.1.50验证人员verifier负责一个或多个验证活动的实体。3.2缩略语下列缩略语适用于本文件。APT:应用编程接口（ApplicationProgrammingInterfaces)ASR:评估人员（Assessor)CFG:控制流图（ControlFlowGraph)CGM:配置管理员(ConfigurationManager)COTS:商用现货（Commercialoff-the-shelf)DES:设计人员（Designer)DSL:领域专用语言（DomainSpecificLanguages)HR:强烈推荐（HighlyRecommended)IMP:实现人员(Implementer)INT:集成人员（Integrator)JSD：Jackson系统开发方法（JackvSonSystemDevelopmentMethod)LCF:可计算函数逻辑（LogicofComputableFunctions)M:强制（Mandatory)MASCOT:软件构造、运行和测试的模块化方法（ModularApproachtoSoftwareConstruction,OperationandTest)NR:不推荐（NotRecommended)PM:项目经理（ProjectManager)QAM:质景保证经理（QualityAssuranceManager)R:推荐（Recommended)RAMS:可靠性、可用性、可维护性和安全性(Reliability，Availability，MaintainabilityandSafety)RQM:需求经理（RequirementsManager)SDL:规格说明和描述语言（SpecificationandDescriptionLanguage)6GB/T288082021SFC:顺序功能图（SequentialFunctionCharts)SIL:安全完整性等级（SafetyIntegrityLevel)SOM:面向服务的建模（ServiceOrientedModeling)SSADM:结构化系统分析和设计方法（StructuredSystemsAnalysis&-DesignMethodology)TST:测试人员（Tester)V&V:验证和确认（VerificationandValidation)VAL:确认人员（Validator)VER:验证人员（Verifier)4目标、一致性和软件安全完整性等级4.1安全相关系统的功能到软件和软件接n的分配应在系统文档中标识。嵌入软件的系统应就下列方面进行完全定义：功能和接口；b)应用条件；系统配置或体系架构；d)需控制的危害；e)安全完整性耑求；f)需求的分配以及安全完整性等级到软件和硬件的分配；g)时间约束。_注：安全完整性需求的分配可能会导致同一子系统中充分分离的软件部分和硬件部分有不同的安全完整性等级。这种分配取决于子系统的软件部分和硬件部分对于安全相关功能的贡献和失效的减轻机制（包括不同安全完整性等级的功能的分离）。4.2软件安全完整性应被指定为五个等级之一，从SILO(最低等级）到SIL1SIL4。4.3应根据系统的安全完整性等级和系统中与软件使用相关的风险等级，在系统层面确定和评估所需的软件安全完整性等级。4.4对于安全性影响不确定但通常低于S1L1的功能软件部分应满足SILO的要求。4.5为符合本文件规定，应表明各子条款中规定的冇关软件安全完整性等级的要求以及附录A中规定的技术和措施得到了满足。4.6如果一个要求附有限定语句“为达到软件安全完整性等级所要求的程度”，则表示应使用一系列的技术和措施来满足该要求。4.7在4.6适用的地方，应使用附录A中的表格来帮助选择与软件安全完整性等级相适应的技术和措施。这种选抒应记录在软件质量保证计划中或软件质Q保证计划引用的其他文件中。这些技术的指南参见附录B。4.8如果某一技术或措施在表格中被列为HR却未被使用，那么应在软件质最保证计划中或软件质量保证计划引用的其他文件中详细说明并记录使用其他替代技术的理由。如果使用了相应表格屮被认可的技术组合，则无需说明和记录理由。应证明所选择的技术已被正确地应用。4.9如果表格中未包含的技术或措施被提议使用，那么应对其在满足特定要求和子条款的整体目标方面的有效性和适合性作论证，并在软件质讀保证计划中或软件质量保证计划引用的其他文件中作相应的记录。4.10应通过审查本文件所要求的文档，适当时还应通过其他客观证据、审查和测试见证来验证是否符a)c)7GB/T288082021合特定子条款的要求和表格屮详细列出的相应的技术和措施。5软 件 管 理 和 组 织5.1组织、角色和职责5.1.1目 标确保所有对软件负有责任的人员被组织起来.被授权并能履行其职责。注：可能要求不M角色之间相互独立，以减少不同角色的人员出现同-理解错误或犯同样错误的可能性.这种形式的独立性，可通过不N的角色由不同的人承担来实现，但通常不要求角色位于不同的组织部门或不同的公司(除非特别要求）。同样重要的是，从安全性角度出发对产品或过程的可接受性作出判断的角色的承担人员不宜受他们的同枣或主管压力的影响，或受商业利益的考虑。这种形式的独立性更可能要求不同的角色位于不N的组织部门或不同的公司。一般来说，安全性等级越岛对各种角色和组织的独立性要求程度也越fiu5.1.2要 求5.1.2.1作为最低要求，供应商应执行GB/T19001屮涉及人员、职责的组织和管理部分。5.1.2.2职责应符合附录C的规定。5.1.2.3被指定为参与软件开发或维护角色的人员应实行实名制并i己录。5.1.2.4评估方应由供应商、客户或安全主管部门指定。5.1.2.5评佔方应独立T供应商。但根据安全主管部门的意见，评估方也可是供应商组织或客户组织的一部分，但独立于开发项目。5.1.2.6评估方应独立于项0。5.1.2.7应赋予评估人员足够的权力来实现对软件的评估。5.1.2.8确认人员应给出同意/不同意软件发布的意见。5.1.2.9在整个软件生命周期中，为达到软件安全完整性等级所要求的程度，人员角色的分配应符合5.1.2.105.1.2.14的规定。首选的组织结构示意图见图2。8GB/T288082021PMASRSIL3和SIL4RQM，DES，IMPVALINT,TSTVER,QAMPMSIL1和STL2RQM,DES,IMPINT,TSTVER,QAM,VALPMSILORQM,DES,IMPINT,TST,VER,QAM,VAL说明:可 是个 人可是同一个组织I应向PM报告可向PMm告不应向PM报吿注1:CGM角色可与ASR以外的其他角色合并(见附录C的表C.10)。注2:本图只是首选组织结构的一个示例。图2首 选 的 组 织 结 构 示 意 图5.1.2.10针 对SIL3和SIL4,首选的组织结构如下：a)软件组件的需求经理、设计人员和实现人员可是同一个人。b)软件组件的需求经理、设计人员和实现人员应向项目经理报告。c)软件组件的集成人员和测试人员可是同一个人。d)软件组件的集成人员和测试人员可向项目经理或确认人员报告。e)验证人员或质童保证经理可向项目经理或确认人员报告。0确认人员不应向项目经理报告。也就是说项目经理不能影响确认人员的决策，但确认人员应将自己的决定通知项目经理。g)某个软件组件的需求经理、设计人员或实现人员不应是同一软件组件的测试人员和集成人员。9GB/T288082021h)某个软件组件的集成人员或测试人员不应是同一个软件组件的需求经理、设计人员和实现人员。i)验证人员或质量保证经理既不应是需求经理、设计人员、实现人员、集成人员、测试人员，也不应是确认人员。j)确认人员不应是需求经理、质最保证经理、设计人员、实现人员、集成人员、测试人员和验证人员。k)项目经理可额外担任需求经理、质M保证经理、设计人员、实现人员、集成人员、测试人员或验证人员的角色，前提是这些额外角色之间的独立性要求得到遵守。l)项B经理、需求经理、质量保证经理、设计人员、实现人员、集成人员、测试人员、验证人员和确认人员可属于同一个组织。m)评估人员应是独立的，并在组织上独立于项目经理、需求经理、质量保证经理、设计人员、实现人员、集成人员、测试人员、验证人员和确认人员等角色。下列选项可适用：n)确认人员也可履行验证人员的角色，但仍独立于项目经理。在这种情况下，验证人员输出的文件应由另一个与确认人员冇相同独立性级別的能胜任的人员审査。该组织选项应经评估人员同意。o)验证人员或质墩保证经理也可履行集成人员和测试人员的角色，在这种情况r，确认人员应根据指定的验证0标检査集成和测试过程中文档化证据的充分性。5.1.2.11针对SIL1和SIL2,首选的组织结构如下：a)软件组件的需求经理、设计人员和实现人员可是同一个人，应向项目经理报告。b)软件组件的集成人员和测试人员可是同一个人。c)软件组件的集成人员和测试人员可向项目经理或确认人员报告。d)验证人员、质量保证经理和确认人员可是同一个人。e)验证人员、质11保证经理和确认人员可向项B经理报告。f)软件组件的需求经理、质M保证经理、设汁人员或实现人员不应是同一软件组件的测试人员和集成人员。g)软件组件的集成人员或测试人员不应是同一软件组件的需求经理、设计人员和实现人员。h)验证人员、质量保证经理或确认人员+应是需求经理、设计人员、实现人员、集成人员和测试人员。i项B经理可额外担任湛求经理、质_a：保证经理、设计人员、实现人员、集成人员、测试人员、验证人员或确认人员的角色，前提是这些额外角色之间的独立性要求得到遵守。i)项目经理、需求经理、质量保证经理、设计人员、实现人员、集成人员、测试人员、验证人员和确认人员可属于同一组织。k)评估人员应是独立的，并在组织上独立于项目经理、需求经理、质S保证经理、设计人员、实现人员、集成人员、测试人员、验证人员和确认人员等角色。下列选项适用：l)验证人员或质童保证经理也可担任集成人员和测试人员的角色，在这种情况下，确认人员的作用应包括审査验证人员或质景保证经理输岀的文档，从而在项目组织内维持两级审查。m)确认人员也可担任验证人员、质贵保证经理、集成人员和测试人员等角色。在这种情况下，验证人员或质量保证经理的输出文档应由另一与确认人员相同独立级别的能胜任的人员审查。该组织选项应经评估人员同意，5.1.2.12针对SILO,首选的组织结构如下：a)软件组件的需求经理、设计人员和实现人员可是同一人，且应归项目经理管理；10GB/T288082021b)软件组件的集成人员、测试人员、验证人员、质量保证经理和确认人员可是同一人；c)集成人员、测试人员、验证人员、质M保证经理和确认人员可归项目经理管理；d)软件组件的需求经理、设计人员或实现人员不应是同一软件组件的测试人员和集成人员；e)软件组件的验证人员、质贵保证经理或确认人员不应是需求经理、设计人员和实现人员；f)项目经理可额外担任需求经理、质量保证经理、设计人员、实现人员、集成人员、测试人员、验证人员或确认人员角色，条件是这些额外角色之间的独立性要求得到遵守；g)项目经理、需求经理、质M保证经理、设计人员、实现人员、集成人员、测试人员、验证人员和确认人员可归属于同一组织；H)评估人员应是独立的，并在组织上独立于项目经理、需求经理、质量保证经理、设计人员、实现人员、集成人员、测试人员、验证人员和确认人员等角色。下列选项适用：i)需求经理、设计人员、实现人员、集成人员和测试人员可是同一人；j)确认人员、验证人员和质讀保证经理可是同一人；k)验证人员、质景保证经理或确认人员不应是需求经理、设计人员和实现人员。5.1.2.13某个组件的需求经理、设计人员和实现人员角色可担任不同组件的测试人员和集成人员角色。5.1.2.14验证人员、质景保证经理和确认人员等角色应在项0级别定义，并在幣个开发项0过程中应保持不变。5.2人员能力5.2.1目 标通过证据显示在各种条件下能正确、高效、一致地执行相关任务达到高质童状态的能力，确保所有对软件负有责任的人员都有能力赠行其职责。5.2.2要 求5.2.2.1附录C定义了软件开发中每个角色所需的关键能力。如果在软件生命周期中某个角色需要额外的经验、能力或资格，应在软件质最保证计划中规定。.5.2.2.2供应商组织应对行关人员能力的证明文件进行维护，包括技术知识、资格、相关经验和适当的培训，以证明安全组织是合适的。5.2.2.3一旦安全组织被证明满足了评估方的要求或通过承担各种角色的人员能力证明文件得到证明，每个人仍耑展示对其能力的持续维护和发M。这点可通过相关活动被定期执行的口志记录来证明，且额外的培训是根据GB/T19001和ISO/IEC90003:2014中6.2.2进行的。5.2.2.4组织应根据现行质M标准对人员能力的管理程序进行维护，使人员能力与所承担的角色匹配。5.3生 命 周 期 和 文 档5.3.1目 标5.3.1.1将软件开发结构化为规定的阶段与活动。5.3.1.2记录整个软件生命周期中所有与软件有关的信总。5.3.2要求5.3.2.1应选择一个软件开发生命周期模型，并根据6.5的要求在软件质M保证计划中加以详细说明。图3和图4给出了两种生命周期模型的示例。11GB/T288082021阶段设计和测试文档验证活动系统需求规格说明系统安全需求规格说明系统架构描述系统安全计划和v&v计划软件需求规格说明整体软件测试规格说明软件需求软件需求驗证软件架构软件架构规格说明软件架构验证软件设计软件集成测试规格说明软件/礙件集成测试规格说明软件设计规格说明软件接口规格说明软件设计驗证软件组件设计规格说明软件组件测试规格说明软件组件设计软件组件设计验证软件源代码和支持文档组件实现与测试软件组件测试报吿源代码舱证软件集成测试报吿软件集成软/硬件集成测试报告软 件 集 成 证整体软件测试报告软件碗认整体软件测试驗证软件部署文档软件部署软件维护文档软件维护注：软件评估是外部活动，并可在整个生命周期中得到实施。图3开 发 生 命 周 期 示 例112GB/T288082021软件维护阶