目的
  • 定义要在当前迭代中分析的一组选定的场景和用例的输入。
  • 定义代表某个重要的中心功能的一组场景和用例。
  • 定义在体系结构上覆盖面广(使用许多体系结构元素)或强调或说明体系结构特定的、精确的点的一组场景和用例。
 
角色: 软件设计人员 
频率:按照要求,通常是对于开始自精化的每个迭代访问一次。
步骤  
输入工件:   结果工件:  
工具向导:  

工作流程明细:  

划分用例和场景的优先级 回到页首

软件设计人员通过选择一定数量的场景和用例进行分析和设计来提议连续迭代的技术内容和顺序。根据人员可用性、客户关于可交付工件的需求、工具和 COTS 产品的可用性以及其它项目的需要,这一技术建议要由各个开发团队来完成和优化。

组成用例视图的场景和用例的选择受一些关键驱动因子的驱动,总结如下。

  • 场景对涉众的好处:关键、重要、有用。
  • 场景的体系结构影响:无、扩展、修改。可能有一些关键用例对体系结构没有或几乎没有影响,而好处不大的用例却有很大的影响。对体系结构有大影响的好处不大的用例应该由项目经理复审以便可以考虑删除。
  • 要减轻的风险(性能、产品的可用性以及组件的适合性)。
  • 体系结构的覆盖面的完整(确保在“精化”阶段结束时,要开发的软件的每一部分都在实施视图中有自己的位置)。
  • 其它战术性目标或约束:到最终用户的演示等。

可能会有两个场景拥有相同的组件并面对类似的风险。如果先实施 A,那么 B 从架构的角度讲就不重要了。如果先实施 B,那么 A 从架构的角度讲就不重要了。所以这些属性可能依赖于迭代顺序,并且应该在顺序发生变化时以及需求本身发生变化时进行重新评价。

这些驱动因子应该当作需求的属性捕获,这样就可以有效地管理它们。

应当对架构上很重要的、很难理解或可能变化的用例划分优先级,以得到澄清和稳定。在有些情况下,这意味着应该在实施需求前先进行进一步的需求分析。在另外的情况下,某种形式的原型设计可能是最适合的。

记载用例视图 回到页首

在软件体系结构文档的用例视图部分记载用例视图。该部分包含了用例模型中每个包内的重要用例和场景的列表,以及一些重要属性,如事件流程的说明、关系、用例图和与每个用例相关的特殊需求。请注意,如果用例视图在迭代早期形成,那么有些属性可能尚未存在。

 

评价您的结果 回到页首

在这个阶段应该检查用例视图来验证工作是否在正确的轨道上,而不是详细复审用例视图。请特别参阅活动:复审体系结构中的用例视图检查点。



Rational Unified Process   2003.06.15