经典系统工程过程的可视化表达有多种模型，1978年Kevin Forsberg & Harold Mooz提出V模型，V模型非常准确地表示了从系统分解到集成活动的系统演进过程，使系统工程过程变得可视化、且易于管理。受到业界广泛的关注与应用。V模型提出后，不断地在工程实践中应用、演化与改进，在1991年，Kevin Forsberg and Harold Mooz在NCOSE第一届年会上又提出系统工程双V模型，双V模型以一种立体的视角来审视系统开发过程，从而使得系统工程过程的可视化表达更加完善。

下面，我们先从不同模型来了解系统工程过程可视化表达的发展情况。

1、系统工程椭圆模型

1974年正式发布的美军标MIL-STD-499A和之后直到90年代初在不断更新的MIL-STD-499B（但从未正式发布）为经典系统工程做了相对完整的总结。如下图所示，我们称之为椭圆模型。

椭圆模型包括需求分析、功能分析和分配、综合这三步构成的串行技术过程，以及系统分析与控制构成的技术管理过程，用来支持技术过程。

基于技术过程的需求回路、设计回路和验证回路，以及技术过程与技术管理过程的接口，形成自上而下、全面综合、反复迭代、循环递进的问题求解过程，来保证全部系统需求被完整定义、追踪和验证

由需求分析、功能分析和分配、综合、系统分析和控制四部分构成的经典系统工程过程被迭代应用于系统生命期各阶段。

国内有学者将经典的系统工程理解为3 个过程，4个回路（验证），生成3个文档。

3个过程的第一步需求分析负责把用户的需求及外部环境的约束变换成系统要求；第二步功能分析与分配负责把系统要求变换成系统的功能, 并把功能分解为系统的一个一个的小动作 , 形成的文档是功能架构；第三步设计综合, 则根据现有的产品及技术条件, 把功能架构/映射到物理架构上, 完成设计过程。

4个回路则负责把3个步骤各自的产出和输入进行对比, 看是否匹配, 这个过程叫作验证。这其中，设计师要在功能架构和物理架构之间进行多次的、双方向的反复迭代，直至所有的功能架构和物理架构都被试验过，并且二者要一致, 这里包含了巨大的工作量。

〖椭圆模型的优点〗

化繁为简，以非常简洁的方式给出了经典系统工程的基本元素，有助于系统工程问题求解方法论的教学过程。

〖椭圆模型的缺点〗

未能详细阐述作为技术管理活动的系统分析和控制。

验证回路未能强调测试计划、过程和结果评估作为产品开发过程的有机组成部分的重要性。

2、瀑布模型

瀑布模型是1970年由Royce提出的，最初应用于软件开发，由5-7个步骤或阶段构成，1981年，Boehm将瀑布模型拓展为8个步骤。

理想中，每一个阶段都应该顺序完成，直到产品交付为止。但实际上极少如此，因为总会发现缺陷，进而重复步骤直到更正。

瀑布模型存在两方面的不足：

− 未关注架构开发的复杂性和风险管理。

− 未展示系统的迭代扩展和需求逐步细化。

3、V模型

V模型是Kevin Forsberg & Harold Mooz在1978年提出的，V过程模型强调测试在系统工程各个阶段中的作用，并将系统分解和系统集成的过程通过测试彼此关联。

用V模型表述项目周期中技术方面，该模型从左上角用户需求出发，到右上角的用户确认结束。在左侧，分解和定义活动构成了系统体系结构，做了详细设计，右侧紧跟着做综合与验证，从部件、子系统到整个系统验证和确认。从部件级到系统确认，在每一级的试验中，都要参考原始的规范体系和需求文档，以保证部件/子系统/系统能够满足所有的体系规范。

V模型用于可视化系统工程,特别是在概念和发展阶段。V模型突出在需求开发过程中定义验证计划的需要,连续验证与利益相关者需要的重要性,并对连续风险和机会进行评估。V模型提供了一个有用的SE活动在生命周期阶段的图示化说明。在V模型中时间和系统成熟度从左向右进行。V模型的核心描述了从用户需求到系统概念识别到系统架构元素定义（包括最终系统）的基线演化过程。

V的形状非常准确地表示了从系统分解到集成活动的系统演进过程，使系统工程过程变得可视化、且易于管理。不是简单地将瀑布模型折弯。

V模型提出后，不断地进行改进，考虑系统架构和系统元素实体的并行开发，在1991年，Kevin Forsberg and Harold Mooz在NCOSE第一届年会上发表的“The Relationship of System Engineering to the Project Cycle”论文中提出系统工程双V模型，双V模型增加了一个维度，以一种立体的视角看待系统开发过程。双V模型强调并发机会与风险管理；重视用户在开发过程中的持续验证；强调集成、验证与确认规划，通过验证解决问题。

系统工程双V模型提出后，系统工程过程的可视化模型已相当成熟和完善。

