RTCA DO-178C 机载系统和设备认证中的软件注意事项-软件开发流程 （五）

5.0 软件开发流程 SOFTWARE DEVELOPMENT PROCESSES

本节讨论软件开发过程的目标和活动。 软件开发过程按照软件计划过程（参见 4）和软件开发计划（参见 11.2）的定义进行应用。 附件 A 的表 A-2 总结了按软件级别划分的软件开发过程的目标和输出。 软件开发流程为：

This section discusses the objectives and activities of the software development processes. The software development processes are applied as defined by the software planning process (see 4) and the Software Development Plan (see 11.2). Table A-2 of Annex A is a summary of the objectives and outputs of the software development processes by software level. The software development processes are:

• 软件需求过程。Software requirements process.

• 软件设计过程。Software design process.

• 软件编码过程。Software coding process.

• 集成过程。Integration process.

软件开发过程产生一层或多层软件需求。 通过对系统需求和系统架构的分析直接产生高级需求。 通常，这些高级需求会在软件设计过程中进一步开发，从而产生一个或多个连续的较低级别的需求。 但是，如果源代码直接从高级需求生成，则高级需求也被视为低级需求，并且低级需求的指南也适用。

Software development processes produce one or more levels of software requirements. High-level requirements are produced directly through analysis of system requirements and system architecture. Usually, these high-level requirements are further developed during the software design process, thus producing one or more successive, lower levels of requirements. However, if Source Code is generated directly from high-level requirements, then the high-level requirements are also considered low-level requirements and the guidance for low-level requirements also apply.

注意：申请人可能需要证明产生单一级别需求的软件开发过程的合理性。

Note: The applicant may be required to justify software development processes that produce a single level of requirements.

软件架构的开发涉及对软件结构的决策。 在软件设计过程中，定义软件架构并开发低级需求。 低级需求是可以直接实现源代码而无需进一步信息的软件需求。

The development of software architecture involves decisions made about the structure of the software. During the software design process, the software architecture is defined and low-level requirements are developed. Low-level requirements are software requirements from which Source Code can be directly implemented without further information.

每个软件开发过程都可能产生派生需求。 可能被确定为派生需求的一些需求示例是：

Each software development process may produce derived requirements. Some examples of requirements that might be determined to be derived requirements are:

• 需要为所选目标计算机开发中断处理软件。The need for interrupt handling software to be developed for the chosen target computer.

• 当分配给软件的系统需求未指定时，定期监视器迭代率的规范。The specification of a periodic monitor’s iteration rate when not specified by the system requirements allocated to software.

• 使用定点运算时增加缩放限制。The addition of scaling limits when using fixed point arithmetic.

高级需求可以包括派生需求，低级需求可以包括派生需求。 为了确定派生需求对系统安全评估和系统需求的影响，所有派生需求应可供系统过程（包括系统安全评估过程）使用。

High-level requirements may include derived requirements, and low-level requirements may include derived requirements. In order to determine the effects of derived requirements on the system safety assessment and system requirements, all derived requirements should be made available to the system processes including the system safety assessment process.

5.1软件需求流程 Software Requirements Process

软件需求过程使用系统生命周期过程的输出来开发高级需求。 这些高级要求包括功能、性能、接口和安全相关的要求。The software requirements process uses the outputs of the system life cycle processes to develop the high-level requirements. These high-level requirements include functional, performance, interface, and safety-related requirements.

5.1.1 软件需求过程目标 Software Requirements Process Objectives

软件需求过程的目标是：The objectives of the software requirements process are:

a. 制定了高级需求。High-level requirements are developed.

b. 定义派生的高级要求并将其提供给系统流程，包括系统安全评估流程。Derived high-level requirements are defined and provided to the system processes, including the system safety assessment process.

5.1.2 软件需求过程活动 Software Requirements Process Activities

软件需求过程的输入包括来自系统生命周期过程的系统需求、硬件接口和系统架构（如果未包含在需求中），以及来自软件计划过程的软件开发计划和软件需求标准。 当满足计划的过渡标准时，这些输入将用于开发高级要求。

Inputs to the software requirements process include the system requirements, the hardware interface and system architecture (if not included in the requirements) from the system life cycle processes, and the Software Development Plan and the Software Requirements Standards from the software planning process. When the planned transition criteria have been satisfied, these inputs are used to develop the high-level requirements.

