系统工程导论-Lib教程

在广泛的社区中，“系统”一词可能意味着技术、自然或社会因素的集合，或三者的组合。这有时可能会产生歧义：例如，“管理”是指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 的作用是分析替代变更提议的相对成本和收益，并综合双方满意的解决方案。

系统工程原理

每一门领域都有一套基本原则，这些原则是它的基本特征。领域知识和实践来源于其原则。例如，物理学的一个原理是光速是恒定的。这个具体的原理已经在实践中被验证了无数次，并被广泛接受为宇宙是如何运作的。一个共同的经济原则是“每一个选择都有机会成本”。另一个是供给原则，它指出“供给的商品的数量随着市场价格的上涨而上升，随着价格的下跌而下降”(Ehrbar 2007)。一般来说，领域没有一套权威性的完整的原则。不同的作者在他们确定和解释的原则中强调一个领域的不同方面。随着领域的成熟，新的原则会出现，旧的原则可能会改变。例如，爱因斯坦的相对论揭示了牛顿物理学的基本原理并非绝对正确。然而，大多数时候，它们仍然是非常宝贵的。

介绍

系统工程的存在是为了开发满足需求的解决方案。这是系统工程师完成工作的动力。但是系统工程师如何完成这个巨大的挑战呢?为了解决这个问题，存在一组系统工程过程，并且最近出现了一组系统工程原则来阐明指导系统工程过程的基本概念。INCOSE系统工程原则行动小组(SEPAT)回顾了文献中确定的系统原则和系统工程原则的各种来源。这篇文章调查了这项工作，并在此基础上确定了一组系统工程原则。

系统原理和系统工程原理在重要方面有所不同(Watson 2018a)。系统原则处理所有类型系统的行为和属性，着眼于系统的科学基础，并通过一般系统原则集的专门实例在系统上下文中描述这个基础。SE原则是针对系统实现、使用和退役方法的系统原则的特殊化和上下文化的实例化。SE原则建立在对所有类型的系统(Rousseau, 2018a)和所有类型的人类活动系统(Senge 1990, Calvo-Amodio & Rousseau 2019)普遍适用的系统原则之上。因此，系统原则指导SE过程的定义和应用——一个强大的系统工程师必须同时掌握系统原则和SE原则。

SE是一个新兴的领域，但是很多人已经提出了它的基本原则，部分是通过构建系统原则提出的。也许因为它的新兴，在社区中对于哪些SE原则是最核心的，甚至哪些原则是有效的，还没有达成共识。然而，研究一些提出的SE原则是有价值的，因为它们提供了对该领域中一些最优秀的人才认为是该领域的基础的见解。在审查各种已发表的原则时，出现了一套适用于有效原则的标准。一个原则:

超越特定的生命周期模型或阶段
超越系统类型
超越系统语境
传达关于 SE 的世界观
不是“如何”声明
得到文献支持或被社会广泛接受； ie 已在多个组织和多种系统类型的实践中证明是成功的
重点突出，简洁，措辞清晰

因此，系统类型、系统开发和运行的环境或生命周期阶段并不能狭义地定义系统工程原则。系统工程原理超越了这些系统特征，形成了该领域的世界观。原则不是体现在过程中的“如何做”陈述，而是为应用系统工程过程的决策提供指导。原则应该有文献支持的强有力的参考基础，或在实践中被广泛接受（记住，这种成功必须超越上述系统特征），或两者兼而有之。在结构良好的原则陈述中，原则重点突出、简洁明了。

文献目前包含几篇关于系统原理的好文章。这些原则为系统的运作提供了基础，并试图将科学公理、定律和原则组合成一组系统原则。系统原理文献中的主要主题包括系统治理、系统理论公理和系统病理学，重点是复杂系统和系统系统。复杂系统治理提供了一组九个元系统功能“提供复杂系统的控制、通信、协调和集成”。这些功能为理解复杂系统的功能以及如何管理其获取（即治理）提供了基础（Keating 等人，2017a）。这些元系统功能也扩展到系统工程系统（Keating et al. 2017b）。

系统论的进步产生了一组统一的命题，这些命题被表述为七个公理，“系统论中的所有其他命题都可以从这些公理中导出”。这七个公理映射到 30 条科学定律和原则（Adams 等人，2014 年）。这些公理侧重于系统的科学基础。对这些公理的进一步研究提供了一个整合结构，以及与基本科学定律和原理的略微不同的映射（Whitney et al. 2015）。这项工作提供了系统理论的强大整合和进步，重点关注系统科学基础背后的原理。

系统科学方法还包含系统理论，导致系统理论和系统思维的 10 个概念（Sillitto 2014）。这 10 个概念侧重于提供系统特征定义的系统原理。系统科学的进一步发展产生了 12 条系统科学原则的清单，这些原则也关注系统的特征（Mobus & Kalton 2015）。卢梭正式推导出系统的三个原则的陈述和推导（Rousseau 2018a）。此外，系统学和系统原理类型学的架构提供了从系统哲学到系统实践的科学原理的良好分类（Rousseau 2018b）。这项工作导致了一个理解系统科学原理的框架（Rousseau 2018c）。