双V模型包括架构V和实体V，架构V模型关注系统架构的开发成熟，实体V模型关注组成架构的实体元素的开发实现。由于系统的复杂性，架构V模型的厚度向下逐渐增加，即每一分解级别（系统层次）上的实体数量不断增加。架构V模型的每个实体都有一个相应的实体V模型负责该实体的开发和实现

系统工程过程的架构V模型表达了和实体V模型可以应用在复杂产品和系统研发的各个层次、各个阶段、各种通用特性和专用特性上，即在全过程、全系统、全特性上的应用，在每个应用侧面都有对应的标准组合、标准、或指南手册为在该侧面应用系统工程V模型提供指导。

4、螺旋模型

螺旋模型由Boehm在1986年提出，参考了Hall从1969年在系统工程方面的成果，目的是引进一种风险驱动的产品研制方法。

螺旋模型将反馈的思想融入系统工程的每一个阶段，并认为原型系统的开发是降低系统风险的重要手段。螺旋模型由18个不断旋进的步骤组成，包括：

1）系统需求确定 2）可行性研究 3）系统分析 4）系统详细说明 5）系统原型 6）概念评估 7）功能定义 8）需求分配 9）平衡分析 10）选择设计 11）集成 12）测试评估 13）详细需求 14）元件设计 15）优化 16）设备定义 17）实用原型 18）正式设计评估。

螺旋模型是对瀑布模型的修改，不再要求使用原型。还综合了其他模型的特点，如反馈等。

应用螺旋模型是反复进行的，每次都要经历一些阶段，研制出一个原型，在进入下一阶段前进行风险评估。

〖螺旋模型的优点〗

− 通过原型的建立，使软件开发在每个迭代的最初明确方向

− 通过风险分析，最大程度地降低软件彻底失败造成损失的可能性

− 在每个迭代阶段植入软件测试，使每个阶段的质量得到保证

− 整体过程具备很高的灵活性，在开发过程的任何阶段自由应对变化

− 每个迭代阶段累计开发成本，使支出状况容易掌握

− 通过对用户反馈的采集，与用户沟通，以保证用户需求的最大实现

〖螺旋模型的缺点〗

− 过分依赖风险分析经验技术，一旦风险分析过程中出现偏差将造成重大损失

− 过于灵活的开发过程不利于已经签署合同的客户与开发者之间的协调

− 由于只适用大型软件，过大的风险管理支出会影响客户的最终收益

− 风险管理被描绘为顺序的分析活动，而非开发过程中的并行活动，导致一些低风险活动也被延误

− 原型完成，风险管理活动看上去就停了

5、MBSE

进入新世纪以来，为满足客户需求、应对激烈的市场竞争，各行各业工业品的复杂性日益迅速增长，与此同时其研制周期和成本又要求缩短和降低。由于复杂性造成的这个尖锐矛盾使得复杂产品和系统的研制和全生命期管理面临前所未有的挑战。

传统系统工程由于缺乏有效的技术手段支持复杂产品和系统，在以下几方面面临着严重挑战，包括：

− 由需求到功能的转换和分解

− 需求及设计变更的追踪管理

− 涉及多学科领域团队和系统元素间交互指数级增长的设计方案表达

− 权衡优化和沟通决策

− 设计方案对涉众需求的验证确认（V&V）

传统系统工程方法已无法掌控这种复杂性，MBSE应运而生。MBSE（Model-Based Systems Engineering）基于模型的系统工程， 2007年, 国系统工程国际委员会(INCOSE )在《系统工程2020年愿景》中，给出了“基于模型的系统工程”的定义: 基于模型的系统工程是对系统工程活动中建模方法应用的正式认同，以使建模方法支持系统要求、设计、分析、验证和确认等活动，这些活动从概念性设计阶段开始，持续贯穿到设计开发以及后来的所有的寿命周期阶段。

MBSE将系统的表达由“以文档报告为中心”转变为“以模型为中心”，基于统一建模语言的一系列系统模型成为全生命期各阶段产品表达的“集线器”，可以被各学科、各角色研发人员和计算机所识别，为研发组织内的高效沟通和协同奠定了基础，并将传统系统工程的手工实施过渡到通过软件工具和平台来实施，通过软件工具和平台物化了相应的“方法”，使得系统工程“过程”可管理、可复现、可重用。

在上一节内容中，我们讲到了系统工程过程模型的发展与演变，给大家展示了系统工程从椭圆模型-瀑布模型-V模型-双V模型-螺旋模型-MBSE的演变过程。本节内容，我们将重点展开双V模型的详细过程。

1978年Kevin Forsberg and Harold Mooz提出V模型后，经过不断地进行改进，考虑系统架构和系统元素实体的并行开发，在1991年，Kevin Forsberg and Harold Mooz在NCOSE第一届年会上发表的“The Relationship of System Engineering to the Project Cycle”论文中提出系统工程双V模型，双V模型增加了一个维度，以一种立体的视角看待系统开发过程。双V模型强调并发机会与风险管理；重视用户在开发过程中的持续验证；强调集成、验证与确认规划，通过验证解决问题。