该过程的主要输出是软件需求数据（参见 11.9）。

The primary output of this process is the Software Requirements Data (see 11.9).

当软件需求过程的目标和与之相关的整体过程的目标得到满足时，软件需求过程就完成了。 此过程的活动包括：

The software requirements process is complete when its objectives and the objectives of the integral processes associated with it are satisfied. Activities for this process include:

a. 应分析分配给软件的系统功能和接口需求是否存在歧义、不一致和未定义的情况。The system functional and interface requirements that are allocated to software should be analyzed for ambiguities, inconsistencies, and undefined conditions.

b. 检测到不充分或不正确的软件需求过程的输入应作为反馈报告给输入源过程以进行澄清或纠正。 Inputs to the software requirements process detected as inadequate or incorrect should be reported as feedback to the input source processes for clarification or correction.

c. 分配给软件的每个系统需求都应在高级需求中指定。Each system requirement that is allocated to software should be specified in the high-level requirements.

d. 应定义解决分配给软件的系统需求以防止系统危险的高级要求。High-level requirements that address system requirements allocated to software to preclude system hazards should be defined.

e. 高级需求应该符合软件需求标准，并且是可验证的和一致的。The high-level requirements should conform to the Software Requirements Standards, and be verifiable and consistent.

f. 高级需求应以定量形式表述，并在适用的情况下带有公差。The high-level requirements should be stated in quantitative terms with tolerances where applicable.

g. 除了指定和合理的设计约束之外，高级需求不应描述设计或验证细节。 The high-level requirements should not describe design or verification detail except for specified and justified design constraints.

h. 应定义派生的高级需求及其存在的原因。Derived high-level requirements and the reason for their existence should be defined.

i. 应向系统过程提供派生的高级要求，包括系统安全评估过程。 Derived high-level requirements should be provided to the system processes, including the system safety assessment process.

j. 如果规划了参数数据项，则高级需求应描述软件如何使用任何参数数据项。 高级需求还应指定其结构、每个数据元素的属性以及每个元素的值（如果适用）。 参数数据项元素的值应与参数数据项的结构及其数据元素的属性一致。 If parameter data items are planned, the high-level requirements should describe how any parameter data item is used by the software. The high-level requirements should also specify their structure, the attributes for each of their data elements, and, when applicable, the value of each element. The values of the parameter data item elements should be consistent with the structure of the parameter data item and the attributes of its data elements.

5.2 软件设计过程 Software Design Process

高级需求通过软件设计过程中的一次或多次迭代来细化，以开发软件架构和可用于实现源代码的低级需求。

The high-level requirements are refined through one or more iterations in the software design process to develop the software architecture and the low-level requirements that can be used to implement Source Code.

5.2.1软件设计过程目标 Software Design Process Objectives

软件设计过程的目标是：

The objectives of the software design process are:

a. 软件架构和低层需求是从高级需求发展而来的。The software architecture and low-level requirements are developed from the highlevel requirements.

b. 定义派生的低级要求并将其提供给系统流程，包括系统安全评估流程。Derived low-level requirements are defined and provided to the system processes, including the system safety assessment process.

5.2.2 软件设计过程活动 Software Design Process Activities

软件设计过程的输入是软件需求数据、软件开发计划和软件设计标准。 当满足计划的转换准则时，在设计过程中使用高级需求来开发软件架构和低级需求。 这可能涉及一项或多项较低级别的要求。

The software design process inputs are the Software Requirements Data, the Software Development Plan, and the Software Design Standards. When the planned transition criteria have been satisfied, the high-level requirements are used in the design process to develop software architecture and low-level requirements. This may involve one or more lower levels of requirements.

该过程的主要输出是设计描述（参见 11.10），其中包括软件架构和低级需求。

The primary output of the process is the Design Description (see 11.10) which includes the software architecture and the low-level requirements.

当软件设计过程的目标和与之相关的整体过程的目标得到满足时，软件设计过程就完成了。 此过程的活动包括：

The software design process is complete when its objectives and the objectives of the integral processes associated with it are satisfied. Activities for this process include:

a. 软件设计过程中开发的底层需求和软件架构应符合软件设计标准，并且可追溯、可验证和一致。Low-level requirements and software architecture developed during the software design process should conform to the Software Design Standards and be traceable, verifiable, and consistent.

