在构架商业周期中.设计师已经设计了构架并将其•编成了文档。现在的任务是，讨论 如何评估和分析构架，以确保该构架满足了需求，能够正常发挥作用。这就是第III部分的 重点，我们首先回答关于构架评估的•些基本问题——原因、时间、成本、收益、技巧、 计划内、计划外、前览条件以及结果。
原 因
关于系统构架的•个最重要的事实是，可以通过了解构架获知系统本身的重要属性 —即使系统还不存在。设计师要制定设计决策，这些决策将会对他们构建的系统产生下 游影响，这些影响足可知的并且是可预测的。如果不制定设计决策的话.那么，设计构架 的过程几乎就是在掷般子：我们只是随机选择了一个构架.然后根据该构架构建系统，肴 看系统是否具有所期望的厲性：如果没有，回过头来茁新进行设计。然而，构架不是烹饪 技术，我们知道自己可以比随机猜想做得更好。
设计师大体上知道其设计决策将会产生的影响。正如在第5章所看到的，我们尤其可 以通过使用构架战术和模式使采用该构架的系统具有某些已知的属性。因此，设计选择（也 就是构架）是可以进行分析的。给定一个构架，我们就可以推断出系统的某些属性，即使 该系统还没有构建出来。
为什么耍对构架进行评估？因为很多亊情都依赖于构架，并且因为我们能够对构架进 行评估。对候选构架进行评估的高效方法一在它成为项目可接受的计划之前——能够产 生很大的经济价值，随着可重复的、结构化方法的出现（如将在笫11章讲述的ATAM), 构架评估能够提供一个相对低成本的风险移植能力。一定耍确保构架是满足需要的构架 在每个基于构架的开发方法中都应该进行构架评估。
在生命期中尽可能地评估软件质量几乎总是经济高效的。如果问题发现得早，它们 就容易纠正——改变需求、规范或设汁都是必要的。不能在项目的后期才注重软件质量，要在一开始就引起重视，即在制定设计决策时就考虑软件质量。在进行全面开发前，在设 计阶段就对候选的设计方案进行评估对项目是最有利的„
然而，可以在系统生命期的许多个点上进行构架评估。如果构架还处于初期，可以评 估那些已经做出的决策或正在考虑中的决策。您可以在构架方案中进行选择。如果构架己 经完成或接近完成，可以在项目投入到漫长昂贵的开发之前，对构架进行验证。对正在修 改、移植、与其他系统集成或进行其他重大升级的早期系统的构架进行评估也是有意义的。 最后，构架评估也是一种出色的发现工具：开发项目的人员通常需要理解所继承的系统如 何（或是否）满足了其质量属性需求。
此外，当采购一个将有很长生命期的大型软件系统时，采购组织了解候选系统的底层 构架是很重耍的。这使得根据重要的质量属性对其适宜性进行评佔成为可能。
还可以通过评估在两个相互竞争的构架之间做出选择：对二者进行评估，根据“出色 构架”的标准肴看哪个构架更能满足需要。
成 本
评估的成本就是需嬰参与评估的人员所付出的时间。AT&T对至少要求700人天的项 目进行了大约300次整个范围的构架评审，它报告说，根据单个项目管理人员的估计，进 行评审的平均成本为70人天。基于ATAM的评审大约需要36人天。'如果您的组织采用 了 一个进行评估的标准单元，那么，必须将支持它的成本和培训成员的时间包括在内。
收 益
进行构架审査有如下6个优点：
(1)财务..在AT&T,每个项目管理人员都报告了进行构架评估所实现的节约。在8 年的时间内对构架进行评估的经验表明，进行全面的构架评估平均可以节约10%的成本。 这说明对于700人天或时间更长的项目来说，通过评佔可以节约70人天。
其他组织还没有公布如此有说服力的量化数据，但有儿家咨询公司报告说.他们所做 的80%以上的工作都是重复业务。其客户已经充分认识到了进行评估的价值.愿意支付额 外的资金来进行评估。
有许多对客户的构架进行评估从而实现成本节约的佚事。一家大型公司在进行评估 后，发现公司要采购的全球信息系统的构架并不能提供所期望的系统厲性，从而避免了数百万美元的采购。对电子资金转账系统进行早期构架分析后发现，该系统每晚只能转账500 亿美元，而这仅为所期塑能力的一半。对一个零售商品系统进行早期评估后发现，该系统 存在.个峰期定购性能问题，但使用多少硬件都无法解决，从而防止了个重大业务故障 的出现，还有很多诸如此类的亊情。
还有一些本应进行，但未进行构架评估的事件。重新编写客户计账系统预计耍用两年 的时间，但在7年后，该系统己被重新实现了 3次。该系统从来没有满足过性能指标，而且最新版本所使用的CPU的计算能力为最初原型版本的60倍。在另外一个关于大型工程 关系数据库的系统中，所出现的性能问题主要是因为制定的设计决策使得不可能进行集成 测试。在投入2 000万美元后，该项目被取消了.
(2)强制为评审做准备。向被评审人员说明构架评估的重点并要求他们在评估前表 述构架，这意味着被评审人员必须把系统的构架编成文档。许多系统都没有-个所有开发 人员都可以理解的构架。现有的构架描述要么太简单：要么太复杂（更常见），可能会有 几千页。而且，对于某些元素的假设，开发人员通常会产生误解。在为评估做准备的过程 中将会揭示出很多问题。
(3)捕获的基本原理。构架评估通常侧重于需要回答的一些具体问题的某几个特定 的方面。回答这些问题通常耑要解释设计选择及其基本原理。在生命期的后期，一个编成 文档的设计基本原理非常重要，因为可以据此评定可修改性的含义。在软件开发中.系统 开发完成后再捕获基本原理是较难完成的任务之一。捕获基本原理（在构架评估中提供） 使得具有了可供以后使用的宝贵信息。
(4)在早期检测中发现构架中存在的问题，在生命期中发现问题越旱，修复这些问 题的代价就越小。可以通过构架评估发现的问题包括不合理（或昂贵）的需求、性能问题 以及与潜在的下游修改相关的问题。例如.应用了系统修改场景的构架评估可以揭示可移植性和可扩展性问题。构架评估可以用这种方式提供对产品能力和限制的皁期洞察。
(5)验证需求。讨论和检查构架满足其需求的情况可以展开对需求的讨论。结果是 能更淸楚地理解需求，通常还能够知道需求的优先级。当不考虑早期设计决策时，需求创建通常会导致相互冲突的系统属性。我们通常都会耍求实现高性能、安全性、容错和低成 本，但这些属性是很难实现的，而且通常不可能同时实现。构架评估揭示了冲突和权衡， 我们可以在构架评估中协商其解决方法。
(6)改进的构架。在开发过程中进行构架评估的组织报告说其所评估的构架的质量 得到了改进。开发组织预计了将会提出的问题，将提出的论点并准备了评估所耍求的文档。 他们非常希望自己在评估中能有最好的表现。构架评估不仅在评估后得到了更好的构架， 而且在评估前也足如此。随禮时间的推移，组织就培养了一种提倡优秀的构架设计的文化.
总而言之，通过构架评估可以提高质量、控制成本并降低预算风险，构架是所有技术决策的框架，因此它对产品的成本和质量有着非常大的彫响。构架评估并不能保证高质量或低成木，但它指出了存在风险的区域„测试或文档质量和编码这些因素也会影响系统的 最终成本和质量。
技 巧
下两章讨论的ATAM和CBAM方法就是提问技巧的示例。两种方法都使用场景来询 问评审中的构架如何对各种情况做出响应的问题。其他提问技巧包括检査列表或调査问 卷。当评估部门反复遇到相同种类的系统时，这些是有效的，而且每次相同种类的探查都是适当的。所有提问技巧基本上都依赖于思维试验，以发现构架适合其任务的程度。
提问技巧的补充是度量技巧，它依赖于对某些类别的定量度量。该技巧的-个示例是 构架度量指标。度量构架的耦合、其模块的内聚性以及其继承层次的深度都可以得出关于 所得到的系统的可修改性的一些结果。同样地，构建模拟或原型，然后对其进行度量以获 知感兴趣的质量属性（在这里是指运行时质量属性，如性能或可用性）也是.种度量技巧。从某种意义上说，度量技巧所给出的答案要比提问技巧所给出的答案更具体，怛是， 我们只能在己幵发出来的工作产品中应用这些技巧.也就是说，使用度量技巧时，必须有已经存在的、可以被度量的工作产品。而对于提问技巧来说，在假定的构架上就可以很好 地应用它，并且可以在生命期的早期应用。
计划内或计划外
评估可以是计划内的或汁划外的。计划内评估被认为是项目开发周期的-个正常的部 分。它事先就已经安排好.是项目的工作计划和预算的组成部分，并预计了后续行动。计 划外的评估是未曾预料到的，通常是因为项目存在严重的问题，需要采取极端的措施来补 救以前的工作。
在理想情况下，计划内评估被认为是项目的一项资产。在最坏的情况下，它被认为是 项目对其的偏离，不能把评估看作是对项目成员的技术权威的桃战，而应将其看作是对项 目最初方向的验证。计划内评估是前瞻性的，由评估小组来完成。
对于项目成员來说，计划外评估更像是-种折磨，项目的资源和时间本来就已经很紧 张了.但还要抽出资源和时间来进行评估。只有当管理层认为项目很有可能会失败，需要 在幵发过程中进行纠正时，才会进行计划外评估。计划外评估是反应性的，会使项目成员 感到非常紧张，评估小组的负责人务必注意，千万不要使该活动变成小组成员之间的相互 指责。
不用说，计划内评估是比较可取的。
前置条件
成功的评估应该具存如下属性：
(1)表述清楚的构架目标和需求。只有针对具体的质量厲性，才可以说构架是合适 的或不合适的。对于一个需要可修改性的应用来说.能够提供惊人性能的构架可能是完全 错误的,，不知道具体的“出色构架”的标准就对构架进行分析犹如开始了一次没有目的 的旅行。有时(但根据我们的经验，这几乎不可能发生），标准是在需求规范屮建立的。 更有可能的是，在实际评估前得出标准，或在实际评估中确定。目标定义了评估的目的， 应该将其明确地作为评估合同的一部分，随后将对此进行讨论。
(2)可控制的范围,，为了把重点放在评估上，应该列出几个明确的目标。目标的数 量应该最少有3〜5个，不能定义少量的高优先级目标可能意味着对评估（也可能是系统） 的期望是不切实际的。
(3)经济高效。评估的发起者应该确保评估的收益大于成本。我们所描述的评估类型适合于大中型项目，对于小型项目可能就不是经济高效的了。
(4)关键人员的可用性。务必确保设计师或至少是能够权威地讲述系统构架和设计 的人员有时间参与评佔。这个人（或这些人）主要是应该能够快速淸晰地讲述有关构架的 一些情况以及构架决策的动机。对于很大的系统来说.每个主耍组件的设计人员都要参与 评估，以确保设计师关于系统设计的想法确实被更详细地反映并体现了出來。这些设计人 员还应该能够说出组件的行为和质量属性。对于ATAM来说，需要在评估时确定构架的涉 众并表示出他们。确定评估报告的客户并了解他们的评价和期望是一个基本的活动。
(5)称职的评估小组,，在理想情况下，软件构架评估小组是公司内•个单独的实体. 他们必须公证、客观并受人尊敬。该小组必须由适合进行评估的人组成，以使项目人员不 会把评估肴作是浪费时间，而且评估结果会得到重视和承认。它必须包括熟知构架和构架要点的人，并由在构架级设计和评估项目方面具有经验丰富的人来领异。
(6)可管理的期望。对评估的成功至关重要的是，双方对支持评估的组织的期望有 —个消楚的理解。应该淸楚评估的目标、结果、将要审沓（不审査）的区域、将要占用项 目多少时间和资源以及把评估结果提交给谁。
结 果
评估应该产生一份描述所关心的问题以及支持数据的报告。初步编写该报告后.应该
将其在所有评估参与人员之间传阅，以发现和纠正任何误解和偏差。将报告的各部分关联 起来，形成最终的报告。在理想情况下，如果问题没有解决，就应该根据其对项目的潜在影响确定问题的优先级。
还应该收集关于评估过程自身的信息。可以根据多次评估的结果授课、进行培训，并 改进系统开发和构架评估过程。应该收集评估的成本和收益信息。最好能从开发管理人员那儿获得有关收益的估计信息。评审组织应该保留有关评估的信息。并使用这些信息来改 进将来的评估，为评审组织的管理人员提供成本/收益总结。
这一部分共有3章“ ATAM (第11章讲述）是•种进行构架评估的结构化方法。通过 使用该方法可以得出一个构架不满足其业务目标的风险列表。CBAM (第12章讲述）是 个确定首先解决哪些风险的方法.在一个大型系统中，所发现的风险的数最可能是非常 多的。确定酋先解决哪些风险就是将消除该风险的收益与修改构架以降低该风险的成本进 行比较。CBAM提供了 一个处理该组织和经济问题的结构。第13章给出了 一个案例分析. 它描述了支持万维网的系统，以及其演变如何构成了 ABC的几个周期的示例。
可进一步参阅的文献
这些介绍性的内容借鉴了 “建议的构架评估最佳行业实践” [Abowd96]，该报告是 根据本书作者和在SEI工作的其他人员组织的一系列研讨会编写的。冇8家公司和咨询组 织的代表参加了这些研讨会。
基于检查列表或调査问卷的构架评估是积极设计评审形式，[Pamas 85b]对此进行了 描述。枳极设计评审是指参与评估的各方使用文档回答事先准备好的具体问题.从而发挥 枳极的作用。这种评估与机会主义的或非结构化的评估对立。在机会主义的或非结构化的 评估中，只要求参与的评估人员报告他们可能发现的任何不正常的情况。
[Cusumano 95]使用度量指标来揭示很可能会发生变化的地方。[AT&T 93]中记录了 AT&T进行构架评估的丰富经验。