项目经理projectman

项目经理projectmanager

GB/T28808—2021

铁路标准GB/T288082021

注：典型的软件生命周期包括需求阶段、设计阶段 3.1.36 软件可维护性softwaremaintainability 软件能被修改以纠正故障，改善性能或其他特性，或适应不同环境的能力。 3.1.37 软件维护softwaremaintenance 软件部署后针对软件采取的活动或活动集合，其目的是增强或纠正软件的功能性。 3.1.38 软件安全完整性等级softwaresafetyintegritylevel 一组分级数字，它决定了应运用于软件的技术和措施， 注：将安全相关软件分为五个安全完整性等级，0为最低等级，4为最高等级。 3.1.39 供应商supplier 设计和建造轨道交通控制和防护系统（包括软件或软件只作为其一部分）的实体。 3.1.40 系统安全完整性等级systemsafetyintegritylevel 表示包含硬件和软件的集成系统满足其指定安全要求所需置信度的分级数字。 3.1.41 测试人员tester 执行测试活动的实体。 3.1.42 测试testing 在受控条件下运行软件，对照相应的需求规格说明以确定其行为和性能的过程。 3.1.43 T1类工具toolclass T1 不产生直接或间接贡献于软件可执行代码（包括数据）输出的工具。 注：T1类工具的示例包括文本编辑器或无自动代码生成功能的需求或设计支持工具、配置控制

可追踪性traceability

开发过程中的两个或多个产品之间可建立关系的程度，特别是那些构成前代/后代或者主要/次要

GB/T 28808—2021

3.1.47 确认validation 一种进行分析然后基于证据进行判断的过程，用于确定某个项（如过程、文档、软件或应用)是否符 合用户需求，尤其是在安全和质量方面，并强调预期环境下操作的适用性。 3.1.48 确认人员validator 负责确认的实体。 3.1.49 验证verification 检查特定开发阶段的输出项（过程、文档、软件或应用)是否满足该阶段中关于完整性、正确性和 致性的要求并根据证据作出判断的过程， 注：验证主要是基于对输出文档（设计、开发、测试文档等)的评审。 3.1.50 验证人员verifier 负责一个或多个验证活动的实体

3.1.47 确认validation 一种进行分析然后基于证据进行判断的过程，用于确定某个项（如过程、文档、软件或应用)是否符 合用户需求，尤其是在安全和质量方面，并强调预期环境下操作的适用性。 3.1.48 确认人员validator 负责确认的实体。 3.1.49 验证verification 检查特定开发阶段的输出项（过程、文档、软件或应用)是否满足该阶段中关于完整性、正确性和 致性的要求并根据证据作出判断的过程， 注：验证主要是基于对输出文档（设计、开发、测试文档等)的评审。 3.1.50 验证人员verifier 负责一个或多个验证活动的实体

SFC：顺序功能图(SequentialFunctionCharts） SIL：安全完整性等级（SafetyIntegrityLevel) SOM：面向服务的建模（ServiceOrientedModeling） SSADM：结构化系统分析和设计方法（StructuredSystemsAnalysis&DesignMethodology） TST：测试人员(Tester) V&V：验证和确认(VerificationandValidation) VAL：确认人员（Validator) VER：验证人员（Verifier）

SFC：顺序功能图（SequentialFunctionCharts） SIL：安全完整性等级（SafetyIntegrityLevel) SOM：面向服务的建模（ServiceOrientedModeling) SSADM：结构化系统分析和设计方法（StructuredSystemsAnalysis&.DesignMethodology） TST：测试人员(Tester) V&V：验证和确认(VerificationandValidation) VAL：确认人员（(Validator) VER验证人员（Verifier）

4且标、一致性和软件安全完整性等级

