《Ｒational统一过程引论》学习笔记

工作流示意：









迭代开发：





Rational软件开发的几个阶段：

l
初始阶段：

１、主要目的：

ü
确定项目的软件范围和边界条件，包括一个可操作的概念、可接受的准则和关于什么是产品目标以及什么不是产品目标的详尽描述。

ü
识别系统的关键用例。即一个主要行为情景，它将驱动系统的功能性并决定主要设计权衡。

ü
展示或者示范至少一个针对主要情景的候选构架。

ü
估计整个项目需要的费用和时间表，并对下一阶段------细化阶段给出详细的评估。

ü
评估风险（不确定性的来源）。

２、主要活动

ü
系统化地明确表述项目的范围------即捕获项目的语境、最重要的需求及限制，以便获得对于最终产品的接受准则。

ü
计划并准备一个业务用例并评价风险管理、人员配备、项目计划和权衡与成本、进度和盈利之间的各种不同的可供选择的方法。

ü
合成一个候选构架，评价有关设计因素的各种权衡，并评估制作、买进、重用作出的对策，以便估算成本、进度及所需资源。

３、产出以下成果：

ü
一个构想文档，即关于项目核心需求、关键特性和主要限制的构想。

ü
一个有关用例模型的调查，其中包括了所有在此阶段可以确定的用例和参与者。

ü
初期的项目术语。

ü
一个初始的业务用例，其中包括：（１）业务环境（２）关于是否成功的评判标准（项目收入、市场认识等）（３）经济预测

ü
一个早期的评估。

ü
一个可以显示阶段和迭代的项目计划。

此外还可能有以下成果：

ü
在初始开发周期完成最初的用例模型。

ü
一个比术语表更详细的领域模型。

ü
如果需要的话，可应有一个业务模型

ü
一个初步的开发案例描述，用于详细说明将用到的过程。

ü
一个或几个原型。

４、里程碑：生命周期目标。评价初始阶段的准则如下：

ü
项目相关人员是否已合作定义项目范围，并估计成本和制定进度安排。

ü
通过需求理解对于主要用例的忠实度来需求理解是否正确。

ü
对于成本和进度安排的评估以及优先权、风险、开发过程等的可信度。

ü
任何已开发的构架原型的深度和宽度。

ü
实际成本与计划成本对比。

l
细化阶段

ü
细化阶段的目标是分析问题领域、建立合理的构架基础、确定项目计划、评价项目的最有可出现风险因素。为了完成这些目标，必须对系统有一个“一公里远一寸深”的认识。要对整个构架做出决定必须对整个系统有着深刻的理解：它的范围、主要功能性及非功能性需求（如性能）。

细化阶段在四个阶段中最关键。在这个阶段结束的时候，艰难的“软件工程”就被　认为结束了，整个项目经历了估算中最重要的时期：决定是否进入构造和移交阶段。

对于大多数项目，也就意味着从不稳定的、灵活的低风险运作阶段进入到高投入、具有巨大的惯性的高风险运作阶段。尽管开发过程必须不停地适应变化，细化阶段的活动还是要确保构架、需求、计划有足够的稳定性，并确保风险已最大限度地降低。因此可以有预见性地确定要完成整个开发所需要的成本和进度安排。理论上讲，预测的正确性将决定项目是否要进入到下一个固定价格的构造阶段。

在细化阶段将完成一个可执行的构架原型，完成这个原型所需的迭代阶段数依赖于项目的范围、规模、风险和新意。这项工作至少应该完成在初始阶段定义的关键用例，这些用例提示了项目中主要的技术风险。尽管目标总是一个符合生产质量组件的进化原型，但也不排除生产一个或多个抛弃原型，以缓解具体的风险或者在设计与需求之间进行权衡。同时，我们还要对可行性进行研究，并给投资者、顾客和最终用户做示范演示。

1.
本阶段目标：

ü
以实际所能达到的最快速度定义、确认构架并将其基线化。

ü
设置构想的基线。

ü
为构造阶段的高可信度计划设定基线。

ü
演示说明基线构架可以在合理的时间以合理的费用支持这个构想。

2.
注要活动：

ü
细化构想，建立对大多数关键用例的确定理解，这些关键用例将驱动做出最终构架和计划决定。

ü
细化过程、基础设施、开发环境，而且过程、工具和自动支持也都各就各位。

ü
细化构架并选择组件。评价潜在组件，很好地理解制作、买进、重用决定，这样就可以非常有信心地对构造阶段的成本和进度安排做出决定。根据主要情景集成并评估选择的构架组件。从这些活动中得到的经验教训可能会导致重新设计构架---考虑可替换的设计或重新考虑需求分析。

