软件项目开发流程RUP

软件项目开发流程RUP软件项目开发流程RUP软件项目开发流程RUP资料仅供参考文件编号：2022年4月软件项目开发流程RUP版本号：A修改号：1页次：1.0审核：批准:发布日期：软件项目开发流程RUPRUP（RationalUnifiedProcess，统一软件开发过程，统一软件过程)是一个面向对象且基于网络的程序开发方法论。根据Rational(RationalRose和统一建模语言的开发者)的说法，好像一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针，模版以及事例支持。RUP和类似的产品--例如面向对象的软件过程（OOSP），以及OPENProcess都是理解性的软件工程工具--把开发中面向过程的方面（例如定义的阶段，技术和实践）和其他开发的组件（例如文档，模型，手册以及代码等等）整合在一个统一的框架内。

一、六大经验

迭代式开发。在软件开发的早期阶段就想完全、准确的捕获用户的需求几乎是不可能的。实际上，我们经常遇到的问题是需求在整个软件开发工程中经常会改变。迭代式开发允许在每次迭代过程中需求可能有变化，通过不断细化来加深对问题的理解。迭代式开发不仅可以降低项目的风险，而且每个迭代过程以可以执行版本结束，可以鼓舞开发人员。

管理需求。确定系统的需求是一个连续的过程，开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化，用例和脚本的使用以被证明是捕获功能性需求的有效方法。

基于组件的体系结构。组件使重用成为可能，系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于管理复杂性，提高重用率。RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。

可视化建模。RUP往往和UML联系在一起，对软件系统建立可视化模型帮助人们提供管理软件复杂性的能力。RUP告诉我们如何可视化的对软件系统建模，获取有关体系结构于组件的结构和行为信息。

项目管理论坛

验证软件质量。在RUP中软件质量评估不再是事后进行或单独小组进行的分离活动，而是内建于过程中的所有活动，这样可以及早发现软件中的缺陷。

控制软件变更。迭代式开发中如果没有严格的控制和协调，整个软件开发过程很快就陷入混乱之中，RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。RUP通过软件开发过程中的制品，隔离来自其他工作空间的变更，以此为每个开发人员建立安全的工作空间。二、统一软件开发过程RUP的二维开发模型

RUP软件开发生命周期是一个二维的软件开发模型。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone)；纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow)。转自项目管理者联盟

三、统一软件开发过程RUP核心概念

RUP中定义了一些核心概念，

角色：描述某个人或者一个小组的行为与职责。RUP预先定义了很多角色。

活动：是一个有明确目的的独立工作单元。

工件：是活动生成、创建或修改的一段信息。

四、统一软件开发过程RUP裁剪

RUP是一个通用的过程模板，包含了很多开发指南、制品、开发过程所涉及到的角色说明，由于它非常庞大所以对具体的开发机构和项目，用RUP时还要做裁剪，也就是要对RUP进行配置。RUP就像一个元过程，通过对RUP进行裁剪可以得到很多不同的开发过程，这些软件开发过程可以看作RUP的具体实例。RUP裁剪可以分为以下几步：

1)确定本项目需要哪些工作流。RUP的9个核心工作流并不总是需要的，可以取舍。2)确定每个工作流需要哪些制品。

3)确定4个阶段之间如何演进。确定阶段间演进要以风险控制为原则，决定每个阶段要那些工作流，每个工作流执行到什么程度，制品有那些，每个制品完成到什么程度。

4)确定每个阶段内的迭代计划。规划RUP的4个阶段中每次迭代开发的内容。5)规划工作流内部结构。工作流涉及角色、活动及制品，他的复杂程度与项目规模即角色多少有关。最后规划工作流的内部结构，通常用活动图的形式给出。

五、开发过程中的各个阶段和里程碑RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段(Transition)。每个阶段结束于一个主要的里程碑(MajorMilestones)；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。

1．初始阶段

初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。初始阶段结束时是第一个重要的里程碑：生命周期目标(LifecycleObjective)里程碑。生命周期目标里程碑评价项目基本的生存能力。

项目经理博客

2．细化阶段

细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。为了达到该目的，必须在理解整个系统的基础上，对体系结构作出决策，包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。细化阶段结束时第二个重要的里程碑：生命周期结构(LifecycleArchitecture)里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。

3．构造阶段项目管理者联盟文章

在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。构建阶段结束时是第三个重要的里程碑：初始功能(InitialOperational)里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版。

4．交付阶段

交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。在交付阶段的终点是第四个里程碑：产品发布(ProductRelease)里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。六、统一软件开发过程RUP的核心工作流(CoreWorkflows)

RUP中有9个核心工作流，分为6个核心过程工作流(CoreProcessWorkflows)和3个核心支持工作流(CoreSupportingWorkflows)。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。项目管理培训

1．商业建模(BusinessModeling)商业建模工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象模型中定义组织的过程，角色和责任。

项目管理者联盟文章

2．需求(Requirements)项目经理博客

需求工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。转自项目管理者联盟

3．分析和设计(Analysis&Design)

分析和设计工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。设计类被组织成具有良好接口的设计包(Package)和设计子系统(Subsystem)，而描述则体现了类的对象如何协同工作实现用例的功能。设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化，该视图中省略了一些细节，使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高被创建模型的质量。

项目管理培训

4．实现(Implementation)

实现工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式(源文件、二进制文件、可执行文件)实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。

5．测试(Test)

项目经理圈子

测试工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现,识别并确认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。测试类似于三维模型，分别从可靠性、功能性和系统性能来进行。6．部署(Deployment)

项目管理论坛

部署工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。

7．配置和变更管理(Configuration&ChangeManagement)

配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录。项目经理圈子

项目经理博客

8．项目管理(ProjectManagement)

软件项目管理平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。

9．环境(Environment)环境工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。

七、RUP的迭代开发模式

RUP中的每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环，产生一个可执行的产品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统。传统上的项目组织是顺序通过每个工作流，每个工作流只有一次，也就是我们熟悉的瀑布生命周期。这样做的结果是到实现末期产品完成并开始测试，在分析、设计和实现阶段所遗留的隐藏问题会大量出现，项目可能要停止并开始一个漫长的错误修正周期。项目管理者联盟文章

一种更灵活，风险更小的方法是多次通过不同的开发工作流，这样可以更好的理解需求，构造一个健壮的体系结构，并最终交付一系列逐步完成的版本。这叫做一个迭代生命周期。在工作流中的每一次顺序的通过称为一次迭代。软件生命周期是迭代的连续，通过它，软件是增量的开发。一次迭代包括了生成一个可执行版本的开发活动，还有使用这个版本所必需的其他辅助成分，如版本描述、用户文档等。因此一个开发迭代在某种意义上是在所有工作流中的一次完整的经过，这些工作流至少包括：需求工作流、分析和设计工作流、实现工作流、测试工作流。其本身就像一个小型的瀑布项目。与传统的瀑布模型相比较，迭代过程具有以下优点：

降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。转自项目管理者联盟

转自项目管理者联盟

降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。项目管理者联盟

