ATAM 是什么
ATAM（Architecture Tradeoff Analysis Method）是 SEI 提出的架构评审方法：以业务驱动因素和质量属性场景为主线，让利益相关方共同审视架构方案，识别哪些决策对质量属性影响大（敏感点）、哪些决策同时影响多个质量属性（权衡点），最后输出风险、非风险与风险主题清单。它的价值在于把“架构好不好”的争论，落到具体场景与可验证的响应度量上。
基本信息
| 参与方 | 架构师、开发、运维、业务方与质量属性相关干系人 |
|---|---|
| 输入 | 业务驱动因素、质量属性场景、架构方案与已有决策记录 |
| 输出 | 风险点、非风险点、敏感点与权衡点清单，含责任人与整改期限 |
| 时机 | 重大架构决策前、方案定型前，以及每轮迭代对既有决策的复评 |
典型使用场景
- 新系统架构定型前：在投入开发前暴露质量属性薄弱环节
- 遗留系统重构：先明确改造目标与不可退让的约束
- 关键决策争议：性能与可用性冲突时用场景量化取舍
- 跨团队协作方案：多个团队共用组件前对齐边界与责任
- 合规与安全评审：把合规要求写成可度量场景一并评估
流程
流程
1. 业务驱动因素与质量属性场景
2. 展示架构方案
3. 识别架构方法与敏感点/权衡点
4. 分析风险点、非风险点与风险主题
5. 输出评审报告与整改项评审输出清单
| 输出物 | 内容 | 用途 |
|---|---|---|
| 风险点 | 可能导致质量目标不达成的决策 | 列入整改与跟踪 |
| 非风险点 | 经分析确认安全的决策 | 减少重复讨论 |
| 敏感点 | 对某质量属性影响明显的决策 | 变更时重点评估 |
| 权衡点 | 同时影响多个质量属性的决策 | 多目标取舍时对照 |
质量属性场景写法
质量属性场景写法
结构：刺激源 → 刺激 → 环境 → 制品 → 响应 → 响应度量
示例：运维人员在峰值期间向订单服务部署新版本，
服务应在不中断在途订单的前提下完成，
部署期间下单成功率不低于 99.95%
# 六个要素缺一不可，否则场景无法用来验证使用要点
- 场景先写全：刺激源、刺激、环境、制品、响应与度量六要素齐备才可验证
- 评审后指定责任人与期限，下期评审先回顾上次整改状态，形成闭环
- 评审纪要要记录被否决的结论与理由，避免同一问题反复争论
- 参与者要包含运维与业务方：只有开发参与的评审常漏掉运维与合规约束
评审质量取决于场景质量：场景要有可度量的响应与触发条件，避免泛泛而谈“性能要好”，否则结论无法验证，也无法进入测试用例。
ATAM 不能替代安全评审与合规审查：它能结构化暴露质量属性风险，但专项安全测试与合规评估仍需独立流程。