第二章 验证计划制定：范围、资源、里程碑、风险、审批流程

适用场景

• 新项目原型验证阶段启动，需要明确验证目标与资源分配。
• 已有初步设计规格和架构文档，但尚未形成可执行的验证计划。
• 跨团队协作（设计、验证、软件、项目管理）需要对齐进度和风险应对策略。

前置条件

• 设计规格书（Specification）已发布基线版本。
• 系统架构文档、接口定义表（IDD）已完成初步评审。
• 前序验证结果（如 IP 级验证报告）可供参考。
• 项目管理已确定项目里程碑总图（Master Schedule）。
• 验证团队已到位至少一名验证负责人（Lead）。

操作步骤

1. 收集输入资料：整理设计规格、架构文档、前序验证数据、项目总计划。
2. 定义验证范围：与设计、系统团队评审功能列表，确定 DVT 阶段需要验证的功能子集、性能指标和覆盖目标。
3. 评估资源与预算：估算所需 FPGA/原型板数量、仿真环境、工具许可、人力技能分布和工时。
4. 设定里程碑与交付物：制定关键检查点（如首次上电、基本功能稳定、全功能回归、最终签核）。
5. 识别并量化风险：召开风险研讨会，列出技术风险（如特定 IP 复杂度）、进度风险（如工具链延迟）、依赖风险（如外部模型交付）。
6. 制定审批流程与回退机制：明确计划变更的审批层级、紧急回退条件和责任矩阵。
7. 编写验证计划文档：将以上信息汇总至标准模板，包含版本历史、假设、约束和签署页。

输入输出物

输入物	来源角色	输出物	接收角色
设计规格书 (Rev X.Y)	设计团队	验证计划基线版 (V1.0)	项目管理、验证团队
架构文档/接口定义	系统团队	范围定义清单	验证负责人
项目总里程碑图	项目管理	DVT 子里程碑甘特图	验证工程师
前序验证报告	IP 验证团队	风险登记册（初始版）	质量保证
资源需求问卷	验证负责人	资源分配与预算表	项目管理/财务

责任边界

角色	职责	审批权限
验证负责人 (DV Lead)	主持计划制定、协调资源、定义里程碑、编写计划草案	计划内容技术正确性
设计负责人 (Design Lead)	提供功能范围确认、估算设计配套工作量	范围与功能定义
系统架构师 (System Architect)	确认接口和系统级验证需求	系统级验证范围
项目经理 (PM)	对齐项目总里程碑、资源调剂、风险跟踪	里程碑日期、预算调整
质量保证经理 (QA Mgr)	监督计划完整性、发起质量门评审	计划审批签字

记录材料

• 《DVT 验证计划模板 (v2.1)》——标准章节结构，含签署页。
• 《风险登记册 (Risk Register)》——包含风险描述、概率、影响、缓解措施、责任人。
• 《资源需求与使用跟踪表》——记录每个资源（板卡、license、人力）的申请和实际占用。
• 《里程碑检查点清单》——每个里程碑的验证通过标准与签字要求。

异常处理

• 资源不足：立即触发资源冲突会议，由 PM 跨项目协调或申请临时采购；若无法解决，必须缩小验证范围并书面记录假设。
• 里程碑延期：验证 Lead 需在延期发生前至少 2 周发出预警，评估对下游里程碑的影响，发布基线变更请求（BCR）。
• 风险升级：当风险概率或影响超过阈值（如概率 > 70% 且影响严重），自动进入风险委员会评审，制定备选方案。
• 审批流程阻塞：若计划文档超过 5 个工作日未完成审批，验证 Lead 应发起催促并抄送项目总监。

验收标准

计划文档被正式批准的前提：

• 范围定义已与设计规格交叉核对，无遗漏项（至少一次正式评审记录）。
• 资源分配表已经 PM 和财务会签。
• 里程碑日期与项目总计划一致，且每个里程碑有明确的通过/失败准则。
• 风险登记册已包含至少 5 条具体风险及缓解措施，且经风险负责人确认。
• 审批流程已在计划文档中写明变更控制方法，并附有签署矩阵。
• 验证计划经过至少一次同行评审（Peer Review），所有评审意见均已关闭或记录在案。