系统工程现代化：基于任务工程、系统工程、数字工程的体系作战能力的敏捷测试评估

作者：与子同袍爱西红柿

53 次浏览

4 次

2024-11-20

编辑推荐:

本文以“知识”和“知识点”为切入点，介绍武器系统测试评估的更具体的内容。希望对你的学习有帮助。
本文来自于微信公众号软件定义战争，由火龙果软件Linda编辑、推荐。

在上一回中，我们已经了解了 GAO 提出的“基于知识的产品开发”方法论，以及“知识点”和“知识消除风险”这几个概念。

本文继续以“知识”和“知识点”为切入点，介绍武器系统测试评估的更具体的内容。

本文正文里面没有提到，但是读者应该了解的重要背景知识：

在国防部诸军种之中，海军在数字工程、测试评估、系统工程现代化等领域，贡献还是挺大的。

ME-SE-TE 三位一体，即任务工程、系统工程、测试评估（工程）三者要高度综合。

测试评估是采办的良心，也将是能力的良心。

“知识点”是理解 ME-SE-TE 三位一体的关键锁钥。同时也要基于知识点这一核心概念，来分析能力、决策、测试评估三大领域。

数字工程 DE，是任务工程 ME、系统工程 SE、测试评估（工程）T&E 的数字赋能者。

竞争压力传导链：大国竞争（GCP）-> 印太战区压力 -> 作战能力需求的综合 -> 系统工程、采办的综合 -> 测试评估的综合。

本文的关键洞察（insights）：

要理解“基于能力的测试评估”，最重要的概念：能力（Capability）、知识点（KP）、综合（Integrated）。

决策和测试评估，要以作战能力为本（Capability-based）。

测试评估，正在不断地综合。测试评估的综合，分战略规划和战术执行两个层面（这一点在下一篇文章详细说明）。

测试评估，从能力生命周期来看，既是大国对抗竞争压力传导链的末端感知（Terminal Sensor，提供能力决策所需的 Sensory data），也是能力持续迭代的闭环反馈的关键一环。

测试评估，在未来体系作战下，需要建立联邦的评估框架。正如 JADC2 中，需要有联邦的 C2、联邦的网络、联网的任务架构、联邦的数据网格、联网的语义本体一样。

本文结构：

回顾 GAO 提出的知识点理论

盘点测试评估社区近20年发展的历程

梳理基于能力的测试评估中的重要概念

评估框架综合化的过程

总结

附录A：GAO 的知识点理论

附录B：测试评估大事表

附录C：能力决策空间中的知识点

附录D：技术能力评估和作战能力评估的指标体系

附录E：综合测试流程

1. GAO 提出的知识点理论

在介绍基于知识点的测试评估之前，我们先来回顾下上一篇文章 GAO（美国政府问责局）提出的“基于知识的产品开发”和“知识点”理论。这个理论，是理解本文的背景知识。

1.1 基于知识的产品开发最佳实践

GAO 每年都要对 MDAP 重大国防采办项目进行年度审计。GAO 每年的审计报告，都会指出国防部的许多重大项目，存在不必要的预算超支和进度延误。

在上世纪90年代末，为了减少国防部采办项目的预算超支和进度延误，GAO 研究了领先商业公司产品开发的最佳实践。

他们发现，利用成熟的技术、拥有完整的产品设计和控制制造过程，是成功开发新产品的关键。GAO 就把这些原则合并为一个单一的采办策略，即“基于知识的产品开发”。GAO 建议国防部采办项目要采取这种采办策略，用于降低采办项目的风险、减少预算超支和项目进度延误。

简单地说，这一采办策略是围绕三个关键知识点（KP）设计的。在这三个知识点，通过知识点的实现情况，帮助项目经理做出是否可以往前推进项目进入下一阶段的最佳决策。所以我们可以把这三个知识点，也看做是决策点。

第一个知识点（KP1）：发生在产品发展开始之前。在这个阶段，项目经理要判断资源、资金和技术能力是否可以满足客户提出的需求。

第二个知识点（KP2）：会在发展阶段的中途出现。项目经理应该在这个时候，对产品的设计成熟度是否可以进入生产阶段做出判断。

第三个知识点（KP3）：需要项目经理在产品生产之前，确定生产制造工艺是否可以在预算，时间和性能限制内制造出产品。

GAO 建议，如果在这三个知识点，项目没有获取足够的知识，则不能让项目进入下一阶段。

这个理论的概括总结，放在本文附录A。更详细的内容，大家可以去看上一篇文章。

1.2 “基于知识的产品开发”在国防部的落地情况

那么国防部听了 GAO 的这个建议之后，“基于知识的产品开发”这一方法论，在国防部的落地情况到底如何呢？

“基于知识的产品开发”方法，确实得到了国防部采办社区最高层的支持，并影响了最近（2020年）国防部重新设计的5000系列采办政策。

但是有趣的是，尽管有高级别采办官员的支持，并影响了采办政策，但一线的采办项目的项目经理们，并没有轻易采用 GAO 建议的方法。许多项目经理，并没有将这一方法完全整合到他们的项目管理过程中——他们不愿意严格按照这三个知识点来评审和推进项目。

