# Etunel 项目生命周期

Hub 选择阶段、正式成果、任务波次、门禁或结项时读取。成员只在当前任务需要理解上下游时读取相关阶段。

## 通用推进原则

- 正常顺序是：业务需求 → 产品定义 → 方案设计 → 项目规划 → 软硬件实现 → 测试验证 → 业务验收 → 发布结项。
- 每项任务只有一个主责角色和一个可以独立判断的结果。
- 主责草案、专业角色评估或设计、主责收口的依赖不可颠倒；同一基线上的独立任务可以形成波次。
- 正式结果必须有指定成果、版本、证据、专业自审和负责人确认。
- 正式成果使用中文名称；过程记录、支持材料和额外文件不得冒充正式成果。
- 不适用、延期、豁免、阻塞、模拟和正式完成是不同状态，不能相互替代。
- 正式项目遵循门禁。明确的模拟或流程验证可以按异常规则灵活跳转，但必须标明模拟和风险。
- 每个阶段的文件、进度和交接按 [项目文件与进度留档](project-files-and-progress.md) 保存。

## 阶段 1：业务需求

### 正常任务链

1. 业务形成待评审的业务草案，澄清背景、客户目标、价值、范围、优先级、合作边界、成功指标和目标里程碑。
2. 产品判断是否需要早期专业风险预审，并精确选择角色、问题和必要输入。
3. 如需要，Hub 只向产品指定角色派发预审任务，不擅自增删名单；预审只识别约束与风险，不替代后续设计和测试。
4. 产品整理预审影响，业务负责人确认阶段 1 基线。

### 正式成果

- 项目背景说明
- 项目目标与里程碑计划

早期风险预审记录、客户材料索引和开放项是支持材料，不新增正式门禁成果。客户期望日期只有获得相应授权才成为正式承诺。

### 门禁

有权业务负责人确认项目目标、范围、业务边界和成果版本；开放项、假设和风险如实保留；产品取得足够输入继续定义。

## 阶段 2：产品定义

### 正常任务链

1. 产品基于阶段 1 基线形成产品定义草案、详细客户输入和可测试验收标准。
2. Hub 以同一草案版本向适用的技术、实现、硬件和测试角色派发专业评估；依赖独立时可以形成波次。
3. 各角色只返回本领域可行性、约束、缺口、风险和建议，不代产品改需求。
4. 产品处置反馈、解决需求冲突并收口产品基线。
5. 业务批准客户范围、验收边界和需要组织授权的结论。

### 正式成果

- 立项资料
- 测试验收标准
- 里程碑要求

客户输入矩阵、平台 SDK、串号、对接资料、功能清单、器件和板框资料可以作为包内内容或支持输入，不另立旧版开发资料包。

### 门禁

产品行为、范围、异常边界、接口期望和客观验收标准明确；关键专业约束已处置；产品负责人确认，业务完成范围批准。

## 阶段 3：方案设计

### 正常任务链

1. 技术负责人基于产品基线形成总体方案、接口契约和设计任务草案；方案不得依赖尚未形成的《项目计划》。
2. Hub 以同一方案和接口版本向适用角色形成设计波次：
   - 嵌入式应用层：应用架构、模块、状态、应用接口和集成需求；
   - 嵌入式底层：BSP、Bootloader、驱动、RTOS、HAL 和底层接口；
   - 硬件：电路、PCB、器件、BOM、电源、信号、热和板卡接口；
   - 测试：测试计划、环境、策略、覆盖、可测试性和通过标准；
   - 产品：确认方案没有需求漂移。
3. 技术负责人处理冲突并收口统一架构、接口和关键决定。
4. 受影响角色分别确认本领域约束与统一版本一致。

### 正式成果

- 总体技术方案
- 软硬件接口契约
- 硬件设计包
- 架构决策记录
- 测试计划

技术负责人主责《总体技术方案》《软硬件接口契约》和《架构决策记录》；硬件主责《硬件设计包》；测试主责《测试计划》。

### 门禁

方案、接口、职责、验证方式、版本和风险形成一致基线；技术负责人确认可用于规划，受影响专业角色和产品完成各自范围确认。

## 阶段 4：项目规划

### 正常任务链

1. Hub 基于已确认方案形成《项目计划》《项目风险》《角色分工》《产品资料整合》和《项目状态内部记录》草案。
2. 技术负责人先确认整体任务结构、技术顺序、依赖、角色覆盖、集成关系和关键风险。
3. 只有具体任务存在缺失、冲突或确需专业估算时，Hub 才定向询问对应执行角色；不要求所有角色重复确认整份计划。
4. Hub 收口计划和状态记录；业务授权真实人员、资源、采购、成本和正式日期。
5. Hub 向相关主责角色下发依赖就绪的任务切片。

### 正式成果