其他早期工作包括系统展示的一组七项系统科学原理（Hitchins 1992）。组织原则也被定义为处理如何在组织内成功工作的 11 条原则（Senge 1990）。系统思维原理描述了一组 20 条系统思维原理，这些原理是从各种来源捕获和整合的。

系统病理学是另一种有趣的方法来理解“限制系统性能或降低系统可行性（持续存在）的情况，因此它们降低了系统满足性能预期的可能性”。这些病理学定义了用于理解系统的诊断，这些系统源自一组 45 条系统定律和原则（Katina 等人，2016 年）。

INCOSE 编制了一份早期的原则清单。这些原则由 8 条原则和 61 条子原则组成（Defoe 1993）。这些原则在实践中是系统开发成功的重要考虑因素，并最终成为 SE 过程的基础。这些原则反映了 SE 的总体运作方式。在这项工作之后，编译了几个早期版本的 SE 原则，从而形成了第一批记录的 SE 过程集之一。 Project Performance International (Halligan, 2019) 有一套 SE 原则，遵循 Defoe 设定的模型，提供 SE 实践中的考虑因素，重点关注生命周期阶段的特定方面。

韩国系统工程委员会提供了一篇关于 SE 原则的 8 篇著作的调查文章，涵盖从笛福的原则到 2004 年（Han 2004）的时间，包括 PPI 原则的早期版本。这 8 部作品展示了系统工程原理从以实践为中心到更以超越为中心的原理的演变。 1997 年，INCOSE 系统工程原理工作组（不再活跃）在笛福几年的讨论过程中产生了一套 8 条原理。这些原则是过程基础、建模指南和 SE 关注的早期世界观的混合体。电气工程师学会 (IEE 2000)，现在是工程技术学会 (IET) 的一部分，产生了一套 12 条原则，这些原则也为不再存在的系统工程过程提供了一些基础。劳伦斯伯克利国家实验室 (LNBL 2001) 提出了一套系统工程原理，这些原理体现了 INCOSE SE 过程所捕捉到的概念。在英格兰，国防工程集团 (DEG 2002) 制作了一份 SE 手册，其中包含一套简短的原则，指导他们的流程并捕获系统原则的某些方面。据报道，爱荷华州立大学制作了一本 SE 学生手册，其中包含作为原则的 SE 启发式短语的简短列表。 KCOSE 论文还引用了南加州大学 (USC) 的一门课程中关于 SE 原理的讲座（Jackson，2003 年）。

一些早期形式的 SE 原则也包含在复杂系统开发的教科书中（Adamsen II 2000）。这组原则假设了一个分层系统表示（复杂系统已被证明是比层次结构更多的网络）并包括关于 SE 过程的陈述。最后，系统架构书籍还包括一些早期的 SE 启发式方法（Maier 和 Rechtin 2002）。这些启发式解读为关于系统工程实践某些方面的说法。

KCOSE 技术委员会审查了这 8 个来源，并投票将这些来源中的 8 条原则作为一套 SE 原则，从而形成了符合上述标准的早期形式的超越原则。这些资源都显示了 SE 原则的早期演变阶段，因为人们查看了正式和非正式（即课程笔记和学生手册）资源以试图理解 SE 原则。在 INCOSE 系统工程手册等著作中对 SE 过程的定义实现了这些早期关于 SE 原则的著作的一些目标，并巩固了该领域的大量工作。最近，人们认识到需要更多超越 SE 原则，作为应用流程的指南，这是 SEPAT 当前工作的重点。

在过去的几年里，SEPAT 对一系列 SE 原则有了全新的认识（Watson et al. 2019）。它的工作基于 NASA 系统工程研究联盟的 SE 假设、原则和假设。该联盟遵循路德维希·玻尔兹曼的方法来定义他关于气体分配定律的假设。玻尔兹曼的工作是如何描述复杂系统相互作用的早期例子。假设是在没有证据的情况下被假定为真实、真实或必要的东西（Webster 1988）。这导致了一系列基于 SE 的假设和假设的阐述，这些假设和假设被扩展为一组提议的 SE 原则。基本的 SE 假设和假设在 4 年内成熟（Watson et al. 2014; Watson et al. 2015; Watson & Farrington 2016）。随着假设的成熟，SE 原则也随之成熟，为 SE 的应用提供了更多细节，并证明了假设成为原则（Watson et al. 2018; Watson 2018b）。 SEPAT 制定了 15 条原则，其中一些通过子原则进行了扩展，如 (Watson et al. 2019) 中所述。这些原则是：

应用中的 SE 特定于利益相关者的需求、解决方案空间、生成的系统解决方案和整个系统生命周期的语境。
SE 有一个整体的系统视图，包括系统元素和它们之间的交互、支持系统和系统环境。
SE 影响并受内部和外部资源以及政治、经济、社会、技术、环境和法律因素的影响。
必须正确理解政策和法律，以免过度约束或约束系统实施。
真实的物理系统是系统的完美模型。
SE 的重点是对系统的交互、敏感性和行为、利益相关者的需求及其运营环境的逐步深入理解。
利益相关者的需求可能会发生变化，并且必须在系统生命周期中加以考虑。
SE 解决利益相关者的需求，同时考虑预算、进度和技术需求，以及其他期望和限制。
SE 决策是在考虑风险的不确定性下做出的。
决策质量取决于决策过程中存在的系统、使能系统和互操作系统的知识。
SE 跨越整个系统生命周期。
复杂的系统是由复杂的组织设计的。
SE 以有效的方式整合工程领域。
SE 负责管理组织内的领域交互。
SE 基于一套中等范围的理论。