加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。转自项目管理者联盟

由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。

项目管理培训

八、统一软件开发过程RUP的十大要素

项目管理培训

1.开发前景

2.达成计划项目管理者联盟

3.标识和减小风险

4.分配和跟踪任务转自项目管理者联盟

5.检查商业理由

6.设计组件构架

7.对产品进行增量式的构建和测试

8.验证和评价结果

9.管理和控制变化

10.提供用户支持转自项目管理者联盟

让我们逐一的审视这些要素，看一看它们什么地方适合ＲＵＰ，找出它们能够成为十大要素的理由。1.开发一个前景

有一个清晰的前景是开发一个满足涉众真正需求的产品的关键。前景抓住了ＲＵＰ需求流程的要点：分析问题，理解涉众需求，定义系统，当需求变化时管理需求。前景给更详细的技术需求提供了一个高层的、有时候是合同式的基础。正像这个术语隐含的那样，它是软件项目的一个清晰的、通常是高层的视图，能被过程中任何决策者或者实施者借用。它捕获了非常高层的需求和设计约束，让前景的读者能理解将要开发的系统。它还提供了项目审批流程的输入，因此就与商业理由密切相关。最后，由于前景构成了“项目是什么”和“为什么要进行这个项目”，所以可以把前景作为验证将来决策的方式之一。对前景的陈述应该能回答以下问题，需要的话这些问题还可以分成更小、更详细的问题：关键术语是什么（词汇表）我们尝试解决的问题是什么（问题陈述）涉众是谁用户是谁他们各自的需求是什么产品的特性是什么功能性需求是什么（ＵｓｅＣａｓｅｓ）非功能性需求是什么设计约束是什么2.达成计划

“产品的质量只会和产品的计划一样好。”(2)在ＲＵＰ中，软件开发计划（ＳＤＰ）综合了管理项目所需的各种信息，也许会包括一些在先启阶段开发的单独的内容。SDP必须在整个项目中被维护和更新。ＳＤＰ定义了项目时间表（包括项目计划和迭代计划）和资源需求（资源和工具），可以根据项目进度表来跟踪项目进展。同时也指导了其他过程内容（原文：processcomponents）的计划：项目组织、需求管理计划、配置管理计划、问题解决计划、QA计划、测试计划、评估计划以及产品验收计划。

在较简单的项目中，对这些计划的陈述可能只有一两句话。比如，配置管理计划可以简单的这样陈述：每天结束时，项目目录的内容将会被压缩成ZIP包，拷贝到一个ZIP磁盘中，加上日期和版本标签，放到中央档案柜中。软件开发计划的格式远远没有计划活动本身以及驱动这些活动的思想重要。正如Dwight所说：“plan什么也不是，planning才是一切。”“达成计划”—和列表中第3、4、5、8条一起—抓住了RUP中项目管理流程的要点。项目管理流程包括以下活动：构思项目、评估项目规模和风险、监测与控制项目、计划和评估每个迭代和阶段。

3.标识和减小风险

RUP的要点之一是在项目早期就标识并处理最大的风险。项目组标识的每一个风险都应该有一个相应的缓解或解决计划。风险列表应该既作为项目活动的计划工具，又作为确定迭代的基础。

4.分配和跟踪任务转自项目管理者联盟

有一点在任何项目中都是重要的，即连续的分析来源于正在进行的活动和进化的产品的客观数据。在RUP中，定期的项目状态评估提供了讲述、交流和解决管理问题、技术问题以及项目风险的机制。团队一旦发现了这些障碍物（篱笆），他们就把所有这些问题都指定一个负责人，并指定解决日期。进度应该定期跟踪，如有必要，更新应该被发布。（原文：updatesshouldbeissuedasnecessary。）这些项目“快照”突出了需要引起管理注意的问题。随着时间的变化/虽然周期可能会变化（原文：Whiletheperiodmayvary。），定期的评估使经理能捕获项目的历史，并且消除任何限制进度的障碍或瓶颈。

5.检查商业理由

商业理由从商业的角度提供了必要的信息，以决定一个项目是否值得投资。商业理由还可以帮助开发一个实现项目前景所需的经济计划。它提供了进行项目的理由，并建立经济约束。当项目继续时，分析人员用商业理由来正确的估算投资回报率(ROI，即returnoninvestment)。商业理由应该给项目创建一个简短但是引人注目的理由，而不是深入研究问题的细节，以使所有项目成员容易理解和记住它。在关键里程碑处，经理应该回顾商业理由，计算实际的花费、预计的回报，决定项目是否继续进行。6.设计组件构架项目经理圈子

在RUP中，件系统的构架是指一个系统关键部件的组织或结构，部件之间通过接口交互，而部件是由一些更小的部件和接口组成的。即主要的部分是什么他们又是怎样结合在一起的RUP提供了一种设计、开发、验证构架的很系统的方法。在分析和设计流程中包括以下步骤：定义候选构架、精化构架、分析行为（用例分析）、设计组件。要陈述和讨论软件构架，你必须先创建一个构架表示方式，以便描述构架的重要方面。在RUP中，构架表示由软件构架文档捕获，它给构架提供了多个视图。每个视图都描述了某一组涉众所关心的正在进行的系统的某个方面。涉众有最终用户、设计人员、经理、系统工程师、系统管理员，等等。这个文档使系统构架师和其他项目组成员能就与构架相关的重大决策进行有效的交流。

7.对产品进行增量式的构建和测试

在RUP中实现和测试流程的要点是在整个项目生命周期中增量的编码、构建、测试系统组件，在先启之后每个迭代结束时生成可执行版本。在精化阶段后期，已经有了一个可用于评估的构架原型；如有必要，它可以包括一个用户界面原型。然后，在构建阶段的每次迭代中，组件不断的被集成到可执行、经过测试的版本中，不断地向最终产品进化。动态及时的配置管理和复审活动也是这个基本过程元素（原文：essentialprocesselement）的关键。

8.验证和评价结果

顾名思义，RUP的迭代评估捕获了迭代的结果。评估决定了迭代满足评价标准的程度，还包括学到的教训和实施的过程改进。根据项目的规模和风险以及迭代的特点，评估可以是对演示及其结果的一条简单的纪录，也可能是一个完整的、正式的测试复审记录。这儿的关键是既关注过程问题又关注产品问题。越早发现问题，就越没有问题。（原文：Thesooneryoufallbehind,themoretimeyouwillhavetocatchup.）

9.管理和控制变化

RUP的配置和变更管理流程的要点是当变化发生时管理和控制项目的规模，并且贯穿整个生命周期。其目的是考虑所有的涉众需求，尽可能的满足，同时仍能及时的交付合格的产品。用户拿到产品的第一个原型后（往往在这之前就会要求变更），他们会要求变更。重要的是，变更的提出和管理过程始终保持一致。在RUP中，变更请求通常用于记录和跟踪缺陷和增强功能的要求，或者对产品提出的任何其他类型的变更请求。变更请求提供了相应的手段来评估一个变更的潜在影响，同时记录就这些变更所作出的决策。他们也帮助确保所有的项目组成员都能理解变更的潜在影响。10.提供用户支持

