系统工程方法论是指用于解决复杂系统问题的一套工作步骤、方法、工具和技术。从总体上说，可以把美国国防部看作是通过各类作战司令部将各系统组合在一起以实现各项军事任务目标的大型体系。然而，无论从开发还是采办的角度，目前美国防部主要聚焦于独立系统（或平台单装），大多数系统的演进过程仍然没有清晰规划体系级系统工程。随着美国防部逐渐从以平台为中心转向以能力为中心，未来美国国防部必然会更加重视体系系统工程，并逐渐形成一套体系级系统工程的方法论。
本文为文章《体系的系统工程方法论浅释》的下篇，详细展示并分析了系统工程的16个过程，其中包括8个技术过程与8个技术管理过程。
文章仅供参考，观点不代表本机构立场。
体系的系统工程方法论浅释（下）
作者：学术plus高级评论员 扬帆
体系的系统工程方法论浅释（上）
【体系系统工程】未来美国国防部的发展大方向（附美国防部SoS样例）
系统工程过程
如何支撑体系系统工程？
系统工程可归纳出如下16个过程，其中8个技术过程和8个技术管理过程，每个过程与其主要支撑的体系系统工程核心要素之间的映射关系如表6-1所示。
表6-1 各系统工程过程与其主要支撑的体系系统工程核心要素之间的映射关系
过程1：需求开发过程
需求开发过程从各利益攸关方处获得需求输入，然后将这些需求输入转换为技术需求。
对于承认型SoS，需求在SoS和系统两个级别上进行开发。SoS级系统工程师团队关注于与SoS整体相关的需求，系统级工程师团队则关注于系统需求。SoS级系统工程师团队主要关注将SoS能力需求转变为SoS技术需求，这是SoS设计方案的基础，SoS包含哪些组成系统也是设计方案的一项重要内容。
需求开发过程主要应用于能力目标转化、开发和演进SoS架构、评估需求和方案选项三个SoS SE核心要素中。
在开发一个单独的系统时，需求一般由一群固定的利益攸关方通过正式的过程进行开发。而在SoS中，形势变得更加复杂。SoS的能力目标用广泛抽象的术语表达，SoS级系统工程师与项目经理、利益攸关方一起开发一种对需求的理解，以满足这些能力目标。在SoS背景下，需求开发过程需要理解各组成系统的能力、高级别SoS需求、以及SoS与系统级的互动。由于可能由现有系统满足SoS的这些需求，所以在尽可能的情况下，SoS需求应当按照所需的功能进行描述，而不是执行细节，这样才能评价可满足这些需求的不同替代方法。需求应不断演进，这样早期的实验和军事应用评估能被用于增强作战团队对未来综合后SoS的能力的理解。
由于SoS的演进常常会跨越较长的时间，需求会根据内外因素的变化而改变。所以，需求开发是一个持续进行中的SoS活动，SoS需求也会一直演进发展。需求开发的过程常常伴随SoS架构的设计开发和执行活动，因为架构特别容易引起对SoS组成系统的新需求。
在SoS开发的每次迭代过程中，SoS系统工程师评审需求并寻求解决它们的可用方案，并将需求分解到SoS的各组成系统。在方案执行过程中，开发出每个有变化的组成系统的详细设计方案。由SoS项目经理和系统工程团队根据SoS的特征，决定开发方案、分阶段能力增量计划、重新对照需求的频次等。
对于新的采办项目，按照正式需求过程（详见联合能力集成和开发系统（JCIDS）过程）开发和验证需求。在某些情况下，JCIDS过程也适用于SoS，例如新的指导型SoS项目，这时，一般SoS会得到一个采办项目的资金支持。在其他情况下，会基于从作战行动（如沙漠风暴行动或环太演习等）、战略指南、以及聚焦于利用已有或在研系统（而非新采办项目）支持SoS的其他驱动方等来源获得对SoS需求的反馈，识别出SoS的能力。对于后者，单独的这些采办项目可能成为某SoS的组成系统或对某SoS的组成做出贡献，但是SoS自身不能被当作一个采办项目。
SoS需求开发过程所面临的主要挑战是：在各组成系统有其自身需求和利益攸关方的背景下，将广泛的能力需求转化为SoS技术需求的复杂性。
SoS的利益攸关方包含用户、SoS的倡导者、及其组成系统的利益攸关方。SoS和组成系统的利益攸关方对SoS的需求和解决方案达成共识是SoS系统工程获得成功的关键，但建立利益攸关方团体需要花费时间。在多数情况下，SoS系统工程师只负责SoS级的需求。但组成系统的需求是持续演进或变化的，而这些变化会对SoS产生影响。因此，SoS系统工程师至少应对组成系统的需求变化保持清楚的认知。
过程2：逻辑分析过程
逻辑分析主要应用于理解各系统关系、开发和演进SoS架构等SoS系统工程的核心要素。
在SoS环境中，逻辑分析从一个在项目开始阶段的过程变成了或多或少会长期持续的过程，资源的变化情况，无论在SoS的内部还是外部，都更加显著和持久，所以在SoS系统工程的背景下更应该重视逻辑分析，以适应未预见到的变化。
对于一个全新的系统，系统工程师可以从一张空白的功能分配表开始进行逻辑分析，然而对于承认型SoS，在逻辑分析过程中，必须将SoS的各组成系统考虑到功能分配之中。SoS的逻辑分析聚焦于已有（组成系统的）功能满足SoS需求的情况。在SoS中，系统工程师的逻辑分析聚焦于识别出哪个系统可提供SoS所需的哪些能力，而不是聚焦于对结果进行反复的综合分析直到达成满意的方案。
为了能实现上述逻辑分析，SoS系统工程师必须理解和评估已有系统及其未来发展计划（即至底而上进行分析）。另外，SoS系统工程师必须理解所需的SoS功能以及如何在已建好、在研、正在规划的组成系统中分配这些功能（至顶向下进行分析）。SoS系统工程师需要分解和降低集成各组成系统的难度，这可通过与用户一道的结构化评估和审查来实现，评估和审查将聚焦于现有系统的开放度上，开放度和灵活度低的现有系统可能会限制SoS的设计以及SoS的最终能力。
过程3：设计方案过程
设计方案过程将需求开发和逻辑分析过程的输出转变成各备选设计方案，并选出最终的设计方案。
设计方案过程主要应用于开发和演进SoS架构、关注需求和方案选项等SoS系统工程的核心要素。
在SoS环境中的设计方案过程远比单系统环境中复杂，因为存在多个利益攸关方、集成、测试时间安排、接口开发程度等方面的挑战。SoS设计方案过程发生在两个级别上：SoS级和组成系统级。SoS系统工程师开发SoS架构并使其覆盖各组成系统，从而为SoS的演进提供一个持久框架。SoS设计方案包含各种满足特殊需求的方法，特别是为了实现SoS级的能力而对组成系统作出的改变。变更设计的责任一般由受影响系统的系统工程师承担。这些变更设计过程的结果被反映在SoS的顶层分配基线中，并会在受影响系统的技术基线中更新。
SoS系统工程中重要的一个步骤是知道如何将SoS级需求分解到独立的组成系统中。在一个SoS项目中，一般而言，识别出哪些系统支撑了SoS所需的功能并评估SoS如何运用这些功能是进行功能分配的基础。建立功能映射图（或表）可能是描述功能分配过程的一种好方法，这也会涉及技术以外的其他考虑因素（包含行动、财政、计划安排以及其他项目考虑因素等）并需要与组成系统相结合，在实际执行时，这些过程可能会经过几次迭代才能完成功能分配。
SoS项目的贯彻落实可能需要满足SoS目标所需的SoS特定组件项目先得到贯彻落实。这些组件常常被称为“中间件”或“蓝件”，其作用是在初始设计时互不兼容的老旧系统之间充当中间调停者（即转换接口），从而使这些老旧系统可以集成到SoS中，协同工作。满足这些SoS目标的选项与满足其他需求的已有选项是一样的，一般包含：使用商业现货的解决方案、利用某个组成系统的能力、或开发一个新的组件。如果开发一个新的组件，既可以由SoS直接管理，也可以由其他组织（例如，某个组成系统的项目组）管理。无论上述哪种管理方式，在SoS系统工程过程中，新组件的开发都会被当作一个组成系统对待。
当选定了一个SoS设计方案，SoS设计规范会作为SoS的分配基线，接受配置控制。分配基线捕获设计信息并作为组成系统可追溯的源点。独立的组成系统负责协同分配SoS的设计需求并维护各自的系统级分配基线。虽然对于SoS系统工程团队而言，了解组成系统基线以及执行这些基线的相关计划是非常重要的，但组成系统的基线仍然由各自系统自己掌控。
在SoS设计方案过程中，SoS系统工程师与组成系统的系统工程团队一起，在SoS层级寻求最优的折中方案，评估为满足SoS需求而需要对现有和规划中系统的可能更改。为了取得一个可行的设计方案，可能会需要对需求开发过程和逻辑分析过程进行反复迭代。最佳的总体SoS设计方案可能导致组成系统的更改，而这些更改需要经过（专家组的）裁定和额外的SoS设计迭代。
和独立系统的情况一样，SoS的设计方案、逻辑分析和需求开发等过程是高度依存的活动，考虑到SoS有大量的利益攸关方、分布式的管理结构、演进的作战概念、以及组成系统处于不同的技术成熟度等级，SoS中上述三个过程的依存关系可能更紧密。平衡（SoS和组成系统目标）研究可以通过实验和仿真的方式得到支持，从而探索各种可能的备选方案；研究必须考虑SoS的性能、计划和全寿命周期总成本。
本节和后续小节聚焦于分配基线的开发（SoS的架构和对各组成系统的设计变更），以支持实现在SoS功能基线中反映的SoS目标。在SoS开发的演进过程中，架构是贯穿SoS历次改进升级的关键要素。如果架构设计良好，在历次升级中（架构）能持续保持，对用户要求的SoS功能性能够通过增加或升级组成系统得到满足，而不需要打断（或再次改变）在先前版本中做出的改变。当需求和技术发生变化时，SoS架构也需要进行重新审视和演进。这些变化将反映在SoS的技术基线中。随着我们对SoS理解的增长，跨越时间的架构管理（包含架构增量升级管理）很可能成为更广阔的SoS系统工程过程的一个重要组成部分。
过程4：执行过程
执行过程实际上是产生系统级结构中最底层系统要素的过程。系统要素可以通过制造、购买和重用的方式获得。
执行过程可应用于同步升级（即第七个）SoS系统工程的核心要素。
在SoS中，执行一般采用对组成系统变更的方式，所有变更的累积可以产生新的SoS能力或增强现有的SoS能力。组成系统的系统工程师和开发者主导执行过程，SoS的系统工程师则扮演辅助者、协商者、技术审查者和最终集成者的角色，这会在后续小节中说明。
在组成系统中，执行过程直接在项目经理和该系统的系统工程师的支持下进行。SoS系统工程师会在与SoS的管理者以及组成系统的管理者和系统工程师协商一致的情况下，规划SoS执行活动。组成系统在贯彻SoS执行过程时，会与本系统自己的开发计划相协调，尽量减小对系统级过程及其支持活动的影响。由于每个系统都有自己的活动过程和开发计划，因此一般在多个不同背景的项目之间协商获得一个可行的（执行）方案是很难实现的，这也是SoS面临的主要挑战。SoS执行过程一般采用增量的方法推进项目进度，即允许系统分阶段交付改进成果，而SoS级的改进成果则视不同系统的增量交付情况而定。一种按增量开发的开发方法被称为“公交站方法”，即按照指定的时间间隔（如，每三个月）交付增量改进成果。如果出现问题且一个系统错过了一次交付，系统开发者将把这次交付推迟到下一次交付节点交付（即下一公交站）。通过这种方法，SoS强制为开发过程规定了一种有规律的节奏，从而可以包容这些系统过程的异步属性。组成系统各过程的异步属性使SoS的集成、测试评估（T&E）和设计工作面临挑战，因为总体方案的一些部件可能在完整的端到端能力还没有到位的情况下，就已经交付甚至使用了。
过程5：集成过程
集成过程是将较低层级的系统要素以协作方式组织起来，使其转变为物理架构中较高层级的系统要素的过程。
集成过程可应用于同步升级（即第七个）SoS系统工程的核心要素。
全SoS集成是SoS系统工程师的一项核心任务。在组成系统的系统工程师负责执行和集成该系统内的变化的同时，SoS系统工程师负责整个SoS端到端功能和性能的集成。因为在SoS中各系统的执行过程是异步进行的，所以集成过程也将异步进行。在SoS中，建模仿真的主要使用是为了产生可以替代SoS组件的模拟器，以支持集成和测试。集成设施是SoS集成和测试的通用工具，而网络化的设施正变得越来越常用。这些设施同时为SoS不同零部件研发交付时的集成测试、以及为SoS能力加入以后的系统级回归测试提供场所，以保证它们继续支持它们的系统级应用。
过程6：核查过程
核查（verification）过程证实系统要素满足设计或建设规范。它回答“你是否正确地建设了该系统（或体系）？”的问题。
核查过程可应用于同步升级（即第七个）SoS系统工程的核心要素。
正如在执行过程中所述，对SoS作出的变化一般由其组成系统执行。对系统作出的变化在顶层的SoS分配基线中记录并在系统技术基线中反映细节。核查就是对照这些基线进行检查的工作。核查包含关于设计是否满足设计规范的演示。SoS系统工程师应了解组成系统开发和执行的详细测试计划，并监督测试结果，因为该系统会应用于SoS。
在系统级上，验证活动可能包含演示、检查、类比分析、测试等。SoS系统工程师负责SoS核查，监督核查过程以确保更改满足SoS的能力需求并评估与组成系统开发过程相关的SoS风险。目标是尽量利用组成系统的系统工程过程；因此，系统级工程师一般负责核查在本系统内作出的更改是否反映了被（SoS）要求的更改。正常情况下，这些更改会作为系统级开发的一部分以及作为系统级系统工程的一部分被执行。
过程7：验证过程
验证过程回答“你是否建设了正确的系统？”这个问题。
验证过程可应用于评估能力目标的性能（即第三个）、同步升级（即第七个）等SoS系统工程的核心要素。
验证SoS能力主要是评估在SoS中作出的改变是否取得了预期的端到端效果。这包含演示设计满足了用户提出的能力目标（派生的需求）。SoS系统工程应确保对SoS至关重要的改变都被包含在组成系统的试验鉴定计划之中，并会影响试验鉴定的结果。开展这种试验鉴定活动应尽可能作为SoS开发过程的一部分，并按照SoS端到端的要求进行测试。目标是确保在组成系统中的改变在SoS层面能产生预期的效果。验证过程可能在集成测试环境中进行，或者作为演习或现场测试的一部分，例如导弹防御系统进行的实弹发射和拦截测试。SoS面临的挑战是组成系统的数量可能很庞大，因此完整（SoS）的现场测试将是无法负担的高昂成本或者无法安排合适的时间进行测试。
因此，尽可能地将SoS的端到端测试与组成系统的试验鉴定结合起来，将是非常有利的，可以有效利用时间和资源。有时，不是所有组成系统在验证过程中都可以得到，因此，SoS的系统工程师可能需要使用激励器/模拟器替代无法参加验证的组成系统。这些激励器/模拟器能按照组成系统自身的要求进行开发。这些激励器/模拟器的替代方案应该在需要使用前就做好规划。SoS系统工程师评估风险，以决定如何采用最好的方式进行SoS验证，从而让现场测试聚焦于SoS存在最高风险的领域，即用现场测试的结果化解SoS中的最大风险点。
除了对组成系统的更改进行试验鉴定之外，一般还需要在作战环境中收集SoS的性能数据。这些数据可用于验证SoS的改变是否使升级后的SoS达到了预期的性能，而且通过这些数据可进一步识别出影响SoS性能的各个因素。这些因素是重要的，它们为将来把SoS应用于更广阔的环境增加了置信度，这可能影响或指明未来投资的方向。
过程8：移交过程
移交是将最终系统交付用户的过程。
移交过程可应用于同步升级（即第七个）SoS系统工程的核心要素。
SoS升级改进的内容仍然通过其组成系统按照各自既定过程进行移交。因为SoS的升级是通过组成系统的执行过程来实现的，正是这些系统的所有者承担着部署和维护这些包含了SoS升级内容的系统的责任。需要在方案评审时，就考虑改进系统的全寿命周期支持计划，这样就可以把全寿命周期支持等选项的总成本考虑在方案之内，所以需要作为决策分析的一部分，受到重视（决策分析过程见下一节）。
有时，支持移交过程所需做的事远比移交独立系统的各种零部件要复杂，可能还需要考虑需求（例如增加总体带宽），这是SoS能力所要求的，同时也需要SoS系统工程师考虑。必须在早期就识别出类似的需求，在选择方案时加以考虑，通过SoS系统工程师与相关组织机构协调。再次重申，这些都是决策分析过程需要考虑的重要因素。
过程9：决策分析过程
当必须从各备选方案中做出选择时，决策分析活动提供了评价和选择备选方案的基础。
决策分析过程包含挑选决策准则、用于指导分析的方法等。例如，在系统设计期间，必须对各备选方案进行分析，从而挑选出一个折中的、可支持（SoS目标）的、健壮的、节约成本的系统设计方案。
一旦高层级（即SoS级）需求集被确定，决策分析过程可应用于评估能力目标的性能（即第三个）、开发和演进SoS架构（即第四个）、监视和评估变化（即第五个）、关注需求和方案选项（即第六个）、同步升级（即第七个）等SoS系统工程的核心要素。
在SoS环境中，SoS系统工程师重视与各备选方案相关的问题，一般通过集成一些现有系统和/或新系统的方式满足SoS能力需求，从而拟定备选方案。SoS系统工程师决定如何调整、拓展、扩大当前系统集合以满足用户能力需求的活动，将贯穿整个SoS的演进过程。决定因素包含移交和维护的方案和成本。从这种意义上说，系统工程师通过各种定量和定性的数据分析方法支持做出决策。
在包含多种老旧系统的更大型SoS中，理解如何把这些系统耦合在一起并且耦合后将如何影响这些系统和SoS的行为是非常重要的，特别是意料之外新出现的行为和间接效果。从建模仿真、主题专家的协作、专题实验中得到的可行性证据，都可用于解决上述问题以及SoS的其他问题。
由于SoS决策可能暗含一些对组成系统的（更改）要求，SoS决策分析过程需要明确考虑受影响的系统、利益攸关方等的观点。然而，对组成系统的系统工程师而言，时间和资源往往是稀缺的，这会限制组成系统的系统工程团队介入SoS决策分析过程的程度。因此，SoS系统工程师可能需要预判将来会影响组成系统的问题并把对这些问题的评估报告作为SoS决策分析的组成部分。
最终，SoS系统工程师面临着严峻的挑战，其利用改进（现有和/或新）系统集以开发满足（SoS）新需求的方案的同时，面临着这些组成系统都有独立的所有者和资金来源的复杂情况。为了获得这种精妙的平衡并支持上层决策（这些常常超出了系统工程的范围和权限），SoS的系统工程师必须从多角度理解各个组成系统及其关系，包含技术和组织关系。这些决策包含选项分析、在综合考虑系统当前特征和未来发展计划的前提下选取折中的SoS设计方案/架构、在系统目标确定的条件下通过评估以决定哪种需求应该在哪个时间段内得到满足；分析内外变化如何对SoS施加影响。有几种活动，包含软件工程协会（Software Engineering Institute）的SoS领航计划（SoS Navigator initiative），正用于检查这些需求和解决方案。
过程10：技术规划过程
技术规划活动确保在整个系统生命周期中都适当应用了系统工程过程。技术规划，相比项目规划而言，更关注在开发系统过程中所需的技术范畴。一种用于该过程的官方授权工具是系统工程规划（SEP）。
每个技术过程（即6.1至6.8中介绍的8个过程）都需要技术规划。对执行、集成、核查、验证和移交过程的技术规划及其伴随系统（或配套系统）能揭示限制条件和接口，这些限制条件和接口将导致派生的技术需求。
技术规划对成功实现系统的重要性已得到广泛认同，同理，技术规划对成功实现SoS也是至关重要的。虽然在规定中并没有明确提及SoS，但项目经理仍应遵循国防部2004年发布的系统工程政策中的一些关键原则：开发一个系统工程规划（SEP）、任命一个主管系统工程师、实施事件驱动的技术评审（技术评审由多个独立的主题专家联合负责）。一个系统工程规划（SEP）预备指南可为技术规划提供源泉。
技术规划是综合、集成、部署SoS的关键活动。直接应用技术规划过程的两个SoS系统工程核心要素为：开发和演进SoS架构、关注需求和方案选项。
从某些角度上说，对SoS作技术规划比对单个系统作技术规划要更难，因为SoS的系统工程团队需要在各组成系统的独立技术规划基本确定的条件下，规划SoS的演进路线。系统级工程活动的高度异步性和并行性，使得在SoS级有一个好的SE过程规划、协同和管理显得更为重要。各组成系统的系统工程师已经准备好在本系统中执行技术规划，因此SoS的技术规划需要考虑甚至可能需要扩展这些组成系统的规划。SoS的技术规划需要拥有充足的资源，因为SoS需要和单个系统项目持续竞争以吸引这些系统工程师的注意力。为了适当化减SoS的风险，在进行SoS技术规划时，SoS的系统工程团队必须积极参与到系统级的系统工程之中。在大多数SoS项目中，形成了各式各样的系统工程委员会或组织，以关注跨SoS的技术规划问题。
过程11：技术评估过程
在SoS中，技术评估过程需要关注在SoS级和系统级中的技术进展。技术评估主要应用于评估能力目标的性能、同步SoS的升级等两个SoS系统工程核心要素。
在SoS中，技术评估主要评估两个方面的进展。第一个是在满足SoS能力方面的进展。第二个是在执行技术变更/升级SoS过程中的进展，包含对原有组成系统的技术变更和在SoS中增加新的系统。
在第一方面，因为SoS系统工程团队主要关注于适应多个系统和长期技术插入所需的用户能力，开发出以用户为导向的测量标准是很重要的，这些测量标准可应用于多种场合，以评估在满足这些目标上所取得的进展并收集数据用于评估进展。虽然在大多数情况下，当人们承认一个SoS的时候，该SoS的一些组成系统就已经存在了，但测量标准必须与特定系统保持独立关系。因为特定的组成系统可能会随着时间发生变化。
在第二方面，在开发和执行SoS升级规划的过程中，SoS系统工程师需要评估在定义、规划、执行、集成和测试技术变更过程中的进展，这些技术变更会对SoS升级产生影响。SoS系统工程师把技术评估过程作为同步SoS升级要素的一部分。技术评估包含对各组成系统中技术变更的评估，这些技术变更会在组成系统项目管理方和系统工程师的支持下进行规划和实施。在定义升级时，技术成熟度在SoS环境中是至关重要的。成熟度指示器包含一系列测量标准，如版本稳定性。SoS系统工程师需要洞察系统级工作，但理想情况下系统级工作作为组成系统系统工程过程的一部分被规划、执行和评估。无论是SoS系统工程团队的成员参加系统评审，还是组成系统的系统工程师向SoS系统工程师提供升级更新，技术评估是基于可获得的资源以及技术变更对SoS的重要性进行的。好的系统工程实践需要SoS系统工程师遵循一条受纪律约束的SoS技术评审过程，受纪律约束指按照SEP文件中定义的技术评审过程进行SoS技术评审。SoS系统工程师对可能影响SoS功能、性能或进度（这基本等同于关键的集成主计划（IMS）的同步点对SoS系统工程的重要性）的组成系统执行进展特别感兴趣，因为这些问题可能会成为SoS的风险源。评估包含各组成系统内部的功能性以及SoS中与执行SoS进程相关的各系统间接口，包含数据通信和数据利用接口。
SoS技术评估包含评估在集成、测试和鉴定综合SoS过程中的技术进展。SoS技术规划将识别需要组织技术评审的关键决策点，包含确定评审的原则。技术评审应关注集成、测试和鉴定计划，包含这些活动应何时、何地发生以及可能伴随的风险。SoS系统工程师对技术评审负责，组成系统的系统工程师则应积极参与。SoS应尽量利用组成系统的集成、测试和鉴定事件或活动，这可以减少SoS和组成系统的冗余并降低SoS的成本。总体上，将SoS评估活动融入系统级事件对SoS系统工程师而言是一种不错的选择。
在该领域的挑战是，会在各组成系统异步开发的环境下进行SoS升级改进的技术规划和执行。这意味着，如果a、b、c三个系统在SoS升级改进中都需要进行技术变更，这三个系统的技术变更将根据各自系统的开发计划进行实施和部署。如果系统a在系统b和c集成、测试和鉴定之前完成开发和部署，就会引发问题。一种解决方法是，评估系统a的技术变更是否可不依赖系统b和c的技术变更到位，并管理各系统异步开发可能引发的风险。这可能影响SoS设计，SoS设计需要在尚未完全落实功能进程的条件下容纳新功能。这也会增加后续系统化减风险的压力。处理这类情形时，建模和仿真是很有用的手段，可以模拟系统b和c的变更，作为系统b和c的模拟器，用在系统a的集成过程中。
过程12：需求管理过程
需求管理可应用于能力目标转化、开发和演进SoS架构、关注需求和方案选项、同步升级等4个SoS系统工程的核心要素。
如6.1节需求开发过程所述，SoS系统工程师是根据SoS能力目标开发需求的活动的积极参与者，SoS系统工程师不仅考虑SoS级的需求，也需要考虑各组成系统用户的需求。需求管理开始于已开发的SoS需求并在整个过程中持续跟踪SoS需求（的变化）。组成系统的需求主要由各自系统的系统工程师使用本系统的需求管理过程单独管理。但至少，SoS系统工程师需要了解这些系统的需求管理过程。另外，应确保为满足SoS需求而增加的系统新需求被反映到对应系统的需求管理过程中并能与SoS需求管理过程相连接。
当各组成系统中存在冗余需求时，SoS系统工程师应该能知道。在SoS环境下，各个系统间的冗余一般是可接受的、期望的，甚至考虑到系统脱离SoS运行的情况（冗余）是必须的。在某些情况下，跨组成系统的复制性（或同质化）需求或功能可能会导致SoS冲突。例如，当SoS中的多个系统每个都有不同的方法计算航迹相关时，综合后的结果只能提供敌方目标的粗略估计（精度不高）。管理和解决冲突是非常重要的，但是若想取消有争议的、冗余的需求或功能可能会耗费巨大或者具有破坏性。
从经典意义上说，需求管理对SoS的成功至关重要；SoS需求应按照输出结果的测量术语和任务的效率测量指标进行定义，从而将SoS的性能测量指标分配到各组成系统之中。然而，存在一些SoS需求管理所特有的挑战。在威胁持续演进和作战概念持续演进的环境下，需求管理活动的一个重要方面是识别和管理新的需求，厘清已部署SoS的配置和所期望SoS能力之间的关系及其追溯性。需求管理功能必须以灵活和敏捷的方式支持新的需求。甚至，虽然需求管理可以聚焦于SoS和各组成系统的特殊功能需求，它也必须能关注和管理在SoS环境下的通信和数据交换需求。
过程13：风险管理过程
风险管理的目的是确保实现项目生命周期中每个阶段的成本、进度和性能等目标，和所有利益攸关方沟通以发现和确定风险的范围并管控项目的不确定性。
风险管理可应用于所有SoS系统工程的核心要素（详见第五章）【体系系统工程】未来美国国防部的发展大方向（附美国防部SoS样例）。
SoS系统工程团队发现和管理的风险是指那些与SoS自身及其任务和目标相关的风险。SoS风险常常与决策分析（详见6.9）和设计方案（详见6.3）活动期间开发出的可行性证据的力度紧密联系（即可行性证据充分、逻辑严密，则风险小；反之亦然）。这些风险可能与SoS的规模、业务质量要求、技术成熟度、跨各组成系统进行SoS风险管理活动的协调能力、一些组成系统及时提供所需SoS功能的能力、以及其他组成系统可能影响整体SoS成功或另外的组成系统（运行）的风险等因素相关。
SoS风险管理开始于识别出SoS的目标以及识别出威胁这些目标实现的风险。在组成系统的小风险可能成为SoS主要风险的同时，也有组成系统的重大风险对SoS功能影响可以忽略不计的可能。另外，甚至可能影响一系列SoS目标的风险，但却不构成对组成系统的风险。例如，意料之外的紧急行为、基础设施、集成风险、成本风险等。
SoS的主要风险可能与SoS系统工程师对开发关键组成系统的有限影响力相关，外加与这些系统和平台相关的技术风险。组成系统的独立演进过程可能导致不可预期地偏离SoS目标（生命周期成本、性能、进度）。每个核心系统工程管理过程能识别风险并支持风险评估。为了应对风险，如同在6.11节技术评估过程中所述，SoS的项目经理和系统工程师必须理解每个组成系统的规划的演进路线。在某些情形下，化减SoS风险的战略可以包含组成系统的预替代方案，特别是某些系统已接近服役年限并将要退役、或是某些系统需要参加延长服役期限计划（SLEP）、重新制造等。然而，常常并不存在一个替换高风险（或有问题）组成系统的选项，与这些系统相关的风险需要通过其他方式进行化减。
风险分析包含与各组成系统全生命周期相关的技术风险（这也包含成本和进度等项目安排上的风险）。虽然量化一个SoS的不确定性是很困难的，但量化SoS中老旧系统的风险却相对容易。然而仍需要特别小心SoS中老旧系统的非合作性，特别是那些技术文件不全的老旧系统。虽然分系统风险不一定会严重影响父系统的能力，但这些分系统风险可能会对SoS造成严重影响，并需要不同的方法计算和降低跨多个系统而积累的风险。不仅需要运用在系统级已经使用的风险原则，而且更需要开发SoS级的风险（或影响）原则。这些原则会随着时间推移而不断更新以反映SoS级的风险容限（risk tolerance）。
其他风险管理措施包含：应建立综合风险管理委员会并鼓励组成系统的成员参与其中。然而，让组成系统参与SoS级风险委员会可能比较困难，因为他们的主要精力不在SoS上。该委员会应总览整个SoS以及SoS的目标，将其作为识别和评估SoS风险的基础。SoS组织中的高级官员应承担委员会的领导职务，从而确保有足够的品阶和领导力。
由于对SoS的初始描述可能不足以支持详细的需求开发，聚焦于军事应用和价值的早期试验可能是重要的化减风险的活动。
过程14： 配置管理过程
配置管理（CM）是对各种有益的商业实践的（再）应用或利用，以建立和维持产品属性的持续性，产品属性中包含其需求和产品配置信息。
配置管理主要应用于能力目标转化、理解各系统关系、开发和演进SoS架构、监视和评估变化、关注需求和方案选项等5个SoS系统工程的核心要素。
CM能影响所有的SoS系统工程核心要素，但上述5个要素是SoS系统工程主动管理SoS配置的关键要素。在其他SoS系统工程核心要素中，配置被作为参考并且是由系统而非SoS进行配置管理。在评估SoS性能（即其他SoS系统工程核心要素之一）时，SoS系统工程师在各种场合检查SoS的性能，但是并不控制SoS基线的任何方面。在同步SoS升级活动（即其他SoS系统工程核心要素之二）中，SoS系统工程团队监督技术规划的执行，这些技术规划是与SoS升级、以及在SoS环境中集成/测试/鉴定各组成系统相关的技术规划。然而，SoS系统工程团队并不控制各组成系统自身的基线。
除此之外，在承认型SoS中，在SoS级和系统级都有（配置）管理机构。对于SoS，在建立和管理SoS各技术基线（包含功能、分配和产品基线）时，需要用到配置管理。在SoS级管理这些基线是很重要的，因此系统工程可以帮助结构化和控制SoS的演进过程。这些基线也能用于其组成系统，当这些组成系统考虑（根据这些基线）对其自身配置进行改变时。
在一个SoS中，功能基线通过如下（核心）要素进行开发和管理。在能力目标转化（要素）中，会开发和更新高级别需求，然后在关注需求和方案选项（要素）进一步分析这些高级别需求并（将需求）分配到一个功能基线中。在开发和演进SoS架构（要素）中，会识别出SoS的新增需求，并将这些新增需求指定到方便进一步分析的级别上，并通过关注需求和方案选项（要素）将这些新增需求分配到一个功能基线中。分配基线也是在关注需求和方案选项（要素）阶段建立起来，因为这时会开发（需求的）解决方案并且会建立需求和未来实现该需求的组成系统的映射关系。会识别出对各组成系统所需作出的额外变更，并将其包含在基线中以提升SoS的性能。最后，随着执行和部署这些系统变更，在理解各系统关系（要素）阶段会识别和监视SoS的产品基线。
SoS配置管理需要了解那些可支持SoS目标的系统以及系统间的关系。为了SoS能成功实现，SoS系统工程师需要了解各组成系统以及对SoS而言重要的组成系统特征、（为满足端到端SoS需求）这些组成系统当前一起工作的方式。而各组成系统的系统工程师负责这些系统的详细配置管理（detailed CM），对SoS有影响的特征会在SoS配置管理中产生镜像（在SoS配置管理中保存的是镜像，在相应的组成系统配置管理中保存的是原物体），应具备在SoS配置管理和各组成系统配置管理的重要要素之间跟踪需求的能力。
过程15：数据管理过程
数据管理应用于所有SoS系统工程的核心要素。
SoS数据包含系统发展规划、系统管理和资金概况等信息以及与SoS进展相关的其他信息。在SoS环境下，对数据管理工作的关键挑战是以方便分析跨组成系统问题的形式获得访问各组成系统数据的许可。这个过程会变得复杂，因为不同的系统产生和保留不同的数据，在各系统间不一定存在通用数据。系统可能不愿意在本系统之外共享数据，一些所需的数据被认为是归开发者所有的专利数据、或是属于不同涉密等级的数据或属于敏感数据（后者需要经隔离处理）。这些挑战成为SoS整体决策分析所面临的问题。协议备忘录（MOA）是一种解决上述SoS数据问题的方法。在MOA中，系统工程师可以定义SoS数据管理的方法，包含数据访问、数据使用和共享、创建一个SoS的通用数据共享库，所有上述措施是为了使各组成系统的利益攸关方对数据访问控制（机制）放心。
在整个SoS系统工程的过程中，需要在SoS活动的环境下捕获和理解关键数据。当对SoS而言很关键的特殊数据源可能演变或消失，就需要为SoS活动找到其他的数据源代替演变或消失的数据源。这对SoS来说尤其重要，因为在SoS演进过程中有更多的分散参与者，能获得SoS活动的相关数据将成为确保SoS过程对系统级和SoS级参与者均透明的关键。
数据管理过程支持所有SoS系统工程的核心要素。数据收集过程包含执行每个核心要素有关的信息以及执行结果，因为一个核心要素的执行结果又为其他核心要素提供信息。
过程16：接口管理过程
接口管理过程保证接口定义、组成系统的各要素之间的兼容性、以及与其他系统之间的互联互通性。
接口管理可应用于理解各系统关系、开发和演进SoS架构、监视和评估变化、关注需求和方案选项、同步SoS升级等五个SoS系统工程的核心要素。
在大多数情况下，SoS提供一种端到端能力，包含通过系统间信息共享而实现的行动协同。因此，接口管理是SoS的关键活动。信息共享和由此引发的接口管理是一个SoS实现端到端运行的（重要）组成要素。更进一步，由于美国国防部（DoD）转向网络中心思想，经典的接口控制准则逐渐被各种网络标准所取代。在DoD系统中使用的所有已知标准都可以在国防信息技术标准登记库（DISR）中找到。
数据和元数据的协调一致逐渐成为接口管理的中心问题，其结果就是接口管理聚焦于数据披露和语义分析。在许多情形下，SoS系统工程必须花费更多的精力在数据、数据交互和数据语义上，而不是在接口问题（如接插件的型号和芯线定义）。大多数时候，SoS并不能控制组成系统的接口；相反，接口一般通过协议和协商进行管理。考虑到一个既定的独立系统可能不只是一个SoS的组成系统是很重要的，因此其接口以及接口的变更将影响不只一个SoS。该领域的资源包含DoD元数据登记库（DMR）以及DoD网络中心全局服务（NCES）的服务登记库。针对特殊SoS数据需求的方法可以在包含已登记DoD服务的DMR库中找到。
（全文完）
扬帆，学术plus高级评论员，专注于战略情报等相关研究。
联系客服
