应用于工程系统的系统方法-Lib教程

系统方法这个术语被系统科学的作者用来描述一个系统的“思考”方法，因为它属于直接利益系统边界之外的问题(Churchman 1979)。当简化假设(整个系统具有直接从其组件的属性派生出来的属性的概念)不再适用于利益系统(SoI)，并且当系统上下文的多个层次的出现和复杂性需要整体方法时，这种系统方法是必不可少的。

工程系统的系统方法旨在检查“整个系统、整个生命周期和整个利益相关者群体”，并确保系统(或系统干预)的目的是可持续地实现，而不会造成任何负面的意想不到的后果。这阻止了工程师“转移负担”(用系统思维的术语来说)到环境中无法承受负担的其他部分(圣吉，2006)。这也阻止了涉及子优化的问题，当整个系统在实现系统的目的时，可能会发生这种问题(Sillitto 2012)。

系统方法(源于系统思维)和系统工程(SE)已经在很大程度上独立地发展和成熟;因此，系统科学和系统工程团体在他们的观点上存在分歧，他们认为系统工程在多大程度上是基于系统方法的，以及系统工程在多大程度上很好地使用了系统思维的概念、原则、模式和表示。下面将讨论这两个视图。

系统科学视图

正如在系统科学文章中所讨论的那样，系统运动的某些部分是作为对系统工程的感知局限性的一种反应而开发的(Checkland 1999)。

根据Ryan(2008)的说法:

系统工程的历史与系统运动是完全分开的。它最紧密的历史联系来自于将系统分析技术应用到部分系统工程过程中…系统工程文献中最近流行的SoS流行词促使了系统工程技术的扩展，包括能够应对半自治系统不断演化的网络的方法。这使得许多系统工程师更广泛地阅读系统文献，并且提供了作为系统运动一部分的系统工程的重新概念化，尽管它在历史上是独立的。这反映在最新的INCOSE手册[INCOSE 2011，第52页]，其中指出“系统工程的观点是基于系统思维”，“认识到循环因果关系，一个变量既是另一个变量的原因也是另一个变量的结果，认识到相互关系和非线性有机思维的首要性——一种认识到整体首要性的思维方式。(重点)

因此，对于系统科学界的许多人来说，系统思维并没有自然地嵌入SE定义或实践中。

系统工程视图

许多 SE 作者看到了 SE 和系统思维之间的明确联系。例如，Hitchins (Hitchins 2007) 描述了将系统思维应用于工程系统上下文的通用模型。他建议这些可以构成对 SE 实践的描述和标准的基础。 Hitchins 还提出了一套指导原则，这些原则显然是 SE 的基础（Hitchins 2009）：

SE 原则 A：系统方法 ——“SE 在更广泛的系统环境中应用于感兴趣的系统 (SoI) ”
SE 原则 B：综合 -“SE 必须将一系列部件组合在一起以创建整个系统解决方案”
SE 原则 C：整体论 ——“在对系统元素做出决策时，始终考虑对更广泛系统的影响”
SE 原则 D：有机体类比 ——“始终将系统视为在其环境中具有动态的“活”行为”
SE 原则 E：自适应优化 -“随着时间的推移逐步解决问题”
SE 原则 F：渐进式熵减少 ——“通过维护、维持和升级活动，继续使系统随着时间的推移而工作。”
SE 原则 G：适应性满足 ——“一个系统只有在其成功关键的利益相关者中获胜时才会成功，因此系统的生命周期必须由其输出对利益相关者目标的贡献程度来驱动”

Hitchins 认为 AD 原则是 SE 的支柱，它确定了系统思维的关键方面，这些方面应该支持 SE 的实践。原则 EG 考虑 SE 生命周期思维的动态，SE 的原因、时间和频率。

以下部分针对四个主题考虑工程系统的系统方法。

1. 整个系统

系统耦合图（图 1）描述了工程系统的系统方法的范围（Lawson 2010）。

情境系统是指未计划或计划的问题或机会。这种情况可能是自然的、人为的、两者的结合，也可能是作为深入理解和训练基础的假设情况（例如商业游戏或军事演习）。
响应系统是为响应情况而创建的系统。双杠表示该系统与情况相互作用并将其转换为新情况。响应系统有几个名称：项目、计划、任务、工作组，或者在科学背景下，实验。
系统资产是一个或多个企业用于应对形势的持续资产。系统资产必须在系统的整个生命周期内得到充分管理，以确保它们在响应系统中实例化时执行其功能。例子包括：增值产品或服务、设施、仪器和工具，以及抽象系统，如理论、知识、过程和方法。

Martin (Martin 2004) 描述了七种类型的系统，系统开发人员需要了解所有这些类型才能开发成功的系统：

情境系统
干预系统
实现系统
部署的系统
协作系统
维护系统
竞争系统

Martin 认为，在为复杂的自适应情况设计解决方案时，必须明确承认和理解所有七个系统。

这些观点和其他观点描述了应用于工程系统时系统方法的一个方面；此外，它适用于理解问题，组织解决该问题，并创建和整合任何相关资产和能力以实现该解决方案。

2. 全生命周期

Ring（Ring 1998）为生命周期和“持续” 系统的持续管理和定期升级提供了一个强大的框架。它还准确地代表了在大多数产品和服务系统消费市场中看到的由市场反馈和不断创新驱动的“持续”或非常快速的产品发布和更新周期。

对于企业资产和服务的不同子集，可以在该模型的多个并发实例中考虑企业系统工程，以便在复杂和动态的外部环境中保持追求企业目标的能力。

此周期的动态特性及其与生命周期思维的关系在应用系统方法一文中进行了讨论。

3. 整个问题

《识别和理解问题与机遇》这篇文章考虑了问题情境的本质。它讨论了问题的硬系统和软系统视图之间的关系以及它们与工程系统的关系。工程系统旨在与包含的社会和/或生态系统一起运行并为其增加价值。问题的范围由诸如政治、经济、社会、技术、法律和环境 (PESTLE) (Gillespie 2007) 或社会、技术、经济、环境、政治、法律、伦理和人口 (STEEPLED) 等框架捕获。

还讨论了邪恶问题的概念（Rittel和Webber 1973）。在传统的工程意义上，这些问题无法量化和解决。

Sillitto (Sillitto 2010) 描述了一个生命周期模型，在该模型中，关于问题的哪些部分可以“解决” 以及哪些部分必须“管理” 是第一个关键决策，并强调需要一种提供灵活性的解决方案方法。解决方案以匹配问题和利益相关者期望的不确定性和变化水平。现在将问题视为“随时间变化” 的问题并提倡价值由关键利益相关者的看法决定的信念是正常的。

因此，在解决问题情况的各个层面时，系统方法可能很有用，从单个技术到工程系统开发领域出现的复杂社会技术问题。

4. 多学科

正如 Sillitto (Sillitto 2012) 所讨论的，许多实践系统工程师应用的方法和思维已经针对实践领域进行了优化。虽然系统思维概念、模式和方法被广泛使用，但它们在 SE 实践中并不普遍。结果，SE 从业者发现很难与参与系统方法的其他人分享系统想法。第 4 部分：系统工程的应用描述了传统的（基于产品的）SE（Lawson 2010），并对照适用于服务、企业和系统能力系统的 SE 方法对其进行了检验。这些方法需要更多地使用问题探索、更广泛的解决方案上下文和目的驱动的生命周期思维。

SE 和系统方法

从上述讨论中，SE 可以通过三种方式使用系统方法：

在其整体解决问题的方法中
在考虑的问题和解决方案系统语境的范围内
在嵌入系统思维和系统思维工具以及实施该方法的各个方面

当前的 SE 标准和指南，如第 3 部分：系统工程和管理中所述，封装了系统方法的许多元素。然而，他们倾向于主要关注系统解决方案的开发，而更广泛的目的驱动的完整系统方法（Ring 1998）和对所有相关系统的更广泛考虑（Martin 2004）嵌入在采购和运营实践中。他们的应用领域。