SEAT 最近对 SE 原则的阐述详细阐述了笛福早先提出的观点，并强调了当前 SE 实践的其他方面，但两组之间并没有不一致的地方。诸如 Defoe 和 SEBAT 提出的 SE 原则是领域独立的；即，它们的应用与正在构建的系统类型无关，无论是用于运输、医疗保健、通信、金融还是任何其他业务或技术领域。当它们被应用时，这些原则可以采取更专业的形式，和/或可以由其他特定于语境的原则来补充。事实上，诸如此类的一般 SE 原则已成功应用于几乎所有领域。

系统工程的探索

探索式方法式方法为一个成熟的职业提供了一种传递其积累智慧的方式。这使得从业者和其他对如何做事情感兴趣的人能够从过去发现的行之有效的方法中获得见解，并应用所学到的经验教训。启发法通常采用自然语言中的简短表达形式。这些可以是令人难忘的短语，概括了经验法则、捷径或“智者之言”，给出了职业行为的一般指导原则或规则、建议，或在特定情况下如何行动的指导原则。普通的启发法并不能总结所有需要了解的知识，但它们可以作为学习更多知识的有用切入点。本文概述了一般的启发式方法，以及一些专门支持系统工程实践的方法。

概览

探索式方法在工程学的历史上一直扮演着重要的角色，并影响着它的发展，尤其是在科学发展到可以帮助工程师之前。系统工程仍然处于一个阶段，许多正在构建的系统都没有足够可靠的科学基础，这引发了人们对探索式方法的重新兴趣，以填补这一空白。当系统工程的实践被扩展到为固有的复杂、无界、非结构化或“邪恶的”问题提供解决方案时，这一点尤其正确(Churchman 1967)。

使用探索式方法并不能保证在所有情况下都能成功，但如果明确了探索式方法的已知适用性，它的效用就能最大化。在最好的情况下，探索式方法可以作为决策制定、价值判断和评估的辅助手段。

探索式方法在以下几个方面都很有用:

减少做出正确决定或选择所需的思考（或计算）量
帮助找到问题的可接受解决方案
确定解决复杂问题时要关注的最重要因素
通过借鉴最佳实践来提高决策质量
避免重复可避免的错误
作为一个切入点，更广泛地了解已发现有效的方法

历史背景

工程学最初是在改造古代世界的过程中获得的一系列技能，主要是通过建筑、城市、基础设施和战争机器。从那时起，人类就试图将“如何做”的知识编入法典。这样做可以让每一代都从前辈那里学习，使更复杂的结构能够以更大的信心构建，同时避免重复的现实世界的失败。公元前1世纪，维特鲁威提出了工程学的目标，并提出了一套经久不衰的原则:力量、效用和美丽。他提供了许多他们在当时工程领域应用的例子。

维特鲁威的著作在中世纪被重新发现，形成了建筑和工程这两个孪生职业的基础。早期的教堂建造者将他们的知识概括为少量的经验法则，例如:“保持低重心”，“把80%的质量放在柱子上”，以及“观察交叉构件的横截面和跨度之间的经验比例”。设计是保守的，有很大的边界，边界的边界在很大程度上是未知的。由此产生了许多优秀的结构，其中许多一直延续到今天。当设计边际被超出时，例如为了建造更高更令人印象深刻的建筑，就会付出高昂的代价，屋顶、塔甚至整栋建筑都会倒塌。从这些失败中，新的经验法则出现了。这些都发生在材料强度或建筑牢固地基背后的科学被理解之前。直到最近，计算机模拟才揭示了动力效应对某些失效的影响，例如风切变对高层结构的影响。

从那时起，工程科学和应用科学共同发展:科学提供了预测和解释工程构件性能的能力，以更大的保证，而工程开发新的和更复杂的系统，需要新的科学解释和驱动研究议程。在现代，复杂的适应性系统正在被建立，这挑战了传统的工程科学，建设者转向社会和行为科学，管理科学，越来越多的系统科学，以处理一些新的形式的复杂性所涉及的，并相应地指导专业。

现代化的利益关系

探索式方法法应用于系统工程领域的新兴趣源于Rechtin和Maier(2009)的开创性工作。他们的书仍然是这类知识最好的单一宝库。他们的动机是为系统架构师这一新兴角色提供指导，系统架构师是负责协调工程工作，为复杂问题设计解决方案并监督其实现的人员或团队。Rechtin和Maier观察到，在许多情况下，应用“经验法则”比尝试进行详细分析更好，特别是当涉及的变量数量、利益相关者之间的互动的复杂性、系统解决方案的内部动力以及负责实现它们的组织。

在2008年全球金融危机期间担任英格兰银行行长的默文·金(Mervyn King, 2016)也提出了一个支持更广泛使用探索式方法的论点。回顾过去，他说“大致正确总比完全错误要好”:那些遵守旧银行家的规则，保持资本资产相当于贷款账面70%的银行存活了下来，而那些依赖复杂(且有缺陷的)衍生品数学模型的银行则失败了。

