从20世纪90年代开始，由于系统架构的全方位兴起（例如面向对象的架构技术、构 件技术、架构与设计模式等），越来越多的从业人员认识到提高架构和设计质量的重要性。 这使得架构评审得到了飞跃式的演化。通过近十几年的发展，架构评审己经有了长足的进 步。我们现在可以看到业界许多体系化的架构评审方法和评审技术，例如：SAAM、ATAM、 SAAMCS、CBAM、ARID、SPE、SAAMER、SAEM、SBAR、EASSMK ALPSft/^。
如此之多的评审方法和技术，有其各自的应用场合和质量关注点。那么在现实中，如 果面对一个系统或者一个子系统要求我们对其进行一次架构评审，到底应该选择怎样的评 审方法或评审技术来进行操作呢？这个问题会引发如下一连串的问题。
•架构评审的总目标应该是什么？
•架构评审应该邀请哪些人参加？
•为了进行架构评审，我们需要搜集和分析哪些系统架构相关的信息或文档？
•架构评审应该遵循怎样的流程或步骤？
•进行架构评审时，应该问一些怎样的问题？应该验证哪些方面？
•评审中需要使用怎样的模板进行工作？
•评审结束时应该有哪些必要的总结信息？
在详细探讨上述问题前，我们可以先来看看如图6-1所示的这个系统架构评审概念模型。
.png)
从该系统架构评审概念模型中，我们可以看到一个体系化的系统架构评审，有如下几 个主要的方面和阶段：
需要确定架构评审的约束条件，这其实就是架构评审工作的主要目标要求；并与 Stakeholders 一起最终确定评审的范围和重点。
根据评审的目标要求和评审重点，确定架构评审主要参与者与时间安排；同时确定 进行评审的主要评审方法或评审技术，最终形成评审计划。
根据确定的评审目标及评审方法和技术，与评审主要参与者一起确定评审需要的输 入信息和输入文档。
根据确定的评审方法或评审技术的流程要求进行评审工作。
在实现评审目标的前提下，产生相应的最终评审输出。
将该评审概念模型进一步分解，就可以看到如图6-2所示的更加详细的评审过程流程, 我们称之为ARP架构评审流程（Architecture Review Process)D
.png)
6.1架构评审目标确定
我们首先来看看哪些人会关注系统的质童，这些人也是我们常说的所谓Stakeholders: 系统开发的出资方、最终用户、产品线/产品管理人员、公司技术管理人员、系统架构和设 计人员、系统开发人员、系统维护人员、子系统或构件的提供商、产品销售人员、产品支 持人员、流程管理人员等。这么多不同的Stakeholders所关注的问题也大为不同。例如有 些Stakeholders关注系统功能性质童；有些Stakeholders关注非功能性质量；有些对产品 的发展前景（对系统架构来讲，可能是可修改、可替换、可扩展能力等）非常关注。
通常促使对一个系统架构进行评审，主要是由于这些Stakeholders对正在构建中的系 统心里没有足够的信心。尤其是在技术或架构方面，他们并不知道自己所关心的问题是否被架构很好地解决；系统架构人员面临管理层的压力，他们也希望能够利用评审来确保自 己构建的架构质量，同时为自己说服管理层做出某些让步创造一次沟通机会；除此之外， 由于公司内部的系统开发流程或规章制度的要求，也会造就了项目或产品开发必须在其特 定阶段进行架构和设计评审。
可以看出各个Stakeholders对系统架构的侧重点大相径庭。这样的情况也就自然而然 造成我们在接收架构评审请求时，确定的评审目标也会大不一样。一般来说，我们可以这些目标分为下面几种类型：
•验证架构和设计的和规性。其主要目的就是检验系统架构是否满足了国际、国家、 行业的标准、法规和流程。
•增进架构和设计的沟通交流。这可以包括非技术背景的stakeholders (例如：管理 层、销售人员)和系统架构人员深入交流系统架构的详细细节，从而避免因为沟通 不畅所导致的担忧；便于利用评审的机会让Stakeholders和架构设计人员进行有关 架构及设计抉择的沟通’从而在理解的基础上达成一致或妥协。
♦评估架构和设计的质量。这包括：架构是否圓满地完成了功能的需要；架构是否为 未来增补的需求提供了可扩展空间；需求中明确要求的那些特定的非功能性（例如： safety、performance)的要求是否在架构中得到合理的考虑和解决；是否有什么悬 而未决的架构及设计抉择；架构和设计在实现中是否可行；为了实现架构和设计而 选择的技术实现手段是否可行或有效等。
•发现架构和设计的改进点。例如：哪些架构和设计方面可以进行进一步的优化以及 这种优化的成本和代价；以怎样的原則或度量方式来衡量改进的程度；识别系统架 构和设计中的错误所带来的危险等。
由于评审目标来自不同的Stakeholders,他们各自的侧重点又属于上述不同类型。这 就要求评审人员必须在评审工作开始前，根据评审总体目标与相应的stakeholders —起精 确定义此次评审的重点。注意：确定清晰的评审重点是评审成功的一个重要约束条件。例 如我们通常可以让Stakeholders回答类似下面的问题来进行提示和澄淸：
•此次架构和设计评审包括系统的哪些部分？是整个系统，还是某些子系统？是否包 括硬件系统、通信网络等？
•评审中要覆盖系统整个的需求，还是选定那些特定的关键需求？
•评审中为了评估各种架构及设计抉择是否满足需求，需要评审所有的架构及设计抉 择，还是选择那些关键的架构抉择？
•是否要将所有的架构和设计结果进行深入的评估？架构评审要达到怎样的纵向深度？
经过这样一系列的工作后，我们已经完全澄清了此次评审的目标，并且清晰而一致地 勾画出评审的重点或范围。例如一个关于评审目标简单的例子可以这样来表述：我们已经 知道此次评审是为了解决最终用户（评审发起人）对系统性能的担忧（评审目标）而进行 的一次有关整个系统架构中与性能相关（评审重点）的那些架构及设计抉择的考童评审。
6.2架构评审计划制定
架构评审目标和评审重点确定后，就可以开始进行评审的准备工作了。首先，需要在 人员上进行准备。通常，参与评审的人有这样的三种类型：
•评审组成员：这可以包括主评审员（Lead Reviewer)、辅助评审员（Reviewer)和 观察员（Observer)。一般系统架构评审，需要双数配对进行工作，一个主评审员 结合一个普通评审员。这样做的主要目的是方便进行对比交叉验证。如果是针对系 统内各个子系统进行评审’对每个子系统的评审需要一主一辅搭配进行。另外，任 何重点问题的评判或裁决只允许由主评审员与Stakeholders进行交流。经常我们也 会遇到有观察员参加的评审，这些观察员可以来自评审方，也可以来自被评审方的 学习人员.
• Stakeholders或其代表：这些评审参与者主要是那些关注系统各方面质量的人员。
例如：最终用户可能对产品是否满足功能的要求及系统性能这两个方面非常关注。
•参加面谈和校验的人员：这些人员通常参与了由评审小组组织的各种面谈或验证活 动的人员。通过面谈或验证活动，他们可以向评审组提供最为真实可信的系统开发信 息。例如：系统测试人员可以帮助验证系统的性能是否满足特定的要求；系统架构组 成员可以向评审组解释为了某个特定质量要求，系统架构所进行的架构手段抉择。
评审方法或评审技术的选择，是制定评审计划的第二个重要步骤。由于Stakeholders 侧重点不同，要进行的架构评审也有着明显的侧重，可选用的评审方法或评审技术也就各 不相同（我们会在第6.4节中，谈到那些可选用的评审方法或评审技术）。基于评审所选定 的方法或技术，评审时间和进度安排也不尽相同。例如一个针对系统性能的评审，我们可 选用“SPE (Software Performance Engineering)”软件绩效工程评审方法，而“SPE方 法在评审时间和进度安排方面与“SBAR (Scenario-Based Architecture Reengineering)’， 基于场景的评审方法大不相同。
评审人员与评审方法的确定，已经为我们制定评审计划做好了铺垫。根据选定的评审 方法，评审进行中的重要活动（不同的评审方法和技术有其不同的评审活动）也就可以完 全，定下来。最后，我们要安排一个评审时间进度表。根据现实中发生的架构评审的统计 显示，一般会有如下几种评审类型（根据系统复杂度、技术成熟度等的不同，评审工作量 会进行相应的上下调整）。
•全面评审：一个完整系统的架构评审，需要6~8人，约3〜4周的时间。
•快速评审：子系统级的架构评审，通常需要2~4人，约2周的时间。
重点评审：系统范围内，选择重点问题（例如系统可靠性）进行评审，通常需要2〜4 人，约1-2周的时间。
•决策评审：一个系统全局范围内重大决策（项目继续进行或者停止），需要6~8人， 约3~4周的评审时间。
■ 6.3架构评审输入收集
在架构评审中，我们不单单要和各方进行口头的交流。更为重要的是，我们需要看到 落实在文档中的那些证据。识别这些重要的架构评审输入信息，对架构评审的成败有着重 要的影响。
在系统架构评审开始前，我们通常会从如图6-3所示的几个方面搜集相应的文档*作 为我们进行评审的依据。
.png)
输入1:系统描述
为了使系统架构评审人员能够淸晰地看到该系统开发的背景，系统描述需要淸晰记录 “为什么要开发该系统”或“希望系统完成怎样的使命”等。一个典型的系统描述一般会包
含下述信息。
商业功能：该系统的开发对一个商业公司或组织有着怎样的功能方面的便捷；该系 统的开发是否隶属于商业产品战略的一部分等。
•最终用户：该系统的最终用户有哪些；这些用户的要求是怎样的。
系统功能概述：该系统应该提供哪些主要的功能；是否需要和其他应用协作；系统 应该提供怎样的外部接口；用户和系统有哪些主要的交互动作等。
输入2:产品战略及产品计划描述
一个产品战略往往是依赖于市场调研和分析后的结果来制定的。这样的产品战略才能 真正代表市场中最终用户的需要。根据竞争对手的情况（例如产品分布、产品优势/劣势等） 及当前自身所处的市场竞争位置，参照市场竞争环境和竞争对手的产品，产品战略通常会 规划一个产品或产品家族在市场上的定位。
竞争定位：该系统是为了占领市场的哪一个位置或哪一部分市场份額。
竞争原則：该系统取得市场竞争力的原则，例如：依赖价格优势、依赖质量优势
制定产品战略的下一个步驟，就是要制作详细的产品计划，这包括：
•产品/产品线路线图：规划未来产品的演化路径、产品家族成员的生命周期、产品的 发布时间及发布版本等。
技术及经济因素：进行投入及产出分析、定价分析、技术演化路线图、技术能力培 养计划等。
架构评审之所以需要考虑产品战略及产品计划的要求，就是因为这些战略层面的指导 原则会严重影响产品对架构的要求，这也是一个系统架构存在的特定背景之一。系统架构 是否满足产品战略及产品计划的要求，也是我们评审的一个衡量标准。
输入3:需求描述
作为架构评审的一个最基本的输入，“需求描述”是我们进行架构质量评判的一个重要准 绳。我们都知道，一个系统架构其实就是以技术的表达方式，来讲述那些需求是如何被实现的。
IEEE STD 610.12.1990曾经定义过下述需求，这也就是我们希望看到的评审输入。
* 功能需求：“It specifies a function that a system or system component must be able to perform, without taking physical constraints into consideration”。简而言之， 就是系统必需提供的服务或功能，及其相应必须的榆入和输出。
•设计需求：“It specifies or constrains the design of a system or system component”。架构期间或系统设计阶段必须遵循的规约。
* 接 口需求：“It specifies an external item with which a system or system component must interact, or that sets forth constrains on formats, timing, or other factors caused by such an interaction"0系统接口必需遵循的要求。
* 实现需求：“It specifies or constrains the coding or construction of a system or system component"0编码实现阶段的要求。
* 非功能性需求：“It imposes conditions on a functional requirement; for example, a requirement that specifies the speed, accuracy, or memory usage with which a given function must be performed^在功能需求之上所加的一些条件，例如速度、 精确性、内存容量等。
一物理需求：“it specifies a physical characteristic that a system or system component must possess; for example, material, shape, weight”。物理特性方面 的需求，例如材料、形状、重量等。
在实践中，我们往往拿不到这么完整清晰系统化的需求描述文档。但是，需求的分类 可以在很大程度上帮助我们在后续的评审中有意识地从各个Stakeholders那里澄淸上述需求。
输入4:重点需求描述
“需求描述”只是代表了各个Stakeholders的关注点，这些关注点是组成我们评审准 尺的基础。但是，这些关注点中，有些是与系统架构层面紧密相关，有些则不是架构所应 考虑的问题。有时候，一些需要重点关注的问题，却没有在“需求描述”中描述出来或者 在行文中只是轻描淡写地进行了表述。所以我们应该将这些需求进行提炼并形成系统化、 有重点的描述，即所谓的“重点需求描述”《必须清晰而有重点地细化Stakeholders的需 求，这将会是后续进行重点评审的工作。如果只是泛泛地走一遍架构评审过程，将无益于 解决Stakeholders的问题和疑虑。
输入5:架构描述
作为架构评审最重要的输入信息之一，系统架构描述将帮助评审人员识别 Stakeholders所提出需求的技术实现手段。架构描述需要全面回答解决问题的各种方法和 步骤，尤其重要的是，它需要记录为实现需求所做出的技术方面的架构及设计抉择。
但是，在现实中进行架构评审时，我们经常看到的架构描述文档，要么太过空泛或抽 象，要么太过细节层面的设计文档。这样的文档并没有提供足够的信息供我们理解系统架 构构建是怎样满足Stakeholders的需求。这就要求我们在架构评审过程中不断地收集和汇 总相关的架构信息。通常我们会以不同的视角来收集和整理架构信息。例如：我们可以以 “系统性能”为一个架构视角，在评审过程中，从系统硬件分布和配置信息、线程及优先级 设计规约、系统接受事件的排序或调度等方面来收集证据，帮助我们理解系统架构是如何 保障系统性能的要求以及做出了哪些架构抉择。
输入6:架构抉择描述
架构描述帮助我们理解了架构人员在进行系统架构构建时最终采用了怎样的方式来解
决问题，从而来满足业务需求。但是•除了架构描述外，如果我们在进行评审前就可以
拿到一份全系统范围内所有架构及设计抉择的汇总表，即所谓的“架构抉择描述”，将非常有 利于后续验证这些抉择是否真正符合要求。因为“架构描述”并没有告诉我们架构人员为 了构建系统架构所经历的痛苦抉择过程，评审人员也并不知道系统架构中哪些是这些痛苦选择的位置。例如：为了解决整个系统的性能问题，经过仔细考虑，架构人员计划在子系 统A和D中’都增加一个构件’该构件准备“使用中央资源Scheduling方法，而不采用 资源Queuing的方式来进行资源管理”，这就是一个架构及设计抉择。
输入7:经验使用点
随着系统架构方面的发展’大量的最佳经验和实践已经总结出来并被很多系统架构人 员所广泛复用（例如：架构原则、架构风格、设计模式、参考架构模型等）。如果在进行架 构评审前，我们能够获取一份有关该系统所使用的经验汇总，将非常有利于评审人员理解 和衡量该系统的架构质量。因为复用这些最佳实践的目的，往往是为了经典而有效地解决 问题。这也自然而然地成为评审人员可以重点评审和验证的一些架构关键点。
输入8:架构/设计指南和规范
在有关系统架构的描述性文档中，除了架构描述、架构抉择描述之外，为了对架构构 建和后续设计工作进行强制约束，还会有一份“架构/设计指南和规范”文档。一般来讲，“架构/设计指南和规范”是公司范围内的一份规范性文档，并不是为每个项目或产品定制 制作的。但是它的约束性也是评审人员需要参考的重要输入信息之一。
架构、设计及编码规则。例如：构件、对象、接口的命名规则接口调用规则、message 或数据格式规范、异常处理规则、存取控制规則等。
公共机制或服务规范。例如：邮件服务、共享内存管理等。
数据库及存储设计规范。
测试规范。例如：测试环境、测试手段、测试工具等。
文档及格式规范。
架构控制流程。
输入9:系统相关证据
评审方法和评审技术有时会需要一些相关的证据，从而帮助验证那些关键但无法切实 验证的方面。这些证据包括：
•可行性研究：该技术报告有力地证明了架构抉择的动态选择和验证过程。可行性报 告往往告诉评审人员，架构组为了验证某些特定的需求是否可以实现而记录的探索 性验证文档。
•系统原型：评审人员可以在系统原型的帮助下，验证那些难以从纸面或推理得出的 验证性评审结果。例如：系统性能的评审往往只能从推理中得到部分的验证，一般 可以结合使用原型进行进一步的试验。
•会议记录、交流笔记：这些证据充分记录了当初架构人员在进行架构和设计过程中 的一些重要架构抉择和讨论过程，表明最终形成当前架构和设计的过程、曾经发生 过的问题和相应的解决方案。
•度量标准：反映了架构和设计过程中遵循的衡童体系。这也是评审人员以怎样的硬 性度量尺度分析架构和设计的依据。
输入10:系统标准及约束描述
“系统标准及约束描述”往往是伴随着用户需求而必须强制执行的一些硬性标准和约 束，这也是评审人员需要着重评审和规性（compliance)的一个重要标尺。这些标准和约 束可以包括：
•国际标准。例如：国际电报电话通行标准、国际财务准則。
•国家标准。例如：中国食品药品标准、美国财务准則。
•国家法律法规。例如：道路交通法。
•行业标准。例如：IEEE802、IS027001标准。
•公司标准。例如：架构和设计标准文档。
除了上述的标准之外，还有一些约束规则需要评审人员进行和规性（compliance)验 证。例如：
•系统架构与老系统的兼容或集成能力。
•系统架构应该尽量使用公司现有资产。
•社会政治方面的和规性。例如：系统架构应该避免使用“中华民国”这样的政治敏 感字眼；考虑到中国民族习惯，页面颜色不应该是红色配绿色；阿拉伯的文字阅读 习惯是自右向左阅读文字等^
•分布开发的因素。系统架构应该尽量保证分布式的开发。
在实践中，Stakeholders往往可能忽略了要求评审人员审核系统架构和设计的和规性。 但是，为了保证架构和设计的质量’评审人员应该衡量系统和规性的方方面面。
输入11:商业信息描述
一个大规模复杂系统的创建和维护，需要后期大量经济方面的支撑。例如：航空母舰 的建造费用并不是非常高’但是其每年的维护费用却高得惊人。这也就意味着，一个系统 架构和设计的过程，往往严重地受制于商业因素的影响。作为架构评审人员，我们应该考 虑到商业因素对我们的系统架构有着哪些重要的影响。这需要在架构评审初期明确得到商 业方面的信息输入，包括项目或产品用于设计和生产的投资、维护成本的预算、产品演化 所计划的费用、投资所带来的短、中长期R0丨计算等。
这些重要的商业输入信息可以帮助评审人员明确地验证一个系统架构及设计抉择的商 业成本和受益。每种架构抉择都有其短、中、长期的投入产出比。没有商业信息进行约束 的架构自然违反了商业的投资策略。业界已经有了专门针对商业问题进行架构评审的标准 技术’例如 SE丨的 CBAM (Cost Benefit Analysis Method)评审技术。
输入12:其他相关文档
为了尽可能多地理解一个系统架构的构建过程，其他辅助文档和信息对评审人员也会 有帮助，例如：
•项目/产品组织结构文档：可以表述架构、设计、测试等人员的职位、职责、关系分 布的信息。
•员工个人信息：作为沟通的基础，员工个人信息能够有效提升针对个人特点的沟通
效率。
•过程性文档：例如，项目过程中的风险管理文档可以有效地帮助评审人员回顾项目 进行中发生过的风险及其识别和应对方法。
6.4架构评审方法和技术选择
系统架构评审在目标明确后，会制定一份评审计划。评审计划中的一个重要的动作就 是根据评审目标和评审重点，确定将要使用的架构评审方法或评审技术。一个评审方法或 技术基本上会包括：评审人员的角色划分、评审时的步骤或动作、所使用的分析技术、所 使用的模板和标注方式等。只有在确立评审方法和技术后，后续的评审输入信息的搜集、 评审的进行以及评审的输出都是完全围绕着将要使用的评审方法和技术而展开的。
谈到评审方法和评审技术，业界虽然早在20世纪80年代后期就开始尝试使用各种不 同的方法和技术进行系统架构评审。但是，直到20世纪90年代初期，在美国国防部专项 基础研究资金的大力推动下，卡内基梅隆大学软件工程研究所（SEI)在Len Bass、Paul Clements 和 RickKazman 的研究基础上，正式对外发布了 SAAM (Software Architecture Analysis Method)软件架构分析评审方法。这是业界第一个有着完整体系的实用架构分析评审技术（业界有很多重要的实践和标准都来自美国国防部和美国国家航天局，主要原因 是它们往往前瞻性地进行了大量大规模复杂系统的实践，这些实践后来成为了事实上的业 界标准)。随着SAAM奠定了架构分析评审基础，美国国家航天局等大量的机构也开始使用或研究系统架构分析评审技术，这标志着该领域开始走向繁荣。
经历近十几年的演化，虽然系统架构分析评审方法和技术己经有了长足的发展，但总 体来讲，还是基本上遵循了 Paul Clements、Rick Kazman和Mark Clein在1998年所指出的方向。系统架构分析评审方法和技术基本有三种类型：“提问技术”、“度量技术”和“混 合技术”。
提问技术（Questioning Technique)：这是一种定性方式的架构分析和评审方法。 主要通过问卷（questionnaire)、检查表（checklist)、场景（scenario)等方式来 分析和评价一个系统架构是否满足了各种质量方面的要求。提问技术主要是通过架 构体系各个视角的审视，通过经验或最佳实践来推測未来系统的行为。一般进行提 问评审时，系统还没有编码实现成为实际运行的系统。
度量技术（Measuring Technique):这是一种定量方式的架构分析和评审方法。通 常，使用这种技术往往是在一个系统已经基本编码完成或部分完成的情况下，应用 相应的度量手段或工具，对系统进行量化的分析和评价。度f技术可以包括运用原 型的方式来评测系统的性能在最大峰值输入时的表现；使用指标（Metrics)来定量 地衡f系统架构如何应对并发事件的处理能力；应用一些自动化工具来模拟和评测 系统内构件间的耦合程度和是否存在潜在的调用死锁等。
混合技术（Hybrid Technique):结合定量分析和定性分析的优点和长处，在架构评 审时混合使用多项提问技术和度量技术。在实践中，如果有些定性分析不能深入洞 悉，或者不能完全确定问題的症结，这时就可以结合使用定量分析的结果作为定性 的依据。而定量分析的前提其实就是带着需要定性的问趙进行的。这两者不能完全 剥离开，例如：我们可以定量分析系统范围内资源的调度和使用情况，这其实也部 分回答了 “系统的性能如何”这样一个定性的问題。
基于上述类型，比较有代表性的架构评审方法和评审技术包括：
• SAAM (Software Architecture Analysis Method)： 1993 年美国国防部出资，由 Len Bass、Paul Clements 和 Rick Kazman 提出，由 SEI 发布0
• ATAM (The Architecture Trade-Off Analysis Method)： 1998 年由 Paul Clements、
Rick Kazman 和 Mark Ctein 提出，由 SEI 发布。
• CBAM (Cost-Benefit Analysis Method)： 1993 年美国国防部出资，由 Len Bass、 Paul Clements 和 Rick Kazman 提出，由 SEI 发布。
• ARID (Active Reviews for Intermediate Designs)： 1998 年由 Paul Clements、Rick Kazman和MarkClein提出，由SEI发布，用于评审架构构建初期或架构半成品的评审技术。
• SPE (Software Performance Engineering)： 1995 年由 Smith and Williams 提出。
• PASA (Performance Assessment of Software Architectures)： 2002 年由 Smith 和Williams提出。
• RMA (Rate Monotonic Analysis )： 1993 年由 Klein M 和 Ralya T 等人提出。
• SAAMCS (SAAM Founded on Complex Scenarios) ： 1999 年由 N .Lassing 提出。
• SAEM(Software Architecture Evaluation Model )： 1998 年由丄C.Duenas 等人提出。
• SBAR (Scenario-Based Architecture Reengineering )： 1998 年由 P.O.Bengtsson等人提出。
在这些架构评审方法和评审技术中，有些是针对当前还没有一个完整的系统架构的情
况选用的评审技术，例如ARID (Active Reviews for Intermediate Designs)方法：有些是 评判当前架构中所采用的架构方法或架构设计抉择，例如CBAM (Cost-Benefit Analysis Method)方法：如果要求专门进行某种特定的质量要求（例如Performance)，则可以采 取 SPE (Software Performance Engineering), RMA (Rate Monotonic Analysis)等评审方法•
与此同时,还有大量的研究工作围绕着这些方法和技术展开。例如Dobrica和Niemela 共同进行的研究是对目前几种主要的评审技术进行透彻的分析和对比，他们的研究报告详 尽地阐述了各种架构评审技术的优缺点。通过此项研究成果，很大程度上帮助我们选择适合自身评审情况的评审技术。
如果从实战角度上来讲，目前各种机构或公司（诸如美国国防部、美国航天局、AT&T、 Nokia、Siemens、Lucent等）使用最为广泛的主要是下述三种主要的评审方法：“基于问卷、 场景和度量技术的混合型架构评审方法”、“基于问卷/检查表技术的提问式架构评审方法”以 及“基于问卷/检查表和度童技术的混合型评审方法”，下面我们对其进行逐一详细讲述。
方法一：基于问卷、场景和度量技术的混合型架构评审
当前，业界非常盛行参考应用基于场景技术的架构评审方法。其中，最为经典的莫过 于著名的ATAM架构分析和评审方法（虽然ATAM标榜自己是基于场景和度童技术的混合 型评审方法，但是ATAM还是以其擅长场景技术而著称)。我们可以参见SEI公布的ATAM 概念模型图，如图6-4所示。
.png)
如果从评审流程的角度上来讲，ATAM评审方法主要包含四个重要的阶段和九个核心 流程活动。现实中各个机构和公司架构评审实践过程时，在参考ATAM主要流程及活动的 基础上，也会或多或少地进行优化和改良，这主要体现在与问卷评审技术和度量评审技术 的结合上。目前应用ATAM进行评审时，大多会遵循如图6-5所示的流程和主要动作。
.png)
Phase 0：准备阶段(Partnership and Preparation)
此阶段是评审启动前的准备阶段。该阶段的主要任务是架构评审人员通过电话或 E-mail,与客户方的一些主要的Stakeholders进行初步的沟通。这种沟通的主要目的如下：
•首先，使客户方理解评审的大致过程及所使用的手段。
*其次，使评审人员明确需要进行评审的是什么样的系统以及一些系统相关的重要背
景信息。
•通过沟通，与客户方形成正式的评审协议。
•评审方组织形成评审团队，客户方预约Stakeholders及相关架构、设计和编码人员
的时间。
Phase 1 ：初始评估阶段(Initial Evaluation )
从这个阶段开始，就正式进入架构评审的执行阶段。该阶段的主要任务是与那些有技 术背景的Stakeholders进行交流，帮助评审人员深入分析和整理系统全局范围内那些最为 重要的、Stakeholders最为关注的、需要系统高质量并合理应对的场景。Initial Evaluation阶段会包括如下六个主要的核心活动。 ‘
①介绍ATAM评审方法：向Stakeholders介绍ATAM方法所需要进行的步骤和动作、 评审中使用的技术（例如Utility Tree技术（效用树）、架构方法和手段分析技术、场景头脑风暴技术 等）以及评审结束时相应的产出物（例如应对质量问题所使用的架构方法、Utility Tree、 排定优先级的场景、威胁或敏感点等）。基于这样全面的介绍，为整个架构评审设定目标并 展示预期的结果，从而与Stakeholders的认知达成一致。 ：
②介绍系统背景信息：客户代表向评审人员介绍该系统开发的主要商业背景和商业目 标。这包括系统商业运作背景、最高层面的系统功能需求、最高层面的质童要求（例如系 统架构构建时期需要考虑的质量因素、核心重点关注的质量要求等)。通过这样的系统背景 介绍，评审人员和所有Stakeholders对系统存在的大背景有了一个完整的认知-
③介绍系统架构和设计：通常由系统总架构师来给评审人员和Stakeholders全面介 绍当构和设计。这可以包括最高层面的系统架构概念（例如操作系统、硬件、 中间件:‘、通信网络等）、该系统与其他遗留系统的集成交互概念、架构中为了保证质量所使 用的重要方法和手段（例如架构原则、架构风格、设计模式等)、重大的架构及设计抉择点 (例f用第三方产品）、利用一些重要的质量要求场景来推演系统架构的实现能力、利用一些重要的发展演化场景来推演系统的适应能力、其他相关已经识别出的威胁或Open Issues等。这样全面的架构介绍，在很大程度上能够帮助评审人员探索和捕捉一些需要深 入验证和评审的问题。同时，全面的系统架构介绍在很大程度上促进了系统研发团队与其 他Stakeholders在系统当前进展情况上的认知一致。
④识别架构中保证质量的方法：系统总架构师进行的系统架构和设计介绍往往涵盖了 比较抽象层面的概念，可能从细节的程度上讲还不够深入。为了更加详细地识别整个架构 中保证质量所使用的方法，评审人员需要在架构组成员的帮助下，进一步识别架构中所使用的那些重童级方法。这包括为何使用3层架构风格、为什么使用watchdog和 publisher-subscriber设计模式、为何使用硬件热备份这样的冗余方法等这种识别的结果， 在很大程度上帮助评审人员理解了实现那些重要质量要求的架构方法。并且，评审人员的 脑海中已经清晰完整地建立了系统核心基线架构。
⑤创建质量Utility Tree（效用树）：经过前4个活动，评审人员已经明确了系统实现的总目标以 及架构人员是如何构建该系统架构的，并在一定程度上形成了完整的系统架构概念。但是， 直到目前为止，评审人员只是看到了当前的架构和设计，并收集整理出了一份有关系统应 该实现的质量要求详细清单。
第5个核心活动的主要目的，就是在该项目决策层（例如客户代表、职能经理、架构 组）的帮助下，识别和提炼出那些最为重要的质量要求及指标参数，并根据重要性和实现 的难度排定优先级。由于架构评审毕竟只有为数不多的几天时间，不可能在全局范围内对 任何细节质量要求进行全面的评审。在实践中，一般公司会主要针对最为关切的质量进行 分析和提炼。
创建质量Utility Tree活动是架构评审中极为重要的一个活动。该活动的完成质童直接 影响了评审的质量。在进行该活动时，一般采用构建Util丨ty Tree和分解为场景这样两个重 要的技术。
所谓的Utility Tree，是一个树状自顶向下结构的质量要求体系。Utility Tree的根可以 命名为“Utility”，其下面的树枝一般是通用的质量要求，如Performance、Modifiability. Security、Availability等。再往下就是系统特定的那些质量要求，如数据的延迟、资源使用、 软件出错、硬件或CPU替换等。底层的叶子就是那些识别和分析出来的场景（scenario)。 请参见如图6~6所示的一个Utility Tree例子。
Utility Tree 的最终产出是一些诸如 “Reduce storage latency on customer DB to < 200 ms” 和 “Network failure detected and recovered in <1.5 minutes” 等这样的场景a 在 utility Tree的识别中，这些场景主要是在评审组的启发下，由架构评审人员和项目决策人员共同完成。
.png)
识别Utility Tree中的场景主要遵循以下几个原则:
•必须是Stakeholders最为关切的、或者对系统架构有震撼性的那些质量要求。
•必须是完整、清晰、精准地表达了一个特定质量要求的场景。这包括诱因、背景、 应对的要求。
•搜集和识别的场景应该考虑系统正常使用的情节。例如：远端用户在正常工作时间 通过Web方式要求从系统数据库产生一张报表，时限不能超过5秒。
搜集和识别的场景必须考虑系统正常演化所带来的变化情节。例如：在未来增加一 个货币转換的系统功能模块，需要三个人天的工作量。
•搜集和识别的场景必须考虑系统处于非正常情况下（例如异常的流量压力、主服务 死机）的情节。
创建质量Utility Tree的最后一个工作，就是根据场景在项目决策人员和其他 Stakeholders眼中的重要程度，并结合架构人员认可的实现难度，对每个场景打分或定级 (通常可以考虑以10分制的打分方式，或以High、Medium、Low来定级），这样就会出现 “Add CORBA middleware in < 20 person-months”，场景的定级为（H, H)。通过完整的Utility Tree中所包含的各个场景的定级，我们就可以对所有的场景排定优先级队列。
⑥分析实现重要场景的架构和设计方法：从活动4中我们己经识别和汇总了那些为架 构构建所应用的方法和架构与设计抉择。第5个活动中我们通过识别、汇总，排定了那些 优先级较髙的质量要求的场景。从现在开始，评审人员需要在架构人员的帮助下，开始映 射和分析这些汇总的信息。
首先，评审人员会通过分析，映射出具体的质量要求场景是由哪些架构方法或架构与 设计抉择来完成的，在实践中，这需要架构人员在评审人员的指导下进行，并最玫形成映射表。 '
其次，针对优先级高的每项场景和相应采用的架构方法，评审人员需要结合自身经验 或技术领域经验（这里的领域是指实时系统领域、嵌入式系统领域等），事先准备好问卷， 对架构人员进行访谈。
架构人员面对场景和评审人员的一连串问题，详细解释采取目前架构方法和架构与设 计抉择的理由。必要时，架构人员可以使用相应的测试数据、模型推演、原型验证或模拟 工具来表明自己抉择的论证实际过程。
问卷和回答的形式最终会导导致讨论的展开，从而帮助评审人员就每个架构方法和架构 设计抉择搜集相应的 SWOT (Strength、Weakness、Opportunity、Threat),从而形成如图6>7所示的架构方法和架构设计抉择分析表。
架构评审的Initial Evaluation阶段，主要执行了上述六个主要动作。到现在为止，评
审人员、主要Stakeholders、项目决策层、系统架构人员都已经有了全面和系统的质童实 施体系的认知。
从上述六个流程活动来看，虽然基本上遵循了 ATAM中的瀑布式流程动作，但是-般 实际评审的过程往往与ATAM的流程有所不同，还需要对ATAM的操作进行调整并使之成 为一个循序渐进和迭代的过程。
.png)
•首先，为了弥补活动1〜活动4的不足，评审人员通常会参考一些客户方提供的架构 文档，作为交流理解的基础。然后利用事先准备好的问卷与Stakeholders进行交流， 再反过来进一步理解架构文档.这样可以有效地提高活动4(识别架构中保证质量 的方法）的工作效率。在进行活动5的工作时，甚至会参考一些商业信息作为重要 的评审输入信息。例如：参照商业信息中有关功能的路线图和财务计划，最终确定 未来会发生什么样的系统级变化。
•其次，活动4~活动6的工作在实际操作中也是一个迭代的过程。一般会采用与 Stakeholders和架构人员定期会议的机制，逐步澄淸系统架构中的方法和抉择，逐 渐淸晰重点质量场景，最终逐步完善活动6的汇总信息。在实际评审中执行这样操 作，其实原因很简单：现实中的架构人员不可能一次性把你想知道的架构方法和架 构设计抉择完整地告诉你；反而当你告诉他们客户的质量要求场景时，会提醒他们自己先前为解决这样的场景所运用的架构解决方法。与此相类似，Stakeholders也 不可能一下就把自己的质量要求和质量场景想得那样清楚、全面而详尽，也需要反 复多次地沟通和澄清，有时甚至是在评审人员和架构人员的提示和引导下， Stakeholders才会明确表示“系统性能要保证500个并发用户正常访问服务器时， Web页面的显示时间不能多于5秒”这样详细的质量场景描述。
•最后，在活动6操作时，大量采用“问卷”这种有预先准备的提问式技术对架构人 员进行提示和引导。如果只是采用传统的ATAM方式进行开放式的讨论，就会导致 经验式的工作方式。尤其是当评审那些重大架构设计抉择和方法时，往往是在评审人 员的引导下，需要架构人员运用“度量技术，，提供试验、模拟等方面的证据，而不仅 仅只是由架构人员说，或者只是看看文档后凭借评审人员自身的经验进行端测•
Phase 2：全面评估阶段(Complete Evaluation)
全面评估阶段（Complete Evaluation)主要有两个目的：首先，以Stakeholders的质 量要求为中心，最大程度地让所有的Stakeholders参与进来，检查、修正和补充Phase 1 阶段的质量Utility Tree:其次，用Phase 1阶段活动6形成的架构方法和架构设计抉择分 析表来推演和验证架构人员前期架构构建的工作，是否满足了所有stakeholders的那些重 要质量要求场景。全面评估阶段Complete Evaluation是一个评测架构质量的阶段，通常 有如下三个核心活动：
①头脑风暴和场景优先级排定
头脑风暴和场景优先级排定在整个评审过程中非常关键。项目决策层召开一个架构评 审中最大规模的会议，要求所有的架构评审人员和所有的stakeholders到场，例如系统出 资方、最终用户代表、架构方、系统服务管理方、系统实施方等所有系统相关人员.
会议首先会由评审人员介绍一下ATAM评审方法步骤，接着架构人员会简单介绍一下 目$系统架构的情况。然后，评审人员会将前期总结提炼出的质量utility Tree给参会人员 进行详细的解读。质量Utility Tree会成为Stakeholders关心的一个重点，因为这正是他们 要求的质量点。同时这也是一个启发思路的步骤，为后续的头脑风暴做好了铺垫。
接下来，评审人员会要求Stakeholders进入头脑风暴的过程。基于目前的质量Utility Tree的启迪作用，鼓励每个Stakeholders提出自己所关心的那些质量场景（无论这些场景 是否已经包含在目前的质量Utility Tree中）•这些场景与评审人员初创质量Utility Tree时 相仿，要求涵盖了系统正常使用的情景、系统正常演化所带来变化的情景、系统非正常情 况下的情景等。
经过一轮头脑风暴’评审人员己经搜集到很多的质量场景。接下来，就进入质量场景 优先级的排定过程。每个Stakeholders会分到质量场景总数30%的选票，例如我们共搜集 了 24个质量场景，那么每个Stakeholders就会得到8张选票，然后，Stakeholders可将 选票投给自己认为最重要的30%的质量场景。经过统计后，所有的质量场景就会得到一个 优先级的排序。通过这样一个收敛和排序的过程，我们会逐渐聚焦在那些最需要关注的重 要质量场景上，这是关键需求，也是评审的重点。
然后’在评审人员的引导下，将这些排定优先级的质量场景按照质量类别属性，放在 质量Utility Tree中相应的位置。在大多数情况下，Stakeholders的质量场景己经被架构人 员在Utility Tree中所涵盖。但是’通过这次头脑风暴，也会发现有些Utility Tree中的场景 表述得或许不准确甚至不对。当然，有可能个别的一些质量场景之前并没有被UtilityTree 所考虑，这正好是对架构工作的一次检验和修正。
经过这样一轮质量场景头脑风暴，现在评审人员手中的质量Utility Tree就已经是一个 完整的、被各方认可的、具有权威架构约束力的质童需求文档。这个完整的质量utility Tree 是我们架构评审最重要的结果之一。
②分析实现重要场景的架构和设计方法
质童场景头脑风暴会议介绍结束后，评审人员需要和架构人员坐在一起，对utility Tree 中那些新增加的或修改的质ft场景，逐一进行Phase 1阶段活动5的动作，即分析当前系 统架构中为了实现这些场景而使用的架构方法、架构设计抉择。最终形成的分析结果则是 架构构建完全匹配上Stakeholders所有的质量要求。该分析结果也成为最终版本的评审结果之一•
③展示评审结果
第二阶段的最后一个动作，就是要将此次的评审结果给Stakeholders做一次展示和介 绍，使各方都能看到最终的评审结果信息。展示的评审内容包括：
•质量 Utility Tree。
•排序后的质童场景。
•架构方法、架构设计抉择。
•架构中存在的 Strength、Weakness、Opportunity、Threat。
Phase 3：跟进阶段(Follow up)
架构评审结束后，需要向客户提交一份正式的书面评审报告。由于一般是管理职能经 理来看这份正式评审报告，他们一般希望看到评审是如何进行的、最终发现的问题、有哪 些威胁以及相应的改进机会，所以不能只是将评审过程中的文档进行简单汇总，还需要一 定的提炼。
作为职业评审人员，架构评审还应该向客户发一份调査问卷，以帮助评审方了解客户 对此次评审的满意程度及相应的意见和建议。
最后，此次评审的所有过程性文档需要存档保存，以便于日后的统计和复用。
方法二：基于问卷/检査表技术的提问式架构评审方法
基于问卷/检查表技术的架构评审方法是另外一种比较流行的、相对简单实用的评审方 法.许多机构和公司都有自己的架构评审问卷或检査表（就如同很多公司有自己的CMMI 评审问卷一样，不过这些问卷大多是保密的）。这种评审方法与Bosch J提出的经验式架构 评审非常相似，即以公司或机构的高级架构师、高级技术顾问的架构实践为基础，结合领 域内的经验总结出来的问卷和检查表„这里所谈到的领域经验，主要是指实时系统、嵌入式系统、电信系统、航空系统等专业领域。
正是由于上述原因，问卷/检査表的架构评审方法一般被大量地应用在行业特征明显、 系统情况相对固定的机构或公司里。例如工业自动化系统的开发公司，每个项目所产出产 品的应用领域都是工业自控方面的系统，并且其使用的底层硬件相近，选择的操作系统相 似，控制原理和控制逻辑也相仿。再例如车载系统的生产公司•绝大多数产品都是嵌入式 系统，面临的技术问题相近，需要克服的质量问题也大致相仿。这些领域的公司往往喜欢 用问卷/检查表这种经验式的、可复用的架构评审方法来评价一个系统的架构。
相比而言I问卷/检查表式的评审比基于场景的评审方式更简单，基本上由如图6-8所 示的五个核心活动组成。
.png)
1.确定评审范围
问卷/检查表的架构评审方法一般是公司和机构对系统全局范围内的情况进行的—种 评估式评审。所以，通常会要求评审所覆盖的系统架构更为全面。这就造成问卷/检查表的 评审范围通常比基于场景的评审范围要广„与基于场景的评审方法相似，问卷/检查表的评 审也需要强调一些重点’进行深入细致的评判。例如：这些重点可以是stakeholders所担心的可扩展能力，也可以是架构组所担心的容错能力。
架构文档及系统相关技术、商业文档的收集也是在这个活动中初步完成。后续文档的 搜集需要在评审进行中逐步挖掘整理。
2.分析架构文档
与基于场景的架构评审不同的是，在面对被评审方之前，要求架构评审人员仔细阅读 和分析现有的架构文档及其他技术支持文档。这样做的益处在于：首先，评审人员在文档 的帮助下，不受外界影响，独立构建出系统架构的初步概念：其次，有效评审了系统架构 文档的质量：另外，使后续的评审更有侧重性，即可以带着分析架构文档后的重点疑问进 行后续的评审工作。这样做虽然有很多优点，但是对评审人员的架构经验要求很高。
3.选择面谈人员
问卷/检査表的架构评审方法在进入评审动作前，需要严格选择面谈对象。面谈对象选 择的质量，会严重影响评审的质量。面谈的人员一般可以划为下述三种类型：
•系统需求相关人员：与系统功能和非功能性要求相关的人员。这可以包括系统出资 方、终端用户、需求工程师、各种职能经理等需求责任人。
•系统架构相关人员：系统总架构师、子系统架构师、高级技术经理等负责系统架构 的责任人。
•系统开发人员：高级程序员、技术专家、业务专家、系统测试等负责具体方面（例 如负责性能方面、负责安全机制方面等）的责任人。
面谈对象选定后，需要提交项目决策层，并由他们负责安排面谈时间。需要说明的是， 当前选定的面谈对象往往不是固定不变的，在实践操作中我们就会发现，我们面谈的对象 往往会不断增加’通常是由当前选定的对象逐步推荐而添加进面谈对象的队列当中。
4.进行面谈
面谈对象选定后’在与每个面谈对象进行面谈前，还需要根据面谈对象的不同而准备 不同的问卷。这个步骤是整个架构评审中非常关键的一个动作。我们可以参考下面问卷目 录的一部分来总结自己的问卷。
1. Requirements
2. Analysis & Design
3. Testing
4. Re-factoring
5. Object-Oriented Design
6. Introduction of new colleagues/contractors
7. Operating System
8. Threading
9. Communication
10. Error-Handling
11. Startup/Shutdown
12. Resource Management/Memory Usage
13 Performance
14. Stability
15. Shared HW Resources
16. Software-Hardware Integration
17. Real-time Constraints
18. Embedded Constraints
19. Constraints imposed through distribution
20. Evolution of existing architectures
在准备问卷时，还需要将评审人员所靠握的相应质量要求和分析出的问题结合进问卷。 举例来讲，如果我们今天面谈的对象是负责实时性(Real-time)要求最髙的子系统架构师 时，我们的问卷可能会是下面这样。
1 . Do you have timing constraints in your system (list these)?
2. What are those time-constrained actions?
3. Which actions are sporadic and which ones are periodic?
4. What is the time constraint of each action?
5. Are these actions independent of each other?
6. What is their dependency structure?
7. How should the system react in case of an action missing its time constraint?
8. Is it possible/reasonable to keep all time-constrained actions on a single CPU?
9. Is there any communication between several time-constrained actions?
10. Are there any non real-time activities in your system?
11. What are those activities/scenarios/requirements?
12. Is there any GUI involved which allows to operate the system?
13. Do you have to meet any integration with other systems (ERP: Enterprise Resource Planning like SAP, Web)?
14. Are there any future requirements related to this kind of integration?
15. Is there any interaction/message exchange of such activities with time-constrained actions?
进行面谈时，首先要求评审人员向面谈人员申明此次谈话只会记录相应的事实，而不 会记录这些事实是由谁提供的，这样可以打消面谈人员的政治压力。接着，以这些有针对 性的问卷为开始，引导面谈人员的思路并最终形成经验交流和探讨式的谈话，这样很容易使面谈人员逐渐放松情绪，能够就系统的顾虑、担忧、意见、建议等进行开放式的交流， 最终形成良好的合作。
在面谈中，经常会遇到有些不属于面谈者职责范围内的问题，或者面谈者无法提供相 关的细节。这时面谈者可以为评审人员指定熟悉相应情况的其他人员来补充信息•自然， 面谈人员的列表上不能遗漏本次访谈的补充面谈者，
每次面谈结束后，需要根据记录的笔记对本次面谈获取的信息进行整理，提高信息的 完整性和条理性。
5.分析和报告
当既定的所有面谈结束后，评审人员需要在评审组长的带领下，再次结合前几个步骒 中获取的需求、架构和技术文档等信息，结合面谈时暴露的问题，进行更加细致的分析. 这样做的目的就是将捜集到的问题进行进一步的考证和汇总^该分析工作是循序渐进的过 程，经常是在面谈进行的同时就可以展开^这是一个工作量比较大、线索复杂的过程》这 与基于场景的评审方法有着很大的区别。
问卷/检査表式的评审方法在分析结束后，要为Stakeholders展示最终的评审结果并向 客户提交一份正式的评审报告。当然，后续的客户满意度问卷、评审归档的动作是不可缺 少的，这与基于场最的评审没有什么区别.
需要说明的是，利用问卷啦查表式的技术进行架构评审，需要的时间往往比使用场景
的技术多很多。主要原因是问卷査表技术要求覆盖的面很广、需要有面谈人、需要进行 分析’是一种系统全方位权衡的评估方法•而基于场景的评审，往往是集中在一些主要核 心需求上的架构评审（ATAM评审最初是针对系统演化所带来的变化而研究的一种架构评 审技术)，这与问卷/检査表技术有着很大的区别。另外，由于时间的限制，问卷/检査表技 术所能评审到的架构深度，没有场景技术的评审那么深入„
方法三：基于问卷/检査表和度量技术的混合型评审方法
问卷/检查表和度量技术这种混合型的评审方法,其实就是为了弥补单纯问卷/检查表技
术深度的不足而产生的。目前应用这项评审技术的公司也非常多，尤其是美国国防部、 Nokia、AT&T等那种恃定的系统/产品生产开发机构。它们研发特定领域的系统，并对特定 质量要求非常高（例如系统可靠性)。
问卷/检查表和度量混合评审，在过程上与单纯的问卷/检查表基本一致。不同点在于:
•确定评审范围阶段，主要是与Stakeholders确定评审重点，例如：Performance。
这与全面架构评审的单纯问卷/检查表评审方式大相径庭。
•面谈对象也选择那些与评审重点相关的人员。
•面谈过程中，不单单使用问卷/检查表技术’通常会大量结合指标（例如性能指标） 制定模拟计划，进行模拟并汇总模拟结果，从而为问卷提供充分的证据。
虽然我们对当前流行的架构评审方法和评审技术进行了探讨，但在实践中很多情况其 实是要求我们混合使用各种评审技术来完成评审工作。没有哪一种评审技术既全面，又深 入，并且代价小„这就要求我们根据自身面临的情况，选择一种或几种合适的技术来进行评审。这与进行系统架构抉择的过程相仿，也是一个折中妥协的过程
6.5架构评审输出汇总
尽管我们可以选择的评审方法和评审技术很多，但是每种架构评审方法最终都需要相 应的评审输出结果。从架构评审的效果上来看，一个评审往往可以增进stakeholders间的 沟通、提高架构文挡的质量、增加架构人员对质量需求的全面而细致的理解并增进客户对 系统架构抉择和妥协原因的认同。
作为一个架构评审的有形的、必需的结果，一般都需要准备一份相应的评审报告，来 陈述架构评审的发现和建议，从而为决策层提供相应的决策支持。在实践评审工作中，我 们可以参考使用下述类似的评审报告模板：
1.评审目标。
2.评审范围和重点。
3.评审方法。
4.评审参与人员。
5.系统架构介绍。
6.系统质量要求。
7.系统架构方法及架构抉择汇总。
8.评审采用的度量指标。
9.当前架构的优点。
10.评审中的发现。
11.识别的问題和威胁。
12.评审方和被评审方的建议。
13.改进计划。
14.其他相关发现。
6.6架构评审实践指导
虽然我们已经比较清晰地了解了架构领域内一个重点研究方向：架构评审的发展和相 关评审技术。但是现实中做好一个系统架构的评审并不是一件简单的事。需要在实际的评 审的过程中不断进行总结。有了锋利的刀，并不一定就能做个好战士。
在实际的架构评审中’我们或许在不同的评审操作阶段会碰到一些各种各样、提前没 有预料或者难以解决的问题。下面我们列举了一些实践中可能遇到的问题，并提供了一些 应对方案和思路供读者参考。
1.评审目标确定阶段
问题：我们接到一个从客户方的质量管理经理处传来的架构评审请求•但是非常不幸， 该质量管理经理说不淸自己的目的是什么，只是说对目前的系统架构心中无数。
方案：必须在评审开始前.与各个重要的Stakeholders或其代表进行一个预备会议， 或者以单独走访的形式（不用会议这样正式公开的形式）拜访几个最为重要的 Stakeholders, 目的是澄淸评审目标，否则应该拒绝这样的评审请求#
2.评审准备阶段
问题：为了有效地进行评审，必备的架构文档是评审的一个成功约束条件.伹是，经 常获取的架构和技术文档并不充分。更为严重的是，有些架构根本没有文档。即便有，其质量对评审也没有什么帮助。
方案：请相关的架构人员使用presentation的形式来讲解其构建的架构，之后进行一 轮Q&A,以便于评审人员和架构人员对架构的认知达到相同的水平。
3.评审进行阶段
问题：评审进行时，发现架构人员等相关技术人员对你有明显的抵触情绪，因为他们 认为你是管理决策层派来检査他们工作的•
方案：首先，评审人员必须尊重这些技术人员•也许评审人员的架构经验更为广博和 精深，但是，这些技术人员比评审人员有更强的商业领域经验•所以，不能以一种挑剔和 批评的态度进行评审，应该抱着结合他们的长处与自身的经验共同探讨的评审态度，最好 把自己认为是架构组的成员之一•其次，在任何情况下，不要向客户管理层报告某某人拒 绝配合评审。同时，可以让管理层与那些拒绝合作的人进行沟通并说服他们进行更好的合 作.如果出现最差的情况，那就绕过这些拒绝合作的技术人员，找其他可以代替的人进行 评审。
4.评审分析和评判阶段
问题：进入分析和架构评判阶段，由于商业领域、技术领域经验的局限，评审人员很 难对当前的系统架构给出一个适当的评判。
方案：主要依靠自身的经验来感觉。首先，经过了评审的过程，评审人员或多或少已 经对系统架构有了“感觉”。这不是说依靠个人情感来感觉系统架构的好坏，一般需要有一 些前提证据存在，例如：该公司的老架构师往往比较值得信赖，可以参考他们对系统中使 用的架构方法、架构及设计抉择的原因的合理解释，来“感觉”该系统架构，从而得出自 己的评判。如果可能的话，有时也可以使用对比法来比较当前的系统架构和先前该公司其 他类似项目的架构，从中找到评判依据。
5.评审结果展示阶段
问题：评审结果展示应该是开一个大会展示给所有的Stakeholders,还是划分不同的 组分别展示？如果不能形成一个所有Stakeholders参加的大会，该怎么办？
方案：首先，要尽量开一个大会，把评审结果一次性地给所有Stakeholders公开、正 式、明确地展示出来。如果不能形成大会形式，最好将评审结果展示给评审发起者或出资 者.然后分组安排时间来展示评审结果。这样做的目的很明确，就是要让所有的 Stakeholders知道评审结果，
经过几次评审实践，我们就会发现_些先前从没有遇到过的各式各样的问题。其实， 架构评审不单单是一个技术工作，它同时也如同一个临时性的小社会，会存在各种社会、 心理、利益上的现象。
虽然系统架构评审作为一项流程和技术只是短短地发展了十几年，但是己经得到越来 越多公司和机构的认同。毕竞系统架构是一个复杂的过程，利用第三方来验证系统架构的 质量，是一种保证系统本身质量的有效手段。截至目前，虽然己经有一些评审实践方法和 技术可以参考，但是并没有形成一套统一、标准、通用的评审方法^不同的领域需要根据 自身的情况，选择适合自己的评审技术并不断地完善它。