于是有人专门整理了几十个国防部 MDAP 重大国防采办项目的数据，根据三个知识点（KP）点达成情况，结合项目的成本、进度方面的五个指标的历史数据，用统计学的假设检验方法，验证遵循 GAO 提出的三个知识点的 MDAP 项目是不是真的改善了成本和进度。

经过对统计显著性的结果进行分析，这项研究发现无法从统计显著性上证实坚持实现所有三个知识点（KP）是提高所有采办指标的有效方法（因为缺少第三个知识点即 KP3 的相关数据）。不过，坚持实现前两个知识点（KP），确实可以改善采办项目的部分指标。

这个研究结果，是个好消息，说明 GAO 的这一方法论确实能够降低采办成本和缩短项目进度。但是它并没有能够解决采办项目经理不愿意采纳这一方法论的问题。“基于知识的产品开发”这一有效的方法论，在融入国防采办文化和采办决策流程时，由于军品和民品产品开发的差异性以及国防部采办文化的惯性，遇到了一些障碍和阻力。

所以，GAO 给国防部采办社区开的药方，还是挺对症下药的。但是由于病人依从性不高，在国防部的采办临床实践中，这一药方的疗效打了些折扣，没有商业公司中效果那么显著。

不过也有好消息——这一方法论给包括测试评估社区在内的国防部采办社区种下了“基于知识” 的思想种子，取得了原本没有设想到的疗效。

本文将要介绍的“基于知识点的测试评估”、“基于知识点的决策”，就是一个显著的例子。“知识点”这个概念，歪打正着，无心插柳柳成荫，在测试评估领域获得了成功应用。

这个歪打正着的原因，一方面是因为 GAO 提出的“知识点（KP）”和“决策”（能力决策、采办决策）之间存在力的相互作用，另一方面是因为“知识”天然与“测试”、“评估”之间也存在着力的相互作用。这样一来，GAO 提出的“知识点（KP）”理论，竟然和测试评估（T&E）产生了意想不到的良好的化学反应。

不过知识点（KP）这个概念在进入测试评估领域后，其意义其实已经和 GAO 的定义有所不同，已经发生了意义上的滑移。本文后面会详细介绍。

古希腊的普罗泰戈拉（Protagoras），曾提出过一个著名的哲学命题，即人是万物的尺度（Of all things the measure is man）。这个命题我们将其简称为 MM（Measure is Man）。

对于商业产品来说，消费者是万物的尺度。而对于国防部的武器系统来说，作战人员是万物的尺度。但是两者的不同之处在于，在商业战场上，商业产品消费者不满意，产品会扑街；而武器系统作战人员不满意，作战人员会扑街。

所以国防部与商业公司相比，有更为强烈的动机，在作战任务下评估出产品的实际的能力。只有获得任务环境下武器系统能力的知识，决策者才能做出正确的决策。

那么要做出正确决策，决策者所需的知识来自哪里？

要回答这个问题，我们需要回到普罗泰戈拉的MM 这个命题。这个命题，等同于“知识是感觉（Knowledge is sensation）”的主张。例如人是体温的尺度——房间里开了电风扇，有人觉得吹的太冷，但也有人觉得吹的挺凉快。换句话说，MM 意味着每个人都是对自己感觉的衡量。普罗泰戈拉，实际上是以感觉数据（Sensory data）为基础的经验主义理论支持者。

所以普罗泰戈拉的 MM 命题，认为知识来自人的感觉数据。而对作战人员需要的能力进行决策，其所需的知识，来自于不同事件生成的数据（从能力生命周期来说，包括传统的测试评估中的发展测试（DT）和作战测试（OT）生成的测试数据，也包括兵棋推演、演习、实验、保障阶段的事件生成的数据）。

总之，GAO 提出的“知识点”，兜兜转转，和测试评估文化挺有缘分，产生了良好的化学反应。

1.3 本文用到的术语说明

测试评估领域有很多术语，为方便读者阅读，列在这里：

GAO：政府问责局

KP：知识点

ME：任务工程

SE：系统工程

T&E：测试评估

M&S：建模仿真

VV&A：校核、验证和确认

Measurement：测量或度量

IT：综合测试，integrated testing

IT：集成测试，integration test

CT：承包商测试

DT：发展测试

OT：作战测试

DT&E：发展测试评估

OT&E：作战测试评估

LFT&E：实弹测试评估？

TEMP：测试评估主计划

TES：测试评估策略

EF：评估框架

DEF：发展评估框架

OEF：作战评估框架

DSK：决策支持表

IDSK：综合决策支持表，跨整个采办周期

DSEF：决策支持评估框架，跨整个能力生命周期

DSQ：决策支持问题，DEF 发展评估框架中的技术方面的重要问题

COI：重要作战问题，OEF 作战评估框架中的作战方面的重要问题

DEO：发展评估目标

CTP：关键技术参数

MOS：适宜性度量

MOE：有效性度量

DDT&E：发展测试评估局

DOT&E：作战试验与鉴定局

