第1章概述
本章首先简要介绍体系的概念、分类与主要特征，对比分析了系统工程和体系工程。针对军事领域体系的特点提出一种体系工程过程模型，重点强调顶层设计和评估环节。介绍评估的概念和内涵，梳理总结了评估的范式及发展，并介绍体系评估的概念和主要内容、要求。
1.1 体系与体系工程
1.1.1 体系的定义、特征与分类
IEEEStandard42010将系统定义为一个被组织起来实现特定行为以完成一项任务的组件的组合。而体系则通常被认为是由系统构成的复杂系统。构成体系的系统称为成分系统或体系成员系统，本书统一称为体系成员。体系成员组合在一起构成了更大的系统，执行单个体系成员独自完成不了的任务，这种现象就是涌现行为。Jamshid将体系定义为有限个体系成员的集成，这些体系成员各自独立可运行，在一定时间内链接在一起完成特定的高层目标。
Maier认为体系有5个主要特征。
（1）业务独立性。每一个体系成员独立运行来完成其自身的使命。
（2）管理独立性。每个体系成员被独立管理，自行决定按被组合时不曾预期的方式进行演进。
（3）地理分布性。体系成员在地理上是分离的，成员间仅交换信息，不交换物质和能量。
（4）演进性开发。体系作为一个整体随时间演化，以响应体系成员和业务环境的改变。
（5）涌现行为。新的行为涌现自体系成员的交互。因为体系成员是独立演化的，因此涌现行为可能是短暂存在的。
按照体系成员的从属等级，体系被分为四类。
（1）受控体系（directed SoS）。体系实施集中管理，体系成员是为满足体系特定目标而采购或开发的。体系成员具备独立运行的能力，但是其实际运行服从体系集中管理。美陆军曾计划开发的未来作战系统（future combat system，FCS）可认为是一个受控体系。
（2）普认体系
（acknowledged SoS）。体系实施集中管理，但是体系成员在松散从属关系下运行（保留各自独立的所有者关系）。弹道导弹防御系统就是一个普认体系。
（3）协作体系
（collaborative SoS）。体系中没有集中管理，但是体系成员就完成统一使命任务自愿达成一致，在体系统一政策规定下运行。
（4）虚拟体系
（virtual SoS）。体系没有集中管理或一致统一的使命，体系成员在各自（可能共享的）政策约定下运行。美军全球信息栅格（global information grid，GIG）就是一个虚拟体系。
在军事领域，有时也按以下三类对体系进行区分。
（1）任务体系
（mission SoS）。一起工作并提供更广泛能力的系统集合，如作战体系。
（2）平台体系
（platform SoS）。装备了达成平台目标所需的独立系统（如传感器、武器、通信）的军事平台，如舰船、飞行器、卫星、地面车辆等。
（3）网络化信息系统（IT-based SoS）。支持平台内、跨平台或跨系统方式运行的信息系统，以保障作战、满足任务或平台的目标。
体系成员系统可分解的组成部分称为体系要素，如对作战体系，体系要素包括指挥控制、侦察情报、火力打击、信息对抗及机动、防护和保障等要素；对网络信息体系，体系要素包括条令条例、组织机构、训练教育、基础设施、装备系统、技术、标准规范等。体系要素按功能聚合组成的成员系统称为体系的功能系统，如对作战体系而言其功能系统包括侦察预警系统、指挥控制系统、打击系统、通信系统等。功能系统再分类组织在一起，称为体系的功能子体系。不同类型的体系要素面向任务执行需要组织在一起，形成体系的任务系统，任务系统再进一步分类组织形成任务子体系。体系要素、功能系统、功能子体系、任务系统、任务子体系之间的关系如图1.1所示。
综上，体系从本质上是能够执行一定使命任务的作战要素的集合，在逻辑上按“要素-功能系统-功能子体系”进行规划、设计、构建和管理，运用时按“要素-任务系统-任务子体系”动态组织使用来完成体系任务。体系成员系统既包括功能系统，也包括任务系统。
1.1.2 体系工程概述
不管采用哪种方式进行分类，不同类型的体系有各自的独特性，这些独特性给体系的设计带来了不同的需求，需要遵循不同的步骤、方法和技术来构建和治理体系。因此，抽取体系设计和构建所采用的不同过程的共性，可以形成通用的规范化过程方法。
图1.1 体系组成相关概念示意
对一般系统，这些方法就是系统工程方法。系统工程是一门多学科方法，通过一个迭代过程把用户需求变换为系统定义、系统架构及设计，最终形成一个有效的业务系统。系统工程适用于全生命周期，从概念开发直到最终的报废。由于系统与体系在利益相关者、治理、业务环节、采办、测试、评估、边界、接口、性能、行为等方面存在诸多不同，因此传统系统工程不能满足体系设计与构建的要求，具体体现如下。
（1）不能处理复杂系统问题中高层次的含糊和不确定性。
（2）没有完全忽略上下文对系统问题阐述、分析、求解的影响，但把上下文放到了背景中。
（3）不准备在部署后再交付解决方案，这些解决方案包含迭代设计，或在实现上是不完整的。针对诸如此类的问题，研究人员提出体系工程的概念来取代系统工程，以处理体系这类对象的建设问题。
关于体系工程的研究由来已久。Keating[6]认为体系工程就是对巨系统的设计、部署、运行和转型，使其如一个集成的复杂系统一样发挥作用并生成期望的效果。DeLaurentis等认为体系工程是针对体系问题开发设计方案的流程集，应该对已有和新系统能力进行规划、分析、组织、集成，以形成超出单个体系成员能力的体系能力。总的来说，体系工程承认系统层和体系层的不同，在不同层次需要采用不同的系统工程方法，应该实施均衡的技术管理，并使用基于开放系统和松耦合的架构。
欧洲自2010年开始资助了一系列体系理论与方法相关的研究，主要项目情况如下。
（1） 2010～2014年的COMPASS（comprehensive modelling for advanced SoS）[8]、DANSE（designing for adaptability and evolution in SoSE）及AMADEOS（architecture for multi-criticality agile dependable evolutionary open SoS）。
（2） 2011～2013年的ROAD2SoS（development of strategic research and engineering roadmaps in SoS）和 T-Area-SoS（transatlantic research and education agenda in SoS）。
（3） 2013年开始资助的DYMASOS（dynamic management of coupled SoS）、 LOCAL4GLOBAL（SoS that act locally for optimizing globally）和CPSoS（cyber-physical SoS）。
在美国，Sandia国家实验室和卡内基梅隆大学软件工程研究所等机构也开展了一系列体系相关研究，特别是对超大规模体系进行了研究。目前体系研究的挑战主要集中在体系表征与描述、体系理论基础、涌现、体系多层建模、体系评估、体系架构的定义与演化、体系原型化、体系折中等方面。
系统工程过程是一系列的活动与决策，系列活动与决策的目的是解决系统问题。体系工程的研究对象为体系，区别于系统工程所针对的简单系统对象，两者在过程原理上存在本质差异。多年来体系工程过程研究提出了一些模型，但在体现体系的特殊性、解决体系构建与演化等问题方面还存在一些不足。
1.1.3几种典型的体系工程过程模型
文献将体系工程从内容分为体系需求工程、体系集成与构建工程、体系演化工程，参考MIL-STD499B的系统工程过程模型提出了一种体系工程过程模型（图1.2），包含需求分析循环、设计分析循环、设计验证循环、体系环境与边界分析四个子过程，这四个子过程通过体系分析与控制活动进行平衡，通过平衡找到体系设计的合适方案。
图1.2体系工程过程模型
作为系统的体系成员在建设时采用系统工程过程模型，除了MIL-STD 499B的模型，图1.3所示的“Vee”模型也是一种常用模型。“Vee”模型包含概念开发、需求工程、系统架构、系统设计与开发、系统集成、测试评估、试验维护等阶段。
图1.3 系统工程过程的Vee模型
因此体系工程过程与系统工程过程间天然就有紧密的联系，一项复杂的体系工程过程中包含众多的系统工程过程，体系工程与系统工程存在包含与被包含的关系。因此多数研究采用扩展系统工程过程“Vee”模型的方法来建立系统工程过程和体系工程过程的综合模型，如图1.4、图1.5所示。
1.1.4 不足及改进思路
INCOSE提出了关于体系的七项挑战：体系成员独立运行；体系成员有不同的生命周期；复杂性（随着系统数量的增加，系统交互的复杂性非线性增长；接口标准冲突或缺失使得定义跨体系成员接口的数据交换极其困难）；初始体系需求含糊不清；管理可以使工程黯然失色；模糊边界带来混乱；体系工程永不终结。目前的体系工程过程模型在解决上述挑战、适应体系特点方面还存在不足，主要体现如下。
（1）能力需求分解时的隐性弱化问题。根据体系需求分析和设计确定体系成员（系统）时，通常采用“能力-功能”映射的系统工程思路，见图1.4中体系设计阶段体系工程层面的主要活动和图1.5中左上侧的活动。这样的处理实际上隐含了下述假设：具备一定功能（记为Funcs）的系统能够提供一定的能力（记为Cap），而且能够提供能力的系统必然具备功能。按照能力的定义，可能存在不同功能的系统，但是都能够提供能力。按原先的思路进行设计和处理，实际上人为地缩小
