一、基本定义

软件系统架构评估是在软件系统开发的特定阶段，一般是在架构设计完成以后，由专门的评估团队或利益相关方，根据一定的评估标准和方法，对软件系统架构的各个方面进行检查和评估。评估的内容包括架构的合理性、可行性、可扩展性、可维护性、性能、安全性等，旨在发现架构设计中潜在的问题和风险，为后续的开发工作提供指导和改进建议。

二、一般流程

软件系统架构评估通常遵循以下一般性流程。

评估准备

• 明确评估目标：确定评估是为了检查架构是否满足特定的业务需求，还是为了提高系统的性能、可用性等质量属性，或者是为了在多个架构方案中进行选择等。
• 组建评估团队：召集具有不同专业背景的人员，如架构师、开发人员、测试人员、项目经理、领域专家等，确保团队具有全面评估架构所需的知识和技能。
• 收集评估资料：收集软件系统的架构文档，包括总体架构设计文档、详细设计文档、模块划分文档等，以及相关的需求规格说明书、技术选型文档等，为评估提供依据。

架构理解

• 架构师讲解：由架构师向评估团队详细介绍软件系统架构的设计思路、整体结构、模块划分、接口设计、技术选型等方面的内容，使评估团队成员对架构有清晰的认识。
• 提问与讨论：评估团队成员针对架构描述进行提问，与架构师进行深入讨论，确保对架构的理解一致，同时发现可能存在的模糊或不明确的地方。

制定标准

• 选择评估方法：根据评估目标和软件系统的特点，选择适合的评估方法，例如调查问卷法、检查表法、度量法、场景法等，可以选择一种或多种组合。
• 确定评估标准：明确各项评估指标的具体标准和要求，例如性能指标，确定系统在不同负载下的响应时间、吞吐量的合格标准。

实施评估

• 运用评估方法：按照预定的评估方法和标准，对软件架构进行全面评估。例如，若采用检查表法，评估人员需要对照检查表中的各项内容逐一检查架构是否满足要求；若采用基于场景法，则需要针对每个场景分析架构的应对方式和效果。
• 记录评估结果：在评估过程中，详细记录发现的问题、优点以及相关的意见和建议，包括问题所在的具体位置、严重程度、可能产生的影响等信息，以便后续进行整理和分析。

分析报告

• 分析评估结果：对记录的评估结果进行汇总和分析，找出架构中存在的主要问题和风险，分析问题之间的相互关系以及对系统整体的影响程度，同时总结架构的优点和值得肯定的地方。
• 编写评估报告：将评估的过程和结果形成正式的评估报告，报告内容通常包括评估目标、评估方法、评估结果概述、详细的问题列表及分析、改进建议、架构整体评价等部分，为决策提供清晰、全面的参考依据。

反馈改进

• 向相关方反馈：将评估报告提交给项目的相关利益者，如项目团队成员、管理层等，通过会议或其他形式进行详细的汇报和沟通，确保各方对评估结果有充分的了解和认识。
• 制定改进计划：根据评估结果和反馈意见，项目团队共同制定架构的改进计划，明确改进的目标、具体措施、责任人以及时间节点，确保架构能够得到有效的优化和完善，以满足系统的业务需求和质量属性要求。

三、质量属性

软件系统架构的评估目标除了满足特定业务需求的功能性要求外，还有非功能性的方面。软件系统架构的质量属性就是指描述软件系统非功能方面特性的一组指标，用于衡量软件满足各种质量需求的程度。

常见的软件系统架构质量属性有下面几点，这些质量属性基本是每个架构都要考虑的：

• 性能：性能是衡量软件系统效率的关键指标，主要体现在系统处理事务的能力和速度上，通常用响应时间、吞吐量、资源利用率等指标来衡量。例如，一个在线购物系统在高并发场景下，需要确保商品搜索、下单等操作的响应时间在用户的可接受范围内，同时也能够处理大量的订单请求，以满足性能要求。
• 可靠性：可靠性指系统在规定条件和时间内，无故障地完成规定功能的能力，通常包括容错能力、恢复能力、错误处理机制等方面。例如，在航空交通管制系统，必须具备高度的可靠性，即使出现硬件故障或软件错误，也要保证系统继续稳定运行，避免出现安全事故。
• 可用性：可用性代表系统能够正常提供服务的时间比例，反映了系统的可访问情况，通过用平均无故障时间（MTBF）和平均修复时间（MTTR）来衡量。例如，银行的网上交易系统需要保证高可用性，确保用户在任何时候都能方便、快捷地进行转账、查询等操作，尽可能减少系统停机维护的时间。
• 可维护性：可维护性反映了对系统进行修改、升级和修复的难易程度。良好的可维护性有助于降低系统的维护成本和维护时间。例如，系统的代码结构清晰、模块划分合理、有良好的文档注释，开发人员能更容易理解和修改代码，当系统出现问题或需要增加新功能时，能够快速定位和解决问题。
• 可扩展性：可扩展性关乎系统应对业务增长和变化的能力，包含逻辑扩展和物理扩展两方面。逻辑扩展与可维护性有近似的含义，是系统可修改性的一部分。物理扩展一般包括水平扩展（增加服务器节点）和垂直扩展（提升单个服务器性能）。例如，随着社交媒体平台用户数量的不断增加，系统需要能够方便地扩展服务器资源，以支持更多的用户并发访问和新功能的添加，如增加新的社交互动功能或支持新的媒体格式。
• 安全性：安全性指保护系统免受未经授权的访问、攻击和数据泄露的能力，包括数据加密、用户认证与授权、访问控制、网络安全等方面。例如，电子商务系统需要确保用户的个人信息和支付信息安全，防止被黑客窃取或篡改，通过采用安全的通信协议、加密算法等措施来保障系统安全性。

