什么是进行轻量级体系结构评估的好方法？

我熟悉架构评估方法，例如技术架构权衡分析方法（ATAM）和面向业务的成本效益分析方法（CBAM）。但是，这些方法的规模相当大：它们规定了一些集思广益的会议，演示文稿，开发了许多描述折衷方案的方案等。尽管对于一定规模的项目很有用，但对于通常用于内部项目或桌面应用程序的项目却太大了由少数开发人员（或更少）开发的产品，即使它们很小，也有一些相当严格的质量约束（性能，可伸缩性，适应性）。

我过去使用的一种典型做法是让一名开发人员（或者如果一个团队有一个团队，则由架构师）提出应用程序的通用体系结构，然后与其他团队在白板上进行讨论，通常使用一些易于绘制和理解的伪UML表示法。这通常会导致反馈和体系结构上的某些迭代。但这往往过于非正式化，导致做出各种假设，这些假设后来可能变成错误的决定。

像ATAM方法通常迫使所有利益相关者深入思考的架构，直到每个人都至少在什么架构究竟同意导致讨论的。

有没有人有进行轻量级前期架构评估的经验？如果是这样，有什么好的做法？

轻量级评估的关键是在正确的时间评估正确的事物。我知道有两种方法可以有效地做到这一点。通过基于方案的评估，您可以使用质量属性方案和用例来驱动评估，而仅着眼于高优先级的质量属性。通过基于风险的评估，您可以识别风险，并让识别出的风险驱动您的架构设计活动。

我可以推荐两本书来探讨这两种（有点相关）的​​方法。

安东尼·拉坦兹（Anthony Lattanze）的软件密集型系统架构师介绍了以架构为中心的设计方法论，并涵盖了基于轻量场景的评估。您可能会在SEI的“质量属性”研讨会上认识到Lattanze，并且涉及类似的想法。

足够的软件体系结构：乔治·费尔班克斯（George Fairbanks）的风险驱动方法介绍了一种风险驱动方法，用于设计和评估软件系统的体系结构。如果您想预览，也可以在他的网站上找到一些免费章节。尽管本书中的原理可以立即应用，但是该方法并没有特定的方法，因此您需要结合其他领域的想法。我强烈推荐SEI的持续风险管理方法来识别/确定风险的优先级。

这些方法的基本思想是通过进行评估而不是等到最后就可以减少评估（和设计）的成本。虽然这肯定比在白板上讲话要重得多，但它的成本与完全成熟的ATAM相比并不昂贵。并且，如果您感到舒适，则可以挑选满足您特定需求的方法。

无论您使用哪种方法进行评估，总体思路都是相同的。

在你开始之前：

• 优先考虑质量属性方案或风险（如果您所拥有的只是非正式的）
• 明确定义可继续执行/不继续进行的决策（您如何知道架构“足够好”）
• 最新的架构描述（您正在评估的工件）

参加评估会议：

• 建筑师介绍了体系结构的概述
• 浏览视图，显示方案或风险如何得到满足
• 记录问题以便以后修复
• 角色和一般程序与Fagan检查（建筑师或作者，主持人，记录员）所使用的相似。
• 根据系统的大小，会话可能只花一两个小时。

会话结束后：

• 查看已发现的问题，并确定是否满足通过/不通过的条件。通常，需要进行大约3条评论才能得出所有结论。如果不满足，请继续完善和试验（或降低体系结构风险）。
• 这不是“全有还是全无”的评估-体系结构的不同部分可能“通过”，而其他部分仍需要改进。

为了帮助您了解基于场景的方法的外观，我在研究生院工作的一个顶峰项目提供了一些公共文档。该文档有些粗略，但是可以在ACDM上下文中提供一些基于方案的方法的示例。我们是一个由5人组成的团队，构建了一个典型的基于Web的应用程序，大约35个KLOC Java / GWT。

我喜欢非正式的白板讨论。我很喜欢只编写当今所需的应用程序部分，然后逐渐让该体系结构在实现期间出现。它更像是“找到体系结构”，而不是试图事先发明它。这种方法不需要太多的前期评估，并且可以帮助您将重点放在重要的方面（交付有效的软件）。

当然，如果您的非功能性需求（内存限制，响应时间，并发用户数等）需要它，则在实施系统时必须考虑到这一点。