方面进行完全定义： a） 功能和接口； b） 应用条件； ） 系统配置或体系架构； d） 需控制的危害； e） 安全完整性需求； 需求的分配以及安全完整性等级到软件和硬件的分配； g） 时间约束。 注：安全完整性需求的分配可能会导致同一子系统中充分分离的软件部分和硬件部分有不同的安全完整性等级。 这种分配取决于子系统的软件部分和硬件部分对于安全相关功能的贡献和失效的减轻机制（包括不同安全完 整性等级的功能的分离）。 4.2软件安全完整性应被指定为五个等级之一，从SIL0（最低等级）到SIL1～SIL4。 4.3应根据系统的安全完整性等级和系统中与软件使用相关的风险等级，在系统层面确定和评估所需 的软件安全完整性等级， 4.4对于安全性影响不确定但通常低于SIL1的功能软件部分应满足SILO的要求。 4.5为符合本文件规定，应表明各子条款中规定的有关软件安全完整性等级的要求以及附录A中规 定的技术和措施得到了满足。 4.6如果一个要求附有限定语句“为达到软件安全完整性等级所要求的程度”，则表示应使用一系列的 技术和措施来满足该要求。 4.7在4.6适用的地方，应使用附录A中的表格来帮助选择与软件安全完整性等级相适应的技术和措 施。这种选择应记录在软件质量保证计划中或软件质量保证计划引用的其他文件中。这些技术的指南 参见附录B。 4.8如果某一技术或措施在表格中被列为HR却未被使用，那么应在软件质量保证计划中或软件质量 保证计划引用的其他文件中详细说明并记录使用其他替代技术的理由。如果使用了相应表格中被认可 的技术组合，则无需说明和记录理由。应证明所选择的技术已被正确地应用。 4.9如果表格中未包含的技术或措施被提议使用，那么应对其在满足特定要求和子条款的整体目标方 面的有效性和适合性作论证，并在软件质量保证计划中或软件质量保证计划引用的其他文件中作相应 的记录。

4.10应通过审查本文件所要求的文档，适当

GB/T28808—2021

合特定子条款的要求和表格中详细列出的相应的技术和措施

5.1组织、角色和职责

5.1.2.1作为最低要求，供应商应执行GB/T19001中涉及人员、职责的组织和管理部分。 5.1.2.2职责应符合附录C的规定。 5.1.2.3被指定为参与软件开发或维护角色的人员应实行实名制并记录。 5.1.2.4评估方应由供应商、客户或安全主管部门指定。 5.1.2.5评估方应独立于供应商。但根据安全主管部门的意见，评估方也可是供应商组织或客户组 的一部分，但独立于开发项目。 5.1.2.6评估方应独立于项目。 5.1.2.7 应赋予评估人员足够的权力来实现对软件的评估。 5.1.2.8确认人员应给出同意/不同意软件发布的意见。 5.1.2.9在整个软件生命周期中，为达到软件安全完整性等级所要求的程度，人员角色的分配应符合 5.1.2.10~5.1.2.14的规定。首选的组织结构示意图见图2。

注1：CGM角色可与ASR以外的其他角色合并（见附录C的表C.10）。 注2：本图只是首选组织结构的一个示例

5.1.2.10针对SIL3和SIL4.首选的组纠

图2首选的组织结构示意图

自选的组织结构如下： a） 软件组件的需求经理、设计人员和实现人员可是同一个人。 b 软件组件的需求经理、设计人员和实现人员应向项目经理报告。 C 软件组件的集成人员和测试人员可是同一个人。 d 软件组件的集成人员和测试人员可向项目经理或确认人员报告。 e 验证人员或质量保证经理可向项目经理或确认人员报告。 f 确认人员不应向项目经理报告。也就是说项目经理不能影响确认人员的决策，但确认人员应 将自己的决定通知项目经理。 g 某个软件组件的需求经理、设计人员或实现人员不应是同一软件组件的测试人员和集成人员