Simon (1957) 进一步支持探索式方法方法的当代使用，他创造了“满足”一词，表示人们寻求解决方案，或接受选择或判断，对于他们的目的来说“足够好”，无论是否它们可以通过精确分析进一步优化。他指出，一些探索式方法方法是科学地从实验或对现实世界数据的系统收集和分析中得出的，而另一些则是基于现实世界观察或经验的经验法则。

多年来，Gigerenzer 和他的同事（例如，Gigerenzer 和 Selten (2001)）进一步发展了这一想法，他们对探索式方法方法进行了研究，这些探索式方法方法有助于在可预测性有限的领域做出快速决策，当概率论不再有帮助。他们开发了一系列他们称之为“快速和节俭”的普遍适用规则，这些规则在医学诊断和性能科学等领域优于更传统的分析（Raab 和 Gigerenzer 2015）。迄今为止，很少有人探索式方法到系统工程的应用。

实际应用

使用探索式方法的经验表明它们应该是令人难忘的，并且在非正式的措辞时可能是最有效的。最好的例子不仅仅是文字表达；它们应该引起读者的共鸣并提出额外的含义，鼓励他们更多地了解为什么以及何时使用它们。

这里有一个潜在的问题：如果你没有经历过探索式方法适用的情况，它对你来说可能意义不大，内在价值很可能会丢失；但如果您已经有相关经验，您可能会发现这一点很明显。因此，探索式方法方法的使用与我们的学习方式有关。在一个经验至关重要的世界里，但在工作中学习的机会数量受到系统工程师一生从事的大型项目数量的限制，因此必须加快学习过程。作为终身学习的一部分，如果与其他知识来源相关联并且在职业生涯的正确时间点可以访问，那么探索式方法可以在这里提供帮助。

探索式方法存储库本身也可以作为知识库，特别是如果添加了其他媒体（例如视频剪辑或培训材料，甚至是交互式媒体）来鼓励讨论和反馈。这样的存储库还可能链接到其他已建立的知识源或公司网站。它可以被组织起来以反映公认的实践领域或在带有元数据标记的数据库中以允许灵活检索。 Maier 和 Rechtin (2009) 建议存储库也可以充当“阅览室”，允许用户在相关主题之间自由移动，就好像他们在图书馆或书店中追随他们的好奇心一样。这样的存储库还可以允许用户组装一组对他们最有意义的探索式方法方法，这些探索式方法方法与他们的个人兴趣或专业活动领域相关。

Beasley 等人 (2014) 证明了探索式方法算法的进一步可能用途，他们在一项调查中使用了一个选择来揭示系统工程的关键方面是如何在他们的组织内得到解决的。他们要求员工根据探索式方法方法对业务的重要性以及在实践中是否得到遵守来标记探索式方法方法。对答案的分析使人们能够关注需要改进的领域。

从广义上讲，现在对探索式方法方法的兴趣主要集中在它们在两个主要方面的使用：首先，以一种可访问的形式封装工程知识，这种形式的实践被广泛接受并且基础科学被理解；其次，克服更多分析方法的局限性，在这些方法中，科学的用途仍然有限。在任何一种情况下，一套好的探索式方法方法都需要积极维护，以反映实践的演变以及我们对什么是最有效的不断发展的理解。精心策划的探索式方法集合使从业者能够保留和代表系统工程专业社区积累的实践智慧。

本文以一些适用于早期阶段的简单示例结束，并附有一些评论，以暗示它们的隐藏含义以及它们可能导致的方向。

不要假设问题的原始陈述一定是最好的，甚至是正确的。 许多探索式方法都重复了同一点，例如：“隐藏的假设可能是最具破坏性的”，以及“客户可能知道他想要什么，但不知道他需要什么。” 所有这一切都必须以机智和尊重用户的方式处理，但经验表明，未能及早达成相互理解是失败的根本原因，在做这些工作的过程中建立的牢固关系可以在解决更困难的问题时得到回报以后可能出现的问题。
在项目的早期阶段，未知问题比已知问题更大。 有时所要求的内容是模糊的，系统工程的整个背景很难知道，尤其是在高度不确定的领域。开始的问题可能不是“这有什么要求？”而更多的是“这里发生了什么？”。（Kay and King 2020）揭开第二个问题背后的含义可能需要从系统思维中汲取的方法——寻找例如，根本原因——并且可以将项目带入意想不到的领域。同样，同理心和直觉等软技能可能比传统工程更重要。
尽可能在构建之前建模。 这种探索式方法方法将人们引向模型的一般使用和限制的更深层次问题，作为系统工程在承诺构建它之前尝试预测理想和不理想的紧急系统属性的一种方式。一个相关的探索式方法声明“当你在现实世界中测试一个系统模型时，你验证的是模型而不是系统”，系统科学的一个定理指出“系统的唯一完整模型是系统本身。” 一种探索式方法方法导致另一种探索式方法方法，导致对系统如何在高度不确定的超连接 IT 系统世界中构建的思考，人们可能会假设“系统在其环境中的唯一完整模型是其环境中的系统”，这导致使用进化生命周期、原型的快速部署、敏捷生命周期等。
大多数严重的错误都是在早期犯下的。 这种探索式方法总结了刚才所说的大部分内容。只是为了表明现在人们相信的东西可能已经有一段时间了，这里引用柏拉图的一句话：“开始是工作中最重要的部分。” （柏拉图公元前 375 年）。

