系统工程系(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 的作用是分析替代变更提议的相对成本和收益,并综合双方满意的解决方案。
|