b. 应定义和分析派生的低级别需求及其存在的原因，以确保较高级需求不会受到损害。Derived low-level requirements and the reason for their existence should be defined and analyzed to ensure that the higher level requirements are not compromised.

c. 软件设计过程活动可能会将可能的故障模式引入软件中，或者相反，排除其他模式。 在软件设计中使用分区或其他架构手段可能会改变软件某些组件的软件级别分配。 在这种情况下，应将附加数据定义为派生要求并提供给系统流程，包括系统安全评估流程。Software design process activities could introduce possible modes of failure into the software or, conversely, preclude others. The use of partitioning or other architectural means in the software design may alter the software level assignment for some components of the software. In such cases, additional data should be defined as derived requirements and provided to the system processes, including the system safety assessment process.

d. 软件组件之间的接口（以数据流和控制流的形式）应定义为在组件之间保持一致。Interfaces between software components, in the form of data flow and control flow, should be defined to be consistent between the components.

e. 当安全相关要求规定时，应监控控制流和数据流，例如看门狗定时器、合理性检查和跨通道比较。Control flow and data flow should be monitored when safety-related requirements dictate, for example, watchdog timers, reasonableness-checks, and cross-channel comparisons.

f. 对故障情况的响应应符合安全相关要求。Responses to failure conditions should be consistent with the safety-related requirements.

g. 在软件设计过程中检测到的不充分或不正确的输入应提供给系统生命周期过程、软件需求过程或软件计划过程，作为澄清或纠正的反馈。Inadequate or incorrect inputs detected during the software design process should be provided to the system life cycle processes, the software requirements process, or the software planning process as feedback for clarification or correction.

注意：软件工程的当前状态不允许复杂性与系统安全目标的实现之间存在定量关联。 虽然无法提供客观指导，但软件设计过程应避免引入复杂性，因为随着软件复杂性的增加，验证设计并证明满足安全相关要求变得更加困难。

Note: The current state of software engineering does not permit a quantitative correlation between complexity and the attainment of system safety objectives. While no objective guidance can be provided, the software design process should avoid introducing complexity because as the complexity of software increases, it becomes more difficult to verify the design and to show that the safety-related requirements are satisfied.

5.2.3 设计用户可修改的软件 Designing for User-Modifiable Software

用户可修改的软件旨在由其用户进行修改。 可修改组件是软件中旨在由用户更改的部分，不可修改组件是用户不希望更改的部分。 用户可修改的软件的复杂性可能有所不同。 示例包括用于选择两个设备选项之一的单个存储器位、消息表或可以编程、编译和链接以实现维护功能的存储器区域。 任何级别的软件都可以包含可修改的组件。

User-modifiable software is designed to be modified by its users. A modifiable component is that part of the software that is intended to be changed by the user and a non-modifiable component is that which is not intended to be changed by the user. User-modifiable software may vary in complexity. Examples include a single memory bit used to select one of two equipment options, a table of messages, or a memory area that can be programmed, compiled, and linked for maintenance functions. Software of any level can include a modifiable component.

用户可修改软件的活动包括：

The activities for user-modifiable software include:

a. 应保护不可修改组件免受可修改组件的影响，以防止干扰不可修改组件的安全操作。 这种保护可以通过硬件、软件、用于进行更改的工具或三者的组合来实施。 如果保护是由软件提供的，则应在与不可修改的软件相同的软件级别上进行设计和验证。 如果保护是由工具提供的，则该工具应按照第 12.2 节中的定义进行分类和鉴定。The non-modifiable component should be protected from the modifiable component to prevent interference in the safe operation of the non-modifiable component. This protection can be enforced by hardware, by software, by the tools used to make the change, or by a combination of the three. If the protection is provided by software, it should be designed and verified at the same software level as the non-modifiable software. If the protection is provided by a tool, the tool should be categorized and qualified as defined in section 12.2.

b. 所提供的用于更改可修改组件的方法应被证明是可以更改可修改组件的唯一方法。The means provided to change the modifiable component should be shown to be the only means by which the modifiable component can be changed.

5.2.4 针对停用代码进行设计 Designing for Deactivated Code

