RUP之动态结构:迭代开发

迭代过程一般分为四个阶段:初始、细化、构造和移交,简称为I,E,C和T。每个阶段以一个重要的里程碑(milestone)结束。 

RUP之动态结构:迭代开发

初始(Inception)阶段

确定最终产品的构想及其业务用例、并定义项目范围

初始阶段以生命周期目标(LCO)里程碑为结束点

细化(Elaboration)阶段

计划出必须完成的活动和需要的资源;详细说明产品特性并设计架构

细化阶段以生命周期构架(LCA)里程碑为结束点 

构造(Construction)阶段

构造整个产品,逐步完善视图、构架和计划,直到产品(完整的构想)已完全准备好交付给用户。

构造阶段以最初运作能力(IOC)里程碑为结束点。

移交(Transition)阶段

移交产品给用户,包括制造、交付、培训、支持及维护产品,直至用户满意。

移交阶段以产品发布版本里程碑为结束点,这也是整个周期的结束点。

 

I,E,C,T这四个阶段构成了开发周期,当周期结束时产生一代软件产品。

软件产品重复IECT这个过程,从而发展成为下一代产品。

周期与周期之间是可以存在时间重叠的。一个周期的初始与细化阶段与上一个周期的移交阶段可能是同时进行的。

从一个迭代过程到另一个迭代过程,从一个阶段到另一个阶段,重点关注的活动是不同的。初始阶段,焦点主要放在理解所有的需求并决定开发工作量的范围上。 细化阶段,焦点放在需求上。一些软件设计和实施的目标是开发构架原型,用来缓解特定技术风险并学习运用特定的工具和技术。此构架原型将作为下一阶段的基线。构架阶段,焦点放在产品的设计与实现上。这时,可以在最初的构架原型基础上生产出第一个可以运行的产品。 移交阶段,焦点是确保系统保持预期的质量水平;修复缺陷、培训用户、调整特性、增加遗漏掉的元素。至此,交付最终产品。

 

初始阶段:

主要任务:

令所有的项目相关人员对生命周期目标达成一致意见。

主要目标:

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

识别系统的关键用例——即主要行为情景

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

估计整个项目需要的费用和时间表,并对下一阶段给出评估

评估风险(不确定性的来源)

主要活动:

系统化地明确表述项目的范围——即捕获项目的语境、需求及限制。

计划并准备业务用例,评价风险管理、人员配备、项目计划,权衡成本、进度和利润。

合成一个候选构架,评价有关设计因素,评估制作/买进/重用的对策,以估算成本、进度和需要的资源。

成果和制品 :

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

一个关于用例模型的调查,包括所有在此阶段可以确定的用例和参与者

初期的项目术语

一个初始的业务用例,包括 业务环境 、关于是否成功的评价标准(项目收入、市场认识等) 、经济预测

一个早期的风险评估

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

可能还会产生以下制品:

完成10%-20%的用例模型

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

一个业务模型

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

一个或几个原型

生命周期目标里程碑:

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

是否定义了项目范围,估计了成本和制定了进度安排。

评估用例对需求的理解是否正确

评估成本、进度安排、优先权、风险和开发过程的可信度

实际成本与计划成本的对比

 

细化阶段:

主要任务:

分析问题领域、建立合理的构架基础、确定项目计划、评价项目最有可能出现的风险因素。

主要目标:

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

设置构想的基线

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

考虑构想的基线的合理性,即可以在合理的时间内以合理的费用来完成

主要活动:

细化构想,完成和明确大部分的关键用例,这些用例将驱动做出最终构架和决定计划。

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

细化构架并选择组件。

成果和制品:

用例模型至少完成80%,包括定义了在用例模型调查中识别出的所有用例、参与者和大部分用例描述。

补充需求分析,包括非功能性需求

一个软件构架描述

一个可执行的构架原型

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

一个整个项目的开发计划,计划中显示了迭代过程和每个迭代过程的评价准则。

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

一个初步的用户手册(可选的)。

生命周期架构里程碑:

生命周期构架里程碑检验细化的系统目标和范围、构架的选择以及主要风险的解决方案。

评价准则:

产品构想是否稳定? 构架是否稳定? 可执行的演示中,主要风险因素是否已经确实处理并解决? 构造阶段计划是否足够详细精确?估计是否建立在可信的基础上? 后继开发人员是否会认可当前的构想? 实际的资源消耗相对于计划消耗来说是否可以接受

 

构造阶段:

主要任务 :

所有保留下来的构件和应用程序特征将被开发并集成以形成产品,而后所有的特征将被彻底测试。

主要目标:

优化资源和避免不必要的浪费和返工,降低开发成本。

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

以实际最快的速度生产一个可用的版本(beta) 

主要活动 :

资源管理、资源控制和过程优化

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

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

成果和制品 :

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

用户手册

对当前版本的描述

最初运作能力里程碑:

最初运作能力里程碑要明确软件、场地、用户是否都准备好正常运行而没有将项目暴露在高风险下,这个版本通常被称为beta版本。

评价准则:

这个产品版本是否足够成熟稳定,可在用户群中实施? 是否所有项目相关人员都准备好将产品向用户群推广? 实际的资源消耗相对于计划消耗是否可以被接受?

 

移交阶段:

主要任务:

将软件产品移交给用户群,具体包括:

Beta测试,确认系统与用户的期望是否一致

平行操作项目,取代一流系统

转换运行的数据库

培训用户和维护人员

产品的首次展示

主要目标:

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

完成实施基线,该基线满足构想的评价准则

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

主要活动:

完成实施工作:结尾工作、商业包装和生产、销售展示以及训练专业人员

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

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

产品发布里程碑:

产品发布里程碑判断本周期目标是否达到,并决定是否要进入下一个新的开发周期。 有些情况下,这个里程碑会与下一个周期的初始阶段的结束点同时发生。

评价准则: 用户是否满意? 实际的资源消耗相对于计划消耗是否可以被接受?

 

RUP之动态结构:迭代开发