此外还有一些质量属性，描述特定场景的质量需求：

• 可移植性：可移植性指系统能够在不同硬件平台、操作系统、数据库等环境中运行的能力，要求软件架构具有较高的独立性和兼容性。例如，一款跨平台的移动应用，需要在iOS和Android等不同的操作系统上都能稳定运行，并且具有相似的用户体验，这就要在架构设计时考虑到不同平台的特性，采用合适的技术和设计模式来实现。
• 可测试性：可测试性体现了软件系统是否易于测试，包括是否便于设计和执行测试用例，能否方便地观察系统的内部状态和输出结果等。例如，具有良好可测试性的系统，会提供清晰的接口和可访问的内部状态，使得测试人员能够方便地对各个模块和功能进行测试，准确判断系统是否满足预期要求。
• 可理解性：可理解性表示系统的架构、设计和代码等是否易于开发人员、维护人员以及其他相关人员理解。可理解性在一定程度上是可维护性的必要条件，具有良好可理解性的软件系统，其架构层次清晰、模块职责明确、代码结构规范且注释丰富，有助于团队成员之间沟通和协作，降低因人员变动或系统复杂性带来的理解成本。
• 互操作性：互操作性指系统与其他系统或组件进行交互和协作的能力。在分布式系统和企业级应用集成中，互操作性尤为重要。例如，企业的不同业务系统（如ERP系统、CRM系统等）需要通过良好的互操作性实现数据共享和流程协同，以提高企业的整体运营效率。
• 易用性：易用性指用户使用系统容易程度，包括界面友好度、操作便捷性、学习成本等方面。例如，一款优秀的办公软件，其界面设计简洁直观，用户能够快速上手，方便地进行文档编辑、格式设置等操作，降低用户的操作难度，提高工作效率。
• 合规性：合规性指系统需要符合相关的安全标准和法规要求，如数据保护法规、行业安全规范等。例如，医疗行业的软件系统需要遵循严格的医疗数据保护法规，确保患者的隐私信息得到安全保护；金融行业的软件则要满足一系列的安全合规标准，以防范金融风险和保障客户资金安全。
• 兼容性：兼容性指系统与其他软件、硬件、网络环境及相关标准的兼容程度。兼容性是一个较广泛的质量属性，根据兼容的目标与场景，可以体现在可移植性、互操作性、安全性、合规性等方面。

软件系统架构的质量属性并非一成不变的列表，以上只列举一些普遍适用的案例，一千个业务眼中有一千个质量属性，只要是业务需要的就是合理的，在进行系统架构评估时既要按图索骥避免漫无边际，又要因地制宜以免削足适履。

四、评估方法

常见的软件系统构架评估方法有调查问卷法、检查表法、度量法、场景法等，不同的评估方法各有优缺点和实施方式。

调查问卷法

• 实施方式：设计一系列与软件架构相关的问题，形成问卷。这些问题涵盖架构的各个方面，如架构的设计原则、模块划分、接口设计、性能、可维护性等。然后将问卷分发给利益相关者，如架构师、开发人员、测试人员、用户等，收集他们的反馈和意见。最后对问卷结果进行统计和分析，了解各方对软件架构的评估和看法，发现潜在的问题和关注点。
• 适用场景：适用于需要快速获取各方对架构的初步印象和反馈，以及在项目的不同阶段了解利益相关者对架构的满意度。
• 优点：简单易行，能够广泛地收集不同角色的意见，成本较低。
• 缺点：结果受主观因素影响较大，回答的深度和准确度可能有限。

检查表法

• 实施方式：依据软件架构的最佳实践、行业标准和以往项目的经验，制定详细的检查表，列出架构应该满足的各种标准和要求。检查表中包含一系列具体的检查项，例如，检查架构是否遵循单一职责原则、是否存在高内聚低耦合的模块结构、数据库设计是否满足范式要求等。评估人员按照检查表中的项目逐一进行检查，记录架构满足或不满足各项要求的情况，从而发现架构中存在的不符合规范或潜在风险的地方。
• 适用场景：适用于对架构进行全面、系统的检查，尤其适用于有明确的架构规范和标准要求的项目。
• 优点：具体系统性和全面性，能够确保评估覆盖架构的关键方面，减少遗漏。
• 缺点：检查表的制定需要丰富的经验和专业知识，且可能无法完全适应每个特定项目的需求。