3.
成果：

ü
一个用例模型（至少完成８０%），其中定义了在用例模型调查中识别出的所有用例、所有参与者，并完成了大部例描述。

ü
补充需求分析，包括非功能性需求和与具体用例不相关的所有需求。

ü
一个软件构架描述。

ü
一个可执行的构架原型。

ü
一个修改过的风险清单和修改过的业务用例。

ü
一个关于整个项目的开发计划，包括粗线条的项目计划。这个项目计划显示了迭代过程和每个迭代过程的评价准则。

ü
一个已更新的开发案例，其中详细描述了将要用到的过程。

ü
一个初步的用户手册（可选）

4.
里程碑：生命周期构架。主要评判准则涉及到对以下问题的回答：

ü
产品构想是否稳定？

ü
构架是否稳定？

ü
可执行的演示中，主要风险因素是否已经确定处理并已确实解决？

ü
构造阶段计划是否足够详细精确？估计是否建立在可信的基础上？

ü
假如在今后的开发中执行现行的开发计划，在当前的构架语境中产生最终的完整系统，是否所有的项目相关人员都认可当前的构想？

ü
实际的资源消耗相对于计划消耗来说是否可以接受？

l
构造阶段

在构造阶段，所有保留下来的构件和应用程序特征将被开发并集成以形成产品，而后所有的特征将被彻底测试。本阶段就是一个制造过程。重点放在管理资源和控制操作上。管理的重点将从初始和细化阶段的智能特性的开发转移到构造和移交阶段的实施产品开发上。

很多足够大的项目可以平等构造增量。这些平行活动可能很大程度上提高实施版本的可用性；它们可以增加资源管理和工作流同步的复杂性。一个健壮的构架与能被精确理解的计划具有高度相关性。也就是说，构架的关键质量之一就是容易构成该构架。这也是在细化阶段强调平衡开发构架瑟计划的一个重要原因。

1.
主要目标：

ü
通过优化资源和避免不必要的浪费和返工，降低工发成本。

ü
以实际最快的速度提高产品质量。

ü
以实际最快的速度生产一个可用的版本。

2.
基本活动：

ü
资源管理，资源控制和过程优化。

ü
完成构件开发并根据已定义的评价准则进行测试。

ü
针对根据构想制定的接受准则对发布的产品进行评估。

3.
成果：

ü
在适当的平台上集成的软件产品。

ü
用户手册

ü
对当前版本的描述。

4.
里程碑：最初运作能力。评价准则涉及到对以下问题的回答：

ü
这个产品版本是否足够成熟稳定，可以在用户群中进行实施？

ü
是否所有的项目相关人员都已经准备好将产品向用户群推广？

ü
实际的资源消耗相对于计划消耗是否可以接受？

l
移交阶段

移交的目的是将软件产品移交给用户群。当产品移交给最终用户后，新出现的问题通常会促使你重新开发一个版本。

这个阶段包括以下几个方面：

ü
进行Ｂeta测试，确认新系统与用户的期望一致。

ü
平行操作的项目，将要替代遗留系统。

ü
培训用户和维护人员。

ü
产品的首次展示。

1.
主要目标：

ü
达到用户自我可支持的程度。

ü
项目相关人员合作完成实施基线，并与构想的评价准则相一致。

ü
以实际可能的最快速度和最高效益达到最终的产品基线。

2.
主要活动：

ü
与实施有关的特定工程------即结尾工作、商业包装和生产、销售展示以及训练专业人员。

ü
调整活动，包括修复缺陷以及为了提高性能和可使用性而作的添加。

ü
根据产品的构想和接受准则评估实施基线。

3.
里程碑：产品发布。主评戏对以下问题的回答：

ü
用户是否满意？

ü
实际的资源消耗相对于计划消耗是否可以被接受？

瀑布式开发模型对于没有多在风险、并且使用众所周知的技术和领域的小项目非常适用，但是它不用于开发周期长、新意大、、风险高的项目。

迭代过程将开发周期分解成连续的迭代周期。每个迭代过程看起来像一个小的瀑布式模型，其中包括了需求分析、设计、实现和评估等各项活动。

为了控制整个项目并明确每个迭代过程适当的焦点，开发周期被分成四个连续的阶段，即初始、细化、构造、移交阶段，其中每阶段又划分成若干个迭代过程。

迭代方法可以适应需求和实现策略中的变更，可以使我们尽早地面对并缓解风险。开发组织还可能通过这种方法不断成长、学习和提高。迭代方法中注重真实的、明确的目标。