h）某个软件组件的集成人员或测试人员不应是同一个软件组件的需求经理、设计人员和实现 人员。 i） 验证人员或质量保证经理既不应是需求经理、设计人员、实现人员、集成人员、测试人员，也不 应是确认人员。 j 确认人员不应是需求经理、质量保证经理、设计人员、实现人员、集成人员、测试人员和验证 人员。 k） 项目经理可额外担任需求经理、质量保证经理、设计人员、实现人员、集成人员、测试人员或验 证人员的角色，前提是这些额外角色之间的独立性要求得到遵守。 1 项目经理、需求经理、质量保证经理、设计人员、实现人员、集成人员、测试人员、验证人员和确 认人员可属于同一个组织。 m）评估人员应是独立的，并在组织上独立于项目经理、需求经理、质量保证经理、设计人员、实现 人员、集成人员、测试人员、验证人员和确认人员等角色。 下列选项可适用： 确认人员也可履行验证人员的角色，但仍独立于项目经理。在这种情况下，验证人员输出的文 件应由另一个与确认人员有相同独立性级别的能胜任的人员审查。该组织选项应经评估人员 同意。 0） 验证人员或质量保证经理也可履行集成人员和测试人员的角色，在这种情况下，确认人员应根 据指定的验证目标检查集成和测试过程中文档化证据的充分性。 1.2.11 针对SIL1和SIL2，首选的组织结构如下： 软件组件的需求经理、设计人员和实现人员可是同一个人，应向项目经理报告。 b） 软件组件的集成人员和测试人员可是同一个人。 c 软件组件的集成人员和测试人员可向项目经理或确认人员报告。 验证人员、质量保证经理和确认人员可是同一个人。 e） 验证人员、质量保证经理和确认人员可向项目经理报告。 f 软件组件的需求经理、质量保证经理、设计人员或实现人员不应是同一软件组件的测试人员和 集成人员。 g 软件组件的集成人员或测试人员不应是同一软件组件的需求经理、设计人员和实现人员。 h） 验证人员、质量保证经理或确认人员不应是需求经理、设计人员、实现人员、集成人员和测试 人员。 i 项目经理可额外担任需求经理、质量保证经理、设计人员、实现人员、集成人员、测试人员、验证 人员或确认人员的角色，前提是这些额外角色之间的独立性要求得到遵守。 项目经理、需求经理、质量保证经理、设计人员、实现人员、集成人员、测试人员、验证人员和确 认人员可属于同一组织。 k）评估人员应是独立的，并在组织上独立于项目经理、需求经理、质量保证经理、设计人员、实现 人员、集成人员、测试人员、验证人员和确认人员等角色。 下列选项适用： 1）验证人员或质量保证经理也可担任集成人员和测试人员的角色，在这种情况下，确认人员的作 用应包括审查验证人员或质量保证经理输出的文档，从而在项目组织内维持两级审查。 m） 确认人员也可担任验证人员、质量保证经理、集成人员和测试人员等角色。在这种情况下，验 证人员或质量保证经理的输出文档应由另一与确认人员相同独立级别的能胜任的人员审查。 该组织选项应经评估人员同意。 1.2.12针对SIL0，首选的组织结构如下： 饰成m通

b 软件组件的集成人员、测试人员、验证人员、质量保证经理和确认人员可是同一人； 集成人员、测试人员、验证人员、质量保证经理和确认人员可归项目经理管理； 软件组件的需求经理、设计人员或实现人员不应是同一软件组件的测试人员和集成人员； e） 软件组件的验证人员、质量保证经理或确认人员不应是需求经理、设计人员和实现人员； 项目经理可额外担任需求经理、质量保证经理、设计人员、实现人员、集成人员、测试人员、验证 人员或确认人员角色，条件是这些额外角色之间的独立性要求得到遵守； 8 项目经理、需求经理、质量保证经理、设计人员、实现人员、集成人员、测试人员、验证人员和确 认人员可归属于同一组织； h）评估人员应是独立的，并在组织上独立于项目经理、需求经理、质量保证经理、设计人员、实现 人员、集成人员、测试人员、验证人员和确认人员等角色。 下列选项适用： i）需求经理、设计人员、实现人员、集成人员和测试人员可是同一人； 确认人员、验证人员和质量保证经理可是同一人； k）验证人员、质量保证经理或确认人员不应是需求经理、设计人员和实现人员。 2.13某个组件的需求经理、设计人员和实现人员角色可担任不同组件的测试人员和集成人员 2.14 验证人员、质量保证经理和确认人员等角色应在项目级别定义，并在整个开发项目过程中应 不变。

通过证据显示在各种条件下能正确、高效、一致地执行相关任务达到高质量状态的能力，确保 软件负有责任的人员都有能力履行其职责。