将系统思维纳入 SE 能力框架 (INCOSE 2010) 代表了在 SE 实践中更多地使用系统思维的总体趋势。广泛的利益相关者希望通过应用 SE 获得系统方法的好处，特别是在当前 SE 方法不充分或不相关的领域。因此，需要更好地阐明系统方法以及如何将其应用于非传统问题。

SEBOK 的合成

SEBoK 中提出的系统方法使用以下活动：

识别和理解现实世界中潜在问题和机会之间的关系。
深入了解问题并在更广泛的系统和环境的背景下描述选定的问题或机会
针对选定的问题或机会情况综合可行的系统解决方案
针对给定的时间/成本/质量版本的问题，分析并选择替代解决方案。
提供解决方案已正确实施和集成的证据
部署、维持和应用解决方案来帮助解决问题（或利用机会）

以上所有内容都在生命周期（词汇表）框架内考虑，该框架可能需要部分或全部系统方法的并发、递归（词汇表）和迭代应用。

当系统方法在工程系统（词汇表）的现实世界中执行时，会出现许多工程和管理学科，包括 SE。第 3 部分：系统工程和管理和第 4 部分：系统工程的应用包含 SE 的详细指南，其中引用了相关的系统方法的原则。第 5 部分：启用系统工程提供了 SE 与组织之间关系的指南，第 6 部分：相关学科也提供了 SE 与其他学科之间关系的指南。

有关系统方法如何与这些工程和管理学科相关的更详细讨论，请参见在本 KA 中应用系统方法一文。

系统工程的背景

本文是应用于工程系统知识领域 (KA) 的系统方法的一部分。它描述了与系统基础知识KA 中介绍的工程系统和工程系统背景的思想的进一步扩展相关的知识。

系统方法的一个最重要的原则是，它应用于工程系统环境，而不仅仅是单个系统(INCOSE 2012)。系统方法包括对工程系统的理解、创建、使用和维护有用的模型和活动，以实现大众化的需求。使用系统方法(如系统工程(SE))的教程考虑定义大众化需求的工程系统背景，并通过将管理的技术活动应用到一个或多个选定的利益兴趣的工程系统(SoI)来寻找提供价值的最佳方法。

一般来说，在SE中可以识别出四种特定类型的工程系统背景:

产品体系
服务体系
企业制度
Systems_of_Systems（SOS）能力

这些系统背景之间的一个关键区别与如何绘制、什么时间绘制SoI边界有关。

利益相关的系统工程

我们使用工程系统背景的思想来定义工程SoI，并捕获它们之间的重要关系，与直接工作的系统，以及任何其他系统。系统方法(以及SE)的所有应用程序都应用于系统背景中，而不是仅应用于单个系统。

系统背景可以围绕以下一组开放系统关系构建(Flood and Carson 1993):

狭义的利益体系（NSoI）是观察者直接关注的体系。该系统的重点是由权力或控制范围驱动的，并隐含着这样一种认识，即该范围可能不会涵盖所有相关要素。。
更广泛的兴趣系统（WSoI）描述了一个逻辑系统边界，包含了完全理解系统行为所需的所有元素。观察员可能对WSoI中的所有要素没有权限，但能够建立WSoI要素和NSoI要素之间的关系。
WSoI存在于一个环境中。直接环境包含工程、自然和/或社会系统，WSoI（以及NSoI的一些元素）与之直接互动，以交换材料、信息和/或能量，实现其目标。
一个更广泛的环境完成了整个环境，其中包含的系统与SoI没有直接交互，但可能会在其生命周期内影响与其相关的决策。
“数学建模的一些理论考虑”（Flood 1987）扩展了这个背景以包括存在于 WSoI 之外并对其进行直接控制的 元系统(MS)。

特定活动的 SoI 边界的选择取决于哪些可以更改，哪些必须保持不变。 SoI 将始终包括一个或多个 NSoI，但在适当时也可能包括 WSoI 和 MS，例如在考虑服务或企业系统时。

应用系统背景

对于较低级别和不太复杂的系统，WSoI 可以表示产品系统层次结构的级别。这方面的一个例子是作为发动机一部分的发动机管理单元，或作为汽车一部分的发动机。系统背景中的 WSoI 可以封装足够复杂系统的 SoS 思想的某些方面。在这些情况下，WSoI 代表了一组具有自己目标和所有权的系统，NSoI 必须与这些系统合作以实现共同目标。这方面的一个例子是为运输服务做出贡献的汽车和司机。

这种将 SoS 背景用作支持 NSoI 产品系统工程的手段的观点是可以应用系统方法的一种方式。它也可以直接应用于 SoS。这方面的例子包括灵活的多车辆运输服务或作为商业企业一部分的运输。在这种情况下，背景的 NSoI 方面不再适用。 WSoI 将由一组协作系统组成，每个系统都可能被更改或替换以帮助合成解决方案。背景可能还需要表示 松散耦合 ，一些系统根据需要移入或移出背景，或者与仅在或接近服务交付时加入背景的系统进行 后期绑定。

因此，背景允许对观察者直接关注的 SoI 进行简化视图，因为它提供了维持对所采取的任何行动的后果的整体视图所需的系统关系和影响。

产品系统背景

系统类型一文中讨论了产品和产品系统之间的区别。

产品系统背景将是其中 SoI 是产品本身的背景。产品系统的更广泛的系统背景可以是更高级别的产品层次结构、服务或直接使用产品来帮助为用户提供价值的企业系统。产品系统背景的一个重要方面是清楚地说明产品的用途，并确保在交付时将此信息提供给需方。客户将被要求接受该系统，通常是通过正式程序，同意不违反使用条款。

如果将系统方法应用于产品背景，则其目的是设计一个狭窄的系统产品，以便在更广泛的系统产品层次结构中集成和使用，或者使更广泛的系统服务能够直接交付给用户。企业。

这种产品和服务之间关系的观点是特定于产品系统工程的。虽然收单方静态服务系统的某些工程可能会发生，但它是以产品为中心完成的。服务系统工程背景中的服务系统定义描述了服务系统的更加动态的视图。

服务系统背景

服务是通过服务提供商和客户之间共同商定的条款导致实体（人员、产品、业务、地区或国家）状态转变的活动（Spohrer 2008）。系统类型一文中讨论了服务和服务系统之间的区别。

服务系统背景是其中 SoI 是服务系统的背景。此 SoI 包含启用服务所需的所有技术、基础设施、人员、资源等。 WSoI 描述了提供服务的企业以及它与影响企业成功的其他服务的关系。

如果将系统方法应用于服务系统，则其目的是设计服务系统以使企业所需的结果能够满足其客户。在服务系统环境中运行时，必须考虑提供服务的所有选项，前提是它们符合企业的约束条件。这将包括与企业中其他服务、人员和资源的接口。如果提供服务的选项利用了企业内部或外部的现有产品或资源，则必须确保它们可用于此用途并且不会对其他服务产生不利影响。获得正确服务的一部分可能需要就更广泛的企业环境的变化进行协商，但这必须与相关当局达成协议。

对于一个服务系统，同样考虑到服务系统的背景，价值只能通过服务交易来实现。最终用户在请求使用服务时共同创造价值。例如，使用智能手机预订航班，服务系统由许多服务系统实体（主叫方、被叫方、智能手机、接入网、核心互联网协议（IP）网络、互联网服务提供商（ISP）、万维网（WWW）、数据中心等，这些都是服务开通所必需的，当主叫方进行预订，然后预订航班时，价值就被创造出来了。

与动态信息技术(IT) 服务相关的服务系统定义将在文章服务系统工程中进一步讨论。

企业系统背景

系统类型一文中讨论了企业和企业系统之间的区别。

企业系统背景是其中 SoI 是企业系统的背景。该系统包含启用服务所需的所有技术、基础设施、人员、资源等。 WSoI 描述了企业所处的业务环境。

