模块 2：系统工程生命周期
V 模型、生命周期阶段以及 MBSE 所支持的技术过程 — 为方法论的学习奠定基础。
前置：MBSE 模块 1V 模型（V-Model）
如果说系统工程中有一张每位工程师都见过的图，那一定是 V 模型。它是系统工程中最常用的生命周期模型，用一个清晰的 V 形结构展示了系统从初始概念到验证交付的完整过程。
V 模型因其形状而得名。V 的左侧代表分解与定义 — 将系统逐步拆解为越来越小的部分，并在每一层定义需求和架构。V 的右侧代表集成与验证 — 将这些部分重新组装，并在每一层进行测试以确认其正确性。
图 1 — V 模型：左侧为分解，右侧为集成与验证
从上到下阅读左侧：
- 系统需求（System Requirements） — 整个系统必须做什么。
- 子系统需求（Subsystem Requirements） — 每个主要子系统需要满足哪些系统需求。
- 组件需求（Component Requirements） — 每个独立组件必须做什么。
- 实现（Implementation） — 对每个组件进行实际的构建、编码或制造（V 的底部）。
从下到上阅读右侧：
- 组件验证（Component Verification） — 每个组件是否满足其组件级需求？
- 子系统验证（Subsystem Verification） — 组件组装成子系统后，是否满足子系统需求？
- 系统确认（System Validation） — 所有部分集成后，完整系统是否满足最初的利益相关者需求？
关键洞察：左侧的每一层分解都对应右侧的一个验证或确认层级。你不必等到最后才发现问题 — 而是在每一层都进行测试。
想象一下策划婚礼。V 的左侧是分解：你从"策划完美的婚礼"（系统需求）出发，然后拆分为子任务 — 预订场地、聘请餐饮服务、找摄影师（子系统需求），再进一步拆分为组件级细节 — 选择菜单、挑选花艺、设计请柬。
V 的右侧是集成与验证：首先逐项检查每个组件（品尝食物、审核请柬样张），然后进行整合多个要素的彩排（彩排晚宴），最后婚礼当天就是"系统确认" — 一切是否如预期般完美地结合在一起？
ISO/IEC/IEEE 15288 技术过程
V 模型给了我们生命周期的形状，而国际标准 ISO/IEC/IEEE 15288 则给了我们词汇表。它定义了一组系统工程项目应当涵盖的技术过程（Technical Processes）。可以把它想象成一本食谱 — 它告诉你有哪些"菜品"（过程），但不规定你必须按什么顺序烹饪。
| 技术过程 | 目的 | 典型 MBSE 制品 |
|---|---|---|
| 利益相关者需求定义 (Stakeholder Needs Definition) | 识别利益相关者及其需求 | 利益相关者模型、用例图 |
| 需求分析 (Requirements Analysis) | 将利益相关者需求转化为精确、可测试的需求 | 需求模型、需求图 |
| 架构定义 (Architecture Definition) | 设计系统结构（组件、接口、分配） | 模块图、内部模块图 |
| 设计定义 (Design Definition) | 详细设计每个组件 | 参数模型、详细零件模型 |
| 集成 (Integration) | 将组件组装为子系统和系统 | 集成计划模型、接口矩阵 |
| 验证 (Verification) | 确认系统满足其需求（"正确地构建了产品"） | 测试用例模型、验证矩阵 |
| 确认 (Validation) | 确认系统满足利益相关者需求（"构建了正确的产品"） | 场景模型、仿真结果 |
| 移交 (Transition) | 将系统交付给运营方并支持持续使用 | 部署模型、培训计划 |
ISO/IEC/IEEE 15288 是一项标准，而非强制规定。它描述的是有哪些过程存在，而不是你必须如何执行它们。你的组织可以根据项目需要自由裁剪、合并或重新排列这些过程。该标准提供了一套通用语言，使跨组织、跨行业的工程师能够有效沟通。
验证 vs 确认（Verification vs Validation）
一个常见的混淆点：
- 验证（Verification）问的是："我们是否正确地构建了系统？" — 产品是否满足其规定的需求？
- 确认（Validation）问的是："我们是否构建了正确的系统？" — 产品是否真正满足利益相关者的实际需求？
你可以建造一座完美通过验证的桥梁（满足所有工程规格），但它可能无法通过确认（因为建在了错误的位置）。两者缺一不可。
MBSE 在生命周期中的位置
首先需要澄清一个关键误解：MBSE 不是一种生命周期模型。它不是 V 模型、螺旋模型或任何其他生命周期框架的替代品。相反，MBSE 是一种使用模型而非文档来执行生命周期活动的方式。
在传统的（基于文档的）方法中，每个生命周期活动都会产出一份文档 — 利益相关者需求文档、系统需求规格书、架构描述文档、测试计划等等。而在 MBSE 方法中，同样的活动产出的是模型：
- 利益相关者需求定义 → 利益相关者需求模型（用例、场景、运行上下文）
- 需求分析 → 需求模型（结构化、有链接的需求及可追溯性）
- 架构定义 → 架构模型（结构分解、接口、分配关系）
- 设计定义 → 行为和参数模型（状态机、活动、约束）
- 验证与确认 → 验证模型（与需求关联的测试用例、仿真结果）
关键优势在于：由于所有这些模型都存在于同一个建模环境中，它们是相互关联的。一条需求可以追溯到满足它的架构元素、验证它的测试用例，以及驱动它产生的利益相关者需求 — 全部通过可导航的实时链接，而非静态文档之间的交叉引用。
当有人问"我们应该用 MBSE 还是 V 模型？"时，答案是"两者都用"。V 模型（或你选择的任何生命周期模型）告诉你做什么以及什么时候做。MBSE 告诉你如何捕获和管理信息 — 用模型代替文档。它们是互补的，而非竞争关系。
迭代与递归（Iteration and Recursion）
现实中的系统开发绝非沿着 V 的一侧走下去再沿另一侧走上来那么简单。两个重要概念使生命周期更加贴近现实：迭代（Iteration）和递归（Recursion）。
迭代（Iteration）
迭代是指在同一层级内反复执行某个过程或过程集以优化结果。例如，你可能要经过几轮架构定义才能使设计稳定下来 — 每一轮都会产出更成熟、更详细的模型。就像雕塑家：第一遍塑造粗糙的形状，第二遍增加细节，第三遍进行打磨。每一遍都是对同一过程的迭代。
递归（Recursion）
递归是指在系统层次结构的不同层级应用同一组过程。你用来定义系统的过程（利益相关者需求、需求分析、架构定义、验证）同样会在子系统层级再执行一次，在组件层级再执行一次。
想象俄罗斯套娃（Matryoshka）。打开最外层的娃娃（系统），里面是一个较小的娃娃（子系统），再里面是一个更小的娃娃（组件）。每个娃娃都有相同的形状和绘制特征 — 只是大小不同。在系统工程中，每一层"娃娃"都会经历相同的生命周期过程（需求、架构、验证），只是在不同的抽象层级上。
这正是模型在系统工程中如此有价值的原因。一个结构良好的模型能够在单一的、一致的框架中表示多个抽象层级。你可以放大查看系统级架构，也可以缩小查看某个具体组件的设计 — 层级之间的可追溯性链接会自动维护。使用文档来管理这种多层级一致性极其困难，而使用模型则是内建的。
V 中的螺旋
在实践中，大多数现代项目会将 V 模型结构与迭代螺旋相结合。在 V 的每一个阶段，团队可能会经历多次迭代（螺旋）来完善其工作成果。MBSE 天然支持这种方式：模型本质上是渐进式的。你不会"一次性"写完一个模型 — 你会在每次迭代中持续演进它，不断增加细节和优化。
运行概念（Concept of Operations, ConOps）
在定义需求或设计架构之前，你需要先理解系统将如何被使用。这就是运行概念（ConOps）的目的 — 从用户视角、用用户的语言来描述系统，聚焦于运行场景。
ConOps 通常是任何 MBSE 工作的起点。它回答三个基本问题：
- 谁是用户和利益相关者？
- 他们做什么（对系统有什么期望）？
- 系统需要处理哪些场景？
示例：智能家居系统
以一个智能家居安防系统为例。ConOps 模型会捕获：
角色（谁）：
- 房主 — 主要用户，布防/撤防系统，监控警报
- 访客 — 有限访问权限，可使用临时密码进入
- 维护技术人员 — 进行更新和维修，需要诊断访问权限
- 监控服务商 — 响应警报事件的外部服务
操作（做什么）：
- 布防系统（全防模式、外出模式、夜间模式）
- 撤防系统（通过键盘、APP 或语音）
- 监控摄像头和传感器状态
- 配置自动化规则（例如"晚上 11 点后检测到移动则开灯"）
- 接收和确认警报
场景（如果发生什么）：
- 正常运行 — 房主离家，布防系统，系统监控传感器，房主回家，撤防
- 警报触发 — 传感器检测到入侵，系统发出警报，通知监控服务商，房主收到警告
- 断电 — 系统切换到电池备份，减少非关键功能，通知房主
- 误报 — 房主在宽限期内取消警报，系统记录事件
为什么 ConOps 很重要：如果没有清晰的 ConOps，工程师往往会在没有真正理解系统将如何被使用的情况下直接跳入组件设计。这会导致技术上令人印象深刻但在实践中失败的系统 — 典型的"拿着锤子找钉子"。在 MBSE 中，ConOps 模型成为一个活的参考基准，模型的其余部分都可以追溯回它：每条需求都应链接到一个运行需求，每个测试用例都应追溯到一个运行场景。
通往三大支柱
在本模块中，我们探索了系统工程生命周期 — V 模型、ISO/IEC/IEEE 15288 技术过程、MBSE 如何支持（而非替代）生命周期、迭代与递归的概念，以及运行概念（ConOps）的重要性。
但理解生命周期只是开始。要真正实践 MBSE，你需要三样东西协同工作：
- 建模语言（Modelling Language） — 一种精确、标准化的方式来表达系统信息（例如 SysML、SysML v2）。
- 方法（Method） — 一套系统化的过程，告诉你建什么模型、按什么顺序、到什么程度的细节（例如 OOSEM、MagicGrid、Harmony）。
- 工具（Tool） — 一个支持语言和方法的软件环境，使你能够创建、管理和分析模型（例如 Cameo、Rhapsody、Capella）。
这三个要素通常被称为 MBSE 的三大支柱。
想象一个三脚凳。凳面就是 MBSE — 它是你坐的地方，是你实际使用的东西。但没有三条腿它就站不住：语言这条腿、方法这条腿、工具这条腿。移除任何一条腿，凳子就会倒塌。再好的工具，没有表达模型的语言也无用武之地。再强大的语言，没有管理复杂性的工具也不切实际。语言和工具齐备了，没有方法来引导方向，也是徒劳的。
在接下来的三个模块中，我们将深入研究每根支柱：模块 3 讲语言，模块 4 讲方法，模块 5 讲工具。