双V模型包括架构V和实体V，架构V模型关注系统架构的开发成熟，实体V模型关注组成架构的实体元素的开发实现。由于系统的复杂性，架构V模型的厚度向下逐渐增加，即每一分解级别（系统层次）上的实体数量不断增加。架构V模型的每个实体都有一个相应的实体V模型负责该实体的开发和实现。

在系统开发过程，架构及实体并行开发时多方面决策以确保架构基线和实体基线的正确性和逐步演进的建模要求；提供了架构与实体并行开发条件下的机会和风险管理、集成、验证和确认计划、及异常处理。因此，双V模型所描述的系统工程过程如上图黑色箭头所示，其中，黑色实线箭头代表实体V模型的开发过程，黑色虚线箭头表明了实体V模型与架构V模型的交互。

下面我们将对这一开发与交互过程进行描述。

1）系统层级的设计

系统层级的设计从架构V模型的左上角开始系统层面的方案开发活动，在双V模型就是系统级实体V模型左侧黑色实线箭头的内容，包括以下四个步骤的定义和基线化：

涉众需求和系统需求

系统功能

系统架构

系统层面的设计指导规范

系统层级实体V的开发活动到此不能继续向前，需要同架构模型进行交互，必须等下一分解级别的实体设计完成。因此我们看到，在双V模型中，开始黑色虚线箭头的交互过程。进入到子系统层级的实体开发活动中。

2）子系统层级设计

在系统级实体V模型过程对需求、功能、架构和设计指导规范进行定义，通过实体V与架构V模型的交互，使得需求从系统级别流向子系统级别，开始子系统级别的需求、功能、架构和设计指导规范的开发。

从系统到子系统被分解成多个子系统，子系统之间必须协同开发，保证接口和设计指导规范的兼容性和一致性，同时便于后面的集成和验证。在子系统层级设计过程中，由上至下的决策关口用于管理不断演变的架构基线。

同样道理，子系统层级实体V的开发活动到此不能继续向前，需要同架构模型进行交互，等下一分解级别的实体设计完成。开始黑色虚线箭头的交互过程。一直往下递归直到进入到最低构型项层级的实体开发活动。

3）LCI层级的设计

子系统级别的设计指导规范完成后，转移到下一分解级别——最低配置项级别的开发。

设计指导决策关口的顺序从系统级别直至LCI，以保证需求可以正确地由上至下传递。

4）LCI层级的开发

对所有最低配置项的建造或编码指导文档同时编制，商业外购成品或半成品除外，但需要综合的技术管理以保证所有LCI外部和内部接口兼容性。

完成包括验证步骤草稿的建造和编码指导文档后，进入建造指导决策关口的评审，以证明LCI建造、编码、集成、验证的可行性，然后对其基线管理。

LCI层级的开发完成后，LCI层级的实体V模型同架构V模型进行交互，开始双V模型中有LCI向子系统以及子系统向系统的黑色虚线箭头的交互过程，往上开始进入子系统/系统层级的开发。

5）子系统/系统层级开发

LCI建造指导文档基线完成后，进行子系统和系统级别的建造文档基线。

对系统级别的建造文档基线进行决策评估时，要有证据保证：若每一实体都按设计文档建造，则整个系统将一定实现对其最初的期望。

子系统/系统开发完成后，又有一个交互过程，在双V模型中，由系统层级到LCI层级的黑色虚线箭头的交互，进入LCIs的实现、集成与验证。

6）LCI层级实现、集成与验证

LCI级别的实现、集成、验证、确认。对于商业外购成品或半成品不用制造，但须在模型的适当级别进行验证确认。

7）子系统层级集成验证

最低级别配置项通过验证后，即可物理集成到相邻的上一级别。

有时，用来集成的硬件和软件也须建造或开发，如用来完成两个商业软件的接口集成软件、用来连接两个硬件配置项的电缆线。

8）系统级集成验证

集成和确认的决策关口顺序和系统建造过程一致，都是由下往上

最后，当子系统被验证实现了规范的要求后，进行整个系统的集成，然后是整个系统的验证和确认。

不论椭圆模型、瀑布模型、螺旋模型、V模型或者双V模型，都主要是对系统工程的技术过程的描述，在ISO/IEC 15288：2008系统生命周期过程模型中，我们知道有四个流程组，除了技术流程外，还有包括管理流程在内的其他三个流程组，因此，在2004年有人融合系统工程实体V模型和相关技术管理过程形成全面系统工程过程模型（CSEP），CSEP模型在2009年被美国国防部采纳为装备采办的标准系统工程过程模型。我们在之前所介绍的NASA系统工程引擎也是CSEP模型一种表现形式。