需要注意的是，根据这个定义，企业背景并不等同于 组织。 企业不仅包括参与其中的组织，还包括组成企业的人员、知识和其他资产，如流程、原则、政策、实践、学说、理论、信仰、设施、土地和知识产权.

企业可能包含或使用与产品系统一起的服务系统。一个企业甚至可能包含子企业。与产品和服务系统相比，企业系统的独特之处在于：

他们在不断发展
他们很少有详细的配置控制要求
他们通常有（不断变化的）提供股东价值和客户满意度的目标
它们存在于定义不明确且不断变化的背景（或环境）中

企业系统工程师必须在其流程和方法中考虑并考虑这些因素。

产品和服务系统都需要企业系统背景来创建它们，并且需要企业使用产品系统并在企业内部或外部向更广泛的社区提供服务。因此，无论开发人员将哪种类型的系统视为交付给客户的开发工作的对象，这三种类型的工程系统背景在所有情况下都是相互关联的。

识别理解问题和机遇

本主题是应用于工程系统知识领域 (KA) 的系统方法的一部分。它详细描述了与识别和理解问题或机遇相关的知识。本主题中的活动所描述的问题情况可以作为综合可能解决方案的起点。下面描述的任何活动也可能需要在一个相关系统(SoI)生命周期的特定时刻与系统方法中的其他活动同时考虑。

下面描述的活动应在本 KA 开始时的系统方法概述主题的背景中考虑。该知识领域的最后一个主题是应用系统方法，它考虑了如何将这些活动用作系统方法的一部分的动态方面，以及这如何与系统工程 (SE) 的元素详细关联

这里使用的短语“问题或机遇”承认“问题”并不总是消极的情况，也可以是改善情况的积极机遇。

介绍

根据 Jenkins (1969) 的说法，系统方法的第一步是“识别和制定问题”。 SE 知识体系指南 (SEBoK) 中描述的系统方法主要是一种硬系统方法。该方法的分析、综合和证明部分假定问题或机遇已被识别并达成一致，并且需要“新的” 工程系统解决方案。

然而，系统方法不一定适用于新设计和构建的技术解决方案的开发和使用。可能会理解针对潜在问题的抽象或实验性解决方案，以帮助就问题背景达成一致。解决方案可能涉及重组现有系统(SoS) 背景或修改或重用现有产品和服务。该方法的问题和机遇部分与软系统方法重叠。这将在下面更详细地讨论。

关于系统复杂性必须考虑的一件事是机遇情况可能难以完全理解；因此，系统解决方案可能不会在第一次解决问题，但仍然有助于加深对问题问题的理解以及下一步要尝试什么来解决问题。

因此，问题理解和识别通常不是指定问题的一次性过程，而是与解决方案综合和分析结合使用，以便随着时间的推移更全面地理解问题和解决方案（参见应用系统方法更完整地讨论该方法的这一方面的动态）。

问题理解

软系统思维不寻找“问题”，而是考虑有问题的情况。形成这种情况的系统视图以帮助利益相关者更好地理解彼此的观点，并为当前系统环境中的定向干预提供一个起点。如果进行完整的软系统干预，例如软系统方法论 (SSM) (Checkland 1999)，它将不包括形式分析、综合和证明。然而，SSM 方法最初是基于硬方法论，特别是 Jenkins (1969) 提出的一种方法。它遵循系统方法的基本原则：“分析” 概念模型共同理解，“综合”干预策略，并“证明”问题情况的改善。

通常，硬方法和软方法之间的区别并不像理论所暗示的那样清晰。作为信息系统设计开发的一部分，Checkland 本人参与了 SSM 的应用（Checkland 和 Holwell 1998）。现在很多人都同意，虽然“纯软系统”方法可以发挥作用，但现在解决的服务和企业问题只能通过软问题模型和硬系统的结合来成功处理解决方案。 Mingers and White (2009) 给出了一些相关的例子。特别是，他们引用了“过程和内容：使用 SSM 的两种方式”（Checkland 和 Winters 2006）。将来，工程系统问题很可能会被陈述、解决并用作主要软干预的一部分，这将对解决方案空间所需的开发速度施加压力。这在主题生命周期模型中进行了更全面的讨论。

批判性系统思维和多方法论方法（Jackson 1985）通过提倡“挑选和混合”方法进一步推动了这一点，其中选择最合适的模型和技术来适应问题，而不是遵循单一的方法论（Mingers 和 Gill 1997 年）。因此，即使使用下面描述的硬问题识别方法，也应该在其中考虑使用一些软系统技术（例如丰富的图片、根定义或概念模型）。

问题识别

硬系统思维的前提是存在问题，并且可以由一个或多个利益相关者以客观的方式陈述。这并不意味着硬系统方法从定义的问题开始。与关键利益相关者一起理解潜在问题仍然是该方法的重要组成部分。

根据 Blanchard 和 Fabrycky (2006, 55-56) 的说法，定义问题有时是最重要和最困难的一步。简而言之，除非可以清楚地描述它应该完成的工作，否则无法定义一个系统。

根据 Edson (2008, 26-29) 的说法，需要提出三种问题来确保我们完全理解问题的情况。首先，问题的难度或理解程度如何？这个问题的答案将有助于确定问题的易处理性。问题可以是“温和的”、“常规的”或“邪恶的”：

对于温和的问题，解决方案可能是明确且显而易见的。
常规问题是定期遇到的问题。它们的解决方案可能并不明显，因此应认真关注它们的各个方面。
棘手的问题（Rittel and Webber 1973）无法完全解决，甚至可能无法完全定义。此外，对于棘手的问题，不可能理解将系统应用于问题的全部效果。

接下来，谁或什么受到影响？可能存在导致问题的情况元素、受问题影响的元素以及仅在循环中的元素。除了这些因素之外，什么是环境以及影响问题的外部因素是什么？在检查这些方面时，可以有效地应用系统思维的工具和方法。

最后，问题的各种观点是什么？大家觉得有问题吗？也许存在相互矛盾的观点。所有这些观点都需要定义。受系统影响、从系统中受益或可能受到系统伤害的人被称为利益相关者。 Wasson (2006, 42-45) 提供了一份完整的利益相关者类型列表。如上所述，软系统模型的使用可以在其中发挥重要作用。在考虑这些问题时，使用情境视图来描述问题可能很有用，即使选择了单个问题观点以供进一步考虑。

运筹学是一种硬系统方法，它专注于通过部署已知的解决方案来解决问题情况。典型方法的问题分析步骤询问有关当前系统的局限性和成本的问题，以确定需要进行的效率改进（Flood 和 Carson 1993）。

传统的 SE 方法倾向于更多地关注描述问题的抽象模型，然后使用该模型开发一个解决方案，该解决方案将产生利益相关者期望看到的好处（Jenkins 1969）。人们通常期望必须创建一个新的解决方案，尽管情况并非如此。 Jenkins 建议 SE 同样适用于现有系统的重新设计。清楚地了解利益相关者在这方面的期望应该可以更好地理解部分问题。利益相关者是否期望新的解决方案或对其现有解决方案的修改，或者他们是否真正对考虑两者优缺点的解决方案解决方案持开放态度？如综合可能的解决方案中所述，此类期望将影响解决方案的建议文章。

定义所需的利益相关者结果、利益和约束的一个重要因素是存在问题或机遇的操作环境或场景。 Armstrong (2009, 1030) 提出了两种情景：第一种是描述性情景，即现在存在的情况，第二种是规范性情景，即未来某个时间可能存在的情况。

问题理解的所有这些方面都可以与系统背景的概念相关。

问题背景

工程系统背景主题确定了一种可以围绕利益相关的系统(SoI)解决复杂系统情况的方法。“问题背景”的初始识别可以被认为是系统方法的这一部分的结果。

系统方法不应只考虑软或硬情况。更恰当地说，应该使用两者的方面来理解问题或机遇。一般而言，以工程系统背景为重点的系统方法的应用将导致硬系统背景，其中可以定义已识别的 SoI 和所需的结果。