系统或设备可以设计为包括多种配置，并非所有配置都旨在用于每种应用。 这可能会导致无法执行的停用代码，例如未选择的功能或未使用的库函数或未使用的数据。 停用代码与死代码不同。 停用代码的活动包括：

Systems or equipment may be designed to include several configurations, not all of which are intended to be used in every application. This can lead to deactivated code that cannot be executed, such as unselected functionality or unused library functions, or data that is not used. Deactivated code differs from dead code. The activities for deactivated code include:

a. 应设计和实施一种机制，以确保停用的功能或组件不会对活动的功能或组件产生不利影响。A mechanism should be designed and implemented to assure that deactivated functions or components have no adverse impact on active functions or components.

b. 应有证据表明已停用的代码在不打算使用的环境中被禁用。 由于异常系统条件而导致的停用代码的意外执行与激活代码的意外执行相同。Evidence should be available that the deactivated code is disabled for the environments where its use is not intended. Unintended execution of deactivated code due to abnormal system conditions is the same as unintended execution of activated code.

c. 停用代码的开发与活动代码的开发一样，应符合本文档的目标。The development of deactivated code, like the development of the active code, should comply with the objectives of this document.

5.3 软件编码过程 Software Coding Process

在软件编码过程中，源代码是从软件架构和低级需求开始实现的。

In the software coding process, the Source Code is implemented from the software architecture and the low-level requirements.

注意：就本文档而言，编译、链接和加载是在集成过程下处理的（参见 5.4）。

Note: For the purpose of this document, compiling, linking, and loading are dealt with under the Integration Process (see 5.4).

5.3.1 软件编码过程目标 Software Coding Process Objectives

软件编码过程的目标是：The objective of the software coding process is:

a. 源代码是根据低级需求开发的。Source Code is developed from the low-level requirements.

5.3.2 软件编码过程活动 Software Coding Process Activities

编码过程输入是来自软件设计过程、软件开发计划和软件编码标准的低级需求和软件架构。 当满足计划的转换标准时，可以进入或重新进入软件编码过程。 源代码是根据软件架构和低级需求通过此过程生成的。

The coding process inputs are the low-level requirements and software architecture from the software design process, the Software Development Plan, and the Software Code Standards. The software coding process may be entered or re-entered when the planned transition criteria are satisfied. The Source Code is produced by this process based upon the software architecture and the low-level requirements.

该过程的主要输出是源代码（参见 11.11）。

The primary output of this process is Source Code (see 11.11).

当软件编码过程的目标以及与之相关的整体过程的目标得到满足时，软件编码过程就完成了。 此过程的活动包括：

The software coding process is complete when its objectives and the objectives of the integral processes associated with it are satisfied. Activities for this process include:

a. 源代码应该实现低级需求并符合软件架构。The Source Code should implement the low-level requirements and conform to the software architecture.

b. 源代码应符合软件编码标准。 The Source Code should conform to the Software Code Standards.

c. 在软件编码过程中检测到的不充分或不正确的输入应提供给软件需求过程、软件设计过程和/或软件计划过程作为澄清或纠正的反馈。Inadequate or incorrect inputs detected during the software coding process should be provided to the software requirements process, software design process, and/or software planning process as feedback for clarification or correction.

d. 自动代码生成器的使用应符合规划过程中定义的约束。Use of autocode generators should conform to the constraints defined in the planning process.

5.4 集成过程 Integration Process

目标计算机和软件编码过程中的源代码与集成过程中的编译、链接和加载数据（见11.16）一起使用，以开发集成系统或设备。

The target computer and the Source Code from the software coding process are used with the compiling, linking, and loading data (see 11.16) in the integration process to develop the integrated system or equipment.

5.4.1集成过程目标 Integration Process Objectives

集成过程的目标是：The objective of the integration process is:

a. 生成可执行目标码及其关联的参数数据项文件（如果有）并将其加载到目标硬件中以进行硬件/软件集成。The Executable Object Code and its associated Parameter Data Item Files, if any, are produced and loaded into the target hardware for hardware/software integration.

5.4.2 集成过程流程 Integration Process Activities

集成过程包括软件集成和软硬件集成。The integration process consists of software integration and hardware/software integration.

当满足计划的转换准则时，可以进入或重新进入集成过程。 集成过程的输入是来自软件设计过程的软件架构和来自软件编码过程的源代码。