5.2.2.1附录C定义了软件开发中每个角色所需的关键能力。如果在软件生命周期中某个角色需要 额外的经验、能力或资格，应在软件质量保证计划中规定。 5.2.2.2供应商组织应对有关人员能力的证明文件进行维护，包括技术知识、资格、相关经验和适当的 培训，以证明安全组织是合适的。 5.2.2.3一旦安全组织被证明满足了评估方的要求或通过承担各种角色的人员能力证明文件得到证 明，每个人仍需展示对其能力的持续维护和发展。这点可通过相关活动被定期执行的日志记录来证明， 且额外的培训是根据GB/T19001和ISO/IEC90003：2014中6.2.2进行的 5.2.2.4组织应根据现行质量标准对人员能力的管理程序进行维护，使人员能力与所承担的角色匹配

5.3.1.1将软件开发结构化为规定的阶段与活动。 5.3.1.2记录整个软件生命周期中所有与软件有关的信息

1.1将软件开发结构化为规定的阶段与活动。

个软件开发生命周期模型，并根据6.5的要求在软件质量保证计划中加以详细说明 图3和图4给出了两种生命周期模型的示例

主：软件评估是外部活动，并可在整个生命周期中得到实放

3开发生命周期示例1

图4开发生命周期示例2

5.3.2.2生命周期模型应允许阶段内和阶段间可能出现的迭代， 5.3.2.3质量保证过程应与生命周期活动并行，并使用相同的术语。 5.3.2.4应在项目启动时起草软件质量保证计划、软件验证计划、软件确认计划和软件配置管理计划， 并在整个软件开发生命周期中进行维护。 5.3.2.5各阶段需进行的所有活动应在该阶段开始之前定义并制定计划。 5.3.2.6月 所有文档应结构化，以便能随着开发过程不断扩展。 5.3.2.7 各个文档应有唯一的索引编号，与其他文档应有确定的、记录在案的文档关系，以便进行文档 追踪。 5.3.2.8 各文档对每个相同的术语、缩略语和简写词应有相同的解释。如果由于历史原因做不到这 点，就应列出不同的释义并给出参考文献。 5.3.2.9除既有软件（见7.3.4.7)的文档外，各文档应按下列规则书写： a）应包含或执行与其有层次关系的前期文档的所有适用条件和要求； b）不应与前期文档有矛盾，

5.3.2.2生命周期模型应允许阶段内和阶段间可能出现的迭代， 5.3.2.3质量保证过程应与生命周期活动并行，并使用相同的术语。 5.3.2.4应在项目启动时起草软件质量保证计划、软件验证计划、软件确认计划和软件配置管理计划， 并在整个软件开发生命周期中进行维护。 5.3.2.5各阶段需进行的所有活动应在该阶段开始之前定义并制定计划。 5.3.2.6月 所有文档应结构化，以便能随着开发过程不断扩展。 5.3.2.7 各个文档应有唯一的索引编号，与其他文档应有确定的、记录在案的文档关系，以便进行文档 追踪。 5.3.2.8 各文档对每个相同的术语、缩略语和简写词应有相同的解释。如果由于历史原因做不到这 点，就应列出不同的释义并给出参考文献。 5.3.2.9除既有软件（见7.3.4.7)的文档外，各文档应按下列规则书写： a）应包含或执行与其有层次关系的前期文档的所有适用条件和要求； b）不应与前期文档有矛盾

GB/T288082021

5.3.2.10在各个文档中，每个 条目或概念应采用相同的名称或描述来指称。 5.3.2.11所有文档内容应以适合于操作、处理和存储的形式来记录。 5.3.2.12由各独立角色编写的文档合并成单一文档时，各独立角色与其编写部分的对应关系在文档内 可追踪。 5.3.2.13根据5.3.2.12的要求，文件可合并或分开。经项目经理决定和确认人员同意，一些开发步骤 可合并、分解或合理删除。 5.3.2.14所选择的任何生命周期和文档结构都应满足本文件的所有目标和要求，文档控制见附录D