2. 盘点测试评估过去20年的发展历程

2.1 测试评估的发展历程

为了帮助大家看清测试评估的发展趋势，我们把测试评估近20年的大事，按照时间线列出来：

2007-2008年：提出综合测试，综合测试评估概念

2010年：综合测试评估连续统，是采办成功的关键

2018年：发布数字工程战略

2022年：DOT&E 发布测试评估转型愿景

2023年：通过数字工程赋能测试评估即连续统

2024年：测试评估从采办生命周期扩展到整个能力生命周期

具体的每件大事的内容，请读者移步本文附录B。

2.2 对这一发展趋势的简单点评

从上述发展历程来看，测试评估的大趋势就是测试评估的综合化、基于能力进行测试评估。

我们要进一步看清楚测试评估的发展趋势，要把它放在更大的背景下看。

天下大势，分久必合。我们在许多领域已经看到了各种综合（Integrated，也可以叫集成或整合，视不同学科习惯）。

军用的例子有：综合模块化航电、综合隐身、综合火控、综合补给、综合保障、综合战术网络、综合电力推进、综合桅杆等。

民用的例子有：集成电路（Integrated Circuit，IC）、集成产品开发（IPD）、集成财经服务（IFS）、集成供应链（ISC）、C# 语言集成查询（LINQ）、整合营销传播（IMC）、配电/变电综合自动化、综合能源系统、综合虫害治理、综合城市管理、综合护理、综合治疗、工厂生产综合调度等。

还有一种我们最关心的综合，就是大国竞争（GPC）背景下能力的综合（Integrated Capability，简称IC）。一个具体的例子，就是近期空军的基于能力的组织结构的变革。

下图为空军的综合能力司令部（ICC）- 空军装备司令部的综合发展办公室（IDO）-空军装备司令部（AFMC）三个组织之间的渐变过渡关系。

其中，ICC 在需求层面需要进行能力需求的综合（基于任务综合管理、任务工程、体系工程等），IDO 作为二传手居中衔接 ICC 和 AFMC，进行前期任务工程、前期系统工程和前期系统采办的发展的综合（对应系统工程现代化中前期的任务工程-系统工程-采办的综合），最后无缝过渡转交给 AFMC 进行能力系统的全生命周期的管理。

在能力的综合过程中，需要进行测试评估的综合，用于在整个能力生命周期中，持续对能力进行评估生成用于支持决策所需的知识。

测试评估需要综合的有：

评估决策的综合（战略规划的综合）：对测试评估计划的综合。DT&E 和 OT&E 的综合，从独立的发展评估框架 DEF 和作战评估框架 OEF，综合为 IDSK。再从跨整个采办生命周期的 IDSK，综合为跨整个能力生命周期的 DSEF 决策支持评估框架。具体见本文第四部分。

测试的综合（战术执行的综合）：CT/DT/OT 三种测试的综合（见本文附录E）。

ME-SE-T&E 的综合（业务流程的综合）：任务工程、系统工程、测试评估，三者的综合一体化。ME/SE 驱动 T&E，T&E 提供知识反馈给 ME/SE 进行下一轮的迭代。详见本文4.3部分。

数字方法的综合（工具和模型的综合）：即通过数字工程的数字基础设施，建立数字的任务模型、系统模型、测试评估模型，再通过数字主线连接这些数字模型，为决策者提供所需的权威的数据信息和知识。这部分以后再说。

3. 基于能力的测试评估

了解了 GAO 的知识点理论和测试评估的发展历程，我们对测试评估有了宏观的全局的理解。

接下来，我们就可以进入细节，介绍什么是能力，以及对应的能力生命周期和采办生命周期，如何通过测试、评估获取能力达成目标方面的知识。

3.1 能力和目标

对每次战争必须从一开始就把它看作一个整体，统帅在向前迈出第一步时就必须已经有了目标，所有的行动都应指向它。——战争论

2002年的时候，时任国防部长拉姆斯菲尔德命令 JROC（联合需求监管委员会）主席 Pace 上将改革国防部的需求流程。

改革之前，作战需要关注的是系统。作战人员的作战需要，用系统（System）或部队元素（Force Element）来表述。比如空战司令部（ACC）会说，“我们需要一架高性能的战斗机。” 这种表述方式下，系统要完成的军事目标（military objectives）这一系统得以成立的理由却被忽视了。

改革之后，作战需要改用“能力”来表述。能力被定义为“在军事行动中实现目标的能力（the ability to achieve an objective in a military operation）”。改为能力之后，空战司令部会这样表达作战需要，“我们需要有能够在xxx任务中实现空中优势这个目标的能力。”

用能力而不是系统来表达作战需要，可以让作战人员更清晰准确地表达出系统要完成的军事目标，从而获得他们真正需要的东西。

根据能力的这一定义，决策者要评估能力（Capability），就是评估在军事行动中达成目标（Objective）的情况。请读者记住这一点，我们后面在分析测试评估时需要用到。

3.2 采办生命周期、采办决策空间

能力交付的重要一环就是系统的采办。采办生命周期大家比较熟悉，就不解释了。

