活动:
|
目的
|
角色: 软件设计人员 |
频率:按照要求,通常是对于开始自精化的每个迭代访问一次。 |
步骤 |
输入工件: | 结果工件: |
工具向导: |
工作流程明细: |
软件设计人员通过选择一定数量的场景和用例进行分析和设计来提议连续迭代的技术内容和顺序。根据人员可用性、客户关于可交付工件的需求、工具和 COTS 产品的可用性以及其它项目的需要,这一技术建议要由各个开发团队来完成和优化。
组成用例视图的场景和用例的选择受一些关键驱动因子的驱动,总结如下。
可能会有两个场景拥有相同的组件并面对类似的风险。如果先实施 A,那么 B 从架构的角度讲就不重要了。如果先实施 B,那么 A 从架构的角度讲就不重要了。所以这些属性可能依赖于迭代顺序,并且应该在顺序发生变化时以及需求本身发生变化时进行重新评价。
这些驱动因子应该当作需求的属性捕获,这样就可以有效地管理它们。
应当对架构上很重要的、很难理解或可能变化的用例划分优先级,以得到澄清和稳定。在有些情况下,这意味着应该在实施需求前先进行进一步的需求分析。在另外的情况下,某种形式的原型设计可能是最适合的。
在软件体系结构文档的用例视图部分记载用例视图。该部分包含了用例模型中每个包内的重要用例和场景的列表,以及一些重要属性,如事件流程的说明、关系、用例图和与每个用例相关的特殊需求。请注意,如果用例视图在迭代早期形成,那么有些属性可能尚未存在。
在这个阶段应该检查用例视图来验证工作是否在正确的轨道上,而不是详细复审用例视图。请特别参阅活动:复审体系结构中的用例视图检查点。
Rational Unified Process
|