02
@@ -804,7 +804,7 @@
03
方案设计
主责:技术负责人 · 协作:嵌入式应用层 + 嵌入式底层 + 硬件 + 测试基于产品定义和前期可行性评估形成可实施方案。
+ 技术负责人:总体架构、软硬件边界、关键决策嵌入式应用层:业务逻辑、应用协议、功能模块设计嵌入式底层:BSP、驱动、RTOS、HAL 设计硬件:器件、PCB、电源/信号/热及接口约束测试:测试标准、测试用例范围、测试项
基于产品定义和阶段 2 已有评审结论形成可实施方案。
技术负责人:总体架构、软硬件边界、关键决策嵌入式应用层:业务逻辑、应用协议、功能模块设计嵌入式底层:BSP、驱动、RTOS、HAL 设计硬件:器件、PCB、电源/信号/热及接口约束测试:测试标准、测试用例范围、测试项
正式成果总体技术方案(选填)软硬件接口契约架构决策记录(选填)测试计划
测试标准、测试用例范围、测试项
测试标准、测试用例范围、测试项
技术负责人确认整体方案,嵌入式应用层/嵌入式底层/硬件确认接口可实施,产品确认不偏离,测试确认可验证
00B / ARTIFACT TRACEABILITY
正式成果—信息流追踪矩阵
流程图规划的每项正式成果都必须能够追踪到首次形成、评审或修订、正式确认以及下游分发。表中流程 ID 与各阶段信息流图和说明表一一对应。
判定原则:正式成果必须由指定主责角色输出;过程记录只能解释校验、评审、冲突、变更和确认,不得替代正式成果。阶段 3 的总体技术方案、架构决策记录,以及阶段 6 的可靠性测试报告为选填成果,未提交不阻塞推进,也无需另行豁免;已提交时仍须完成版本登记和相应确认。若其他必需成果获准豁免,则以下对应流转中的成果引用改为豁免记录和替代证据。
| 阶段 | 正式成果 | 主责角色 | 首次形成/提交 | 评审、修订与确认 | 正式分发/下游使用 |
|---|---|---|---|---|---|
| 1 业务需求 | 项目背景说明 | 业务 | F1.1 | F1.2 条件修订;F1.7 业务确认 | F1.3 评审分发;F1.8 正式基线给产品 |
| 1 业务需求 | 客户里程碑要求 | 业务 | F1.1 | F1.2 条件修订;F1.7 业务确认 | F1.3 评审分发;F1.8 正式基线给产品 |
| 1 业务需求 | 项目背景说明 | 业务 | F1.1 | F1.2 条件修订;F1.7 产品与业务确认 | F1.3 评审分发;F1.8 正式基线给产品 |
| 1 业务需求 | 客户里程碑要求 | 业务 | F1.1 | F1.2 条件修订;F1.7 产品与业务确认 | F1.3 评审分发;F1.8 正式基线给产品 |
| 2 产品定义 | 立项资料 | 产品 | F2.2 | F2.3–F2.6 专业评审与修订;F2.7–F2.8 业务批准 | F3.1 方案设计输入;F4.1 项目规划输入 |
| 2 产品定义 | 测试验收标准 | 产品 | F2.2 | F2.3–F2.6 测试评审;F2.7–F2.8 业务批准 | F3.7 测试计划 输入;F6.1 测试输入;F7.1 验收输入 |
| 2 产品定义 | 里程碑要求 | 产品 | F2.2 | F2.3–F2.6 专业评审;F2.7–F2.8 业务批准 | F4.1 项目计划 输入;S.2 状态同步 |
| 3 方案设计 | 架构决策记录(选填) | 技术负责人 | 提供时于 F3.2 形成;F3.4–F3.6 持续补充 | F3.8–F3.10 确认;X 流程变更时追加 | F4.1 项目规划输入;F5.1 实现约束;F8.7 归档 |
| 3 方案设计 | 测试计划 | 测试 | F3.3/F3.7 明确测试标准、测试用例范围和测试项 | F3.8–F3.10 多角色确认 | F4.1 测试任务规划输入;F6.1 测试任务输入 |
| 4 项目规划 | 项目计划 | 项目Hub | F4.1 | F4.2 技术负责人确认;F4.3–F4.5 定向修订;F4.6–F4.7 业务授权 | F4.8 分发相关执行角色;F5.1 实现任务输入;后续由 X 流程变更 |
| 4 项目规划 | 项目风险 | 项目Hub | F4.1,引用 F1.5–F1.6 预检和阶段3方案风险 | F4.2–F4.7 更新与确认;E/X 流程持续更新 | F4.8 分发;F5.1 实现风险输入;S.2 按角色同步 |
| 4 项目规划 | 项目风险 | 项目Hub | F4.1,汇总阶段 2 已识别风险和阶段 3 方案风险 | F4.2–F4.7 更新与确认;E/X 流程持续更新 | F4.8 分发;F5.1 实现风险输入;S.2 按角色同步 |
| 4 项目规划 | 角色分工 | 项目Hub | F4.1 | F4.2 技术负责人确认;F4.3–F4.5 问题任务修订 | F4.8 随正式任务分发;F5.1 实现责任输入 |
| 4 项目规划 | 产品资料整合 | 项目Hub | F4.1 | F4.2 技术负责人检查产品与方案输入引用 | F4.8 按角色裁剪分发;F5.1 实现输入 |
| 4 项目规划 | 项目状态内部记录 | 项目Hub | F4.1 初始执行记录 | S.3–S.4 证据化纠正;E/X 流程更新 | F4.8 初始执行快照;S.2 自动或按需分发 |
| ID | 触发条件 | 发送 → 接收 | 正式载荷 | 约束/确认 | 对阶段的影响 |
|---|---|---|---|---|---|
| F1.1 | 收到新的客户需求或业务机会,且业务已完成原始信息收集、自查和负责人确认。 | 业务 → 项目Hub | 正式成果草案:项目背景说明、客户里程碑要求。 附带内容:负责人确认、来源引用、成果版本和实际文件。 | 项目Hub不重复判断业务内容质量,只检查形式和跨来源一致性。 | 进入中心登记。 |
| F1.2(条件流) | 仅当文件结构、版本、证据不合规,或与已登记正式信息发生冲突时触发;不存在上述问题时跳过。 | 项目Hub → 业务 | 过程记录:形式校验问题清单或冲突清单。 关联成果:受影响的项目背景说明/客户里程碑要求及其字段、版本、冲突来源和修正要求。 | 项目Hub不能生成业务缺失项或替业务补写事实;无错误或冲突时不得发起此流。 | 触发后,错误或冲突关闭前阻塞登记;未触发则直接进入 F1.3。 |
| F1.3 | 业务成果通过项目Hub的文件、版本、证据和跨角色冲突检查并完成登记。 | 项目Hub → 产品 | 评审分发成果:待评审的项目背景说明、客户里程碑要求。 附带内容:成果版本、状态、证据、待确认项和回复时限。 | 必须标明这是待评审版本,不得冒充正式基线,产品不得据此直接启动阶段 2。 | 产品获得早期风险识别所需上下文。 |
| F1.4 | 产品审阅业务成果后,判断存在需要其他专业角色提前确认的风险。 | 产品 → 项目Hub | 过程记录:早期风险预检请求。 关联成果:项目背景说明/客户里程碑要求的相关字段与版本;另含预检原因、问题、目标角色、期望输出和时限。 | 是否预检、预检范围及对象角色均由产品负责指定;项目Hub不代替产品判断。 | 按产品指定名单创建预检任务。 |
| F1.5–1.6 | 产品预检请求格式完整,且指定的对象角色均为当前项目有效成员。 | 项目Hub ↔ 产品指定的对象角色 | 过程记录:角色预检任务 / 预检结果(角色预检任务/结论)。 关联成果:项目背景说明、客户里程碑要求;返回本专业红线、风险、证据、待澄清项和受影响字段,作为后续 项目风险 输入。 | 项目Hub必须主动提醒全部关联角色,只校验、路由和汇总,不得自行增删产品指定名单。多角色结论冲突、影响较大或无法异步收敛时,建议由产品组织线下会议;参与角色统一确认的结论按 E.3 回传后,才能继续当前流程。 | 补充业务澄清和早期风险登记;复杂问题进入 E.1–E.4,闭环前保持阻塞。 |
| F1.7 | 业务内部审查、中心形式校验和预检问题均已关闭。 | 业务 → 项目Hub | 确认成果:完成负责人确认的项目背景说明、客户里程碑要求。 附带内容:确认状态、确认时间、确认条件和版本。 | 角色内部确认状态、时间和版本必须记录。 | 门禁可进入评审。 |
| F1.8 | 业务确认完成,项目Hub已登记并留档正式版本且阶段门禁通过。 | 项目Hub → 产品 | 正式基线:项目背景说明、客户里程碑要求的当前有效版本。 附带内容:成果版本、基线与证据引用、阶段 2 任务和确认时限。 | 只允许分发已经确认并留档的当前有效版本;分发事件和接收状态必须登记,草稿或过期版本不得作为产品定义输入。 | 产品接收后开启阶段 2。 |
| F1.3 | 业务成果通过项目Hub的文件、版本、证据和跨角色冲突检查并完成登记。 | 项目Hub → 产品 | 评审分发成果:待评审的项目背景说明、客户里程碑要求。 附带内容:成果版本、状态、证据、待确认项和回复时限。 | 标明待评审状态;经产品与业务确认并留档后,才可作为阶段 2 输入。 | 产品与业务通过项目Hub进入 F1.7 需求基线确认。 |
| F1.7 | F1.3 已分发评审版本,业务内部审查和中心形式校验已完成。 | 产品 ↔ 项目Hub ↔ 业务 | 确认成果:经产品与业务各自负责人确认的项目背景说明、客户里程碑要求。 附带内容:确认状态、确认时间、确认条件和版本。 | 待确认项经项目Hub中转澄清;记录双方各自负责人确认状态、时间和版本,双方须确认同一版本。 | 双方确认后通过门禁,进入 F1.8 并开启产品定义。 |
| F1.8 | 产品与业务确认同一需求基线,项目Hub已登记并留档正式版本且阶段门禁通过。 | 项目Hub → 产品 | 正式基线:项目背景说明、客户里程碑要求的当前有效版本。 附带内容:成果版本、基线与证据引用、阶段 2 任务和确认时限。 | 只允许分发已经确认并留档的当前有效版本;分发事件和接收状态必须登记,草稿或过期版本不得作为产品定义输入。 | 产品接收后开启阶段 2。 |
02 / PRODUCT
阶段 2:产品定义信息流
产品形成完整立项资料,并让技术负责人、嵌入式应用层、嵌入式底层、硬件和测试从各自专业角度完成可行性确认。
主责产品;业务批准范围
核心成果立项资料、测试验收标准、里程碑要求
门禁产品确认方案,业务批准范围,约束和测试标准完整
-
+
@@ -1020,11 +1015,11 @@
-
+
项目Hub
F2.1下发产品定义任务附阶段 1 基线和全部红线约束
产品
项目Hub
F2.1下发产品定义任务附产品与业务已确认的阶段 1 基线及已知约束
产品
产品
F2.2提交立项资料草案与专业评审请求产品明确评审角色、问题、范围和期望输出
项目Hub
项目Hub
F2.3校验请求并并行路由专业评审按产品指定范围裁剪上下文,不新增专业问题
技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
评审角色
F2.4返回可行性、缺口和约束每条意见必须关联具体成果字段
项目Hub
03 / DESIGN
阶段 3:方案设计信息流
技术负责人依据产品定义基线和前期风险评估组织总体方案;产品、嵌入式应用层、嵌入式底层、硬件和测试围绕同一份软硬件接口契约完成多轮确认。
03 / DESIGN
阶段 3:方案设计信息流
技术负责人依据产品定义基线,结合阶段 2 已有评审结论组织总体方案;产品、嵌入式应用层、嵌入式底层、硬件和测试围绕同一份软硬件接口契约完成多轮确认。
主责技术负责人主责接口契约及选填的方案、决策记录;硬件确认接口与约束;测试主责测试计划
核心成果软硬件接口契约、测试计划;总体技术方案、架构决策记录为选填
门禁方案确认、接口可实施、需求不偏离、测试可验证
总体技术方案、架构决策记录为选填,未提供不阻塞阶段推进,也无需另行豁免;必要的技术决定仍须写入软硬件接口契约或角色确认记录。硬件在本阶段完成接口与约束确认,硬件设计包在阶段 5 形成并确认。
-
+
@@ -1036,7 +1031,7 @@
项目Hub
F3.1下发总体方案设计任务附产品定义基线、前期风险结论和现有技术参考资料
技术负责人
项目Hub
F3.1下发总体方案设计任务附产品定义基线、阶段 2 已有评审记录和现有技术参考资料
技术负责人
技术负责人
F3.2提交接口契约草案含边界、关键决策、非功能和风险;附已提供的总体技术方案、架构决策记录
项目Hub
项目Hub
F3.3并行分发角色化设计任务每个角色在同一契约版本上工作
产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
嵌入式应用层
F3.4提出 HAL、资源和应用接口需求接口新增或资源不足时触发
项目Hub → 嵌入式底层 / 技术负责人
项目Hub
F3.10请求各角色确认接口可实施嵌入式应用层、嵌入式底层、硬件、产品、测试分别确认
产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
| ID | 触发条件 | 发送 → 接收 | 正式载荷 | 约束/确认 | 对阶段的影响 |
|---|---|---|---|---|---|
| F3.1–3.3 | 阶段 2 门禁通过,产品定义基线和前期风险结论有效。 | 项目Hub ↔ 技术负责人/协作角色 | 按主责角色分别形成的正式成果草案:技术负责人输出 软硬件接口契约;总体技术方案、架构决策记录为选填。测试输出 测试计划,包含测试标准、测试用例范围、测试项。 协作输入:硬件完成接口与约束确认。 输入内容:阶段2三类产品成果、现有技术参考资料、F1.5–F1.6 预检结论、设计范围和时限。 | 方案设计不得依赖尚未形成的 项目计划;所有设计必须引用同一产品基线。 | 开启并行方案设计。 |
| F3.1–3.3 | 阶段 2 门禁通过,产品定义基线有效。 | 项目Hub ↔ 技术负责人/协作角色 | 按主责角色分别形成的正式成果草案:技术负责人输出 软硬件接口契约;总体技术方案、架构决策记录为选填。测试输出 测试计划,包含测试标准、测试用例范围、测试项。 协作输入:硬件完成接口与约束确认。 输入内容:阶段2三类产品成果、现有技术参考资料、阶段 2 已有的可行性与风险评审记录(如有)、设计范围和时限。 | 方案设计不得依赖尚未形成的 项目计划;所有设计必须引用同一产品基线。 | 开启并行方案设计。 |
| F3.4 | 嵌入式应用层需要新的资源、HAL 或协议。 | 嵌入式应用层 → 项目Hub → 嵌入式底层 / 技术负责人 | 修订对象:软硬件接口契约;已提供的总体技术方案、架构决策记录。 提交内容:接口需求、调用频率、性能、资源指标、理由和受影响功能。 | 不得绕过契约直接约定。 | 可能触发契约修订。 |
| F3.5 | 嵌入式底层依赖引脚、电平、器件或时序。 | 嵌入式底层 → 项目Hub → 硬件 / 技术负责人 | 修订对象:软硬件接口契约;已提供的架构决策记录。 提交内容:HAL、引脚表、时序、电气约束、板卡依赖和证据。 | 涉及既有板卡时引用明确版本;新设计注明约束版本。 | 冲突时阻塞相关设计。 |
| F3.6 | 器件、PCB、电源、空间或热约束影响方案。 | 硬件 → 项目Hub → 技术负责人 / 嵌入式底层 / 产品 | 关联或修订成果:软硬件接口契约;必要时同步修订已提供的 总体技术方案、架构决策记录。 过程记录:硬件约束与接口确认。 提交内容:限制、替代方案、成本、性能和交期影响。 | 器件替换不得静默发生。 | 更新接口与约束确认;改变正式基线时走变更申请。 |