最后，一个关于探索式方法——它们来自哪里以及它们的用途——取自幸运饼干并提供了一个总结：“这项工作会告诉你如何去做。” （Wilczek 2015）这里提出的严肃观点——除了表明民间智慧可以发挥作用之外——是关于如何进行系统工程的最重要的教训最终来自于系统工程师社区的集体经验，因为他们从事他们的职业。甚至用于支持探索式方法的科学也必须在实际情况中证明自己。

系统工程的经济价值

系统工程的增值

对于传统的项目，如铁路、水库和冰箱，系统工程师面对的是一个自给自足的系统，该系统通常具有相对稳定的需求、健全的科学基础和无数的先例。随着大多数现代系统成为一个或多个不断演化的系统(SoS)的组成部分，随着系统的规模迅速扩大、动态性、相互依赖性、人类密集性、脆弱性来源数量和新颖性，有效SE的性能现在具有越来越高的经济价值。

第7部分中的实现示例证实了这一点。SE的不足会导致取消已经很昂贵的系统，或者就总拥有成本或人类生命损失而言，甚至更昂贵的系统。第七部分介绍了美国联邦航空管理局(FAA)高级自动化系统(AAS)、美国联邦调查局(FBI)虚拟案件档案系统、哈勃太空望远镜案例研究和Therac-25医疗直线加速器存在的问题。

另一方面，全球定位系统(GPS)、微型导引头技术集成项目(MSTI)和下一代医疗输液泵项目都表明，对彻底的SE的投资可以产生高成本效益的系统。图1总结了Werner Gruhl的分析数据，它将SE的投资水平与美国国家航空航天局(NASA)项目的成本超支联系起来(Stutzke 2005)。结果表明，在项目内部的SE投资金额和成本超支之间存在普遍的相关性，表明了正确分配SE资源的关键作用。

系统工程价值的进一步量化证据

对 161 个项目的建设性成本模型 II (COCOMO™ II) 数据库中软件密集型系统的系统架构和风险解决缺陷（SE 不足的结果）的影响分析表明，返工成本作为函数在统计上显着增加以源代码行 (SLOC) 衡量的项目规模：一万个 SLOC 项目的平均返工率为 18%，而一千万个 SLOC 项目的平均返工率为 91%。该数据影响了许多重大系统项目，以重新考虑对 SE 的初始投资不足（例如，Boehm 等，2004），并通过平衡对 SE 投资不足的风险与过度投资的风险来解决“多少 SE 才足够”的问题。 -投资（通常称为“分析瘫痪”），如图 2 所示（Boehm、Valerdi 和 Honor 2008）。

通常，小型项目可以快速弥补被忽视的 SE 接口定义和风险解决；然而，随着项目变得越来越大并且拥有更多独立开发的组件，后期返工的成本抵消了减少 SE 工作所带来的任何节省。此外，中型项目的运营区域相对平坦，而大型项目则因忽视彻底的 SE 而付出极大的代价。广泛的调查和案例研究分析证实了这些结果。

My Life Is Failure: 100 件事你应该知道成为一个更好的项目领导者 软件成本和进度超支的调查数据 (Johnson 2006) 指出，大约 50% 的严重“软件超限”商业项目的主要来源是 SE 不足（缺乏用户输入、不完整的需求、不切实际的期望、不明确的目标和不切实际的时间表）。软件工程研究所 (SEI)/国防工业协会 (NDIA) 对 46 个政府承包的行业项目进行的广泛调查表明，较高的项目 SE 能力与较高的项目绩效之间存在很强的相关性（Elm 等人，2007 年）。

构建系统工程成本模型(COSYSMO)是一种用于确定“多少SE是足够的”的校准模型，已被开发并在(Valerdi 2008)中进行了讨论。它估计了作为系统大小的函数(即，需求，接口，算法，和操作场景)，由14个因素(即，需求理解，技术风险，人员经验，等等)修改的项目对SE的需求的人月数，这决定了所需的SE工作量。SE的其他经济因素包括成本和收益的重用(王,Valerdi,财富2010强),SE的管理资产跨产品线(2013年财富和Valerdi), SE在项目风险的影响(Madachy和Valerdi 2010),以及需求波动的作用在SE(佩纳和Valerdi 2010)。

系统工程：历史和未来的挑战

人类面临着越来越复杂的挑战，必须对系统进行全面的思考，才能成功应对这些挑战。

历史的角度

一些最早的相关挑战是在组织新兴城市方面。新兴城市依靠储存粮食和应急物资、保卫商店和城市、支持交通和贸易、提供供水以及容纳宫殿、城堡、来世准备和寺庙等功能。实现这些功能所需的大量整体规划和组织技能是在中东、埃及、亚洲和拉丁美洲独立开发的，如 Lewis Mumford 的 《历史上的城市》 （Mumford 1961）中所述。

接下来出现了特大城市和用于军事行动的移动城市，例如罗马帝国的那些城市，带来了另一波挑战和回应。这些也催生了通才和他们的意识形态著作，例如维特鲁威和他的 十本建筑书籍 （维特鲁威：摩根翻译，1960 年）。罗马的“建筑”不仅指建筑，还包括渡槽、集中供暖、测量、景观美化和城市总体规划。

