写在前面，软件架构评估是一个大型项目成功的保证，不管是否完全按照书中的操作来完成，但这总是一个必须的过程。老外的技术方面的书一般都很实在，在提出一定的事实和相应的理论基础后，一般就会列出些很具体的方法，可操作性都比较强，当然，其实其理论在我们看来也没什么高深之处，可能是思维方式和长期教育环境的不同造成的，在我看来，他们的理论就是对自己的观点或者方法的一个形而上的逻辑证明，但恰恰这就是最重要的，如果在逻辑上就不具有可推导性，具体的方法再怎么说得天花乱坠也没有可信度，另外翻译得也不错，不象有些书，根本就是外行瞎折腾，翻译出来只有鬼才看得懂，不如直接去看原版。

建议有空详读原文，我把这些摘录下来是希望能有所参照。　

《软件架构评估》学习笔记

〈Evluating Software Architectures〉 Authors: Paul Clements, Rick Kazman, Mark Klein

清华大学出版社 孙学涛 朱卫东 赵凯 译

概念：

架构方法： 就是一组架构决策，各个架构决策互相协调，共同实现所期望的质量属性目标。

架构评估： 架构来自许多离散的决策，而这些决策是可以被分析和审查的。

ATAM： 架构权衡分析方法

Architectures Trade-off Analysis Method

ATAM方法步骤：

共4大部分，9个步骤

以上步骤并不是固定的，有时必须对评估规划做某些动态的更改，以容许人员或架构信息的改变。

ATAM评估方法的的阶段：
　

评估小组各成员的角色及其职责

商业目标分析结果表：

系统质量属性列表：

第一阶段获得的带优先级的效用树：

第1层： 效用

场景分析表：

1. 场景描述：

ARID评估方法

---- Active Reviews for Intermediate Design

ATAM和SAAM都是适用于对软件的完整架构进行评估的方法。但是，架构经常是要经历很长时间，阶跃式地逐渐完善，而不是一开始就以最终确定的完美形式出现的

在架构设计过程中，对已经完成的部分逐步进行评审，及时发现某些部分的错误，不一致性或者是考虑不周的地方，而且在大多数项目开发中经常需要对系统的每个大组件或子系统进行这种评审。这一阶段需要的是一种简单易用的评估方法，应该重点关注适宜性，以一种风险承担者能够接受的方式展示设计方案，并能在缺少详细文档的情况下进行架构评估，这时就要用到ARID方法，active reviews for Intermediate Design。ARID最适合于对尚不完善的架构进行评估，在这一阶段，设计人员就是想搞清楚从要求使用该设计架构的其他部分的角度来看，所采用的设计方案是否合适。或许设计中的这个框架的潜在采用者／重用者想要搞清楚该怎样使用这一框架。

传统设计评审和积极设计评审中所用的指令对比

ATAM，SAAM，ARID的比较

所有的评估方法至少要用下列两种技巧：

-- 提问技巧。 用问卷、检查列表或场景来调查某个架构满足其质量属性需求的方式。架构评估中所用的提问技巧通常涉及到要做某些“思维实验”，以预期系统的表现，因为此时系统还不存在

-- 度量技巧。 要用某个工具对软件产品进行度量。度量技巧包括要运行所评估架构对应系统的模拟程序，以搞清系统的某些情况。要选择恰当的单位。对复杂性、耦合度和内聚性的度量通常用来得出可修改性的结论。对数据流的度量（即度量沿通信通道的数据量的大小及其频率）则可用来对系统性能或性能瓶颈做出预测。

应注意的危险信号：

• 架构必须与当前的组织结构相对应。因为有相应的组织而添加 不必要的部分。
• 最顶层的架构组件超过了25个。过于复杂，架构设计师可能 难以进行明智的控制，负责实现架构的设计人员那当然也无法做到这一点。
• 设计方案的剩余部分受某一项需求的左右。架构是以满足极高的可用性需求为目标的。如果降低这一需求，整个架构就会显得过于复杂。过分强调某一需求可能会使其他需求得不到重视。
• 架构信赖操作系统中的可变部分。这样使架构受到操作系统升级的影响；这一明显的设计缺陷在实际中经常出现，其频度令人惊讶。
• 在可用标准组件的地方却使用了专用组件，使整个架构信赖于某个供应商。
• 组件的定义是根据硬件划分确定的。硬件会随着系统的演进而变化，硬件组件可能会合并成更通用的处理器，或分解成专用的设备。如果软件独立于硬件结构，就可使其免受硬件变化的影响。
• 有超出可靠性要求之外的冗余。这表明设计人员意见不一，导致不必要的复杂性，也会使系统维护的难度加大。
• 设计方案受例外情况的左右；重点强调的是可扩充性而不是共核部分。
• 开发组织不能确定出谁是系统架构设计师。
• 构架设计师或项目经理在确定该架构的风险承担者时感到很困难，这可能意味着他们根本就没有考虑关于风险承担者的问题。
• 开发人员在对某两个组件的组件的交互进行编程时有过多的选择余地。出现这种情况的原因可能是架构上提供了太大的选择自由，或者没有考虑这一问题。意味着架构还要进一步完善。
• 当要求架构设计师提供文档时，除了类图外，拿不出任何其他材料。
• 当要求架构设计师提供文档时，拿出的是大量的由某一工具自动生成的文档，但这些文档根本没人看过。
• 所提供的架构文档陈旧，显然已经过时。
• 当要求对架构做出表述时，设计人员或编程人员或者不能做出表述，或者所做的表述与架构设计师所讲的内容存在很大的差别。
• there must be more as the process progressed.

对项目开发威胁最大的管理问题：

• 没有清楚地确定出风险承担者
• 项目开发中没有相关领域专家的参与
• 项目资金没有真正落实
• 没有指定项目经理或项目负责人
• 没有制定出项目计划或规划
• 部署日期不实际
• 没有明确的衡量优劣的标准
• 没有选定软件的架构
• 虽然在每个层面上都有一位架构设计师，但没有人对总体架构负责
• 没有编写总体架构计划
• 没有独立的负责编写需求的小组存在
• 没有硬件和安装规则
• 没有合适而独立的性能研究计划
• 没有合适的质量保证组织
• 没有制定出系统测试计划
• more

影响项目开发成败的性能方面的问题：

• 最终用户没有确定出性能需求
• 未收集与性能相关的数据
• 没有确定性能开销
• 所期望的通信速率未能得到证实
• 未采用任何用以度量处理时间的机制或处理数量未得到证实
• 未采用任何评估手段来保证能够处理所要求的吞吐量
• 未采用任何评估手段来保证硬件上能够满足处理的需要
• 没有性能模型
• more
  　

附A：

风险承担者列表：