活动:
|
用途
|
|
角色:技术复审员 | |
频率:在您复审进行中的工作的“精化”和“构造”阶段,安排在每个迭代中对设计模型进行一次复审。然后,在认为设计模型差不多已完成的“构造”阶段,您应在迭代中安排对设计模型进行详细的复审。您还应该在精化设计模型时的其它阶段(“先启”和“移交阶段”)的每一个迭代中安排一次复审会谈。
参加复审会议的人将最终核准设计模型。在此之前,您可能必须多次复审系统,因为复审的结果无疑会导致更改模型。 |
|
步骤 | |
输入工件: | 生成的工件: |
工具向导: | |
更多信息: |
工作流程明细: |
用途 | 每次复审的一般建议。 |
用途 | 确保设计模型的整体结构形成得很好。 检测无法通过查看低级别元素看到的大范围质量问题。 |
设计模型必须进行整体复审,通过分层和职责划分来检测突出的问题。整体复审模型是为了检测更详细的复审将会忽略的大范围问题。
在“先启”阶段和“精化”阶段早期,这种复审将注重模型的整体结构,特别强调分层和接口。应检查包和子系统依赖关系,以确保封装元素之间宽松的结合。应检查包和子系统的内容,以确保封装元素内的高度内聚性。总体而言,应检查所有元素来确保它们的职责清晰、恰当,并确保它们的名称能反映它们的职责。
一旦开发了体系结构原型,就应开展更为综合的设计复审。首先应复审模型的完整性,然后更仔细地寻找缺陷。
用途 | 确保系统的行为(如设计用例实现中所说的)符合系统所要求的行为(如用例中所说的),即,它完整吗? 确保行为在各模型元素间分配得当,即,它正确吗? |
一旦复审了设计模型的结构,就需要复审模型的行为。首先,通过查看设计用例实现完全覆盖了当前迭代的所有场景,确保不缺少任何行为。相关用例子流程中的所有行为都必须在已完成的设计用例实现中有所描述。
如果系统的行为是事件推动的行为,您就可能使用状态表图来描述用例的行为。在状态表图存在的情况下,则需要检验这些状态表图,以确保它们描述正确的行为,参阅指南:状态表图可了解更多详细信息。
接着,确保设计用例实现的行为是在实现中的模型元素之间正确分发的:确保操作得到正确使用、所有参数都已传递且返回值的类型正确。
用途 | 确保设计元素的内部实施执行了所要求的行为。 |
对于每个被分配了行为的设计元素(例如设计类或设计子系统),都必须复审内部设计。对于设计子系统,这意味着确保在开放的接口中指定的行为已分配给一个或多个包含的设计元素。对于设计类,这意味着每个操作的描述都是充分定义的,这样就可以明确地实施该操作。
用途 | 确保与设计相关的项目特定指南保持最新状态,并纠正指南中存在的缺陷。 |
基于设计复审,在设计指南中查找缺陷。
用途 | 记录复审结果。 确保记录已识别的缺陷。 |
每次复审会谈后,会谈的结果就记录在复审记录中。此外,任何缺陷都按照项目的变更管理流程进行记录。
Rational Unified Process
|