软件测试的目标是在选定的测试覆盖率可达到的范围内，根据相应的测试规格说明确定软件的行 性能，由测试人员和/或集成人员实施

。软件验证计划中规定的所有必需的系统、硬件和软件文

输出文档如下： a) 整体软件测试规格说明； b) 整体软件测试报告； c 软件集成测试规格说明； 软件集成测试报告； e) 软件/硬件集成测试规格说明； f) 软件/硬件集成测试报告； g) 软件组件测试规格说明； h) 软件组件测试报告。

6.1.4.1由其他成员（如需求经理、设计人员或实现人员）执行的测试，如果有完整的文档化记 循下列要求，可被验证人员接受。 6.1.4.2应校准用于测试的测量设备。用于测试的任何工具、硬件或软件，均应表明适合于测试 6.1.4.3 软件测试活动应按下列规定，形成测试规格说明文档和测试报告文档。 6.1.4.4每份测试规格说明应记录下列内容：

6.1.4.1由其他成员（如需求经理、设计人员或实现人员）执行的测试，如果有完整的文档化记录，并递 循下列要求，可被验证人员接受。 6.1.4.2应校准用于测试的测量设备。用于测试的任何工具、硬件或软件，均应表明适合于测试。 6.1.4.3软件测试活动应按下列规定，形成测试规格说明文档和测试报告文档。 6.1.4.4每份测试规格说明应记录下列内容

a）测试目标； b）测试用例、测试数据和预期结果； c) 实施的测试类型； d) 测试环境、工具、配置及程序； 判断测试完成的准则； f) 需要达到的测试覆盖率准则和程度； g）测试活动中所涉及人员的角色和职责；

GB/T288082021

h）测试规格说明所覆盖的需求； 软件测试设备的选择和利用。 6.1.4.5 应按下列要求生成测试报告： a) 测试报告应提供测试人员的姓名、陈述测试结果以及测试规格说明规定的测试目标和测试准 则是否得到满足，应记录并总结出现的失效； b） 应记录测试用例及其结果，最好是采用机器可读的方式进行记录，以便后续的分析； C） 测试应可重复，如果可行，则采用自动方式进行； d) 应验证用于自动测试执行的测试脚本； e) 应记录所有相关项（包含使用的硬件、使用的软件、使用的设备、设备校准、被测软件的版本信 息，以及测试规格说明的版本信息）的标识和配置； 应提供对测试覆盖率和测试完成度的评价，并记录所有偏差

软件验证的目标是检查并基于证据判断指定开发阶段的输出项（过程、文档、软件或应用）在 正确性和一致性方面是否满足要求和计划。

输出文档如下： a）软件验证计划； b）软件验证报告（可能多份）； c）软件质量保证验证报告

输出文档如下： a）软件验证计划； b）软件验证报告（可能多份）； c）软件质量保证验证报告。

6.2.4.1验证活动应文档化，至少要有软件验证计划和一份或多份（与过程相关的）验

要求6.2.4.36.2.4.9适用于软件验证计划。 6.2.4.3软件验证计划应描述为保证验证正确性将要实施的活动，并适当规定特定的设计或其他验证 需求。 6.2.4.4开发期间（根据系统的规模），软件验证计划可被分解为若干子文档，且随验证的详细要求逐渐 清晰而增加。 6.2.4.5软件验证计划应描述在验证过程中所有用到的准则、技术和工具，软件验证计划应包括从表 A.5、表A.6、表A.7、表A.8中选择的技术和措施，所选技术和措施的组合应被证明是满足4.8、4.9、4.10 的集合。 6.2.4.6软件验证计划应描述为确保阶段输入的正确性和一致性所要进行的活动。这些活动包括评 审、测试和集成。 6.2.4.7在每个开发阶段，应表明功能、性能和安全需求都得到满足。 6.2.4.8每次验证的结果应采用软件验证计划中规定的或引用的格式来保存。