更广泛的 SoI 和环境的初始描述用作问题或机遇问题范围。期望的利益相关者利益在更广泛的系统中被表达为结果，并且可以确定 SoI 预期用途的一些初始表达。 Jenkins (1969) 定义了一种问题表述方法，其中：

说明 SoI 的目标
定义了更广泛的 SoI
定义更广泛的 SoI 的目标
定义系统的目标
定义经济、信息和其他条件

在硬系统问题背景中，可能包括对逻辑或理想系统解决方案的描述。这个理想系统不能直接实现，而是描述了任何可实现的系统解决方案所需的属性。

为了支持这个问题或机遇描述，SoI 的软背景视图将有助于确保考虑更广泛的利益相关者的关注。如果定义了软系统背景，它可能包括一个概念模型（Checkland 1999），该模型描述了解决问题情况的系统的逻辑元素以及不同利益相关者如何看待它们。与硬系统视图不同，这并没有描述理想的解决方案，而是提供了关于潜在利益相关者如何看待任何解决方案的各个方面的替代视图。

在具有强强制性维度的问题背景下，问题背景应包括对利益相关者的相对权力和重要性的识别。

问题背景应包括利益相关者所需的成本、部署时间、使用时间和运营有效性的一些界限。一般而言，既描述了完整的问题背景，也描述了接下来要解决的问题的商定版本。（请参阅应用系统方法。）

综合可能的解决方案

本主题是应用于工程系统知识领域（KA）的系统方法的一部分。它描述了与综合可能的解决方案选项相关的知识，以响应活动从识别和理解问题和机遇主题中描述的问题情况。综合活动提出的解决方案选项将成为分析和选择解决方案的起点。在系统的利益（SoI）生命周期的某个特定点，以下描述的任何活动也可能需要与系统方法中的其他活动同时考虑。

以下描述的活动应在本KA开始时系统方法主题概述的背景下考虑。本KA的最后一个主题是应用系统方法，它考虑了这些活动如何作为系统方法的一部分使用的动态方面，以及这些活动如何与系统工程（SE）的元素详细关联。

综合概览

系统综合是系统方法中的一项活动，用于根据系统生命周期的问题背景描述一个或多个系统解决方案，以：

为SoI定义选项，并为已识别的问题或机会上下文定义所需的属性和行为。
在SoI的预期环境中提供与SoI相关的解决方案选项，以便在问题背景中描述的规定时限、成本和风险内评估这些选项是否可能实现
在更广泛的系统环境中评估每个候选解决方案的属性和行为。

系统综合的迭代活动开发可能的解决方案，并可能对所述解决方案的可行性做出一些总体判断。关于一个解决方案是否适用于系统方法的给定迭代的详细判断是通过分析和选择备选解决方案活动来进行的。

对综合来说至关重要的是整体主义的概念（Hitchins 2009），它指出一个系统必须被视为一个整体，而不仅仅是其元素的集合。任何潜在解决方案系统的整体性要求通过在预期环境中处理系统而不是简单地累积元素的属性来确定整体的行为。后一个过程被称为还原论，与整体论相反，希钦斯（Hitchins，2009，60）将整体论描述为“系统的属性、能力和行为源自其部分、这些部分之间的相互作用以及与其他系统的相互作用”的概念

当系统被视为一个整体时，通常会出现称为新兴的的属性（参见系统工程的出现）。这些特性通常很难仅从元素的特性来预测。必须在系统方法中对其进行评估，以确定系统的整套性能水平。根据Jackson（2010）的说法，在设计系统时可以考虑这些特性，但要做到这一点，需要一种迭代方法。

在复杂系统中，单个元素将适应其他元素的行为以及整个系统。整个元素集合将表现为一个有机整体。因此，整个合成活动，尤其是在复杂系统中，本身必须是自适应的。

因此，综合通常不是解决方案设计的一次性过程，而是与问题理解和解决方案分析结合使用，以便随着时间的推移，更全面地理解问题和解决方案（有关该方法这一方面的动力学更完整的讨论，请参阅应用系统方法主题）。

问题或机遇背景

系统综合需要解决系统打算处理的问题或机遇已经被识别和描述，对于非平凡系统，问题或机遇需要与解决方案综合活动同时被识别和理解。

正如在识别和理解问题和机会方面所讨论的，系统方法不应考虑严格的软或硬情况。一般来说，系统方法的应用（重点是工程系统环境）将导致硬系统环境，在硬系统环境中定义已识别的SoI和所需的结果。即使在这些情况下，SoI环境的软环境视图也将有助于确保考虑更广泛的利益相关者问题。

问题背景应包括利益相关者所需的成本、部署时间、使用时间和运营效率方面的一些界限。一般来说，目标不是综合问题的完美解决方案，而是为问题的商定版本找到最佳可用解决方案。

综合活动

以下活动提供了定义SoI的大纲：元件分组、元件之间相互作用的识别、元件之间接口的识别、SoI边界外部接口的识别以及SoI边界内的公共子元件。

系统边界的识别

确定系统的边界对于综合、确定系统与其环境和其他系统的相互作用以及SoI的范围至关重要。Buede（2009，1102）全面讨论了在SE环境中定义系统边界的重要性和方法。

系统功能识别

给定抽象级别的系统功能对合成至关重要，因为合成活动的主要目标是提出可实现的系统描述，从而提供给定的功能。系统的功能不同于其行为，因为它描述了系统在更大的系统环境中可以用于或被要求做什么。

Buede（2009，1091-1126）提供了SE环境下功能分析的全面描述。

识别系统元素

系统综合要求识别系统的元素。工程系统环境的典型元素可能是物理、概念或过程。物理元素可以是硬件、软件或人。概念元素可以是想法、计划、概念或假设。过程可能是心理的、心理运动的（书写、绘图等）、机械的或电子的（Blanchard and Fabrycky 2006，7）。

除了考虑中的系统要素（即SoI），ISO 15288（ISO/IEC/IEEE 15288 2015）还要求识别启用系统。这些系统（或服务）在生命周期的不同阶段使用，例如开发、利用或支持阶段，以促进SoI实现其目标。

今天的系统通常包括现有的元素。很难找到一个真正的“绿地”系统，开发者可以从零开始指定和实现所有新元素。“棕地”系统更为典型（Boehm 2009），其中遗留元素约束系统结构、能力、技术选择和实施的其他方面。

系统元素的划分

系统综合可能需要将元素划分为更小的元素。如莱文（2009，493-495）所述，将元素划分为更小的元素可以对系统进行分组，并产生物理架构的SE概念。每一层划分都会导致系统层次视图的另一层。正如莱文指出的，有许多方法来描述物理架构，包括使用接线图、方框图等。所有这些视图都取决于元素的排列，并将它们划分为更小的元素。根据递归原理，这些分解的元素要么是终端元素，要么是可分解的。分层视图并不意味着用自上而下的分析方法来定义系统。这只是一种观点。在系统方法中，层次结构的级别是递归定义和考虑的，其中一个级别构成下一个级别的上下文。

系统元素分组

系统综合可能需要对元素进行分组。这导致识别对系统定义至关重要的子系统。综合决定了一个系统如何被划分，以及每个子系统如何适应整个系统并发挥作用。最大的一组是 SoI，Checkland (1999, 166) 也将其称为相关系统。根据 Hitchins 的说法，SoI 的一些属性如下：SoI 是开放的和动态的，SoI 与其他系统交互，并且 SoI 包含子系统 (Hitchins 2009, 61)。 SoI 是通过综合的概念组合在一起的。

识别系统元素之间的相互作用

系统综合可能需要识别系统元素之间的相互作用。这些相互作用导致界面分析的 SE 过程。这方面不可或缺的是相互作用的原则。与其他系统元素以及与外部元素和环境的交互都会发生。在系统方法中，接口具有技术和管理的重要性。管理方面包括接口组织之间的合同。技术方面包括物理和功能接口的属性。 Browning 提供了技术和管理界面特征的理想特征列表（Browning 2009, 1418-1419）。