在RUP中，部署流程的要点是包装和交付产品，同时交付有助于最终用户学习、使用和维护产品的任何必要的材料。项目组至少要给用户提供一个用户指南（也许是通过联机帮助的方式提供），可能还有一个安装指南和版本发布说明。根据产品的复杂度，用户也许还需要相应的培训材料。最后，通过一个材料清单（BOM表，即BillofMaterials）清楚地记录应该和产品一起交付哪些材料。关于需求有人看了我的要素清单后，可能会非常不同意我的选择。例如，他会问，需求在哪儿呢他们不重要吗我会告诉他我为什么没有把它们包括进来。有时，我会问一个项目组（特别是内部项目的项目组）：“你们的需求是什么”，而得到的回答却是：“我们的确没有什么需求。”刚开始我对此非常惊讶（我有军方的宇航开发背景）。他们怎么会没有需求呢当我进一步询问时，我发现，对他们来说，需求意味着一套外部提出的强制性的陈述，要求他们必须怎么样，否则项目验收就不能通过。但是他们的确没有得到这样的陈述。尤其是当项目组陷入了边研究边开发的境地时，产品需求从头到尾都在演化。因此，我接着问他们另外一个问题：“好的，那么你们的产品的前景是什么呢”。这时他们的眼睛亮了起来。然后，我们非常顺利的就第一个要素（“开发一个前景”）中列出的问题进行了沟通，需求也自然而然的流动着（原文：andtherequirementsjustflownaturally.）。也许只有对于按照有明确需求的合同工作的项目组，在要素列表中加入“满足需求”才是有用的。请记住，我的清单仅仅意味着进行进一步讨论的一个起点。

项目经理博客

九、总结

RUP具有很多长处：提高了团队生产力，在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础。它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。但同时它也存在一些不足：RUP只是一个开发过程，并没有涵盖软件过程的全部内容，例如它缺少关于软件运行和支持等方面的内容；此外，它没有支持多项目的开发结构，这在一定程度上降低了在开发组织内大范围实现重用的可能性。可以说RUP是一个非常好的开端，但并不完美，在实际的应用中可以根据需要对其进行改进并可以用OPEN和OOSP等其他软件过程的相关内容对RUP进行补充和完善。

RUP与XP的平衡之道Author：SpiderMan（ShenZhen）

From：

Email：

人有过什么经验，遇到过什么恐惧的事，就会形成设法避免这种事情的方法学。研究重型方法学的人可能一直以来的经验就是组织上千人的开发队伍进行开发，比如说大型电信系统的开发、军事航天系统的开发......这种项目严格强调过程执行的规范，注重文档规范、评审及过程度量。而发明XP的人可能一直是在小团队里做项目，项目团队只有3、5个人，项目总是会因为没有满足用户价值而被Cancel，开发公司也蒙受损失，因此注重与用户的交流、反馈，强调快速、灵活。

每种软件方法产生的背景不同、特点不同、适用的领域亦不相同。那么对于软件项目来说，是否可以使用同一种软件开发方法来对不同类型、规模、复杂度的项目来进行开发呢，显然是不合理的。

前不久，恰巧和国内一位资深的软件工程咨询顾问做过一些交流，他本人热衷于RUP的过程改进，倡导针对不同类型项目进行适当的裁剪，实际上这也是一种灵活适应的方式、随需而变的思想。我对此是理解并赞同的，但是我对RUP却一直保持一种相对谨慎的态度。

对于RUP来说，首先，我认为它过于理想化和理论化，RUP是过程组件、方法以及技术的框架，你可以将其应用于任何特定的软件项目，由用户自己限定RUP的使用范围。对于各种类型的软件项目，RUP并未给出具体的自身裁减及实施策略，总有些无依据可循的感觉。你既可以说它能解决任何问题，也可以说它什么都不是；其次，RUP从本质来说还是一个强调设计和规范的软件方法，从这个角度来讲，与传统的瀑布模型没有太大差别，它的灵活性较之敏捷方法还是相对较弱的。在一些小型软件项目、特别是不可预测的软件项目开发中，面临着各种紧急需求、面临着时间压力，沿用RUP是很难应付自如的。但是在另一方面，RUP强调对知识的收集、整理和加工定义，强调在软件开发的时候要有好的体系结构。所以它还是很有利于知识的积累和共享的。

相比RUP

，敏捷方法如XP则更为灵活，倡导尽早的、持续的交付有价值的软件满足用户需要。用交流沟通取代详尽的文档，强调团队的主动、自律、自我组织和自发管理。而XP也是以代码为核心的一种方法，这里有很多的东西是未知的，知识只存在于两个地方：开发者的头脑和最后的代码。对于项目管理者来说，他们会认为敏捷开发方法弱化了知识管理的概念，而实际上敏捷开发注重的是最有价值的知识的积累和沉淀。

如何灵活应对各种项目风险、如何最大化优先满足用户价值、又如何能够有效的控制项目开发过程、如果做好项目过程中的知识管理，是每一个软件项目管理者都需要深入思考的问题。RUP的倡导者一直强调RUP裁剪，实际上我认为RUP不仅仅是需要自身的裁剪，还需要学会融合。在RUP裁剪的同时，适宜的融合敏捷开发的各种实践。不要认为RUP与XP是矛盾的，其实不然，它们具有不同的原理、具有不同的应用领域。在RUP中融合了XP技术时，才会得到过程的正确量，既满足了项目所有成员的需要，又解决了所有主要的项目风险问题。对于一个工作于高信任环境中的小型项目团队，其中用户是团队的一部分，那么XP完全可以胜任。对于团队越来越分散，代码量越来越大，或者构架没有很好定义的情况，您需要做一些其他工作。在用户交互具有"契约"风格的项目中，仅有XP是不够的。RUP是一个框架，可以从RUP出发，在必要时以一组更健壮的技术来扩展XP。

RUP最佳实践包括：1.迭代开发

2．管理需求

3．使用基于组件的构架

4．可视建模

5．持续的质量验证

6．控制变更

12个XP实践包括：有计划的开发：通过结合使用优先级"故事"和技术估算，确定下一版本的功能

小版本：以小的增量版本经常向客户发布软件

隐喻：隐喻是一个简单、共享的"故事"或描述，说明系统如何工作

简单设计：通过保持代码简单从而保证设计简单。不断的在代码中寻找复杂点并且立刻进行移除

测试驱动开发：用户编写测试内容以对"故事"进行测试。程序员编写测试内容来发现代码中的任何问题。在编写代码前先编写测试内容

重构：这是一项简化技术，用来移除代码中的重复内容和复杂之处

结对编程：团队中的两个成员使用同一台计算机开发所有的代码。一个人编写代码或者驱动，另一个人同时审查代码的正确性和可理解性

集体代码所有权：任何人都拥有所有的代码。这就意味这每个人都可以在任何时候变更任何代码

持续集成：每天多次创建和集成系统，只要任何实现任务完成就要进行

