软件架构评估指导书

1.概述
我们常说软件架构是软件项目取得成功的关键要素。那么什么是软件架构呢？SEI认为一个程序或计算机系统的软件架构是指此系统的一个或多个结构，一个系统包含多个组件以及这些组件的外部可见属性和各组件之间的关系。“外部可见”属性是指其他组件使用该组件时的假设，如它提供的服务、性能特征、错误处理、共享资源的使用等。
通俗意义讲，软件架构，就如同建筑图纸一样，它规划了整个建筑的框架。软件架构是软件的设计蓝图，是软件的体系结构，它把软件的各个部分通过约定的契约（接口）有机的组合起来，形成整体。
架构如此重要，那么确保选择和设计正确的架构也变得更加关键。架构评估是一种产品的验证形式，就像软件测试是一种代码验证形式一样。架构评估可以在不同阶段不同时期进行，它可以在规划架构或权衡候选架构时（即选择技术备选方案）时进行，也可以在初步的架构决策完成之后详细的设计开始之前进行；评估也可以在整个系统创建之后进行，此时主要是进行再工程或资产挖掘。架构评估的输出依赖于所执行的阶段。
必须指定足够的设计决策以便于分析需求和质量属性目标的实现。架构的决策制订的越多，越能精确的执行评估。但另一方面，决策制订的越多，越难以更改。

2.工作流程
2.1确定架构评估方向
评估架构需要选择评估的要素，明确评估的关注点。例如：关注质量还是进度。诚然，质量和进度都是SE应该关注的，但在实际操作过程中，往往需要在质量或进度之间做出取舍。如何平衡两者之间的关系，是SE的职责之一。通常意义将，市场紧迫意义强，属于抢占市场型的产品，往往要在质量上做出一定的牺牲，软件架构以能满足当前需要为出发点；而那些属于长期型、需求不稳定、产品可塑性较大的产品，关注架构质量更具有意义。

2.2明确架构需要满足的行为需求和质量目标
系统的业务目标导致了特殊的行为需求和质量属性目标。评估前必须明确架构支持那些行为和质量属性目标，以及这些质量属性目标支持那些业务目标。例如：如果业务目标是系统将长期存在，可维护性就是一个重要的质量属性目标。必须将重要的质量目标具体化，也就是说质量目标必须具有可衡量性，架构评估必须提供可以参考的证据。架构评估必须考虑风险的影响，任何一个评估要素如果风险等级为高，则该评估要素必须予以重点关注。

2.3选择架构评估要素
选择架构评估要素之前，要明确架构的利益相关者；明确技术方案的需求，选择可以验证的评估要素。例如：
l 运行效率；
2 资源占用率
3 可维护性
4 可扩展性
5 开发效率
6 稳定性
7 需求可变性
8 可重用性
与利益相关者共同确定架构关注点和要素，并寻求共同期望的目标。通常我们建议提供checklist，并提供明确的计分标准。也可以通过在checklist给出权重，评估者直接给出通过与否的建议。对于重要的评估要素，比如：性能等可以采取一票否决制。系统的架构代表了一组最早的设计决策，最难修改，同时也最难保证正确。质量目标要考虑 1）支持产品的质量目标；2）随着时间的发展支持产品的预期发展。

2.4选择架构评估方法（软件架构实践）
业界有很多架构的评估方法，介绍几种常用的方法。
ATAM架构平衡分析方法（architecture trade-off analysis method，atam）
是一种基于场景的架构评估方法，重点考察系统的质量目标。它的输出包括：
一系列场景，表示利益相关者对此系统和架构最理想的用法和质量型目标。
一颗工具书，将各个场景分配到被评估系统的架构所支持的各质量属性。
专业分析结构，包括对敏感点的显示识别、折中方案和其他绝对或可能会影响所要求的质量属性的架构据测。通常需要三整天以及一些准备和初步的调研时间。

ARID中间设计的主动评审（active reviews for intermediate designs, arid）
是一种综合了ADR主动设计陪你更深哲学和ATAM和SAAM中基于场景的分析方法的混合设计评审技术。它是在早期或概念阶段业绩在其完全文档化之前创建的，用来评估部分设计。它的工作方式是为了设计召集利益县官这，让他们选择一组能有效表达其使用设计方式的场景，然后通过代码或微代码通过设计实现每个场景。

主动设计评估（active design reviews, adr）
该技术主要用于正在构造的架构。它的原理是由利益相关者评审描述组件所提供的接口设计的文档，但要求利益相关者完成所有练习，这些练习会强迫他们实际的使用文档。

2.5软件架构实践的选择
根据所处阶段、目标等的不同选择适用于自己的架构评估实践。架构评估实践的选择表如下：

场景\方法 ATAM ARID ADR 阶段

输出

目标

范围

3.架构评估的风险
错误的人员参加评估；参与架构评估的应该是架构的利益相关者和对架构有充分认识的人员。

架构的设计者完全主导评估；这个风险主要源于以下因素：
A. 参与人员没有足够的时间了解；
B. 参与人员不是技术人员，无法了解技术细节；
C. 提供者过于强势，掩盖了所有不同意见；
D. 不注重事实。
3 对架构的风险估计不足
4 风险较大或存在问题的要素没有重新评估
5 生命周期中的错误时间进行评估；例如：当编码已经大规模开始，架构评估完全失去意义。
6 没有时间进行评估。
7 对评估进行错误解释。
8 没有数据支撑，仅凭一面之词。

更多推荐

架构评估内容详解

【架构师指南】总结分库分表的实现方案

微服务及技术栈介绍

深度介绍分布式系统原理与设计

应用架构之道：分离业务逻辑和技术细节

免责声明：

本公众号部分分享的资料来自网络收集和整理，所有文字和图片版权归属于原作者所有，且仅代表作者个人观点，与本公众号无关，文章仅供读者学习交流使用，并请自行核实相关内容，如文章内容涉及侵权，请联系后台管理员删除。