用途
  • 验证设计模型满足系统上的要求,并验证设计模型可作为实施的良好基础。
  • 确保设计模型与一般设计指南保持一致。
  • 确保设计指南实现自身目标。
角色:技术复审员 
频率:在您复审进行中的工作的“精化”和“构造”阶段,安排在每个迭代中对设计模型进行一次复审。然后,在认为设计模型差不多已完成的“构造”阶段,您应在迭代中安排对设计模型进行详细的复审。您还应该在精化设计模型时的其它阶段(“先启”和“移交阶段”)的每一个迭代中安排一次复审会谈。

参加复审会议的人将最终核准设计模型。在此之前,您可能必须多次复审系统,因为复审的结果无疑会导致更改模型。

步骤
输入工件:   生成的工件:  
工具向导: 
更多信息: 

工作流程明细:  

一般建议 到页首

用途 每次复审的一般建议。

“同级”复审人员的人员配备概要信息与“角色:软件设计人员”相同,但更注重技术问题。领导能力、成熟性、实用性以及结果导向的重要程度相对较低,但还是很重要:复审人员可能会发现一些可能不太普遍、但威胁项目日程安排的设计缺陷。较好的做法还是及早提出关键问题(这时可以解决问题),而不是盲目按照日程安排行事,导致项目团队走上错误道路。设计复审人员需要平衡风险和成本之间的关系,对项目成功的更宽泛问题保持敏感。设计复审人员还需要成为一个有说服力的交流者,能提出并讨论敏感问题。从技术知识的立场出发,设计复审人员需要拥有作为“角色:设计人员”的经验。

复审整个设计模型回到页首

用途 确保设计模型的整体结构形成得很好。
检测无法通过查看低级别元素看到的大范围质量问题。 


设计模型必须进行整体复审,通过分层和职责划分来检测突出的问题。整体复审模型是为了检测更详细的复审将会忽略的大范围问题。

在“先启”阶段和“精化”阶段早期,这种复审将注重模型的整体结构,特别强调分层和接口。应检查包和子系统依赖关系,以确保封装元素之间宽松的结合。应检查包和子系统的内容,以确保封装元素内的高度内聚性。总体而言,应检查所有元素来确保它们的职责清晰、恰当,并确保它们的名称能反映它们的职责。

一旦开发了体系结构原型,就应开展更为综合的设计复审。首先应复审模型的完整性,然后更仔细地寻找缺陷。

复审每个设计用例实现回到页首

用途 确保系统的行为(如设计用例实现中所说的)符合系统所要求的行为(如用例中所说的),即,它完整吗?
确保行为在各模型元素间分配得当,即,它正确吗? 


一旦复审了设计模型的结构,就需要复审模型的行为。首先,通过查看设计用例实现完全覆盖了当前迭代的所有场景,确保不缺少任何行为。相关用例子流程中的所有行为都必须在已完成的设计用例实现中有所描述。

如果系统的行为是事件推动的行为,您就可能使用状态表图来描述用例的行为。在状态表图存在的情况下,则需要检验这些状态表图,以确保它们描述正确的行为,参阅指南:状态表图可了解更多详细信息。 

接着,确保设计用例实现的行为是在实现中的模型元素之间正确分发的:确保操作得到正确使用、所有参数都已传递且返回值的类型正确。

复审每个设计元素 到页首

用途 确保设计元素的内部实施执行了所要求的行为。 

对于每个被分配了行为的设计元素(例如设计类或设计子系统),都必须复审内部设计。对于设计子系统,这意味着确保在开放的接口中指定的行为已分配给一个或多个包含的设计元素。对于设计类,这意味着每个操作的描述都是充分定义的,这样就可以明确地实施该操作。

复审设计指南 回到页首

用途 确保与设计相关的项目特定指南保持最新状态,并纠正指南中存在的缺陷。 


基于设计复审,在设计指南中查找缺陷。

  • 遵照指南了吗?如果没有,那是为什么?
  • 它们正确吗?检测到由于错误的指南而造成的系统缺陷吗?
  • 它们完整吗?如果提供指导信息,系统缺陷会减少吗?

准备复审记录并记录缺陷 回到页首

用途 记录复审结果。
确保记录已识别的缺陷。 


每次复审会谈后,会谈的结果就记录在复审记录中。此外,任何缺陷都按照项目的变更管理流程进行记录。



Rational Unified Process   2003.06.15