每周40个小时：程序员在疲劳时无法保证最高效率。连续两周加班是绝对不允许的

现场客户：一名真实的客户全时工作于开发环境中，帮助定义系统、编写测试内容并回答问题

编码标准：程序员采用一致的编码标准证RUP与XP的融合，是各自特点的相互补充，也是软件开发方法的平衡之道。而对软件技术平衡的思考也可以说是技术成熟的开始吧。最后，再阐明我对软件项目开发的理解。在软件项目开发过程中，应该能够识别、分析不同软件项目的特点，采用相对适合的开发实践来适应软件开发过程，保证对软件开发的有效支持，以便能够创造出“足够好的”软件。而这个足够就是对进度、成本、质量之间的平衡，最大化满足客户需要的实现。

软件开发过程学习总结目的：初步理解CMM、RUP、XP分别是怎样的过程，弄懂其关键步骤，分析其优劣及适应情况。最后综各家之长，给出一个可能较实用可行的软件开发过程体系XProcess，以用在项目(或产品)开发中。ByRobinZhang.一、

CMM1.综述CMM2－CMM3，可以看作是一个严谨的，传统瀑布式的开发体系。CMM并未提供具体的过程体系，它只是一个评价标准(“软件能力成熟度”)。但它提供了一个目标：一个可重复赋值成功经验的开发体系应该是怎样的。知识点：1).通常应该从CMM2开始实现，一般做到CMM3的已经难得了。2).CMM2是一套已定义的项目管理过程，CMM3是总结不同项目的经验，最终形成组织（公司）的一套过程标准。3).可以考虑交叉引用，即上CMM2及CMM3的培训、同行评审。4).CMM与CMMI的区别：前者仅限于软件工程,后者还包括其他学科的CMM，如系统工程等；前者一般意味着瀑布过程，后者支持迭代方法。参考：CMM2:“定义了项目管理过程，将项目划分成几个明确定义的阶段，每个阶段结束都是控制点，增加了软件开发过程的透明度和可控性。项目执行中好的经验可以在别的项目中重复，软件开发有了一定的保证。”CMM3:“是对CMM2项目管理的全面整合和提高，综合公司所有类型项目的过程经验，制定公司统一的最佳过程，增加了对项目每个阶段的内部过程规定和检查点，使得软件开发工程更加透明和可控。”2.关键过程包括：CMM2：项目计划、需求管理、配置管理、质量管理、项目过程控制。CMM3：同行评审(需求、设计、代码评审)、培训计划、体系规范注：能做到上面8项就可以了。

CMM等级关键域KPA对应产出、流程操作相关产出、过程(参考)CMM2需求管理需求基线项目建议书,概要需求,需求评审,需求规格书软件项目计划建立一个合理有效的软件项目计划软件项目立项书、风险分析控制报告等软件项目跟踪和监督项目管理,过程管理任务分解、下达，每日耗费，每周例会，单元测试报告，里程碑等软件配置管理标识软件配置项，建立产品基线库，对配置项的修改加以系统的控制配置管理计划,VSS代码库,版本,代码同步,演示帐套软件质量管理单元测试、功能测试、继承测试等质量保证计划,测试计划,测试用例,产品质量报告,单元测试、功能测试、继承测试等子合同管理外包管理CMM3同行评审

需求评审,设计评审,代码评审培训计划

知识共享,内部培训,VSS共享,创新奖等组织级过程焦点，组织级过程定义，集成软件管理，软件产品工程，组间协调，1.各种规范：需求、分析设计、编码、数据库规范。2.体系规定文档

3.适用情况1).中大型软件企业，同时进行多个项目、产品的研发（必须有一套体系以便管理、控制）。2).需求比较明确，并已经定义冻结的情况，如产品项目。3)适合用瀑布式过程开发的项目。4.优劣优点：体系严谨，提高了软件开发过程的透明度和可控性，令项目成功经验可以重复复制。缺点：因瀑布过程需要，要求需求冻结，导致需求过程要求非常高。而在项目中，需求变更是不可避免的。5.其他企业上到一定规模，偏重产品开发时，可以考虑上CMM。中小软件企业可借鉴并精简地实现它的关键过程，如项目计划、需求管理、配置管理、质量管理、项目过程控制、同行评审、培训计划。

二、

RUP1．

综述RUP是一个由用例驱动、以架构为中心的、迭代增量的开发过程框架。2．

关键过程

迭代开发过程及产出：见：《UML和设计模式》第一页。流程工件初始精化构造交付项目管理软件开发计划等S:1)定义项目目的，范围、约束。2)第一个迭代计划1）

分析需求用例，确定迭代计划(任务时间表)。2）

确定编码等规范3）

需求基线1）按迭代计划进行开发2）每个迭代都实现一个用例集，包含一个设计编码测试过程。客户测试评估上线运行

业务建模领域模型

S细化建模

需求用例模型、需求规格说明书、补充需求文档S:1)确定Actor及其需要。2)确定最重要的用例

R1)编写详细用例需求规格书2)确定更多用户需要、产品特性、用例集合并确定其优先级重要性风险。需求初步基线。r迭代过程中允许需求变更，但必须受控，分析对目前需求的影响，再决定是否在下一个迭代基线进去。

设计设计模型、软件架构文档

R挑选部分重要用例，开始建设计模型R对迭代内的用例进行更详细的设计

实现实现代码

S1）实现部分重要且风险大的用例，以验证并确定架构设计。R全力编码，按时完成迭代内的用例实现。

测试测试用例

S根据用例编写测试用例测试已实现迭代功能，编写新迭代的测试用例

文档等使用文档等

s

产品文档，用户培训产出

项目计划书(前景文档)、高层用例模型、最重要用例规格说明书、(概要设计说明书)、开发环境(总体软件架构、开发规范)80%详细需求规格书(用例集及补充说明书)、用例模型、领域模型及设计模型，部分详细设计文档，部分测试用例，产生一个可执行的原型(实现部分重要用例)内部发版，可用于测试的完整产品。详细设计说明书

产出2

项目计划、概要需求列表、初步架构说明、重要用例需求规格书、编码规范需求规格说明书(80%)，概要设计文档()、项目迭代计划、重要用例的设计及实现,设计模型，详细设计说明书，代码实现，测试用例（迭代）产品、说明文档，用户培训s开始，r精化提炼

3．

适用情况4．

优劣5．

其他参考：

三、

XPXp注重人的因数，提倡尽量敏捷轻量级的过程。重要过程：测试驱动、迭代开发、持续集成构建、客户现场参与(确定迭代内的功能集，提供业务逻辑的确认，验证程序等)、只在必要时做简单设计

一)、Xp的缺点：1.

要求客户现场参与。通常国内项目都是前期作需求确认，无法提供整个开发过程的需求确认支持。除非是分段来确认（如迭代结束时）。2.

测试驱动开发。目前还很难做到，因为编写测试脚本需要花费不少精力，一般项目无法做到。由此也无法作重构，无法保证能有灵活的设计来支持因前期不明确的需求而导致的变更。3.

