里程碑:
|
必需工件(按重要性排序) | 里程碑处的状态 |
---|---|
原型 | 已创建一个或更多可执行体系结构原型,以探索关键功能和在体系结构方面重要的场景。请参阅建立原型的作用下方的注释。 |
风险列表 | 已更新并复审。新的风险可能在本质上是体系结构方面的,主要与非功能需求的处理有关。 |
开发流程 |
已根据先前的项目经验优化了开发流程(包括所有特定于项目的指南和模板),且开发流程的定义足以使构造阶段能够继续。 |
开发基础结构 |
构造的开发环境已就位,包括用于流程的所有工具和自动化支持。 |
软件体系结构文档 | 已创建并构建基线,包括在体系结构方面重要的用例的详细描述(用例视图)、关键机制和设计元素的确定(逻辑视图)以及进程视图和部署视图如果系统是分发式的或必须处理并发问题)。 |
设计模型(和所有组成工件) | 已定义并构建基线。已定义在体系结构方面重要的场景的设计用例实现并且已将所需行为分配至适当的设计元素。已确定组件并充分理解关于“自制/购买/重用”的决策,以有信心地确定构造阶段成本和进度安排。对照主要场景集成和评估选定的体系结构组件。从这些活动中得到的经验教训将导致重新设计体系结构,考虑可选的设计或重新考虑需求。 |
数据模型 | 已定义并构建基线。已定义并复审主要数据模型元素(例如,重要实体、关系和表等)。 |
实施模型(和所有组成工件,包括实施元素) | 已创建初始结构并创建主要组件原型。 |
远景 | 根据该阶段获得的新信息得到优化,建立对驱动体系结构和计划决策的最关键用例的可靠理解。 |
软件开发计划 | 得到更新和扩展以涵盖构建和移交阶段。 |
迭代计划 | 已完成并复审构造阶段的迭代计划。 |
用例模型(参与者,用例) | 用例模型(大约完成了 80%),已在用例模型调查中确定了所有用例,已确定了所有参与者并开发了大部分用例描述(需求捕获)。 |
补充规范 | 已记录并复审补充需求,这些需求捕获非功能需求。 |
可选工件 | 里程碑处的状态 |
业务用例 | 如果体系结构调查揭示了要更改基本项目假设的问题,则进行更新。 |
分析模型 | 可作为正式工件进行开发;通常不会正式进行维护,而演化为设计模型的早期版本。 |
作为一种减少风险的策略,Rational Unified Process 使软件设计人员和项目经理能够自由构建几种类型的原型(请参阅概念:原型)。这些原型中的某些原型可能纯粹是试验性质的,随后就被丢弃。但是,有可能(对较大或无先例的系统,则是肯定)以一系列演进原型来构建体系结构,这些原型涵盖精化进行中的各种不同问题,并在精化结束时在集成、稳定的体系结构基础中达到顶点。这并不意味着我们建议精化期间的建立原型工作应导致一组需要集成的体系结构片断。
Rational Unified Process
|