采办生命周期的不同阶段，需要在决策点做出重大决策。这些决策组成了采办决策空间。采办决策空间中，最重要的决策问题就是验证和确认（V&V）。即回答两个灵魂问题：根据军方作战人员提出的作战需求，是否正确地开发了系统，是否开发了正确的系统。

系统工程的传统的 V 模型，其右侧部分，就是回答这两个灵魂问题。在右侧，通过测试评估，实现对系统的技术能力和作战能力的评估。

对技术能力和作战能力的评估，需要通过测试评估的发展评估框架（DEF）和作战评估框架（OEF）来实现。本文后面第四部分会介绍评估框架的演化历史。

发展评估和作战评估所需的数据，来自不同层级的测试生成的测试数据。组件级别的测试由承包商完成，即承包商测试（CT），加上前期介入的发展测试（DT）。子系统的功能测试和系统测试由发展测试（DT）负责。作战测试（OT）负责进行根据能力在任务下的作战能力的测试。

系统工程 V 模型的右侧，属于测试评估社区传统的领地。我们会在本文后面看到，测试评估社区要走出自己的地盘，进入系统工程 V 模型的左上角的地带。

3.3 能力生命周期、能力决策空间：立体化的疏而不漏的评估决策网

了解所有细节对统帅是有害的，因为人的才智是通过传授给他知识和思想培养起来的。只有大的知识和思想能使一位统帅成为杰出的统帅，而细枝末节的知识和思想，如果统帅没有把它们当作无关紧要的东西而加以拒绝，就只会使统帅成为狭隘的人。——战争论

采办并不是全部，它只是能力交付其中的一环。

能力始于 JROC 审批后给出的作战需要，到能力对应的科学技术，然后立项采办，再到形成IOC/FOC作战能力，最后运行保障和处置，这是能力经历的完整的生命周期。

这个完整的生命周期，我们称之为能力发展生命周期，或者能力交付生命周期，或者直接简称为能力生命周期。能力生命周期，由于分为多个阶段，并且能力连续过渡，所以也可以看做是能力连续统（capability continuum）。

能力发展生命周期，可以分为若干个阶段（见下图）：

能力发展规划（CDP）

科学&技术（S&T）

原型样机/实验（P&E）

采办（适应性采办框架的六种不同采办路径）

生产/列装（P&F）

运行保障（O&S）

在能力发展生命周期不同阶段的转换点，都需要决策者做出正确的决策。

这些不同阶段的重大决策，就组成了能力发展生命周期的能力决策空间（CDS）。能力决策空间由不同阶段的关键决策点组成。在这些关键决策点，由于需要知识来提供决策支持，所以为了强调知识的重要性，同时为了遵循受到 GAO “基于知识的产品开发”方法论影响的国防采办政策，也将其称之为知识点（KP）。

下图为能力生命周期、能力决策空间、采办生命周期、采办决策空间之间的关系。

从图中可以看出，采办生命周期和采办决策空间，分别包含于能力生命周期和能力决策空间。采办决策空间是能力决策空间的一个子空间。

能力决策空间，由能力生命周期不同阶段的决策点（或知识点）和知识点下关联的问题组成。这些问题，都聚焦于任务需要下的能力（包括技术和作战能力两大类）评估，以帮助决策者在整个能力生命周期中做出正确决策：

评估能力（或能力大类，如性能、生存性、互操作性、面对威胁的韧性等）的现状；

评估能力与任务需要之间的差距；

评估填补能力差距的解决方案；

评估提升能力的科技是否满足任务需要；

评估采办的能力是否满足任务需要；

评估已装备的能力是否跟得上威胁变化。

下面的示意图，粗略表达了能力生命周期不同阶段、决策空间、决策点（知识点）、知识点下关联的问题之间的关系。

从图中可以看出，每个能力生命周期的阶段，都对应一个能力决策子空间。每个能力决策子空间，包含该阶段的多个决策点（知识点）。每个决策点（知识点）又包含多个能力相关的问题。

能力决策空间中，不同阶段的知识点的更详细的介绍，见本文附录C。

3.4 能力发展生命周期、能力、目标、测试、评估等概念之间的关系

从战争的最高任务来看，它不是由无数细小事件构成的，而是由各个需要分别处理的、决定性的大事件构成的。战争不是长满禾秆的一片田地，收割时无须考虑每根禾秆的形状，割得好坏只取决于镰刀的好坏，而是一片大树，用斧头砍伐时，必须考虑每棵树的特性和方向。——战争论

能力决策空间中的决策点（知识点），需要对作战概念、系统或体系的能力进行评估，以此获取用于支持决策的知识。为了获取这些支持决策的知识，对于每个决策点（知识点），决策者需要明确提出做出明智决策所依赖的信息。

这里面，其实有三组大的概念组（见下图，分为三种颜色）：

能力概念组

决策概念组

测试评估概念组

为了让大家梳理清楚相关的概念体系，按照能力-决策-测试评估三组概念，画了下面这个概念关系图。

理解了上图的能力、目标、任务、能力生命周期、知识点、决策问题之间的逻辑关系，我们就搞明白了能力、目标、评估、测试之间的关系了。