缺少文档、设计支持。Xp只在必要时才写文档及设计，这样可能导致xp新手缺乏良好的设计指引，项目开发过程透明度不够，可能会失控。二）、xp可借鉴的地方1.

对整个开发过程：迭代开发、持续集成2.

对特定迭代：编码规范、保持设计灵活(允许需求改动)3.

设计编码过程：测试驱动、重构(用在编码过程中，以客户端来“测试驱动”业务逻辑层、以重构减少重复代码)参考：四、实用过程XProcess：RUP+XP，并达到CMM2-3考虑目前国内项目现况：需求调研先行，但需求不明确导致需求变更。中小公司缺乏过程规范指导，基本在CMM1即混乱状态。

XProcess＝CMM的体系+RUP的过程+XP的最佳实践参考文档：,,RUPand,dXProcess

1.

过程：取RUP的过程过程还是取项目启动、细化、构建、交付四个过程。启动阶段：定义项目计划、风险分析、项目前景、范围、约束；确定Actor、涉众及收益；确定概要需求；作一个原型，实现关键用例。细化阶段：确定用户需要、产品特性并确认优先级、风险；确定80%需求，编写需求规格书。制定迭代计划，需求基线；完成重要用例的设计及实现，由此确定系统架构及第三方组件。已制定迭代计划。同时编写对应用例的测试用例。 构建阶段：按计划迭代开发。在每个迭代里采用小瀑布的方式，应用部分XP的最佳实践(见下2)，每个迭代为一个里程碑，提交给客户确认，由此得到需求变更，分析后调整迭代计划。 交付阶段：提交客户测试，作小的修改。编写产品说明，用户培训，上线运行。项目总结、关闭报告。2.

迭代内的步骤：取xp的最佳实践合并细化的后期+构造期，为“设计编程期”，在这期间，启用“保持设计灵活”、编码规范、代码审核(结队编程)、持续集成、测试驱动、重构的最佳实践。3.

使用CMM的关键域的规范流程，，以达到CMM2-3的效果在RUP的四个阶段中，应用CMM的关键域，来保证各种产出的质量。如下：先启阶段：项目计划、项目过程控制、配置管理、培训计划(设计、编码规范)细化阶段：体系规范、同行评审(需求、设计、代码评审)、需求管理、质量管理构建阶段：编码规范、设计、代码评审、需求变更管理交付阶段：体系规范

三者的关系如下：1.

RUP：是由用例驱动、迭代增量开发的过程，主要定义了各个阶段应该做什么，做到什么程度。2.

CMM：是一套评估标准，提供了一些关键实现域(需求管理等)，对每一个产出提出了质量要求。3.

XP：主要关注编码阶段的一些最佳实践。是一个提倡敏捷的轻量级软件开发方法。强调“交流；简单；反馈；实事求是”。强调客户参与，简单设计(灵活设计)、允许需求变更等。4.

下面是按传统瀑布式的过程，来考察三种过程方法在各个阶段的活动及产出。

过程RUPCMMXP项目启动先启项目计划、风险列表、过程控制、配置计划、概要需求列表等客户尽可能参与需求调研先启、精化(用例模型)需求管理、需求评审、需求基线客户尽可能参与分析设计精化、构建(领域模型、设计模型)设计评审、软件配置、培训计划灵活设计、需求变更编码实现构建、启动、精华(代码)代码评审、需求变更控制测试驱动开发、重构、编码规范、日构建、小版本发布、简单实现测试构建、精化质量管理UnitTest文档及实施等交付

RUP与Scrum的对话作者：IBM摘要现在使用RUP的软件项目可以很容易地从Scrum原则中获益，即使已经开始的项目也是如此。首先需要调研的是RUP过程模型，Scrum如何影响RUP最好的实践活动，四个阶段（初始，细化，构建和产品化），以及RUP的九个原则。

来自于RationalEdge：本文介绍了被称为Scrum的灵活软件开发过程。作者阐述了软件开发团队在已有RUP环境中加入Scrum理念的技术。

正如你所知道的，RUP（RationalUnifiedProcess，Rational统一过程），是一种被广泛使用的软件过程框架。它可以很好地迎合你的软件开发过程的需要，还可以容纳其他技术。Scrum是一系列有趣的，用来包装灵活软件项目的项目管理模式。本文介绍了Scrum的一些重要特性，并阐述了可以让你在已有RUP环境中加入Scrum理念的技术。我在工具条内提供了关于Scrum和“灵活”的术语的词汇表，并且在下文中这些术语首次出现的地方用星号作了标记。

什么是Scrum

Scrum是一种灵活的软件管理过程，它可以帮助你驾驭迭代，递增的软件开发过程。Scrum于1995年由AdvancedDevelopmentMethodologies,Inc提出，并在2001年“敏捷联盟（AgileAlliance）”形成后受到了更多欢迎。这个轻量的过程可以作为包装器，也就是说你可以把Scrum与其它灵活的过程框架组合起来，比如说RUP。

Scrum提供了一种经验方法，它使得团队成员能够独立地，集中地在创造性的环境下工作。它发现了软件工程的社会意义。Scrum一词来源于橄榄球运动，暗指这种情况：“在橄榄球比赛中，双方前锋站在一起紧密相连，当球在他们之间投掷时他们奋力争球。2”

这一过程是迅速，有适应性，自组织的，它代表了从顺序开发过程以来的重大变化。Scrum认为软件的开发不应使用和一般制造业相同的方法，也就是不应采用一种反复的模式。这种重复使得输入和输出参数更加容易预测和描述，但这并不是当今软件工程的有益目标。现代软件工程的主要挑战包括上市时间，投资回报，以及影响顾客的需要等。RUP和其他敏捷软件工程过程能够很好地迎接这些挑战。

Scrum如何工作

Scrum区别于其他开发过程之处是什么假设你是一个Scrum项目的初次观察者，那么最显而易见的不同将是每天的短会，通常在每天的同一时间在同一个房间内举行。这个会议也叫Scrum，在会议中每个团队成员仅就以下三点发言：

*自上次Scrum会议后你做了什么

*从现在到下次Scrum会议的时间里你准备做什么

*你在工作中遇到了哪些困难

Scrum团队的组成

由于一个Scrum团队最多由7人组成，会议应当不超过15分钟。Scrum管理者*主持会议，并且对整个项目的成败负责。他倾听每个成员的发言并设法解决会议中提到的各种障碍。Scrum管理者在会上对障碍提出即时的解决方案或指导，使团队不断向着目标前进。Scrum会议不同于项目会议，对团队来说，它起到了快速简报的作用。如果问题得不到解决，团队成员应向Scrum管理者或大项目成员提出质疑。

只有团队成员可以在Scrum会议上发言，但是允许有旁听者。对于人数多于7人的项目团队，Scrum建议与其扩大团队规模不如将团队分组。分组可依据功能，结构主体，或者应用，包括子应用等进行。分组后各个子团队就可以并行工作了，而且Scrum管理者可以通过Scrum会议对各个子团队的工作进行同步。Scrum甚至可以兼顾在其他地方工作的团队成员。

