目的
|
定义复审的范围和目标。
定义用于每个具体范围/目标组合的方法。
|
执行复审可使用不同的方法:
表示驱动的复审
获得(或建立)体系结构表示,然后基于这一表示来找问题和原因。
这里存在广泛的情况:有很善于建立体系结构并将提供可理解的描述来着手进行的组织,有需要确定谁是软件设计人员(甚至隐藏在某个其他名称后)并需要获取此人信息的组织,还有软件体系结构是一个完全未知概念的组织。
此流程则称为“挖掘体系结构”,实际在字面上像是:使用镐将体系结构从软件或文档中挖出,查看源代码、接口、配置数据等。
可用于组织表示的一种模型是使用体系结构视图(在软件体系结构文档中提供)的形式:逻辑视图组织主要类(对象模型)、进程视图描述主要控制线程和线程之间如何通信、开发视图显示各种子系统及其依赖关系、物理视图描述其他视图的元素到一个或多个物理配置的映射。将问题与各种视图一起组织起来。
信息驱动的复审
确定论证所需的一系列信息(数据、度量),获取信息并将此信息与需求或某个已认可的参考标准相比较。这很适用于调查某些质量属性,如性能或健壮性。
场景驱动的复审
这是有条理的“如果...会怎样”的方法。将所问的一般问题转换成系统应通过的一组场景,并基于场景来提问题。此类场景的示例是:
-
系统在平台 X 和 Y 上运行。(探查的真正质量属性是可移植性。)
-
系统执行此(附加)功能 F。(真正的质量属性是可扩展性。)
-
系统每小时处理 200 个请求。(真正的质量属性是可伸缩性。)
-
用户将系统安装在这种类型的站点上。(真正的质量属性是完全性或可用性。)
这种方法的好处在于它将任务置于非常具体的、各方都可理解的角度。它也允许探查需求内的疏漏或缺陷,特别是当需求非正式、非书面或非常不具体时。缺点在于它不将体系结构本身作为复审的对象来捕获,而是将系统作为黑匣,只能对其中发出某些探查。
实际上,许多事情并不是那么明确地分离的,我们以所有三种方法都执行一部分来作为结束。
确定问题
揭示潜在的问题主要由人基于知识和经验来判断。某些故障模式在项目间和组织间是重复的。某些启发式方法可用于揭示问题区域。检查列表是有用的(以后会建议一些非常普遍的检查列表),以前的复审得出的结果(如有)也很有用。
捕获潜在问题(当出现时),以中立的语气(不要指指点点,也不是“劫数难逃”)描述问题。可以象 AT&T 复审人员那样使用小纸板卡,或使用 CRC 卡,帮助对问题划分优先级、组织和消除问题。
然后,按范围或影响的递减顺序对候选问题排序,并且如果存在多个问题,则首先处理与手边的问题直接相关的问题,如果时间允许,保留“其他建议”以便以后使用。接着,声明问题的真实性:极常见的情况是一个人可以察觉到一个问题,但它可能并不是真正的问题。
我们尚未与恰当的人交谈以及查看恰当的信息。再次排序。确保有多个数据点来验证问题的真实性。(缺乏经验的评估员倾向于思路太单一。)
当确认问题后,快速检查可消除问题的方法,而不必尝试即时重新设计系统。写下可能的简化、重用和备选方法(例如,购买还是自制)。
|