- 项目计划
- 项目风险
- 角色分工
- 产品资料整合
- 项目状态内部记录

项目创建时由 Etunel 提供的角色事实和阶段 1–3 状态在本阶段正式化；完整计划由 Hub 维护，不要求全员查看或重复确认。

### 门禁

每项计划任务有主责角色、输入、输出文件、证据、期限、完成条件和依赖；真实资源与日期状态明确，首批任务可以执行。

## 阶段 5：软硬件实现

### 正常任务链

1. Hub 按依赖向嵌入式应用层、嵌入式底层和硬件形成一个或多个实现波次。
2. 各实现角色形成本领域实现成果、版本、自测、证据和负责人确认。
3. 底层向 Hub 提交可消费的底层版本和集成说明；Hub 交应用层合版。
4. 应用层解决集成问题并作为唯一出口形成《嵌入式应用层固件包》。
5. 硬件形成匹配板卡、BOM、ECO、样机和实现资料。
6. Hub 维护固件、底层、硬件、BOM／ECO、配置和接口匹配关系；技术负责人确认可提测组合。

### 正式成果

- 硬件实现资料
- 嵌入式底层实现资料
- 嵌入式应用层固件包

版本矩阵、构建记录和角色自测是必要支持证据，但不新增正式成果类别。底层不得直接向测试提交最终固件。

### 门禁

适用实现成果形成；统一固件与底层、硬件、BOM／ECO、配置和接口版本匹配；技术负责人确认当前组合可交测试。

## 阶段 6：测试验证

### 正常任务链

1. Hub 将应用层统一固件、技术负责人确认的版本组合和对应环境基线交测试。
2. 测试依据《测试计划》和《测试验收标准》执行功能、可靠性、专项和回归验证。
3. 测试创建并维护《缺陷分析报告》；缺陷由 Hub 向实际责任角色形成修复波次。
4. 实现角色提交根因分析、修复计划、修复成果、版本、自测和影响，不能替测试关闭缺陷报告。
5. 底层修复先由应用层重新合版；硬件 ECO 同步完成底层兼容、应用有效性和版本组合确认。
6. 测试在目标版本组合上独立复验并更新缺陷状态；全部适用验证完成后由测试负责人确认结论。

### 正式成果

- 功能测试报告
- 可靠性测试报告
- 专项测试报告
- 测试证据包
- 缺陷分析报告

质量结论、回归和缺陷证据写入上述适用正式成果，不另立其他测试门禁成果。

### 门禁

测试对象、环境、范围、结果、证据、缺陷、复验和剩余风险可追踪；测试明确给出通过、失败或阻塞。测试通过不替代业务验收。

## 阶段 7：业务验收

### 正常任务链

1. 产品基于产品基线、平台结果和测试结论组织验收材料、用例、演示或试用和差异处置。
2. 外部客户不是默认 Etunel 角色；客户输入由业务或产品负责人按联络边界取得，并返回对应角色会话。只有已经定义职责并由 Hub 负责人手动加入 Etunel 的客户角色才可接收任务。
3. 问题由产品判断为需求理解、实现缺陷、环境问题或正式变更；Hub 只路由实际受影响角色，并从正确阶段返工。
4. 产品形成验收报告和附条件事项；业务批准验收结论、上线或交付条件和业务风险接受。

### 正式成果

- 平台提测通过报告
- 客户验收通过报告
- 附条件验收事项

不适用的平台或客户验收成果按不适用或《成果豁免申请》规则处理，不能用内部测试自动替代。

### 门禁

平台与客户验收证据、差异、附条件事项、责任、期限和业务决定明确；未解决项有处置条件和承接人。

## 阶段 8：发布结项

### 正常任务链

1. Hub 只向实际参与、拥有正式成果、遗留风险或发布责任的角色派发发布或结项任务：
   - 应用层输出唯一最终发布固件和发布说明；
   - 底层归档实际被集成的版本和接口信息；
   - 硬件归档板卡、BOM、生产资料和适用 ECO；
   - 技术负责人确认最终版本组合与发布技术前提；
   - 测试对最终组合执行适用发布验证；
   - 产品确认发布范围与已批准产品和验收一致；
   - 业务确认交付、合同、授权、客户沟通和遗留责任。
2. 实际参与角色提交成果索引、未决事项和本角色流程闭环输入；未参与角色说明不适用原因，不创建虚假任务。
3. Hub 汇总归档、变更、结项报告和流程闭环总结，并完成必要确认。

### 正式成果

- 结项资料归档
- 变更记录
- 结项报告
- 流程闭环总结

### 门禁

正式项目只有在适用交付、验证、批准、阶段文件留档和遗留承接完成后才可关闭。模拟项目只记录“模拟完成”，不得宣称真实发布、客户验收或生产就绪。