第一部分
简要叙述所参与管理和开发的软件项目，并明确指出在其中承担的主要任务和开展的主要工作。
第二部分
SAAM的分析和评估目的、评估参与者、评估活动或过程以及评估结果说明。
1．评估目的
SAAM(Scenario-based Architecture Analysis Method)目的是验证基本的体系结构假设和原则，评估体系结构固有的风险。SAAM指导对体系结构的检查，使其主要关注潜在的问题点，如需求冲突。SAAM不仅能够评估体系结构对于特定系统需求的使用能力，也能被用来比较不同的体系结构。
2．评估参与者
风险承担者、记录人员、软件体系结构设计师。
3．评估活动或过程
SAAM分析评估体系结构的过程包括6个步骤，即形成场景、描述体系结构、场景的分类和优先级确定、间接场景的单个评估、场景相互作用的评估、总体评估，如下图所示。
(1)形成场景
形成场景是通过集中讨论来实现。使风险承担者在一个友好的氛围中提出一些场景，这些场景反映了他们的需求，也体现了他们对体系结构将如何实现需求的认识。
(2)描述体系结构
体系结构设计师应该采用参加评估的所有人员都能够充分理解的形式，对待评估的体系结构进行适当的描述。这种描述说明系统中的运算和数据构件，以及他们之间的联系。除了要描述这些静态特性以外，还要对系统在某段时间内的动态特征做出说明。
(3)场景的分类和优先级确定
场景分为直接场景和间接场景(或潜在场景)。直接场景是按照现有体系结构开发出来的系统能够直接实现的场景。与在设计时已经考虑过的需求相对应的直接场景能增进对体系结构的理解，促进对诸如性能和可靠性等其他质量属性的研究。
间接场景就是需要对现有体系结构做某些修改才能支持的场景。间接场景对衡量体系结构对系统在演化过程中将出现的变更的适用情况十分关键。通过各种间接场景对体系结构的影响，可以确定体系结构在相关系统的生命周期内对不断演化的使用的适应情况。直接场景类似于用例，而间接场景有时也叫变更案例。
评估人员通过对场景设置优先级，可以保证在评估的有限时间内考虑最重要的场景。这里的“重要”完全是由风险承担者及其所关心的问题确定的。风险承担者通过投票表达所关心的问题。
(4)对间接场景的单个评估
对于直接场景而言，体系结构设计师要讲清所评估的体系结构将如何执行这些场景；对于间接场景而言，应说明需要对体系结构做哪些修改才能适应间接场景的要求。
对每一个间接场景，列出为支持该场景而需要对体系结构所做的改动，并估计出这些变更的代价。对体系结构的更改意味着引入某个新构件或新联系，或者需要对已有构件或联系的描述进行修改。
(5)评估场景的相互作用
场景的相互作用暴露了设计方案中的功能分配。场景相互作用的多少与结构复杂性、耦合度、内聚性有关。同时，场景的相互作用能够暴露出体系结构设计文档未能充分说明的结构分解。
(6)形成总体评估
总体的权衡和评价，反映该组织对表现在不同场景中的目标考虑优先级。根据对系统成功的相对重要性来为每个场景设置一个权值。
如果要比较多个体系结构，或者针对同一体系结构提出多个不同的方案，则可通过对权值的确定来得出总体评价。权值的设置具有很强的主观性，所以，应该让所有风险承担者共同参与，但也应合理组织，要允许对权值及其基本思想进行公开讨论。
4．评估结果
SAAM评估的主要有形输出包括以下内容：
(1)把代表了未来可能做的更改的场景与构架对应起来，显现出构架中未来可能会表现出较高复杂性的地方，并对每个这样的更改的预期工作量做出评估。
(2)理解系统的功能，对多个构架所支持的功能和数量进行比较。
如果所评估的是一个框架，SAAM评估将指明框架中未能满足其修改性需求的地方，有时还会指出一种效果更好的设计。SAAM评估也能对两个或者三个备选构架进行比较，明确其中那一个能够较好地满足质量属性需求，而且做的更改较少、不会在未来导致太多的复杂的问题。
ATAM的分析和评估目的、评估参与者、评估活动或过程以及评估结果说明如下。
(1)评估目的
ATAM(Architecture Tradeoff Analysis Method，构架权衡分析方法)的评估目的是依据系统质量属性和商业需求评估设计决策的结果。ATAM希望揭示出构架满足特定质量目标的情况，使我们更清楚地认识到质量目标之间的联系，即如何权衡多个质量目标。
(2)评估参与者
①评估小组。该小组是所评估构架项目外部的小组，通常由3～5人组成。该小组的每个成员都要扮演大量的特定角色。他们可能是开发组织内部的，也可能是外部的。
②项目决策者，对开发项目具有发言权，并有权要求进行某些改变，他们包括项目管理人员，重要的客户代表，构架设计师等。
③构架涉众(stakeholders)。包括关键模块开发人员、测试人员、用户等。
(3)评估活动或过程
整个ATAM评估过程包括9个步骤，按其编号顺序分别是描述ATAM方法、描述商业动机、描述体系结构、确定体系结构方法、生成质量属性效用树、分析体系结构方法、讨论和分级场景、描述评估结果，如下图所示。
①描述介绍ATAM方法。
评估小组负责人向参加会议的风险承担者介绍ATAM评估方法。在这一步中，要解释每个人将要参与的过程，并预留解答疑问的时间，设置好其他活动的环境和预期结果。关键是要使每个人都知道要收集哪些信息，如何描述这些信息，将要向谁报告等。
②描述商业动机。
项目决策者从商业的角度介绍系统的概况。该描述应该包括：系统最重要的功能；技术、管理、经济和政治方面的任何相关限制；与该项目相关的商业目标和上下文；主要的风险承担者；架构的驱动因素。
③描述体系结构。
首席设计师或设计小组要对体系结构进行详略适当的介绍。在体系结构描述中，至少应该包括：技术约束(例如，操作系统、硬件、中间件等)；要与本系统交互的其他系统；用以满足质量属性要求的体系结构方法。
④确定体系结构方法。
ATAM评估方法主要通过理解体系结构方法来分析体系结构，在这一步，由设计师确定体系结构方法，由分析小组捕获，但不进行分析。
⑤生成质量属性效用树。
在这一步中，评估小组、设计小组、管理人员和客户代表一起确定系统最重要的质量属性目标，并对这些质量属性目标设置优先级和细化。即使是体系结构级的分析，也不一定是全局的，所以，评估人员需要集中所有相关人员的精力，注意体系结构的各个方面，这通常是通过构建效用树的方式来实现的。
效用树的输出结果是对具体质量属性需求的优先级的确定，这种优先级列表为 ATAM评估方法的后面几步提供了指导，它告诉了评估小组应该把有限的时间花在哪里，特别是应该到哪里去考察体系结构的方法与相应的风险、敏感点和权衡点。
⑥分析体系结构方法。
一旦有了效用树的结果，评估小组可以对实现重要质量属性的体系结构方法进行考察。这是通过文档化这些体系结构决策和确定它们的风险、敏感点和权衡点等来实现的。
在这一步中，评估小组要对每一种体系结构方法都考察足够的信息，完成与该方法有关的质量属性的初步分析。这一步的主要结果是一个体系结构方法或风格的列表，与之相关的一些问题，以及设计师对这些问题的回答。通常产生一个风险列表、敏感点和权衡点列表。
在这一步结束时，评估小组应该对整个体系结构的绝大多数重要方面所做出的关键设计决策、风险列表、敏感点、权衡点有一个清楚的认识。
⑦讨论和分级场景。
场景在驱动ATAM测试阶段起主导作用。风险承担者进行两项相关的活动：集体讨论用例场景和改变场景。用例场景是场景的一种，在用例场景中，风险承担者是一个终端用户，使用系统执行的一些功能。
一旦收集了若干个场景后，必须设置优先级。评估人员通过投票表决的方式来完成，每个风险承担者分配相当于总场景数的30%的选择，且此数值只入不舍。例如，如果共有17今场景，则每个风险承担者将拿到6张选票，这6张选票的具体使用则取决于风险承担者，他可以把这6张票全部投给一个场景，或者每个场景2～3张票，还可以一个场景一张票等。
⑧分析体系结构方法。
在收集并分析了场景之后，设计师就可把最高级别的场景映射到所描述的体系结构中，并对相关的体系结构如何有助于该场景的实现做出解释。
⑨描述评估结果。
最后要把ATAM分析中所得到的各种信息进行归纳，并反馈给风险承担者。这种描述一般要采用幻灯片的形式，但也可以在ATAM评估结束以后，提交更完整的书面报告。在描述过程中，评估负责人要介绍ATAM评估的各个步骤，以及各个步骤中得到的各种信息，包括商业环境、驱动需求、约束条件和体系结构等。
(4)评估结果
ATAM的评估结果包括以下内容：
①一个简洁的构架表述。
②表述清楚的业务目标。
③用场景集合捕获的质量属性。
④所确定的敏感点和权衡点的集合。例如，备份数据库，对可靠性质量属性来讲，是敏感点性质的设计决策，但对性能和可靠性两个质量属性而言，它是权衡点性质的设计决策。
⑤有风险决策和无风险决策。
⑥风险主题的集合，包括：
·敏感点(sensitivity points)——与某个质量属性相关的构架决策。
·权衡点(tradeoff points)——与多个质量属性相关的构架决策。
·有风险决策(risk set)——根据所陈述的质量属性需求，可能导致不期望结果的构架决策。
·无风险决策(nonrisk set)——根据分析被认为是安全的构架决策。
第三部分
结合你参与的实际工作和项目的实际情况，具体阐述你在进行体系结构设计和评估时采用的评估方法和具体实施的过程和步骤，并对最终实际效果进行说明。
如果在实际项目实施的时候，能利用ATAM方法进行软件体系结构评估，并利用 CBAM方法作为ATAM的补充对软件体系结构成本效益等经济性进行评估，则更完善。
深色：已答题 浅色：未答题