我们可以更进一步，把上图和上一篇文章中的那张知识点和风险和承诺的概念图（下图），通过“知识点”串起来。理解了这两张图上的概念之间的关系，我们就可以弄明白什么是“基于能力的测试评估”、“基于测试评估的风险管理”、“基于评估的决策”了。当然我们要注意，左边和右边的知识点（KP）的含义其实是稍微有些不同的了。

4. 测试评估的综合化的发展历程

厘清概念之间的关系之后，我们可以进入本文主题，研究在能力决策空间中，如何基于知识，来支持决策者进行决策。

本部分主要介绍战略规划层面即决策和评估的综合。战术层面的综合，即测试的综合，在本文附录E，有一个简单的介绍。

我们按照评估框架的发展的时间顺序，分三小节介绍评估框架的演变历史。

发展评估框架（DEF）和作战评估框架（OEF）

综合决策支持表（IDSK）

决策支持评估框架（DSEF）

这些评估框架，与能力生命周期、采办生命周期之间的关系如下图所示：

当然，在对体系的能力进行评估时，需要通过决策框架的联邦（Federated）的方式进行测试评估。

4.1 采办生命周期中，对技术能力和作战能力独立的评估：DEF 和 OEF

在军事活动本身这一领域内，根据指挥官的职位，需要不同的知识。如果指挥官职位较低，那么他需要涉及面较窄和比较具体的知识；如果指挥官职位较高，那么他需要涉及面较广和概括性更强的知识。——战争论

传统的测试评估（T&E），从属于采办生命周期，包括 DT&E（发展测试评估）和 OT&E（作战测试评估），所处的位置在系统工程 V 模型的右侧（见下图红圈）。这个红圈，就是传统的测试评估社区的活动领地。其中，红圈下面部分，是 DT&E 的地盘，红圈上面部分，是 OT&E 的地盘。

对能力（Capability）进行评估，就是在军事行动（military operation）下对达成目标（Objective）的能力（ability）进行评估，为决策者提供相关的和及时的支持决策用的信息。

老师要评估学生学习能力，就要出考卷来测试学生，也就是俗称的考试。所以对能力进行评估的问题，就变成了如何做好测试计划，根据测试得到的测试数据进行分析，评估军事目标达成的情况。

制定测试计划，应该聚焦于只收集对能力评估和决策支持必要的数据信息和知识。而细枝末节的数据信息和知识，都要舍弃掉。具体地说，测试计划应该包括三个部分：

定义要做出的决策：技术能力的决策、作战能力的决策；

定义需要评估的能力目标：需要评估的技术能力目标、作战能力目标；评估出来的实际结果作为支持决策的知识；

定义数据源事件：事件类型包括测试、建模仿真，这些事件用于生成评估能力目标所需的数据。

能力分为两大类，一类是技术能力，一类是作战能力。这两大类能力需要采用不同的评估框架进行评估。

技术能力：发展评估框架（DEF）用于评估技术能力，即能力实现技术目标的情况；

作战能力：作战评估框架（OEF）用于评估作战能力，即能力实现作战目标的情况。

这两个评估框架，是由两个不同的国防部的测试评估部门开发的。发展测试评估（DT&E）部门的发展评估框架（DEF），作战测试评估（OT&E）部门的作战评估框架（OEF）。

DEF 和 OEF，从收集决策所需的信息都角度看，其实上是一张表格，在其中填写知识点（决策点）、知识点对应的能力目标、能力目标对应的测量指标、以及为了获取实际测量指标值需要进行的测试/建模仿真事件。

下图为 DEF 要填写的表格的信息。OEF 与之类似，只不过知识点对应的决策问题叫 COI 而不是 DSQ，评估目标变成了作战目标而不是 DEO，测量指标也变了。具体细节见本文附录D。

下图中的例子，列举了某太空态势感知任务的决策点（知识点）的部分支持决策问题。

要回答这些技术和作战上的问题，要通过 DEF 和 OEF 这两个评估框架（EF）。这两个框架，都是深思熟虑的流程框架（process framework）。这两个流程框架，自顶向下“定义”下一层所需的信息和资源需求，再自底向上地执行生成数据、分析数据进行评估生成知识，生成的知识用于回答决策点（知识点）关联的问题。

这两个评估框架都分为四层，上面两层是战略规划层，下面两层是战术执行层。

这里框架（framework）的含义，是说决策到报告的六个步骤的流程，是不同采办项目均可复用的思维性的框架结构。下图为 DEF 框架的四层结构的描述。

下图是 DEF 框架结构和 DEF 表格之间的对应关系。

注意，上图其实有点问题——对于采办生命周期的 DEF 框架来说，用于生成评估所需的数据的数据源只有测试和建模仿真，只有到了后面介绍的面向整个能力生命周期的 DSEF 评估框架的时候，其第三层的数据源才会有兵棋推演、样机实验、演习之类的其他来源。

4.2 采办生命周期中，对技术能力和作战能力的综合测试评估

知识的压缩