Scrum团队不止是一个程序员队伍，它由各种背景下的不同角色组合而成，包括商业分析者，设计师，程序员和测试者等等。更多时候，成员可以身兼多职；正确的组合决定了团队的能力和效率。

项目规划

Scrum的迭代过程被称为“疾跑”，时间为30天。在RUP中，迭代过程通常在2至6周之间，每次“疾跑”都以获得可执行可测试的代码为结束。

产品拥有者持有产品订单，他控制并区分功能的开发次序，但是工作量的评估是由Scrum团队来完成的。产品风险的所有承担者，包括Scrum团队和产品所有者，共同检视订单，然后根据优先级次序决定先开发哪一功能。除去优先级，RUP的迭代规划过程也是基于风险的。

现在团队定义的“疾跑”目标已经成为了进展控制的指导。“疾跑”过程一旦开始，团队全部与外界的交流都必须经由Scrum管理者进行。Scrum管理者务必保证团队能够专心于既定目标而不受外界干扰。

Scrum团队持有自己的“疾跑”订单，上面记录了更多关于待实现目标的具体任务的细节。在团队对“疾跑”的作用有更多了解以后，团队成员就可以调整原始的产品评估，并将“疾跑”过程中获得的信息加入到产品订单中。这些做法对Scrum进度回溯都是有益的。

Scrum团队由每天的Scrum会议，每月的“疾跑”计划和“疾跑”审查会议紧密相连，鉴于此，整个组织必然存在一种纵向的透明度。这就使得组织上的问题和挑战清晰明显。由于团队成员都亲自观察整个项目，交流也就变得简短，迅速和有效。团队是自组织的，着眼于“疾跑”的目标，这样就最大限度发挥了每一个团队成员的作用。Scrum管理者充当一个问题和交流的“票据交换所”，而不是一个控制整个团队的老板。

“疾跑”审查会议持续半天。在会上，团队向项目的风险承担者展示完成的功能模块。团队按照既定的“疾跑”目标来演示完成的内容。

订单，“疾跑”计划和回顾，管理承诺，每日Scrum会议，进度回溯，以及其他Scrum技术都是基于主要用于软件项目管理的进程模式的。这些模式在过去的大小项目和不同商业领域中都获得了成功。如果你打算采用Scrum进程模式并与RUP结合起来，下面一部分将向你解释更多要点。

Scrum与RUP的结合

现在使用RUP的软件项目可以很容易地从Scrum原则中获益，即使已经开始的项目也是如此。首先需要调研的是RUP过程模型，Scrum如何影响RUP最好的实践活动，四个阶段（初始，细化，构建和产品化），以及RUP的九个原则。RUP各阶段和原则之间的关系如图一所示。

图一：左边列出的是RUP的各个原则，与项目的四个阶段相关联。

尽管大多数原则与各个阶段都相关，上图表示出了在各个阶段中原则的不同的相关度。

RUP：软件开发的最佳实践

让我们从RUP过程框架的六个最佳实践开始吧。

迭代开发

Scrum项目强制执行迭代的开发过程，以30天为一个合适的开发时长。尽管在对“迭代”的定义上RUP更为灵活，30天的限定仍然经常被RUP使用，并且已被认为是一个有效的长度。工作总是按照30天的“疾跑”排列下来的，而不是定义一个RUP项目的一次迭代的长度。

管理需求

整个团队都可以管理需求，但是需求的控制权是由产品所有者掌握的。在RUP中，需求工程师对需求负责，但在Scrum中，这一责任属于产品所有者，通常表现为商业风险承担者。在RUP中，需求管理需要通过协作完成。

使用模块构建

体系架构是由公司的开发策略和指导决定的，或者由团队自身提出。RUP倡导的以体系架构为核心的方法导致了对各种应用结构的仔细考虑和选择。在Scrum中，这一定义较松，并决定于发布给团队的指导和标准。很多灵活的软件项目使用现代软件工具和编程语言，比如，模块构建占主导的技术。

可视化模型

RUP提倡可视化模型。甚至RUP框架本身就是可视的，有很多UML的外壳。和RUP一样，Scrum虽然不要求开发团队建构某一特定的可视化组件，但是委派Scrum团队完成这项工作。关于使用哪种组件，使用到何种程度和质量，取决于既定的“疾跑”目标。由于UML在工业界的广泛认可，很多工业专家都使用可视化技术，并且在RUP和Scrum中，可视化模型的使用都是很普遍的。

持续的保证质量

迭代，递增的开发已经为每个软件项目的质量和进展提供了很好的度量手段。Scrum团队完全集中于他们的“疾跑”目标，在30天的周期内必须展示工作成果。在这种方式下，功能是用一种重复的方式测试，度量和展示的。但是在大型组织中，质量控制是从各种角度观察的，而且需要更高质量管理的程序。Scrum可以从RUP的质量保证计划中获益，该计划由项目管理者控制，是成功的迭代开发的重要组成部分。

管理变更

在任何现代软件开发项目中都会出现变更（变化应该是受到欢迎的！），但是Scrum管理者不会为了引入发生在达成共识的目标上的变更而打断一个“疾跑”周期。他们抓住需要的变化，在本次“疾跑”结束时提出它们作为下一系列目标的一部分。这对Scrum的“疾跑”来说是最关键的。团队与外界隔离开工作，不予许变化影响当前的“疾跑”。否则，迭代开发的领域（“疾跑”的目标）的不断调整将会导致团队失去中心，不能很好完成疾跑伊始确定的功能目标。

Scrum和RUP原则

为了在Scrum的上下文环境中讨论RUP的九个原则，我把它们分成了两类。第一类是关于“雨伞活动”的，它们间接的对系统开发或组织有益，比如“环境”，“项目管理”，和“配置和变更管理”。第二类是材料活动，包括“商业模型”，“需求”，“分析和设计”，“实现”，“测试”，和“部署”。

雨伞活动

雨伞活动是指Scrum团队上层的管理机制，应由外部的风险承担者处理，比如，项目管理。除了扮演项目经理角色的Scrum管理者，团队成员应该专注于对实现Scrum目标必要的活动，而不应陷于管理工作之中。

RUP的“项目管理”原则，特别是项目规划，为软件开发团队提供了体验Scrum精髓的绝好机会。从Scrum管理者开始项目起，对团队来说RUP项目就如同一个Scrum项目。内部的组织上，管理上，语言的，非语言的交流都应被Scrum团队消除，而应该交给Scrum管理者（在RUP中称为项目经理）处理。一个RUP项目规划对如下工作来说是最理想的：

*概括项目中应用的Scrum规则；

*确定项目阶段标志；

*描述正在进行中的“疾跑”目标；

*呈现风险；

*描述评估和评估使用的技术。

在Scrum中，Scrum管理者充当了管理和Scrum团队之间的协调人。管理者管理项目的使用域和功能，同内部和外部进行交流，但是并不参与更具体活动级别的管理。这些职责和义务的不同需要在项目规划中定义。另外，Scrum团队成员的角色通常是设计师。

