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

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

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

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

〈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的比较

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

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

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

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

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

附A：

风险承担者列表：