应用系统方法-Lib教程

工程系统通过帮助利益相关者在一个或多个问题情况下实现价值，从而为利益相关者提供利益。最终，一个系统只有在为其利益相关者带来成功结果的情况下才是成功的（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 不仅要做企业自身的工程，还可能参与企业实现其目标所必需的服务系统和产品系统的工程。

337 次浏览	1次

欢迎参加课程:
	MBSE（基于模型的系统工程）
	系统思维与系统工程
	系统工程方法与实践

< 首页

< 下一页