| 系统工程系(SE)以 跨领域的方法及手段 ，
从而确保成功 地 集成 系统 。
成功地集成 系统 必须满足其客户、用户和其他涉众的需求。本文概述了SEBoK中讨论的SE以及SE和系统之间的关系(有关此方面的更多信息，请参阅第2部分)。
系统与系统工程
在广泛的社区中，“系统”一词可能意味着技术、自然或社会因素的集合，或三者的组合。这有时可能会产生歧义：例如，“管理”是指SE过程的管理，还是指正在设计的系统的管理？与许多特殊领域一样，SE使用术语的方式在领域之外可能并不熟悉。例如，在系统领域和SE中，“开放”意味着系统能够与其环境进行交互，而不是与环境“封闭”。然而，在更广泛的工程世界中，我们将“开放”理解为“非专有”或“公开同意”在这种情况下，SEBoK试图通过详细阐述替代方案来避免误解，例如“系统管理”或“系统工程管理”。
SEBoK试图将SE定位在更广泛的知识范围内，将系统视为其基础的一部分。为了在不重新定义通用系统术语的情况下实现这一点，SEBoK引入了两个特定于SE的相关定义：
- 工程系统是技术或社会技术系统，是SE生命周期的主题。它是一个设计或调整的系统，用于与预期的操作环境交互，以实现一个或多个预期目的，同时遵守适用的约束条件。
- 工程系统上下文以工程系统为中心，但在其关系中还包括一个或多个定义环境中的其他工程、社会或自然系统。
由于 SE 属于 工程系统 ，大多数SE文献在其术语中都假设这一点。因此，在SE讨论中，“系统架构”指的是正在设计的系统架构（例如航天器），而不是其边界之外的自然系统架构（例如太阳系）。事实上，航天器结构将涵盖更广泛的系统环境，包括重力和外部气压变化等外部因素，以及这些因素如何影响航天器的技术和人为因素。因此，术语“系统架构”更恰当地指的是工程系统上下文。SEBoK试图更明确地说明这一点，但在直接参考其他SE文献时，可能仍会做出此类假设。
一个广泛的术语表确定了术语在SEBoK中的使用方式，并显示了它们在不同语境中的含义可能会有怎样的变化。根据需要，术语表包括指向提供更多详细信息的文章的指针。
有关系统定义的更多信息，请参阅“什么是系统？”？第二部分。SEBoK第3部分：系统工程与管理和第4部分：系统工程应用的主要重点是如何创建或更改工程系统，以在这些更广泛的系统环境中实现利益相关者的目标。第5部分：系统工程管理和第6部分：系统工程和其他领域中的知识检查了SE本身在其执行的人类活动系统中被集成和支持的需求，以及SE和其他工程和管理领域之间的关系。
工程系统领域内的系统工程范围
SE的范围不包括工程系统的工程和管理所涉及的一切。活动可以是SE环境的一部分，但除了SE功能的具体管理之外，不被视为SE的一部分。例如系统建设、制造、资金和综合管理。这反映在国际系统工程理事会（INCOSE）对系统工程的顶级定义中，即“利用系统原理和概念以及领域、技术和管理方法，成功实现、使用和废弃工程系统的跨领域综合方法”（Fellows 2019）。虽然SE可以实现成功的系统，但如果SE范围之外的活动（如制造）管理和执行不善，SE无法确保成功实现。
在工程和管理中定义SE范围的一种便捷方法是绘制维恩图。图3显示了SE、系统实施和项目/系统管理之间的关系。分析生产、测试和操作的替代方法等活动是SE规划和分析功能的一部分。生产线设备订购和安装及其在制造中的使用等活动，虽然仍然是重要的SE环境考虑因素，但不属于SE边界。注意，如图3所示，系统实现工程还包括系统实现的软件生产方面。因此，软件工程不被视为SE的子集。
SE 的传统定义强调 SE 活动的顺序执行，例如，“记录需求，然后进行设计综合……”（INCOSE 2012）。最初，SEBoK 作者和编辑脱离传统，强调系统需求定义和系统设计中 SE 的以下修订定义：
系统工程（SE）是一种跨领域的方法和手段，可以实现成功的系统。 它侧重于整体和同时理解利益相关者的需求； 探索机会； 记录要求； 从系统概念探索到系统处置，在考虑完整问题的同时综合、验证、验证和演化解决方案。 （INCOSE 2012，已修改。）
最近，INCOSE Fellows 提供了 SE 的更新定义，该定义已被采纳为官方 INCOSE 定义：
使用系统原理和概念以及科学、技术和管理方法，使工程系统能够成功实现、使用和跨领域的综合方法。
第 3 部分：系统工程和管理 详细阐述了上述定义，以更全面地充实 SE 的范围。
系统工程和工程系统项目生命周期 SE 作为生命周期方法的一部分执行。 图 2 总结了 SE生命周期 中涉及的主要代理、活动和工件 ，在创建和发展工程系统的项目环境中。
对于每个主要项目生命周期阶段，我们看到主要代理正在执行的活动，改变了 ES 的状态。
- 主要项目生命周期阶段显示在最左侧的列中。 它们是系统定义、系统初始操作能力 (IOC) 开发以及系统演进和退役。
- 主要代理出现在顶行的三个内部列中。 他们是构成项目环境的系统工程师、系统开发人员和主要的项目外部主体（用户、所有者、外部系统）。
- 出现在最右边栏中的 ES 可以是产品、服务和/或企业。
在每一行中：
- 每个内部列中的框显示该列最上面一行列出的代理正在执行的活动
- 生成的工件出现在最右边的框中。
箭头表示依赖关系：从框 A 到框 B 的箭头表示框 B 的成功结果取决于框 A 的成功结果。双头箭头表示双向依赖：从框 A 指向框 B 的箭头而从盒子B到盒子A意味着每个盒子的成功结果取决于另一个盒子的成功结果。
例如，考虑如何处理系统开发和演进过程中出现的不可避免的变化：
- 一个框显示系统的用户和所有者可能会提出更改。
- 更改必须与系统开发人员协商，系统开发人员显示在第二个框中。
- 谈判由系统工程师调解，他们显示在前两者之间的第三个框中。
- 由于提议的更改从左到右，反建议从右到左，所有三个框都由两个箭头连接。 这反映了协商的双向依赖。
图 1 所示的代理-活动-工件图可用于捕获复杂的交互。 对本示例进行更详细的查看表明：
- 系统的用户和所有者（利益相关者）提出更改以应对竞争威胁或机会，或适应独立发展的外部系统（例如商用现货 (COTS) 产品、云服务或供应链）所带来的变化推动者。
- 这些利益相关者和系统开发人员之间的谈判随后由 SE 调解。
- SE 的作用是分析替代变更提议的相对成本和收益，并综合双方满意的解决方案。
|