系统综合将包括了解系统元素的属性、建议的系统解决方案的结构以及组合系统的最终行为的活动。系统思维的概念主题中讨论了许多用于描述系统行为的系统概念。应该注意的是，为了完全理解系统的行为，我们必须考虑它可能被放置的所有环境及其在每个环境中的允许状态。根据佩奇的说法，在复杂系统中，系统的各个元素都具有增强整个系统的特性，例如它们的适应性（Page 2009）。

界定利益体系

Flood和Carson提供了两种确定系统边界的方法：一种是自下而上的方法，即结构方法，从重要的系统元素和构建开始；另一种是自上而下的方法，即行为方法，即确定实现目标所需的主要系统，然后工作向下流动（Flood和Carson 1993）。他们确定了Beishon（1980）和Jones（1982）提出的一些规则，以帮助选择最佳方法。

在任何一种情况下，系统元素的细化、分组和分配方式都必须朝着可实现的系统解决方案描述的综合方向发展。可实现的解决方案必须考虑已经可用的元素，可以从现有的系统元素创建，或者它们本身被描述为需要在未来点合成的系统上下文。在第三种情况下，它是分析和选择解决方案活动的结果之一，用于评估给定要素可能无法在要求的时限或成本预算中合成的风险。

自上而下的方法可以从系统边界和系统功能的总体描述开始。通过反复应用元件识别、划分、分组和功能分配，可以定义SoI所需元件的完整描述。在这种情况下，系统元素的选择和功能的分配可以由解决给定问题的预定义方法或确定的系统模式来指导；两者都可以支持合成，也可以在合成中插入偏见。例如，一开始可能需要为一个新的住房项目提供能源，并根据与现有电网的连接、当地发电机、可再生能源、提高能源效率等提出解决方案。

分析的迭代性质也反映了随着生命周期的进展和系统环境的变化而改变解决方案的需要；因此，可能会改变什么是“最佳”解决方案。

自下而上的方法从主要元素和交互开始。同样，划分、分组和识别允许构建完整的系统描述，该描述能够提供所有必要的功能，此时可以设置最终SoI边界。在这种情况下，系统元素和分组的选择将以确保主要系统元素可以一起形成一个可行的系统整体为目标。例如，可能需要更换现有的配送车辆并产生考虑车辆所有权/租赁、驾驶员培训、汽油、柴油或电燃料等的解决方案。

综合的系统方法方面导致了SE术语，如“设计”和“开发”Wasson从SE的角度描述合成（Wasson 2006，390-690）。White全面讨论了实现设计综合的方法（White 2009，512-515）。系统方法在抽象级别处理综合，而SE过程定义提供具体步骤。

SoI通过综合概念将元素、子系统和系统结合在一起，以确定解决方案选项。

可能解决方案的综合可能会导致开发记录综合本身的工件，并为分析和选择替代解决方案提供基础。这些工件是动态的，并且会随着SoI在整个系统生命周期中改变其环境而改变。

备选方案的分析和选择

本主题是应用于工程系统知识领域（KA）的系统方法的一部分。它描述了与分析和从可能的选项中选择首选解决方案相关的知识，这些选项可能是通过综合可能的解决方案提出的。选定的解决方案选项可能构成实施和证明解决方案的起点。在系统的利益（SoI）生命周期的某个特定点，以下描述的任何活动也可能需要与系统方法中的其他活动同时考虑。

系统分析

系统分析是系统方法中的一项活动，用于评估在综合可能解决方案的活动中创建的一个或多个系统工件，例如：

根据已识别问题或机会系统情况的所需属性和行为定义评估标准。
对照标准访问每个候选解决方案的属性和行为。
比较对候选解决方案的评估，确定任何可能解决问题或利用机会的方案，以及应进一步探索的候选方案的选择。

正如综合可能的解决方案主题中所讨论的，工程系统的问题背景将包括逻辑或理想系统解决方案描述。假设“最佳”与理想方案匹配的解决方案将是利益相关者最可接受的解决方案。注：如下文所述，“最佳”解决方案应包括对成本和风险以及有效性的理解。问题背景可能包括一个软系统概念模型，该模型描述了解决问题情况的系统逻辑要素，以及不同利益相关者如何看待这些要素（Checkland 1999）。这种软背景视图将为分析过程提供额外的标准，这可能成为在两种同等有效的解决方案之间进行选择的关键问题。

因此，分析通常不是解决方案选择的一次性过程；相反，它与问题理解和解决方案综合结合使用，随着时间的推移，逐步实现对问题和解决方案的更全面理解（有关该方法这一方面的动力学的更完整讨论，请参阅应用系统方法主题）。

有效性分析

有效性研究将问题或机会系统背景作为起点。

综合系统解决方案的有效性将包括与系统主要功能和启用功能相关的性能标准。这些来源于系统的目的，以便在一个或多个更广泛的系统环境中实现利益相关者的需求。

对于一个产品系统，有一组与不同类型的解决方案模式或技术相关的通用非功能性品质，例如安全性、可靠性、可维护性、可用性等。这些标准通常作为技术领域相关技术学科领域知识的一部分明确说明。

对于服务系统或企业系统，标准将更直接地与确定的用户需求或企业目标联系起来。这类系统的典型特征包括敏捷性、弹性、灵活性和可升级性等。

除了评估给定解决方案系统的绝对有效性外，系统工程师还必须能够将有效性与问题背景中的成本和时间限制结合起来。一般来说，系统分析的作用是确定提议的解决方案，这些解决方案可以在分配给系统方法的任何给定迭代的成本和时间内提供一些有效性（有关详细信息，请参阅应用系统方法）。如果没有一个解决方案能够提供一个有效性水平来证明拟议投资的合理性，那么就有必要回到问题的原始框架。如果至少有一种解决方案被评估为足够有效，则可以在两种解决方案之间进行选择。

比较研究

在系统定义的背景下，权衡研究包括将每个候选系统元素的特征与每个候选系统架构的特征进行比较，以确定以最佳方式在全球范围内平衡评估标准的解决方案。成本分析、技术风险分析和有效性分析（NASA 2007）中收集了分析的各种特征。要完成权衡研究，有多种方法，通常由工具支持。每一类分析都是以下主题的主题：

评估标准用于对各种候选解决方案进行分类。它们要么是绝对的，要么是相对的。例如，每单位生产的最大成本为c$，成本降低为x%，效率提高为y%，风险缓解为z%。
边界识别和限制分析时要考虑的特征或标准（例如，要考虑的成本种类、可接受的技术风险以及有效性的类型和水平）。
量表用于量化特征、属性和/或标准并进行比较。它们的定义需要了解最高和最低限度，以及特性演变的类型（线性、对数等）。
评估分数被分配给每个候选解决方案的特征或标准。权衡研究的目标是成功量化每个候选解决方案的成本、风险和有效性这三个变量（及其分解为子变量）。这种操作通常很复杂，需要使用模型。
特征或属性的优化提高了有趣解决方案的评分。

决策过程不是一门准确的科学；因此，权衡研究有局限性。应考虑以下问题：

主观标准——分析师的个人偏见；例如，如果组件必须是漂亮的，那么什么是“漂亮”的组件？
不确定数据——例如，在估算系统整个生命周期内的维护成本时，必须考虑通货膨胀；系统工程师如何预测未来五年通货膨胀的演变？
敏感性分析——为每个候选解决方案指定的全局评估分数不是绝对的；因此，建议通过考虑评估标准值（权重）的微小变化的敏感性分析来收集稳健的选择。如果变化不改变分数的顺序，则选择是稳健的。

全面的权衡研究指定了结果的假设、变量和置信区间。

系统分析的系统原理

从上面的讨论中，可以定义以下系统分析的一般原则：

