|
知识路径: > 软件工程 > 软件体系结构评估 >
|
相关知识点:6个
|
|
|
|
使用ATAM方法对软件体系结构进行评估的目标,是理解体系结构关于软件的质量属性需求决策的结果。ATAM方法不但揭示了体系结构如何满足特定的质量目标(例如性能和可修改性),而且还提供了这些质量目标是如何交互的,即它们之间是如何权衡的。这些设计决策很重要,一直会影响到整个软件生命周期,并且在软件实现后很难修改这些决策。
|
|
|
|
|
(1)描述ATAM方法。评估小组负责人向参加会议的项目干系人介绍ATAM评估方法。在这一步,要解释每个人将要参与的过程,并预留出解答疑问的时间,设置好其他活动的环境和预期结果。关键是要使每个人都知道要收集哪些信息,如何描述这些信息,将要向谁报告等。
|
|
|
(2)描述业务动机。参加评估的所有人员必须理解待评估的系统,在这一步,项目经理要从业务角度介绍系统的概况。
|
|
|
(3)描述体系结构。首席设计师或设计小组要对体系结构进行详略适当的介绍。这一步很重要,将直接影响到可能要做的分析及分析的质量。在进行更详细的分析之前,评估小组通常需要收集和记录一些额外的体系结构信息。
|
|
|
(4)确定体系结构方法。ATAM评估方法主要通过理解体系结构方法来分析体系结构,在这一步,由设计师确定体系结构方法,由分析小组捕获,但是不进行分析。
|
|
|
(5)生成质量属性效用树。评估小组、设计小组、管理人员和客户代表一起确定系统最重要的质量属性目标,并对这些质量目标设置优先级和细化。这一步很关键,它对以后的分析工作起指导作用。
|
|
|
(6)分析体系结构方法。一旦有了效用树的结果,评估小组可以对实现重要质量属性的体系结构方法进行考察。这是通过文档化这些体系结构决策和确定它们的风险、敏感点和权衡点等来实现的。在这一步中,评估小组要对每一种体系结构方法都考察足够的信息,完成与该方法有关的质量属性的初步分析。这一步的主要结果是一个体系结构方法或风格的列表,与之相关的一些问题,以及设计师对这些问题的回答。通常产生一个风险列表、敏感点和权衡点列表。
|
|
|
(7)讨论和对场景分级。场景在驱动ATAM测试阶段起主导作用,实践证明,当有很多项目干系人参与ATAM评估时,生成一组场景可为讨论提供极大的方便。
|
|
|
(8)分析体系结构方法。在收集并分析了场景之后,设计师就可把最高级别的场景映射到所描述的体系结构中,并对相关的体系结构如何有助于该场景的实现做出解释。在这一步中,评估小组要重复第6步中的工作,把新得到的最高优先级场景与尚未得到的体系结构工作产品对应起来。在第7步中,如果未产生任何在以前的分析步骤中都没有发现的高优先级场景,则在第8步就是测试步骤。
|
|
|
(9)描述评估结果。最后,要把ATAM分析中所得到的各种信息进行归纳,并反馈给项目干系人。这种描述一般要采用辅以幻灯片的形式,但也可以在ATAM评估结束之后,提交更完整的书面报告。在描述过程中,评估负责人要介绍ATAM评估的各个步骤,以及各步骤中得到的各种信息,包括业务环境、驱动需求、约束条件和体系结构等。最重要的是要介绍ATAM评估的结果。
|
|
|
我们可以修改这9个步骤的顺序,以满足体系结构信息的特殊需求。也就是说,虽然这9个步骤按编号排列,但并不总是一个瀑布过程,评估人员可在这9个步骤中跳转或进行迭代。
|
|
|
|
ATAM方法的各个步骤是随着时间的推移而展开的,可大致分为两个阶段。第一个阶段以体系结构为中心,重点是获取体系结构信息并进行分析;第二个阶段以项目干系人为中心,重点是获取项目干系人的观点,验证第一个阶段的结果。
|
|
|
之所以要分为两个阶段,是因为评估人员要在第一个阶段收集信息。在整个ATAM评估过程中,评估小组中的部分人(通常是1~3人)要与设计师、1~2个其他关键的项目干系人(例如,项目经理、客户经理、市场代表)一起工作,收集信息。对支持分析而言,在大多数情况下,这种信息是不完整的或不适当的,所以,评估小组必须与设计师一起协作引导出必须的信息,这种协作通常要花几周的时间。当评估人员觉得已经收集了足够的信息,并已把这些信息记录成文档,则就可以进入第二个阶段了。
|
|
|