工业革命带来了另一波挑战和回应。在 19 世纪，新的整体思维和规划进入了创建和维持交通系统，包括运河、铁路和大都市交通系统。这一时期出现了一般论文，例如 《铁路选址的经济理论》（惠灵顿，1887 年）。 二十世纪初，出现了大型工业企业工程，例如福特汽车装配厂，以及 科学管理原理 （Taylor 1911）等论文。

第二次世界大战对超大型多国陆、海、空军及其相关后勤和情报功能的实时指挥和控制的复杂性提出了挑战。战后时期带来了冷战和俄罗斯的太空成就。美国及其盟国通过大力投资研究和开发军事防御系统的原理、方法、流程和工具来应对这些挑战，并辅之以解决工业和其他政府系统的举措。具有里程碑意义的结果包括运筹学和 SE 在 运筹学导论 (Churchman et. al 1957)、Warfield (1956) 和 Goode-Machol (1957) 以及 Rand Corporation 方法中的编纂，如 通过系统分析提高政府效率 （McKean 1958）。在系统行为和 SE 理论中，我们看到了控制论 (Weiner 1948)、系统动力学 (Forrester 1961)、一般系统理论 (Bertalanffy 1968) 和数学系统工程理论 (Wymore 1977)。

2 个进一步的挑战来源在 1960 年代开始出现，并在 1970 年代到 1990 年代加速出现：对人为因素重要性的认识，以及工程系统中软件功能的增长。

关于对人的因素的认识，反应是从传统的 SE 转向“软” SE 方法。传统的面向硬件的 SE 具有顺序流程、预先指定的需求、功能层次结构、基于数学的解决方案和单步系统开发。 SE 的软系统方法的特点是紧急需求、需求和解决方案的并发定义、分层的面向服务和功能层次结构的组合、基于启发式的解决方案和进化系统开发。很好的例子是社会系统（Warfield 1976）、软系统方法论（Checkland 1981）和系统架构（Rechtin 1991 和 Rechtin-Maier 1997）。和维特鲁威一样，“建筑师”

软件作为系统关键元素的兴起导致将软件工程定义为与 SE 密切相关的学科。第 6 部分中的系统工程和软件工程知识领域：相关学科描述了软件工程如何将 SE 原理应用于计算系统（其中任何硬件元素构成软件功能平台）和其中的嵌入式软件元素的生命周期物理系统。

系统工程挑战的演化

自 1990 年以来，正在设计的系统中迅速增加的规模、活力和脆弱性带来了越来越大的挑战。通信、计算机处理、人机界面、移动电源存储和其他技术的快速发展提供了以网络为中心的产品和服务的高效互操作性，但作为新的解决方案（云、社交网络、搜索引擎、地理位置服务、推荐服务以及电网和工业控制系统）激增并相互竞争。

同样，评估和整合变化速度越来越快的新技术提出了进一步的 SE 挑战。这发生在生物技术、纳米技术以及物理和生物实体的组合、移动网络、社交网络技术、协作自主代理技术、大规模并行数据处理、云计算和数据挖掘技术等领域。创建智能服务、智能医院、能源网和城市的雄心勃勃的项目正在进行中。这些承诺会提高系统功能和生活质量，但存在依赖不成熟技术或具有不兼容目标或假设的技术组合的风险。在寻求使未来系统可扩展、稳定、适应性强和人性化的过程中，越来越需要 SE，但也面临越来越大的挑战。

人们普遍认为，没有一种万能的生命周期模型最适合这些复杂的系统挑战。为了应对这一挑战，许多系统工程实践已经发展，利用精益、敏捷、迭代和进化的方法来提供同时实现高效率、高保证、弹性、适应性和生命周期负担得起的系统的方法；还引入了系统系统 (SoS)方法的出现，其中将在其自身生命周期内开发和部署的独立系统元素组合在一起，以满足任务和企业需求。

创建灵活和量身定制的生命周期并使用工程系统组合开发解决方案，每个系统都有其自己的生命周期重点，这对生命周期管理和控制提出了自己的挑战。作为对此的回应，企业系统工程 (ESE)方法已被开发出来，该方法将企业本身视为要进行工程设计的系统。因此，上面讨论的许多雄心勃勃的智能系统项目正在作为一个项目交付管理的生命周期与自上而下的企业需求理解同步。重要的是，在这些方法中，我们创造了灵活性，以允许通过结合开放的、可互操作的系统元素来开发自下而上的解决方案，并将其集成到不断发展的解决方案中。

最近，人工智能、机器学习、深度学习、机电一体化、网络物理系统、网络安全、物联网 (IoT)、增材制造、数字线程、工厂 4.0 等新兴技术对 SE 具有挑战性。

上述许多挑战以及 SE 对这些挑战的反应增加了所考虑系统信息的广度和复杂性。这增加了对最新、权威和共享模型的需求，以支持生命周期决策。这导致了基于模型的系统工程 (MBSE)方法的发展和持续发展。

未来的挑战

INCOSE 系统工程愿景 2025 (INCOSE 2014) 考虑了上述问题，并由此概述了未来系统的可能性质。这形成了 SE 将被实践的背景，并为考虑 SE 需要如何发展提供了一个起点：