系统分析是一项迭代活动，包括在系统综合活动的各种解决方案选项之间进行的贸易研究。
系统分析使用基于问题或机会系统描述的评估标准。
- 这些标准将基于假设可以定义硬系统问题上下文的理想系统描述。
- 该标准必须考虑完整解决方案在所有可能的更广泛的系统上下文和环境中所需的系统行为和属性。
- 贸易研究需要同等考虑主要系统和使能系统作为一个单一系统来满足用户需求。这些研究需要考虑整个生命周期内关键性能参数 (KPP)、系统安全性和可负担性的系统要求。
- 这种理想的系统描述可以得到软系统描述的支持，从这些描述中可以定义额外的“软”标准（例如，利益相关者偏好或反对某些类型的解决方案以及在可能的解决方案中要考虑的相关社会、政治或文化惯例环境等）。

至少，评估标准应包括利益相关者可接受的成本和时间范围的限制。
贸易研究提供了一种对替代解决方案进行分析的机制。
- 贸易研究应考虑“评估标准系统”，特别注意各个标准之间的限制和依赖性。
- 贸易研究需要处理客观和主观标准。必须小心评估整体评估对特定标准的敏感性。

部署、使用和维护系统以解决问题

本主题是“应用于工程系统的系统方法”知识领域(KA)的一部分。它描述了与部署、维护和使用解决方案相关的知识，这些解决方案可能已经通过实现和证明解决方案主题中描述的活动开发出来。讨论部署的系统如何适应业务环境。在利益相关系统(SoI)的生命周期的某个特定点上，下面描述的任何活动都可能需要与系统方法中的其他活动同时考虑。

下面描述的活动应在本KA开始时的系统方法概述主题的背景中加以考虑。这个KA的最后一个主题，应用系统方法，考虑了这些活动如何作为系统方法的一部分被使用的动态方面，以及这些活动如何详细地与系统工程(SE)的元素相联系。

介绍

SE知识体系指南（SEBoK）的第3部分“系统工程和管理”提供了两个额外的KAs，用于解决系统方法这些步骤的工程方面。KAs产品和使用寿命管理以及系统部署和使用在第3部分中解释了部署、操作、维护、组织工作、使用寿命延长、更新、升级、处理和系统退化的SE方面。

系统方法考虑整个系统和系统的整个生命周期。这包括系统的所有方面以及系统在其整个生命周期内的所有方面，直到用户销毁系统和外部企业完成处理系统产品的处理。系统的创建很少是解决利益相关者问题的步骤。正是使用系统解决方案解决了这个问题。从这个角度来看，系统的部署、使用和维护是重要的概念，必须成为系统方法的一部分。

工程系统最终归个人、团队或企业所有。在开发过程中拥有系统的人可能不是在系统运行时拥有系统的人。此外，所有者可能不是用户；例如，服务系统可能由公众使用，但由提供服务的特定企业拥有。系统从开发过渡到运行本身往往是一项复杂的任务，包括培训系统操作人员，采取法律行动完成转移，以及建立组织工作安排，以便运营商在过渡完成后保持系统运行。

一个完整的系统方法也必须考虑到系统中涉及的许多企业从初始概念到完成处理过程。这些企业都是有需求的利益相关者，它们都有接口，必须被视为整个系统方法的一部分。

文献中很少有关于将系统方法应用于生命周期的这些阶段的内容。然而，这种KA的一个基本前提是，系统方法适用于系统生命周期的所有阶段。因此，为了正确构建系统以解决问题或用于其他用途，可以推断系统方法与系统的部署、使用和维护有关。本主题领域的许多可用参考文献来自SE文献，而不是与系统方法相关的文献；读者还应参阅SEBoK的第3部分，系统工程和管理。

部署：从开发到运营的过渡

SoI的保管权和支持责任从一个组织转移到另一个组织的过程中发生，通常被称为过渡（INCOSE 2011）。产品系统的过渡包括将系统集成到采购组织的基础设施中。部署和转换涉及将系统从开发位置移动到操作位置的活动，以及完成重新定位所需的支持系统。

过渡包括系统的初始安装，以及确定其与更广泛的系统兼容，并且不会导致任何重大的更广泛的系统问题。这种接受和发布使用的过程在不同领域、不同企业和企业之间有所不同，可以被认为是对系统有效性的初步评估（Hitchins 2007）。一般来说，过渡可以被认为有两部分：1。）确保新系统与周围系统的互操作性和2.）确保生成的系统是安全的，并具有其他关键的操作特性。

当新的系统被添加到现有组织的系统（SOS）网络中，以及新系统被转换的组织的复杂性（也见复杂性）时，考虑紧急特性是特别重要的。接收组织越复杂，过渡过程就越具有挑战性，新系统的插入就越有可能产生意外的互动和后果。应对这种复杂性的后果始于过渡阶段，并持续到运行、维护和处理阶段。

服务系统的过渡通常分为两个阶段。首先，服务系统基础设施被接受并发布。其次，接受并发布服务的每个实现。如果服务所需的响应性没有留出足够的时间来确保服务满足必要的功能和质量属性，包括互操作性、安全性和安全性，那么在第二阶段可能会出现重大问题。（参见服务系统工程。）

系统的过渡和部署可能会引入操作或使用不需要的独特需求。这些要求可能会影响系统的设计；因此，在最初的要求和设计阶段必须考虑到这一点。最常见的例子与运输系统或系统元件的需要有关，这通常会限制系统元件的尺寸和重量。

过渡还需要自己的使能系统，每个系统都可以使用系统方法实现。

用途:操作

利用该系统帮助提供用户服务通常被称为“操作”(INCOSE 2011)。一个系统的有效性通常在整个系统的运行周期内被考虑。对于一个复杂的系统，应该从三个方面考虑紧急行为:

识别和规划系统实现过程中的紧急属性（参见第 3 部分中的系统实现KA，系统工程和管理）
在系统使用过程中加入用于识别和处理系统内意外紧急属性的机制
提供必要的程序来处理企业中意外紧急属性的更广泛的系统后果（例如，紧急响应或医疗急救）

运营需要他们自己的支持系统，每个系统都可以使用系统方法来实现。

系统可持续性和可维护性

系统维护需要在系统的整个使用寿命期间对其进行维护（INCOSE 2011）。在系统方面，维护实现了处理熵并将 SoI 保持在可行状态的系统。由于开放系统通过与环境不断交换能量、信息和物质来维护其存在，因此其维护的一个方面必须是对环境中资源的管理。

Hitchins (2007) 描述了基于系统概念的资源管理和可行性管理的通用方法。资源管理确定需要考虑资源的获取、存储、分配、转换和处理。活力管理应考虑维护体内平衡的系统和确保对环境干扰的复原力和对环境变化的适应性的手段。

维护将需要自己的支持系统，每个系统都可以使用系统方法来实现。如果在系统投入使用之前就将其视为系统概念和设计的一部分，则维护成功的可能性更大。

处理

如果不考虑如何完成系统处理，就不能认为全生命周期系统方法是完整的。处理的目的是从运行环境中移除系统元件，以永久终止其使用，并移除任何危险或有毒材料或废物产品（INCOSE 2011）。

在处理过程中，整个开放系统从系统侧跨越边界到达环境。一个完整的系统方法必须考虑它是如何跨越边界的，剩下的必须由企业来管理，而不是那些开发、使用或维护系统的企业。在系统方法中包含处理扩展了必须考虑的利益相关者、企业和外部系统。

处理需要自己的启用系统，每个启用系统都可以使用系统方法实现。其中一些可能包含在系统边界内，另一些可能位于系统外部。对于外部处理系统，必须考虑发生移交的接口。与维护一样，成功处理的很大一部分要求在系统生命周期的早期就考虑相关问题。

SEBoK第3部分“系统工程和管理”中的“处理和退役”主题提供了有关系统处理工程方面的信息。

应用系统方法

系统方法既与问题解决的动态性有关，也与利益相关者随时间的价值有关，还与系统关系、详细管理以及这意味着的工程活动的水平有关。

