3. 质量评审体系：嵌入式软件质量模型与评审类型

做嵌入式项目这么多年，我越来越觉得一个道理：质量不是测出来的，是设计出来的，更是评审出来的。你想想看，一个Bug在需求阶段发现，改一改可能就几分钟；等到了现场才发现，那可能就是出差、换板、甚至召回。所以，建立一套靠谱的质量评审体系，是项目管理里最值得投入的事。

3.1 嵌入式软件质量模型（ISO 25010）

说到质量，总得有个衡量的尺子吧？ISO 25010就是这把尺子。它把软件质量分成两大块：产品质量和使用质量。对于嵌入式来说，我特别关注产品质量里的那几个维度。

3.1.1 产品质量模型（8大特性）

ISO 25010的产品质量模型，有8个特性。我挑几个嵌入式里最容易踩坑的说说。

质量特性	嵌入式场景解读	我踩过的坑
功能正确性	该做的事做了没？比如ADC采样值对不对。	曾经有个项目，功能测试全过，但现场发现采样值在低温下漂了5%。
性能效率	响应快不快？内存省不省？	我记得有个电机控制算法，仿真跑得飞起，上板后发现CPU占用率90%。
可靠性	死不死机？数据丢不丢？	这是嵌入式最要命的。我曾经遇到看门狗复位后，全局变量没重新初始化。
可维护性	代码好不好改？模块清不清晰？	接手过一份代码，一个函数3000行，改一个Bug要排查半天。
可移植性	换芯片、换编译器，要改多少？	硬件升级时，发现底层驱动和业务逻辑耦合得死死的。

3.1.2 使用质量模型（5大特性）

使用质量，说白了就是用户觉得好不好用。嵌入式产品的用户可能是操作工、维修员，甚至是另一台机器。

• 有效性：用户能完成任务吗？比如HMI上的启动流程是否顺畅。
• 效率：完成任务快不快？比如参数配置需要点10下还是2下。
• 满意度：用户用得爽不爽？这个容易被忽略，但很重要。
• 抗风险性：误操作会不会导致事故？比如按了急停后，系统是否安全。
• 上下文覆盖：在极端环境下还能用吗？比如高温、高湿、强振动。

嗯，这里要注意：使用质量的评审，最好让最终用户参与进来。我见过太多工程师自己觉得设计得很完美，结果现场工人根本不知道怎么用。

3.2 评审类型：技术评审、同行评审、管理评审

有了质量模型这把尺子，接下来就是怎么量的问题了。评审不是开大会，不同的目的要用不同的评审类型。我个人习惯把评审分成三类：技术评审、同行评审、管理评审。

3.2.1 技术评审

技术评审，说白了就是专家把关。通常由资深工程师或架构师主导，审查技术方案的可行性、设计的合理性。

什么时候做？

• 需求分析完成后，评审需求的可实现性。
• 系统架构设计完成后，评审模块划分和接口定义。
• 关键模块详细设计完成后，评审算法和数据结构。
• 测试方案完成后，评审测试覆盖率和边界条件。

3.2.2 同行评审

同行评审，也叫代码走查或同级审查。它的核心目的不是找茬，而是互相学习、共同提高。

我建议的同行评审流程：

1. 准备阶段：作者提前把代码或文档发给评审人，每人花30分钟过一遍。
2. 评审会议：控制在1小时内，作者逐段讲解，评审人提问和提建议。
3. 记录问题：所有发现的问题都记录下来，分类为“必须改”、“建议改”、“仅供参考”。
4. 跟踪闭环：作者修改后，评审人确认关闭。

3.2.3 管理评审

管理评审，是给项目经理和客户看的。它不关心具体的技术细节，而是关注项目的整体状态。

管理评审的核心议题：

评审维度	关键问题	输出物
进度	当前进度是否符合计划？关键里程碑是否达成？	进度偏差报告
质量	缺陷趋势如何？测试覆盖率是否达标？	质量度量报告
风险	有哪些新风险？原有风险是否已缓解？	风险登记册更新
资源	人力是否充足？设备是否到位？	资源需求清单
变更	需求变更是否已评估影响？	变更控制记录

管理评审的频率，我建议每月一次，或者每个迭代结束做一次。形式可以灵活，但一定要有明确的结论和行动项。我最怕那种开完会什么都没定下来的评审，那还不如不开。

3.3 如何建立评审文化

光有流程和模型还不够，关键是团队愿不愿意做。我见过很多团队，评审就是走个过场，大家坐在一起，没人说话，最后签个字就完了。

怎么破？

• 从简单开始：先做技术评审和同行评审，别一上来就搞全套。
• 领导带头：项目经理和架构师要亲自参与，不能只让下面的人做。
• 不追责：评审中发现的问题，不能用来考核个人绩效。否则没人敢说真话。
• 持续改进：每次评审结束后，花5分钟复盘评审过程本身，看看哪里可以优化。