在一个Scrum管理的项目中，RUP环境原则下的开发工程是不断进行调整和修改的。开发工程把强制性的和可选择性的组件罗列出来作为成功的指路标。但是由于Scrum团队是作为一个独立单位工作的，团队开发的组件应该都被称为“可选择性的”以反映团队在Scrum环境中的控制作用。另一方面，你也可以从开发工程去掉所有和Scrum团队相关的组件。RUP中的一般开发工程模板都可以完成这种需要。经过一段时间，随着Scrum团队在“疾跑”过程中规律性地获得有用的文档，真实的开发工程也就成形了。

收集素材

余下的六个RUP原则对软件工程有更直接的影响，它们为Scrum团队提供了一系列可选择的组件和活动。RUP过程框架可以作为指导，提供可供考虑的有用步骤和组件。在特殊情况下，团队可以对每一条原则做出变更和修改，只要这种变更和修改有助于实现“疾跑”的目标。新手和经验不丰富的软件工程师可以把RUP作为交流的指导和一个结构化的环境。

RUP项目的四个阶段体现了软件工程过程中的不同项目样式。尽管Scrum原则适用于项目的整个生存周期，消耗大部分项目资源的细化和构建阶段最宜使用Scrum方法。与初始阶段相比，在细化和构建阶段团队的工作更加独立和指向切实目标。Scrum的“疾跑”规划，审查，和每日会议在这两个阶段是非有用的手段。

如果在初始阶段，甚至在项目开始之前，项目团队中有各种商业分析人员，那么在初始阶段Scrum也是很有益的。为了更好地保证项目的成功部署，产品化阶段可以单独作为一个项目拥有Scrum部署团队人员。对整个RUP项目来说，Scrum项目管理技术可能不是最理想的，但是它们可以在项目的不同阶段以不同形式被采用。项目规划反映了这些决定，而且阐述了在某些阶段不使用Scrum技术的原因。

使RUP适用于Scrum的工具

与IBM的RationalProcessWorkbench共用时，RUP作为进程框架体现了强大优势，而且是完全用户化的。RationalProcessWorkbench产品包含了RUP模型设计，RUP组织和RUP构建。

RUP模型设计是修改和管理核心模型的可视化工具。过程工程师可以对现有RUP框架进行修改以引入Scrum概念。使用RUP模型设计工具可以很容易的管理Scrum的角色和组件之间的依赖性。过程工程师可以使用RUP组织工具描述修改后的Scrum工作流。这样做有助于项目团队成员更好的理解Scrum过程。为了共享组织内的过程变化，过程工程师通过RUP构建工具发布进程。该工具将过程，组件和描述文档集成起来，并创建一个网络导航。

结束语

Scrum和RUP可以通过很多方式相互加强。RUP过程框架可以迎合你的项目需要；RUP开发工程和软件开发规划反映了你对使用Scrum技术的决定。根据我的经验，Scrum团队会非常规律地进行开发活动，并完成最有效的开发工程。输出的组件可以作为组织内其它项目的输入文档。

概括来说，RUP通过引入结构化并已经证实的进程框架满足了组织上的需求，而且Scrum模式可以为项目加入更多动态特性。比如说，可以很容易地向你当前的或未来的RUP项目中加入Scrum管理模式。至于软件工程的社会效应方面，Scrum已被证实的过程模式可以即时地方便需求管理，变化控制以及项目管理提供。在RUP组件对开发过程和项目文档的指导下，Scrum团队成员，特别是新手或是经验不足者，可以避免陷入软件开发的陷阱。

参考

您可以参阅本文在developerWorks全球站点上的英文原文。

AgileAlliance(2004)

KenSchwaber和MikeBeedle,AgileSoftwareDevelopmentwithSCRUMPrenticeHall,2002.

Scrum(2004).SeeThediagramat的图表可以帮助你更直观的理解Scrum的项目迭代过程。

