RUP迭发计划的两种方法

李华玲

2009年5月14日发布

随着技术的飞速发展和市场的快速变化，应用软件项目的交付越来越面临着要求不明确，交付时间表紧张，项目风险高，项目规模大，项目团队协作困难和客户参与度更高的问题. 问题. 在这种情况下，RUP的迭发方法已成为应用软件开发项目的主流开发模型，并且可以有效地解决这些问题. 但是本文不会完全讨论RUP在整个软件开发过程中的贡献以及如何应用RUP. 仅从项目管理和项目计划的角度来看，如何应用RUP的迭代方法来制定项目计划.

作者在多个项目中使用RUP来开发和管理软件项目. 在本文中，我将结合实际说明RUP迭代计划的两种开发方法，它们对指导项目经理削减和应用RUP具有实际参考意义. 本文还将与读者分享如何在实际项目中使用RUP来制定迭代目标，如何制定迭代计划以及介绍两个不同迭代计划的模板参考示例.

迭发是RUP的核心思想，但是当您开始使用RUP时，您会发现这么多并行工作流也给项目管理带来了巨大的挑战和困难. 因此，使用RUP来完成项目，开发迭代计划是实施中的主要困难之一.

迭代计划的特征:

制定迭代计划时要考虑的因素:

上述迭代计划是实现RUP的困难之一，因此设置迭代目标是解决此难题的关键.

RUP开发项目的迭代目标主要基于项目开发周期中迭代之后发布的可交付成果. RUP的迭代可交付成果通常是可以运行的系统，包括需求验证原型，体系结构验证原型，功能验证原型，测试系统，最后是产品.

在项目的早期迭代中，主要发布了原型系统和原型体系结构. 在项目的中间，主要发布了增量功能和业务模块. 在项目的后期，主要使用增量业务功能和测试. 系统对非功能性要求，缺陷主要进行修改. 当然，对于不同的项目类型，迭代目标的设置也不同. 例如，系统软件产品开发项目和应用软件开发项目，新软件产品开发和软件系统升级项目有很大的不同. 此外，影响迭代目标的另一个重要因素是项目需求和体系结构的成熟度，需求的清晰程度以及个性化需求和共同需求的比率，这是影响项目风险和迭发目标的重要因素. . 还有所使用的体系结构和技术，这也是影响的重要因素之一. 因此，设置迭代目标需要结合并考虑项目的总体目标以及所使用的不同体系结构方法，例如SOMA（IBM SO A项目的面向服务的建模）和Architecture）面向服务的建模和体系结构

通常来说，项目范围或需求，架构和决策以及总体项目目标是设置迭代目标的重要输入. 例如，原型迭发的迭代目标可以定义如下:

RUP开发过程模型对项目管理和项目计划提出了更高的要求. 迭代计划的质量直接影响项目目标的实现，项目风险和生产效率. 如何更好地平衡和组织项目中的许多并行活动并分配不同的项目角色，对项目管理构成了巨大挑战.

根据RUP在许多项目中的应用和实践，我总结了两种迭代计划的开发方法. 当然，这两种方法不能单独或分开使用. 在不同项目或同一项目的不同阶段中，它们可以互换甚至组合使用.

下面介绍这两种方法的内容，区别和应用.

以时间为轴的迭代计划也是使用RUP制定总体项目计划的主要方法. 根据项目周期，它分为软件开发的初始阶段（初始阶段），精化阶段（精化阶段），构建阶段（构造阶段）和产品化阶段（过渡阶段）. 一般来说，这四个阶段是项目开发生命周期的主要里程碑，而改进的迭代阶段则是项目的第二级里程碑.

迭代计划是在每个里程碑下按时间顺序设置不同的开发迭代，以满足里程碑的要求并实现里程碑的目标. 例如，通常在初始阶段有1-2个迭代周期，在优化阶段有2-4个迭代周期. 当然，应根据项目的类型，项目的大小和项目的特征来选择迭代周期数. 通常，对于要求不明确的应用软件开发项目，在优化阶段通常会有更多的迭代，而在产品转移阶段通常会有更少的迭代. 对于软件系统升级项目，在构建阶段通常会有更多的迭代.

迭代周期（Duration）也是制定迭代目标时要考虑的一个因素. 迭代周期还基于项目的总长度来确定合理的周期. 通常，2周至2个月是一个合理的选择. 在同一项目中，迭代周期的长度可以有所不同，但是从总体经验来看，相对固定的设置从项目管理和项目团队工作的角度来看更合适，并且可以保持更好的项目工作节奏.

确定迭代次数和迭代周期通常是对设置迭代目标的补充. 综合考虑，在迭代目标和周期完成后，项目管理人员可以制定项目迭代计划.

在以时间为轴的迭代计划中，通常将多个工作流（工作流）集成到一个计划中. 项目团队中存在分工，但并未强调明显的分工. 此方法通常适用于人员少的项目早期阶段. 在项目的中后期，通常会结合以软件工程过程和角色为轴的计划方法. 在这种方法下，对于迭发周期，它更像是一个小瀑布模型. 迭代之间没有重叠（重叠），并且它们是串行执行的. 具体示例如下:

当项目规模较大且团队中的角色划分相对清晰时，迭代式开发活动通常难以在计划中进行管理和监视. 目前，该项目通常以软件工程过程或开发角色为轴来组织迭发计划.

根据RUP的工程过程，项目中将进行以下类型的活动:

业务建模，需求分析，分析和设计，实施开发，测试，部署，配置和变更管理，项目管理以及环境.

理论上，每个软件工程过程将对应一个单独的计划，并且每个软件工程过程将定义自己的迭代周期和迭代次数. 当然，这个单独的计划只是相对独立的. 一方面，它必须与总体项目集成计划相一致，另一方面，还必须考虑对其他软件工程过程计划的依赖性. 项目经理的一项重要职责就是识别并管理这些依赖关系，以确保项目的顺利进行.

对于上述9个软件工程过程，不必与9个单独的子计划相对应. 在一般应用软件开发项目中，根据团队的角色迭代的开发计划，各个团队通常分为以下几个单独的计划: <

可能有多个软件开发计划，例如在一个项目中开发多个子系统，开发团队相对较大，一般分为子系统1开发计划，子系统2开发计划，分别组织和实施. 在这种情况下迭代的开发计划，迭代计划之间存在重叠，并且项目计划活动的执行是并行进行的.

具体示例如下:

下表比较了这两种方法，并总结了不同方法在不同应用场景中的应用，作为项​​目经理选择和采用的基础:

两种方法的比较总结了适用于场景时间轴和迭代计划角色轴的迭代计划工作流

合适的项目规模

任何事情

所有或大型项目

适合项目团队的规模

小团队

大团队

合适的项目阶段

所有或早期项目

项目中期

内部依赖性，串行执行

团队或计划之间的依赖性，并行执行

管理难度

中低

高

总而言之，在项目中，项目经理和项目经理经常根据项目的特定条件和项目的阶段采用不同的迭代计划开发方法. 他们甚至将两者结合起来，制定了适合该项目的迭代计划，从而降低了项目风险，提供了项目团队的协作能力，提高了生产效率，并实现了快速交付的目标.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-219318-1.html