军事活动一般所需要的，以及一支只是有了装备的部队上战场前所必须要有的大量的知识和技能，在它们能在战争中达到其活动的最终目的以前，就被压缩成少数大的结论，就像陆地上的小河在流入大海以前先汇成大河一样。只有那些直接流入战争这个大海的活动，才是指挥这些活动的人所需要了解的。——战争论

国防部为了便于进行综合决策和综合测试规划，又通过名为 IDSK（综合决策支持关键）的表格，将 DEF 和 OEF 这两个评估框架与采办生命周期的“采办决策空间”合并（conbine）起来，形成一个跨采办生命周期的单一的决策支持评价框架。其中，发展测试评估 DT&E 生成技术能力的知识，作战测试评估 OT&E 生成作战能力的知识。

填写 IDSK 表格的过程是一个深思熟虑的过程。在这个过程中，发展测试评估和作战测试评估的两个测试计划的三部分关键计划信息，就被填充到 IDSK 表里面。

IDSK 就成为了跨整个采办生命周期的综合测试评估的重要舞台（stage），而决策者会在决策点（知识点）时刻，准时出现在 VIP 包厢里。

从采办能力空间来看，IDSK 描述了在采办立项项目的采办生命周期不同阶段，需要做出的重要的技术、项目和作战决策，做出这些决策所需评估的能力目标，以及能力评估所需的数据源（源自承包商测试CT、发展测试DT、作战测试OT、综合测试IT、建模仿真等事件生成的数据）。

除了上述的 DEF 和 OEF 合并的视角，理解 IDSK 的另一个视角是从能力的不同利益相关方关心的决策问题入手。

IDSK 把能力的不同利益相关方，各自最关心的决策问题，综合到了一张表里面。不同利益相关方，其关心的决策问题不同。比如，军方关心系统在任务背景下的作战效能，技术发展社区则关心关键子系统的技术成熟度，承包商只关心自己的那部分系统/子系统/组件的技术指标，项目经理则关心决策点和技术评审点上是否已经获取足够的知识降低了风险。

不同利益相关方的决策问题，其实不可能完全不同，也有重复的地方。所以就需要把不同利益相关方关心的决策问题，以及这些问题对应的性能目标、测量指标、测试事件，都整理合并到一个表格里。这个表格，就是国防部 DODI 5000.89 测试评估这一指令性政策中的 IDSK 表。IDSK 表，可用于识别所有利益相关方的重要决策所需的问题、数据需求。

这个表，其实一开始也不是综合的，也是独立的，发展测试 DT 有自己的 DSK 表，作战测试 OT 有自己的 DSK 表。后来为了便于决策者综合决策，整合为一张综合的决策支持表。

IDSK 表，告诉综合测试 IT 要回答哪些问题，这些问题对应的能力目标，能力目标对应的量化的测量指标，以及为了获取这些量化指标需要进行的测试事件。这样，决策者就可以根据决策点对应的 DSQ 和 COI 问题得到的知识作为决策支持，来回答 IDSK 中不同利益相关方的决策问题了。

下表就是海军舰艇的一些决策点（知识点）和关联决策支持问题（包括技术类的 DSQ 和作战类的 COI）的对应关系的具体例子。一旦表格右边的 DSQ 和 COI 问题知道了答案，就可以用于支持左边的决策了。

4.3 能力生命周期中，对能力的综合测试评估

另一个问题是，理论对手段应分析到什么程度。显然只需考察它们在使用时的特性就够了。各种火器的射程和效果对战术来说是极为重要的，至于其构造，尽管它决定效果，对战术来说却是无关紧要的，因为战法关心的不是用炭粉、硫黄和硝石制成火药，用铜和锡造出火炮，而是现成的武器及其效果。——战争论

只生成采办阶段的决策问题的知识，用于支持采办决策者和项目经理进行决策，是不够的。在采办阶段之前的阶段，能力发展规划、根据未来能力需要发展的新科技、原型样机和实验等，还有其他决策者也需要获取关于能力的知识，用于做出决策。

因此，测试评估活动扩展到采办之前的阶段，也是顺理成章的了。扩展之后的测试评估，就涵盖了包括采办生命周期在内的整个能力生命周期。

相应地，也需要对采办生命周期中的 IDSK 综合评估框架，进行再一次的扩展（2024年），形成更为综合的跨整个能力生命周期的评估框架。这个评估框架的名字叫做 DSEF（决策支持评估框架）。这个名字起的也不是很好，主打一个随意。不过我们知道这里面的扩展继承的关系就可以了。

下图说明了在这次新的扩展过程中，评估框架（EF）的四层中的每一层发生的变化。

从上图，我们可以看出，从面向采办生命周期和采办决策空间的 IDSK，扩展到面向能力生命周期和能力决策空间的 DSEF 之后，评估框架（EF）的每一层的外延，都需要相应的扩展：

决策：IDSK 为立项的采办项目（POR）提供决策支持；DSEF 为整个能力生命周期提供决策支持。

评估：IDSK 对采办阶段收集的数据进行技术和作战评估；DSEF 对从整个测试评估连续统收集的数据进行技术和作战能力的评估。

