 [基础知识]RUP四个阶段 |
RUP for System z 路线图
RUP for System z 路线图遍历了一个典型 System z 开发项目的所有阶段（先启，精化，构建和产品化）。 RUP for System z 生命周期如图 1 所示。路线图提供了对途中每个元素的一个概览。 500)this.width=500'>
图 1： RUP for System z 路线图
图 1 中每个迭代中的活动可以顺序或者按照任何次序执行。 事实上，在 RUP 中，一次迭代不一定是一个活动序列；它可以是一个活动的多方面组合，包括一些可能并行完成的活动。
先启阶段
先启阶段的主要目标是在项目范围内的所有涉众之间达成一致，以确保项目是值得做并且是可能做的。先启阶段包括了达到生命周期目标里程碑的许多迭代。
在先启阶段的一个典型迭代包括以下活动，如图 1 所示：
构思新项目。 这项活动将项目从一个想法的初始雏形带到一个合理的决策点上，以决定继续项目或是废弃项目。
准备项目环境。 此项活动为项目准备了开发环境，开发环境既包括过程，也包括工具。
定义需求。这项活动涵盖了项目远景的定义。 它驱动了系统范围的一致，并概括出了核心需求。 需求可以使用用例的形式进行描述。 在先启阶段，主要的用例被识别出来，并被简要描述。 不适合放在用例中的需求（功能性和非功能性）应当在补充规约中进行文档化。 一旦确定了一些用例和补充规约，就可以决定它们的开发次序。 例如，描述一些重要功能的用例，包含重要架构覆盖（例如，它们运用了许多架构元素）的用例，以及说明或强调一个特定且重要的架构点的用例，将会被首先开发。
执行构架概念论证。 此选项活动关注于通过构建一个架构概念论证来证明解决方案的可行性，并评估架构上重要需求的生存力。
计划项目。 此项活动从当前迭代的评估和风险的重新评估开始进行。 它提炼了软件开发计划（覆盖了所有项目阶段和迭代），并创建了一个良好而成熟的迭代计划，用于下一个迭代或以后的迭代。 此项活动也驱动了必要资源（包括人员）的获取，以执行即将到来的一个或多个迭代。
在先启阶段的末尾，生命周期目标里程碑按照以下的标准来评估项目：
在范围定义上的涉众协作
正确的需求集已经被捕获的协定
成本或进度估算，优先级，风险以及开发过程是否合适的协定
所有风险已经被识别，并且每个风险都有缓解策略的协定。
在先启阶段里程碑处的一些基本工作产品的状态是：
业务用例（100％完成）
远景（几乎100％完成）
词汇表（大约40％完成）
软件开发计划（大约80％完成）
首次精化迭代的迭代计划（计划100％完成）
风险列表（大约25％完成）
用例模型（大约20％完成）
补充规约（大约20％完成）
测试计划（大约10％完成）
软件架构文档（大约10％完成）
构架概念证明（一个或多个概念论证原型可以用于处理非常特定的风险）
精化阶段
精化阶段的主要目标是对系统架构进行基线化，为在构建阶段中的大量设计和实现工作提供一个稳定的基础。 这个构架的稳定性是根据一个或者多个构架原型来评估的。 精化阶段包括许多生命周期构架里程碑处的迭代。
在精化阶段的一个典型迭代包括以下活动，如图 1 所示：
提炼需求。 此活动以用例的形式详细说明了系统的需求。 只有在当前迭代范围内的用例被详细描述，以达到迭代的目标。 余下的用例将在后续的迭代中被详细描述。 不适合放在用例中的需求（功能性和非功能性）应当在补充规约中进行详细描述。
定义架构。 此活动从定义一个备选架构（初始的系统组织结构）开始，识别可重用资产，定义架构模式，识别架构上重要的用例，以及在每个上面执行用例分析（也称作用例实现）。 此活动包括识别必要的概念分析元素，以表示每个用例的行为。 一旦定义了一个备选架构，就可以通过从分析活动转到设计活动，来精炼架构。 概念分析元素被细化成为设计元素，比如模块或者类（例如，图 4 中的模块的例子）。目标也是描述系统运行时的组织结构和部署架构，并维护架构的一致性和完整性。 此活动以最终架构的评审作为结束，在软件架构文档中进行文档化。 注意，架构和设计使用统一建模语言（UML） 9 进行文档化。 UML 图允许您建模面向对象和非面向对象的元素，如模块。
设计组件。 此项活动主要关注在迭代计划的识别范围中的一个或多个组件的详细设计。 当包含服务时，此项活动使用服务元素来提炼设计。 当包含数据库时，此项活动识别出要在数据库中保存的设计元素，并设计相应的数据库。 当包含用户界面时，此项活动对用户界面进行模型化和原型化。 此项活动以最终设计的评审作为结束，在设计模型中进行文档化，并且可以选择其它支持模型，如服务模型。
编码和单元测试组件。 此项活动完成了一部分实现，可以交付至集成。 它通过编写源代码，采用已有源代码，编译，链接以及执行单元测试，实现设计模型中的元素。 如果发现了设计中的缺陷，设计上的返工反馈将被提交出来。 此活动也包括修复代码缺陷和执行单元测试，以验证变更。 代码将被评审，以评估质量以及对编程指南的遵循性。
集成和测试。 此项活动涵盖了产品的集成和测试。 集成子活动集成了来自多个实现的变更，以创建一个实现子系统的新的和一致的版本。 对于在迭代范围内的所有实现子系统，都要完成此活动。 当合适时，此活动也要集成实现子系统，以创建最终系统的一个新的和一致的版本。 测试子活动包括了特定范围内的测试所要求的任务。 范围可以是一个给定的测试级别或测试类型，例如功能验证测试（FVT）或系统验证测试（SVT）。 它可能也受限于组件或部分组件，这些组件已经在迭代中被实现了或被计划要实现。 它包括测试计划的改进，测试用例的定义以及将它们实现为测试脚本（一个测试脚本就是能够执行一个测试用例的一步一步的指南），测试的执行和评估，以及产生的问题的相应报告。 它也包括安装验证过程（IVP）的定义和实现。
计划项目。 参见上面的迭代阶段。
在精化阶段的末尾，生命周期架构里程碑按照以下的标准来评估项目：
产品需求和架构是稳定的。
在测试和评估中所使用的关键方法是被证明的。
可执行原型的测试和评估已经被证明，主要的风险元素已经被确定，并且已经实际被解决。
构建阶段的迭代计划足够详细，使得工作可以继续开展，并被具体的估算所支持。
在当前构架的背景下，如果执行当前的计划能够开发完整的系统，所有的风险承担者们都认为愿景是可以满足的。
实际的资源花费相比已计划的花费是可接受的。
在精化阶段里程碑处的一些基本工作产品的状态是：
词汇表（大约80％完成）
软件开发计划（大约95％完成）
构建迭代的迭代计划（几乎100％完成，至少是第一次迭代）
风险列表（大约50％完成）
用例模型（大约80％完成，取决于迭代目标）
补充规约（大约80％完成，取决于迭代目标）
软件架构文档（几乎100％完成）
设计模型（大约60％完成）
服务模型（大约60％完成）
测试计划（大约30％完成）
测试用例（大约40％完成）
测试脚本（大约40％完成）
实现元素，包括源代码（大约40％完成）
构建是可用的（例如，一个或多个迭代）。
一个或多个可执行架构原型是可用的（以查看重要功能和架构上重要的场景）。
安装验证过程（IVP）（大约80％完成）
构建阶段
构建阶段的主要目标是完成基于已基线化构架的系统的开发。 构建阶段包括许多初始操作性能里程碑处的迭代。
在构建阶段的一个典型迭代包括以下活动，如图 1 所示：
提炼需求。 此项活动以用例和补充规约的形式，完成了系统的详细需求。
设计组件。 此项活动完成了在迭代计划的识别范围中的组件的详细设计。
编码和单元测试组件。 此项活动完成了绝大部分实现，它们可以被交付至集成。
集成和测试。 此项活动涵盖了产品的集成和测试，如精化阶段所描述的。
准备部署。 此项活动定义了部署计划。 其目的是确保系统被成功地送达到用户。 部署计划提供了一个详细的事件进度计划，人员职责，以及必要的事件依赖，以确保对新系统的成功完成。 此活动也包括了用户支持资料的首个草稿版本，以及其它附属资料，包括用户学习、安装、操作、使用和维护系统所需要的全部范围的信息。
计划项目。 参见上面的迭代阶段。
在构建阶段的末尾，初始操作里程碑按照以下的标准来评估项目：
产品发布是足够稳定和成熟，可以在用户环境中部署吗？
是否所有涉众都准备好迁移到用户环境中？
是否实际的资源花费相比已计划花费仍然是可接受的？
在构建阶段里程碑处的一些基本工作产品的状态是：
词汇表（几乎100％完成）
软件开发计划（几乎100％完成）
产品化迭代的迭代计划（几乎100％完成，至少是第一次迭代）
风险列表（大约75％完成）
用例模型（几乎100％完成）
补充规约（几乎100％完成）
设计模型（几乎100％完成）
服务模型（几乎100％完成）
测试计划（大约90％完成）
测试用例（大约80％完成）
测试脚本（大约80％完成）
实现元素，包括源代码（大约95％完成）
构建是可用的（例如，一个或多个迭代）。
可执行系统是可用的。
安装验证过程（IVP）（大约90％完成）
用户支持资料（大约40％完成）
产品化阶段
产品化阶段的主要目标是确保软件对其用户是可用的。 它包括对准备要发布的产品的测试，以及基于用户反馈对软件进行的较小的调整。 此阶段主要关注在产品，配置，安装和易用性问题的细微调整。 产品化阶段包括许多产品发布里程碑处的迭代。
在产品化阶段的一个典型迭代包括以下活动，如图 1 所示：
编码和单元测试组件。 此项活动完成了所有系统实现的剩余部分，它们可以被交付至集成。
集成和测试。 此项活动完成了产品的集成和测试。
执行 Beta 和 验收测试。 此项活动涵盖了产品的 beta 和验收测试。 Beta 测试需要在产品仍处于开发状况下时，来自那些有意愿的用户提出的反馈。 Beta 测试为产品提供了一个受控的，真实世界的测试，这样，来自潜在用户的反馈可以用来形成最终的产品。 它也为有兴趣的顾客提供了下一个发布版本的预览。 验收测试确保产品在正式发布之前，被顾客认为是可接受的。
打包产品。 此项活动构建和打包要发布的产品。 它产生出所有需要有效地学习，安装，操作，使用和维护产品的工件。
计划项目。 在最后的项目迭代期间，要为项目验收评审准备一个最终的状态评估，如果评审成功，将标记为顾客正式接受软件产品的点。 然后，项目经理通过安排遗留资产和重新安排遗留人员，完成项目关闭。
在某些情况下，可能需要更新系统需求和设计。 但是，任何重要的变更，应当被延迟到未来产生的解决方案，以维护其稳定性。 参见上面对精化阶段有关提炼需求和设计组件活动的讨论。
在产品化阶段的末尾，产品发布里程碑按照以下的标准来评估项目：
用户满意吗？
是否实际的资源花费相比已计划花费是可接受的？
在产品发布里程碑处，产品处于生产之中，并且发布后的维护周期开始了。
在产品化阶段里程碑处完成的一些基本工作产品包括：
风险列表
测试计划
测试用例
测试脚本
实现元素，包括源代码
部署单元
构建
用户支持资料
安装验证过程（IVP）
产品
|
阅读全文(3787) | 回复(0) | 编辑 | 精华 |
|
|
| « | December 2025 | » | | 日 | 一 | 二 | 三 | 四 | 五 | 六 | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | | | | |
|
| 公告 |
|
有一种鸟儿是永远关不住的
因为它的每片羽翼上都沾满了自由的光辉
方向:计算机视觉 人工智能 演化算法
| |
| Blog信息 |
|
blog名称:阳光海岸心
日志总数:166
评论数量:237
留言数量:-4
访问次数:1464360
建立时间:2006年6月2日 | |
|