1. 架构评审概述

各位同学好，我是老张。今天咱们开始聊ASPICE流程里的架构评审。说实话，这个主题我讲了不下二十次，但每次讲都有新感悟。为什么？因为架构评审这东西，你做得越深，越发现它不光是技术活，更是个管理艺术。

什么是架构评审

架构评审，说白了就是一群人坐在一起，对着你的系统架构设计方案挑毛病。嗯，我故意说得这么直白。你想想看，一个汽车电子系统，少则几十个ECU，多则上百个，里面跑的软件动辄上千万行代码。如果不在设计阶段把架构理清楚，等到代码写完了再改，那成本可就大了去了。

我个人习惯把架构评审分成两类：

• 正式评审：有流程、有模板、有签字确认。ASPICE里要求的那种。
• 非正式评审：拉几个资深工程师，在白板前画一画，聊一聊。我经常干这事。

但不管哪种形式，核心目标都一样——尽早发现设计缺陷。

为什么在ASPICE中如此重要

这个问题我问过很多学员。有人说是为了过审核，有人说是客户要求的。这些都对，但没说到根子上。

ASPICE的SYS.3和SWE.2这两个过程域，专门针对架构设计。评审是其中的关键活动。我记得有一次帮一家供应商做流程改进，他们的架构评审就是走过场——评审会开了，问题也提了，但没人跟踪整改。结果呢？项目后期出了个严重的时序冲突问题，改了一个月才搞定。

为什么会这样？因为架构评审在ASPICE里承担着三个核心作用：

1. 验证符合性：架构设计是否满足了系统需求？有没有遗漏？
2. 识别风险：架构层面的技术风险、集成风险、性能风险。
3. 建立基线：评审通过的架构，就是后续开发的基准。谁想改，得走变更流程。

说白了，ASPICE把架构评审当作一个质量门。过了这个门，你才能往下走。不过这个门，后面出了问题你都得自己扛。

评审的总体目标

我总结了四个字：找茬、对齐。

找茬，就是发现架构设计里的问题。比如：

• 模块划分不合理，耦合度太高
• 接口定义不清晰，数据流有歧义
• 性能指标没满足，响应时间超标
• 安全机制缺失，故障处理路径不完整

对齐，就是让所有干系人对架构达成一致理解。你想想看，系统工程师、软件工程师、测试工程师、项目经理，每个人对架构的理解可能都不一样。评审会就是把这些理解拉到同一个频道上。

我曾经遇到过一个项目，系统工程师画的架构图里有个模块叫"通信管理"，软件团队理解成CAN通信，硬件团队理解成以太网通信。结果评审会上才发现，两边说的根本不是一回事。你说这评审重不重要？

最后说一句。架构评审不是一次性的活动。我习惯在架构设计的不同阶段做多次评审：

阶段	评审重点	参与角色
概念设计	方案可行性、技术选型	系统架构师、技术专家
详细设计	模块划分、接口定义	软件架构师、开发代表
实现前	时序分析、资源预算	性能工程师、测试代表

嗯，今天就先聊到这儿。下一节咱们具体讲讲评审的输入和输出，也就是评审前你要准备什么，评审后你要产出什么。这些东西搞清楚了，你的评审才不会流于形式。