本文以“系统方法概述”主题中介绍的概念为基础。它是应用于工程系统知识领域（KA）的系统方法的一部分，主要通过五组活动，描述了基于系统思维的方法在其整个生命周期中对工程系统环境的应用。

生命周期

工程系统通过帮助利益相关者在一个或多个问题情况下实现价值，从而为利益相关者提供利益。最终，一个系统只有在为其利益相关者带来成功结果的情况下才是成功的（Boehm和Jain，2006）。在复杂的现实世界中，根据渐进满足原则（Hitchins 2009），通过不断调整系统需求和开发相关解决方案以应对不断变化的环境，可以最好地提供价值。

将系统方法与交付真实世界的利益相关者相关联的价值循环在系统方法概述主题中进行了讨论。对工程系统在其上下文中价值的更深入的理解，使得在问题情况和适当的系统干预被创建、部署和整体使用上达成一致，反过来使系统方法的更有效的应用成为可能。只有在考虑时间、成本、资金和其他适合关键利益相关者的资源问题时，价值才能得到充分实现(1998年环)。

部署：从开发到运营的过渡

图1中的视图将系统干预的思想应用于解决可能需要一个或多个工程系统解决方案的问题情况。对于周期的每一个转折点，利益相关者和开发人员之间都达成了一项协议，即在商定的条件Z下，有效解决问题X的工程系统有机会交付价值a，他们愿意为此投入成本B和其他资源C。

正是在邪恶问题的本质上，这一命题不可能是确定的。生命周期模型中讨论了理解和管理解决此类问题的共同风险的生命周期方法。系统干预的概念来自软系统思维（参见系统方法）。

对于每一个工程系统问题，必须制定上述商定的解决方案，以使其在成本、性能和与问题领域相关的其他属性方面有效。开发人员不仅要考虑做什么，还要考虑何时和多少要提供真正的价值（SGEGN 1990）。在系统工程（SE）和管理实践中，这引出了两个关键概念（INCOSE 2011）：

生命周期： 利益相关者的价值和问题解决被描述为一组生命周期阶段，在这些阶段可以探索和解决问题，并且可以管理资源。
生命周期过程： 专注于创建和共享与系统方法相关的知识的活动系统，可用于在整个生命周期内促进整体方法。

生命周期管理提供了一个框架，在该框架中，可以对工程系统环境的所有方面采取系统方法，不仅包括系统产品或服务，还包括创建、部署和支持它的系统（Martin 2004）。下面的部分考虑在上面讨论的整个价值周期的上下文中，系统方法应如何应用于已识别的问题陈述。

应用原则

并发性

系统价值周期（Ring 1998）可以看作是在利益相关者价值驱动的问题解决周期内工程系统生命周期的通用模型。出于实际原因，有必要将这一生分解为一组有限的阶段，以便组织活动。我们可以将价值循环表示为六组问题，围绕与系统方法相关的价值、问题和解决方案问题进行循环：

利益相关者想要/需要什么价值观？
哪些系统结果可以提高这个值？
什么系统可以提供这些结果？
我们如何创建这样一个系统？
我们如何部署和使用系统来实现结果？
这些结果是否提供了预期的价值改进？

上述问题侧重于系统方法的每次迭代，以在企业环境中交付利益相关者目标。活动 1 和 6 是在企业内提供利益相关者价值的业务周期的一部分，而活动 2 到 5 可以直接映射到产品、服务和企业工程生命周期。这里区分了企业的正常业务和企业系统工程的长期战略活动。

下图说明了系统方法的活动随时间的并发性质。

生命周期：利益相关者的价值和问题解决被描述为一组生命周期阶段，在这些阶段中可以探索和解决问题，并管理资源。

生命周期过程：专注于创建和分享与系统方法相关的知识的活动系统，可用于在整个生命周期内促进整体方法。

迭代

系统方法可以以迭代的方式应用，以在更大的利益相关者价值周期内朝着可接受的解决方案迈进。

系统方法可以应用于工程系统环境中的多个系统，如下所述。在每个级别，可以迭代地应用该方法，以在生命周期模型内的所需内容和解决方案版本之间循环。

Hitchins (2009) 定义了与迭代相关的两个原则：

自适应优化： 持续重新设计解决问题空间，检测和解决情况、操作环境、其他交互系统和其他因素的变化；它不断构思、设计和实施或重新配置整个解决方案系统，以在当代运营环境中以最佳效率运行。
渐进式熵减少： 客户或用户组织可以在有或没有行业支持的情况下对运行中的系统进行持续的性能和能力改进，因为他们寻求在苛刻的情况下从他们的系统中“获得最佳”。就知识或信息而言，这个过程涉及逐渐减少熵，从一开始的高熵（即无序）状态到结束时的低熵（有序）状态。

一般来说，这两个迭代周期可以通过三种生命周期类型的组合来实现（Adcock 2005）：

顺序：通过阶段之间的迭代来解决出现的详细问题，系统方法的单一应用就足够了。
增量：顺序方法的连续版本对于解决方案概念是必要的。随着时间的推移，每个增量都会为不断增长的解决方案增加功能或有效性。
进化的：一系列用于替代解决方案的顺序方法的应用，旨在提供利益相关者价值并增加对问题的理解。每个演进周期都提供了一个机会来检查解决方案的使用方式，以便将吸取的经验教训纳入下一次迭代。

系统方法的这些方面构成了生命周期模型中生命周期模型的基础。

递归

系统价值循环的利益相关者价值、问题解决和系统创建方面可能都需要使用集中的系统方法。这些可能是软系统，以证明更好地了解情况、产品系统和或服务系统解决方案来满足运营需求，使系统能够支持产品或服务生命周期的某个方面，或者使系统能够被企业系统直接使用。

这些系统中的每一个都可以被识别为感兴趣的系统 (SoI)，并且需要应用系统方法。此应用程序可能是顺序的（一个系统方法的开始取决于另一个系统方法的完成）或并行的（可能会或可能不会在时间上重叠的独立方法），但通常是递归的。

递归是从计算机科学中借来的一种技术。在计算机科学中，当一个函数重复调用自身以在逻辑上简化算法时，就会发生递归。在应用于系统的递归应用程序中，一个感兴趣系统的系统方法嵌套在另一个系统中。示例包括以下情况：

在系统的某一层进行的交易要求对系统元素进行交易；
系统分析需要对系统元素进行分析；
解决方案系统的综合需要一个或多个子系统元素；和
产品系统的验证需要系统元素的验证。

在每种情况下，“外部”系统方法可能会在某种程度上与“内部”系统并行，但取决于其自身进展的关键结果。

与所有递归过程一样，在某个阶段，该方法的应用必须达到可以成功完成的水平。然后这会“汇总”以允许更高级别继续前进并最终成功完成所有嵌套应用程序。

INCOSE 系统工程手册 (INCOSE 2011) 描述了 SE 对系统元素级别的递归应用，每个应用程序代表一个系统项目。 Martin (1997) 描述了 SE 在产品系统层次结构中的递归应用，直到达到组件级别，此时可以使用设计和构建过程的采购来创建解决方案元素。

递归应用的原理以及它与生命周期模型的关系在生命周期模型中进行了描述。本主题是应用于工程系统知识领域 (KA) 的系统方法的一部分。它总结了利益相关者在系统生命周期过程中获取和所有权责任的各个方面，这些责任由国际系统工程委员会手册 (INCOSE 2012) 等来源所涵盖。在感兴趣系统(SoI) 的生命周期中的特定时间点，以下描述的任何活动也可能需要与系统方法中的其他活动同时考虑。

下面描述的活动应在本 KA 开始时的系统方法概述主题的上下文中考虑。本 KA 的最后一个主题是应用系统方法，它考虑了如何将这些活动用作系统方法的一部分的动态方面，以及这如何与系统工程 (SE) 的元素详细关联。