The integration process may be entered or re-entered when the planned transition criteria have been satisfied. The integration process inputs are the software architecture from the software design process, and the Source Code from the software coding process.

集成过程的输出是目标代码； 可执行目标码（见11.12）； 参数数据项文件（见11.22）； 以及编译、链接和加载数据。 当集成过程的目标以及与之相关的集成过程的目标得到满足时，集成过程就完成了。 此过程的活动包括：

The outputs of the integration process are the object code; Executable Object Code (see 11.12); Parameter Data Item File (see 11.22); and the compiling, linking, and loading data. The integration process is complete when its objectives and the objectives of the integral processes associated with it are satisfied. Activities for this process include:

a. 目标码和可执行目标码应从源代码生成并编译、链接和加载数据。 应生成任何参数数据项文件。The object code and Executable Object Code should be generated from the Source Code and compiling, linking, and loading data. Any Parameter Data Item File should be generated.

b. 软件集成应在主机、目标计算机模拟器或目标计算机上执行。Software integration should be performed on a host computer, a target computer emulator, or the target computer.

c. 应将软件加载到目标计算机中以进行硬件/软件集成。The software should be loaded into the target computer for hardware/software integration.

d. 在集成过程中检测到的不充分或不正确的输入应提供给软件需求过程、软件设计过程、软件编码过程或软件计划过程，作为澄清或纠正的反馈。Inadequate or incorrect inputs detected during the integration process should be provided to the software requirements process, the software design process, the software coding process, or the software planning process as feedback for clarification or correction.

e. 补丁不应在提交用于认证产品的软件中使用，以实现需求或体系结构的更改，或由于软件验证过程活动而发现必要的更改。 补丁可以在有限的、具体情况的基础上使用，例如，以解决软件开发环境中的已知缺陷，例如已知的编译器问题。Patches should not be used in software submitted for use in a certified product to implement changes in requirements or architecture, or changes found necessary as a result of the software verification process activities. Patches may be used on a limited, case-by-case basis, for example, to resolve known deficiencies in the software development environment such as a known compiler problem.

f. 使用补丁时，这些应该可用： When a patch is used, these should be available:

1. 确认软件配置管理流程能够有效跟踪补丁。Confirmation that the software configuration management process can effectively track the patch.

2. 提供证据证明修补软件满足所有适用目标的分析。 An analysis to provide evidence that the patched software satisfies all the applicable objectives.

3. 软件完成摘要中使用补丁的理由。 Justification in the Software Accomplishment Summary for use of a patch.

5.5 软件开发过程的可追溯性 Software Development Process Traceability

软件开发过程可追溯活动包括：Software development process traceability activities include:

a. 开发了跟踪数据，显示分配给软件的系统需求和高级需求之间的双向关联。 此跟踪数据的目的是：Trace Data, showing the bi-directional association between system requirements allocated to software and high-level requirements, is developed. The purpose of this Trace Data is to:

1. 验证分配给软件的系统需求的完整实施。 Enable verification of the complete implementation of the system requirements allocated to software.

2. 使那些无法直接追踪到系统需求的派生高级需求变得可见。Give visibility to those derived high-level requirements that are not directly traceable to system requirements.

b. 开发了跟踪数据，显示高级需求和低级需求之间的双向关联。 此跟踪数据的目的是：Trace Data, showing the bi-directional association between the high-level requirements and low-level requirements, is developed. The purpose of this Trace Data is to:

1. 验证高级要求的完整实施。Enable verification of the complete implementation of the high-level requirements.

2. 提供对那些无法直接追溯到高级需求以及在软件设计过程中做出的架构设计决策的衍生低级需求的可见性。 Give visibility to those derived low-level requirements that are not directly traceable to high-level requirements and to the architectural design decisions made during the software design process.

c. 开发了跟踪数据，显示低级需求和源码之间的双向关联。 此跟踪数据的目的是：Trace Data, showing the bi-directional association between low-level requirements and Source Code, is developed. The purpose of this Trace Data is to:

1. 启用验证，确保没有源代码实现未记录的功能。Enable verification that no Source Code implements an undocumented function.

2. 启用对低级需求的完整实施的验证。 Enable verification of the complete implementation of the low-level requirements.