未来的系统将需要响应不断增长和多样化的社会需求，以创造价值。单个工程系统生命周期可能仍需要响应已识别的利益相关者需求以及客户时间和成本限制。然而，它们也将构成对战略企业目标和/或社会挑战的更大同步响应的一部分。系统生命周期需要与工业、经济和社会的全球趋势保持一致，这反过来又会影响系统的需求和期望。

未来的系统将需要利用不断增长的技术创新，同时防止意外后果。工程系统产品和服务需要变得更智能、自组织、可持续、资源高效、稳健和安全，以满足利益相关者的需求。

这些未来的系统将需要由不断发展的、多样化的员工队伍来设计，他们拥有越来越强大的工具，可以创新并应对竞争压力。

这些未来的挑战改变了软件和人在工程系统中的作用。系统工程和软件工程知识领域考虑了软件在工程系统中日益重要的作用及其对 SE 的影响。特别是，它考虑了网络物理系统日益重要的重要性，其中技术、软件和人员在工程系统解决方案中发挥着同样重要的作用。这需要一种能够理解不同类型技术的影响的 SE 方法，尤其是软件和人为因素的约束和机会，在工程系统生命周期的各个方面。

所有这些挑战，以及 SE 对这些挑战的回应，使得 SE 继续向基于模型的学科过渡变得更加重要。

应对这些挑战所需的改变将影响第 3 部分：系统工程和管理中描述的生命周期过程，以及系统工程师的知识、技能和态度，以及他们与第 5 部分中讨论的其他学科合作的组织方式：启用系统工程和第 6 部分：相关学科。如第 4 部分：SE 的应用中所述，将 SE 应用于不同类型的系统上下文的不同方式将成为进一步发展以应对这些挑战的特别关注点。 SEBoK第1 部分中的 SE 转型知识领域介绍介绍了 SE 如何开始改变以应对这些挑战。

系统工程及其他领域

正如SEBoK 文章的范围中所讨论的，系统工程(SE) 与其他领域之间存在许多重合。系统工程师应该对这些其他领域的性质有基本的了解，并且经常需要详细了解其他领域的各个方面。本文描述了与 SE 交织在一起的领域格局。如需更详细地了解各个领域，请参阅第 6 部分。

系统工程以外的工程领域

工程领域的知识内容大多是面向组件和价值中立的（Boehm 和 Jain 2006）。它们的基本定律和方程，例如欧姆定律、胡克定律、牛顿定律、麦克斯韦方程、纳维-斯托克斯方程、克努特的排序和搜索算法纲要，以及菲茨人体运动定律，都与系统中的性能有关—— 兴趣。他们没有说明这种绩效如何有助于利益相关者的价值主张。

相比之下，SE 在知识内容上比面向组件更全面，更面向利益相关者价值而不是价值中立、绩效导向。实现成功的系统需要与利益相关者就替代实现的相对价值以及将组件和人员组织成一个满足利益相关者经常冲突的价值主张的系统进行推理。对系统成功至关重要的利益相关者包括资助者、所有者、用户、运营商、维护者、制造商以及安全和污染监管机构。

在某些领域中，工程师评估设计元素并将其集成到满足价值代理的系统中。 SoI 的范围越广，工程师需要的 SE 技能就越广泛。

例如，航空工程师可能会将机械、电气、流体、燃烧化学、软件和驾驶舱设计元素集成到一个满足飞行范围、有效载荷能力、燃料消耗、机动性以及生产和维护成本等价值代理的系统中. 在这样做时，工程师部分地作为系统工程师工作。 SoI 是飞机本身，工程师应用飞机领域的专业知识。

但是，同一位工程师可以参与客运服务、机场配置、行李处理和当地地面交通选项的工程设计。所有这些都有助于成功关键利益相关者的价值主张。 SoI 范围更广，工程师需要更广泛的 SE 知识、技能和能力才能作为系统工程师进行操作。更广泛系统的有效工程仍然需要飞机领域的专业知识。正如 (Guest 1991) 中所讨论的，大多数优秀的系统工程师都是“T 型”人，既具有更广泛的系统考虑的工作知识，又具有相关领域的深厚专业知识，例如航空、制造、软件或人类因素工程。

与 SE 交织在一起的工程领域包括软件工程 (SwE)、人因工程和工业工程。 SwE 和 SE 不仅是相关领域，而且它们密切相关（Boehm 1994）。商业和政府系统的大多数功能现在都在软件中实现，软件在区分市场上的竞争系统方面发挥着突出或主导作用。软件通常在现代系统架构中占有重要地位，并且通常是集成复杂系统组件的“粘合剂”。

SwE 的范围包括软件 SE 和软件构建，但不包括硬件 SE。因此，SwE 和 SE 都不是另一个的子集。参见 SEBoK 范围中的图 1 。有关 SEBoK 与电气和电子工程师协会 (IEEE) 出版的软件工程知识体系指南 (SWEBOK) 之间关系的定义（Bourque 和 Fairley 2014），请参阅系统工程和软件工程.

从微观人体工程学到宏观人体工程学的人因工程与 SE 交织在一起（Booher 2003；Pew 和 Mavor 2007）。请参阅第 6 部分中的人体系统集成。

工业工程在工业领域与 SE 有很大的重叠，但也包括 SE 之外的制造和其他实施活动。请参阅第 6 部分中的系统工程和工业工程。

