系统架构过程基础知识汇总

1.目的

系统架构过程的目的是生成系统架构备选方案，选择框架利益攸关方关注并满足系统需求的一个或多个备选方案，并在一组一致的视图中表达这一点。。

应该注意的是，下面的架构活动与系统定义活动和概念定义活动都是重叠的。特别地，操作和业务环境的关键方面，以及某些利益攸关方的需求，强烈地影响架构开发和描述所采用的方法。此外，架构活动将推动选择和适应所选择的解决方案集成方法。

2.过程的活动

在此过程中执行的主要活动和任务包括:

3.初始化系统架构的定义

建立对系统所需要的使用环境/环境的理解，以建立对利益攸关方关注点的洞察力。为此，分析相关的市场、行业、利益相关方、企业、业务、运营、使命、法律和其他有助于理解可以指导系统架构视图和模型定义的透视图的信息。

捕获利益攸关方关注的问题(例如。跨越系统生命周期各阶段的期望或约束)。这些问题通常与与各阶段有关的系统的关键特性有关;它们应该被转换成或合并到系统需求中。

处理操作条件(例如，安全性、安全性、可靠性、人为因素、接口、环境条件)和生命周期约束(例如，维护、处置、部署)的标签系统需求会影响架构要素的定义。

建立架构路线图和策略，其中应包括方法、建模技术、工具、任何支持系统、产品或服务的需求、过程需求(例如，度量方法和方法)、评估过程(例如，评审和标准)。

计划产品或服务的获取(需要、需求、采购)。

4.定义必要的架构观点

基于确定的利益攸关方关注点，确定可能支持模型和视图开发的相关架构视点和架构框架。

5.开发候选架构模型和视图

使用相关的建模技术和工具，并结合利益攸关方的需求和需求过程以及系统需求过程，确定系统的环境，包括外部环境要素的边界。这个任务包括识别相关系统与外部要素的关系、接口或连接、交换和交互。此任务允许定义或理解其使用环境中的预期操作场景和/或系统行为。

定义架构实体(例如,功能,输入/输出流,系统要素,物理接口、架构特点、信息/数据要素、容器、节点、链接、通信资源,等等),解决不同类型的系统需求(例如,功能需求、接口需求、环境需求、操作条件(可靠性、人为因素等),约束(物理尺寸、生产、维护、处理))。

将架构实体与与系统利益（SoI）架构的决策相关的概念、属性、特征、行为、功能和/或约束联系起来。这就产生了架构特性(例如，通用性、模块化、可操作性、效率、简单性)。

选择、调整或开发系统的候选架构的模型，例如逻辑和物理模型(请参阅逻辑架构模型开发和物理架构模型开发)。有时使用逻辑和物理模型既不是必要的，也不是充分的。要使用的模型是那些最好地处理关键利益攸关方关注点的模型。

从候选架构的模型中，组合与利益攸关方关注点和关键或重要需求相关的视图。

定义由架构实体的必要实例(如功能、接口)和结构配置(如约束、操作条件)引起的派生系统需求。使用系统需求定义过程来定义和形式化它们。

检查模型和视图的一致性并解决任何确定的问题。ISO/IEC/IEEE 42010, 2011可用于此。

如果建模技术和工具允许的话，通过执行或模拟来验证和确认模型。在可能的情况下，使用设计工具检查可行性和有效性，和/或实现部分模型，或使用可执行的架构原型或模拟器。

5.将系统架构与系统设计联系起来

定义反映架构特征的系统要素(当架构是设计不可知的，这些系统要素可能只是概念上的，直到设计开发)。为此，对系统要素进行划分、对齐和分配架构特征和系统需求。建立系统设计和演进的指导原则。有时，一个“参考架构”是使用这些概念系统要素创建的，作为传达架构意图和检查设计可行性的方式。

为那些对于架构的详细程度和理解是必要的定义接口。这包括系统要素之间的内部接口以及与其他系统之间的外部接口。

确定适用于系统要素的设计属性，以满足架构特征。

对于组成系统的每个系统要素，开发与分配、对齐和划分设计属性和系统要素需求相对应的需求。为此，使用利益攸关方需求和需求定义过程和系统需求定义过程。

6.评估架构候选者并选择一个

使用架构评估标准评估候选架构。这是通过应用系统分析、度量和风险管理过程来实现的。

选择首选的架构。这是通过应用决策管理过程来实现的。

7.管理选定的架构

为架构、架构框架、视点、模型种类和架构模型的可选方案和决策之间的所有选择建立并维护基本原理。

管理架构描述的维护和开发，包括模型和视图。这包括一致性、完整性、由于环境或环境变化而发生的变化，以及技术、实现和操作经验。分配和可追溯性矩阵用于分析对架构的影响。当前过程在系统发生演化的任何时候都被执行。

建立架构治理的方法。治理包括角色、职责、权限和其他控制功能。

协调架构的评审以达成利益攸关方的协议。利益攸关方需求和系统需求可以作为参考。

8.工件、方法和建模技术

这个过程可能会创建一些工件，例如系统架构描述文档和系统证明文档(可跟踪矩阵和架构选择)。

这些工件的内容、格式、布局和所有权可能会因创建它们的人和使用它们的域而有所不同。流程活动的输出应该包含本文第一部分中确定的信息。

9.实际考虑

9.1陷阱

表3提供了计划和执行系统架构时遇到的一些关键缺陷。

陷阱	描述
问题的相关性	如果架构的开发没有来自利益攸关方关注的输入，或者不能被理解并与他们的问题相关，那么它可能会失去利益攸关方社团的投资。
系统要素的复用	在某些项目中，就工业用途而言，现有产品或服务很早就作为架构/设计的约束被强加于利益攸关方需求或系统需求中，而没有对包含它们的系统的新使用环境给予足够的重视。最好从一开始就朝着正确的方向付出。首先定义系统，注意其他需求，然后看看是否有合适的非开发项目(NDI)可用。不要从一开始就强加系统要素，这会减少贸易空间。正确的复用过程包括在每个使用环境中定义可复用的系统要素。

9.2实践证明

表4提供了从参考资料中收集的一些经过验证的实践。

实践	描述
新兴的属性	控制系统或系统要素之间相互作用的涌现性;获得所需的协同特性，控制或避免不良行为(振动、噪声、不稳定、共振等)

责任编辑：PSY

原文标题：系统架构过程方法

文章出处：【微信公众号：汽车电子硬件设计】欢迎添加关注！文章转载请注明出处。