活动:
|
目的
|
|
角色: 技术复审员 | |
频率:每个迭代至少一次,尤其是在精化阶段期间。 | |
步骤 | |
输入工件: | 生成的工件: |
工具向导: | |
更多信息: |
工作流程明细: |
目的 | 每个复审的一般建议。 |
大致一看,软件体系结构评估与任何其它评估或复审没有太大区别。
但是,软件体系结构的一个重要特征是缺乏对于多个体系结构质量属性的特定评估 - 只有几项体系结构质量可以客观评估。性能是可能可以评估的一个示例。其它质量则更加定性或主观:概念上的完整性就是一个示例。 而且,在缺乏可比的其它数据或参考的情况下,通常很难确定某个度量表示什么。如果参考系统可用并且目标使用者能够理解,则相对于此参考系统来表示某些复审结果通常是很方便的。 这可能发生在被设计系统与较早设计可比的环境中。
此评估在生命周期中的发生时间也影响它的目的或有用性。
“同行”复审人员具有与角色软件设计人员相同的人员配备概要文件,尽管复审人员更局限地侧重于技术问题。领导地位、成熟度、实用性和面向结果的重要程度有所下降,但仍然很重要 - 复审人员揭示体系结构缺陷,如果这些缺陷影响到项目的进度安排,则可能是不希望看到的。不过,关键问题最好在能够解决时及早提出,
而不要盲目遵循导致项目团队沿错误路径而行的进度安排。体系结构复审人员需要平衡风险和成本,对项目成功的更多问题保持敏感。
体系结构复审人员也需要是能够提出和讨论敏感问题的具有说服力的沟通人员。
目的 | 定义复审的范围和目标。 定义用于每个具体的范围/目标组合的方法。 |
执行复审可使用不同的方法:
获得(或建立)体系结构表示,然后基于这一表示来找问题和原因。
这里存在广泛的情况:有很善于建立体系结构并将提供可理解的描述来着手进行的组织,有需要确定谁是软件设计人员(甚至隐藏在某个其它名称后)并需要获取此人信息的组织,还有软件体系结构是一个完全未知概念的组织。 此流程则称为“挖掘体系结构”,实际在字面上像是:使用镐将体系结构从软件或文档中挖出,查看源代码、接口、配置数据等。
可用于组织表示的一种模型是使用体系结构视图(在软件体系结构文档中提供)的形式:逻辑视图组织主要类(对象模型)、进程视图描述主要控制线程和线程之间如何通信、开发视图显示各种子系统及其依赖关系、物理视图描述其它视图的元素到一个或多个物理配置的映射。 将问题与各种视图一起组织起来。
确定论证所需的一系列信息(数据、度量),获取信息并将此信息与需求或某个已认可的参考标准相比较。 这很适用于调查某些质量属性,如性能或健壮性。
这是有条理的“如果...会怎样”的方法。将所问的一般问题转换成系统应通过的一组场景,并基于场景来提问题。此类场景的示例是:
这种方法的好处在于它将任务置于非常具体的、各方都可理解的角度。它也允许探查需求内的疏漏或缺陷,特别是当需求非正式、非书面或非常不具体时。 缺点在于它不将体系结构本身作为复审的对象来捕获,而是将系统作为黑匣,只能对其中发出某些探查。
实际上,许多事情并不是那么明确地分离的,我们以所有三种方法都执行一部分来作为结束。
揭示潜在的问题主要由人基于知识和经验来判断。某些故障模式在项目间和组织间是重复的。某些启发式方法可用于揭示问题区域。 检查列表是有用的(以后会建议一些非常普遍的检查列表),以前的复审得出的结果(如有)也很有用。
捕获潜在问题(当出现时),以中立的语气(不要指指点点,也不是“劫数难逃”)描述问题。可以象 AT&T 复审人员那样使用小纸板卡,或使用 CRC 卡,帮助对问题划分优先级、组织和消除问题。
然后,按范围或影响的递减顺序对候选问题排序,并且如果存在多个问题,则首先处理与手边的问题直接相关的问题,如果时间允许,保留“其它建议”以便以后使用。接着,声明问题的真实性:极常见的情况是一个人可以察觉到一个问题,但它可能并不是真正的问题。我们尚未与恰当的人交谈以及查看恰当的信息。再次排序。 确保有多个数据点来验证问题的真实性。(缺乏经验的评估员倾向于思路太单一。)
当确认问题后,快速检查可消除问题的方法,而不必尝试即时重新设计系统。写下可能的简化、重用和备选方法(例如,购买还是自制)。
目的 | 对已确定的缺陷采取行动。 |
在复审之后,为每个确定的缺陷分配职责。在这种情况下,“职责”可能不是修正缺陷,而是协调附加的备选方法调查,或协调缺陷的解决(如果缺陷范围广大、影响深远)。
Rational Unified Process
|