生成数据的数据源：IDSK 只包括采办生命周期的基于测试和建模仿真两种数据源；DSEF 除了测试和建模仿真，还需要兵棋推演、演习、实验、实物或虚拟的技术演示、LVC等数据源。

资源：DSEF 比 IDSK 需要的资源更多。

这个新的DSEF 评估框架，需要具备敏捷性和扩展性，才能在各种实际场景中落地使用。

数据源接入的扩展性：能够在跨整个能力生命周期，收集和分析评估不同数据源生成的数据。这一点上面已经提到了。

可根据活动裁剪：在采办之前的阶段，可根据能力前期的S&T、样机、实验活动进行裁剪。

不同采办路径的适应性：在采办阶段，对于适应性采办框架的六个不同采办路径的采办项目，DSEF 也要具有适应性和可扩展性。

纳入仿真VV&A信息：包含对建模仿真进行校核、验证与确认（VV&A）所需的信息。

识别测试基础设施：在项目前期识别测试所需的资产，尤其是用于能力组合评估所需的 LVC 资产。

这一扩展的最终结果，就是基于能力生命周期连续统，通过 DSEF 决策支持评估框架来综合测试评估连续统、建模仿真连续统、数字孪生/数字主线、数据连续统，实现综合能力（IC）的综合测试评估（ITE）的战略规划和战术执行（见下图）。

而在此过程中，测试评估连续统，与任务工程（ME）、系统工程（SE），在数字工程环境（DEE）下，通过数字主线（DTh）将三者的可执行的任务模型、系统模型、测试评估模型建立可协作的数字连接，从而实现深度数字整合，三者之间并行执行、迭代开发。

利用基于模型的数字工程环境，任务工程、系统工程和测试评估三者的活动，就可以全部在基于模型的数字环境中进行（见下图）。在此过程中，敏捷的、可伸缩的评决策支持估框架，可以在能力生命周期全程持续、敏捷、迭代地提供技术和作战能力的重要反馈。尤其是能力生命周期早期的能力评估反馈，价值巨大，可以减少或避免后期发现能力不足或者能力需求缺陷等影响能力交付的重大隐患。

采用这种方式之后，国防部的能力交付模式，就可以从传统的“设计-构建-测试-修复-测试”流程，过渡到“模型-测试-验证-设计-测试”流程（下图）。

最终，就可以在能力生命周期不同阶段，为各阶段的决策者提供决策支持所需的各种知识（下图）：

ME（任务工程）：研究分析能力差距，提出和论证解决方案和能力需求，使作战概念逐步成熟。

S&T（科学与技术）：对科技发展路线和科技投资进行评估，对技术成熟度进行评估。

P&E（原型与实验）：评估原型样机的能力，判断是否可以从 S&T 转成 PoR 立项项目。

PoR（立项项目）：对采办系统的技术能力和作战能力进行评估，用于采办决策。

CPM（能力组合管理）：对系统所从属的体系作战能力进行评估，用于体系组合管理决策。

O&S（运行保障）：在运行和保障阶段，结合敌方威胁和技术变化，持续分析能力，并进行能力升级的决策。

注意，这里面没有分析 LVC 连续统、AI自主能力、未来基于模型的靶场、JADC2 体系测试评估这几个之间的互动。这块也非常重要，限于篇幅就不展开了。

5. 总结

本文本来想采用复调式，知识和综合两条线来写。不过笔力不够，好像不太成功。

本文前面介绍的内容，加上在本文没有来得及展开的内容，高度提炼总结一下，就是：

“一心”：以作战能力交付为初心；

“两融”：实行"多工程学科融合"、"全能力周期融合"的新发展模式；

“三力”：具备"决策力、综合力、数字力"的能力为本的测试评估；

“五化”：坚持“综合化决策、数字化转型、集约化测试、框架化评估、生态化共赢”的发展路径和原则。

附录A：GAO 的基于知识的产品开发理论

GAO 在上一世纪90年代末发现，领先的商业公司的产品开发实践，通常会把产品开发分为三个阶段，即技术开发、产品开发和产品生产。

在这三个阶段，会有三个 GAO 概括为“知识点（Knowledge Point）”的时刻。这三个时刻，分别叫知识点1，知识点2，知识点3。在这三个时刻，必须积累足够的知识来降低技术、设计和制造的风险，公司决策层才会继续往前推进产品开发到下一个阶段。

GAO 认为，如果在正确的时间以正确的顺序——技术、设计和制造——获得足够的知识以消除重大风险，是商业公司产品开发的最佳实践。这种做法降低了产品开发风险，缩短了周期时间和成本，并使生产计划更加顺利。

在这三个知识点上，项目经理要确保已经获取足够的产品知识来降低风险：

知识点1：积累足够的技术知识，技术和用户的需求匹配；技术要达到足够的成熟度才能进入下一个产品开发阶段；

知识点2：积累足够的设计知识，设计和用户的需求匹配；完成大部分设计，设计在进入下一阶段后不能再大改；

知识点3：积累足够的制造知识，能够在规定的成本、进度和质量目标的要求下生产出所需的产品；在进入实际生产阶段之前制造工艺就要稳定下来。