度量法

• 实施方式：定义一系列与软件架构相关的度量指标，如模块的耦合度、内聚度、代码行数、类的层次深度等。通过使用专门的工具或手动分析代码和架构文档，收集这些度量指标的数据。然后根据预先设定的标准或行业基准，对这些数据进行分析和评估，判断架构的质量。例如，如果某个模块的耦合度指标过高，说明该模块与其他模块的依赖关系过于复杂，可能影响系统的可维护性和可扩展性。
• 适用场景：适用于对架构的量化分析，尤其适用于需要对多个架构方案进行比较或对架构的演化进行长期跟踪的情况。
• 优点：提供了客观、量化的数据支持，能够更准确地评估架构的质量，便于进行比较和趋势分析。
• 缺点：度量指标的选择和定义需要谨慎，而且有些质量属性难以用简单的指标来衡量，可能会忽略一些非量化的重要因素。

场景法

• 实施方式：设计一系列代表系统典型使用场景的用例或场景描述，包括正常情况和异常情况。通过分析系统架构在这些场景下的表现，评估其是否能够满足功能性和非功能性方面的需求。可以采用模拟、建模或实际运行等方式来验证系统在各种场景下的行为。
• 适用场景：适用于需要深入评估架构在满足各种质量属性和业务需求方面的能力，特别是对于复杂的、对质量属性要求较高的软件系统。
• 优点：能够紧密结合业务需求和质量属性，全面评估架构的优缺点，有助于发现架构中潜在问题和权衡关系。
• 缺点：实施过程相对复杂，需要较多的时间和专业知识，对评估人员要求较高。

基于场景的软件系统架构评估方法主要有SAAM和ATAM两种。

SAAM（Scenarios-based Architecture Analysis Method，基于场景的架构分析方法）的基本特点是把任何形式的质量属性都具体化为场景，输入问题描述、需求声明和架构描述，通过分析架构对特定场景的支持程度来判断架构的优劣。

SAAM分析评估架构的过程包括5个步骤，即场景开发、架构描述、单个场景评估、场景交互和总体评估。

• 场景开发：确定与系统相关的各种场景，这些场景将用于评估架构对不同需求的满足程度。
• 架构描述：以一种清晰、准确且易于理解的方式描述系统的架构，以便评估人员对架构有一个全面的认识。
• 单个场景评估：针对每个场景，评估架构是否能够有效地支持该场景的实现，并确定架构在满足该场景需求时的优点和不足。
• 场景交互：考虑不同场景之间的相互影响和交互，评估架构在处理多个场景并发或顺序执行时的表现。
• 总体评估：综合前面各个步骤的评估结果，对架构的整体质量和适用性做出最终的判断，并提出改进建议。

SAAM可以帮助架构师们及时发现架构的潜在问题，特别是在评估架构对需求变化的适应性方面具有很好的效果，适用于各种规模和类型的软件系统，尤其是在需求不确定或经常变化的项目中。

ATAM（Architeture Tradeoff Analysis Method，架构权衡分析方法）是在SAAM的基础上发展起来的，主要针对性能、安全性、可用性、可修改性等，一般在系统开发之前，对这些质量属性进行评价和折中。

ATAM的目标是在考虑多个相互影响的质量属性的情况下，从原则上提供一种理解软件架构的能力的方法。ATAM被分为4个主要阶段，分别是场景和需求收集、架构视图和场景实现、属性模型构造和分析、权衡和折中。

• 场景和需求收集：此阶段的主要目标是全面收集系统相关的各种信息，包括利益相关者的需求、系统的功能需求以及最重要的质量属性需求，并将这些需求以场景的形式具体地描述出来，为后续的架构评估提供基础。
• 架构视图和场景实现：该阶段旨在将系统的架构以多种视图的形式展示出来，并说明这些架构如何实现之前收集到的场景，使评估人员能够直观地理解架构与需求之间的关系。
• 属性模型构造和分析：这个阶段的核心目标是针对系统的各种质量属性，构建相应的分析模型，并运用这些模型对架构进行深入分析，以评估架构在满足质量属性方面的表现。
• 权衡和折中：此阶段的主要目标是在多个质量属性之间进行权衡和决策，找到一个能够在整体上最优地满足系统需求的架构方案，同时明确不同质量属性之间的相互影响和制约关系。

ATAM适用于大型复杂软件系统的架构评估，特别是在项目初期需要对多种架构方案进行比较和选择，以及在系统演进过程中需要对架构进行重大调整时，帮助团队在不同质量属性之间做出合理的权衡决策。