利益相关者的责任

上面讨论的生命周期应用的一般原则在必要时适用于 SE 的每个应用。以下部分阐明了不同类型的利益相关者以及他们在 SEBoK 中讨论的不同系统环境中所扮演的角色。

产品、服务和企业

大多数情况下，术语“产品”和“ 服务”描述了在客户和供应商协议中交换的效果。这可能是一项商业协议，由慈善机构公开资助或由政府机构提供。产品和服务之间的区别在于，产品是为实现结果而获得的人工制品，而服务是直接提供给用户的结果。

术语“客户”和“用户”在工程和管理学科中经常互换使用。 INCOSE 系统工程手册(INCOSE 2012) 对与 系统相关的利益相关者进行了以下具体区分：

收购方是从供应商处获取或采购产品或服务的利益相关者。
供应商是与需方签订协议以提供产品或服务的组织或个人。
操作者是使用知识、技能和程序来执行系统功能以提供产品或服务的个人或组织。
用户或客户是从系统运行中受益的个人或团体。

这些术语定义了利益相关者所扮演的角色；但是，它们可能并不总是位于这些不同的实体中（例如，收单方也可能是用户）。这也适用于服务系统，因为一些实体也可能在角色上重叠。帕内尔等人。 (2011) 提供了一个替代的利益相关者列表，其中包括决策机构、客户、所有者、用户、消费者和相互关联的。

产品系统由硬件、软件和人组成，传统上它们一直是 SE 工作的重点。这些系统被交付给收单方并运行以实现导致系统要求的目标。这些要求源于作为企业一部分向一个或多个用户提供产品和服务的需要。

服务的交付（供应）表明结果的直接交付，这通常与产品的交付有关（例如，维护、培训或清洁服务）。这与服务系统的交付不同（参见下面的讨论）。

在传统的 SE 中，术语“服务”或“服务系统”指的是更广泛的系统上下文，它描述了收购方交付用户价值的需求。在这种情况下，服务系统是一个固定的系统定义，它规定了收单企业将利用产品向用户提供服务的方式。产品系统被=设计为可根据需要进行集成和操作，以使该服务能够根据需要得到维护或改进。在这种观点中，服务系统是静态的，包含专门的产品、人员和资源；也就是说，产品的层次结构旨在为收单方提供向用户或客户提供预定义服务的能力。

最近，术语“服务系统”已被用来描述一种系统，该系统的设计方式允许企业直接向用户提供服务，而无需在企业内部保存所有必要的产品和服务。这需要将“供应商”的定义扩展如下：

产品供应商 是与收购方签订协议以提供产品或相关产品支持服务的组织或个人。
服务系统供应商 是与需方签订协议提供服务系统的组织或个人。
服务提供 者是与用户签订协议以提供服务的组织或个人。

这些服务系统倾向于动态配置，以处理传统静态服务难以解决的问题。这种服务系统视图采用与不属于企业所有但用于使服务尽可能接近给定时间需求的产品系统的“后期绑定”。这是第 4 部分，系统工程应用中的服务系统工程主题中使用的服务系统的定义。

利益相关者需求

利益相关者最重要的职责之一是确定提供产品或服务的系统的需求和要求（INCOSE 2012）。这些需求和要求体现在收购方和供应商之间的协议中。

还有其他利益相关者根据他们的需求制定系统要求，但不一定是收购方或供应商。利益相关者和需求工程师共同负责在需求过程中识别他们的需求。

收购方/供应商协议

Lawson (2010) 对拥有系统的意义、系统产品和服务的贸易以及供应链对系统、其产品和服务的增值和所有权的影响提供了一个视角。 INCOSE (2012) 定义了与采购和供应相关的两个生命周期过程。采购过程包括识别、选择和与产品或服务供应商达成商业协议的活动。

在许多较大的组织中，系统所有权属于个人或在某些情况下属于企业实体（组或团队）的传统。所有权意味着创建、管理和处置利益系统(SoI) 以及有时运营 SoI 的权限和责任。

产品获取/供应

在某些行业中，供应商直接与收购方合作以帮助了解收购方的需求，然后设计一种或多种产品来满足这些需求。在某些情况下，单个供应商将提供完整的有价值的产品系统。在其他情况下，将形成一个供应链，通过系统集成商交付产品系统，以确保它们组合在一起并集成到更广泛的环境中。这是产品系统工程的理论观点，其中上下文是固定的，并且产品旨在适应它。优秀的系统工程师可能会向企业建议更改，作为解决问题的更好方法，然后相应地修改产品系统的要求。但是，在某个时候，将设置一个商定的上下文，并开发一个产品系统以在其中工作。

对于许多商业产品，例如手机，供应商会创建一个有代表性的用户配置文件来生成需求，然后在实现后将产品推销给真实用户。在这些情况下，系统方法的其他要素由需方/用户执行，可能不遵循正式的 SE 流程。在考虑设计系统的最佳方式时，产品供应商必须考虑到这一点，因为购买的产品可能需要提供额外的帮助或支持服务。供应商为在别处购买的某种产品（例如，为不同品牌的汽车提供服务的汽车修理工）为用户提供支持服务的想法开始与服务系统上下文重叠，正如下一个主题中所讨论的。

对于 SoI 完全由企业或其各方拥有的制度化基础设施，包括运营在内的生命周期管理的全部责任通常由系统所有者承担。这些系统属于一个企业或多个企业的系统资产组合，提供系统资源，包括在生命周期管理过程中开发的计划系统。

服务获取/供应

提供服务系统的组织不需要拥有他们提供给用户和客户的单个产品和服务。根据这种观点，所提供的服务系统包括在需要时识别和访问适当产品或服务的方法。服务系统将是为用户组装的产品和服务的捆绑；例如，为用户已经拥有的手机组装软件应用程序和服务协议。反过来，提供服务系统的企业可以为广泛的不同技术或应用领域提供基础设施服务 . 这可能意味着与系统所有权相关的过渡、运营、维护和处置活动可能不会嵌入在收购服务系统企业中，因此需要将其视为单独的系统服务。更多详细信息，请参见 系统工程知识体系 (SEBoK) 指南中的第 4 部分系统工程应用中的产品系统工程、服务系统工程和企业系统工程。

服务系统工程师帮助服务供应商创建和维护服务系统，该服务系统可用于在需要时发现、集成和使用特定版本的通用产品或服务。服务系统的实现需要使用产品系统的能力；但是，这些产品系统是在服务系统之外开发和拥有的。服务系统必须能够在需要时访问产品或服务，并与其有效交互。使用开放式接口标准，例如标准电源、接口连接（例如，通用串行总线 (USB)）或文件格式（例如，便携式文档格式 (PDF)）可以帮助简化此操作。

企业演进

产品系统设计和企业系统设计之间的一个有用区别是“企业设计不像大多数系统的设计那样发生在单个时间点。相反，企业会随着时间的推移而发展，并且不断变化，或者不断被设计”（Giachetti 2010，xiii）。

企业开发人员还可以通过利用技术进步，特别是信息技术(IT) 和相关流程来优化组织或机构的后台流程（内部运营）。在这些情况下，工程系统被认为是企业系统。

企业系统可以提供产品（商品）和/或服务。从企业工程的角度来看，与其产品 SE 并行的企业不仅要着眼于产品的开发和交付，而且还要着眼于产品交付在企业目标内的对齐和优化。同样，在服务 SE 中，主要关注点是向最终客户交付无形的价值（外部关注：前台），其中内部和外部流程必须同步。然而，随着信息和通信技术的飞速发展 (ICT)，在许多情况下，内部流程和外部流程之间的界限非常模糊。当前的 SE 研究正在将产品方法、流程和工具扩展到企业转型和服务创新领域，以利用业务流程方法和技术的进步。

企业 SE 不仅要做企业自身的工程，还可能参与企业实现其目标所必需的服务系统和产品系统的工程。

1354 次浏览	5次

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

< 首页

< 下一页