GAO 指出，如果在正确的时间以正确的顺序——技术、设计和制造——获得足够的知识以消除重大风险，是商业公司产品开发的最佳实践。这种做法降低了产品开发风险，缩短了周期时间和成本，并使生产计划更加顺利。

GAO 建议国防部在开发武器系统时，也采取这种产品开发最佳实践。

GAO 用知识点来评估技术、设计和生产的稳定性和成熟度，并据此定性和定量分析相应的风险，用于支持决策者做出采取战略行动的重大决策，即商业承诺（比如认为某导弹或某舰艇可以通过当前里程碑，进入下一阶段）。

国防部的采办项目的商业承诺之所以是重大决策，是因为一旦做出承诺，就会采取战略行动，即牵涉到大规模的、不可取消的资源投入。这种资源一旦投入就不可轻易撤出，因为沉没成本极高（想想国防部许多失败和虽然成功但是成本进度受到极大影响的重大采办项目）。

国防部采纳了 GAO 提出的“基于知识的产品开发”最佳实践的建议，许多采办项目都用了。所以我们能够看到类似下面的新闻：2023年11月的时候，美国导弹防御局（MDA）经过评估认为洛马的下一代拦截弹（NGI）已经达到了知识点1（KP1）。

我们知道，知识点1（KP1）意味着技术成熟，所以上述新闻的意思就是，洛马的这个下一代的远程弹道导弹拦截弹，在2023年11月份的时候，已经在技术上成熟了，关键技术的技术成熟度等级（TRL）和相应的制造成熟度等级（MRL），都达到了KP1时刻的要求的相应的等级。洛马的 NGI 软件工厂的技术也已经和 NGI 需求匹配了。

根据上述新闻，结合下图中的 PRD、CDR 技术评审点、KP1 和 KP2、以及TRL、MRL等级之间的关系，我们就可以得知洛马的 NGI 这一产品的当前开发进展了。

以上就是 GAO 提出的基于知识的产品开发的最佳实践的介绍。

附录B：测试评估大事时间线

近二十年来，测试评估的发展的重要时间线：

2007-2008年：综合测试，综合测试评估

2010年：综合测试评估连续统，是采办成功的关键

2018年：国防部发布数字工程战略

2022年：DOT&E 测试评估转型愿景

2023年：通过数字工程赋能测试评估连续统

2024年：扩展测试评估到整个能力生命周期

2007-2008年：提出综合测试概念

2007年，USD（AT&L）和DOT&E在5000.02中提出了综合测试评估（T&E）的概念，并于2008年的联合备忘录将综合测试（Integrated Testing，IT）定义为：

综合测试是测试阶段和测试事件的协作式规划和协作式执行，提供共享数据，支持所有利益相关者，特别是发展测试评估和作战测试评估的独立分析、评估和报告。

值得注意的是，这个定义侧重于协作式的测试规划和独立的评估。其结果是，由于担心评估报告缺乏第三方的独立性客观性，这个综合测试概念，并没有强调要对整个采办生命周期的数据进行信息整合。测试虽然综合了，但是测试生成的数据却没有综合。

这个定义导致 CT/DT/OT 的测试事件生成的数据，还是分散的、并且相当一部分数据是重复的。从而带来两个不利后果，一个是测试资源的浪费，另一个更严重的后果是从测试数据到采办决策的流程缓慢。

2010年：综合测试评估连续统，是采办成功的关键

到了2010年，DDT&E 发现了上述综合测试定义存在的问题。就扩展了2008年的综合测试的定义，提出要利用从 DT&E（发展测试评估）到 OT&E （作战测试评估）的综合信息流。提出要跨整个采办生命周期，综合发展测试和评估（DT&E）和作战测试和评估（OT&E），促进从里程碑A之前到里程碑C之后的系统需求、开发和性能方面的知识的持续学习和共享。

这个测试评估连续统指出，要实现四个综合：

测试评估与技术发展和采办的综合：综合测试与评估必须是开发和采办的一个组成部分。测试评估的利益相关方要包括作战人员、国会、项目经理、承包商、项目管理团队和整个开发团队。

资源的综合：在承包商和政府的T&E的规划和实施中，测试评估工作量、测试评估设施、测试评估人员或其他资源，都不能重复投入。为了提高效率，集成承包商和政府的T&E还必须包括测试数据的公开共享。

价值流的综合：DT&E到OT&E的价值流的连续性。

组织职责的综合：经过良好测试和理解的成熟技术、专业T&E工作人员的开发和维护、测试基地能力、贯穿整个采办项目的综合测试评估计划、组织良好且负责任的测试组织，有效利用应用于关键采办决策的测试评估知识。

这一跨采办生命周期的综合测试评估的概念，提出后的几年时间里，受到测试评估社区的广泛理解和接受。但是，测试评估的综合，实际进展却很缓慢。这主要由于以下原因：

实施成本

缺乏可互操作的数字工程环境

工具之间的互操作性

在测试评估各个阶段和整个采办生命周期中，统一的数据和知识共享策略