3. 系统工程过程与生命周期模型

航天器研制是一项高风险、高投入、长周期的复杂工程活动。系统工程过程的核心任务，是把用户需求逐层分解为可设计、可制造、可验证、可交付的系统要素，再通过自下而上的集成与验证，证明最终产品确实满足最初的需求。生命周期模型就是描述这一“分解—实现—集成—验证”过程如何组织、何时评审、何时冻结的技术管理框架。本节围绕V模型、瀑布模型、迭代增量模型，以及航天器研制阶段划分、评审节点与里程碑管理展开。

3.1 瀑布模型：线性推进的基线

瀑布模型把研制过程划分为需求分析、初步设计、详细设计、实现、集成、测试、运行维护等阶段，各阶段顺序推进，前一阶段完成并评审通过后才进入下一阶段。它的优点是阶段边界清晰、文档基线明确、便于合同管理和经费拨付；缺点是反馈滞后，若需求在测试阶段才暴露问题，返工代价极高。对于需求相对稳定、技术成熟度较高的分系统（如结构、热控的常规设计），瀑布模型仍然适用。

3.2 V模型：分解与验证的对称结构

V模型是航天器系统工程最常用的生命周期表达。左侧下行分支是分解与定义：任务需求→系统需求→分系统需求→部件/单机规格→制造与装配；右侧上行分支是集成与验证：单元测试→分系统集成测试→系统集成测试→系统验证→任务确认。V模型的关键在于“对称”：每一条需求在右侧都有对应的验证活动，需求与验证通过验证矩阵建立双向追溯关系。

V模型的工程价值体现在三点：第一，强制在左侧定义阶段就规划右侧的验证方法，避免“先设计、后想怎么测”；第二，明确各级接口的验证责任，单元级问题不带到分系统级；第三，为技术状态管理和评审节点提供结构支撑。需要强调的是，V模型并非严格的单向流程，实际工程中允许在相邻层级间进行受控迭代，但每次迭代都必须重新确认基线和验证覆盖。

3.3 迭代增量模型：应对不确定性的策略

当任务需求尚不完全明确，或采用新技术需要先验证可行性时，迭代增量模型更为合适。它把系统划分为若干增量，每个增量都经历一轮“需求—设计—实现—验证”的完整循环，逐步交付可用能力。在航天器研制中，迭代增量常体现为：先研制工程验证星验证关键技术，再研制正样星；或按载荷分系统分批集成、分批测试。迭代增量模型的风险控制优势明显，但要求更强的接口管理和基线控制能力，否则容易出现“版本漂移”。

3.4 航天器研制阶段划分

我国航天器研制通常划分为方案阶段、初样阶段、正样阶段、发射与在轨测试阶段。方案阶段完成可行性论证、总体方案设计和关键技术攻关，输出任务书和方案报告；初样阶段研制电性星、结构星、热控星等各类初样产品，验证设计正确性和接口协调性；正样阶段研制飞行产品，完成全部环境试验和系统级测试，形成飞行基线；发射与在轨测试阶段完成发射、入轨、在轨功能性能测试，确认任务成功。

各阶段的划分不是简单的时间分段，而是以“技术状态基线”为标志：方案阶段结束建立功能基线，初样阶段结束建立分配基线，正样阶段结束建立产品基线。基线一旦冻结，任何更改都必须走技术状态更改控制流程。

3.5 评审节点与里程碑管理

评审节点是阶段之间的“质量闸门”，典型节点包括：任务需求评审（MDR）、系统需求评审（SRR）、初步设计评审（PDR）、关键设计评审（CDR）、测试准备评审（TRR）、飞行准备评审（FRR）。每个评审都有明确的进入准则、退出准则和待关闭行动项。里程碑管理则关注关键事件的完成确认，如PDR通过、CDR通过、正样星出厂、发射窗口确认等。

评审不是“走过场”，其核心是回答三个问题：当前技术状态是否满足阶段目标？遗留问题是否已识别并纳入闭环管理？下一阶段是否具备启动条件？评审结论通常分为“通过”“有条件通过”“不通过”三类，有条件通过时必须明确行动项责任人、完成时间和验证方式。

3.6 模型选择与组合使用

实际航天器研制中，三种模型往往组合使用：总体层面采用V模型保证需求追溯和验证覆盖；分系统内部对成熟技术采用瀑布式推进，对新技术采用迭代增量方式先验证再固化；项目管理层面以阶段评审和里程碑作为控制节点。选择模型时需权衡需求稳定性、技术成熟度、进度压力和经费约束，没有“一刀切”的最优解。

无论采用哪种模型，系统工程过程的本质不变：把需求转化为可验证的基线，用评审和里程碑控制技术状态，用追溯关系保证“所验即所需”。掌握这些模型和节点，是后续开展总体设计、接口管理和试验策划的基础。