中文翻译《ASPICE in practice》之“ENG.3 系统架构设计”

2.5 ENG.3 系统架构设计

2.5.1 目的

系统架构设计过程的目的是确定哪些系统需求应分配给系统的哪些元素。

在顶层，系统架构描述了所有系统元素、它们之间的关系以及接口。对于每个系统元素，必须知道相关的系统需求。

2.5.2 汽车行业特有的特征

在定义系统架构设计时，需要决定哪些功能将在硬件中实现，哪些功能将在软件中实现。例如，必须决定是否使用现有 LCD 显示器的软件控制功能或单独的 LED 来实现显示功能。

在复杂系统中，将系统划分为其元素通常需要几个步骤或描述级别。在这些情况下，描述由几个相关文档组成，其详细程度各不相同。图 2-5 提供了早期阶段系统架构设计的示例。图 2-6 包含较低描述级别的示例。

图 2-5 无线电导航系统的顶层系统架构设计示例

图 2-6 低级系统架构设计描述示例

2.5.3 基本实践

BP1：定义系统架构设计。建立系统架构设计，根据功能性和非功能性系统要求确定系统元素。

注意：如有必要，系统可以分解为不同系统级别的多个子系统。

系统架构设计是最上层、最通用的描述级别，以概览图、列表和系统元素描述的形式呈现。它由已确定的元素组成，这些元素与系统要求相对应，需要实施。在系统架构设计期间，还需要制定相应的验证标准。此要求来自 ENG.3 中对过程结果的注释。验证标准指定需要满足哪些条件才能认为系统架构设计（主要通过集成测试）已成功验证。

BP2：分配系统需求。将所有系统需求分配给系统架构设计的各个元素。

尽可能将已识别的功能性和非功能性系统需求分配给系统架构设计组件。目标是尝试分配所有需求，以确保在充分考虑所有约束的情况下所有系统元素无故障交互，并避免迭代循环。在由许多相互关联的子系统或系统元素组成的复杂系统中，这种分配在那个阶段并不总是可行的。典型的原因是，在这个早期阶段尚未做出详细的设计决策，并且尚未就相关需求的相关性做出任何决定。分配必须在以后进行。一些（尤其是非功能性）需求适用于整个系统，因此不可能分配给单个系统组件。

例如，可以通过在考虑系统架构设计的情况下构建系统需求描述（例如，系统规范）来实现分配。任务的结果是系统需求和系统架构设计之间的可追溯性。

BP3：定义接口。识别、开发和记录每个系统元素的内部和外部接口。

在顶层，给出了系统元素如何交互以及系统如何在与其他系统交互时发挥作用以实现所需的系统功能（在 ENG.2 中标识）的定义和描述。

在此过程中，区分了内部和外部接口。内部接口描述各个系统元素之间的交互。接口描述可以记录在系统架构设计中，也可以记录在单独的文档中。它们通常用于描述某些细节，例如，在编码与硬件相关的层时或使用现有驱动程序或操作系统时要考虑的细节。

外部接口是系统与其他系统的接口，例如数据传输、显示和控制元件或传感器/执行器。

BP4：验证系统架构设计。确保系统架构满足所有系统要求。

根据系统要求检查系统架构可以采用不同的形式。除了涉及不同小组的协调会议外，建议进行架构审查并记录结果。在实践中，一开始可能很难将所有要考虑的因素映射到系统要求上。因此，全面合作很重要。

协调会议有助于大幅降低概念变更的风险，因此，在项目后期阶段，变更的成本可能更高。协调的需求不仅存在于内部，也存在于外部合作伙伴。内部合作应与参与项目的所有个人达成一致。这些包括：

1. 采购部门，因为例如，必须就第三方系统组件（例如，标准软件、电子组件）达成一致并采购。需要合作，特别是在第三方采购标准化、保障交付可靠性等方面。
2. 领域代表负责协调战略发展问题
3. 其他或并行项目的代表，在平台开发过程中将从这些项目中接管元素
4. 必须参与系统架构设计的设计师、开发人员和测试人员

在以下情况下需要外部协调：

1. 如果必须明确指定外部系统接口并与客户协调，因为正在开发的系统通常会集成到由其他（可能同等）系统组成的环境中，
2. 如果客户在系统架构设计方面有发言权，因为他指定或禁止特定的系统组件（例如，操作系统或特定驱动程序）。

BP5：确保系统需求与系统架构设计的一致性和双向可追溯性。确保系统需求（包括验证标准）与系统架构设计（包括验证标准）的一致性。通过在系统需求（包括验证标准）和系统架构设计（包括验证标准）之间建立和维护双向可追溯性来支持一致性。

此检查的基础是系统需求与系统架构设计之间的可追溯性；有关这一点，请参阅 BP2。必须确定在系统架构设计中已考虑了每个系统需求，并且对于系统架构的每个元素，相关的系统需求都是已知的，并且系统需求和系统架构设计是一致的。在项目期间，必须注意保持完整的可追溯性。因此，如果不重复系统需求分析的相关步骤，则不能对系统架构设计进行任何与需求相关的更改，反之亦然。如果设计需求不是基于系统需求，则最好（但不是强制性的）记录它们的来源和必要性。

可追溯性要求也扩展到系统架构验证标准。最好在审查期间检查与系统需求的一致性。应特别注意检查两种验证标准是否一致，以便有效地协调系统和系统集成测试，并确保两者之间的一致性。

BP6：传达系统架构设计。建立沟通机制，向所有相关方传播系统架构设计。

这是为了确保从事系统架构设计或受其变化影响的工程师及时了解情况，并能够在自己的工作中对此类修改做出反应或考虑此类修改。ENG.2 BP7 中关于沟通机制的陈述也可以在这里应用。

2.5.4 指定工作产品

04-06 系统架构设计

系统架构设计概述了整个系统的结构，并描述了各个元素（包括软件）的交互。整个系统通常由一个或多个“框图”组成，这些框图说明了系统元素以及它们之间的相互关系和数据流。这些概览图通常辅以技术描述（接口描述）。在复杂系统中，描述可能由多个相关文档组成，这些文档的细节各不相同。在这种情况下，重要的是跨多个细节程度的需求/功能的可追溯性（参见图 2-5 和图 2-6 中的示例）。

13-22 可追溯性记录

参见 ENG.2

13-25 验证结果

系统架构设计针对系统需求的验证结果（参见 BP4）以审查或会议支持记录、已完成的检查表和验证日志的形式体现（有关此工作产品的进一步说明，请参阅 SUP.2）。

2.5.5  2 级的特征

关于绩效管理

系统架构必须系统地设计。实际上，在多次迭代中重复的小工作步骤很少会详细规划。但是，较大的工作步骤（例如，指示何时需要提供不同版本的系统架构设计的里程碑）必须明确规划和记录。如果在某些里程碑处需要更新系统架构设计，则必须在项目计划中进行规划。

关于工作产品管理

过程属性 PA 2.2 的要求与系统架构特别相关。除其他外，它们要求对系统架构进行审查，并根据情况由客户接受。基线包括与每种情况相关的系统架构。