从20世纪90年代开始，因为系统架构的全方位兴起（例如面向对象的架构技术、构 件技术、架构与设计模式等），愈来愈多的从业人员认识到提升架构和设计质量的重要性。 这使得架构评审获得了飞跃式的演化。经过近十几年的发展，架构评审己经有了长足的进 步。咱们如今能够看到业界许多体系化的架构评审方法和评审技术，例如：SAAM、ATAM、 SAAMCS、CBAM、ARID、SPE、SAAMER、SAEM、SBAR、EASSMK ALPSft/^。
如此之多的评审方法和技术，有其各自的应用场合和质量关注点。那么在现实中，如 果面对一个系统或者一个子系统要求咱们对其进行一次架构评审，到底应该选择怎样的评 审方法或评审技术来进行操做呢？这个问题会引起以下一连串的问题。
•架构评审的总目标应该是什么？
•架构评审应该邀请哪些人参加？
•为了进行架构评审，咱们须要搜集和分析哪些系统架构相关的信息或文档？
•架构评审应该遵循怎样的流程或步骤？
•进行架构评审时，应该问一些怎样的问题？应该验证哪些方面？
•评审中须要使用怎样的模板进行工做？
•评审结束时应该有哪些必要的总结信息？
在详细探讨上述问题前，咱们能够先来看看如图6-1所示的这个系统架构评审概念模型。
从该系统架构评审概念模型中，咱们能够看到一个体系化的系统架构评审，有以下几 个主要的方面和阶段：
须要肯定架构评审的约束条件，这其实就是架构评审工做的主要目标要求；并与 Stakeholders 一块儿最终肯定评审的范围和重点。
根据评审的目标要求和评审重点，肯定架构评审主要参与者与时间安排；同时肯定 进行评审的主要评审方法或评审技术，最终造成评审计划。
根据肯定的评审目标及评审方法和技术，与评审主要参与者一块儿肯定评审须要的输 入信息和输入文档。
根据肯定的评审方法或评审技术的流程要求进行评审工做。
在实现评审目标的前提下，产生相应的最终评审输出。
将该评审概念模型进一步分解，就能够看到如图6-2所示的更加详细的评审过程流程, 咱们称之为ARP架构评审流程（Architecture Review Process)D
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所示的几个方面搜集相应的文档*做 为咱们进行评审的依据。
输入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)的一个重要标尺。这些标准和约 束能够包括：
•国际标准。例如：国际电报电话通行标准、国际财务准則。
•国家标准。例如：中国食品药品标准、美国财务准則。
•国家法律法规。例如：道路交通法。
•行业标准。例如：IEEE80二、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所示。
若是从评审流程的角度上来说，ATAM评审方法主要包含四个重要的阶段和九个核心 流程活动。现实中各个机构和公司架构评审实践过程时，在参考ATAM主要流程及活动的 基础上，也会或多或少地进行优化和改良，这主要体如今与问卷评审技术和度量评审技术 的结合上。目前应用ATAM进行评审时，大多会遵循如图6-5所示的流程和主要动做。
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的识别中，这些场景主要是在评审组的启发下，由架构评审人员和项目决策人员共同完成。
识别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的操做进行调整并使之成 为一个按部就班和迭代的过程。
•首先，为了弥补活动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所 示的五个核心活动组成。
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知道评审结果，
通过几回评审实践，咱们就会发现_些先前从没有遇到过的各式各样的问题。其实， 架构评审不仅仅是一个技术工做，它同时也如同一个临时性的小社会，会存在各类社会、 心理、利益上的现象。
虽然系统架构评审做为一项流程和技术只是短短地发展了十几年，可是己经获得越来 越多公司和机构的认同。毕竞系统架构是一个复杂的过程，利用第三方来验证系统架构的 质量，是一种保证系统自己质量的有效手段。截至目前，虽然己经有一些评审实践方法和 技术能够参考，可是并无造成一套统1、标准、通用的评审方法^不一样的领域须要根据 自身的状况，选择适合本身的评审技术并不断地完善它。