RUP迭代开发计划的两种方法2009年5月14日随着软件技术的发展、客户需求的变化越来越快、对应用软件项目的交付的要求也越来越要跟上市场的变化，RUP非常适合这样的开发场景，在应用软件开发中已经成为最常用的开发模式。从项目管理的角度来看，RUP的开发中对于迭代计划的开发和管理是保证成功交付项目的关键。好的迭代开发计划可以有效降低项目的风险，提高团队的协作，提高项目开发效率。笔者结合在以往项目中应用RUP迭代开发的实践，总结了两种开发迭代计划的方法，并对比两者的适用情况，以期对应用RUP的项目管理人员提供借鉴。前言随着技术的快速发展和市场的快速变化，应用软件项目的交付越来越面临着需求不明确、交付进度紧、项目风险大、项目规模变大、项目团队协作困难、客户参与度高等问题。在这种情况下，RUP的迭代开发的方法已经成为应用软件开发项目的主流的开发模式，并能够有效解决这些问题。但是本文不会完整讨论整个软件开发过程中RUP的贡献和如何应用RUP。只是从项目管理和项目计划的角度探讨如何应用RUP的迭代方法开发项目计划。笔者在多个项目中应用RUP进行软件项目的开发和管理，在本文中将结合实践阐述RUP迭代计划的两种开发方法，对于指导项目经理裁剪和应用RUP有实际的参考意义。本文还将与读者分享在实际项目中应用RUP如何开发迭代目标、如何开发迭代计划以及介绍了两种不同的迭代计划的模板参考示例。迭代计划的特点迭代开发是RUP的核心思想，但是大家在刚开始使用RUP时你会发现这么多的并行工作流对项目管理同时也带来很大挑战和难度。因此使用RUP来完成项目，开发迭代计划是实施的主要难点之一。迭代计划的特点：一个迭代是总体项目计划的一个阶段需要明确的交付目标（或可以运行的系统）多个比较明确的角色的参与可以串行也可以并行体现了RUP架构驱动、关注风险的特点实现快速交付，缩短大项目的交付周期提高客户参与度和项目的可视化迭代计划的开发考虑的因素：总体项目计划项目规模大小、周期需求明确程度和技术风险团队成熟度和规模项目所处的阶段，在同一个项目的不同的阶段可以采用不同的迭代计划方法迭代目标的设置上面提到迭代计划是实施RUP的难点之一，那么设置迭代目标就是解决这个难点的重点。应用RUP开发项目的迭代目标主要是以项目开发周期中该迭代结束后所发布的交付物为主。RUP的迭代交付物通常以可以运行的系统，包括需求验证原型，架构验证原型，功能验证原型，测试系统，最终上线产品等。通常在项目前期的迭代中以发布原型系统和原型架构为主，在项目的中期以发布的增量的功能Feature、业务模块为主，而在项目的后期以增量业务功能、测试系统、非功能需求、缺陷修改为主。当然，对于不同的项目类型，迭代的目标的设置也不同，比如系统软件产品的开发项目与应用软件开发项目，新软件产品开发与软件系统升级项目的差别就非常大。另外影响迭代目标的另外一个重要因素是项目的需求和架构的成熟程度，需求的明确程度，个性化需求和共性需求的比例，是影响项目风险和迭代开发目标的重要因素。还有就是采用的架构和技术，也是影响的重要因素之一，因此迭代目标的设置需要结合和考虑项目的总体目标和采用的不同的架构方法论，比如IBMSOA项目的SOMA（Service-OrientedModelingandArchitecture）面向服务的建模和架构。概括来说，项目范围或需求、架构及决策、项目总体目标是设置迭代目标的重要的输入。比如原型迭代开发的迭代目标可以这样定义：开发架构验证框架完成2个关键业务用例的实现完成对架构决策中3个关键技术的验证实现迭代计划的开发方法RUP的开发过程模型对项目管理和项目计划提出了更高的要求，迭代计划的好坏直接影响到项目目标的实现，项目风险和生产效率。如何更好地平衡和组织项目中众多的并行活动和分配不同的项目专业角色，对项目管理提出了很大的挑战。根据笔者在众多的项目中应用和实践RUP中，总结出了两种迭代计划的开发方法。当然这两种方法并不是相互独立和分开使用的。在不同的项目或者同一个项目的不同的阶段，会交替使用甚至组合使用。下面就分别介绍这两种方法的内容、区别和适用情况。以时间为轴线的迭代计划以时间为轴线的迭代计划也是使用RUP开发整体项目计划的主要的方法。根据项目的周期分为软件开发的初始阶段（InceptionPhase）、精化阶段（ElaborationPhase）、构建阶段（ConstructionPhase）和产品化阶段（TransitionPhase）。一般来说，这四个阶段作为项目开发生命周期的主要里程碑，而细化后的迭代阶段作为项目的二级里程碑。迭代计划就是在每个里程碑下以时间顺序设置不同的开发迭代以满足里程碑的要求，达到里程碑的目标。比如在初始阶段一般有1-2个迭代周期，精化阶段一般会有2-4个迭代周期。当然迭代周期的个数要根据项目的类型、项目的规模和项目的特点不同来选择。一般对于需求不明确的应用软件的开发项目，往往精化阶段会有更多个迭代，而在产品移交阶段的迭代会比较少。而对于软件系统升级项目，往往在构建阶段的迭代会比较多。迭代周期（Duration）也是制定迭代目标要考虑的因素，迭代周期也是根据项目整体的周期长短来确定合理的周期。一般来说2个周到2个月是比较合理的选择。迭代周期的长短在同一个项目中是可以不同的，但是一般经验来看，相对固定的设置从项目管理和项目团队的工作来看更适合，可以保持比较好的项目的工作节奏。确定迭代个数和迭代周期，往往与设置迭代目标是相辅相成的。综合考虑，在完成了迭代目标、周期后，项目管理人员就可以开发项目的迭代计划了。在以时间为轴线的迭代计划一般会将多个工作流（WorkFlows）集成在一个计划中，项目团队内部有分工，但是不强调过于明显的分工。这种方法一般适合项目早期、人员较少的情况下。在项目的中后期，往往会结合以软件工程流程和角色为轴线的计划方法。在这种方法下，对于一个迭代开发周期中，更像一个小的瀑布模型。各个迭代之间没有重合（Overlap），是串行执行的。具体例子参照如下：

图1.以时间为轴线的迭代计划

图2.以时间为轴线的迭代计划示例

以软件工程流程或者角色为轴线的迭代计划当项目规模比较大，团队内部角色分工比较明确的情况下，迭代开发的活动组织在一个计划中往往难以管理和监控。这个时候项目一般会采取以软件工程流程或者开发角色为轴线来组织迭代开发计划。根据RUP的工程流程，项目中会有如下活动类型：业务建模，需求分析，分析设计，实施开发，测试，部署，配置和变更管理，项目管理，环境。理论上每种软件工程流程都会对应一个单独的计划，而且每个软件工程流程会定义自己的迭代周期和迭代次数。当然这个单独的计划只是相对独立的，一方面要与总体的项目集成计划保持一致，另一方面还要考虑与其他软件工程流程的计划的依赖关系。项目经理的非常重要的职责之一就是识别和管理这些依赖关系，使之保证项目开发的顺利进行。对于如上九种软件工程流程，并不是一定要对应九个单独的子计划，在一般的应用软件的开发项目中，一般根据角色的团队的情况分为如下几个单独的计划：业务需求开发计划软件设计计划软件开发计划测试计划管理和集成计划软件开发计划可能还会存在多个，比如一个项目有多个子系统的开发，开发团队比较大，一般又会分为子系统1开发计划、子系统2开发计划，分别组织实施。在这种情况下各个迭代计划之间是有重合（Overlap）的，项目计划活动的执行是并行进行的。具体的例子如下所示：

图3.以软件工程流程为轴线的迭代计划

图4.以软件工程流程为轴线的迭代计划示例

回页首两种计划方法的总结下表对比两种方法，总结不同的方法在不同的适用场景下的适用情况，作为项目管理人员选择和采用的依据：

表1.两种方法的对照总结适合情景时间为轴线的迭代计划工作流程和角色为轴线的迭代计划适合的项目规模都可以全部或大型项目适合项目团队的大小小团队大团队适合的项目阶段全部或者项目早期项目的中期依赖内部依赖，串行执行造成团队之间或者计划之间的依赖，并行执行管理难度中低高综上所述，在一个项目中，项目经理和项目管理人员往往根据项目的具体情况和项目所在阶段来采用不同的迭代计划的开发方法。甚至将两者结合，制定适合项目的迭代计划，从而降低项目风险、提供项目团队的协作能力，提高生产效率，实现快速交付的目标。

敏捷RUP：来自实战中的经验由ScottW.Ambler所做的介绍这篇文章实际上是由三篇文章组合而成的。它们为在IBM®Rational®UnifiedProcess®或者简称为RUP®团队上面应用敏捷策略提供了被证明为行之有效的建议。本文是由MarkLines、JoshuaBarnes、以及JulianHolmes分别撰写的，它们都是UnifiedProcessMentors（）的共同创办人。这三位已经通过书籍指导了全世界成千上万名软件开发方面的从业者，举办了几十场研讨会，撰写了多部著作，作为咨询顾问和用户组的主席人等。他们工作于遍及世界各地的机构中，将他们的处理过程理论付诸实践，通过实例引导并且通过结构的改变驱动成功。我的经验是，好的RUP就是敏捷的1并且包含了许多成功地测量敏捷技术所需要的建议。第一篇文章“将规则引入到敏捷的生命周期之中”是由MarkLines撰写的，它展示了RUP需求管理技术和风险驱动开发周期是如何将所需要的规则性水平引入到许多机构中的，并且还不失敏捷方法的特点之一：灵活性。作者认为您并不希望需求在开发周期的后期发生根本上的变更，而前期的一小部分投资能够从根本上减少您的开销、进度、以及整个项目所面临的风险。第二篇文章“在大型机构中将敏捷性引入RUP的策略”是由JoshuaBarnes撰写的，它从一个相反的方向对待