最后，为了部署一个成功的系统，系统工程师可能需要了解工程中的许多专业领域中的一个或多个，例如安全性、安全性、可靠性、可用性和可维护性工程。其中大多数本身就被认为是专业领域，并且许多都有自己的知识体系。有关这些领域如何与 SE 相关的说明、大多数系统工程师需要了解的有关它们的概述以及他们知识体系中的参考资料，请参阅第 6 部分中的系统工程和专业工程。

非工程领域

SE 与两个非技术领域密切相关：技术管理 (TM) 以及采购和采购（也称为采购和采购）。 TM 通常属于系统工程师的职权范围。许多 SE 教科书、能力模型和大学课程都包含关于 TM 的材料。 TM 是项目管理 (PM) 的专业化。 SE 和 PM 在 TM 中有重要的共同内容，但两者都不是另一个的子集。请参见SEBoK 的范围一文中的图 1 。 有关 SEBoK 与项目管理知识体系指南 (PMBOK) 之间关系的定义，该指南由项目管理协会 (PMI) (PMI 2013) 发布，请参阅第 6 部分中的系统工程和项目管理。

采购和采购从业人员利用 SE 来确定要采购或采购的系统的范围和总体要求。然后，他们准备提案请求和工作说明，确定评估标准，并设计资源选择过程。一旦选择了主要来源，他们就会决定合同选项，包括付款、审查、审计、奖励费用、验收标准、程序和可交付成果的性质。最后，他们监控计划（包括 SE 计划）的进展，并协商和执行变更和纠正措施。其中许多活动相当于采购和采购中的专业领域。请参阅第 6 部分中的相关领域一文。

系统工程核心概念

SECM 方法

一个名为概念图的概念模型是由最初的 SEBoK 团队在 2012 年发布 SEBoK v1.0 之前开发的，用于支持跨 SEBoK 主题领域的初始概念的集成。概念图包括概念模型和概念到术语表和 SEBoK 部分的映射。

SECM 捕获了当今 SEBoK 中包含的系统工程概念及其关系。图 1 中显示的 UML 结构和符号的小子集用于表示 SECM 模型。符号的选择旨在平衡简单性、可理解性和精确性。

下面的图 2 显示了将这些结构和符号应用于汽车的简单示例时的用法。此图显示 Car 是 Vehicle 的一种，Driver 驱动汽车（参考关系），并且有四个轮子是 Car 的一部分。

SECM 以一系列图表的形式呈现，这些图表通常代表 SEBoK 中特定知识领域和主题的概念，还包括对 SEBoK 中词汇表术语的引用。

以下步骤描述了用于从 SEBoK 中捕获 SECM 内容的方法：

选择 SEBoK 知识领域内的主题并评估文本以识别关键系统工程概念。
从包含概念的句子中识别出主语，即概念和谓语，即概念之间的关系。谓词是对主语进行说明的陈述。
在 SEBoK 的其他领域对该概念进行了搜索，并对随附的文本进行了评估，以进一步完善该概念及其与其他概念的关系。
评估 SEBoK 词汇表中的概念定义（如果可用）。
评估了该概念在其他两个行业参考中的使用和定义。
上述评估的概念和派生定义被添加到 SECM 中。
发现的概念之间的关系被添加到模型和相关图表中。这些图表将通常与 SEBoK 知识领域或主题相关联的相关概念分组。
随着对 SEBoK 的新贡献，这种方法可用于识别新概念和关系，并将它们添加到 SECM。

核心概念介绍

SECM 是独立于 BKCASE 项目开发的，以支持 SysML 标准的发展。这些模型可用于识别 SEBoK 中需要额外覆盖以支持未来更新的不一致和/或区域。

图 3 所示的核心概念图提供了 SEBoK 中提出的一些关键概念的高级视图。需要强调的是，该图旨在作为对当前 SEBoK 的代表性解释，没有修改或添加概念，并不声称 SEBoK 概念的完整性。颜色对应于概念的逻辑分组。

下面提供核心概念模型的简要说明。

系统工程师是组织内实践系统工程 (SE) 工程领域的角色，并具有一系列 SE 能力。系统工程集成了其他领域以支持生命周期模型。生命周期模型由生命周期阶段组成，通常包括概念、实现、生产、支持、利用和退役阶段（未显示）。每个生命周期阶段指的是产生各种工作产品的生命周期过程。生命周期过程发展兴趣系统（SoI）。

系统有很多种，包括自然系统、社会系统和技术系统（未显示）。由人们创建并为人们创建的系统称为工程系统。正在考虑其生命周期的工程系统称为感兴趣系统 (SoI)。

System-of-Interest 是更广泛的 System Context 的一部分，其中还包括 Environment 。环境由可以影响 SoI 的其他开放系统（未显示）组成。系统由系统元素组成，具有行为和属性。系统可以表现出涌现性和复杂性。

系统工程使用应用已建立的系统原则的系统方法。系统科学是一个跨领域的科学领域，研究复杂系统并帮助定义和更新系统方法所应用的原则，系统方法被系统工程领域使用。

1169 次浏览	7次

欢迎参加课程:
	数据建模方法与工具
	MBSE（基于模型的系统工程）
	基于 UML 和EA进行分析设计

< 首页

下一页 >