要求6.2.4.3~6.2.4.9适用于软件验证计划。 6.2.4.3软件验证计划应描述为保证验证正确性将要实施的活动，并适当规定特定的设计或其他验证 需求。 6.2.4.4开发期间（根据系统的规模），软件验证计划可被分解为若干子文档，且随验证的详细要求逐渐 清晰而增加。 6.2.4.5软件验证计划应描述在验证过程中所有用到的准则、技术和工具，软件验证计划应包括从表 A.5、表A.6、表A.7、表A.8中选择的技术和措施，所选技术和措施的组合应被证明是满足4.8、4.9、4.10 的集合。 6.2.4.6软件验证计划应描述为确保阶段输入的正确性和一致性所要进行的活动。这些活动包括评 审、测试和集成。 6.2.4.7在每个开发阶段，应表明功能、性能和安全需求都得到满足。 6.2.4.8每次验证的结果应采用软件验证计划中规定的或引用的格式来保存。

4.9软件验证计划应指

6.3.1.1软件确认的目标是证明过程及其输出可做到：软件具有所定义的安全完整性等级，满足软件需 求且适合预期的应用。软件确认活动由确认人员进行。 6.3.1.2主要的确认活动是通过分析和/或测试证明所有的软件需求已按照适用的安全完整性等级要 求，被指定、被实现、被测试和得到满足，并根据评审、分析和测试的结果，评价所有异常和不符合项的安 全关键性。

本文件指定的所有系统、硬件和软件文档

输出文档包括： a）软件确认计划； b）软件确认报告。

6.3.4.1应由具备相应独立性级别，如5.1所定义的确认人员来开发和执行软件确认活动，并对其结果 进行评价。

6.3.4.4软件确认计划应包括一个概要来说明所选确认策略的合理性，根据所需的软件安全完整性等 级，其说明应包括下列方面的考虑： a）手动或自动化技术，或二者兼有； b）静态或动态技术，或二者兼有； c） 分析技术或统计技术，或二者兼有； d）真实环境或仿真环境中的测试，或二者兼有。 6.3.4.5软件确认计划应确定必要的步骤，以证明所有软件规格说明在满足系统安全需求规格说明中 陈述的安全需求方面的充分性。 6.3.4.6软件确认计划应确定必要的步骤，以证明整体软件测试规格说明作为对软件需求规格说明的 测试的充分性。

6.3.4.17仿真和建模可作为确认过程的补

GB/T288082021

6.4.1.1对生命周期过程及其输出进行评价，以判断软件是否具有规定的软件SIL1SIL4并适合预期 的应用。 6.4.1.2对于SIL0级软件，应满足本文件的要求，但是如果有符合GB/T19001的证书，则不需要进行 评估。

6.4.1.1对生命周期过程及其输出进行评价，以判断软件是否具有规定的软件SIL1～SIL4并适合预期 的应用。 6.4.1.2对于SIL0级软件，应满足本文件的要求，但是如果有符合GB/T19001的证书，则不需要进行 评估。

输人文档包括： a）系统安全需求规格说明； b）软件需求规格说明： c）实施评估过程必需的所有其他文档

输人文档包括： a）系统安全需求规格说明； b）软件需求规格说明； c）实施评估过程必需的所有其他文档

输出文档包括： a）软件评估计划； b）软件评估报告。

输出文档包括： a）软件评估计划； b）软件评估报告

6.4.4.5软件评估计划应包括下列内容！

6.4.4.8评估人员应评估系统的软件符合预期的目的，并对系统安全需求规格说明中的安全问题作出 正确响应。 6.4.4.9评估人员应根据所要求的安全完整性等级，评估是否从附录A中选择并应用了适用于预期开 发的技术集合。评估人员应评估来自附录A的每项技术被应用的程度，即它是否适用于所有或仅适用 于部分软件，同时还应查看它被正确应用的证据。 6.4.4.10评估人员应评估配置管理和变更管理体系，以及其使用和应用的证据。 6.4.4.11评估人员应根据附录C对项目成员能力的证据进行审查，并根据5.1的要求对软件开发的组 织进行评估。 6.4.4.12对于任何包含有安全相关应用条件的软件，评估人员应检查已注意到的偏差、与需求的不符 合项和已记录的不符合项，是否对安全有影响，同时判断项目组给出的理由是否可接受。结果应在评估

6.4.4.13评估人员应评估V&V活动，以及这些活动提供的证据。

4.4.13评估人员应评估V&V活动，以及这些活动提供的证据。 4.4.14软件确认计划的范围和内容应得到评估人员同意。同时明确相关测试过程评估人员应在 4.4.15评估人员可在整个开发过程中开展审核和审查（如测试见证)工作，评估人员可要求进行 JV&V工作。

6.4.4.16软件评估报告应由评估人员负责继

要求6.4.4.17~6.4.4.19适用于软件评估报告。 6.4.4.17软件评估报告应满足软件评估计划的要求，并提供结论和建议。 6.4.4.18评估人员应记录其自身活动以作为软件评估报告的一致性基础，并在软件评估报告中对此进 行概述。 6.4.4.19评估人员应识别和评价偏离本文件要求的任何不符合项，并判断其对最终结果的影响。这些 不符合项及其判断应在软件评估报告中列出

求的质量需采取的所有技术和管理活动。有必要针对 系统性故障提供所需的定性防护并确保会建立审核跟踪，以使V&V活动有效开展。 6.5.1.2提供上述活动已被执行的证据。

生命周期每个阶段所有可用的文档。

安全生产标准规范范本输出文档包括： a）软件质量保证计划； b）软件配置管理计划（如果系统级配置管理计划未涵盖相关内容）； c）软件质量保证验证报告。 注：软件质量保证报告包含在GB/T28809—2012定义的质量管理报告中

.5.4.11配直官理控

6.5.4.13供应商应建立、记录和维护外部供应商

a）确保外部供应商提供的软件满足既定要求的方法和相关记录。应确保以前开发的软件满足要 求的软件安全完整性等级和可信性。新软件应按照供应商的软件质量保证计划或由外部供应 商根据供应商的软件质量保证计划编制的具体软件质量保证计划来进行开发和维护。 ） 确保提供给外部供应商的需求是充分而完备的方法和相关记录。 6.5.4.14在安全相关系统的确认过程中，需求的可追踪性应是重要的考虑因素。应提供在生命周期所 有阶段均能证实这一点的方法。 6.5.4.15在本文件的上下文中，为与规定的软件安全完整性等级相适应，应特别强调可追踪性，可追踪 性应是配置管理的主题，包括： a 需求到设计或实现需求的其他对象的可追踪性； b 设计对象到将其实例化的实现对象的可追踪性； 需求和设计对象到对其进行验证的测试（组件测试、集成测试、整体软件测试）和分析的可追 踪性。 6.5.4.16在特殊情况下，如既有软件或原型软件，其追踪性可在代码实现和/或代码文件化之后，但在 验证/确认之前建立。在这种情况下，应表明验证/确认如同所有阶段都具有的追踪性那样有效。 6.5.4.17对于不能被充分跟踪的需求、设计或实现对象，应证明其对系统的安全性或完整性没有影响。

6.6.1.1确保软件按要求执行，在修改软件时应保持软件的安全完整性和可信性。 6.6.1.2上述目标由配置管理员进行管理

输入文档包括： a) 软件质量保证计划； b) 软件配置管理计划； c) 所有相关的设计、开发和分析文档； d) 变更申请； e) 变更影响分析和授权

输出文档包括： a）所有已发生变更的输人文档； b）软件变更记录（见9.2.4.10）； c）新的配置记录。

输出文档包括： a）所有已发生变更的输人文档； b） 软件变更记录（见9.2.4.10）； c）新的配置记录。

问题报告和/或纠正措施所需的文档，目的是向责任管理部门提供反馈； b） 问题报告中所汇集信息的分析螺纹标准，以识别其原因； c 在开发阶段和软件维护期间，报告、跟踪和解决已识别的问题应遵循的实践； d）有关开发和软件维护的特定组织的职责； e) 如何实施控制，以确保纠正行为已被采取并且有效； 对正在开发或已经交付的软件组件的变更的影响分析； g） 影响分析应陈述针对变更有必要开展的再验证、再确认和再评估； h）实施了多处变更的地方，影响分析时应分析累积影响； 注：累积若干变更后，可能要求一次完整的再测试。 i) 执行前的授权。 价段指定的程序执行，